このセクションでは、請求書全体で使用される列挙型について説明します。 リクエストとレスポンスのドキュメントですUBL 標準では列挙型は定義されていない 標準の一部として使用できます。そのため、可能な限り定義済みの列挙型を使用します。 基づいて、独自のカスタムモデルによってこれらの標準を 使用できます。
バッチファイルのステータス コード
この列挙型により、レスポンス ファイルがより明確になります。
エラー処理が
<ApplicationResponseBatch>/<FileStatus>。
| ステータス コード | 説明 | 想定される措置 |
|---|---|---|
| S | 問題なし、ファイルは処理されました | 成功 |
| E | ファイル処理エラー（復号エラー、ファイルを開けない） | 手動介入 |
| D | 重複ファイル | 特別なご対応は不要です |
ステータス理由コード
この列挙型により、cbc:StatusReasonCode の説明がより明確になります。
表示されます。ステータスの理由コードを組み合わせて使用します。
Status Clarification Reason コード
Peppol BIS 3.0 標準
必要に応じて Google 独自の定義で補足できます。
| ステータス理由コード | 説明 | 期待されるアクション（エンティティ固有） |
|---|---|---|
| なし | 問題なし | 成功 |
| 番号 | 参照ファイルが正しくない（購入者の税務情報が正しくないか、欠落している） | 失敗 + 改訂/再請求 |
| TER | 請求書を処理するための過去の時間の制約。注: Google 拡張機能 | 失敗 + 改訂/再請求 |
| SVE | 請求書リクエストの構文違反、形式が無効、情報が不足している | 手動介入 |
| CER | 通信/一時的なエラー - ベンダーがリクエストを再試行します。注: Google 拡張機能 | 待機&詳しくは、 |
| OTH | ステータスの理由はコードで定義されていません | 手動介入 |
| PEN | 請求書の生成は保留中です。注: Google 拡張機能 | 待機&詳しくは、 |
| COM | Permanent Communication Failure - ベンダーはリクエストを再試行しません。注: Google 拡張機能 | 手動介入 |
| REJ | バックエンド システムが拒否されました（致命的です） | 手動介入 |