戦国IT - 情報処理技術者試験の過去問対策サイト
ブログお知らせお問い合わせ料金プラン

システムアーキテクト 2009年 午後1 問01


販売管理システムに関する次の記述を読んで、設問1~4に答えよ。

 A社は、缶入りの飲料を製造・販売している。商品の大部分は自動販売機(以下、自販機という)で販売されるので、自販機向けの販売管理システム(以下、A社販売管理システムという)を構築し、運用している。このたび、A社販売管理システムの機能強化を図ることにした。   〔A社の概要〕  (1)営業所が全国に300か所あり、各営業所には商品倉庫が一つずつある。  (2)各営業所には、約10名の営業担当者が所属しており、各営業担当者にトラック1台が割り当てられている。  (3)各営業担当者は、ハンディターミナル(以下、HTという)を1台ずつ所持する。各営業担当者は、約200台の自販機を担当し、毎日数回から毎月1回の頻度で担当の自販機を巡回して、売上金の回収や商品の補充などを行う。  (4)自販機は、商品を格納する縦型のストッカ(以下、コラムという)を30~40個内蔵しており、自販機前面の操作ボタンと連動して商品を販売する。  (5)工場での商品の1回の製造単位をロットといい、1ロット当たりの商品数量は数十万本である。ロットごとに一意のロット番号が付与される。ロット番号、製造年月日、製造工場番号、商品コード、商品賞味期限、原材料番号などは生産管理システムで管理されている。     〔販売管理業務とA社販売管理システムの概要〕  (1)A社販売管理システムの構成   ①A社販売管理システムは、サーバ、各営業所に設置されるWeb端末及びHTから構成される。HTはサーバや自販機と通信をすることができる。   ②サーバ及びHTはファイルを保持しており、ファイルは、Web端末やHTを介した入力、サーバとHTとの通信、HTと自販機との通信、夜間バッチ処理で更新される。  (2)営業担当者の業務   ①ダウンロード処理:自販機の巡回出発前に、当日の巡回に必要なファイルを、サーバからHTにダウンロードする。   ②売上処理:自販機に到着後、HTと自販機を通信させ、自販機コードと、コラムごとにコラム番号、販売単価及び売上数のデータを取得する。HTのアプリケーションは、販売単価及び売上数から売上金額を計算し、取得及び計算したデータをHTに保存する。その後、売上金を回収する。   ③補充処理:HTのアプリケーションで、売上処理で取得した売上数を基にコラムごとの最適補充数を計算する。それを参考に商品を補充し、補充数をHTに入力する。HTのアプリケーションは、HT内のファイルの情報、売上数及び補充数から、コラムごとの在庫数及びトラックの商品ごとの在庫数を計算し、入力及び計算したデータをHTに保存する。さらに、自販機内のコラムごとの売上数をゼロにする。   ④トラック棚卸処理:自販機の巡回終了後、営業所に戻り、トラックの商品の棚卸しを行う。棚卸しでは、トラックコード、商品コード及び実地棚卸数をHTに入力する。HTのアプリケーションは、トラック在庫マスタの在庫数を実地棚卸数で更新する。   ⑤積込積降処理:棚卸結果などから次の巡回に必要な商品をトラックに積み込み、倉庫コード、トラックコード、商品コード及び積込数をHTに入力する。また、不要な商品はトラックから倉庫に降ろし、倉庫コード、トラックコード、商品コード及び積降数をHTに入力する。HTのアプリケーションは、HT内のファイルの情報及び入力されたデータから、トラックの商品ごとの在庫数を計算し、入力及び計算したデータをHTに保存する。   ⑥アップロード処理:積込積降処理終了後、HT内のファイルをサーバにアップロードする。サーバでは、該当するファイルの該当するレコードを更新する。  (3)営業所の業務(倉庫担当者がWeb端末で行う)   ①入庫処理:工場から倉庫に商品が届いた際、検品後に登録する。   ②移動出庫処理:ほかの倉庫に商品を移動する際、移動元倉庫で登録する。   ③移動入庫処理:ほかの倉庫から商品が届いた際、移動先倉庫で検品後に登録する。   ④返品出庫処理:商品を工場に返品する際、登録する。   ⑤倉庫在庫確定処理:HTから当日アップロードされたデータを入力として、倉庫在庫マスタを更新し、当日の在庫数を確定する。夜間バッチ処理で行われる。     主要なファイルの一覧を表1に、ダウンロード処理とアップロード処理を除くHTのアプリケーションの処理のDFDを図に示す。図は作成途中であり、データのうちHT番号と各伝票番号は省略している。  
システムアーキテクト試験(平成21年度 午後1 問1 表1) ↩設問2(1) ↩設問3(2)
  システムアーキテクト試験(平成21年度 午後1 問1 図1)
〔機能強化〕  次の二つの対応を行うことにした。  (1)ほかの営業担当者が担当する自販機への巡回対応   現在、1日のうちに複数の営業担当者が同一自販機を巡回することはない。しかし、今後は巡回する可能性があり、問題なく対応できるようにする。そのため、サーバのコラムマスタの在庫数を、HT内のコラムマスタのアップロード時にHT内に保存されている値で更新するのではなく、サーバで計算し直すことを考えている。  (2)商品賞味期限の一覧表出力機能   自販機内の商品は、通常1か月以内に販売される。したがって、トラックや倉庫の在庫の賞味期限が2か月以上あれば、賞味期限に余裕をもった商品を販売できる。   生産管理システムからロットごとの商品賞味期限を入手し、その商品賞味期限が、本日から2か月以内に迫っているロットが、どの倉庫、どのトラックに存在するかを調べ、一覧表として出力する。この機能の実現のためには、ロット番号を関連するファイルに記録する必要がある。ロット番号を属性として追加するファイルと、そのロット番号を利用する処理との関連の一部を抜き出して、表2に整理した。

設問1:HTのアプリケーションについて、(1)~(3)に答えよ。

問題文を見る
(1)図中の補充プロセスは売上プロセスの後に実行される。そのように設計した理由を30字以内で述べよ。

模範解答

補充プロセスの処理では売上数を必要とするから

解説

解答の論理構成

  1. 売上プロセスの役割を確認
    問題文(2)②に「自販機コードと、コラムごとに…売上数のデータを取得する」とあり、ここで当日の「売上数」が確定します。
  2. 補充プロセスの入力を確認
    同(2)③には「売上処理で取得した売上数を基にコラムごとの最適補充数を計算する」と記載されています。
  3. データ依存関係の導出
    補充プロセスは売上数という計算済みデータを前提に動くため、売上プロセスより前に置くと必要データが存在しません。
  4. 結論
    したがって「補充プロセスは売上プロセスの後」となる理由は「補充で売上数を参照する」ことに尽きます。

誤りやすいポイント

  • 「在庫数更新が後だから」という表面的理由だけを書くと、売上数依存を示せず減点対象。
  • プロセスの並列実行可否を論じてしまい、本質のデータ依存関係を外す。
  • 補充プロセスが売上数を“更新”すると誤解し、順序を逆転させてしまう。

FAQ

Q: 売上プロセスと補充プロセスを一体化すれば順序問題は解消しますか?
A: 一体化は可能ですが、職務分担や改修時の影響範囲を考えると別プロセスのまま順序制御する方が保守性に優れます。
Q: 売上数以外に補充プロセスが参照するデータは?
A: 問題文には「HT内のファイルの情報、売上数及び補充数から…在庫数を計算」とあるため、ローカル在庫情報も参照しますが、順序の決定要因はあくまで売上数です。
Q: 売上数をサーバへ直送し即時補充計算する方法は?
A: リアルタイム計算には通信環境の制約とシステム改修コストが伴うため、現行のHT内処理+巡回終了後アップロード方式が採用されています。

関連キーワード: DFD, データフロー、プロセス順序、補充数計算

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問1:HTのアプリケーションについて、(1)~(3)に答えよ。

問題文を見る
(2)補充処理で、自販機内のコラムごとの売上数をゼロにしている理由を、30字以内で述べよ。

模範解答

売上数をゼロにしないと売上数が累積されてしまうから

解説

解答の論理構成

  1. 売上処理の流れ
    • 【問題文】「自販機に到着後、HTと自販機を通させ、自販機コードと、コラムごとに…売上数のデータを取得する。」
    • 同段落で「売上金額を計算し、取得及び計算したデータをHTに保存する。」
      すなわち、巡回時点の売上数を読み取り計算します。
  2. 補充処理の最後の操作
    • 【問題文】「さらに、自販機内のコラムごとの売上数をゼロにする。」
      ここでカウンタを初期化している事実が明記されています。
  3. 初期化の必要性
    • 次の巡回では再び「売上数」を読み取り計算するため、前回分を残しておくと「累積」され実際の当日売上を超えてしまいます。
    • 逆にゼロにしておけば、次回は当該巡回以降の純粋な増分だけが取得できます。
  4. よって「累積防止」がゼロクリアの直接目的となります。

誤りやすいポイント

  • 「在庫数の初期化」と取り違え、売上数でなく在庫補充後の在庫リセットと誤解する。
  • 「売上金額」までゼロにすると解釈し、会計データ消失と混同する。
  • 「翌日の締め処理で自動的にクリアされる」と思い込み、HT側のリアルタイム処理を軽視する。

FAQ

Q: 在庫数はゼロにしないのですか?
A: 在庫数は補充後に「コラムごとの在庫数」を再計算して保存します。ゼロにするのは売上数だけです。
Q: 夜間バッチで売上数をまとめてリセットしてもよいのでは?
A: 巡回は日中に複数回あり得るため、巡回ごとにリセットしないと同日中の二重計上が発生します。
Q: 売上数を差分計算する方式に変えればゼロクリアは不要?
A: 自販機の仕様が「累積カウンタ」である場合、HT側で差分を取るよりゼロクリアの方が確実かつ処理が簡単です。

関連キーワード: DFD, 在庫管理、データ整合性、累積カウンタ、初期化

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問1:HTのアプリケーションについて、(1)~(3)に答えよ。

問題文を見る
(3)図のDFDを完成させよ。図のDFDの表記例に倣って、プロセスを一つ、データフローを三つ、データとともに追記すること。ただし、データは属性名で記述し、ほかの部分と同様、HT番号と各伝票番号は省略し、その他の属性は省略しない。 なお、図に〔機能強化〕は反映させない。

模範解答

システムアーキテクト試験(平成21年度 午後1 問1 設問01-03解答)

解説

解答の論理構成

  1. 追加すべきプロセス
    【問題文】の営業担当者の業務に
    "④トラック棚卸処理:自販機の巡回終了後、営業所に戻り、トラックの商品の棚卸しを行う。"
    とあります。図のDFDには、営業担当者から「トラックコード、商品コード、実地棚卸数」の矢印と、商品マスタから「商品マスタ情報」の矢印がすでに描かれていますが、その行き先のプロセスがありません。そこでプロセス「トラック棚卸」を追加します。
  2. 追加すべきデータフロー その1(トラック在庫マスタの更新)
    同じ段落に
    "HTのアプリケーションは、トラック在庫マスタの在庫数を実地棚卸数で更新する。"
    とあります。表2でもトラック棚卸処理(g)はトラック在庫マスタ(H)を U(参照して更新)しています。表1のトラック在庫マスタの属性から
    「トラックコード、商品コード、在庫数」
    のデータフローを、トラック棚卸 → トラック在庫マスタ に描きます。
  3. 追加すべきデータフロー その2(トラック棚卸の登録)
    棚卸結果のヘッダは表1の
    "トラック棚卸 HT番号、トラック棚卸伝票番号、棚卸日、トラックコード"
    です。設問に「HT番号と各伝票番号は省略し、その他の属性は省略しない」とあるので、トラック棚卸 → トラック棚卸 には
    「棚卸日、トラックコード」
    を描きます。
  4. 追加すべきデータフロー その3(トラック棚卸明細の登録)
    明細は表1の
    "トラック棚卸明細 HT番号、トラック棚卸伝票番号、商品コード、実地棚卸数"
    です。表2でもトラック棚卸明細(H)は (g) 列で C(登録)です。HT番号・伝票番号を省略して、トラック棚卸 → トラック棚卸明細 に
    「商品コード、実地棚卸数」
    を描きます。
  5. まとめ
    ・プロセス1つ:トラック棚卸
    ・データフロー3つ:
    ①トラック棚卸→トラック在庫マスタ「トラックコード、商品コード、在庫数」
    ②トラック棚卸→トラック棚卸「棚卸日、トラックコード」
    ③トラック棚卸→トラック棚卸明細「商品コード、実地棚卸数」
    これで「プロセスを一つ、データフローを三つ」追記せよという指示を満たします。

誤りやすいポイント

  • 営業担当者からトラック棚卸への入力フローを、追加する三つのうちの一つに数えてしまう。この矢印は元の図にすでにあります。
  • トラック在庫マスタの更新を描き忘れる。問題文の「トラック在庫マスタの在庫数を実地棚卸数で更新する」が根拠です。
  • HT番号・各伝票番号をデータフローに書いてしまう。設問の「HT番号と各伝票番号は省略し」を見落とすと減点になります。
  • 明細(トラック棚卸明細)とヘッダ(トラック棚卸)を区別せず、どちらか一方しか描かない。

FAQ

Q: トラック在庫マスタへのフローのデータは「実地棚卸数」ではないのですか?
A: 更新されるのはトラック在庫マスタの「在庫数」です。図のほかの部分と同じく、データストアの属性名(トラックコード、商品コード、在庫数)で書きます。
Q: 棚卸日は営業担当者からの入力に含まれていませんが、どこから来るのですか?
A: HTのアプリケーションが当日の日付を付けて登録すると考えます。入力の矢印はすでにあるので、描き足すのはトラック棚卸への出力側だけです。
Q: 明細側にトラックコードを入れても良い?
A: 表1のトラック棚卸明細の属性にないため不可です。「商品コード、実地棚卸数」だけにします。

関連キーワード: DFD, データフロー, データストア, 棚卸処理, 在庫マスタ更新

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問2:倉庫在庫確定処理について、(1)、(2)に答えよ。

問題文を見る
(1)この処理の入力ファイルを、表1中のファイル名を用いてすべて答えよ。

模範解答

積込積降、積込積降明細

解説

解答の論理構成

  1. 倉庫在庫確定処理の目的
    「倉庫在庫マスタ」を当日分で確定させるバッチ処理であり、入力は “当日HTからアップロードされたデータ” と明示されています。
  2. 当日HTからアップロードされるファイル
    • 巡回終了後に行う「⑥アップロード処理」でサーバへ送信されるファイルは、「積込積降」と「積込積降明細」であると【問題文】が示しています。
  3. サーバ専用ファイルは対象外
    「入出庫明細」や「倉庫在庫マスタ」そのものはサーバに常駐し、アップロード対象ではないため入力ファイルには該当しません。
  4. よって入力ファイルは
    「積込積降、積込積降明細」となります。

誤りやすいポイント

  • 「入出庫明細」や「入出庫」と混同してしまう
    → 自動倉庫間移動や返品時に使うサーバ側の伝票であり、HTアップロードの対象外です。
  • 「トラック棚卸明細」もアップロードされると勘違い
    → 棚卸はトラック在庫を更新するための処理で、倉庫在庫には直接関与しません。
  • ファイル名の入力漏れ
    → 「積込積降」と「積込積降明細」はセットで扱われるため両方を書きます。

FAQ

Q: なぜ「積込積降明細」だけでは不十分なのですか?
A: 「積込積降」で日付・倉庫コード・トラックコードなどヘッダ情報を持ち、「積込積降明細」で商品・数量を持つため、両方揃って初めて在庫更新ロジックが成り立ちます。
Q: 倉庫在庫確定処理はいつ実行されますか?
A: 【問題文】に「夜間バッチ処理で行われる」とある通り、営業日の終了後にまとめて実行されます。
Q: 入出庫に関するデータは倉庫在庫確定処理で使わないのですか?
A: 入出庫系は営業所のWeb端末で登録直後に「倉庫在庫マスタ」を更新しているため、確定処理の追加入力対象になりません。

関連キーワード: ファイルアップロード、在庫マスタ更新、バッチ処理、データフロー、ハンディターミナル

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問2:倉庫在庫確定処理について、(1)、(2)に答えよ。

問題文を見る
(2)倉庫の在庫を確定するためにこの処理が必要な理由を、35字以内で述べよ。

模範解答

積込み・積降ろしした分を倉庫在庫に反映させる必要があるから

解説

解答の導き方

  1. まず設問が問う処理の定義を問題文で確かめます。問題文に「倉庫在庫確定処理:HTから当日アップロードされたデータを入力として、倉庫在庫マスタを更新し、当日の在庫数を確定する。夜間バッチ処理で行われる。」とあります。これから入力が「HTから当日アップロードされたデータ」で、出力が「倉庫在庫マスタの更新(当日の在庫数の確定)」であることが分かります。
  2. 次に倉庫在庫マスタの位置づけを確認します。表1の注に「注:※ は、ファイルがサーバだけに存在することを示し、無印はサーバ及びHT上に存在することを示す。」とあり、表1では「※ 倉庫在庫マスタ」が示されています。つまり倉庫在庫はサーバ側で一元管理されるデータであり、最終的な在庫数はサーバ上で確定する必要があります。
  3. HT側の処理とサーバへの反映の流れを確認します。問題文に「アップロード処理:積込積降処理終了後、HT内のファイルをサーバにアップロードする。サーバでは、該当するファイルの該当するレコードを更新する。」とあります。各営業担当者は巡回や補充、積込積降、棚卸などでHTにデータを作成し、それをサーバにアップロードします。
  4. どの処理が倉庫在庫に影響し、どこで反映されるかを見ます。営業所業務の「①入庫処理」「②移動出庫処理」「③移動入庫処理」「④返品出庫処理」は営業所のWeb端末からサーバに登録する処理で、表2の b〜e 列のとおり、登録時に倉庫在庫マスタ(S)を直接更新しています(CU または U)。一方、営業担当者が倉庫でトラックに積み込み・積み降ろしした分は、HTの積込積降処理で積込積降明細(H)に記録されるだけで(表2の a 列)、サーバの倉庫在庫マスタはまだ変わっていません。
  5. 以上をつなげると、HTからアップロードされた積込積降・積込積降明細(設問2(1))を入力にして、積込み・積降ろしした分をサーバの倉庫在庫マスタに反映する処理が別に必要になります(表2の f 列:積込積降明細(S)を R、倉庫在庫マスタ(S)を U)。これが倉庫在庫確定処理が存在する理由で、「積込み・積降ろしした分を倉庫在庫に反映させる必要があるから」となります。

誤りやすいポイント

  • 入庫処理・移動入庫処理・移動出庫処理・返品出庫処理の分も倉庫在庫確定処理で反映すると考える誤り。これらはサーバ上で登録した時点で倉庫在庫マスタを直接更新しています(表2の b〜e 列)。倉庫在庫確定処理が反映するのは、HTからアップロードされた積込積降・積込積降明細の分です(設問2(1))。
  • HTのアップロード処理と倉庫在庫確定処理を混同する誤り。アップロードは「該当するファイルの該当するレコードを更新する」までで、倉庫在庫の最終確定は「HTから当日アップロードされたデータを入力として、倉庫在庫マスタを更新し、当日の在庫数を確定する」夜間バッチによる処理で行われます。
  • 倉庫在庫マスタがHT側にも存在すると誤認する誤り。表1の注により「倉庫在庫マスタ」はサーバだけに存在する(※)ことを押さえておく必要があります。

FAQ

Q: HTがアップロードすれば倉庫在庫マスタの数が即時確定しますか?
A: HTのアップロードで該当ファイルのサーバ側レコードは更新されますが、問題文の定義どおり「倉庫在庫確定処理」はHTから当日アップロードされたデータを入力として夜間バッチで倉庫在庫マスタを更新し「当日の在庫数を確定する」処理です。アップロードと在庫の最終確定は役割が分かれています。
Q: なぜ在庫確定を夜間バッチで行うのですか?
A: 営業担当者ごとのHTのアップロードは、巡回終了後にばらばらの時刻で行われます。当日分の積込積降のアップロードがそろってから一括で反映するために、夜間バッチで行います(問題文に「夜間バッチ処理で行われる」と明記されています)。
Q: トラックの棚卸結果は倉庫在庫にどう影響しますか?
A: 影響しません。トラック棚卸処理はHT上のトラック在庫マスタを実地棚卸数で更新する処理で(表2の g 列)、倉庫在庫マスタは扱いません。

関連キーワード: 在庫管理、バッチ処理、マスタファイル、アップロード/ダウンロード、データ整合性

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問3:ほかの営業担当者が担当する自販機への巡回対応について、(1)、(2)に答えよ。

問題文を見る
(1)サーバのコラムマスタの在庫数を計算し直す理由を、40字以内で述べよ。

模範解答

在庫数は巡回したすべてのHT内の売上と補充の情報から計算する必要があるから

解説

解答の論理構成

  1. 状況変化の把握
    • 【問題文】「現在、1日のうちに複数の営業担当者が同一自販機を巡回することはない。しかし、今後は巡回する可能性があり」とある。
    • つまり同一自販機に対して複数HTから売上・補充データが送られる前提に変わる。
  2. 既存方式の問題点
    • 「サーバのコラムマスタの在庫数を…HT内に保存されている値で更新する」とある。
    • 単純上書きでは、後にアップロードしたHTが先のHTの在庫計算を潰してしまう。
  3. 必要となる対策
    • 各HTが送る「売上数」「補充数」を合算し、「コラムごとの在庫数」を再計算すれば整合性が保たれる。
    • これが「サーバで計算し直す理由」であり、模範解答の「在庫数は巡回したすべてのHT内の売上と補充の情報から計算する必要があるから」に一致する。

誤りやすいポイント

  • 「ロット番号追加」や「賞味期限一覧」と混同し、理由に賞味期限を絡めてしまう。
  • 「複数自販機」ではなく「複数HT」が問題である点を見落とす。
  • 「上書き防止」ではなく「レスポンス向上」など枝葉の利点を挙げてしまう。

FAQ

Q: 単純に最後にアップロードしたHTの値を採用してはいけませんか?
A: 先に巡回したHTの売上・補充実績が消え、実在庫より多い在庫数が計上される恐れがあります。
Q: サーバ側での再計算はどのタイミングで行うのですか?
A: 各HTからのアップロード時点でバッチまたはトランザクション処理として合算・再計算する方式が一般的です。
Q: 巡回順序をシステムで管理すれば再計算は不要ですか?
A: 物理的に巡回順序を確定できない場合や緊急対応で順序が変わる場合があるため、順序管理だけでは整合性が保証できません。

関連キーワード: 在庫管理、マスタ更新、データ整合性、同期処理、集計ロジック

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

設問3:ほかの営業担当者が担当する自販機への巡回対応について、(1)、(2)に答えよ。

問題文を見る
(2)(1)で在庫数を計算し直す際に、サーバでコラムマスタの在庫数を計算するのに必要なHTのファイル名を、表1中から二つ選べ。

模範解答

①・売上補充 ②・売上補充明細

解説

解答の論理構成

  1. 目的確認
    問題文に「サーバのコラムマスタの在庫数を、HT内のコラムマスタのアップロード時にHT内に保存されている値で更新するのではなく、サーバで計算し直す」とあります。つまりサーバは“変化量”を受け取り、現在高を自力で再構築します。
  2. 変化量を含むHTファイルを列挙
    表1より、売上を保持するのは「売上補充明細」(属性:売上金額、売上数、補充数)。そのヘッダ情報をまとめるのが「売上補充」(属性:売上日、自販機コード、回収金額)。
  3. 他候補との比較
    • 「トラック在庫マスタ」はトラック全体の在庫数であり、自販機内在庫とは直接関係しません。
    • 「トラック棚卸明細」「積込積降明細」はトラックと倉庫の移動に関するデータであり、コラム在庫計算には不要です。
  4. 結論
    在庫数を算出する最小限のHTファイルは「売上補充」と「売上補充明細」の二つになります。

誤りやすいポイント

  • トラック関連ファイルを選択してしまう
    自販機コラム在庫の更新対象はあくまで自販機内の売上と補充。トラックの在庫増減は計算に直接使いません。
  • ファイルの所在を見落とす
    表1の注にある「無印はサーバ及びHT上に存在」を読み飛ばすと、アップロード対象を取り違える危険があります。
  • 「売上補充明細」だけを選んでしまう
    明細行だけでは日付・自販機コードが欠けるため、サーバ側で正しく在庫をひも付けできません。ヘッダ「売上補充」も必須です。

FAQ

Q: 「売上補充」と「売上補充明細」は内容が重複していませんか?
A: ヘッダと明細の関係です。ヘッダが伝票単位の共通情報(売上日、自販機コード 等)を、明細がコラム単位の数量を持ちます。
Q: コラム在庫の再計算で「積込積降明細」を参照しない理由は?
A: 積込積降はトラックと倉庫の在庫変動であり、自販機のコラム在庫には影響を与えないためです。
Q: 他営業担当者が同一自販機を巡回すると何が問題になるのですか?
A: 先に巡回した営業担当者の売上・補充を後から巡回した担当者が上書きするリスクが発生します。サーバ側で累積計算することで競合を防ぎます。

関連キーワード: 在庫更新、売上データ、補充データ、ファイル同期、データモデル

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

表2中の(a)~(g)に入れる適切な字句を、〔販売管理業務とA社販売管理システムの概要〕内の処理名を用いて答えよ。 (b, cは順不同、d, eは順不同)

模範解答

a:積込積降処理 b:入庫処理 c:移動入庫処理 d:返品出庫処理 e:移動出庫処理 f:倉庫在庫確定処理 g:トラック棚卸処理

解説

解答の導き方

最終解答は次の通りです。
a:積込積降処理
b:入庫処理
c:移動入庫処理
d:返品出庫処理
e:移動出庫処理
f:倉庫在庫確定処理
g:トラック棚卸処理
導き方(表2の記号と業務説明を照合して決めます)。
  1. 前提:表2の注記より「C:登録、R:参照だけ、U:参照して更新」を意味します。まず各列に付されたC/U/Rの意味を確認します。
  2. (a) の決定
    • 表2で、積込積降明細(H)にC、トラック在庫マスタ(H)にCUがあることから、該当処理はHT上で積込積降明細を登録し、トラック在庫を作成/更新する処理です。
    • 業務説明で「倉庫コード、トラックコード、商品コード及び積込数をHTに入力する」とある処理は積込/降しの操作をHTに記録し、HT内のトラック在庫を更新します。したがって (a) は積込積降処理です。
  3. (b),(c) の決定(順不同可)
    • 表2で、入出庫明細(S)にC、倉庫在庫マスタ(S)にCUがある列は、サーバ上に入出庫伝票を登録しつつ倉庫在庫マスタを作成/更新する処理です。
    • 業務説明の「入庫処理:工場から倉庫に商品が届いた際、検品後に登録する。」および「移動入庫処理:ほかの倉庫から商品が届いた際、移動先倉庫で検品後に登録する。」はいずれもサーバ側で入出庫登録を行い倉庫在庫を増加させる処理に該当します。よって (b),(c) は入庫処理と移動入庫処理(順不同)です。
  4. (d),(e) の決定(順不同可)
    • 表2で、入出庫明細(S)にC、倉庫在庫マスタ(S)にUがある列は、入出庫伝票を登録し倉庫在庫を参照して更新(減少)する処理を示します。
    • 業務説明の「移動出庫処理:ほかの倉庫に商品を移動する際、移動元倉庫で登録する。」と「返品出庫処理:商品を工場に返品する際、登録する。」はどちらも出庫の登録を行い倉庫在庫を減らす処理です。したがって (d),(e) は返品出庫処理と移動出庫処理(順不同)です。ここではd:返品出庫処理、e:移動出庫処理 とします。
  5. (f) の決定
    • 表2で (f) 列は、倉庫在庫マスタ(S)に U、積込積降明細(S)に R があります。HTからサーバにアップロードされた積込積降明細を参照して、サーバ上の倉庫在庫マスタを更新する処理です。
    • 業務説明に「倉庫在庫確定処理:HTから当日アップロードされたデータを入力として、倉庫在庫マスタを更新し、当日の在庫数を確定する。」とあるため、(f) は倉庫在庫確定処理です。
  6. (g) の決定
    • 表2で (g) 列は、トラック在庫マスタ(H)に U、トラック棚卸明細(H)に C があります。HT上でトラック棚卸明細を登録し、トラック在庫マスタを更新する処理です。
    • 業務説明に「トラック棚卸処理:…棚卸しでは、トラックコード、商品コード及び実地棚卸数をHTに入力する。HTのアプリケーションは、トラック在庫マスタの在庫数を実地棚卸数で更新する。」とあるため、(g) はトラック棚卸処理です。
以上よりa〜gの割当は冒頭の通りになります。

誤りやすいポイント

  • 表のC/R/Uの意味を誤解すると間違えます。Cは「登録」、Uは「参照して更新」、Rは「参照だけ」です。
  • サーバ上ファイル(S)とHT上ファイル(H)を混同すると、どの処理がHT側で行われるか(積込・棚卸など)を誤認します。
  • 積込積降明細には(H)と(S)の2行がある点を見落としやすいです。HT上の積込積降明細(H)を登録(C)するのが積込積降処理(a)、アップロード後のサーバ上の積込積降明細(S)を参照(R)するのが倉庫在庫確定処理(f)です。トラック棚卸明細(H)を登録(C)するのはトラック棚卸処理(g)です。
  • (b,c) と (d,e) はそれぞれ「順不同」と明示されているため、どちらを先に書くかで得点が変わらない設問です。順序にこだわらないで、ファイル操作の意味で対応付けることが重要です。
  • 問題文中の業務説明の語句は正確に使うこと。プロセス名は問題文と同一表記で記述してください。

FAQ

Q: 表2で同じ列にCUとあるとき、CとUのどちらが根拠になりますか?
A: どちらも根拠です。Cは該当処理がそのファイルに登録(伝票の作成など)を行うことを、Uは参照したうえで更新を行うことを示します。両方ある場合は、登録と更新の両方を行う処理と判断します。
Q: なぜ (f) をトラック棚卸処理ではなく倉庫在庫確定処理とするのですか?
A: 表2で (f) 列は倉庫在庫マスタ(S)に U、積込積降明細(S)に R があり、アップロードされた積込積降明細を参照してサーバ上の倉庫在庫を更新する処理を示しています。問題文の「倉庫在庫確定処理:HTから当日アップロードされたデータを入力として、倉庫在庫マスタを更新し、当日の在庫数を確定する。」と一致します。トラック棚卸処理は、トラック棚卸明細(H)を登録(C)しトラック在庫マスタ(H)を更新(U)する (g) 列に対応します。
Q: b,cとd,eの順序が指定されていない理由は何ですか?
A: 表2の記号分布がbとc(入庫系)が同じパターンで、dとe(出庫系)も同じパターンになっているため、どちらの列に入れても表2の指示と整合します。重要なのは各列が示すファイル操作(入出庫明細の登録、倉庫在庫の更新)と業務内容を照合することです。

関連キーワード: DFD、バッチ処理、在庫管理、トランザクション制御、マスタ設計

解説を読んでも分からないところは、AIに質問できます。 この問題の本文と解説をふまえて答えます。

この設問をAIに質問する

クイズモードで開きます(AIへの質問は無料の会員登録で使えます)

戦国ITクイズ機能

\ せっかくなら /

システムアーキテクトを
クイズ形式で学習しませんか?

クイズ画面へ遷移する→

すぐに利用可能!

©︎2026 情報処理技術者試験対策アプリ

このサイトについてブログプライバシーポリシー利用規約特商法表記開発者について