6.1 【設問】受発注(1/3)
例題2 受注のステータス管理ができるようにする
まず、業務の現状と要望事項を説明します。
それを把握した上で、続く問題に答えなさい。
営業所の社員にインタビューを行ったところ、受注業務では「仮受注→受注確定(納期、数量確定)→納品確認」というステータスの管理が必要であることがわかりました。 それぞれの意味を以下に説明します。
ステータス | 説明 |
---|---|
仮受注 | 注文伝票に記載されている商品のうち、いくつかは希望数量の在庫引当ができておらず、仮引当のみ行った状態 顧客への確認、仕入処理が必要 |
受注確定 | 次のうちのいずれか
|
納品確認 | 受注確定状態3.の処理後、仕入先から注文請書が返送され、納期が確定した状態 |
表6-2 ステータス
【CASE1】
在庫を確認したところ、出荷可能在庫数が十分あったため引当を行い、その倉庫にある在庫を押さえた
この状態は受注確定
【CASE2】
在庫不足のため、現在の在庫をすべて仮引当し、顧客に納期確認をする
この状態は仮受注
【CASE3】
顧客に確認した結果、現在倉庫にある在庫数だけでよいことになったので、数を変更して受注確定
【CASE4】
在庫不足のため、在庫品をすべて仮引当し、顧客に納期確認をする
顧客に確認した結果、不足分は納期を延期しても取り寄せてほしいといわれ、仕入処理をした
仕入処理を行った結果、納期が決まり、受注するために十分な数量を確保できることが確認できた
この状態が受注確定
その後、仕入先から注文請書が送付されてきて、仕入納期が確定した
この状態が納品確認
また、営業担当からは、次のようなリクエストが発生しています。
「在庫が不足していたために、顧客が当初希望した数量より少ない数で受注した場合の機会損失をなるべく避けたい。そのため、機会損失の情報を後で確認できるようにしてほしい」。
問題
他の必要な条件が決まらないために属性が決まらない部分については、保留にしておいてください。
ヒント
「ステータス」はどのエンティティで管理すればよいでしょうか。
次のことを念頭に置いて考えてみてください。
ステータス管理は、多くの場合、正規化した結果の属性を組み合わせて利用すれば、管理できる内容です。
このため、「ステータス」という属性を追加した場合、それが導出属性であれば、ある処理を行った結果として連携して更新する必要がある場合が多いといえます。
ステータスを管理するための追加のアプリケーションと、ステータスを確認する要件のコストとパフォーマンスを考慮に入れ、どうやってステータスを管理する方法が最適かを決めます。
たとえば、ステータス管理の例としては以下が挙げられます。
- 「ステータス」などの追加の属性はもたせず、既存の属性のみで管理する
- 「ステータス」という導出属性を追加する
- 「受注ステータス」というエンティティを作成する
解答
受注 | |||
* | 受注注文番号 | ||
客先注文番号 | |||
受注日付 | |||
受注顧客コード | (FK1) | ||
受注社員コード | (FK2) | ||
値引き承認社員コード | (FK3) | ||
受注部門コード | (FK4) | ||
全体値引き額 | |||
消費税額 | (導出) | 1. | |
税抜受注金額合計 | (導出) | 1. | |
納入希望日 | |||
摘要 | |||
スーパータイプ:受注明細 | 3. | ||
* | 受注注文番号 | (FK1) | 5. |
* | 商品コード | (FK2) | 5. |
値引き額 | |||
消費税額 | (導出) | 1. | |
金額 | (導出) | 1. | |
予定納付日付 | |||
受注数量 | 4. | ||
変更後最終受注数量 | 4. | ||
ステータス | 4. | ||
サブタイプ:在庫引当 | 3. | ||
* | 受注注文番号 | (FK1) | |
* | 商品コード | (FK2) | |
* | 倉庫コード | (FK3) | |
引当数量 | |||
サブタイプ:発注分 | 3. | ||
* | 受注注文番号 | (FK1) | |
* | 商品コード | (FK2) | |
* | 発注注文番号 | (FK3) | |
不足分数量 | |||
確定納期日付 |
解説
(注:番号は解答中の番号と対応します。番号が記載されていない解説は全体に当てはまります)
1. 「受注」エンティティの「合計金額」、「消費税額」と「受注明細」エンティティの「金額」、「消費税額」は導出属性として概念設計では残しておきます
2. 「受注明細」エンティティのオカレンスは、以下の2つに分類できます
- 在庫が引当できた在庫引当受注
- 在庫の引当数が不足したため、仕入れ処理を行い受注を受けた「発注分」
また、この2つに共通の属性およびリレーションと、個別に管理される属性およびリレーションに分けることができます
そこで、「受注明細」エンティティを、共通に管理すべきスーパータイプと2つの受注種別のサブタイプに分けます
3. 共通属性がスーパータイプの属性になります。各サブタイプ固有の属性としては、「倉庫コード」が「在庫引当」サブタイプの、「不足分数量」と「確定納期日付」が「発注分」サブタイプに固有の属性となります。概念設計では、サブタイプの一意識別子はスーパータイプと同一のものにしておきます。それぞれどのようなテーブル構成にするかは論理設計時に検討します
4. ステータスは、商品単位に在庫状況を確認して管理することから、「受注明細」スーパータイプで管理します
- 仮受注:「受注明細」スーパータイプの「変更後最終受注数量」の値と、「在庫引当」サブタイプの同じ受注注文番号をもつ各「引当数量」の値の和を比較して、引当数量の和の方が小さい場合です(複数の倉庫から引当をしている場合があるため、和をとる必要があります)
「受注数量」は、顧客が最初に発注した数量です
在庫不足のため、「受注数量」を「変更後最終受注数量」に変更した場合、営業としては機会損失しているわけですから、その値を後で調べるために「最初の受注数量」を属性として管理すべきと判断しています - 受注確定:「受注明細」スーパータイプの「変更後最終受注数量」の値と、「在庫引当」サブタイプの「引当数量」属性と、「発注分」サブタイプの「不足分数量」属性の値の和を比較して、等しい状態です ただし、まだ「発注分」サブタイプの「確定納期日付」に値が入っていない状態を指します
- 納期確定:受注確定の条件の中で、「発注分」サブタイプとリレーションをもつ「発注明細」エンティティの「確定納期日付」に値が入った状態です
5. 概念設計では、一意識別子は、あえて人工的なキーは用いません
人工的なキーを早めに用いてしまうと、本来のオカレンスのもつ意味(どのような属性の組み合わせで一意なオカレンスが決まるか)がわかりにくくなってしまうためです
一意識別子の検討は、表への変換を行う論理設計の段階で決めます
- 受注ヘッダエンティティや出荷/売上ヘッダエンティティ等の一意識別子は、すでに管理する属性として受注注文番号などが使用されているため、これらはそのまま一意識別子として使用します
- 属性名には、エンティティ名を接頭辞として付けることにより、明確に意味がわかるようにします
解説トレーナー