タイトル内のページ
多くの企業の情報システムで 売掛先だけに関する各データを得意先テーブル（マスター）という形で管理しています。
このテーブルも少し工夫を凝らし、取引に関連する全ての相手を 取引先テーブルとして一元管理すれば ずっと
拡張性に富んだ物となります。
「得意先」の範囲
直接売掛の発生する相手先だけでなく、二次店（三次店）も、納入先も同じテーブルに並存させます。
さらに 仕入れ先、メーカー等の情報も 同じテーブルに置きます。
取引先間のつながり定義
テーブル内に 関連する取引ルートを定義します。
例えば そのコードが ある末端納品先（A）を定義している場合、
その納品先に対して 上位関係にある 納品先の本社(本部）（B)が テーブル上に書き込まれます。
さらに (B)に対し 販売している 二次卸（C)が有れば それも定義します。
さらに （C)に対し販売している代理店（D)があれば それも定義します。
つまり コード（A)のテーブルには B → C → Dが定義されるようなフィールドを 用意します。
仕入れ先も同様です。
ある原料メーカーのコードには 自社に納入されるまでの 経路を 順番にそれぞれ定義します。
効果
① ある納品先を入力するだけで、その上位にいるセンター、二次店、代理店 等が自動的に 入力データとして
利用でき、入力作業が軽減します。当然 入力ミスも 発生しません。
② 取引先の変更 例えば ルート変更、倒産廃業等は、マスターの変更のみで 元始データには 影響しません。
③ 支店、営業所、配送先等が 多数ある場合でも その取引先の代表コード１個に対してだけ ルートを定義すれば
他の 子コードには ルート登録の必要がありません。
④ ある得意先に対して 二つ以上のルートが存在する場合も コード化できます。
ヒント
通常 コードを考える時 自社からみて関係の深い取引先から 構造を組み立てます。
発想を逆転して 取引関係の遠いところから 考えて見てください。
文責 齋藤陽一郎
