受発注マスタ整備

公開日 2026.07.13 著者:株式会社ミチタス

受発注システム導入前に整理する
マスタ項目と責任分担

同じ取引先や商品が複数の名前・コードで登録されていると、システムを替えても検索、変換、確認が残ります。本記事では、顧客・商品・価格・単位・届け先などについて、項目だけでなく「どれが正本か」「誰がいつ更新するか」まで整理します。

この記事で整理できること
  • 受発注に関係する主なマスタ
  • 正本・コード・表記揺れの確認方法
  • 登録、変更、廃止の責任分担
  • 移行前に試す小さな照合方法

マスタは繰り返し参照する基準情報

受発注では、顧客、商品、価格、単位、届け先などを注文のたびにゼロから入力せず、登録済みの基準情報を参照します。問題になりやすいのは項目の不足だけではありません。同じ情報がExcel、販売管理、倉庫管理などに分散し、どれを正しい情報として更新するか決まっていない状態です。

データを一度きれいにするだけでは足りません。
新規登録、変更、廃止の入口と承認者を決めないと、導入後に再び重複や表記揺れが増えます。

最初に確認するマスタ項目

マスタ項目例起きやすい不一致
顧客顧客コード、法人名、部門、請求先、締日社名変更、支店重複、略称
商品商品コード、名称、仕様、状態旧品番、廃番、類似名称
単位個、箱、ケース、換算数発注単位と在庫単位の違い
価格標準価格、契約価格、適用期間顧客別価格、開始・終了日の欠落
届け先届け先コード、住所、受入条件同名拠点、移転前住所
取引条件締切、納入リードタイム、最低ロット口頭ルール、担当者依存

実際に必要な項目は業種、取引条件、対象システムで異なります。上表をそのまま要件にせず、日常の注文・出荷・請求で参照している情報から確認します。

マスタを整理する5ステップ

利用場所を並べる

販売管理、会計、倉庫、Excel、紙台帳など、同じマスタを参照・更新する場所を列挙します。

正本を仮決めする

項目ごとに、最初に登録され、正しい値として扱う場所を1つ仮置きします。すべてを同じシステムにする必要はありません。

重複と表記揺れを数える

コードが同じで名称が違う、名称が同じでコードが複数ある、全角・半角や旧字体が混在する、といった状態を分類します。

変換ルールを決める

取引先コードと自社コードが異なる場合は対応表、単位が異なる場合は換算ルールを作り、判断が必要な条件を分けます。

登録・変更・廃止の担当を決める

申請者、承認者、実際の更新者、利用部門への通知、定期確認の周期を明記します。

責任分担まで含めた記入例

対象正本申請承認更新確認周期
顧客基本情報販売管理営業営業責任者受注担当変更時
商品・旧品番商品台帳商品担当商品責任者商品担当月1回
届け先販売管理営業顧客確認受注担当出荷前

これは仮想例です。小規模組織では一人が複数役割を兼ねても構いませんが、少なくとも「誰の確認で正しい値になるか」を区別します。

移行前の小さな照合

導入候補へ確認する質問

よくある質問

すべてのマスタを先に統合すべきですか

対象業務で使う範囲から始めます。全社マスタ統合を前提にすると検証が大きくなるため、最初の対象プロセス、顧客、商品を限定して不一致の型を確認します。

表記揺れはすべて直すべきですか

検索や連携に影響しない表示名まで一律に直す必要はありません。コード照合、帳票表示、顧客との合意に影響するものを優先します。

Next step

マスタが使われる工程を確認する

受注から請求までの担当、入力情報、転記、例外を整理する印刷用テンプレートです。

テンプレートを開く

関連する実務記事

参考情報

編集方針:受発注データを移行・連携する前の一般的な確認手順として作成しています。必要項目、保存要件、権限、セキュリティは対象システム、契約、法令に応じて専門家・提供事業者へ確認してください。最終更新日:2026.07.13

M

著者:ミチタス編集部

物流IT、BtoB営業、業務整理、提案設計の経験をもとに、特定製品に依存しない導入前の確認手順を作成しています。

著者プロフィール・経験・考え方を見る →

Fit check

製品比較を始める前に、支援対象か確認できます。

現行業務、例外、候補製品、社内で確認できる担当者の有無を照合します。

受発注・物流業務整理の対象確認

更新日:2026.07.22
編集方針:公開情報とミチタスの実務知見をもとに、事実・仮定・説明例を区別して作成しています。特定製品の推奨、導入効果、投資回収、法令適合を保証しません。固有の顧客情報・社内情報・機密情報は使用していません。