Q&A
顧客品番と製品番号は兼用されることは無いですか？
それとも、製品番号に枝番が付与されるだけですか？
見積は自社発注もあるのでしょうか？
前提・実現したいこと
ODMでのアパレル製造業の生産管理を行いたいです。
具体的には受注ごとに見積もりに対しての達成率を算出したいと考えております、
使えるツールはエクセルのみでpowerpivotかSQLで計算したいです。
現状は一応自社の製品番号をもとにした見積書と受注一覧があります（省略しています）
社内では受注IDと製品番号をよく利用しています。
発生している問題・エラーメッセージ
１つの自社製品番号に素材替え等で2つの客先品番が発生することがあります
製品番号１ A社品番111-1
製品番号１ A社品番111-2
（製品番号は現状2000弱でそのうち10個程度に複数客先品番があります。）
また、材料値上げ等で見積りが変更になるときがあります
製品番号１ 2019/12/31まで 価格20000円
製品番号１ 2020/1/1から 価格23000円
（見積変更は０～２０個位で年によって違います）
このような場合、どのようにテーブルを作ったほうがよいでしょうか？
試したこと
質問１．客先品番に対して自社製品番号を振るように考えました
製品テーブルと製品見積テーブルをわけて、
見積をバージョン管理するのはどうでしょうか？
そうすると、顧客品番テーブルには製品見積は紐づかず、
受注一覧の受注日を製品見積の期間で確定して、値段が決まると思いますが
たいへんそうだなと思います。
質問２．受注テーブルに単価や売上、製品番号があるのは冗長性が増しますが、
あってもいいとお考えになりますか？
初心者でハードルが高いと自分でも思いますが、
よい方法がありましたら、ご教授いただけますよう
よろしくお願いいたします。
顧客品番と製品番号は兼用したくないと思っています。
現状は受注一覧を入力する際、製品番号を入力すると値段と顧客品番が連動するようにになっており、
顧客品番が複数になって初期設定と違う場合は手入力で直しています。
見積書は製品番号ごとにブックになっており、品番が増えた場合は別シートで客先品番ごとに保存されています。
社員は製品番号で製品を識別しているので、製品番号に枝番を付与して顧客品番と製品番号を1対1に
したほうがいいと考えています。(それが見積verのつもりです)
すいませんこれで回答になっているでしょうか？
自社発注について
自社のオリジナルの製品はなく、依頼したお客様専用の製品となります。
基本的にデザイン画で依頼が来たものを形にして、それが社内の製品番号になります。
ですので自社発注はないです。
どうぞよろしくお願いいたします。
回答2件
0
ベストアンサー
質問１．
見積と受注は顧客とリレーションすべき。
通常、見積→受注となりますが、現場では見積無しの受注もよくある事です。
特に見積は製品からのリレーションであるべきではない。
製品番号に素材替え等で2つの客先品番が発生する
というのは、「製品番号に素材替え等」という行為自体が見積で、それで品番が生まれるという事だから。
エンティティを発生の時系列で考えると、リレーションを設計しやすいと思います。
質問２．
見積価格と受注価格は別物としておいた方が良いので、冗長とは思いません。
投稿2020/11/25 01:42
編集2020/11/25 01:48総合スコア25327
> 現場では見積無しの受注もよくある事です。
見積もりなしの受注は本質的に問題を抱えるので、ルールを強制するのもありだと思いますけどねぇ。。。まぁ、今回そこまで踏み込むかどうかは別として。
質問２ に関しては、いわゆる「要素の洗い出し」に失敗しているように思います。
ほとんど個人的な横からの質問ですが、sazi さんに「どう考えればよかったのか」聞いてみたいです。
sazi さんの「エンティティを発生の時系列で考えると、リレーションを設計しやすいと思います。」というコメントと、
sousuke さんの「個人的にはマスターテーブルというのは入力の補助に使うものであって、値の保持が必要なら受注テーブル側に持つべきかなと。」というコメントは、なかなか納得いくものですが、ちょっと物足りない気がします。
見積を強制するというのは、システムの立ち上げ時によく言われる事でありますが、実際には。。。
なので、両方可能な構成にしておくというのが理想です。
「個人的にはマスターテーブルというのは入力の補助に使うもの」というのは、入力の際に既にあって欲しいという時系列で考えれば良いだけだと考えます。
> 「個人的にはマスターテーブルというのは入力の補助に使うもの」というのは、入力の際に既にあって欲しいという時系列で考えれば良いだけだと考えます。
洗い出しの際に、実際の実務フローを追ってみて、各要素に矛盾がないか、過不足ないか確かめるって感じですかね？
これ、相当現場に近くないと難しい気がしますが、まぁ近道はないのかなぁ。。。少しすっきりしました。
ありがとうございます。
設計の精度を高める手順は色々ありますが、先ずは自身を現場で作業する一員としての視点で考えるようにしていますね。
その為に、どんな些細な資料にも必ず目を通して、情報収集に努めます。
> その為に、どんな些細な資料にも必ず目を通して、情報収集に努めます。
苦手なヤツだわｗ
ちょっと好きになる方法を質問してきます！
ご返答ありがとうございます。
弊社でも大まかな受注があって最終的に見積りが決まるという形がだいぶあるので、おっしゃっていただいたように時系列で再考してみます。
もう１つ質問をさせていただきたいのですが、見積は製品からのリレーションであるべきではない。とすると見積が仕様書(材料リスト)を含む場合、仕様書を分けたほうがいいのでしょうか？
これがおっしゃっていた兼用のことでしょうか？
質問の見積には材料を含むように見えていますが、それを分けるという事ですか？
受注が確定した時点で、製作に入る為の仕様書という意味なら、指示書とか指図書という類でしょうか。
それらのアクションが、見積に含まれていないなら、エンティティは分けていた方が効率的です。
兼用と言っていたのは、製品番号と品番が体系的に同じものかどうかという事です。
体系的に同じなら、顧客ごとに品番があるものを製品番号と差替えるという考えでの設計も考えられますので。
ご返答ありがとうございます。指示書のことを仕様書と言っていました。見積に含まれています。
弊社リピート生産が多く、製品番号何番をもう一度素材を変えて生産することがあります。
その場合、客先品番が変更して受注するけれど、製品番号が変わらないということが起きます。
見積は製品からのリレーションであるべきではない。とするとこの場合、製品番号を新たに作ったほうがいいということでしょうか？おっしゃっていることが理解できずすいません。
見積が、製品を外部参照する形であるべきで、時系列的には、見積時には製品が既に存在しているという事ですが、それは顧客に対しても同様で、見積が顧客を外部参照していないというのが指摘事項です。
質問の内容だと、どこの顧客に対する見積か不明ですよね。
> 弊社リピート生産が多く、製品番号何番をもう一度素材を変えて生産することがあります。
それが顧客とリンクしない理由になるようには思えません
時系列的には、基本、見積→受注→顧客品番という関係性で、この過程で、見積時に顧客品番と製品の関連付けが出来ていて、受注によって顧客品番が確定するというイメージです。
すいません昨日から考えているのですが、
顧客と見積がリレーションすべきなのはわかりました。
顧客品番が最後に確定するのも理解できました。
見積と製品の関係を考えてみます。ありがとうございました。
0
結構内容が複雑なんで分けて聞いたほうがいいと思いますがとりあえず回答。
あくまで私だったらどうするかという話です。いろんな意見があると思います。
質問１
M顧客品番テーブルは見えているフィールドだけなら私は作りません。
T受注テーブルに[品番]や[品名]といったフィールドを設けて受注ごとに
製品番号を入れるついでに[品番]や[品名]も埋めればいいと思います。
M製品見積テーブルはPKを見積IDなど１列の主キーにしたうえで
T受注テーブルに見積IDなどで入力可とし見積から単価などを引っ張って
製品関連の情報を埋められるようにします。
見積IDの入力の際に日付などの期間をみてリスト化するなりして補助すればいいです。
（個人的には見積はマスターテーブルになるとは思わないです）
質問２
受注テーブルの単価や製品番号を抜く選択肢はないです。
（売上はなにかわからない。例えばT売上テーブルがあるなら不要）
個人的にはマスターテーブルというのは入力の補助に使うものであって
値の保持が必要なら受注テーブル側に持つべきかなと。
連結のみですべてを解決しようとするとどんなUIかわかりませんが
あちこちのテーブルを覗く必要が入力する担当者にも必要になりますし
それがマスターテーブルとなると変えてはいけない項目もミスタッチする可能性もあります。
質問者さんが「受注」というものをどういう風に考えているのかにもよりますが
私は「受注」というのは『発注書に書いてある内容が登録できるもの』ととらえていますので
T受注テーブルにおいてお客さんの発注書を再現するだけのデータの入れ物が必要と思います。
投稿2020/11/24 09:11
総合スコア3830
長文でのご返答ありがとうございます。
質問１について、品番テーブルはブランドやシリーズが客先によってあったりなかったりするので、別途分けています。
製品見積テーブルは１列の主キーにして引っ張ってきたほうがいいのは理解できました。
ただ、見積がマスターにならないというのがちょっとよくわかりません。
質問２については値の保持が必要でしっくりきました。ありがとうございます。
もう少し考えてみます。
あなたの回答
tips
プレビュー
