Visits: 152

BIS Invoice Response 3.0の抄訳

2.原則と前提条件

この章では、PEPPOLインボイス応答の使用の基礎となる原則と前提条件について説明する。 この仕様のインボイスという用語は、本文で特に明記されていない限り、または文脈から明らかでない限り、インボイスとクレジットノートの両方に使用される。
インボイス応答は、当事者が支払い済みまたはキャンセル済みの決済に合意するためのインボイスとクレジットノートの交換プロセスで使用できる。インボイスまたはクレジットノートの発行者としての販売者に、インボイスまたはクレジットノートのステータスに関する情報を提供し、インボイスまたはクレジットノートの受信者としての購入者に、販売者に情報を提供し続けるための効率的な手段を提供する。

2.1. 一般的なインボイス応答メッセージ

電子メッセージの作成から、1つ以上のトランスポートネットワークを経由するトランスポートラインを下って、指定された受信者に到達し、メッセージコンテンツの最終的な処理に至るまで。 メッセージが通過するアクションのステータスまたは結果について、管理者に応答する必要がある場合があります。 これらの応答は性質が異なるが、この文書の範囲では、次の主要なグループに分けることができる。

2.1.1. トランスポートの確認

これらは、トランスポートネットワーク内で交換されるメッセージであり、メッセージをトランスポートラインに伝送するプロセスについて通知する。 これらの応答は、特定のポイントへの配信が成功したかどうかを管理者の誰かに通知し、配信が成功しなかった理由など、関連する問題の詳細を含む場合がある。 これらの応答の重要な性質は、転送されるペイロードのコンテンツの検証または処理の結果にまったく作用しないことである。 これらの応答メッセージは一般に“acks” (確認応答 acknowledgementsの略）と呼ばれ、PEPPOLではPEPPOLネットワークのトランスポートプロトコル（PEPPOL eDeliveryネットワーク仕様）の一部（例：MDN –メッセージ処理通知– AS2）。

2.1.2. ビジネスレベルの対応

受信されて処理に割り当てられたメッセージは、受信者に代わってアクションを要求する場合がある。 その受信者の行動は、管理者に報告する必要があるかもしれない。 例としては、技術的に正しいインボイスを受け取ることができたが、受信者は、誤った値、配信の問題などの業務上の理由でインボイスに異議を唱えることを決定。これらの応答の重要な性質は、 受信者が受信したメッセージインスタンスについて下した業務上の決定を報告することである。 業務レベルの応答は、インボイス以外のさまざまな種類の文書の処理に影響を与える可能性がある。

2.2.インボイス応答メッセージの範囲

インボイス応答はインボイスおよびクレジットノート固有の応答メッセージであり、購入者の業務ルールおよび/または販売者/購入者契約に基づいて、購入者の承認および支払いプロセスにおけるインボイスの状態を販売者に通知するために使用できる。
インボイス応答は、ユーザーに次の利点がある。

• インボイス応答は、インボイスの処理が購入者側で異議を唱えられた場合に、販売者が早期にアクションを開始するのに役立つ
• 応答は、インボイスが適正手続きであるかどうか、またはそのプロセスが中断されて販売者からのアクションが必要かどうかを販売者に通知する
• インボイス応答は、インボイスが承認されたとき、または支払いが開始されたときに販売者に通知するため、販売者はキャッシュフローを管理し、支払いチャネルを介した資金の受け取りを監視できる
• インボイス応答は、インボイス検証プロセスで販売者にインボイスの状況を通知し続けるための自動化された手段を購入者に提供し、したがって、手作業での状況確認の必要性を低減または排除する
• インボイス応答は、手作業での処理が必要な場合もあるが、販売者側での自動処理をサポートするように設計されている
• インボイス応答は、購入者から販売者への有益なメッセージ
• インボイス応答は、購入者側のインボイス処理プロセスに関する購入者から販売者へのフィードバックループを構築する
• インボイス応答は、構造化または非構造化形式でインボイス処理における購入者の決定について購入者が販売者に通知するためのオプション

2.2.1. 範囲内

次の概念は、インボイス応答の範囲内。

• 購入者は、購入者側のインボイスとクレジットノートの処理手順と状況について販売者に通知できる
• インボイス応答は、購入者のビジネスルールに基づいている
• インボイス応答は、購入者から販売者への一方向のメッセージのみ
• 複数の応答メッセージを1つのインボイスまたはクレジットノートと交換できる可能性がある
• 応答コンテンツによっては、販売者側での手動による対応が必要な場合がある
• インボイス応答は、インボイス状況のプッシュメッセージのみをサポートする
• インボイス応答は、販売者が自動的に要求することはできない
• 送信されたインボイスが受信され、処理できることを確認する

2.2.2. 範囲外

次の概念は、インボイス応答の範囲外。

• 行レベルでのインボイス応答
• 1つの応答メッセージに複数のステータスがある場合
• 販売者側の完全自動化　–　すべてのエラーをエンコードする必要はない
• 双方向コミュニケーション　–　応答に関する議論
• インボイス応答メッセージの照会
• 送信レベルのステータス
• 添付ファイルのサポート

2.3. 組織と役割

次の表は、インボイス応答メッセージの処理における組織と役割の定義を示す。 組織とは、役割に責任を持つ個人または団体。 彼らはそれらを彼ら自身で実行するか、またはそれらを外部に委託するかもしれない。

受注者は、製品および/またはサービスを提供する法人または組織
受注者の役割の例：売り手、荷送人、債権者、経済運営者

表1.組織と役割

組織/役割	タイプ	定義
受注者	組織
発注者	組織	発注者は、製品、サービス、または仕事を要求している法人または組織 発注者の役割の例：購入者、荷受人、債務者、契約機関
販売者	役割	購入者に販売された商品またはサービスのインボイスを発行し、債務を負っている人。 支払いを請求し、請求の問題を解決し、和解を手配する責任を負う当事者。 また、インボイス発行者、売掛金、債権者、経済オペレータとしても知られている
購入者	役割	販売者から購入した商品やサービスのインボイスを受け取り、債務を負っている人。 購入に関連する決済を行う責任を負う当事者。 また、インボイス宛先、買掛金、債務者としても知られている
サービスプロバイダー	組織	インボイス応答メッセージを送信または受信するために、受注者および/または発注者のいずれかまたは両方によって契約されている組織

2.3.1.組織の責任

この段落では、技術的、実用的、および有益な観点から、インボイス応答プロセスで各組織が実行する責任と活動を示す。ここで説明する措置の法的意味は、この文書の範囲外。

販売者

• インボイス応答をサポートする義務はない。
• 販売者がインボイス応答のサポートを登録している場合、販売者はインボイス応答メッセージを受信し、この仕様に従ってアクションを実行する責任がある。

購入者

• インボイス応答を送信する義務はない。
• インボイス応答の作成を担当する。インボイスの検証で使用されるビジネスルールを順守する責任がある。
• インボイス応答ドキュメントのフレームでインボイス応答をいつどのように使用するかを担当します。
• 販売者に期待される行動を表現する責任がある。
• 販売者との潜在的な問題を解決するために、購入者が自分または彼に代わって作成したすべてのインボイス応答メッセージの可視性を維持することを推奨する。
• インボイス応答の使用について、販売者と当事者間協定を結ぶ場合がある。

3.プロセスと典型的なユースケース

3.1. ビジネスプロセス図

3.2.一般的なプロセス

このプロセスは、販売者側が電子インボイスを準備し、それを購入者に送信するときに始まる。インボイスが検証されて転送された後、購入者はインボイスを受け取る。
購入者は、処理可能な形式でインボイスを受け取ったら、インボイス応答でこれについて販売者に通知することができる。
受領後、販売者は通常、インボイスのレビューと承認のプロセスに入る。承認プロセスにより、コメントなしでインボイスがそのまま承認される場合がある。その場合、購入者は販売者にインボイス応答を送信して、インボイスが承認され、期日に支払われることを販売者に通知する。承認プロセスは、クレジットノートでは少し異なる場合がある（特に、ステータス「支払い済み」は適用されないが、他のステータスはその目的を果たす）。
承認プロセス中に、さまざまな問題が特定される場合がある。数量または金額が購入者のデータと一致していない、インボイスを正しく処理するための情報が不足している、インボイスの条件が契約または契約と一致していない、などの問題。問題の性質に応じて、購入者は次のいずれかを行う場合がある。

• 購入者は承認プロセスを保留にし、ステータスが「照会中」のインボイス応答を送信して販売者に通知し、問題の説明を追加することができる。
  • 販売者が問題に対応すると、承認プロセスが続行されるか、購入者がさらに問題を提起する可能性がある。
• 購入者は条件付きで請求書を承認することができる。その場合、購入者はそれぞれの状況と条件を記載したインボイス応答を販売者に送信する。
  • 販売者は異議がある場合など外部から応答する場合がある。 応答しない場合もあるが、その場合、購入者は条件に従ってインボイスを支払う。
  • 最も一般的な例は、請求書に、契約に沿っていない期日や支払いアカウントなどの支払い条件がある場合
  • それから、買い手は、インボイスが契約に従って支払われることを通知し、販売者が反対しない限り、そうすることを続行することができる。
• 購入者はインボイスを拒否することができる。その場合、販売者に通知し、拒否の理由を述べ、場合によってはクレジットノートを要求する。
  • これはインボイスの最終ステータスであるため、販売者が拒否に同意しない場合は、外部からフォローアップする必要がある。

インボイスが承認された場合、または条件付きで承認された場合、購入者はやがて期限までに支払いを行う。 その後、購入者は販売者に支払いが開始されたことを通知することができる。

3.3. インボイス応答プロセスルール

インボイス応答プロセスは、トランザクションが発行される方法と時期、および送信者と受信者の間でトランザクションが処理される方法を管理する。

表2.インボイス応答プロセスのルール

RuleID	ルール
OP-BR111-R001	インボイス応答は、購入者から販売者への一方向のメッセージのみ。 インボイス応答は、購入者から販売者に送信され、購入者の業務プロセス内のインボイスの状況を通知することを目的としている。
OP-BR111-R002	各インボイス応答メッセージは、個々のインボイスに対して、一度に1つの状況コード（トップレベルの状況）を伝達することを目的としている。 インボイスのいくつかの状況について通知するには、いくつかのメッセージを順番に使用する必要がある。 インボイスは、一度に1つの状況しか持つことができない。
OP-BR111-R003	1つのインボイスに対して複数のインボイス応答を送信できる。
OP-BR111-R004	インボイスの状況が「拒否」または「支払い済み」になっている場合、そのインボイスに関してそれ以上のインボイス応答を送信することはできない。 つまり、販売者はそれらを無視するかもしれない。
OP-BR111-R005	インボイスの状況が承認済みの場合は、その後に状況が「支払い済み」のインボイス応答のみがある。 つまり、販売者はそれらを無視するかもしれない。
OP-BR111-R006	購入者は、3営業日以内に最初のインボイス応答を提供しなければならない(SHALL)。
OP-BR111-R007	インボイス応答メッセージは、購入者のインボイス ワークフロー プロセスを規定していない。 購入者が異なれば、インボイスのワークフロープロセスも異なる場合がある。
OP-BR111-R008	インボイス応答には法的権限はない。
OP-BR111-R009	インボイス応答は、請求書の内容を変更しない。
OP-BR111-R010	インボイス応答は、購入者と販売者の間の商業的責任を変更しない。
OP-BR111-R011	インボイス応答（拒否された場合でも）は、契約または実際の商取引、あるいはクレジットノートの場合はその逆によって義務が存在する場合、販売者に対する支払い義務から購入者を解放しない。
OP-BR111-R012	インボイスの状況は、次の順序で進む。 AB Acknowledged　確認した IP In process　処理中 UQ Under query　問い合わせ中 CA Conditionally accepted　条件付き受入 RE Rejected (Final status) 拒否（最終状況） AP Accepted (approved)　了解（承認済み） PD Paid 支払い済み（最終状況、状況コード「支払い済み」はクレジットノートに関連して使用されない可能性がある） プロセスは任意の状況から開始でき、すべての状況を報告する必要はない。
OP-BR111-R013	販売者は、インボイス応答で購入者が提示した状況について、外部プロセスで争うことができる。
OP-BR111-R014	文書タイプコードは、応答が送信される元のメッセージの文書タイプコードに準拠している必要がある（通常、コマーシャルインボイスの場合は380、クレジットノートの場合は381）。

以降省略
3.4. Code Policy
3.5. Typical use cases
4. Semantic datatypes
4.1. Primitive types
4.2. Semantic data types
5. Code lists
5.1. Code lists for coded elements
5.2. Code list for identifiers
6. Description of selected parts of the invoice message response
6.1. Message identification
6.2. Message note
6.3. Sending and receiving parties
6.4. Response
6.5. Document reference
7. Peppol Identifiers
7.1. Profiles and messages
7.2. Customization and Profile identifiers
7.3. Namespaces