受注番号生成システムの仕様・実装¶

概要¶

リツビ BtoB ECサイトでは、注文の配送モード（通常配送または直送）に応じて、異なるプレフィックスを持つ受注番号を生成します。

番号体系¶

配送モード	プレフィックス	フォーマット	例
通常配送	`NetB2B_`	`NetB2B_` + 8桁連番	`NetB2B_10000001`
直送モード	`Direct_`	`Direct_` + 8桁連番	`Direct_10000001`

※ 旧システムとのID衝突を避けるため、連番は 10000001 から開始します。

生成フロー¶

受注番号の生成は、Vendureのライフサイクルに合わせて2段階で行われます。

初期生成（一時番号）:
注文が作成された直後（AddingItems 状態）では、TEMP_ プレフィックスとランダムな文字列（例: TEMP_A1B2C3D4）が付与されます。
これは RitsubiOrderCodeStrategy.generate() によって行われます。
確定（最終番号）:
注文が以下のいずれかの状態に遷移した際に、最終的な番号に書き換えられます。
- ArrangingPayment (支払い待ち)
- Arranging (手配中)
- PaymentSettled (決済完了)
この確定処理は orderCodeFinalizerProcess (OrderProcessフック) によって行われます。
連番は PostgreSQL のシーケンス order_code_seq から取得されます。

実装詳細¶

構成要素¶

RitsubiOrderCodeStrategy:
apps/vendure-server/src/id-strategy/ritsubi-order-code-strategy.ts
一時番号の生成（generate）と、最終番号の生成（finalizeCode）を担います。
DBシーケンス order_code_seq から値を増分取得します。
orderCodeFinalizerProcess:
apps/vendure-server/src/plugins/ritsubi-admin-extensions/order-code-finalizer.process.ts
注文状態の遷移を監視し、TEMP_ で始まる受注番号を finalizeCode で生成された正規の番号に更新します。
データベースシーケンス:
order_code_seq
マイグレーションによって作成されます。 START WITH 10000001 で定義されており、旧システムとのID衝突を避けるため、10,000,001から開始します。

プラグイン連携¶

RitsubiAdminExtensionsPlugin (apps/vendure-server/src/plugins/ritsubi-admin-extensions/ritsubi-admin-extensions.plugin.ts) の configuration フックにて、上記のプロセスが登録されています。

// ritsubi-admin-extensions.plugin.ts
configuration: (config) => {
    config.orderOptions.process.push(orderCodeFinalizerProcess);
    return config;
},

テスト¶

統合テストにより、以下の動作が保証されています。

初期状態での TEMP_ 番号の付与。
状態遷移時の NetB2B_ への確定。
directShipping: true の場合の Direct_ への確定。
連番が正しく増分されること（開始番号は10,000,001）。

テストファイル: apps/vendure-server/tests/integration/order-code-strategy.integration-spec.ts