NetSuite仕訳エントリの転記

Post NetSuite Journal Entryステップを使用して、PlaidCloudのプロジェクトテーブルから NetSuite に仕訳エントリを転記します。このガイドでは、ヘッダーテーブルと明細テーブルからバッチを作成し、NetSuite には一切触れずにプレビューしたうえで転記し、結果を読み取ります。

前提条件

仕訳エントリを作成できるロールを持つ、動作する NetSuite 接続（読み取り側のガイドで説明している REST/OAuth の設定に加えて、Journal Entry レコードに対する作成アクセスが必要です）。
プロジェクト内の 2 つのソーステーブル。
- 仕訳エントリごとに 1 行を持つヘッダーテーブル。
- 仕訳エントリごとに 1 行以上の借方/貸方行を持つ明細テーブル。

ヘッダーテーブルと明細テーブルの準備

仕訳エントリごとに 1 行を持つヘッダーテーブルを作成またはインポートします。最低限、次の列が必要です。

列	マッピング先	必須
仕訳の識別子	Journal ID	はい
NetSuite のサブシディアリ	Subsidiary	はい
エントリの日付	転記日	はい
NetSuite の通貨	Currency	いいえ
エントリレベルのメモ	Memo	いいえ
呼び出し元が指定する外部 ID	External ID	いいえ

仕訳エントリごとに 1 行以上を持つ明細テーブルを作成またはインポートします。各行はヘッダー行と同じ仕訳の識別子を共有します。

列	マッピング先	必須
仕訳の識別子	Journal ID	はい
GL 勘定科目	Account	はい
借方金額（なしの場合は 0）	Debit	はい
貸方金額（なしの場合は 0）	Credit	はい
明細レベルのメモ	Memo	いいえ
部門、クラス、ロケーション、エンティティ	Department / Class / Location / Entity	いいえ

転記する粒度（1 日ごと、ドキュメントごと、バッチごとに 1 エントリなど）に合わせて、通常のテーブルステップ（ピボット、グループ化集計、結合）を使用し、金額をこの 2 つのテーブルに集約します。Journal ID は明細の集合をヘッダー行に結び付けるものです。仕訳エントリごとに一意で、そのエントリに属するすべての明細行が共有するキーとして作成してください。

ステップの設定

ワークフローに Post NetSuite Journal Entry ステップを追加します。
接続タブで、NetSuite接続に使用する NetSuite 接続を設定し、環境を選択します。
データタブで次のように設定します。
- 仕訳エントリヘッダーテーブルと仕訳エントリ明細行テーブルに、上記で作成したテーブルを設定します。
- 当面は Test Only Mode をオンのままにします。プレビューと検証を参照してください。
- バッチを最初の不正なエントリで即座に停止させたい場合を除き、Continue posting remaining entries if one entry fails はオンのままにします。
- 大量バッチのために NetSuite の非同期受付パスが特に必要な場合を除き、Submit Asynchronously はオフのままにします。後述の非同期送信を参照してください。
- 転記結果テーブルには、PlaidCloud が作成または上書きできるテーブルを設定します。初回だけでなく毎回の実行でこのテーブルが必要になります。結果テーブルの読み取りを参照してください。
ヘッダーマップタブで、ヘッダーテーブルの列を Journal ID、Subsidiary、転記日、および（ある場合は）Currency、Memo、External ID にマッピングします。ヘッダー行の一部だけを転記したい場合は、ヘッダーフィルターを使用します。
明細マップタブで、明細テーブルの列を Journal ID、Account、Debit、Credit、および（ある場合は）Memo、Department、Class、Location、Entity にマッピングします。明細フィルターも同様に使用します。

プレビューと検証

Test Only Mode をオンにした状態でステップを実行します。PlaidCloud はマッピングされたデータからすべての仕訳エントリを組み立て、転記時と同じチェック（貸借の一致、必須フィールドの存在、有効な転記日）を実行しますが、NetSuite への呼び出しは一切行いません。何も転記されません。

ステップを実行します（ワークフロー内の 1 つのステップを実行するを参照）。
結果テーブルを開き、転記を予定していたすべての行が status = validated になっていることを確認します。error となっている行には、そのエントリの Journal ID と問題点が示されます。よくある原因は、貸借の不一致、Account の欠落、Subsidiary または転記日の空欄です。
error の行については、ソースデータ（またはマッピングとフィルター）を修正し、バッチがエラーなしで検証されるまで再実行します。

バッチの転記

バッチがエラーなしで検証されたら、Test Only Mode をオフにして、もう一度ステップを実行します。今度は PlaidCloud が、検証済みの各エントリを実際に NetSuite へ転記します。

非同期送信

Submit Asynchronously は、同期的な作成と読み戻しを待つ代わりに、NetSuite の非同期受付ヘッダー付きで各エントリを送信します。NetSuite はエントリをキューに入れてすぐに応答し、PlaidCloud はそのエントリを posted や error ではなく、送信参照付きの pending として記録します。

結果テーブルの読み取り

結果テーブルには、ステップがどのモードで実行されたかにかかわらず、処理を試みた仕訳エントリごとに 1 行が格納されます。

列	説明
journal_id	ヘッダーテーブルの Journal ID。
external_id	この転記の試行に使用された外部 ID（下記を参照）。
internal_id	作成されたエントリの NetSuite 内部 ID。`pending` の間は非同期の送信参照。Test Only Mode の場合とエラー時は空欄。
status	`validated`、`posted`、`pending`（Submit Asynchronously によりエントリは受け付けられたが、NetSuite がまだ確認していない状態）、または `error`。
message	`error` の場合のエラー詳細。`posted`/`validated` の場合は空欄。

Continue posting remaining entries がオンの場合、大量のバッチ内の不正なエントリが 1 件あってもステップ全体は失敗しません。そのため、error 行に対する通知や、internal_id を記録するためのヘッダーテーブルへの結合といった後続のステップは、ステップ自体の実行ステータスではなく、このテーブルに基づいて構築してください。

バッチの安全な再実行

各エントリは、プロジェクト、接続、Journal ID、転記日、および明細金額から作成される決定的な外部 ID を付けて転記されます。変更のないエントリに対してステップを再実行すると、同じ外部 ID が再利用され、NetSuite 独自の外部 ID の処理により重複の作成が防がれます。そのため、一時的な障害の後にワークフローを再実行しても、変更のないエントリについては安全です。