アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
osCommerce (スコア:1)
Re:osCommerce (スコア:3, 参考になる)
メインフレームでの流通システムでは普通にやっている事だと思うんですが、
発注数量や仕入原価、販売単価の相互チェックを行います。
たとえば、洗剤、お菓子ような安価な物の場合は、発注数量が千個あってもそんなに不思議はありません。
でも、大型のテレビのような高価な商品を千台もいきなり発注ってのはちょっとおかしいかもしれない。
だからそんな発注がデータとして入力された時は実際に発注出す前にチェックを入れて、
必ず目を通さないと発注がかからないような仕組みにする事があります。
他にも仕入原価よりも販売単価が安くなるような発注をしている入力データとか、
仕入原価と販売単価があまりにもかけ離れている入力データとかも、
しきい値を設けてメインフレームの処理では一旦データをエラーないしはワーニングのデータとして扱い、
必ず何人かの人間の目を通した上で正しいデータとして扱うような仕組みにしている、と思います。
#それは「仕入先と販売店の世界じゃないか」と思われるかもしれませんが、
#自動化を進めたシステムでは発注データを元にして店頭の値札、タグ、ポップを作ったりするんで、
#とんでもない発注を入れたが最後、現場のレジで大慌て・・となる可能性もあります。
あくまで私見(むしろ偏見かもしれません)なんですが、
ネットショッピングのシステムの納期や開発費用はメインフレームのそれに比べても短いです。
#すくなくともうちの会社を見る限りはそう感じます。
ですから、基本設計を行う時に「品目も数量も少ないだろうから、人間のチェックで間に合うだろう」
と楽観視している、という事はないでしょうか?
#無論、設計者はその事を重要視していても、クライアントから「そこまでしなくて良い」と突っぱねられ、
#「人間のチェックで間に合わせるしかない」と悲観的に設計したのかもしれませんし。
ちょっとまずいかもしれないのでAC