受発注をつなぐ前に、正本と例外処理の境界を決める。

受発注のデジタル化で、最初に決めるのは『どこを正本にするか』

対象となった流通事業者では、取引先・品目・単価の情報と、発注から請求までの進捗が複数の手段に分かれていました。入力画面を用意するだけでは、FAXで届く例外注文、取引先別の単価、基幹システムへの反映方法が未整理のまま残ります。

そこで、業務フローの各段階について、誰が入力するか、どのデータを正本とするか、例外をどこで処理するかを先に整理しました。オンライン化の対象と既存運用に残す範囲を分けることが、二重管理を避ける前提になりました。

AMELAが担当した範囲と設計判断

AMELAは、B2B受発注プラットフォームの新規構築に参画しました。公開用ケース資料で確認できる構成は、フロントエンドがVue.js、バックエンドがLaravelとPHP、データベースがMySQL、外部連携がkintone APIとCSV入出力です。

設計では、発注から受注回答、納品、検収、請求までのステータス管理、取引先・品目・取引先別単価のマスタ管理、CSVの取込・出力と入力検証、kintoneとのデータ連携と連携状況の確認を一つの業務フローとして接続しました。

読者が使える実践ツール

開発会社に画面案を依頼する前に、業務段階ごとの移行境界を一枚にまとめます。次は記入例であり、OrderBridgeの実際の運用設定ではありません。

• 発注入力：現状＝FAX・電話／移行後＝取引先がWeb入力／正本＝OrderBridge／例外＝緊急注文は代理入力／受入条件＝必須項目と重複注文を確認できる
• 受注回答：現状＝電話・メール／移行後＝サプライヤーが数量・納期を回答／正本＝OrderBridge／例外＝回答期限超過は担当者へ通知／受入条件＝回答履歴が残る
• 納品・検収：現状＝納品書とExcel／移行後＝納品実績と検収結果を登録／正本＝OrderBridge／例外＝一部納品・返品を別状態で管理／受入条件＝請求対象を追跡できる
• 取引先別単価：現状＝複数のExcel／移行後＝単価マスタに集約／正本＝合意した一方のシステム／例外＝適用開始日と個別契約を記録／受入条件＝変更履歴を確認できる
• 基幹連携：現状＝手入力／移行後＝kintone APIまたはCSV連携／正本＝項目ごとに定義／例外＝連携失敗は再送キューへ／受入条件＝失敗件数と再処理結果を確認できる

自社向けに書き換えるときは、各行に『入力責任者』『正本』『連携方向』『例外』『再処理』『受入条件』を必ず入れてください。特に単価、請求、取消は、通常フローと承認が必要な例外を分けます。