システムアーキテクト 2016年 秋期 午後I 問題

共通の文章

仕入れ納品システムの変更に関する次の記述を読んで,設問1こ3に答えよ。 A社は,約500店舗を展開する中堅コンビニエンスストアである。このたび,他社 との差別化を図るために,精肉を販売することを決定し,A社の仕入れ・納品の仕組 み,及び取引先であるB社の商品加工ラインの仕組みを変更することになった。 [現在の業務及びシステムの概要〕 A社では,商品を仕入れる取引先は,商品によって一意に決まっている。4A社が取 引先から仕入れる価格を原価,A社が店舗で販売する価格を売価という。また,商品 1個当たりの原価を原単価,商品1個当たりの売価を売単価という。これらの単価及 び取引先は商品マスタに登録されている。取引先での処理に必要なマスタ情報は,A 社から取引先に送信され,共有されている。 現在の仕入れ納品システム(以下,現行システムという)を用いた,注文から検品 に至る各業務の流れは次のとおりである。 (1)注文業務 ・店舗では,発注用端末を使って,商品ごとに数量を入力して発注データを作成する。 ・店舗から本部への発注データの送信は随時可能である。本部では,毎日,発注デー タの締め処理を行い,商品マスタを用いて,それぞれの商品に対応した取引先及び 納品予定日を決定して,注文ファイルに登録する。また,このとき,取引先ごとに 商品別の合計数量を求めて,注文速報データを作成し,取引先に送信する。取引先 は,注文速報データを基に,商品をそろえる。生鮮食品については,毎日8時に発 注データを締めて取引先に送信し,当日17時までに,店舗に納品してもらう。 (2)納品業務 ・本部では,注文ファイルの注文データから,店番,納品予定日,取引先コードごと に,納品伝票データを作成する。生鮮食品については締め処理を行った当日が納品 予定日になる。伝票番号は,伝票番号マスタに店舗別に格納されている最終伝票番 号に1を加算して付与し,さらに,商品コード単位に行番号を付与した明細行を作 り,納品明細データを作成する。1伝票には明細が複数行表示できるが,明細行が 1伝票に収まらない場合は,伝票番号に1を加算して次の納品伝票データを作成し た後で,納品明細データを作成する。1店舗の処理が終了すると,終了時の伝票番 as ff= 号を伝票番号マスタの最終伝票番号に格納する。 ・納品伝票ファイル及び納品明細ファイルから取引先ごとに抽出したデータを,当該 取引先に送信し,取引先では,これらのデータを使って納品伝票を印刷する。 ・取引先では,納品伝票に記載された商品を記載された数量だけピッキングし,納品 伝票を付けて出荷し,店舗に納品する。 (3)検品業務 ・店舗では,商品の検品を行い,検品データを本部に送信する。A社では商品が発注 どおりに納品される確率が99.9%を超えているので,通常は,修正なしの情報をセ A R、-ー. 1ットして,検品データだけを本部に送信する。検品時に納品伝票と異なる数量が納 品された場合は,修正ありの情報をセットして検品データを本部に送信するととも に,検品差異ゲータを本部に送信する。商品が納品されなかった場合は,実納品数 量に0をセットした検品差異データを送信する。 ・本部では,納品伝票データ,納品明細データ,検品データ及び検品差異デゲータを使 って納品金額を決定し,買掛金システムに渡す買掛金合計データ及び買掛金明細デ —4を作成する。 現行システムの主要ファイルを表1に示す。 表1現行システムの主要ファイル 主な属性(下線はキーを示す) 店番,商品コード,作成日時,Bulk 店番,商品コード,HEB,納品予定日,取引先コード,Bok 取引先コード,商品コード,発注上納品予定日,数量 店番,GES,発注日,納品予定日,取引先コード,取引先名,原価合計売価合計,納品日 店番,伝票番号,納品日,修正有無 店番,GRBs,GES,実納品数量 商品コード,適用開始日,適用終了日,商品名取引先コード,原単価,売単価,消旨期限 店番,店舗名。住所,電話番号 取引先コード,取引先名,住所,電話番号,支払条件,口座情報 GRE,取引先コード,納各日原価合計 店番,伝番号,GES,取引先コード,納品日,商品コード,数量,原価 ーー3に 〔変更の概要〕 これまでA社で扱ってきた商品は,商品ごとに原単価,売単価が一律に決まる商品 CAR,定貫商品という)だけであった。しかし,新たに扱う精肉については,100 グラム当たりの単価は決まっているが,個包装ごとに内容量及び販売価格が異なる商 品(以下,不定貫商品という)になる。 A社で扱つている肉類の商品は,取引先であるB社が購入,加工,GR,店舗別ピ ッキング及び配送を行っている。B社は,A社以外とも取引を行っており,地元のス ーパマーケットには不定貫商品も納品している。 A社の情報システム部に所属するC Rik,次のような変更を行うことにした。 ・精肉の商品には,大パックは300グラム,小パックは100グラムという目安の重量 を設け,商品マスタに,大パック,小パックを別々の商品として登録する。 ・商品マスタで,不定貫商品を取り扱うようにするために,ある属性を新たに追加す る。また,既存の属性の二つについて,現在と別の意味をもたせる。 ・B社では,納品明細データを基に,後述する計量値付機を使って,包装,HH,値 札発行,値札貼付を行い,納品伝票データ及び納品明細データを更新する。 ・B社は,更新した納品伝票データ及び納品明細データを用いて納品伝票を印刷する とともに,納品伝票データ及び納品明細データをA社に送信する。 ・A社の本部では,B社から送信されてきた納品伝票データ及び納品明細データで, 本部のファイルを更新する。 [B社の商品加工ラインでの作業の概要と変更要件〕 B社では,商品加工ラインで,商品の加工,包装,値札発行,値札貼付,店舗別ピ ッキングを行っている。値札には,商品名の他,消費期限,売価,税込売価及びバー コードを印字する。バーコードには,商品コード及び原価・売価情報を含める。 現在,A社向けには,加工肉類などの定貫商品だけを扱っつている。本部から送られ てきた注文速報データを基に,値札発行機で,商品ごとに,当日A社から発注された 数量分の枚数の値札を発行し,手作業で商品に貼付している。その後,店舗別に,値 札が貼付された商品を,納品伝票に記載された数量分ピッキングしている。 B社では不定貫商品の加工に当たり,現在,他社に納品している不定貫商品で用い ている計量値付機を使用することにした。計量値付機とは,パックした商品をベルト ee コンベアで流し,量り部分で計量し,それを基に値札を発行し,値札を自動貼付する 機械である。不定侍商品の値札には,従来のA社向け定貫商品の値札に印字している 項目に加え,販売する店舗の店舗名,100グラム当たりの金額,内容量を印字する。 PCで受信した納品明細データを計量値付機に送り,計量結果を反映させた納品明 細データを送り返してもらい,PCの納品明細データ及び納品伝票データを更新する。 計量値付機で行う作業は,次のとおりである。 (1)事前作業として,注文速報データを基に,商品単位に,それぞれの目安重量に 応じたパックを,当日A社から発注された数量分準備する。 2)PCから,当該商品の商品コード,商品名,消費期限,100グラム当たりの金額 を計量値付機に送る。 (3)当該商品について,1店舗分の店番,店舗名,数量の情報を計量値付機に送る。 (4)1パックずつベルトコンベアに流し,まず,量り部分で計量し,内容量及び売価 を計算する。次に,消費税率を用いて税込売価を計算する。その結果を基に値札を 発行しベルトコンベアを流れる商品に自動貼付する。 (5)1店舗の数量分の作業が終了すると,計量結果データは計量値付機からPCに送 信される。 (6)一つの店舗の作業が終わったら,(3)て5)を,全ての店舗が終わるまで繰り返す。 (⑦一つの商品の作業が終わったら,(2)~O*,全ての商品が終わるまで繰り返す。 定貫商品と不定貫商品の値札の例を図1に示す。 定貫商品不定貫商品 粗がききツーセージ税抜価格(円)298国産生ひき肉(小)税抜価格(円)260 税込価格(円)321 100g当たり2っso税込価格(円)280 消費期限2016.10.22||(Pik.円)消費期限2016.10.22 内容量(g)104 川川川交SS本晴信の 図1定貫商品と不定貫商品の値札の例 また,B社では,不定侍商品をA社店舗に納品する際の店舗別ピッキングについ て,①徒来の定貫商品と同じ店舗別ピッキングでは,A社の買掛金の処理に不都合を 生じさせてしまうので,づ店舗別ピッキングの方法を変更することにした。 a=B= [買掛金システムに渡すデータの作成処理] 店舗から送られてくる検品データ,検品差異ゲータと,A社にある納品伝票データ, 納品明細データを使って,買掛金システムに渡すデータを作成している。現在の処理 の流れを表2に示す。 表2現在の処理の流れ 納品伝票データと検品データを,店番,伝票番号をキーにしてマッチングさせ,一 致したら,次の処理を行う。 検品データ|①納品伝票データに納品日を格納し,納品伝票データから買掛金合計データを作 成する。 ②納品伝票データに関係する納品明細データから買掛金明細データを作成する。 納品明細データと検品差異デゲータを,FB,伝票番号,行番号をキーにしてマッチ ングさせ,一致したら,次の処理を行う。 ①検品差異デゲータの実納品数量で納品明細データの数量を書き換える。商品マス 検品差異どゲ|タ上の原単価,売単価に実納品数量を乗じて算出した原価,売価で納品明細デー =iタの原価,売価を書き換えるとともに,書換え前後の原価の差額,売価の差額を 納品伝票データに反映する。 Q①で書き換えた納品明細データの原価の差額を,対応する買掛金明細データ及 び買掛金合計データに反映する。 今回,不定貫商品を扱うに当たって,検品業務において,不定貫商品の納品数量が異 なるケースを想定して,③検品差異データに,実納品原価,実納品売価の二つの属性を 追加する。実納品原価,実納品売価は,実際に納品された商品の原価,売価を商品単位 に合計して算出する。また,不定貫商品の検品差異データが発生した場合を考慮し,表 2の検品差異データの処理を,不定貫商品については表3のように変更する。 表3不定貫商品の検品差異データの処理 納品明細データと検品差異データを,EB,伝票番号,行番号をキーにしてマッチ ングさせ,一致したら,次の処理を行う。 ①検品差異データの実納品数量で納品明細データの数量を書き換える。検品差異 mazes|データの[|s 1[ゎ5]で[|c]デ-タの[_d 1[|s| ータを書き換えるとともに,書換え前後の原価の差額,売価の差額を納品伝票データ に反映する。 ②①で書き換えた納品明細データの原価の差額を,対応する買掛金明細データ及 び買掛金合計データに反映する。 —_6—

共通の文章

問合せ管理システムの導入に関する次の記述を読んで,設問1ー3に答えよ。 D社は,産業用機械メーカである。全国にあるグループの販売会社数社を通じて, 法人顧客に対して社製品の販売・保守を行っている。D社グループでは,製品に関 する顧客からの不具合の連絡,クレームなどを含む問合せ(以下,問合せという)を グループ全体で一元的に管理する問合せ管理システム(以下,新システムという)の 導入を行うことにした。 [新システム導入の目的] 顧客からの問合せは,販売会社で受け付け,対応しており,受付内容及び対応内容 の情報(以下,問合せ情報という)については,各販売会社で記録,管理している。 しかし,現在は問合せへの対応状況が適切に管理されておらず,一部の対応が滞るこ とがある。また,問合せ情報をD社グループ内で共有できておらず,過去の対応内 容を類似の問合せへの対応に生かすことができていない。製品製造元であるD社に おいても,問合せ情報が即時に販売会社から報告されていないので,問合せが急増し ている製品を早期に把握し,改善を図ることができていない。 そこで,D社グループ内で新システムを構築し,顧客サービスの向上と毅品の品質 改善につなげることにした。新システムは1年後に稼働する計画とした。 [現在の問合せ対応業務の概要] 現在の,各販売会社で行う問合せ対応業務の概要は,次のとおりである。 (1)顧客は,購入したD社製品に問題が発生した場合,販売会社へ電話又は電子メ ール(以下,メールという)で連絡する。 (2)連絡を受けた担当者は,顧客から問合せ内容の詳細を聞取りする。 (3)担当者は,即時に解決可能な問合せの場合,聞取りと同時に解決に必要な対応 を行う。即時に解決できない問合せの場合,一旦聞取りを終了し,販売会社内の製 品技術者又はD社の製品部門に連絡して,対応策を相談する。相談した対応策に 基づき,再度顧客に連絡し,解決に必要な対応を行う。 (4)対応が完了した後,担当者は各販売会社所定の報告書を作成し,上司に報告す る。報告書は,各販売会社の文書管理規程にのっとって管理する。 as if mx なお,解決困難な問合せの場合は,問合せ内容の聞取り終了から報告までに数週間 掛かる場合がある。また,安全性に関わる重大な問題の場合は,品質問題報告書を作 KL,聞取り終了した日の翌営業日までに,D社品質保証部門に報告している。 (D社グループのIT戦略〕 5年前に策定したD社グループのIT戦略では,グループ全体の経営を支える情報 システムの最適化を目標として定め,社内LAN及びグループウェアを含む社内イン トラネットシステムの統合を実現した。統合の際,ディレクトリサーバを用いたID 管理基盤を導入し,それまで情報システムごとに個別管理していた利用者ID及びパ スワードを一元管理している。また,多様な働き方に対応するために,社員に貸与す るPCを利用して,自宅,外出先などから,インターネットVPN経由で社内システ ムへ安全にアクセスできる環境を構築した。当環境では,個人所有のPCなど,許可 されていない端末からはアクセスできない対策が取られている。 現在,新システムとは別に,D社グループ全体で基幹業務システムの再構築プロジ ェクトが進行しており,1年半後に新たな基幹業務システムの稼働を予定している。 なお,D社では今年,IT戦略の見直しを行った。見直し後のIT戦略では,BRS 経営効率向上を目指し,自社で構築・運用する情報システム(以下,自社運用システ ムという)を段階的に減らし,専門の事業者が提供するクラウドコンピューティング サービス(以下,クラウドサービスという)の活用を積極的に進めることにした。 〔[販売会社からの新システムへの要望〕 販売会社からの新システムへの要望は次のとおりである。 ・問合せ対応の参考にするために,他の販売会社で受け付け,対応が完了した問合せ 情報についても,RAMS,製品名,問合せ分類.,フリーワード,受付年月日の期 間指定などで検索することで,問合せ件名などの基本情報,受付内容及び対応内容 を閲覧できるようにしてほしい。一方で,その他の情報については,必要がない限 り問合せ受付元の販売会社以外には閲覧させないことを原則としてほしい。 ・自社で登録した問合せ情報は,登録後も自社で修正できるようにしてほしい。一方 で,自社で登録した問合せ情報を,他の販売会社が修正できないようにしてほしい。 ・誤って同一の問合せを重複して登録することが想定されるので,自社で登録した問 =mh ee 合せ情報を削除できるようにしてほしい。一方で,自社で登録した問合せ情報を, D社及び他の販売会社が削除できないようにしてほしい。 ・担当者が問合せを受けた時に聞了取りした相手である顧客側の担当者(以下,問合せ 顧客という)の情報については,機密性が高いので,D社及び他の販売会社へ開示 しないでほしい。D社が問合せ顧客の情報を必要とする場合は,担当者に連絡をも らえれば,問合せ顧客に了解を得た上で,情報を伝えるようにする。 ・新たに,利用者ID及びパスワードを覚えなくても済むようにしてほしい。 (D社品質保証部門及び製品部門からの新システムへの要望〕 D社品質保証部門及び製品部門からの新システムへの要望は次のとおりである。 ・販売会社からの要望に加えて,D社としては製品の品質改善のために,重大な問題 に限らず,早期に問合せ情報を確認できるようにしてほしい。具体的には,どのよ うな問題が発生しているのかを把握するために,問合せ件名,受付内容及び報告時 点までの対応経緯だけでも直ちに確認できるようにしてほしい。問合せ内容,対応 経緯などの修正が後から生じることは問題ない。 ・受付内容の記入間違い時の訂正,D社が支援した内容の対応経緯への加筆などが想 定されるので,販売会社が登録した受付内容及び対応内容を,販売会社が対応中で も対応が完了した後でも,D社が修正できるようにしてほしい。 ・複雑な問題の場合,D社が直接顧客から問合せの詳細を聞取りしたいことがあるの で,必要な情報を見られるようにしてほしい。 ・製品マスタなどのマスタ情報は,基幹業務システム上で更新が発生するので,MY ステム上にも最新情報を反映するようにしてほしい。 〔[新システムの構成 IT戦略に基づき,新システムは,クラウドサービスを活用して構築することを検 討した。MHOC,クラウドサービス上に構築する新システムを,社内LAN経由 ではなくインターネット経由で直接利用した場合のリスクとして,外部からの不正ア クセス,盗聴の他,社内システムでは認めていないシステムの利用方式で社員が新シ ステムを利用できてしまうおそれがあるのではないかという意見が挙がった。 これらのリスクに対して,クラウドサービスと自社運用システムとの間を閉域綱で ー10一 接続ししインターネットから論理的に遮断して社内LAN経由でしか新システムを利 用できない構成とすることによって,リスクを回避することにした。 検討した新システムの構成概要を図1に示す。 自社運用システム Fay fay re サーバサーバ||サーバ専用線ae Web DB ネット|…|ネットトリ= 接続このパサーバ||サーバ サービス 基幹業務||基幹業務 a YAF bl RF Ly ZB<(elサーバサーバ Cr)D社グループWAN(閉域細) D社事業所販売会社事務所販売会社事務所 aa eee[PE]…Le]|”+[PC] ee= DB:データベース 図1新システムの構成概要 新システムへの要望に基づき,新システムで構築するディレクトリサーバと自社運 用システム上のディレクトリサーバとの連携,及び新システムで開発する業務アプリ ケーションプログラムと基幹業務システムの業務アプリケーションプログラムとの連 携が必要になる。しかし,基幹業務システムとの連携は,基幹業務システム側での対 応作業の負荷が高いことに加え,①ある理由で新システム乏働後の改修が発生する可 能性が高いので,今回はディレクトリサーバの連携だけを行うことにした。基幹業務 システムとの連携は新システム稼働後に改めて検討することにし,当面は人手での情 報連携で運用することにした。 [登録画面の設計〕 新システムで管理する問合せ情報は,五つに分類し,その情報の種類ごとに画面領 域を分割して問合せ情報を登録する画面(以下,登録画面という)を設計した。情報 の種類ごとの主な属性を,表1に示す。 表1情報の種類ごとの主な属性 a 役職,問合せ顧客電話番号,問合せ顧客メールアドレス 電話番号,担当者メールアドレス 基本情報の対応ステータスは,問合せへの対応状況に応じて“受付内容確認中", “受付完了・対応中”,“対応完了”の三つのステータスの中から選択し,新システム に登録,更新することによって,問合せ対応の進捗状況を可視化できるようにした。 新システムへの要望を踏まえて,対応ステータスを“受付完了・対応中"にするこ とによって,D社品質保証部門及び製品部門に必要な権限を与えるようにした。また, “対応完了”にすることによって,D社品質保証部門及び製品部門に加えて,問合せ 受付元以外の販売会社にも必要な権限を与えるようにした。 なお,②新システムを利用した問合せ対応業務では,即時に解決できない問合せの 場合であっても,遅くとも業務上のあるタイミングまでには,問合せ情報を新システ ムに登録するルールとした。 [問合せ情報に対する権限 問合せ受付元の販売会社が登録した問合せ情報を利用するに当たっての,利用者の 所悦,基本情報の対応ステータス及び情報の種類に応じた,閲覧,修正及び削除の権 限を,表2の決定表に整理した。 ー12一 表2登録された問合せ情報を利用するに当たっての権限の決定表 利用者の所属が問合せ受付 利用者の所属が問合せ受付 部WWトトトトトト中|四則 利用者の所属がD社品質保 Zs間還是回回EEIEEIEIEEEEEEIEEIEE 基|受|対|問|担基|受|対|問|担|基|受|対|間|揚 本|RT|応|A}当本|付|応|合|当|本|付|応|合|当 情報の種類=情|内|内|せ|者情|内|内|せ|者|情|内|内|せ|者 報]容|容|顧報|容|Al報|容|容|顧 客客Be 閲覧可能=|-|NL J|—[ees eee(ieee—|x| The Nelfelfel=del T= 削除可能|—|=Lea-[Res LN es aN|—|-| 注記1対応ステータスのコードの意味1:受付内容確認中,2:受付完了・対応中,3:対応完了 注記2網掛けの部分は,表示していない。

共通の文章

売上・回収業務のシステム改善に関する次の記述を読んで,設問14に答えよ。 E社は,関東地方を中心に建材の卸販売を行っている。現在,販売管理システムと 会計システムを対象に,売上から回収までの業務及びシステムの改善を進めている。 [現状の売上から回収までの業務と関連システムの概要) 現状の売上から回収までの業務と関連システムの概要は,次のとおりである。関連 システムは,販売管理システムと会計システムである。 (1)売上業務 売上計上には,販売している商品の特性によって,出荷した時点で売上を計上す る(以下,出荷基準という)場合と,顧客からの検収書を入手した時点で売上を計 上する(以下,検収基準という)場合の2通りがある。出荷基準の場合は出荷伝票 の控えから,検収基準の場合は顧客の検収書から,営業事務部門で売上伝票を起票 し,販売管理システムに入力して売上を登録している。また:,売上伝票の控えが経 理部門に回付され,経理部門で仕訳伝票を起票し,会計システムに入力して,売上 勘定と売掛金勤定に計上している。 (2)返品業務 商品は,誤出荷や不良品出荷などによって返品されることがある。良品の返品は, 倉庫在庫へ戻入れを行い,それ以外は廃棄などの処理を行う。返品の受付後,返品 伝票を起票し,販売管理システムに入力することによって,必要な処理を行ってい る。また,返品伝票の控えが経理部門に回付され,返品に伴う修正仕訳伝票を起票 し,会計システムに入力している。 なお,返品に対する再出荷は,通常の出荷と同様に処理する。 (3)請求業務 顧客への毎月の請求は,指定請求先に対し,締日までの売上情報に基づき請求書 を発行する場合と,一部の大手顧客からの支払通知書に基づき請求書を発行する場 合がある。請求書は,会計システムで発行し,経理部門から顧客に送付している。 (4)入金業務 顧客からのE社への入金は,E社指定口座への銀行振込によって行われる。ま た,全ての顧客の支払条件は,締日の翌月末払いとなっている。支払日が休日の場 =Res 合は,その前の営業日となっている。顧客からの入金情報はファームバンキングに よって入手している。 (5)売掛金管理業務 売掛金の消し込み及び残高管理は,経理部門で行っている。 [売上から回収までの業務に関わるシステム改善要望] 関連部門から,売上から回収までの業務に関わる,次のようなシステム改善要望が 出された。 (1)売上業務の改善 ①営業事務部門と経理部門での伝票の受渡しをできるだけ減らせるようにシステ ムを改善してほしい。 @経理部門での仕訳伝票起票,入力などの事務処理工数を減らすために,販売管 理システムと会計システムとの連携を強化してほしい。 (2)返品業務の改善 ①これまで返品については,返品理由が曖昧なまま安易に返品を受け付け,処理 されていたケースが多かった。今後は,顧客や配送業者との確認も含めて営業事 務部門,出荷部門などの関連部門で返品理由を明らかにし,自社責任による返品 か人否かを明確化していきたい。 ②自社次任による返品については,販売管理システムに新たに返品受付処理を設 け,返品に伴う必要な処理をシステムで連携できるようにしてほしい。 (3)請求業務の改善 ①顧客からの支払通知書は,今は郵送されてきているが,その入手方法をシステ ムで対応できるように改善してほしい。 ②支払通知書の内容と請求内容の照合をシステムで対応してほしい。 (4)売掛金管理業務の改善 資金繰り強化及び売掛金の不良債権化予防の一環として,売掛金未回収のリスク を減らすための情報提供をシステムで行ってほしい。 [改善後のシステムの内容〕 システム改善要望を踏まえ,情報システム部門で検討した改善後のシステムの内容 ー16一 は,次のとおりである。 1)売上及び返品に関する処理 出荷後の出荷伝票又は顧客検収後の検収書を販売管理システムに登録し,TOR 績データに基づき売上計上を行う。また,出荷実績は,販売管理システムの在庫管 理に反映する。売上の情報は,会計システムに連携し,自動仕訳を行い,一般会計 処理で関連する勘定科目に計上する。それによって,売上伝票を起票して経理部門 に回付することは廃止する。また,経理部門での仕訳伝票の起票とその入力も廃止 する。 返品については,販売管理システムに新たに返品受付の処理を設ける。ここで受 け付ける返品は,自社責任が明確になった返品だけとする。売上の修正が必要な返 品は,売上ファイルにその修正を反映し,会計システムにもその修正を連携して反 映する。また,良品の返品の場合は,販売管理システムの在庫管理に反映する。 売上及び返品に関する処理の改善後のシステムフローを図1に示す。 a Cd ierscaeenes 販売管理システム ーー|・在庫管理sk ・売上計上oレ ファイル a]ER ro 2 =B Gal 会計システム マスタieーーテー ・売掛金管理総勘定元帳 マスタ トー・返品受付ファイル.在庫管理ファイル =7 em) 在庫 .マスタ 図1売上及び返品に関する処理の改善後のシステムフロー (2)請求に関する処理 大手顧客からの支払通知書に基づく請求については,顧客からの支払の対象とな る支払明細データを事前にED]で入手できるように顧客と調整する。その支払明 細データと売上データとの照合処理を,毎月顧客ごとの締日を基準にして実施する。 照合の結果,不一致が発生した場合は,人手で顧客との確認・調整を行い,確定結 果をシステムに登録し,必要な売上データの修正を行う。 請求に関する処理の改善後のシステムフローを図2に示す。 売上 ファイル 会計システムae SH支払明細会計システム売掛金 Tae ES)ロロGal ED!|.sy/eeme|VZV=請求処理マスタ eg MM の確認調整mm 売上修正 図2請求に関する処理の改善後のシステムフロー 3③売掛金管理に関する処理 売掛金管理において,新規の管理帳票として売掛金年齢表を作成する。売掛金年 齢表は,売掛金の回収を促進し,不良債権化を未然に防止するための情報を提供す る管理表であり,現時点の売掛金残高に対する回収が,顧客の売掛金の支払条件に 応じた回収になっているか,回収が遅れている場合はいつの売上分の売掛金残高が 吉ら未回収となかっているかが出力されている。 売掛金年齢表の帳票イメージを図3に示す。売掛金年齢表に例示している,顧客 F社,G社,H社の売掛金の支払条件は,3社とも月末締め翌月末払いである。ま た,売掛金年齢表の作成は,月末入金による売掛金の消し込み処理の後に行うもの とする。 saiealilia平成28年11月1日現在 (金額単位:千円) _ 売上分|売上分|売上分|売上分 |Fat|15,000|150001||| ||wogl wl 200| 図3売掛金年齢表の帳票イメージ

共通の文章

生活支援ロボットシステムの開発に関する次の記述を読んで,設問1~4に答えよ。 K社は,生活支援ロボット及びそれを用いたシステムを開発し,製造・販売してい る。生活支援ロボットは,移動作業型,人間装着型及び搭乗型に分類されている。K 社では,物をつかむ,つかんだ状態で移動する,つかんだ物を離すという基本機能を もつ移動作業型ロボット(以下,従来ロボットという)を製品化している。K社はこ れまで,従来ロボットを用いて生活支援ロボットシステム(以下,従来システムとい う)を構成し,販売してきた。 近年,少子高齢化社会の到来が問題となってきており,高齢者世帯における生活支 援の要求が高まっている。Ek,共働き世帯及び単身生活者の増加によって,一般家 庭でも不在時の配達物受取りなどの生活支援の要求が高まっている。K社は,生活支 援機能を充実させ,他社との差別化を図ることによって,移動作業型の生活支援ロボ ットの直要が更に見込まれると考え,新たな機能を追加した生活支援ロボットシステ ム(以下,新システムという)を開発することにした。 (HEY AF LORE) K社の従来ロボットは,基本機能以外に,タッチパネル付きディスプレイ,カメラ, マイク,スピーカ及び音声認識機能こよる人とのコミュニケーション能力を備え,人 が生活する場所で生活支援の機能を果たすことができる。また,無線LAN通信機能 も備え,無線LANアクセスポイントを介してデータ通信が可能である。 K社がこれまでに開発した生活支援機能は,従来ロボットと,LAN,無線LANア クセスポイント及びサーバで構成された従来システムが実現している。サーバは,シ ステム管理,利用者の認証などを行う。従来システムの構成を図1に,従来システ ムが実現している生活支援機能を表1に示す。 Ai ポイント アクセス 図1従来システムの構成 ー20一 表1従来システムが実現している生活支援機能 ・指示された物を取りに行き,指示された行き先へ運ぶ。 見守り・生|・様々な機能(就寝時刻・起床時刻の管理,薬の服用の管理,体操の指導,室内の 〔新システムに対する利用者の要望 新システムの開発は,K社のシステムアーキテクトであるL氏が担当することに なった。L氏は開発に当たって,これまでに従来システムに対して利用者から寄せら れた要望のうち,新たな機能追加の対象となる要望を次のとおりまとめた。 ①外出中の居住者,又は別居している家族,知人が,ロボットを硝隔操縦できるよ うにしてほしい。 ②単に物を運ぶだけでなく,日用品の在庫管理もしてほしい。 ©室内の備品,収納品などが,通常と違う場所に移動又は放置されたとき,それら を元の場所に戻せるようにしてほしい。 ④留守中に配達物を受け取れるようにしてほしい。また,受け取った配達物が在庫 管理対象品の場合,在庫管理に反映できるようにしてほしい。 〔(新システムの開発目標〕 L氏は,利用者の要望を考慮して,新システムの開発目標について検討し,次のと おり定めた。 ①インターネットを介して,遠隔操縦できるようにする。 ②あらかじめ在庫管理対象と定めた日用品を,専用収納ボックスのトレイ単位で在 庫管理できるようにする。 ③片付けの指示があったとき,通常と違う場所に移動又は放置されている物を識別 し,元の場所に戻せるようにする。 ④事前に連絡があった配達物を,受け取れるようにする。配達物が在庫管理対象品 の場合は,受取りが在庫管理に反映できるようにする。 新システムへの追加機能を表2に示す。 ー21一 表2新システムへの追加機能 ままーー eo = 在庫管理・トレイの重量を計測させ,サーバで在庫数量を管理する。定められた数量以下に 遠隔操縦カメラ映像及び音声を確認できる。 ・従来ロボットに遠隔操縦用カメラを追加し,遠隔地からモバイル端末を用いて, なると,アラーム“在庫僅か"を出力する。 I (VAT LO ERK) L氏は,新システムの構成を次のとおりまとめた。 ①従来ロボットに新たな機能を追加した移動作業型ロボット(以下,新ロボットと いう)と,サーバ,専用収納ボックスで構成し。これらをLAN,無線LANで接続 してデータ通信を行えるようにする。また,配達物受入所の扉の錠,テレビドアホ ンなどを無線LANで接続する。 @新ロボットには,遠隔操縦のためのデータ送受信機能と遠隔操縦用カメラを追加 する。 ③遠隔操縦に用いるモバイル端末を用意し,インターネット経由でサーバと通信で きるようにする。操縦者の顔画像・音声をサーバに送信し,新ロボットのカメラ映 像とマイクからの音声をサーバ経由で受信する。 ④サーバには,新ロボット及びテレビドアホンからの映像の処理,居住者・操縦 者・訪問者の顔認証,電子メールの送受信,在庫管理などの機能を追加する。 新システムの構成を図2に,新ロボットの各部の機能を表3に示す。 4。、無線LAN S|サーバ| pie PTE=aA=erob ql et wR 72 7-7 iL] 図2新システムの構成 ー9一 表3新ロボットの各部の機能 REET Skids上下伸縮機能をもった本体,及び本体に格納できるアームを備える。アーム を動かし,本体を上下することで,アームの先端が上下左右に展開する。 orアームの先端にある二指ハンドは適度な柔軟性をもち,形状になじみながら ——物を確実につかむ。 対象物の形状認識・|よ、計論した形状及びつかみ方を記憶し,以後同じ物かどうかを判断す とmag.|物の3次元形状を認識し,アームと二指ハンドの動かし方を判断してつか 把持制御部 最高速度は15mン分で,段差5mm,登坂5まで走破できる。 本屋内の環境を認識し,障害物を避けながら,指示された目的地まで最適ルー トで移動するように制御する。 タッチパネル付きデ|本体上部に配置しヒューマンインタフェースに用いる。 イスプレイ 左右に並べて設置し,形状認識,環境認識に用いる。 広い範囲を撮彫でき,環境認識に用いる。 遠隔操縦用カメラ|ズーム及びカメラの向きを遠隔制御でき,遠隔操縦に用いる。 人とのコミュニケーション及び環境音の入力に用いる。 入力した人の音声を文字列に変換し,意味を認識する。 Pf LANに接続しさらにインターネットにも接続す 近接センサは衝突・接触を避けるために,赤外線センサは人などを検知する センサために用いる。その他,各種センサによって,室内の空気のモニタリングを 行う。 〔新システムの追加機能の検討結果〕 L氏は,新システムの追加機能を検討し,結果を次のとおり整理した。 ①遠隔操縦機能 遠隔操縦時には,セキュリティの観点から操縦要求者の顔認証をサーバで行う。 また,操縦中も1分ごとに上顔認証を行うも。さらに,サーバで顔認証によって居住 者かどうかを判断できるようにする。 居住者の在宅時の遠隔操縦は,操縦の四較を避けるため居住者の承諾を得てか ふくそう ら行う。新ロボットは,赤外線センサ及びカメラ映像から近くに人がいることを確 認した場合,サーバにカメラ映像を送信する。サーバは居住者かどうかの認証を行 い,居住者と判断できたら,新ロボットが音声で居住者に|a|,返事を聞 く。居住者に拒否された場合,新ロボットは,その則を操縦要求者に返信する。居 住者の不在時は,操縦要求者が認証できたら操縦可能とする。 遠隔操縦は,新ロボットの遠隔操縦用カメラからの映像とマイクからの音声を見 聞きしながら行う。新ロボットを移動させたり,アームを動かしたりする操縦指示 lk,モバイル端末を介して音声で行う。対象を特定して見る場合は,モバイル端末 の画面を向けた方向に示隔操縦用カメラが向くように制御する。 ②在庫管理機能 在庫管理は,在庫管理対象品を,あらかじめサーバの在庫管理マスタに登録し, 専用収納ボックスのトレイに1品目ずつ保管する。トレイには識別コードのラベ ルを貼付し,専用収納ボックスの収納位置及びトレイ自体の重量も特定できるよう にしておく。新ロボットは,専用収納ボックスからトレイを引き出したとき,及び 収納するときに,トレイを含む重量を量り,そのデータをサーバに送信する。その ために,専用収納ボックスの近くに電子はかりを用意する。入庫時は,新ロボット が在庫管理対象品を1個ずつトレイに移し,入庫数をカウントする。 サーバは受信したデータかとら在庫数を算出し,更新する。在庫数が定められた数 量以下となった場合は,アラーム“BED”を出力し,補充を求める。 @片付け機能 片付ける対象は,重さなどの制約から室内の家具などは除外し,床面に放置され た器具,置物などに限定する。対象物の保管場所をあらかじめ定めておき,形状な どを新ロボットに認識・記憶させておく。新ロボットは,片付け指示を受けると, 近くの床面から順次,探索し,置かれている物を判別する。保管場所から移動又は 放置された物と判別した場合,新ロボットは,記憶している保管場所に戻し,判別 できない場合は,不明品保管場所に運ぶ。 ④配達物受取機能| 定期的な配達物,及び事前に電子メールで連絡があった配達物は,人を介さずに 受け取れるようにする。テレビドアホンの映像をサーバに取り込み,定期的な配達 物の場合は配達人の認証を行い,事前に連絡があった配達物は伝票番号と照合する。 認証又は照合ができれば配達物受入所の扉を開錠し,配達物受入所に置くよう案内 する。新ロボットは,ステレオカメラで撮影した配達物の映像をサーバに送信する。 サーバは,受け取った配達物が在庫管理対象品であることを確認した場合,MO ー24一 ボットに対し,開封し,|b|]するよう指示する。