システムアーキテクト 2014年 午後1 問02
物流センタのシステム構築に関する次の記述を読んで、設問1~4に答えよ。
C社は、関東地方を中心に日用雑貨品の製造・販売を行っている。このたび物流センタの新設に伴い、物流センタシステムを新規に構築することになった。
〔現在の受注・出荷業務及びシステム化状況〕
(1) 商品は、見込生産をしており、生産後、決められた配分割合で各営業所に配送し、各営業所で在庫を保持している。
(2) 顧客は、雑貨卸問屋及び量販店が主であり、担当する顧客が営業所ごとに決められている。商品の注文は、営業担当者が直接顧客から受けるか、顧客から営業所への電子メール、電話、ファックスで受けている。
(3) 受注は、各営業所で入力し、営業所サーバで管理している営業所在庫から引き当てる。在庫引当てができた受注は、システムで出荷関連の帳票を発行して出荷する。
(4) 営業所在庫で引当てができなかった受注は、他営業所に在庫の有無を確認し、在庫があれば受注データをその営業所に送信し、出荷を依頼する。
(5) 他営業所にも在庫がない場合は、工場サーバに自営業所への出庫依頼データを送信する。工場は、受けた出庫依頼を追加の生産計画として取り込み、その結果を営業所への出庫予定データとして送信する。営業所は、その出庫予定(営業所にとっての入荷予定)が、受注した納期に影響する場合は、営業担当者が顧客と納期調整を行い、その結果を受注変更として登録する。
(6) 顧客への出荷データは売上データとして、営業所サーバから夜間に本社へ送信され、本社サーバで売上計上、請求・入金処理が行われる。売上は、受注した営業所への計上が原則であるが、他営業所から出荷した場合は、売上の一部が出荷手数料として、出荷した営業所に振替計上される。
〔物流センタ新設後の業務概要〕
新設した物流センタで商品在庫を集中管理し、顧客への出荷は全て物流センタから行う。物流センタには、物流センタサーバを導入し、営業所の受注処理を行う。
現在検討している、物流センタ新設後の業務概要は、次のとおりである。
(1) 受注・在庫引当て
① 顧客からの受注は、各営業所から物流センタサーバに登録し、出荷予定、出荷実績、在庫引当てなどの状況を、随時照会できるようにする。受注登録時に、物流センタの商品在庫の引当てを行い、結果を出荷予定ファイルに出力する。
② 物流センタの商品別在庫を管理する在庫マスタの在庫関連項目として、実在庫、引当済実在庫、入荷予定在庫及び引当済入荷予定在庫を設ける。受注登録時の在庫引当ては、これらの在庫情報から算出した引当可能在庫に対して行われる。引当可能在庫は、次の式で算出する。
引当可能在庫 = 実在庫 + 入荷予定在庫 −(引当済実在庫 + 引当済入荷予定在庫)
(2) 入荷
① 物流センタサーバは、工場サーバから入荷予定情報を受信し、在庫マスタの入荷予定在庫を更新するとともに、翌日分の入荷予定表を出力する。工場からの入荷時に、入荷予定表と現品の照合チェックを行う。
② 入荷実績を物流センタの受入場の端末から入力し、保管庫に棚入れするための棚入指示表を出力するとともに、在庫マスタの実在庫、引当済実在庫、入荷予定在庫及び引当済入荷予定在庫を更新し、棚番別在庫ファイルの棚入指示済在庫を更新する。
(3) 棚入れ・保管
① 棚入指示表に基づき、商品を保管庫の棚に入れ、ポータブル端末から棚入実績を入力し、物流センタサーバに送信する。保管庫では、1種類の商品を一つ以上の棚に保管している。保管庫の在庫管理は、物流センタサーバの棚番別在庫ファイルで行い、棚入実績によって、棚番別在庫ファイルの実在庫及び棚入指示済在庫を更新する。
② 適正在庫を維持するために、在庫マスタに在庫補充点を新たに設定する。在庫量が在庫補充点以下になると、システムで一定量の在庫補充のオーダを生成し、工場サーバに送信する。在庫補充点には、在庫補充のリードタイム内での欠品を防止するための安全在庫が含まれている。
(4) 棚出し
① 保管庫で、翌日出荷予定の棚出指示表を出力し、棚番別在庫ファイルの棚出指示済在庫を更新する。棚出指示表に基づいて棚出しをした後、ポータブル端末から棚出実績を入力し、物流センタサーバに送信する。
② 棚出実績によって、棚番別在庫ファイルの実在庫及び棚出指示済在庫を更新する。
(5) 出荷
① 出荷場で、翌日出荷予定の出荷予定表と出荷ラベルを出力する。棚出しされた商品を出荷場で段ボール箱に梱包し、出荷ラベルを貼り、納品先別にそろえておく。翌日、商品を引取りに来た運送業者のトラックに段ボール箱を積み込む。その出荷実績を出荷場の端末から入力し、受注の消込み、在庫マスタの実在庫、引当済実在庫を更新するとともに、納品伝票などの出荷関連帳票を出力する。
② 物流センタからの出荷時点で、受注した営業所の売上として計上される。売上データは、夜間に本社サーバに送信し、本社サーバで売上集計処理、請求・入金処理を行う。
〔棚出しから出荷までの業務フロー〕
棚番別在庫ファイルのレイアウトを図1に、(4)棚出しから(5)出荷までの業務フローを図2に示す。
〔棚出し関連及び出荷関連の処理記述書〕 棚出し関連の処理記述書を表1に、出荷関連の処理記述書を表2に示す。

設問1:物流センタの在庫について、(1)、(2)に答えよ。
(1)受注登録時の在庫引当てにおいて、引当対象となる引当可能在庫の算出式の(a)~(c)に入れる適切な字句を答えよ。
模範解答
a:実在庫
b:引当済実在庫
c:出荷予定日までの入荷予定在庫
解説
解答の論理構成
- 在庫マスタで扱う項目を確認
【問題文】「実在庫、引当済実在庫、入荷予定在庫及び引当済入荷予定在庫を設ける。」
‐ ここで “実在庫” と “引当済実在庫” が明示されています。 - 引当可能在庫の式を確認
【問題文】「引当可能在庫 = (a) - (b) + (c) - ((c)のうち引当済みのもの)」
‐ 先ほどの4項目を式に当てはめると、(a) は “実在庫”、(b) は “引当済実在庫”。 - (c) を特定
‐ 式の +(c)-((c)のうち引当済みのもの) は「入荷予定在庫」から「引当済入荷予定在庫」を差し引く構造。
‐ ただし受注登録時点で出荷予定日に間に合う分でなければ計上できません。よって (c) は「出荷予定日までの入荷予定在庫」。 - 以上より
(a) 実在庫
(b) 引当済実在庫
(c) 出荷予定日までの入荷予定在庫
誤りやすいポイント
- (c) を単に「入荷予定在庫」としてしまい、将来分まで足してしまう。
- (b) と「引当済入荷予定在庫」を取り違える。式の前後関係と差し引き対象を確認すること。
- 「安全在庫」「在庫補充点」と混同し、安全在庫を引くと誤解する。
FAQ
Q: 「実在庫」と「引当済実在庫」はどちらもマイナス要素では?
A: 「実在庫」をベースとして、すでに他の受注で押さえられている量「引当済実在庫」を差し引くため、両方必要です。
A: 「実在庫」をベースとして、すでに他の受注で押さえられている量「引当済実在庫」を差し引くため、両方必要です。
Q: なぜ「引当済入荷予定在庫」を式に直接入れないのですか?
A: 式は と で表現しています。これは「入荷予定在庫」全量を足し、そのうち既に引当て済みの量を差し引く二段階の考え方だからです。
A: 式は と で表現しています。これは「入荷予定在庫」全量を足し、そのうち既に引当て済みの量を差し引く二段階の考え方だからです。
Q: 安全在庫はどこで考慮しますか?
A: 安全在庫は補充点を決める際に使われ、日々の引当計算には直接登場しません。
A: 安全在庫は補充点を決める際に使われ、日々の引当計算には直接登場しません。
関連キーワード: 在庫引当、実在庫、入荷予定在庫、安全在庫
設問1:物流センタの在庫について、(1)、(2)に答えよ。
(2)物流センタへの入荷時に、在庫マスタの実在庫の加算更新と入荷予定在庫の減算更新を行う。他に二つの在庫情報が更新される可能性がある。その二つについて、何の在庫情報が、どのように更新されるか。それぞれ20字以内で述べよ。
模範解答
①:引当済実在庫が加算更新される。
②:引当済入荷予定在庫が減算更新される。
解説
解答の論理構成
- 設問は「実在庫の加算更新」と「入荷予定在庫の減算更新」を前提とする。
- 【問題文】(2) 入荷②
「在庫マスタの実在庫、引当済実在庫、入荷予定在庫及び引当済入荷予定在庫を更新」
から更新対象が4つであることが分かる。 - 実在庫と入荷予定在庫は既に条件に示されているため、残る
「引当済実在庫」「引当済入荷予定在庫」が追加で更新される在庫情報である。 - 入荷実績が立つ時点では、引当て済みで実在庫へ引き渡す数量が発生するため
「引当済実在庫」は在庫を確保するために加算される。 - 一方、入荷予定のうち既に引当てられていた数量は予定から実績側へ移るので
「引当済入荷予定在庫」は減算される。 - よって回答は
① 引当済実在庫が加算更新
② 引当済入荷予定在庫が減算更新
誤りやすいポイント
- 「引当済実在庫」と「引当済入荷予定在庫」を逆にしてしまう。
- 「加算/減算」を両方とも同じ方向に書いてしまう。
- 「棚番別在庫ファイル」の更新内容と混同する。
FAQ
Q: なぜ「引当済実在庫」を加算するのですか?
A: 入荷実績が確定すると、引当て済みで出荷待ちだった数量が実在庫側に移るため、確保済みとして加算されます。
A: 入荷実績が確定すると、引当て済みで出荷待ちだった数量が実在庫側に移るため、確保済みとして加算されます。
Q: 「引当済入荷予定在庫」を減算する理由は?
A: 予定だった在庫が実績に変わるため、予定側の引当て数量を減らし二重計上を防ぎます。
A: 予定だった在庫が実績に変わるため、予定側の引当て数量を減らし二重計上を防ぎます。
Q: 更新対象は常に4項目ですか?
A: 【問題文】どおり入荷処理では4項目を更新しますが、他の業務(棚出し・出荷)では更新対象が異なります。
A: 【問題文】どおり入荷処理では4項目を更新しますが、他の業務(棚出し・出荷)では更新対象が異なります。
関連キーワード: 在庫マスタ、引当処理、入荷実績、在庫補充点
設問2:表1の棚出し関連の処理記述書について、(1)、(2)に答えよ。
(1)表1中の(d)に入れる適切な字句を,25字以内で述べよ。
模範解答
d:棚番別在庫ファイルの出荷対象商品の棚番
解説
解答の論理構成
- 処理ステップの確認
表1「棚出指示表作成」の(2)で「出荷予定ファイルから翌日出荷予定レコードを抽出」した後、(3)で (d) を「特定する」とあります。 - 何を特定するか
出荷予定から得られるのは “商品コード” と “出荷数量” ですが、実際に棚から商品を取り出すには “棚番” が欠かせません。 - 必要なデータソース
問題文では「保管庫の在庫管理は、物流センタサーバの棚番別在庫ファイルで行い」と明記され、棚番はこのファイルで管理されています。 - 更新対象との整合性
続く(4)で「棚番別在庫ファイルの棚出指示済在庫を更新」とあるため、(d) で特定した情報は同一ファイル内のキー項目である必要があります。 - 結論導出
以上より、(d) は「棚番別在庫ファイルの出荷対象商品の棚番」となります。
誤りやすいポイント
- 出荷予定ファイル内に “棚番” があると誤解し、「商品コードと数量のみで足りる」と判断してしまう。
- (d) が数量や在庫区分だと勘違いし、キー情報の特定という意図を見落とす。
- 表1(4)更新対象が同ファイルである事実を読み飛ばし、処理の整合性を崩してしまう。
FAQ
Q: 在庫マスタにも棚番はありませんか?
A: 在庫マスタは商品の総量を管理しており、保管場所を示す “棚番” は「棚番別在庫ファイル」にのみ保持されています。
A: 在庫マスタは商品の総量を管理しており、保管場所を示す “棚番” は「棚番別在庫ファイル」にのみ保持されています。
Q: 棚出指示表に必要な情報は棚番以外にもありますか?
A: あります。商品コード、商品名、数量などが載りますが、棚を探し当てるキーとして “棚番” の特定が最優先です。
A: あります。商品コード、商品名、数量などが載りますが、棚を探し当てるキーとして “棚番” の特定が最優先です。
Q: (d) が棚番なら、実際の数量はどこで取得しますか?
A: 数量は出荷予定ファイルに記録されており、棚番特定後に棚番別在庫ファイルへアクセスして “棚出指示済在庫” を更新します。
A: 数量は出荷予定ファイルに記録されており、棚番特定後に棚番別在庫ファイルへアクセスして “棚出指示済在庫” を更新します。
関連キーワード: 在庫引当、棚番管理、ファイル更新、出荷指示
設問2:表1の棚出し関連の処理記述書について、(1)、(2)に答えよ。
(2)表1中の(e)に入れる処理内容を,35字以内で述べよ。
模範解答
e:棚番別在庫ファイルの実在庫及び棚出指示済在庫を更新する。
解説
解答の論理構成
- 問題文の該当箇所把握
〔棚出し〕(4)② に「棚出実績によって、棚番別在庫ファイルの実在庫及び棚出指示済在庫を更新する。」とある。 - 処理記述書との対応付け
表1「棚出処理」の(3)では、ポータブル端末から棚出実績が送られてきた際に行う処理を①( e )と②で示している。 - 更新対象の特定
棚出実績が確定すると在庫数量の実態(実在庫)が減る一方で、指示された分(棚出指示済在庫)は消し込む必要がある。両方を更新する処理が求められる。 - 結論導出
よって (e) は「棚番別在庫ファイルの実在庫及び棚出指示済在庫を更新する。」となる。
誤りやすいポイント
- 「実在庫」だけを更新すると記述し、「棚出指示済在庫」を忘れる。
- 在庫マスタと混同し、「在庫マスタを更新する」と書いてしまう。
- 処理主体を意識せず「出荷予定ファイルを更新する」と誤記する。
FAQ
Q: なぜ在庫マスタではなく棚番別在庫ファイルなのですか?
A: 棚出しは保管庫内の棚単位の在庫を扱うため、棚番管理を行う「棚番別在庫ファイル」で数量を減算・消込する必要があります。
A: 棚出しは保管庫内の棚単位の在庫を扱うため、棚番管理を行う「棚番別在庫ファイル」で数量を減算・消込する必要があります。
Q: 棚出指示済在庫とは何を表していますか?
A: 棚出指示表発行時点で「この棚から取り出す予定」とマークされた在庫です。実際に棚出しが完了すると実在庫と合わせて更新し、二重計上を防ぎます。
A: 棚出指示表発行時点で「この棚から取り出す予定」とマークされた在庫です。実際に棚出しが完了すると実在庫と合わせて更新し、二重計上を防ぎます。
Q: 出荷予定ファイルの状態更新は(e)に含めなくていいのですか?
A: 出荷予定ファイルの状態更新は表1の②で別途「棚出済みにする」と規定されており、(e) は棚番別在庫ファイルのみを対象にします。
A: 出荷予定ファイルの状態更新は表1の②で別途「棚出済みにする」と規定されており、(e) は棚番別在庫ファイルのみを対象にします。
関連キーワード: 在庫管理、実在庫、棚番管理、棚出指示、ファイル更新
設問3:表2の出荷関連の処理記述書について、(1)、(2)に答えよ。
(1)表2中の(f)に入れる適切なファイル名を答えよ。
模範解答
f:出荷予定ファイル
解説
解答の論理構成
- 表2「出荷処理」(2) に
“出荷予定表の出荷番号を入力し、出荷予定ファイルから該当する出荷予定レコードの内容を表示する。”
とあります。ここで参照しているのは「出荷予定ファイル」です。 - 同じ処理の(3)①で空欄(f)に続く文が
“該当する出荷予定レコードの状態を出荷済みにするとともに、出荷実績ファイルに出力する。”
と記述されています。“該当する出荷予定レコード”は直前で参照した「出荷予定ファイル」のレコードを指します。 - よって、更新対象ファイル=空欄(f)=「出荷予定ファイル」と導けます。
誤りやすいポイント
- “出荷実績ファイル”と混同する
- 出荷済みになったデータは“出荷実績ファイルに出力”と記載されていますが、状態変更は“出荷予定ファイル”で行うので注意です。
- 表1の棚出し処理と混同する
- 棚出し関連では“棚番別在庫ファイル”を更新しますが、本設問は出荷関連であり対象ファイルが異なります。
- “受注ファイル”を選ぶミス
- 出荷処理時に“受注の消込み”も行いますが、状態更新対象は“出荷予定レコード”である点を見落としがちです。
FAQ
Q: 出荷実績ファイルはいつ作成されますか?
A: 表2「出荷処理」(3)①で“出荷実績ファイルに出力”とあるように、状態を“出荷済み”にしたタイミングで同時に作成されます。
A: 表2「出荷処理」(3)①で“出荷実績ファイルに出力”とあるように、状態を“出荷済み”にしたタイミングで同時に作成されます。
Q: “受注の消込み”はどのファイルを操作していますか?
A: 図2「出荷処理」プロセスには“受注ファイル”が入力として接続されています。受注状況を完了に更新する処理がここで行われます。
A: 図2「出荷処理」プロセスには“受注ファイル”が入力として接続されています。受注状況を完了に更新する処理がここで行われます。
Q: 棚出指示済在庫や棚出実績との違いは?
A: 棚出関連は“棚番別在庫ファイル”で棚単位の物理在庫を管理し、出荷関連は“出荷予定ファイル”で受注単位の出荷ステータスを管理します。
A: 棚出関連は“棚番別在庫ファイル”で棚単位の物理在庫を管理し、出荷関連は“出荷予定ファイル”で受注単位の出荷ステータスを管理します。
関連キーワード: 在庫管理、ステータス更新、ファイル設計、業務フロー
設問3:表2の出荷関連の処理記述書について、(1)、(2)に答えよ。
(2)表2中の(g)に入れる処理内容を,30字以内で述べよ。
模範解答
g:受注ファイルの受注レコードの状態を出荷済みにする。
解説
解答の論理構成
- 【問題文】(5)出荷①
「…受注の消込み、在庫マスタの実在庫、引当済実在庫を更新…」
→ 受注情報を完了(=出荷済み)状態に変更する必要がある。 - 表2「出荷処理」③
①で「(f)の該当する出荷予定レコードの状態を出荷済みに」
②で「在庫マスタ…を更新」
③の(g)はその間に挟まれており、残る“受注の消込み”を実現する処理である。 - 以上より、(g)は「受注ファイルの受注レコードの状態を出荷済みにする。」となる。
誤りやすいポイント
- 出荷予定ファイルと受注ファイルの役割を混同し、同じファイルを二重に更新すると解釈してしまう。
- 「受注の消込み」を“削除”と誤解し、レコード削除や数量を0にするなど不適切な操作を想定してしまう。
- 在庫マスタ更新と受注ファイル更新の順序を取り違え、処理の因果関係を見失う。
FAQ
Q: 「受注の消込み」は必ずステータス更新ですか?
A: はい。【問題文】ではデータを保持しつつ状態だけを変える前提で設計されているため、削除ではなくステータスを「出荷済み」に更新します。
A: はい。【問題文】ではデータを保持しつつ状態だけを変える前提で設計されているため、削除ではなくステータスを「出荷済み」に更新します。
Q: 出荷実績ファイルには受注情報を転記しないのですか?
A: 出荷実績は表2③①で「出荷実績ファイルに出力」済みです。(g)はあくまで受注ファイル側の完了処理を担います。
A: 出荷実績は表2③①で「出荷実績ファイルに出力」済みです。(g)はあくまで受注ファイル側の完了処理を担います。
関連キーワード: 出荷実績、受注管理、ステータス更新、在庫引当、ファイル設計
設問4:
物流センタ新設後は、営業所別の売上集計を行うとき、現状の売上データの集計で発生している、あるデータが発生しなくなる。それは、どのようなデータか。25字以内で述べよ。
模範解答
他営業所に振替計上する出荷手数料分のデータ
解説
解答の論理構成
- 現状の仕組み
- 【問題文】では、営業所間の在庫融通が起こるときに「売上は、受注した営業所への計上が原則であるが、他営業所から出荷した場合は、売上の一部が出荷手数料として、出荷した営業所に振替計上される。」とあります。
- つまり、売上データには「出荷手数料分」の振替伝票が必ず混在します。
- 物流センタ新設後の変更点
- 【問題文】に「新設した物流センタで商品在庫を集中管理し、顧客への出荷は全て物流センタから行う。」とあります。
- 営業所は受注入力のみを行い、出荷は物流センタ単独で処理されるため、営業所間を跨ぐ出荷そのものがなくなります。
- 帳票・会計データへの影響
- 出荷元が常に物流センタに一本化されることで、営業所別売上を集計しても「どの営業所が出荷したか」による手数料振替は不要になります。
- よって、発生しなくなるデータ
- 振替元・振替先を示す「他営業所に振替計上する出荷手数料分のデータ」です。
誤りやすいポイント
- 「営業所在地の売上計上がなくなる」と勘違いする
→ 売上は依然として「受注した営業所」へ計上されます。 - 「物流センタの在庫補充データが不要」と答えてしまう
→ 補充オーダは引き続き必要であり、問題は売上集計時の不要データです。 - 「出荷実績ファイルが不要」と短絡する
→ 出荷実績ファイルは物流センタで必要です。不要になるのは営業所間振替の手数料データのみ。
FAQ
Q: 物流センタが出荷しても営業所の売上になるのはなぜですか?
A: 営業所は顧客窓口であり、受注情報を保持しているため、売上は受注した営業所へそのまま計上される運用が維持されます。
A: 営業所は顧客窓口であり、受注情報を保持しているため、売上は受注した営業所へそのまま計上される運用が維持されます。
Q: 物流センタに出荷手数料は発生しないのですか?
A: 物流センタは社内組織であり営業所ではないため、営業所間のような売上振替は不要です。物流費はセンタ運営費として別勘定で管理されます。
A: 物流センタは社内組織であり営業所ではないため、営業所間のような売上振替は不要です。物流費はセンタ運営費として別勘定で管理されます。
関連キーワード: 在庫引当て、売上計上、振替計上、集中在庫管理


