デスぺR5午後2問1設問3の(2)の解釈と答え
sunakan.icon個人的に難問
下線①
連携WTに溜まった...案1よりも短縮できる
sunakan.icon依頼3をある程度理解する必要がありそう
年月別の在庫回転率を時系列に抽出
在庫回転率=数量・金額を元に算出
月末ではなくても最新情報何度も参照可能にしたい
table:残高集計表
# 名前 説明
A 月初残高 前月繰越による受入の数量
B 当月受入 当月中の入荷による受入数の数量
C 月末残高 次月繰越による払出の数量、金額
D 当月払出 A + B - C
E 在庫回転率 D / ((A+C)/2)
全部売れた
A=0
B=100
C=0(全部売れた)
D=(A+B-C)=0+100-0=100
E=D / ((A+C)/2)=100 / 0=無限
全部売れた2
A=100
B=100
C=0(全部売れた)
D=200
E=200/50=4.00
全部残った
A=0
B=100
C=100
D=0
E=0/50=0
2:係数を格納するテーブル設計
受払明細テーブルは
入荷(受入)と出荷(払出)、赤伝と黒伝、前月繰越と次月繰越を1つのテーブルで表現
これら6タイプを摘要区分(てきようくぶん)という列で表現
受払残高テーブル
残高集計テーブル
3. 計数を格納する処理
sunakan.icon赤伝・黒伝ごとに洗い替えってマジか
sunakan.iconそのまま赤伝、黒伝かけばいいのに
案1:同期的
案2:非同期的
(2)の説明にて、
...受払明細テーブルへの追加及び削除行数を調べることで..
の部分で、表5の見方がようやくわかる
p.16
09-26の出荷数量40の出荷明細を追加入力すると、次月繰越の2行を削除、...
これ単価が載ってないのがなかなか意地悪
ここで次月繰越の2行削除が指す2行は
20行目の次月繰越の単価90の数量50個の商品を表現している行
21行目の次月繰越の単価95の数量300個の商品を表現している行
だと思われる
しかし、続く文章で
出荷1行及び新たな次月繰越1行の2行を追加することになる。
出荷数量40の行で1行
次月繰越1行の行で1行
合計2行を追加することになると読み取った
この時、出荷数量40の単価が90だろうが95だろうが、次月繰越は合計2行になるのでは?
問題文おかしくない?
単価90の出荷数量40の追加であれば、単価95の次月繰越は不変だから追加不要みたいなことを言うのであれば、次月繰越の削除が2行ではNGと解釈します
逆も然り
このへんググっても、指摘や疑問に思うところは無かった
次月繰越が何行あっても次月繰越は1行と表現するとしても、
次月繰越の2行を削除
という表現がおかしくなる
モヤモヤ
次の例
09-04の出荷を取り消す赤伝を追加すると、"受払明細"テーブルに合計で11行の削除、12行の追加
09-04のデータは単価80の数量30がキャンセル
つまり、09-04以降の単価80のやりとりをキャンセルする必要がある
表5の行4,6だけで残り消す必要なくない?
09-04、09-07、09-12、09-17、09-19、09-24、09-30の次月繰越
受払日付が同じものを1行と言っている場合
7行
最後の次月繰越を2行とカウントしても8行
受払日付が同じものを2行と言っている場合
14行
(09-04)出荷、(09-07)出荷、(09-12)入荷、(09-17)出荷、(09-17)赤伝、(09-17)黒伝、(09-19)入荷、(09-24)出荷、(09-30)次月繰越、(09-30)次月繰越
これで10行
前述で追加した 09-26の出荷数量40の出荷明細 を含めると、削除11行になる
そして、赤伝分を入れて12行の追加になると思われる
ただ、そうなると(09-04)出荷は消さなくてよくない?
本質ではないのでスルー
設問3 (2) (a)
問題
処理WTに同じ年月、拠点#、商品#の赤伝、黒伝が複数ある場合の洗い替えの起点となる行を選択する条件
3. 係数を格納する処理 > (2) 係数格納処理の処理方式検討 > 案2 > (b) > 「赤伝、黒伝があれば」の部分
入荷年月日又は出荷年月日、登録TSの順に取得して洗い替えを行う
を使って答える(昇順に並べて先頭行)
1. 計数の算出方法確認 > (1)商品有高表 > 3項目目
入荷の入荷年月日、出荷の出荷年月日を受払日付とし、受払日付順及び入出荷の登録順に記入する
を使って答える(受払日付、登録順が最も古い入出荷)
code:答え
入荷年月日又は出荷年月日、登録TSの昇順に並べた先頭の行
or
受払日付、登録順が最も古い入出荷
できるだけ問題文にある文章・文言を使うのが吉
設問3 (2) (b)
問題
(a)の洗替えの起点となる行を基に、洗替えの対象となる入荷、入荷明細、出荷、出荷明細を取得するときに、計数格納処理開始時点で登録済みの入出荷だけを反映した状態にするためにしている条件。ただし、入荷年月日又は出荷年月日が、起点となる行の入荷年月日又は出荷年月日よりも大きい条件を除く
code:解答例
登録TSが処理WT内で最大の登録TS以下であること
or
登録TSが計数格納処理の開始日時以前であること
or
拠点#、入荷#、出荷#が連携WTに存在しないこと
処理WTと連携WT
連携WT:一旦溜めておく用のテーブル
処理WT:処理するとき、連携WTの中身を全部処理WTに移す
むずいので解答例から考える
問題の「登録済みの入出荷だけ」=「(連携WTor処理WTに)登録済みの入出荷だけ」と言うこと
この部分の理解がキッツイ
そうしないと、連携WT→処理WTにコピー後また連携WTに入っている分の明細まで処理対象に入ってしまう(この部分を明記していない)
問題文の
計数格納処理開始時点で登録済みの入出荷だけを反映した状態にするために
計数格納処理開始時点の(連携WTに)登録済みの入出荷だけを反映した状態対象とした処理にするために必要なことは?
と聞いていると解釈するとわかりやすい
そうすると
解答例である
登録TSが処理WT内で最大の登録TS以下であること
登録TSが計数格納処理の開始日時以前であること
がわかりやすい
3つ目の解答例である
拠点#、入荷#、出荷#が連携WTに存在しないこと
は、連携WTにあるということは、未来で処理するものなので、対象としてはいけない
しかし、実務ではこれはしないと思われる
なぜなら連携WTはリアルタイムで増えるだろうから、次の瞬間には連携WTは増えてる可能性があるため