MyInvois電子インボイスの送信、検証、ステータス管理

送信受付、最終検証、顧客交付、訂正は、一つの請求ライフサイクルにある別々の時点です。

マレーシア

記事種別

プラットフォーム解説

最終確認日

2026-08-30

Submit Documents の応答を処理完了とみなすのは典型的な誤りです。MyInvois は初期受付と完全検証を分離しています。成功時は HTTP 202 と識別子が返りますが、文書は Submitted の後に Valid または Invalid になります。

プラットフォーム解説 · MyInvois

MyInvoisの処理方式

SAP Billing が計上され、MyInvois が要求する JSON または XML に変換されたとします。送信前に、発行納税者、買い手識別、文書種別、税処理、金額、元文書参照を決めておく必要があります。MyInvois がその業務判断を代替するわけではありません。

Submit Documents は構造と送信者を初期確認します。通過した文書には submission UID と文書識別子が割り当てられます。完全検証が終わっていないため応答は HTTP 202 です。

連携は制御された間隔で Get Submission を利用します。財務には HTTP コードではなく業務状態を表示し、元インボイスを MyInvois UUID、送信参照、検証証跡へ結び付けます。

この節の参照先: MyInvois Submit Documents API · MyInvois Get Submission API · MyInvois連携プラクティス

五つの主要処理段階

1

送信準備完了

必須業務事実と文書版が確定。識別、金額、元文書が不足すれば送信前に停止します。

2

処理受付

HTTP 202、submission UID、初期受付・拒否文書が返ります。これは通信の進行であり最終法定状態ではありません。

3

検証完了

ポーリングで各文書が Valid または Invalid になります。無効詳細と原文応答を責任チームへ渡します。

4

顧客・ERP整合

有効文書、顧客向け表現、ERP文書を接続します。Validだけでは顧客交付や会計照合は証明されません。

5

調整・完了

取消、買い手拒否要求、クレジット、デビット、返金文書を元インボイスに関連付けて終端まで照合します。

この節の参照先: MyInvois Submit Documents API · MyInvois Get Submission API · MyInvois連携プラクティス

主要状態の運用上の意味

Submitted

完全検証が進行中。

推奨間隔で照会し、無統制な重複送信をしません。

Valid

MyInvois検証を通過。

識別子と検証リンクを保存し、顧客交付とERP照合を完了します。

Invalid

検証ステップが失敗。

詳細エラーを取得し、権威あるソースまたは承認済みマッピングを直して再送要否を決めます。

Cancelled

発行者が許可された手順で有効文書を取消。

取消文書と理由を残し、原履歴を上書きしません。

統制されたSAP/ERP–MyInvoisアーキテクチャ

元請求から訂正まで、業務事実、送信状態、財務証跡が接続されて初めて連携が完了します。

権威ある請求事実

統制されたSAP/ERPから取引当事者、税、金額、通貨、分類、原文書参照を取得します。

決定的な変換

シナリオごとに文書種別と版を一つに定め、欠落時は停止し、税番号や分類を暗黙補完しません。

送信と冪等性

安定した業務キーで重複を防止し、実送信データを保持し、安全な再試行と新規法定文書を区別します。

状態・例外管理

最終状態を照会し、検証詳細を担当者へ配分し、取消期限と無効文書の完了防止を管理します。

照合と保管

ERP文書、MyInvois UUID、状態履歴、顧客表示、訂正文書、期間締め照合を接続します。

一般的な統制上の不備

HTTP成功を財務状態にする

送信から最終検証までが隠れ、未完了文書が完了に見えます。

状態確認せず再送する

同一送信は重複やスロットリングの対象です。先に照会し、冪等規則で再送します。

顧客PDFだけを保存する

ソース事実、構造化文書、応答、識別子、最終状態、後続調整も証跡に必要です。

よくある質問

HTTP 202が完了ではない理由は。

処理受付を示すだけで、最終的な有効性は後続の状態結果で確認します。

再試行はどう管理しますか。

元の業務キーと応答に基づき、照会、安全な再試行、訂正文書を判断します。盲目的な再送は重複を招きます。

SAP/ERPに何を保存しますか。

業務識別、送信参照、submission UID、document UUID、状態、時刻、エラー、訂正関係を保存します。

顧客文書はいつ発行しますか。

通信受付ではなく、対象シナリオと最終状態に紐づく承認済み方針で決めます。

連携統制の要件

財務担当者はミドルウェアログを開かず、現在位置、次の担当行動、ERP計上からプラットフォーム結果と顧客文書までの履歴を答えられるべきです。答えられないなら、接続はあっても業務運用は完成していません。

公式情報源

最終確認日: 2026-08-30

情報に関する注意: 本記事は一般的なビジネス情報であり、法務・税務・会計上の助言ではありません。企業固有の取扱いは最新の公式情報と現地専門家に確認してください。
マレーシア電子インボイス:ガイドラインv4.8、適用範囲、2026年MyInvois更新
企業導入に関連するガイドライン、SVDP文書版、本番検証の変更を解説します。