システムアーキテクト 2019年 午後1 問02
容器管理システムの開発に関する次の記述を読んで、設問1～3に答えよ。
D社は、化学品を製造・販売するメーカである。製造した化学品を、様々な形状・容量の瓶（以下、容器という）に充填し、製品として顧客へ出荷する。顧客が製品を使用し、空になった容器は、D社が回収して再利用している。
現在は、生産管理システムから受領する製造計画に基づいて化学品を充填し、販売管理システムで製品の販売管理を行っている。このたび、顧客サービスの向上、容器の管理強化及び作業の効率向上のために、容器管理システムを新規に開発することにした。
〔現行業務の概要〕
現行業務の概要は、次のとおりである。
（1）充填
・D社の化学品は見込生産で、日ごとに生産する総量を、生産管理システムで製造計画として決定している。化学品は、製造の最終工程のラインで、化学品ごとに一意に定められた容器種の容器に充填されて、製品となる。“容器種”とは、どのような形状と容量の容器かを表す。
・充填に必要な容器は、製造計画に従って、容器倉庫から出庫される。同じ容器種が、異なる化学品の充填に用いられることもある。
・製品コード、化学品名、ロット番号、充填日を印刷した製品ラベルを生産管理システムから出力し、製品の容器に貼る。
・製品ラベルが貼られた製品を、製品倉庫に入庫・保管する。入庫時に、販売管理システムに入庫登録を行う。
（2）ピッキング
・製品倉庫では、受注した製品の出荷準備のために、販売管理システムから、ピッキングリストを出力する。
・倉庫作業者は、ピッキングリストの指示に従って、製品ラベルを目視確認しながら出荷すべき製品を集める。
・倉庫作業者は、ピッキングされた製品を、出荷場所に移動する。移動時に、販売管理システムに出庫登録を行う。
（3）積込・出荷
・出荷場所では、出荷のために手配された配送のトラック便ごとに、販売管理システムから、積込リスト及び出荷伝票を出力する。
・出荷作業者は、積込リストの指示どおり製品がそろっているかどうかのチェックと、配送業者が積込リストの指示どおり積込みを行ったかどうかの検品を行う。検品に合格したトラック便から出発し、顧客に製品を納品する。
・出荷作業者は、出荷実績を計上するために、出荷場所の端末から、出荷した製品の情報を販売管理システムに入力する。
（4）容器回収
・配送業者は、顧客が空になった容器を保管していた場合、容器返却書を起票して容器を回収し、D社の容器回収場所へ持ち帰る。
・回収作業者は、容器回収場所で、回収された容器と容器返却書の照合を行う。
（5）容器洗浄・検査
・回収された容器は洗浄され、検査担当者が検査を行う。
・検査に合格した容器は、再利用が可能になり、次の化学品の充填に利用されるまで、容器倉庫に保管される。
〔関連部門からの要望〕
容器管理システムを開発するに当たり、関連部門から次のような要望が出された。
（1）容器一つ一つが、今どのような状態にあるのかを管理できるようにしてほしい。
（2）作業者が行っている入力などの作業の負担を軽減してほしい。
（3）顧客が誤って使用期限を過ぎた製品を使ってしまわないように、顧客の下に使用期限間際の製品があれば、その期限の1週間前を過ぎたら、システムで警告を出せるようにしてほしい。
〔容器管理システムの開発方針〕
（1）容器管理システムは、購入、容器倉庫での保管、充填、製品倉庫での保管、出荷、回収、検査などの容器利用サイクルの状態を、容器単位に管理する。
（2）容器一つ一つの管理を行う手段として、無線通信方式のICタグ（以下、RFタグという）を採用する。
（3）容器倉庫、製造の最終工程のライン及び容器回収場所に、ゲート型のRFタグリーダライタ（以下、ゲートアンテナという）を設置する。
（4）製品倉庫、出荷場所、容器回収場所及び容器洗浄場所に、ハンディ型のRFタグリーダライタ（以下、HTという）を導入する。HTは、バーコードの読取りもできる機種とする。
（5）容器管理システムとして、容器購入処理、容器保管処理、充填処理、容器回収処理、容器洗浄・検査処理、及び容器状態検索処理の各機能を新規に開発する。
（6）ピッキング処理、積込・出荷処理、製品在庫管理処理、及び使用期限警告処理は、現行の販売管理システムの改修で対応する。
〔D社で採用したRFタグ及び関連する機器などの説明〕
（1）RFタグの通信距離は数メートルである。
（2）RFタグのデータレイアウトを、図1に示す。RFタグ番号は、RFタグの製造時に書き込まれるタグ固有の番号であり、書換えはできない。容器情報領域は、RFタグを容器に貼付する際に書き込み、書込み口ックを掛ける。書込みロックが掛けられた領域は、ロックを外さない限り値を変更できない。製品情報領域は、書込みが可能で、RFタグ購入時はクリアされている。
（3）ゲートアンテナは、ゲートを通過するRFタグを一括で読み書きできる。RFタグの一括読み書きでは、環境によって数%程度の漏れが発生することを事前検証で確認している。書込みについては、エラーを訂正する機能を備えているので、書込み時の異常は考慮しなくてよい。
（4）HTはRFタグを個別に読み書きでき、バーコードの読取りも可能である。
（5）D社は、容器の誤使用を防ぐために、RFタグへの書込み処理では、対象項目がクリアされていない場合は書き込みできないよう、プログラムでガードする。
〔容器管理システムの処理概要〕 容器管理システムの処理概要は、次のとおりである。
なお、容器一つ一つが、今どのような状態にあるかの管理を行うために、容器状態管理ファイルを設ける。
（1）容器購入処理
・容器の購入時に、RFタグに容器種コード、容器番号を書き込み、容器に貼付して、容器倉庫へ運ぶ。RFタグに書き込む際、容器種コード、容器番号をキーにして容器状態管理ファイルに登録し、容器状態区分を“未使用”にする。
（2）容器保管処理
・化学品の充填が可能になった容器を容器倉庫に入庫する。その際に、ゲートアンテナでRFタグを読み込んで、容器状態管理ファイルによるチェックを行い、充填可能な状態であることを確認する。その後、入庫処理を行い、それぞれの容器について、容器状態管理ファイルの容器状態区分を“容器倉庫入庫”にする。
・容器の出庫は、製造計画で決定した化学品の当日分の生産総量と製品マスタに登録されている情報を用いて、①どの容器が何個必要かを計算し、出庫指示を出す。出庫時に、ゲートアンテナでRFタグを読み込んで、それぞれの容器について、容器状態管理ファイルの容器状態区分を“容器倉庫出庫”にする。
（3）充填処理
・製造の最終工程で、製品がゲートアンテナを通過する際に、一つ一つのRFタグの製品情報領域へ製品コード、ロット番号、充填日の書込みを行う。この際、容器状態管理ファイルの容器状態区分を“充填済”にする。
・製品は製品倉庫に運ぶ。
（4）容器回収処理
・容器回収場所のゲートアンテナで、回収した容器のRFタグを一括して読み込む。
・容器返却書に記載された容器返却数をシステムに入力して、RFタグの読込み件数とのチェックをシステムで行い、数が一致したら、それぞれの容器について、容器状態管理ファイルの容器状態区分を“回収”にする。
・数が不一致の場合は、まず、容器返却数のシステムへの入力が正しいことを確認して、その後、HTによる個別の読込みに切り替える。個別読込み時に、容器状態管理ファイルの容器状態区分を“回収”にする。個別読込み件数と容器返却書に記載された容器返却数が不一致の場合は、エラー処理を行う。
（5）容器洗浄・検査処理
・回収した容器は、容器洗浄場所で洗浄され、検査担当者が再利用の可否についての検査を行った後、RFタグの製品情報領域をクリアする。検査に合格した容器は容器倉庫へ運び、不合格となった容器は廃棄する。検査結果によって、容器状態管理ファイルの容器状態区分を“合格”又は“廃棄”にする。
・廃棄した容器に貼付してあったRFタグは、容器からはがして、再利用できるように、HTを用いて、②ある処理を行う。
（6）容器状態検索処理
・容器状態管理ファイルの情報を任意の条件で検索する。
容器管理システムで使用する主要なファイルを表1に示す。
〔販売管理システムの改修〕 容器管理システムの新規開発に伴い、販売管理システムを、次のとおり改修する。 （1）ピッキング処理 ・ピッキングリストへバーコードを印字し、HTでピッキング指示データを受ける。 ・ピッキング指示データに基づき、HTで、ピッキング対象となる容器のRFタグを読み込む。ピッキング指示データとRFタグ情報をチェックし、製品コードが合っていればRFタグへ受注伝票番号を書き込み、容器状態管理ファイルの容器状態区分を“ピッキング済”にする。合っていなければエラー処理を行う。 （2）積込・出荷処理 ・積込リストへバーコードを印字し、HTで積込指示データを受ける。 ・HTで、積込対象となる製品のRFタグを読み込み、積込指示データとRFタグ情報をチェックする。③データ内容及び数が合っていれば、検品を完了して出荷する。この際、容器状態管理ファイルの容器状態区分を“出荷”にする。合っていなければエラー処理を行う。 ・HTの検品を完了した実績データを取り込んで、(a)。 （3）製品在庫管理処理 ・製品倉庫への入庫時に、HTでRFタグを読み、読み込んだデータで入庫実績を計上できるようにする。この際、容器状態管理ファイルの容器状態区分を“製品倉庫入庫”にする。 ・製品倉庫からの出庫時に、HTでRFタグを読み、読み込んだデータで出庫実績を計上できるようにする。この際、容器状態管理ファイルの容器状態区分を“製品倉庫出庫”にする。 （4）使用期限警告処理 ・顧客の下にある、使用期限が過ぎそうな製品及び使用期限が過ぎた製品を、容器管理システムの容器状態検索処理を利用して次の条件で検索し、顧客に警告を発することができるようにする。 条件：容器状態管理ファイルの容器状態区分の値が “(b)”で、(c) が本日日付の1週間後より前の日付である容器
設問1：容器管理システムの処理について、（1）、（2）に答えよ
（1）容器倉庫へ入庫可能な容器の容器状態区分の値を全て答えよ。
模範解答
未使用、合格
解説
解答の論理構成
- 入庫可能条件を探す
- 容器倉庫での入庫フローは【問題文】「化学品の充填が可能になった容器を容器倉庫に入庫する。」と記載。
- 入庫前に取り得る容器状態を抽出
- 購入時処理: 【問題文】「容器状態区分を“未使用”にする。」→まだ使用歴がなく入庫可能。
- 洗浄・検査後処理: 【問題文】「検査に合格した容器は容器倉庫へ運び…容器状態区分を“合格”…にする。」→再利用OKで入庫可能。
- 他の区分は候補外
- 「容器倉庫入庫」は入庫後に付与されるため前提条件にならない。
- 「回収」「廃棄」などは入庫対象外と明示的または業務的に判断できる。
- よって回答は「未使用、合格」。
誤りやすいポイント
- 「容器倉庫入庫」を入庫可と勘違いする
- 「回収」後すぐ入庫できると思い込む（実際は洗浄・検査を経て“合格”になるまで不可）
- “検査に合格”＝“充填済”と混同して「充填済」を挙げてしまう
FAQ
Q: 「容器倉庫入庫」はなぜ含めないのですか？
A: これは入庫処理が完了した後に設定される状態区分です。入庫する前提としての区分ではありません。
A: これは入庫処理が完了した後に設定される状態区分です。入庫する前提としての区分ではありません。
Q: “回収”の容器は一度倉庫に通るのでは？
A: 回収直後は洗浄・検査前なので直接倉庫には入りません。検査で“合格”判定を受けて初めて倉庫入庫対象になります。
A: 回収直後は洗浄・検査前なので直接倉庫には入りません。検査で“合格”判定を受けて初めて倉庫入庫対象になります。
Q: “未使用”の容器も洗浄は不要ですか？
A: 購入直後の新品を想定しており、洗浄は不要と業務フローに示されています。そのまま容器倉庫へ搬入されます。
A: 購入直後の新品を想定しており、洗浄は不要と業務フローに示されています。そのまま容器倉庫へ搬入されます。
関連キーワード: RFID, 状態遷移管理、在庫区分、検査合否、回収フロー
設問1：容器管理システムの処理について、（1）、（2）に答えよ
（2）本文中の下線①で用いる、製品マスタに登録されている情報は何か。表1中の属性名を用いて全て答えよ。
模範解答
容器種コード、容器一個当たり標準充填量
解説
解答の論理構成
- 【問題文】の該当箇所
製造計画で決定した化学品の当日分の生産総量と製品マスタに登録されている情報を用いて、①どの容器が何個必要かを計算し、出庫指示を出す。
- 目的を分解
- 「どの容器が？」→容器種を特定する情報が要る。
- 「何個必要か？」→総量 ÷ 1本あたりの充填量で個数を算出。
- 製品マスタ（表1）の属性確認
製品マスタ：製品コード、化学品名、容器種コード、容器一個当たり標準充填量、製品使用可能日数
- 上記②③を結びつけると、必要なのは
- 容器種コード
- 容器一個当たり標準充填量
他の属性は容器数計算に直接関与しない。
- よって答えは「容器種コード、容器一個当たり標準充填量」となる。
誤りやすいポイント
- 「製品コード」まで挙げてしまう
⇒ 容器種は一意に決まるため不要。 - 「製品使用可能日数」を含める
⇒ 使用期限管理には使うが容器数計算には関係なし。 - 「容器番号」と混同
⇒ 容器番号は個体識別用。マスタには存在せず、計算にも不要。
FAQ
Q: 製品コードを使わずに容器種をどう特定するのですか？
A: 製品マスタには製品コードと「容器種コード」の対応が登録されています。容器数計算では、製品コード経由で取得した「容器種コード」を直接利用します。
A: 製品マスタには製品コードと「容器種コード」の対応が登録されています。容器数計算では、製品コード経由で取得した「容器種コード」を直接利用します。
Q: 充填量は実測とズレることがありますが問題ありませんか？
A: 計算には「容器一個当たり標準充填量」という設計値を用いる想定です。実際の重量差異は充填工程側の管理対象であり、容器出庫指示の段階では標準値で十分とされています。
A: 計算には「容器一個当たり標準充填量」という設計値を用いる想定です。実際の重量差異は充填工程側の管理対象であり、容器出庫指示の段階では標準値で十分とされています。
関連キーワード: 容器種コード、標準充填量、RFタグ、在庫計算、マスタ参照
設問2：〔容器管理システムの処理概要〕について、（1）、（2）に答えよ。
（1）容器回収処理において、HTによる個別読込み時に、数が一致するケースと不一致になるケースがある。それらはどのようなときに起きるか、それぞれ30字以内で述べよ
模範解答
一致するケース：RFタグの一括読込みで読込み漏れが発生したとき、
不一致になるケース：容器返却書の容器返却数と実際の容器の数が違っているとき
解説
解答の論理構成
- 一括読込みの特性
- 【問題文】「RFタグの一括読み書きでは、環境によって数%程度の漏れが発生」とあり、ゲートで全数を捉えられないことがある。
- 一致となる流れ
- 一括で不足→個別に読み直し→本来の返却数と“ピタリ”一致。
- したがって「一致＝一括読込み漏れの補正が成功した状態」。
- 不一致となる流れ
- 【問題文】「個別読込み件数と容器返却書に記載された容器返却数が不一致の場合は、エラー処理」。
- 返却書自体の記載誤り、積込ミスなどで物理数が違うと個別読込みでも合わず不一致に。
- 30字以内のまとめ
- 一致: 「ゲート一括読込みでRFタグを取りこぼした場合」
- 不一致: 「返却書記載数と実容器数が食い違っている場合」
誤りやすいポイント
- 「個別読込み＝必ず不一致」と思い込む
→ 実際は漏れ補完なら一致になる。 - ゲート読込み漏れを“通信エラー”と表現し枚数を絡めずに書く
→ 原因は「数%程度の漏れ」という枚数不足。 - 不一致の原因を「HT読取りエラー」とする
→ 個別読込みはタグを一つずつ読むため漏れに強く、主因は数量誤記。
FAQ
Q: ゲートアンテナの漏れは常に再読込みで解消できますか？
A: 数量が合うまでHTで個別読込みすれば補完できます。ただし容器が存在しない場合は不一致のままです。
A: 数量が合うまでHTで個別読込みすれば補完できます。ただし容器が存在しない場合は不一致のままです。
Q: HT読込みでもタグを読み取れない場合がありますか？
A: 個別読込みは至近距離で実施するため漏れのリスクは極小ですが、タグ破損など物理故障時には読み取れません。
A: 個別読込みは至近距離で実施するため漏れのリスクは極小ですが、タグ破損など物理故障時には読み取れません。
Q: 不一致時の「エラー処理」とは具体的に？
A: 返却書再確認、配送業者への照会、破損・紛失調査など社内規程で定められた手続きを指します。
A: 返却書再確認、配送業者への照会、破損・紛失調査など社内規程で定められた手続きを指します。
関連キーワード: RFID, ゲートアンテナ、一括読取り、在庫照合、誤差補正
設問2：〔容器管理システムの処理概要〕について、（1）、（2）に答えよ。
（2）本文中の下線②のある処理とは何か。30字以内で述べよ。
模範解答
書込みロックを外して、容器情報領域をクリアする処理
解説
解答の論理構成
- 再利用の目的を確認
- 【問題文】「廃棄した容器に貼付してあったRFタグは、容器からはがして、再利用できるように、HTを用いて、②ある処理を行う。」
ここで言う“再利用”は次の容器に貼り替えることを意味します。
- 【問題文】「廃棄した容器に貼付してあったRFタグは、容器からはがして、再利用できるように、HTを用いて、②ある処理を行う。」
- 容器情報領域はロックされている
- 【問題文】「容器情報領域は、RFタグを容器に貼付する際に書き込み、書込みロックを掛ける。書込みロックが掛けられた領域は、ロックを外さない限り値を変更できない。」
- クリアしないと新規書込みができない
- 【問題文】「対象項目がクリアされていない場合は書き込みできないよう、プログラムでガードする。」
- 従って必要な操作
(1) 書込みロックを解除する
(2) 容器情報領域をクリアする
以上を HT で実行すれば，RF タグは新しい容器に使える状態になります。
誤りやすいポイント
- 「製品情報領域だけをクリア」と誤解しやすい
→ 再利用時は容器種コード・容器番号も書き直すため、容器情報領域の初期化が必須です。 - ロック解除を忘れる
→ ロックされたままでは書込みができません。 - RFタグ番号を書き換えると考えてしまう
→ RFタグ番号は「書換えはできない」ので対象外です。
FAQ
Q: なぜ製品情報領域のクリアだけでは足りないのですか？
A: 再利用時は別の容器に貼るため「容器種コード」「容器番号」を新たに書き込む必要があります。これらは容器情報領域にあるため、ロック解除とクリアが不可欠です。
A: 再利用時は別の容器に貼るため「容器種コード」「容器番号」を新たに書き込む必要があります。これらは容器情報領域にあるため、ロック解除とクリアが不可欠です。
Q: ロック解除とクリアは HT で一度にできますか？
A: 多くの HT では API で「ロック解除→書込み（クリア値）」を連続実行できますが、システム上は２段階動作として実装し、解除が成功したことを確認してからクリアするのが安全策です。
A: 多くの HT では API で「ロック解除→書込み（クリア値）」を連続実行できますが、システム上は２段階動作として実装し、解除が成功したことを確認してからクリアするのが安全策です。
関連キーワード: RFタグ、書込みロック、データクリア、再利用
設問3：〔販売管理システムの改修〕について、（1）～（3）に答えよ。
（1）本文中の下線③のデータ内容を、表1中の属性名を用いて全て答えよ。
模範解答
受注伝票番号、製品コード
解説
解答の論理構成
- ピッキング処理での書込み内容を確認
「ピッキング指示データとRFタグ情報をチェックし、製品コードが合っていれば RFタグへ受注伝票番号を書き込み」（本文引用）とあり、RF タグは以後「受注伝票番号」「製品コード」を保持します。 - 積込・出荷処理でのチェック内容を確認
「HTで、積込対象となる製品のRFタグを読み込み、積込指示データとRFタグ情報をチェックする。③データ内容及び数が合っていれば…」（本文引用） - ここで照合するのは、積込指示データ（＝受注単位）と RF タグ情報の一致確認です。受注単位を識別する「受注伝票番号」と、製品種別を識別する「製品コード」が双方に含まれるため、この二つが③の答えとなります。
- 表1を見ると双方とも属性名としてそのまま記載されているため、表記は「受注伝票番号、製品コード」となります。
誤りやすいポイント
- 「製品コード」だけで良いと判断し、「受注伝票番号」を落とす。結果、同一製品の他の受注分と混載する危険を見落とす。
- 表1の属性名を正確に引用せず、「受注番号」「商品コード」など勝手に言い換えて減点。
- ピッキング処理と積込処理の役割を混同し、ピッキング時点でチェックが終わっているから積込では不要と勘違いする。
FAQ
Q: なぜロット番号は照合対象に含まれないのですか？
A: 積込指示は受注単位で作成され、ピッキング処理でロットが確定しています。積込工程では受注単位の誤混載防止が主目的なので、「受注伝票番号」と「製品コード」で十分です。
A: 積込指示は受注単位で作成され、ピッキング処理でロットが確定しています。積込工程では受注単位の誤混載防止が主目的なので、「受注伝票番号」と「製品コード」で十分です。
Q: RFタグの読み取り漏れがあるときはどうするのですか？
A: 本文では「数が合っていれば検品を完了」とあり、合わなければエラー処理に進みます。ゲートではなく HT を使うため、読み取り漏れは発生しにくい前提です。
A: 本文では「数が合っていれば検品を完了」とあり、合わなければエラー処理に進みます。ゲートではなく HT を使うため、読み取り漏れは発生しにくい前提です。
関連キーワード: RFタグ、トレーサビリティ、在庫照合、バーコード認識、データ整合性
設問3：〔販売管理システムの改修〕について、（1）～（3）に答えよ。
（2）積込・出荷処理について、(a)に入れる適切な字句を答えよ。
模範解答
a：出荷実績を計上する
解説
解答の論理構成
- 現行業務の確認
【問題文】の〔現行業務の概要〕(3)積込・出荷には
「出荷作業者は、出荷実績を計上するために、出荷場所の端末から、出荷した製品の情報を販売管理システムに入力する。」
と記載されています。 - 改修後の流れ
〔販売管理システムの改修〕(2)積込・出荷処理 では
「HTで…検品を完了して出荷する。この際、容器状態管理ファイルの容器状態区分を“出荷”にする。」
とあり、続けて
「HTの検品を完了した実績データを取り込んで、(a)。」
と指示されています。 - 目的の一致
検品完了後にシステムへ登録すべき実績は、旧来の「出荷実績」に相当します。したがって (a) には「出荷実績を計上する」が入ります。
誤りやすいポイント
- 「検品実績を記録する」と誤記する
検品自体は HT 内で完了しており、システムに登録するのは“出荷”の実績です。 - 「在庫を更新する」と答える
在庫は別途〔製品在庫管理処理〕で管理されます。ここで求められているのは販売管理上の実績計上です。 - 「RFタグ情報を更新する」と混同する
RFタグは直前の処理で“出荷”状態へ更新済みであり、(a) は販売管理システム側の処理です。
FAQ
Q: 検品と出荷実績計上は同時に行うのではないのですか？
A: 検品は HT 上で完了し、その結果データをシステムに取り込む時点で“出荷実績を計上”します。業務的にはほぼ連続しますが、処理目的は区別されています。
A: 検品は HT 上で完了し、その結果データをシステムに取り込む時点で“出荷実績を計上”します。業務的にはほぼ連続しますが、処理目的は区別されています。
Q: 在庫減算は出荷実績計上と自動連携されますか？
A: 問題文では明示されていませんが、通常は販売管理システムで出荷実績が計上されると在庫管理モジュールと連携し、在庫数量が更新される設計が一般的です。
A: 問題文では明示されていませんが、通常は販売管理システムで出荷実績が計上されると在庫管理モジュールと連携し、在庫数量が更新される設計が一般的です。
Q: 「出荷確定」と書いてはダメですか？
A: 業務的には意味が近いものの、問題文が用いている正式な用語「出荷実績を計上する」をそのまま解答する必要があります。
A: 業務的には意味が近いものの、問題文が用いている正式な用語「出荷実績を計上する」をそのまま解答する必要があります。
関連キーワード: ハンディターミナル、出荷実績、トレーサビリティ、ファイル更新、プロセス改善
設問3：〔販売管理システムの改修〕について、（1）～（3）に答えよ。
（3）使用期限告処理について、(b)、(c)に入れる適切な字句を答えよ。ここで、(b)は本文中の容器状態区分の値を答えよ。また、(c)は表1中の属性名を用いて述べよ。
模範解答
b：出荷
c：充填日から製品使用可能日数後の日付
解説
解答の論理構成
- 顧客に渡り使用中の製品を示す容器状態区分
- 【問題文】「出荷場所では…検品を完了して出荷する。この際、容器状態管理ファイルの容器状態区分を“出荷”にする。」
- よって、顧客の手元にある容器は状態区分 “出荷”。
- 使用期限日付の導出ロジック
- 使用期限は「充填日」が起点。
- 表1「製品マスタ」の属性に「製品使用可能日数」が定義。
- 【問題文】「顧客が誤って使用期限を過ぎた製品を使ってしまわないように…」とあり、充填日＋製品使用可能日数で算出した日付を比較する仕様。
- 検索条件への落とし込み
- 条件式は「充填日から製品使用可能日数後の日付 ＜ 本日日付＋7日」。
- 属性名としては「充填日」と「製品使用可能日数」をそのまま用い、算出後の日付を (c) とする。
- したがって
- (b) = 「出荷」
- (c) = 「充填日から製品使用可能日数後の日付」
誤りやすいポイント
- 「回収」や「製品倉庫出庫」を選んでしまう
顧客に届く前後のフローを混同しやすいので、出荷タイミングを時系列で整理することが重要です。 - 充填日そのものを使用期限と勘違い
使用可能日数を加算する計算を忘れると条件式がずれます。 - 属性名で記述する指示を見落とす
「使用期限」など未定義フィールドを書くと減点対象になります。
FAQ
Q: 顧客の下にあるかどうかは「受注伝票番号」が入っているかで判別できませんか？
A: 受注伝票番号はピッキング時点で書き込まれるため、倉庫内でも保持されています。顧客到着を確実に示すのは「出荷」の状態区分です。
A: 受注伝票番号はピッキング時点で書き込まれるため、倉庫内でも保持されています。顧客到着を確実に示すのは「出荷」の状態区分です。
Q: 「充填日から製品使用可能日数後の日付」は物理項目として持つべきですか？
A: 検索時に計算で求める設計で問題ありません。リレーショナル演算で動的に算出し、固定項目としては保持しないケースが一般的です。
A: 検索時に計算で求める設計で問題ありません。リレーショナル演算で動的に算出し、固定項目としては保持しないケースが一般的です。
Q: 1週間前の基準日は「本日日付＋7日」と「本日日付の1週間後」どちらで表現すべき？
A: どちらも同義ですが、仕様書では「本日日付の1週間後」と統一されていますので合わせると読み違いを防げます。
A: どちらも同義ですが、仕様書では「本日日付の1週間後」と統一されていますので合わせると読み違いを防げます。
関連キーワード: RFID, 状態遷移、在庫管理、期限管理、データ整合性
