(57)【要約】【課題】発注データを送る側と受ける側の日付に関する整合を保つことができ、これにより発注システムの信頼性の向上が図れるデータ処理装置を提供する。【解決手段】ストアサーバ２で受信される各発注データの受信時刻ｔ１が発注締め時刻ｔｘを過ぎていれば、送信エラーとして、ストアサーバ２からホストサーバ３１への発注データの送信を禁止する。【選択図】図１
2009053843.tif 000002
【特許請求の範囲】
【請求項１】
入力される発注データを送信する端末と、
前記端末から送信される発注データを受信し、その受信時刻が予め定められた発注締め時刻より前であることを条件に、同受信した発注データを本部へ送信するサーバと、
を備えていることを特徴とするデータ処理装置。
【請求項２】
発注処理の機能を有し、その発注処理の起動中に入力される発注データを送信する端末と、
前記端末から送信される発注データを受信する機能、および前記発注処理の終了に伴い起動される発注締め処理の機能を有し、その発注締め処理の起動中の送信操作に基づき、かつ前記受信した発注データの受信時刻が予め定められた発注締め時刻より前であることを条件に、同受信した発注データを本部へ送信するサーバと、
を備えていることを特徴とするデータ処理装置。
【請求項３】
前記サーバは、前記発注データの受信に際し、その受信時刻が前記発注締め時刻以降の場合に、前記端末に送信エラーを通知する手段を有することを特徴とする請求項１または請求項２に記載のデータ処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、複数の店舗の発注データを本部で受付けるチェーンストアシステム等で使用されるデータ処理装置に関する。
【背景技術】
【０００２】
複数の店舗の発注データを本部で受付けるいわゆるチェーンストアシステムでは、各店舗に携帯型の端末およびストアサーバが設置される。端末は、店員の操作により入力される発注データをストアサーバに無線送信する。ストアサーバは、端末から送信される発注データを受信し、受信した発注データを店員の送信操作に基づき、通信ネットワークを介して本部へ送信する（例えば特許文献１）。
【０００３】
本部にはホストサーバが設置されており、そのホストサーバは、発注締め時刻である例えば午前１０時までに受信した発注データについては当日締め分として受付け、その後、休止時間である例えば３０分後の午前１０時３０分以降に受信した発注データについては翌日締め分として受付ける処理を行う。
【特許文献１】特開平１０―２２２５７０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
発注データが発注締め時刻を過ぎてホストサーバに送信されることがある。この場合、送信のタイミングがホストサーバの休止時間中であれば、送信エラーとなり、送信された発注データはホストサーバに取込まれない。
【０００５】
この送信エラーの後、店員が再び送信操作を行うと、送信エラーとなった発注データが再びホストサーバに送信される。この送信タイミングが休止時間の後であれば、送信された発注データはホストサーバに取込まれる。
【０００６】
ただし、この場合、ホストサーバに取込まれる発注データは、発注締め時刻より前のいわゆる前日区分の発注データであるにもかかわらず、ホストサーバ側では当日分として扱ってしまう。つまり、発注データの日付が店舗側と本部側で異なることになる。この不整合は、発注システムの信頼性を損なうものである。
【０００７】
この発明は、上記の事情を考慮したもので、発注データを送る側と受ける側の日付に関する整合を保つことができ、これにより発注システムの信頼性の向上が図れるデータ処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
請求項１に係る発明のデータ処理装置は、入力される発注データを送信する端末と、この端末から送信される発注データを受信し、その受信時刻が予め定められた発注締め時刻より前であることを条件に、同受信した発注データを本部へ送信するサーバと、を備える。
【発明の効果】
【０００９】
この発明のデータ処理装置によれば、発注データを送る側と受ける側の日付に関する整合を保つことができる。これにより、発注システムの信頼性の向上が図れる。
【発明を実施するための最良の形態】
【００１０】
以下、この発明の一実施形態について図面を参照して説明する。  
図１に示すように、コンビニエンスストア等の複数の店舗１があり、これら店舗１にストアサーバ２がそれぞれ設置されている。そして、各ストアサーバ２に、ＲＯＭ３、ＲＡＭ４、制御プログラム記憶用のハードディスクドライブ（ＨＤＤ）５、時計６、操作表示部７、プリンタ８、端末用インターフェース９、およびネットワークインターフェース１０が接続されている。
【００１１】
時計６は、年月日を把握するカレンダー機能を有し、現在の時刻を時・分・秒の単位で計時する。端末用インターフェース９は、携帯型の複数の端末１１から送信される発注データを受信する。これら端末１１は、店員が店舗１内で自由に持ち歩きながら操作することが可能で、起動と終了が自在な発注処理の機能を有し、その発注処理の起動中に入力される発注データをストアサーバ２に向け無線送信する。ネットワークインターフェース１０は、通信ネットワーク２０を介して、本部３０とのデータ送受信を行う。
【００１２】
本部３０には、ホストサーバ３１が設置されている。このホストサーバ３１に、ＲＯＭ３２、ＲＡＭ３３、制御プログラム記憶用のハードディスクドライブ（ＨＤＤ）３４、操作表示部３５、プリンタ３６、時計３７、およびネットワークインターフェース３８が接続されている。
【００１３】
時計３７は、店舗１の時計６と同じく、年月日を把握するカレンダー機能を有し、現在の時刻を時・分・秒の単位で計時する。ネットワークインターフェース３８は、通信ネットワーク２０を介して、各店舗１とのデータ送受信を行う。
【００１４】
そして、ストアサーバ２は、端末１１から送信される発注データを受信する機能、および端末１１の発注処理の終了に伴い起動される発注締め処理の機能を有し、その発注締め処理の起動中の送信操作に基づき、かつ受信した発注データの受信時刻ｔ１が予め定められた発注締め時刻ｔｘ例えば午前１０時より前であることを条件に、受信した発注データを本部３０へ送信する。さらに、ストアサーバ２は、発注データの受信に際し、その受信時刻ｔ１が発注締め時刻ｔｘ以降の場合に、端末１１に送信エラーを通知する手段を有する。
【００１５】
ホストサーバ３１は、発注締め時刻ｔｘである午前１０時までに受信した発注データについては当日締め分として受付け、その後、休止時間である例えば３０分後の午前１０時３０分以降に受信した発注データについては翌日締め分として受付ける処理を行う。
【００１６】
つぎに、上記の構成の作用を図２のフローチャートおよび図３，図４のタイムチャートを参照しながら説明する。  
店舗１の店員は、端末１１で発注処理を起動し、店舗１内の商品の在庫を確認しながら、補充が必要な商品の発注データを端末１１に入力する。入力された発注データは、端末１１からストアサーバ２へ送信される。
【００１７】
ストアサーバ２では、上記発注処理の起動に伴い（ステップ１０１のＹＥＳ）、受信処理が起動され（ステップ１０２）送信エラーチェックフラグｆが“０”にセットされる（ステップ１０３）。この受信処理の起動により、端末１１から送信される発注データが受信され（ステップ１０４）、その受信時刻ｔ１が時計６の計時から認識される（ステップ１０５）。そして、認識された受信時刻ｔ１と発注締め時刻ｔｘとが比較される（ステップ１０６）。受信された発注データは、ＲＡＭ４に記憶される。
【００１８】
受信時刻ｔ１が発注締め時刻ｔｘより前で（ステップ１０６のＹＥＳ）、しかも端末１１で発注処理がまだ終了していなければ（ステップ１０７のＮＯ）、上記ステップ１０４の発注データの受信が継続される。
【００１９】
ただし、受信時刻ｔ１が発注締め時刻ｔｘ以降の場合（ステップ１０６のＮＯ）、端末１１に送信エラーが通知されて（ステップ１０８）、送信エラーチェックフラグｆが“１”にセットされる（ステップ１０９）。
【００２０】
端末１１で発注処理が終了され（ステップ１０７のＹＥＳ）、ストアサーバ２において、受信処理が終了され（ステップ１１０）、新たに発注締め処理が起動される（ステップ１１１）。この発注締め処理では、店員による送信操作が監視される（ステップ１１２）。
【００２１】
ストアサーバ２で店員の送信操作があったとき（ステップ１１２のＹＥＳ）、送信エラーチェックフラグｆが“０”であるか否かが判定される（ステップ１１３）。“０”であれば（ステップ１１３のＹＥＳ）、これまで受信してＲＡＭ４に記憶している全ての発注データが発注締め時刻ｔｘより前のものであるとの判断の下に、ＲＡＭ４内の全ての発注データがストアサーバ２からホストサーバ３１に向け送信される（ステップ１１４）。送信された各発注データは、ホストサーバ３１の発注受付処理により、同ホストサーバ３１に当日分として取込まれる。発注データが入力されてからホストサーバ３１に取込まれるまでの動作を図３に示している。
【００２２】
一方、ストアサーバ２で店員の送信操作があったとき（ステップ１１２のＹＥＳ）、送信エラーチェックフラグｆが“０”でなければ（ステップ１１３のＮＯ）、これまで受信してＲＡＭ４に記憶している各発注データの少なくとも１つが発注締め時刻ｔｘ以降のものであるとの判断の下に、ストアサーバ２からホストサーバ３１への各発注データの送信が禁止される（ステップ１１５）。この禁止に伴い、送信されなかった各発注データを記録した未発注データリストがプリンタ８でプリントされる（ステップ１１６）。発注データが入力されてからホストサーバ３１への送信が禁止されるまでの動作を図４に示している。
【００２３】
店舗１の店員は、未発注データリストを見て、発注が未完了であることを把握することができ、改めて発注データの入力および送信を行うことができる。
【００２４】
このように、ストアサーバ２で受信される各発注データの受信時刻ｔ１が発注締め時刻ｔｘを過ぎていれば、送信エラーとして、ストアサーバ２からホストサーバ３１への発注データの送信を禁止するので、発注締め時刻ｔｘより前のいわゆる前日区分の発注データがホストサーバ３１に当日分として取込まれる不具合を解消することができる。よって、発注データの日付が店舗１側と本部３０側で適切に整合することになり、発注システムの信頼性が大幅に向上する。
【００２５】
なお、上記実施形態では、未発注データリストをプリント出力する構成としたが、操作表示部７で表示する構成としてもよい。あるいは、プリントと表示の両方を行う構成としてもよい。その他、この発明は上記実施形態に限定されるものではなく、要旨を変えない範囲で種々変形実施可能である。
【図面の簡単な説明】
【００２６】
【図１】一実施形態の制御回路を示すブロック図。
【図２】一実施形態の作用を説明するためのフローチャート。
【図３】一実施形態における発注データの入力から取込みまでの動作を示すタイムチャート。
【図４】一実施形態における発注データの入力から送信禁止までの動作を示すタイムチャート。
【符号の説明】
【００２７】
１…店舗、２…ストアサーバ、６…時計、７…操作表示部、８…プリンタ、１１…端末、２０…通信ネットワーク、３０…本部、３１…ホストサーバ、３７…時計
【図１】
2009053843.tif 000003
【図２】
2009053843.tif 000004
【図３】
2009053843.tif 000005
【図４】
2009053843.tif 000006