(57)【要約】【課題】確実に作業指示と在庫確認、及びその回答結果をヒモ付け、データ交換するタイミングによって発生するデータ不整合を防止することができるデータ不整合防止システム及びデータ不整合防止方法を提供する。【解決手段】キーコードを含んだ指示データを受信すると、新たなキーコードであれば、キーコード毎に初期値の枝番を関連付けて記憶し、さらに、初期値の枝番を付加して指示データに基づく確認依頼データを送信する。また、既存のキーコードであれば、記憶されているキーコードの枝番を更新し、更新後の枝番を付加して指示データに基づく確認依頼データを送信する。そして、確認依頼データに基づく確認結果データを受信すると、含まれる枝番が記憶されている枝番と一致する場合に、確認結果データを有効に処理し、一致しない場合に、確認結果データを無視する。【選択図】　図１
2004091153.tif 000002
【特許請求の範囲】
【請求項１】
配送指示者が発番する発送指示番号であるキーコードを含んだ指示データを受信する指示データ受信手段と、
前記キーコード毎に枝番を保持する枝番記憶手段と、
前記指示データに含まれるキーコードが新たなキーコードである場合に、前記枝番記憶手段に当該キーコードと初期値の枝番を関連付けて書き込むとともに、当該キーコードに初期値の枝番を付加して前記指示データに基づく確認依頼データを送信する第１の確認依頼手段と、
前記指示データに含まれるキーコードが既存のキーコードである場合に、前記枝番記憶手段に記憶されている当該キーコードの枝番を更新するともに、当該キーコードにこの更新後の枝番を付加して前記指示データに基づく確認依頼データを送信する第２の確認依頼送信手段と、
前記確認依頼データに応じて送られてくる確認結果データを受信し、前記確認結果データに含まれる枝番が前記枝番記憶手段に保持されている枝番と一致する場合には当該確認結果データを有効に処理し、前記確認結果データに含まれる枝番が前記枝番記憶手段に保持されている枝番と一致しない場合には当該確認結果データを無視する確認結果取得手段と
を具備することを特徴とするデータ不整合防止装置。
【請求項２】
前記確認結果取得手段は、前記確認結果データに含まれる枝番が前記枝番記憶手段に保持されている枝番と一致する場合には、さらに、当該確認結果データを記憶することを特徴とする請求項１に記載のデータ不整合防止装置。
【請求項３】
指示データに基づく確認依頼データと、該確認依頼データに応じて送られてくる確認結果データとをデータ交換するタイミングによって発生するデータ不整合を防止するデータ不整合防止方法において、
配送指示者が発番する発送指示番号であるキーコードを含んだ指示データを受信すると、
前記指示データに含まれるキーコードが新たなキーコードである場合には、キーコード毎に枝番を保持する枝番記憶手段に当該キーコードと初期値の枝番を関連付けて書き込むとともに、当該キーコードに初期値の枝番を付加して前記指示データに基づく確認依頼データを送信し、
前記指示データに含まれるキーコードが既存のキーコードである場合に、前記枝番記憶手段に記憶されている当該キーコードの枝番を更新するともに、当該キーコードにこの更新後の枝番を付加して前記指示データに基づく確認依頼データを送信し、
前記確認依頼データに応じて送られてくる確認結果データを受信すると、
前記確認結果データに含まれる枝番が前記枝番記憶手段に保持されている枝番と一致する場合に、当該確認結果データを有効に処理し、
前記確認結果データに含まれる枝番が前記枝番記憶手段に保持されている枝番と一致しない場合に、当該確認結果データを無視する
ことを特徴とするデータ不整合防止方法。
【請求項４】
前記確認結果データに含まれる枝番が前記枝番記憶手段に保持されている枝番と一致する場合には、さらに、当該確認結果データを記憶することを特徴とする請求項３に記載のデータ不整合防止方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データ交換するタイミングによって発生するデータ不整合を防止するデータ不整合防止装置及びデータ不整合防止方法に関する。
【０００２】
【従来の技術】
通常、物流管理システムでは、得意先からの配送指示を物流マネジメントシステムが受け、作業現場に流す方式が取られている。
その指示の流れ方は、以下の通りである。
▲１▼　得意先から配送指示が一日の業務開始前に物流マネジメントシステムに流される。
▲２▼　その指示に対して、物流マネジメントシステムは、作業現場（在庫管理者）に在庫管理依頼を行う。
▲３▼　作業現場はその依頼に基づいて、在庫状況を調べて回答する。
▲４▼　在庫がある場合には、物流マネジメントシステムは、配送指示を作業現場に流し、在庫が無い場合には、在庫が補充されるまで待つ。
▲５▼　作業現場は、在庫不足の商品が入庫により配送可能となった場合、以前受領した在庫確認依頼に対して在庫状況を確認する。
【０００３】
配送指示が上述のように一日に一回だけ流れるのであれば、物流マネジメントは非常に簡単である。しかし、最近では、インターネット上から顧客の要望がリアルタイムに入ってくることもあり、得意先としては、少しでも早くそれらの要望にこたえるため一日に複数回の配送指示を流したいと考えている。そのため、物流マネジメント側には、在庫さえあれば即配送する体制をとることが要求されてきている。
【０００４】
この場合、一日に何度も配送指示と在庫確認・回答を行うことになるので、それらがどの指示に対するものなのか、確実にヒモ付けしてしておかないと混乱が起こる。
例えば、物流マネジメントの立場では、得意先からの指示がＡ商品１００個であれば、配送可能かどうかを確認するために在庫確認を行うが、作業側からの回答が来る前に１００個の指示が２００個に変更されてしまうと、作業現場から戻ってきた回答が「在庫有り」だとしても、１００個配送可能であればよいのか、２００個配送可能であればよいのかがわからなくなってしまう。
これは、得意先が配送指示の変更時に、配送指示者が発番する発送指示番号であるキーコードを変更すれば問題ないが、他業務との連携のからみからキーコードが変更できないことがある。
その場合には、得意先が指示数量を変更する場合には、物流マネジメントシステム側の数量を直接書き換えることになり、なおかつ、キーコードは変更されないので、混乱が生じる原因となっていた、
【０００５】
【発明が解決しようとする課題】
本発明はこのような事情を考慮してなされたもので、その目的は、確実に作業指示と在庫確認、及びその回答結果をヒモ付け、データ交換するタイミングによって発生するデータ不整合を防止することができるデータ不整合防止システム及びデータ不整合防止方法を提供することにある。
【０００６】
【課題を解決するための手段】
この発明は上記の課題を解決すべくなされたもので、請求項１に記載の発明は、キーコードを含んだ指示データを受信する指示データ受信手段と、キーコード毎に最新の枝番を保持する枝番記憶手段と、前記指示データに含まれるキーコードが新たなキーコードである場合に、前記枝番記憶手段に当該キーコードと初期値の枝番を関連付けて書き込むとともに、当該キーコードに初期値の枝番を付加して前記指示データに基づく確認依頼データを送信する第１の確認依頼手段と、前記指示データに含まれるキーコードが既存のキーコードである場合に、前記枝番記憶手段に記憶されている当該キーコードの枝番を更新するともに、当該キーコードにこの更新後の枝番を付加して前記指示データに基づく確認依頼データを送信する第２の確認依頼送信手段と、前記確認依頼データに応じて送られてくる確認結果データを受信し、前記確認結果データに含まれる枝番が前記枝番記憶手段に保持されている枝番と一致する場合には当該確認結果データを有効に処理し、前記確認結果データに含まれる枝番が前記枝番記憶手段に保持されている枝番と一致しない場合には当該確認結果データを無視する確認結果取得手段とを具備することを特徴とする。
【０００７】
請求項２に記載の発明は、請求項１に記載の発明において、前記確認結果取得手段は、前記確認結果データに含まれる枝番が前記枝番記憶手段に保持されている枝番と一致する場合には、さらに、当該確認結果データを記憶することを特徴とする。
【０００８】
請求項３に記載の発明は、指示データに基づく確認依頼データと、該確認依頼データに応じて送られてくる確認結果データとをデータ交換するタイミングによって発生するデータ不整合を防止するデータ不整合防止方法において、キーコードを含んだ指示データを受信すると、前記指示データに含まれるキーコードが新たなキーコードである場合には、キーコード毎に枝番を保持する枝番記憶手段に当該キーコードと初期値の枝番を関連付けて書き込むとともに、当該キーコードに初期値の枝番を付加して前記指示データに基づく確認依頼データを送信し、前記指示データに含まれるキーコードが既存のキーコードである場合に、前記枝番記憶手段に記憶されている当該キーコードの枝番を更新するともに、当該キーコードにこの更新後の枝番を付加して前記指示データに基づく確認依頼データを送信し、前記確認依頼データに応じて送られてくる確認結果データを受信すると、前記確認結果データに含まれる枝番が前記枝番記憶手段に保持されている枝番と一致する場合に、当該確認結果データを有効に処理し、前記確認結果データに含まれる枝番が前記枝番記憶手段に保持されている枝番と一致しない場合に、当該確認結果データを無視することを特徴とする。
【０００９】
請求項４に記載の発明は、請求項３に記載の発明において、前記確認結果データに含まれる枝番が前記枝番記憶手段に保持されている枝番と一致する場合には、さらに、当該確認結果データを記憶することを特徴とする。
【００１０】
【発明の実施の形態】
以下、図面を参照して、本発明の一実施形態における、データ不整合防止装置を適用したデータ不整合防止システムについて説明する。図１は、本実施形態における、データ不整合防止システムの全体構成図であり、本データ不整合防止システムは、配送指示端末１、配送管理サーバ２、在庫管理サーバ３をネットワーク１０を介して互いに接続させることによって構成される。
本データ不整合防止システムの特徴は、配送管理サーバ２がデータ不整合防止装置としての機能を備えている点である。
【００１１】
配送指示端末１は、物流マネジメントを行う配送管理サーバ２に対して、得意先が商品に関する配送指示を行うための端末であり、得意先毎に管理される。
配送管理サーバ２は、得意先から配送指示を受けて、商品倉庫などの作業現場に設置された在庫管理サーバ３に対して商品在庫の確認を行い、在庫状況に関する確認結果に応じて配送指示を行うためのサーバであり、配送管理者によって管理される。配送管理サーバ２は、配送管理サーバ２と在庫管理サーバ３との間で有効な枝番（カウンタＮｏ）を、配送指示端末１から商品毎に発番する配送指示番号であるキーコードを含む配送指示データに付加した在庫確認データを用いることでデータの不整合を防止する。
在庫管理サーバ３は、配送管理サーバ２から在庫確認指示を受けて、在庫管理情報に関するデータを記憶しているデータベース（以下ＤＢとする）である在庫データＤＢ・５を参照し、在庫確認指示に対する回答を行うためのサーバであり、配送作業現場の在庫管理者によって管理される。
【００１２】
以下、配送管理サーバ２と在庫管理サーバ３との間で有効なカウンタＮｏの設け方について説明する。
・カウンタＮｏの体系
ｙｙｙｙｍｍｄｄＴ９９００の場合、ｙｙｙｙｍｍｄｄ：年月日、Ｔ：データ更新者、９９：年月日毎の連番（配送管理サーバ２が採番）、００：年月日毎の連番と対応した連番（在庫管理サーバ３が採番）をそれぞれ示している。カウンタＮｏは、得意先が商品毎に発番する配送指示番号であるキーコード毎に付加され、配送情報自体は変更されない。
・配送管理サーバ２での採番注意点
カウンタＮｏを新規に作成する場合、配送管理サーバ２は、初期値として上述の”００”部分には、「００」をセットする。また、データ更新・削除を行う場合、古いカウンタＮｏの赤データと新しいカウンタＮｏの黒データを作成し、新しい黒データには、カウンタＮｏの”９９”部分を一つ繰り上げる。ただし、赤データは、古いカウンタＮｏの在庫確認データの削除を指示するデータであり、黒データは、新しいカウンタＮｏの在庫確認データの追加を指示するデータであるとする。
・在庫管理サーバ３での採番注意点
在庫管理サーバ３は、”９９”は変更せず、”００”に年月日毎の連番と対応した連番をふる。また、データ更新・削除を行う場合、古いカウンタＮｏの赤データと新しいカウンタＮｏの黒データを作成し、新しい黒データには、カウンタＮｏの”００”部分を一つ繰り上げる。
・配送管理サーバ２でのデータ取り込み条件
配送情報番号（得意先キーコード）、ｙｙｙｙｍｍｄｄ、”９９”の部分が一致したデータだけを取り込み、それ以外の一致しないデータは、無視して取り込まない。
【００１３】
次に、本実施形態における、データ不整合防止システムの通常時の動作について説明する。図２は、配送指示端末１が配送指示を出してから配送確定の知らせを受け取るまでの流れを示すフローチャートである。
取引先のユーザが配送指示を配送指示端末１より行うと、配送指示端末１は、配送指示番号であるキーコードを発番し、このキーコードを含む配送指示データを配送管理サーバ２に送信する（図２のステップＳ１）。配送管理サーバ２は、配送指示データを受信すると（ステップＳ２）、配送指示データに付加するカウンタＮｏを生成する。すなわち、配送管理サーバ２は、ｙｙｙｙｍｍｄｄ部分に年月日を付け、Ｔ部分にデータ更新者Ｔを付け、”９９”の部分を例えば「０１」とし、さらに、得意先キーコードが新規のものであるので、”００”部分に初期値として「００」をセットする。この場合、カウンタＮｏは、２００２０３０４Ｔ０１００となる。
配送管理サーバ２は、このカウンタＮｏを付加した在庫確認依頼データを配送データＤＢ・４に記憶し、在庫管理サーバ３に対して生成したカウンタＮｏを付加した在庫確認依頼データを送信する（ステップＳ３）。
【００１４】
在庫管理サーバ３は、在庫確認依頼データを受信すると（ステップＳ４）、在庫データＤＢ・５を参照し、依頼された数だけ商品があれば配送可の在庫確認結果データを配送管理サーバ２に送信し、依頼された数だけ商品がなければ配送不可の在庫確認結果データを送信する（ステップＳ５）。この時、付加されるカウントＮｏは、例えば、在庫管理サーバの管理者Ｉから送信されたことを示す２００２０３０４Ｉ０１００となる。
配送管理サーバ２は、在庫確認結果データを受信すると（ステップＳ６）、この在庫確認結果を配送データＤＢ・４に記憶し、配送可能であれば（ステップＳ７でＹｅｓの場合）、配送確定データを作成し、配送指示端末１に送信する（ステップＳ８）。配送指示端末１が、在庫管理サーバ３より配送確定データを受信し（ステップＳ９）、取引先のユーザは、商品が配送されることが確定したことを知ることが出来る。一方、商品の在庫がなく、配送不可能であれば（ステップＳ７でＮｏの場合）、配送管理サーバ２は、在庫管理サーバ３より商品が入荷された旨の在庫確認データが再度送信されてくるまで待つ。
【００１５】
次に、異常時におけるデータ不整合防止システムの動作について説明する。図３のフローチャートは、取引先のユーザが配送依頼を変更したために、配送管理サーバ２が、既に送信した在庫確認依頼データＡに対する回答である在庫確認結果データＡを受ける前に、さらに在庫確認依頼データＢを在庫管理サーバ３に送信した場合の処理の流れを示している。
配送管理サーバ２が、上述の手順でカウンタＮｏ２００２０３０４Ｔ０１００を生成し、これを付加した在庫確認依頼データＡを配送データＤＢ・４に記憶した後、在庫管理サーバ３に送信すると（図３のステップＳ３１）、在庫管理サーバ３は、これを受信し（ステップＳ３２）、在庫確認を行う。取引先のユーザが、配送依頼を変更したために、配送管理サーバ２が、さらに、上述の手順でカウンタＮｏ２００２０３０４Ｔ０２００を生成し、これを付加した在庫確認依頼データＢを配送データＤＢ・４に記憶した後、在庫管理サーバ３に送信すると（ステップＳ３３）、在庫管理サーバ３は、これを受信し（ステップＳ３４）、さらに、在庫確認を行う。
在庫確認依頼データＡに対する在庫の確認が取れ、在庫管理サーバ３が、在庫確認結果データＡを送信すると（ステップＳ３５）、配送管理サーバ２は、これを受信し（ステップＳ３６）、この在庫確認結果データＡのカウンタＮｏが最新であるかを調べて、これが有効であるか否かを判断する（ステップＳ３７）。すなわち、配送管理サーバ２は、配送データＤＢ・４に記憶されている在庫確認依頼データＡの配送情報番号、２００２０３０４の部分と、”０１”の部分を調べ、この場合、”０１”の部分が”０２”となっていないため古いカウンタＮｏと判断し（ステップＳ７でＮｏの場合）、在庫確認結果データＡを無効と判断し、キャンセルする（ステップＳ３８）。
次に在庫確認依頼データＢに対する在庫の確認が取れ、在庫管理サーバ３が、在庫確認結果データＢを送信すると（ステップＳ３９）、配送管理サーバ２は、これを受信し（ステップＳ４０）、この在庫確認結果データＢのカウンタＮｏが最新であるかを調べて、これが有効であるか否かを判断する（ステップＳ３７）。この場合、”０２”の部分も一致しているため、最新のカウンタＮｏと判断し（ステップＳ３７でＹｅｓの場合）、在庫確認結果データＢを有効と判断し、配送確定データＢを配送指示端末１に対して送信する（ステップＳ４１）。
【００１６】
以下に、上述の通常時・異常時の動作を３パターンに分類し、パターン１は図４、パターン２は図５、パターン３は図６を参照して説明する。図４、５、６は、すべて１商品に関する在庫確認の場合であり、商品が異なると配送情報番号は異なるものとする。
パターン１におけるデータ交換タイミングの条件と、カウンタＮｏの経時は以下に示す通りである。ただし、▲１▼、▲２▼・・は、図のステップＳ１、Ｓ２、・・に対応している。
（パターン１）
・在庫不足が発生する場合
・配送管理サーバ２が途中でデータ修正しない場合
・在庫管理サーバ３が途中でデータ修正しない場合
カウンタＮｏの経時
▲１▼カウンタＮｏ　：　２００２０３０４Ｔ０１００　（黒）
▲２▼カウンタＮｏ　：　２００２０３０４Ｉ０１００　（黒）
←▲１▼に対する結果データ（在庫不足）
▲３▼カウンタＮｏ　：　２００２０３０４Ｉ０１００　（赤）
カウンタＮｏ　：　２００２０３０４Ｉ０１０１　（黒）
←▲２▼に対する更新結果データ
【００１７】
配送管理サーバ２が、上述の手順でカウンタＮｏ２００２０３０４Ｔ０１００を生成し、これを付加した在庫確認依頼データＡを配送データＤＢ・４に記憶した後、在庫管理サーバ３に送信する（図４のステップＳ４１）。在庫管理サーバ３は、これを受信し、在庫データＤＢ・５を参照して在庫確認を行った後、在庫不足である旨の在庫確認結果データＡ（在庫不足）を送信する（ステップＳ４２）。このときのカウンタＮｏ２００２０３０４Ｉ０１００である。
【００１８】
配送管理サーバ２は、上述の手順で配送データＤＢ・４に記憶されたカウンタＮｏを参照し、この場合は、カウンタＮｏが有効（以下ＯＫとする）であるので、配送データＤＢ・４に在庫確認結果データＡを記憶する。
在庫管理サーバ３は、商品入庫により、在庫不足が解消されると、既に送信したカウンタＮｏ２００２０３０４Ｉ０１００の在庫確認結果データＡを更新するために、まずカウンタＮｏ２００２０３０４Ｉ０１００の赤データと、カウンタＮｏの”００”部分を一つ繰り上げたカウンタＮｏ２００２０３０４Ｉ０１０１の黒データとを配送管理サーバ２に送信する。
【００１９】
配送管理サーバ２は、上述の手順で配送データＤＢ・４に記憶されたカウンタＮｏを参照し、この場合は、カウンタＮｏが有効（以下ＯＫとする）であるので、配送データＤＢ・４に記憶された在庫確認結果データＡのうち、まずカウンタＮｏ２００２０３０４Ｉ０１００の赤データを受けて、カウンタＮｏ２００２０３０４Ｉ０１００の黒データを削除し、カウンタＮｏ２００２０３０４Ｉ０１０１の黒データを受けて、在庫確認結果データＡを更新し、配送データＤＢ・４に記憶する（ステップＳ４３）。
【００２０】
パターン２におけるデータ交換タイミングの条件と、カウンタＮｏの経時は以下に示す通りである。
（パターン２）
・在庫不足が発生する場合
・配送管理サーバ２が途中でデータ修正する場合
・在庫管理サーバ３が途中でデータ修正しない場合
カウンタＮｏの経時
▲１▼カウンタＮｏ　：　２００２０３０４Ｔ０１００　（黒）
▲２▼カウンタＮｏ　：　２００２０３０４Ｉ０１００　（黒）
←▲１▼に対する結果データ（在庫不足）
▲３▼カウンタＮｏ　：　２００２０３０４Ｔ０１００　（赤）
カウンタＮｏ　：　２００２０３０４Ｔ０２００　（黒）
←配送管理サーバ２側の変更データ
▲４▼カウンタＮｏ　：　２００２０３０４Ｉ０１００　（赤）
カウンタＮｏ　：　２００２０３０４Ｉ０１０１　（黒）
←▲２▼に対する更新結果データ
▲５▼カウンタＮｏ　：　２００２０３０４Ｉ０１０１　（赤）
カウンタＮｏ　：　２００２０３０４Ｉ０２００　（黒）
←▲３▼に対する結果データ
【００２１】
図５に示すように、パターン１とパターン２との違いは、配送管理サーバ２が▲１▼の在庫確認依頼データにおいて、必要数量の変更が生じた結果、在庫確認依頼データの更新を行い、在庫管理サーバ３は、この変更に気づかず▲２▼に対する更新結果データを送信している点である。このパターン２は、上述の図３に示した場合の動作と同様であり、例えば、図５のステップＳ５４で無効とされた（以下、ＮＧとする）▲２▼に対する更新結果データは、図３のステップＳ３８における「在庫確認結果データＡキャンセル」に相当する。▲２▼に対する更新結果データがＮＧと判断される理由は、カウンタＮｏの経時を用いて説明した場合、▲３▼によって配送データＤＢ・４に記憶された最新のカウンタＮｏが”０２”となったため、図５のステップＳ５４でカウンタＮｏ２００２０３０４Ｉ０１００の赤データとカウンタＮｏ２００２０３０４Ｉ０１０１の黒データに関して、配送管理サーバ２は、カウンタＮｏが古いと判断して受け付ないことによる。
【００２２】
以上説明したように、図５のステップＳ５４で送信された、▲２▼に対する更新結果データを配送データＤＢ・４に記憶した場合、配送データＤＢ４の記憶内容に不整合が生じることを上述のデータ不整合防止処理によって防ぐことが出来る。
【００２３】
パターン３におけるデータ交換タイミングの条件と、カウンタＮｏの経時は以下に示す通りである。
（パターン３）
・在庫不足が発生する場合
・配送管理サーバ２が途中でデータ修正する場合
・在庫管理サーバ３が途中でデータ修正する場合
カウンタＮｏの経時
▲１▼カウンタＮｏ　：　２００２０３０４Ｔ０１００　（黒）
▲２▼カウンタＮｏ　：　２００２０３０４Ｉ０１００　（黒）
←▲１▼に対する結果データ（在庫不足）
▲３▼カウンタＮｏ　：　２００２０３０４Ｔ０１００　（赤）
カウンタＮｏ　：　２００２０３０４Ｔ０２００　（黒）
←配送管理サーバ２側の変更データ
▲４▼カウンタＮｏ　：　２００２０３０４Ｉ０１００　（赤）
カウンタＮｏ　：　２００２０３０４Ｉ０１０１　（黒）
←▲２▼に対する更新結果データ
▲５▼カウンタＮｏ　：　２００２０３０４Ｉ０１０１　（赤）
カウンタＮｏ　：　２００２０３０４Ｉ０１０２　（黒）
←在庫管理サーバ３側の変更データ
▲６▼カウンタＮｏ　：　２００２０３０４Ｉ０１０２　（赤）
カウンタＮｏ　：　２００２０３０４Ｉ０２００　（黒）
←▲３▼に対する結果データ
【００２４】
図６に示すように、パターン２とパターン３との違いは、配送管理サーバ２が、ステップＳ６３において、在庫確認依頼データの更新を行ったのに、在庫管理サーバ３がこの変更に気づかず、ステップＳ６４において、▲２▼に対する更新結果データを送信し、さらに、在庫管理サーバ３が、商品入庫により在庫数が変更したことを配送管理サーバ２に通知する在庫確認結果データを、ステップＳ６５において送信している点である。この場合、配送管理サーバ２は▲３▼によって配送データＤＢ・４に記憶された最新のカウンタＮｏが”０２”となったため、ステップＳ６４でカウンタＮｏ２００２０３０４Ｉ０１００の赤データとカウンタＮｏ２００２０３０４Ｉ０１０１の黒データに関して、さらに、ステップＳ６５でカウンタＮｏ２００２０３０４Ｉ０１０１の赤データとカウンタＮｏ２００２０３０４Ｉ０１０２の黒データに関して、ステップＳ６４及びステップＳ６５における在庫確認結果データをＮＧと判断する。
【００２５】
以上説明したように、ステップＳ６４及びステップＳ６５で送信された、▲２▼に対する更新結果データまたは、在庫管理サーバ３側の変更データを配送データＤＢ・４に記憶した場合、配送データＤＢ４の記憶内容に不整合が生じることを上述のデータ不整合防止処理により防ぐことが出来る。
【００２６】
なお、上述の実施形態においては、作業現場が１つである場合について説明したが、作業現場が複数である場合は、枝番の数も作業現場の数に対応する形で増やしていけばよい。また、作業の性質により作業現場毎にデータを更新できる範囲を限定することも考えられる。この場合、例えば
作業現場Ａ・・・項目Ａのみ更新可能
作業現場Ｂ・・・項目Ｂのみ更新可能
作業現場Ｃ・・・項目Ｃのみ更新可能
というようにデータを更新できる範囲を限定すればよい。
【００２７】
なお、本実施例では、オンライン物流システムにおいて、データ不整合防止装置を適用させた場合を示したが、本発明と同様のデータ処理方法を採用しているシステムであれば本データ不整合防止装置は適用可能である。
【００２８】
なお、上述のデータ不整合防止装置は内部に、コンピュータシステムを有している。そして、上述したデータ不整合防止処理に関する一連の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって、上記処理が行われる。ここでコンピュータ読み取り可能な記録媒体とは、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等をいう。また、このコンピュータプログラムを通信回線によってコンピュータに配信し、この配信を受けたコンピュータが当該プログラムを実行するようにしても良い。
【００２９】
【発明の効果】
以上説明したように、請求項１及び請求項３の発明によれば、キーコードを含んだ指示データを受信すると、指示データに含まれるキーコードが新たなキーコードである場合には、キーコード毎に枝番を保持する枝番記憶手段にキーコードと初期値の枝番を関連付けて書き込むとともに、キーコードに初期値の枝番を付加して指示データに基づく確認依頼データを送信し、指示データに含まれるキーコードが既存のキーコードである場合に、枝番記憶手段に記憶されているキーコードの枝番を更新するともに、キーコードにこの更新後の枝番を付加して指示データに基づく確認依頼データを送信し、確認依頼データに応じて送られてくる確認結果データを受信すると、確認結果データに含まれる枝番が枝番記憶手段に保持されている枝番と一致する場合に、確認結果データを有効に処理し、確認結果データに含まれる枝番が枝番記憶手段に保持されている枝番と一致しない場合に、確認結果データを無視するので、キーコード毎に確実に作業指示データと在庫確認データ及びその回答結果データがヒモ付けられるため、データ交換するタイミングによって発生するデータ不整合を防止することができる効果を得ることが出来る。
【００３０】
請求項２及び請求項４の発明によれば、請求項１または請求項３に記載の発明において、確認結果データに含まれる枝番が枝番記憶手段に保持されている枝番と一致する場合には、さらに、確認結果データを記憶するので、キーコード毎により確実に作業指示データと在庫確認データ及びその回答結果データがヒモ付けられるため、データ交換するタイミングによって発生するデータ不整合を防止することができる効果を得ることが出来る。
【図面の簡単な説明】
【図１】本実施形態における、データ不整合防止システムの全体構成図である。
【図２】配送指示端末１が配送指示を出してから配送確定の知らせを受け取るまでの流れを示すフローチャートである。
【図３】配送管理サーバ２が、在庫確認結果データＡを受ける前に、さらに在庫確認依頼データＢを在庫管理サーバ３に送信した場合の処理の流れを示すフローチャートである。
【図４】配送管理サーバ２と在庫管理サーバ３との間でのカウンタＮｏに基づいた配信データＤＢ・４の書き換え許可の認否の流れを示すフローチャートである。
【図５】配送管理サーバ２と在庫管理サーバ３との間でのカウンタＮｏに基づいた配信データＤＢ・４の書き換えが拒否される場合の流れを示すフローチャートである。
【図６】配送管理サーバ２と在庫管理サーバ３との間でのカウンタＮｏに基づいた配信データＤＢ・４の書き換えが拒否される場合の流れを示すフローチャートである。
【符号の説明】
１…配送指示端末
２…配送管理サーバ
３…在庫管理サーバ
４…配送データＤＢ
５…在庫データＤＢ
１０…ネットワーク
【図１】
2004091153.tif 000003
【図２】
2004091153.tif 000004
【図３】
2004091153.tif 000005
【図４】
2004091153.tif 000006
【図５】
2004091153.tif 000007
【図６】
2004091153.tif 000008