Land
Malaysia
Artikeltyp
Plattformerklärung
Zuletzt geprüft
2026-08-30
Ein häufiger Integrationsfehler ist, die Antwort von Submit Documents als Prozessende zu behandeln. MyInvois trennt Annahme und vollständige Validierung: Die erfolgreiche Einreichung liefert HTTP 202 und Identifikatoren, während das Dokument zunächst Submitted und später Valid oder Invalid sein kann.
Plattformerklärung · MyInvois
Verarbeitungsmodell von MyInvois
Ein SAP-Billing-Beleg wurde gebucht und in MyInvois-JSON oder -XML umgewandelt. Vor der Übertragung müssen ausstellender Steuerpflichtiger, Käuferidentität, Dokumenttyp, Steuerbehandlung, Beträge und Ursprungsreferenz feststehen. MyInvois ersetzt diese Geschäftsentscheidungen nicht.
Submit Documents prüft zunächst Struktur und Einreicher. Erfolgreiche Dokumente erhalten eine Submission UID und Dokumentkennungen zur weiteren Verarbeitung. HTTP 202 zeigt gerade, dass die vollständige Validierung noch nicht abgeschlossen ist.
Anschließend ruft die Integration Get Submission in kontrollierten Abständen auf. Finanzanwender benötigen den Geschäftsstatus statt des HTTP-Codes; die Quellrechnung bleibt mit MyInvois-UUID, Einreichungsreferenz und Validierungsnachweis verbunden.
Quellen zu diesem Abschnitt: MyInvois-API Submit Documents · MyInvois-API Get Submission · MyInvois-Integrationspraxis
Fünf wesentliche Verarbeitungsstufen
Einreichungsbereit
Pflichtfakten und Dokumentversion stehen fest. Fehlende Identitäten, Beträge oder Ursprungsbezüge blockieren vor der Übertragung.
Zur Verarbeitung angenommen
MyInvois liefert HTTP 202, Submission UID und zunächst angenommene oder abgelehnte Dokumente. Das ist Transportfortschritt, kein endgültiger Rechtsstatus.
Validierung abgeschlossen
Die Statusabfrage ergibt Valid oder Invalid. Fehlerdetails und Originalantwort gehen an das verantwortliche Team.
Kunde und ERP abgestimmt
Validiertes Dokument, lesbare Kundendarstellung und ERP-Beleg sind verbunden. Valid beweist weder Zustellung noch Buchungsabstimmung.
Angepasst und abgeschlossen
Storno, Käuferablehnung, Gutschrift, Belastung oder Erstattung bleiben mit dem Original verbunden und erreichen einen abgestimmten Endzustand.
Quellen zu diesem Abschnitt: MyInvois-API Submit Documents · MyInvois-API Get Submission · MyInvois-Integrationspraxis
Operative Bedeutung der Hauptstatus
Submitted
Die vollständige Validierung läuft.
Empfohlen weiter abfragen und keine unkontrollierte Dublette senden.
Valid
Das Dokument hat die MyInvois-Validierung bestanden.
Kennungen und Validierungslink speichern, Kundenzustellung und ERP-Abstimmung abschließen.
Invalid
Mindestens ein Prüfschritt ist fehlgeschlagen.
Details abrufen, maßgebliche Quelle oder freigegebenes Mapping korrigieren und Neueinreichung entscheiden.
Cancelled
Der Aussteller hat ein gültiges Dokument im zulässigen Verfahren storniert.
Dokument und Grund beibehalten; die Historie nicht überschreiben.
Kontrollierte SAP/ERP-MyInvois-Architektur
Die Integration ist erst vollständig, wenn Geschäftsfakten, Übermittlungsstatus und Finanznachweis vom Ursprungsbeleg bis zur Korrektur verbunden bleiben.
Maßgebliche Rechnungsfakten
Genehmigte Parteien-, Steuer-, Betrags-, Währungs-, Klassifikations- und Ursprungsreferenzen aus geregelten SAP/ERP-Quellen lesen.
Deterministische Transformation
Je Szenario genau einen Dokumenttyp und eine Version zuordnen; fehlende Fakten sperren und Steuer-ID oder Klassifikation nicht still ersetzen.
Übermittlung und Idempotenz
Stabilen Geschäftsschlüssel nutzen, Doppelübermittlung verhindern, Payload aufbewahren und sichere Wiederholung von neuem Rechtsbeleg trennen.
Status- und Ausnahmebearbeitung
Endstatus abfragen, Validierungsdetails zuordnen, Stornofristen steuern und ungültige Belege nicht abschließen.
Abstimmung und Archiv
ERP-Beleg mit MyInvois-UUID, Statushistorie, Kundendarstellung, Korrektur und Periodenabstimmung verbinden.
Häufige Kontrolldefizite
HTTP-Erfolg als Finanzstatus
Die Phase bis zur endgültigen Validierung verschwindet und offene Rechnungen wirken abgeschlossen.
Wiederholung ohne Statusprüfung
Identische Einreichungen können als Dublette erkannt oder gedrosselt werden. Erst abfragen, dann nach Idempotenzregel wiederholen.
Nur das Kunden-PDF archivieren
Zur Nachweiskette gehören auch Quellfakten, strukturierte Nutzlast, Antwort, Kennungen, Endstatus und spätere Anpassungen.
Häufige Fragen
Warum beendet HTTP 202 den Prozess nicht?
Es bestätigt nur die Annahme zur Verarbeitung. Die endgültige Gültigkeit folgt aus späteren Übermittlungs- und Dokumentstatus.
Wie sind Wiederholungen zu steuern?
Geschäftsschlüssel und vorhandene Antwort entscheiden zwischen Abfrage, sicherer Wiederholung und Korrektur. Blinde Wiederholung kann Duplikate erzeugen.
Was sollte SAP/ERP speichern?
Geschäftsidentität, Payload-Referenz, Submission-UID, Dokument-UUID, Status, Zeitstempel, Fehler und Korrekturbeziehung.
Wann wird das Kundendokument freigegeben?
Nach dokumentierter, szenario- und endstatusbezogener Regel; reine Transportannahme reicht nicht.
Anforderungen an die Integrationskontrolle
Finanzanwender sollten ohne Middleware-Protokolle beantworten können: Wo steht die Rechnung? Was passiert als Nächstes? Lässt sich der Weg von der ERP-Buchung bis zum Plattformresultat und Kundendokument vollständig rekonstruieren? Wenn nicht, ist die Schnittstelle verbunden, der Prozess aber noch nicht betriebsfähig.
Amtliche Quellen
Zuletzt geprüft: 2026-08-30