ECと基幹システム（ERP）や物流WMSをつなぐ案件で、意外と見落とされるのが「営業日カレンダー」だ。連携仕様書には各バッチの時刻は書かれていても、それが「どの日に動くのか」が書かれていないことが多い。この記事は、EC事業者と、基幹連携を設計する技術者に向けて、なぜ営業日カレンダーを最初に確定させる必要があるのかを整理したものだ。結論を先に言えば、ECは24時間365日注文が入るが、基幹やWMSは営業日しか動かない。このズレをどう扱うかを決めないまま作ると、本番後に「正常な滞留」と「本当の障害」を区別できず、連休明けに事故になる。
時刻は書いてあるが「動く日」が書いていない
基幹連携の設計は、たいてい時刻ベースで組まれている。受注登録は9:30・14:00・19:00、出荷指示は9:00・12:00・15:00、出荷結果は夜間の日次バッチ、といった具合だ。この「時刻」の裏には必ず「どの曜日・どの日に動くのか」があるはずだが、そこが仕様書に明示されていないことが多い。
ECはこの前提を共有していない。注文は土日祝も深夜も入る。一方で基幹やWMSは、土日祝や年末年始、定期メンテナンス日、棚卸日には動かない。この非対称を設計に織り込まないと、後述するいくつもの判断がすべて宙に浮く。
カレンダー次第で変わる設計判断
営業日カレンダーが決まらないと確定できない設計判断は、少なくとも次の五つある。いずれも「連携仕様の細部」ではなく、システムの根幹に関わる。
連携漏れ検知の閾値。 連携の肝は「送ったのに結果が返ってこない注文を検知する」ことだ。ここは「N時間以内に結果が返らなければ異常」というロジックになるが、土日祝をまたげば当然返ってこない。カレンダーがないと、正常な滞留と本当の障害を区別できず、月曜の朝にアラートが大量に鳴る。
キャンセル可能期限。 「出荷指示が飛ぶ前ならキャンセル可」という設計にする場合、金曜夜以降の注文がいつ出荷指示に乗るのかが分からないと、ユーザーに提示するキャンセル期限が決められない。
お届け目安・出荷予定日の表示。 注文確認メールやマイページに出荷目安を出すなら、同じ理由でカレンダーが要る。
在庫の乖離。 在庫情報が日中1時間ごとに来る設計でも、非営業日は更新が止まる。連休中にEC側の在庫が何日ズレたままになるのか、売り越しリスクをどこまで許容するかの判断材料になる。
売上計上・月末締め。 売上計上や売掛金残高は基幹側の会計締めに直結する。月末が休日にあたる場合の扱いや、期末棚卸で連携を止める期間があるかどうかは、事前に把握しておかないと本番後の事故になる。
先方に確認すべきは四点
営業日カレンダーについて相手に確認する内容は、次の四点に絞れる。
基幹側・WMS側のバッチが稼働しない日はいつか（土日祝、年末年始、定期メンテナンス、棚卸日）。非営業日にECから送信したファイルはどう扱われるか（翌営業日にまとめて処理されるのか、送信自体を止める必要があるのか）。各バッチの締め時間は何時か（何時までに送れば当日扱いになるか）。そして、営業日カレンダーをシステム的に参照できるのか、それとも年1回ファイルでもらう運用なのか。
「参照できるか」は見積もりに直接効く
最後の項目――カレンダーをシステム参照できるか――は、見積もりに直接効いてくる。システムから参照できないなら、中間連携基盤の側に営業日マスタを持ち、それを管理する機能を作る必要があり、その分の工数が乗る。逆に「非営業日も常時受け付けて翌営業日に処理される」で運用を統一できるなら、こちら側は営業日マスタを持たずに済む。
つまり営業日カレンダーは、単なる運用上の確認事項ではなく、中間連携基盤に機能を1つ増やすかどうかを左右する設計判断だ。だからこそ、要件定義の早い段階で押さえておきたい。
まとめ
ECは24時間365日動き、基幹やWMSは営業日しか動かない。この非対称を無視すると、連携漏れ検知、キャンセル期限、出荷目安、在庫乖離、売上締めのすべてが宙に浮く。当社では、基幹連携の要件定義で真っ先に営業日カレンダーを確認し、「非稼働日はいつか」「非営業日の送信はどう扱うか」「締め時間は何時か」「システム参照できるか」の四点を必ず潰している。とりわけ最後の「参照できるか」は、中間基盤に営業日マスタを持つかどうかという工数の分岐点になる。時刻だけでなく「動く日」まで詰めておくことが、本番後の事故を防ぐ最初の一歩だ。