iDmpiere 想定組織、製品カテゴリー、パートナーグループ、パートナー

パートナーとかや製品などの登録の仕方だけを書こうとしていたが、やはりちと無理がありました。

多くのパラメータのどれを使用するのか、無視するのか？

また、パラメーターはどのように利用すればビジネスとして使いやすいのかなどは、まず想定するビジネスを実現するための「工夫」として「あみ出す」ものであったりするので、ここではビジネスの想定と設定を行ったり来たりしながら進みたいと思います。

というわけで、マスターとしてどんなビジネスを想定するのか（DRAFT）を考えてみます。

今回想定する商品構成から、以前このブログで作成したクライアントは破棄して新たに Minotta Film を作成することにしました。（すいません）

会社の想定としては、カメラ、メモリ、PCの製造・販売を行う会社です。

製造はDeskTop PCのパーツを仕入れて組み上げを行っています。

その他の製品について、設計は行いますが製造はOEMに依頼しています。（完成品を仕入れ）

製品カテゴリで Camera/Memory/PC 事業部をあえて製品カテゴリとして識別する形にしていますが、本来は組織で分けるべきかもしれません。

Organization として、事業の軸（縦軸）と機能の軸（横軸）を混ぜるのが良いソリューションかわからず、とりあえず製品カテゴリーで事業部を表現しておきます。（進めていくうちにメリット・デメリットが見えて来たらまた再構成します）

製品カテゴリは製品によって階層数が異なることがあると考えています。

ここでの例はMemory/SSD の階層は 他と異なり１階層深く分解されています。このように階層数がまちまちだった場合にどのような制約があるのか見ていきたいと思います。

また、上のグループで受発注特徴は後に出てくる概要ワークフローが異なって来ます。

１：事前発注・在庫販売

２：パーツ事前発注・受注後組み立て

３：受注後発注

このあたりは概要ワークフローでもう一度定義します。

次にビジネスパートナー

ここでも少し試してみようと思っていることが、、

ビジネスパートナーグループの使い方ですが、 iDempiere のサンプル（初期登録済クライアント）Gardenwordでは ビジネスパートナーグループはCustomer/Vendor/Staffとなっていました。Customer/Vendor/Staff は（基本的には）パラメタで設定・識別できると思いますので今ひとつピンときていません。

なにかしらの集計・評価単位とするためにはあらかじめ評価する単位（グループ）などの構成を決める必要があるわけですが、現時点もやもやしているのでとりあえず顧客を優先度（重要度）で分ける事と、もう一つ量販店など複数店舗のまとめる単位として使ってみようと思います。

例えば量販店でも、店舗ごとに独立性が高く、個別の店舗から発注を受けるが、支払いは本部一括であったり、あらかじめ本部が店舗への必要量は一括した発注を受けるが、配送先は各店舗であったりするケースがあると思います。

もちろんMinotta Film側として統一した構造として管理したいところですが、まず動きの特徴を把握するために混在した構造を試してみたいと思います。