Business Central: Post General Journal Lines
Business Central接続を通じて、PlaidCloudの共有ERP書き込みパイプライン経由で、Business Centralに総勘定元帳仕訳明細を転記します。このステップは、ヘッダーテーブル（journal_idごとに1行）と明細テーブル（journal_idごとに1行以上）を受け取り、既存の仕訳バッチ内に明細を作成して、そのバッチを転記します。検証のみを指定すると、転記せずにすべての仕訳を構築してチェックします。オプションの結果テーブルに結果を記録できます。
- Business Central接続 — 転記に使用するBusiness Central接続です。
- 環境 — 接続の環境です。
- ヘッダーテーブル —
journal_idごとに1行。明細の転記先となるBusiness Centralの仕訳バッチ名、document_number、posting_date、および通貨ラベルです。 - 明細テーブル —
journal_idごとに1行以上。符号付きのamount（借方は正、貸方は負）、account_idまたはaccount_number、account_type、descriptionです。 - 結果テーブル — 出力テーブルID。
journal_idごとに1行で、journal_id、external_id、internal_id、status、messageを含みます。 - 検証のみ — デフォルトでオンです。事前チェックのみを行い、元帳の確保や転記は行いません。このフィールドがまったく含まれないステップ設定（たとえばREST API、MCP、ワークフローバンドルのインポートで作成されたもの）も、本番の転記ではなく検証のみがデフォルトになります。
- エラー時に続行 — デフォルトでオンです。1つの仕訳が失敗しても、残りの仕訳の転記を続けます。オフにすると、最初の失敗でバッチを停止します。
転記の仕組み
Section titled “転記の仕組み”Business CentralのMicrosoft.NAV.postバウンドアクションは、このリクエストが作成した明細だけでなく、仕訳バッチ全体を転記します。PlaidCloudはこれを呼び出す前にバッチを読み戻し、このリクエストのドキュメント番号が付いていない明細が含まれている場合は、転記せずにエラーを記録します。このガードにより、以前の部分的な失敗で残った明細が、同じバッチへの無関係な後続の転記によって総勘定元帳に紛れ込むことを防ぎます。
generalLedgerEntriesは読み取り専用で、転記済みのデータのみを含むため、PlaidCloudは仕訳バッチを読み直すのではなく、そこでドキュメント番号を探すことで転記の成功を確認します。generalLedgerEntriesで一致が見つかれば、明細が作成されただけでなく、実際に転記されたことの証明になります。
| 制限事項 | 内容 |
|---|---|
| 書き込み可能なドキュメントタイプは1つ | サポートされているのは総勘定元帳仕訳明細の転記のみです。Business Centralのドラフトドキュメントフロー（販売/購買請求書、ドラフト→転記済み）はサポートされていません。そのフローの正確な転記アクションがMicrosoftの公開ドキュメントで特定されていないためです。 |
| 既存のバッチのみ | このステップが仕訳バッチを作成することはありません。先にBusiness Centralで作成し、journal_idをそのバッチに向けてください。 |
| 同一バッチへの同時転記 | 冪等性ガードの対象はドキュメント番号であり、仕訳バッチではありません。そのため、異なる2つのドキュメント番号を同じバッチに同時に転記した場合、同じドキュメント番号での2回の呼び出しのように直列化されることは保証されません。1つのバッチへの同時転記は避けてください。 |
- Business Centralへの接続 — 設定、プレビュー、転記までの手順を説明したウォークスルー
- Business Central RESTコネクター
- Business Centralステップ
- ERP転記履歴の確認