あるIT現場4 論理在庫遅延と実績とフラグと月頭、月中でデータパターンは192通りある

あるIT現場4 論理在庫遅延と実績とフラグと月頭、月中でデータパターンは192通りある

いやしかし。
なんだかなぁ。

ようやく、仕様を理解し始めた東北の歳をとった方が、
データをわざわざ消して、なにかおかしいとかいいだしたが。

あるうるデータパターンは最大２４通りかな。
そして、処理パターンは２つ。

それなのに、１９２通りある組み合わせのいくつかを発見しては、
このときは、あーだとか、こーだとか。

今更なにをいっているのか。

自分で好きに直せばいいのにな。

１９２通りの決定表でもはじめにつくればいいだろう。

ないときは、０と考えあると考えると途中で変わった。
更に、０ではいけないと変わった。
その後、ヤッパリ０だな！

とか、もう、ない組み合わせであーでもないこーでもない。

１９２通りあるんだから、その全部のデータパターンを作り、
結果がなんでなければならないのか何故、顧客に確認しないのだろうか。

私の考えでは２通りなんだがな。

それなのに、次の日になると、
「・・・これはー・・・」
とかいうのだが。

多分しばらくすると、１９２通りの組み合わせで、処理しきれない現象が発生し、
また、「あーでもない、こーでもない」とやりだすのかもな。

東北の若い人Aはよくがんばっているが、
東北の歳をとったほうに使われるとダメになってしまう。

まあ、明日のなるとまた
なんか言い出すのかもしれない。

元請の人が仕切って、もっていって直すことになる可能性が大だ。


そうそう、今日、東北の歳をとったほうに、「不具合だ」といわれてあるものを修正したのだが、
他システムからやってくる、論理在庫と、実績の意味がわかっているのなら、そんなことは言わないだろう。
おそらく、まったく意味が分かっていない。

論理在庫は遅延する。
だから実績を優先する。
論理在庫は不正確。
だから実績の出庫、入庫と前の論理在庫から論理在庫を出す。
前の論理在庫がないのなら、新規に作成された保管場所である。
論理在庫は遅延しても不正確な数量が存在する。
だからないときは、０と考えることに決まっていたのだが。