こんにちは。
大変である。
只野です。
初めに
当記事は日々の仕事の振り返りです。参考になるかはわかりません。
取引先情報を販売管理システムで管理する場合、受注、仕入などあらゆる箇所に利用されることをまずは想定しなくてはなりません。そんなこんなで顧客から要件をお聞きすると
「請求するときは関連会社もまとめてすべて本社に請求しています。」
「与信も考慮できるようにしたいです。」
「得意先であり仕入先でもある取引先は請求や支払い時に相殺したいです。」
「出荷先は一つの取引先で複数管理できるようにしたいです。」
と要件定義をすれば沢山の要望が出てくるものです。取引先を管理する方法のある程度のパターンは決まっているので、基幹システムに取引先を管理する機能を構築する場合、大枠を設計し、あとから要件を聞き入れるほうが早いと感じる私です。
取引先はまず、グループ化できる方式を採用します。
取引先をグループ化できる仕組みを取るのは下記の意味があります。
- 請求時、関連取引先も代表取引先へ請求
- 支払い時、関連取引先も代表取引先へ支払い
- 与信管理時、関連取引先全体で管理
など実施している運用により上記のような内容が出てきます。取引先毎に請求先を設定できるようにしますが、請求先が同一でもシステム内で構築する請求情報をそれだけでまとめるわけにはいきません。
まとめるかまとめないかは任意で指定していただくほうがシステム的にも安全です。運用体系は年々複雑になっている気がするので、システムも柔軟に対応できる仕組みを事前に考えていく必要があります。分社化対応というプロジェクトとかで上記内容を考慮できるようにする事は多いです。
次に取引先は大きく分けると「得意先」、「支払先」を管理できる仕組みが必要になります。2点の情報はほぼほぼ一緒の情報を持つようになるので、設計時にDBテーブルを分けるかなど検討が必要になります。
上記2点で違いが出てくる情報は得意先ならば「請求情報、与信情報」が必要。仕入先ならば「支払情報」が必要となります。DBテーブルで「取引先」を用意し、全部持たせてもよい気もしますが、情報の管理としては分けた方が良いかなと考える私です。
DBテーブルの項目数が増えれば増えるほどDBテーブルが使いにくい状態となりますからね。テーブルが増えすぎても問題があるのでバランスは難しいところです。DBテーブルの設計は1テーブル50項目以下などルールを設け設計すれば分けるかの判断がしやすかもしれません。
なのでこんなDB設計をまずはやっていきます。あとは要望により必要な情報を作成していく流れですかね。
要件定義は顧客がイメージを完全に持っていれば良いのですが、大体は顧客がこちらに伝えてくる断片的な情報をこちらで組み合わせ求める動きをするシステムを構築する事になります。
顧客が知らない情報をこちらから先回りで提案する作業が日常となります。システム屋さんはプログラムだけではなく、システム構築が依頼された顧客の業務知識も同時に必要となるのが大変だなと感じますね。
本日はこの辺で