・・・・まだ、できていません。
だいぶ進捗はしました。Webから発注する分に関しては。
しかし、肝心のデータベース本体に不具合が多すぎます。
何が原因なのか考えてみますと、
やはり、ひとつひとつ目の前のことに対処（修正）しているだけで
全体が見えていないのです。
売上計上日、これはのちのちまでも意味を持つキーとなる要素なのですが、これが同じ発注データに対して（つまり同じ受注番号に対して）複数あったりするのです。
本当に売上げた日。これが正しいのですが、そして売上伝票には
この日付が入っているのですが、出荷伝票のほうに行くと
この売上計上日が入るべき項目に「入力日」が入っていたりするのです。
自分で作っていたら、ここに表示されている日付はどこから引っ張ってきたものか？何を基準にして計算したらいいのか？
などがわかっているので、間違いがあってもどこをどう直せば整合性がとれるかも対処できるのですが
外部に頼んだシステムは、まったくのブラックボックスになっていて
わけがわかりません。
ありえないような計算結果がでてきたりすると、
いったいどのデータをどういう計算をしてこんな結果がでたのか？！を、つい問い詰めたくなってきます。
今日もひとつ大きなミスが発覚し、修正依頼をしました。
修正してくれるのはいいのですが、それによって当然変わるべき数字（連動しているはずなので）も変わるんでしょうね？と念を押してしまいました。
先日もこんなことがありました。
普通、発注のキャンセルがあって売上伝票を削除したら、その伝票分の発注商品数は在庫に戻るはずです。
（この場合、発注があった時点で商品在庫数が減るシステムのため）
それが、売上伝票を削除しても在庫数は変わらなかったのです。
在庫数との連動がされていなかったのです。
信じられない・・・。
うちの経営陣はあまりコンピュータに詳しくないのですが、
「コンピュータってそういうのは自動的に変わるんじゃないの？」
と呆れていました。
いや、いくらコンピュータだからって、連動させるようにプログラムしておかなければ自動的には変わりませんけどね。
それをするのがシステム会社の役目なんですよね。
こちらからそれを指摘されるシステム会社っていったい・・・。
このシステムってデータベースじゃない、ワープロなんだ。
１箇所直したら全部が直る、とかそういう風に思っちゃいけないんだ。
ここを直したら、あそことこことそこも直すのだ、とマニュアル化しておかなければならないようなシステムなんだ。
そう思うことにしました。
今より断然やることが増えるんですけど・・・（涙）
システム会社に限ったことじゃありませんが
全体を見る
仕組みづくりをする
整合性をとる
その力を持つ人は、もしかしたら貴重なのかもしれない
と思う今日この頃です。
そんなことを言っている暇があったら、自分がその力を身に付けろよってことなんですけどね。
タグ：整合性
