7.2 受注処理
解答1
解説
受注明細表は、スーパータイプ/サブタイプの構造になっていましたが、今回はすべての行を同時に参照することが多いため、1つの表にまとめた方が検索処理が速いこと、サブタイプの種類がこれ以上増えることは考えにくいという業務側の判断から、1表にまとめることにしました。
- 受注明細行を、種禁則こよって次のように分け、それを「受注明細種類コード」で識別します
- 受注時の受注個数、全額情報などを格納する元の行
- 倉庫での引当処理によって受注できた行
- 仕入れを必要とした行
- 上記明細のうち、引当と仕入れを表す行は、「上位受注明細番号」という列で、元になっている行を参照します
- 引当ができた明細には「倉庫コード」が、仕入れが必要になった明細行には、仕入れのための発注の後に決まった「確定納期」が指定される属性になります
- 倉庫からの引当は、当初複数倉庫からの引当もできるように考えていましたが、業務的な観点から、倉庫は1箇所からの引当のみになりました。エンティティ上の変更は特にありません
また、受注明細エンティティには、出荷後に返品が起きた場合に対応する属性も追加しました。
出荷/売上に返品処理が起きた場合、出荷返品分に関しては、新たに受注オカレンスが作成される場合があります。
そのとき、新たな受注ではないことがわかるように、受注エンティティの「返品元受注番号」属性に、今回の返品のための受注の原因となった受注番号を入力します。
(受注エンティティには、返品が生じた場合、返品用に顧客に新たに出荷するための新規受注オカレンスが追加され、返品の原因となった受注を再帰的に参照する再帰リレーションシップが加わることになります)
出荷返品分の出荷が完了すれば、返品のあった受注も出荷/売上完了となります。
解答2
解説
注文検索画面より、検索キーになっている列、他表との結合列になっている列に対して索引の作成を検討します。
受注表には次の索引を作成します。
- 主キー
- 客先注文番号(客先で管理している注文番号)
- 顧客情報を特定するための索引(受注した顧客と出荷先の顧客)
- 受注した部門、社員を検索するための索引
部門、社員に関しては、ヒアリングによって、名前から検索されることが多いことがわかりました
IDと名前の両方が必要であるため、複合列索引として作成しました - 検索画面には出てきませんが、承認が必要となる社員がログインした際に、承認が必要な伝票を検索する必要があります その観点から、承認社員IDに索引を作成します
受注明細表には、以下の索引を作成します。
- 主キー
- 検索画面にはありませんが、出荷管理表から検索する際に必要な情報として、倉庫、商品、ロットの組み合わせに索引を作成します
- 承認が必要となる社員がログインした際に、承認が必要な伝票を検索する必要があります
その観点から、承認社員IDに索引を作成します
解答3
受注エンティティでは、以下の項目を導出項目として残します。
- 税抜受注金額計
- 消費税金額
- 伝票単位での値引金額
- 受注部門名
- 受注社員名
- ステータスコード
理由は、受注エンティティの検索頻度が非常に高いこと、併せて受注時に決定した以下の値は、参照先の表では、時間の経過とともに変化する可能性がありますが、ほしい値は受注時の値であるためです。
また、受注が確定した後、この借の変更はほとんどないということがアプリケーションの調査からわかっているため、冗長性を残しても問題はないと判断しました。
また、受注した伝票が最終的に入金処理まで完了したかどうかを管理するために、受注エンティティにキーとなるイベントが実施された日付を記述できるようにしてあります。
それぞれの処理が完了した時点で、受注エンティティにその日付が記入されるようにします。
- 出荷日付
- 請求日付
- 入金完了日付
受注明細エンティティでも同様の考え方で、次の属性を導出項目として残しておきます。
- 商品名
- 商品売上原価(売上時の利益計算に使用)
- 品販売原価(同上)
- ステータスコード
- 消費税額
- 金額
- キャンセル数量
- 出荷指示日付
解答4
受注エンティティの一意識別子は、受注番号で変更はありません。
桁数は、1年で発行される伝票数から8桁とします。
受注明細エンティティの一意識別子は、いろいろなエンティティから参照されて いため、受注番号+受注明細番号という人工的な番号をふることにします。
解答5
受注または受注明細の単位で、キャンセル時、元データの履歴を残しておくため、キャンセルフラグを設定します。
後からキャンセルしたレコードには「1」をたてます。
オンライン格納期間を過ぎたら、それ以降については、テープにバックアップを取得します。
解説トレーナー