Malaysia
MyInvois-Übermittlung, Validierung und Betriebslebenszyklus
2026-08-28
MyInvois unterstützt Portal und API, doch ein stabiler Unternehmensprozess endet nicht mit der Dateiübermittlung. Validierungsergebnis, Plattformantwort, Käuferdokument, Korrekturpfad und Nachweise müssen mit der ursprünglichen Geschäftstransaktion verbunden bleiben.
So nutzen Sie diesen Leitfaden
Ein gutes Projektergebnis wiederholt nicht nur die Vorschrift. Es schafft ein nachvollziehbares Entscheidungsmodell, das Regeln mit Gesellschaften, Transaktionsszenarien, Quelldaten, Systemverhalten, Betriebsverantwortung und Nachweisen verbindet.
End-to-End-Betriebsablauf
Der Plattformaufruf ist nur eine Stufe des Geschäftslebenszyklus.
- Qualifizieren
Umfang, Kanal und Dokumentweg vor der Erzeugung bestimmen. - Validieren
Fehlende Identitäten, Steuern, Beträge und Bezüge blockieren. - Erzeugen
Darstellung mit nachvollziehbarer Mapping-Version erstellen. - Senden
Duplikate durch Idempotenz und Korrelation verhindern. - Interpretieren
Antwort in Finance-Status und Aktion übersetzen. - Liefern und abstimmen
Kundenzustellung, Ergebnis und Buchung koordinieren. - Aufbewahren
Quelle, Payload, Antwort, Darstellung und Ereignisse zusammen archivieren.
Länderspezifische Entscheidungen
01
Übermittlung ist noch kein Geschäftsergebnis
Das Portal eignet sich für manuelle oder geringere Volumen, die API für systemgestützte Übermittlung. In beiden Fällen muss klar sein, welches SAP/ERP-Dokument maßgeblich ist, ob Identitäten und Klassifikationen vollständig sind und wer einen Validierungsfehler bearbeitet.
02
Statusmodell für Finanzanwender
Technische Antwortcodes sollten in Geschäftsstatus wie bereit, übermittelt, validiert, abgelehnt, Korrektur erforderlich oder abgeschlossen übersetzt werden. Finanz- und Betriebsteams müssen diese Zustände sehen können, ohne Middleware-Protokolle zu interpretieren. Jede Änderung sollte Anfrage, Antwort, Zeitpunkt und Verantwortlichkeit dokumentieren.
03
Dokumentenkette zusammenhalten
Ursprungsrechnung, gesendete Nutzlast, validiertes Ergebnis, lesbare Kundenansicht und spätere Anpassung bilden eine nachvollziehbare Kette. Das unterstützt Kundenservice, Periodenabstimmung und Prüfung und verhindert, dass ein erfolgreicher HTTP-Aufruf mit einem abgeschlossenen Geschäftsprozess verwechselt wird.
Jedes Artefakt als eigenes Kontrollobjekt behandeln
Handelsrechnung, Payload, Plattformantwort und Kundendokument hängen zusammen, sind aber nicht austauschbar. Ihre getrennte Identität muss in Monitoring, Abstimmung und Auditabruf sichtbar bleiben.
| Entscheidungsbereich | Zu klärende Entscheidung | Aufzubewahrender Nachweis |
|---|---|---|
| Quelltransaktion | Autoritatives ERP-Dokument und auslösendes Ereignis festlegen. | Dokumentschlüssel, Version, Gesellschaft, Zeit, Status. |
| Strukturierter Payload | Nationale Darstellung aus validierten Fakten erzeugen. | Payload-/Mapping-Version, Prüfsumme, Korrelations-ID. |
| Plattformantwort | Technische und fachliche Antworten nicht in einem Erfolgsflag verdichten. | Originalantwort, normierter Status, Grund, Aktion. |
| Kundendarstellung | Geeignetes lesbares Dokument über den vereinbarten Kanal liefern. | Dokument, Empfänger, Kanal, Zeitpunkt. |
| Änderungskette | Ersatz, Storno und Folgebelege mit dem Original verbinden. | Originalbezug, Ereignisse, Endstatus. |
Erforderliche Fehlerszenarien
- Ablehnung nach ERP-Buchung.
- Timeout bei möglicher Annahme.
- Duplikat mit anderer technischer ID.
- Annahme ohne Kundenzustellung oder Abstimmung.
- Korrektur ohne stabilen Originalbezug.