名前 題名 ▼ 宮さん > ▼ Syakeさん > > しかるに、通常は現在のデータが保持されるのが当然です。 > 私なら１番をとります。 > 理由１ > このような処理の環境なら、オペレータコード、日時、端末番号、を記録されるべきであり、 > 印刷を開始する前に印刷されるだろう確定された伝票番号とリンクされなければならない。 > 印刷するとき加算して伝票番号が生成されることは、オペレーターが処理を開始する前は、架空の番号となる。 > たいてい、複数のオペレーターが操作することを考えると管理しにくい。 > > 理由２： > 必ず、ハードトラブルが起きることを想定しなくてはならないから、オペレーターは自分が印刷しようとした伝票番号を > かれが印刷が成功するまで、はじめにもらった伝票番号を管理しなくてはならない。 > そうでないと、複数のオペレータが複数のプリンタで処理しているであろうことを考えると、 > 全員先に進めないことになる。 > 印刷は非常にくせ者で、一見正常に印刷したようでもジャムッていた、印字がかすれていた、 > 成功したことを確認しにくい。 > また、プリンターはバッファーをたいてい持って印刷待ちになりながら印刷するので、処理指令が発せられてから > 勝手に伝票番号がカウントアップされては、フォローが大変。 > つまり、どの時点で伝票番号をカウントアップするか非常に難しいのでは。 > > 理由３： > かならず、このようなジョブではイレギュラー処理が発生する。ことを前提にしておかなければならない。 > オペレーターが印刷指令をした後でいわばその時点では架空の番号が伝票に印刷される場合、 > イレギュラー処理はやりにくいことは明白です。 > 印刷履歴は不要とのことですが、実務では考えられない。 > データのミス発見、返品、キャンセル、等があった場合対応できないのでは。 > > と私は考えます。 > では。 GIF,JPEG,PNG画像ファイル及びLZH,ZIPファイルをアップロードできます.600 x 1200 ピクセルを超える画像は縮小表示されます(画像クリックで拡大表示). (上限122000(120k)バイト) 削除キー Link