(57)【要約】【課題】  本発明は、ＥＤＩで商取引する２社のうちどちらかが、製品一つひとつを区別して業務履歴情報を収集可能であれば、ＥＤＩでやり取りする商取引情報(以下、ＥＤＩメッセージ)を活用することにより、製品一つひとつを区別できるレベル（以下、個品レベル）で情報を収集不可能な企業が実施した業務の履歴情報を、個品レベルで補完可能とする方法を提供することにある。【解決手段】  注文から入出荷、検査、検収、支払いに亘る取引の一連業務で、取引を一意に特定するＩＤ（以下、取引番号）が付番されるターンアラウンド型取引において、取引番号を含んだＥＤＩメッセージと、一連業務のどこかで取得した個品レベルの業務履歴情報と、について、取引番号をキーに個品レベルで算出し、補完する。この時、前記取得した個品レベルの業務履歴情報のレコード数と、ＥＤＩメッセージの中から取得した数量の値と、が不一致の場合は、確率値や仮想ＩＤ等を利用して補完する。【選択図】  図１
2011215981.tif 000002
【特許請求の範囲】
【請求項１】
複数の企業間での取引であって、当該取引を一意に特定する取引番号が付番される取引における業務履歴情報を補完する業務履歴補完方法において、
第1の企業で利用される第1の情報処理装置が、
前記複数の企業に含まれる取引関係にある第2、第3の企業のうち、
第2の企業で利用される第2の情報処理装置から、前記取引対象の各個品についての当該取引における履歴を示す業務履歴情報および、前記第２の情報処理装置と第３の情報処理装置の間でＥＤＩを介してやり取りする商取引情報であるＥＤＩメッセージと、を受信する処理と、
前記第３の情報処理装置から前記ＥＤＩメッセージを受信する処理と、
前記第2の情報処理装置および前記第3の情報処理装置から受信したＥＤＩメッセージおよび受信した前記業務履歴情報を用いて、当該第1の情報処理装置が、前記取引において一連業務で取得した各個品の業務履歴情報のうち、不足する分を算出する処理とを有することを特徴とする業務履歴補完方法。
【請求項２】
請求項１に記載の業務履歴補完方法において、
受信した前記業務履歴情報に含まれる前記個品の数量と、受信した前記ＥＤＩメッセージに含まれる数量とを比較する処理と、
当該比較の結果が不一致の場合は、業務履歴を推定する処理と、
をさらに有することを特徴とする業務履歴補完方法。
【請求項３】
請求項２に記載の業務履歴補完方法において、
前記業務履歴を推定する処理は、比較した結果、前記業務履歴情報の数量の方が多い場合は、前記業務履歴情報の各個品ＩＤに対応する製品が履歴情報を補完する業務において存在していた確率値を算出する処理を有することを特徴とする業務履歴補完方法。
【請求項４】
請求項２または３のいずれかにに記載の業務履歴補完方法において、
前記業務履歴を推定する処理は、比較した結果、前記業務履歴情報の数量の方が少ない場合は、前記業務履歴情報の数量と、前記ＥＤＩメッセージに含まれる数量と、の差分の数だけの個品を識別する仮想個品ＩＤを生成する処理を有することを特徴とする業務履歴補完方法。
【請求項５】
請求項２乃至４のいずれかに記載の業務履歴補完方法において、
前記業務履歴を推定する処理は、数量が異なっている旨を、前記第2もしくは第3の情報処理装置に送信処理を有することを特徴とする業務履歴補完方法。
【請求項６】
請求項１乃至５のいずれかに記載の業務履歴補完方法において、
前記ＥＤＩメッセージは、
当該ＥＤＩメッセージが表す業務の種類を特定する情報区分と、
当該ＥＤＩメッセージに関連した取引の受注者を一意に特定する受注者コードと、
当該ＥＤＩメッセージに関連した取引の発注者を一意に特定する発注者コードと、
当該ＥＤＩメッセージに関連した取引を一意に特定する取引番号と、
当該ＥＤＩメッセージが表す業務に関連する製品の種類を一意に特定する製品コードと、
当該ＥＤＩメッセージが表す業務に関連する製品の数量と、
当該ＥＤＩメッセージが表す業務が行われた日時と、
を含み、
前記業務履歴情報は、
前記個品を識別する個品ＩＤと、
前記個品の種類を識別する製品コードと、
当該業務履歴情報のもととなる業務が行われた拠点を識別する拠点ＩＤと、
当該業務履歴情報のもととなる業務が行われた日時と、
当該業務履歴情報がどのような業務において生成されたものであるかを特定する
作業タイプと、
当該業務履歴情報のもととなる業務、に関連する取引を識別する取引番号と、
上記個品ＩＤの製品が当該業務履歴情報のもととなる業務、において存在していた確率と、
を含むことを特徴とする業務履歴補完方法。
【請求項７】
複数の企業間での取引であって、当該取引を一意に特定する取引番号が付番される取引における業務履歴情報を補完する業務履歴補完方法を、第1の企業で利用される第1の情報処理装置に対して、以下の処理を実行させるためのプログラムにおいて、
前記複数の企業に含まれる取引関係にある第2、第3の企業のうち、
第2の企業で利用される第2の情報処理装置から、前記取引対象の各個品についての当該取引における履歴を示す業務履歴情報および、前記第２の情報処理装置と第３の情報処理装置の間でＥＤＩを介してやり取りする商取引情報であるＥＤＩメッセージと、を受信する処理と、
前記第３の情報処理装置から前記ＥＤＩメッセージを受信する処理と、
前記第2の情報処理装置および前記第3の情報処理装置から受信したＥＤＩメッセージおよび受信した前記業務履歴情報を用いて、当該第1の情報処理装置が、前記取引において一連業務で取得した各個品の業務履歴情報のうち、不足する分を算出する処理とを実行させることを特徴とするプログラム。
【請求項８】
請求項７に記載のプログラムにおいて、
受信した前記業務履歴情報に含まれる前記個品の数量と、受信した前記ＥＤＩメッセージに含まれる数量とを比較する処理と、
当該比較の結果が不一致の場合は、業務履歴を推定する処理と、
をさらに有することを特徴とするプログラム。
【請求項９】
請求項８に記載のプログラムにおいて、
前記業務履歴を推定する処理は、比較した結果、前記業務履歴情報の数量の方が多い場合は、前記業務履歴情報の各個品ＩＤに対応する製品が履歴情報を補完する業務において存在していた確率値を算出する処理を有することを特徴とするプログラム。
【請求項１０】
請求項８または９のいずれかにに記載のプログラムにおいて、
前記業務履歴を推定する処理は、比較した結果、前記業務履歴情報の数量の方が少ない場合は、前記業務履歴情報の数量と、前記ＥＤＩメッセージに含まれる数量と、の差分の数だけの個品を識別する仮想個品ＩＤを生成する処理を有することを特徴とするプログラム。
【請求項１１】
請求項８乃至１０のいずれかに記載のプログラムにおいて、
前記業務履歴を推定する処理は、数量が異なっている旨を、前記第2もしくは第3の情報処理装置に送信処理を有することを特徴とするプログラム。
【請求項１２】
請求項７乃至１１のいずれかに記載のプログラムにおいて、
前記ＥＤＩメッセージは、
当該ＥＤＩメッセージが表す業務の種類を特定する情報区分と、
当該ＥＤＩメッセージに関連した取引の受注者を一意に特定する受注者コードと、
当該ＥＤＩメッセージに関連した取引の発注者を一意に特定する発注者コードと、
当該ＥＤＩメッセージに関連した取引を一意に特定する取引番号と、
当該ＥＤＩメッセージが表す業務に関連する製品の種類を一意に特定する製品コードと、
当該ＥＤＩメッセージが表す業務に関連する製品の数量と、
当該ＥＤＩメッセージが表す業務が行われた日時と、
を含み、
前記業務履歴情報は、
前記個品を識別する個品ＩＤと、
前記個品の種類を識別する製品コードと、
当該業務履歴情報のもととなる業務が行われた拠点を識別する拠点ＩＤと、
当該業務履歴情報のもととなる業務が行われた日時と、
当該業務履歴情報がどのような業務において生成されたものであるかを特定する
作業タイプと、
当該業務履歴情報のもととなる業務、に関連する取引を一意に特定する取引番号と、
上記個品ＩＤの製品が当該業務履歴情報のもととなる業務、において存在していた確率と、
を含むことを特徴とするプログラム。
【請求項１３】
複数の企業間での取引であって、当該取引を一意に特定する取引番号が付番される取引における業務履歴情報を補完する業務履歴補完装置において、
前記複数の企業に含まれる取引関係にある第2、第3の企業のうち、
第2の企業で利用される第2の情報処理装置から、前記取引対象の各個品についての当該取引における履歴を示す業務履歴情報および、前記第２の情報処理装置と第３の情報処理装置の間でＥＤＩを介してやり取りする商取引情報であるＥＤＩメッセージと、を受信する手段と、
前記第３の情報処理装置から前記ＥＤＩメッセージを受信する手段と、
前記第2の情報処理装置および前記第3の情報処理装置から受信したＥＤＩメッセージおよび受信した前記業務履歴情報を用いて、当該第1の情報処理装置が、前記取引において一連業務で取得した各個品の業務履歴情報のうち、不足する分を算出する手段とを有することを特徴とする業務履歴補完装置。
【請求項１４】
複数の企業間での取引であって、当該取引を一意に特定する取引番号が付番される取引における業務履歴情報を補完する業務履歴補完装置であって、
前記複数の企業に含まれる取引関係にある第2、第3の企業のうち、
第2の企業で利用される第2の情報処理装置から、前記取引対象の各個品についての当該取引における履歴を示す業務履歴情報および、前記第２の情報処理装置と第３の情報処理装置の間でＥＤＩを介してやり取りする商取引情報であるＥＤＩメッセージと、を受信する手段と、
前記第３の情報処理装置から前記ＥＤＩメッセージを受信する手段と、
前記第2の情報処理装置および前記第3の情報処理装置から受信したＥＤＩメッセージおよび受信した前記業務履歴情報を用いて、当該第1の情報処理装置が、前記取引において一連業務で取得した各個品の業務履歴情報のうち、不足する分を算出する手段とを有する業務履歴補完装置と、
前記第２の情報処理装置と、
前記第３の情報処理装置と、
前記個品を識別する個品ＩＤを記録した１つ以上のタグと、
を有することを特徴とする業務履歴補完システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、製品に関する業務履歴を情報処理技術を用いて把握するための技術に関する。その中でも特に、ＥＤＩでやり取りする商取引情報を活用して、製品一つひとつを区別できるレベル（以下、個品レベル）で情報を収集不可能な企業が実施した業務の履歴情報を、個品レベルで補完する技術に関する。
【背景技術】
【０００２】
近年、製品のリコールが頻繁に発生している。製造業者は、自社製品に不具合が認められた時、回収の必要性が生じるが、製品を他社に搬出した後にリコールが発覚した場合、各社で発生した業務の履歴情報は会社ごとに管理しているため、出荷先に問い合わせるしか方法は無い。よって、リコール対象品の所在を追跡するのに手間がかかるという問題がある。
【０００３】
そのような背景の中で、特許文献１では、２社間を跨って、製品一つひとつを区別して業務履歴情報を管理し、リコール等、問題発生時に業務履歴情報を検索可能とする仕組みが必要という課題を捉え、生鮮品を対象として、流通時のトレーサビリティを確保できるＥＤＩシステムを開示している。すなわち、センタサーバにデータベースがあって、前記データベースに、２社間でやり取りする商取引情報と、業務履歴情報と、を収集し、一括して管理することにより、２社で発生した業務の履歴情報を検索できる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−１７１８０５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、製品一つひとつを区別して業務履歴情報を管理する場合、ＥＤＩで商取引する両社が、製品一つひとつを区別できるレベル（以下、個品レベル）で業務履歴情報を収集可能でなければならない。
【０００６】
そこで、本発明の目的は、ＥＤＩで商取引する２社のうちどちらかが、個品レベルで業務履歴情報を収集可能であれば、ＥＤＩでやり取りする商取引情報を活用することにより、個品レベルで情報を収集不可能な企業が実施した業務の履歴情報を、個品レベルで補完可能とする方法を提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明では、取引関係にある一方の企業（組織）が有する個品についての取引における各業務の履歴を示す業務履歴情報および本取引についてのＥＤＩメッセージを用いて、他方の企業の業務履歴情報のうち、収集できなかったものを補完するものである。この際、補完に利用した業務履歴情報の示す取引に関する数量のデータとＥＤＩメッセージの示す数量のデータに矛盾が生じる場合に、これらのデータと他のデータ（例えば、確率値や仮想ＩＤ）を用いて、業務履歴情報を推定することも本発明の一態様に含まれる。
【０００８】
より詳細には、本発明には以下の構成も含まれる。注文から入出荷、検査、検収、支払いに亘る取引の一連業務で、取引を一意に特定するＩＤ（以下、取引番号）が付番される取引において、演算処理手段と、記憶手段と、通信手段と、を有する第１の情報処理装置において、製品一つひとつを区別できるレベル（以下、個品レベル）で情報を収集不可能な企業が実施した業務の履歴情報を、個品レベルで補完する業務履歴補完方法であって、演算処理手段が、第２の情報処理装置から通信手段を介して、個品レベルの業務履歴情報と、第２の情報処理装置、第３の情報処理装置の間でＥＤＩを介してやり取りする商取引情報（以下、ＥＤＩメッセージ）と、を取得する処理と、演算処理手段が、第３の情報処理装置から通信手段を介して、ＥＤＩメッセージを取得する処理と、取引番号を含んだＥＤＩメッセージと、一連業務のどこかで取得した個品レベルの業務履歴情報と、について、取引番号をキーに、個品レベルで算出し、補完する処理と、前記業務履歴情報のレコード数と、前記ＥＤＩメッセージの中から取得した数量の値と、を比較した結果が不一致の場合は、業務履歴を推定する処理と、を有することを特徴とする第１の業務履歴補完方法を提供する。
【０００９】
また、本発明は、第１の業務履歴補完方法における業務履歴を推定する処理は、比較した結果、前記業務履歴情報のレコード数の方が多い場合は、前記業務履歴情報の各個品ＩＤに対応する製品が履歴情報を補完する業務において存在していた確率値を算出する処理を有することを特徴とする第２の業務履歴補完方法を提供する。
【００１０】
また、本発明は、第１の業務履歴補完方法における業務履歴を推定する処理は、比較した結果、前記業務履歴情報のレコード数の方が少ない場合は、前記業務履歴情報のレコード数と、前記ＥＤＩメッセージの中から取得した数量の値と、の差分の数だけ、ＲＦＩＤのように製品に添付されているＩＤではないが、製品一つひとつを一意に特定できる仮想的な個品ＩＤを採番する処理を有することを特徴とする第３の業務履歴補完方法を提供する。
【００１１】
また、本発明は、第１の業務履歴補完方法における業務履歴を推定する処理を実施する際に、同時に、数量が異なっている旨をＥＤＩ取引先に通知する処理を有することを特徴とする第４の業務履歴補完方法を提供する。
【００１２】
また、本発明は、第１、２、３、４の業務履歴補完方法におけるＥＤＩメッセージは、少なくとも、当該ＥＤＩメッセージが表す業務の種類を特定する情報区分と、当該ＥＤＩメッセージに関連した取引の受注者を一意に特定する受注者コードと、当該ＥＤＩメッセージに関連した取引の発注者を一意に特定する発注者コードと、当該ＥＤＩメッセージに関連した取引を一意に特定する取引番号と、当該ＥＤＩメッセージが表す業務に関連する製品の種類を一意に特定する製品コードと、当該ＥＤＩメッセージが表す業務に関連する製品の数量と、当該ＥＤＩメッセージが表す業務が行われた日時と、を含み、第１、２、３、４の業務履歴補完方法における個品レベルの業務履歴情報は、少なくとも、製品一つひとつを一意に特定する個品ＩＤと、製品の種類を一意に特定する製品コードと、当該業務履歴情報のもととなる業務が行われた拠点を一意に特定する拠点ＩＤと、当該業務履歴情報のもととなる業務が行われた日時と、当該業務履歴情報がどのような業務において生成されたものであるかを特定する作業タイプと、当該業務履歴情報のもととなる業務、に関連する取引を一意に特定する取引番号と、上記個品ＩＤの製品が当該業務履歴情報のもととなる業務、において存在していた確率と、を含むことを特徴とする第５の業務履歴補完方法を提供する。
【００１３】
その他、本願が開示する課題、およびその解決手段は、発明を実施するための最良の形態の欄、および図面より明らかになる。
【発明の効果】
【００１４】
本発明によれば、取引における業務履歴情報の補完を可能にする。注文から入出荷、検査、検収、支払いに亘る取引の一連業務で、取引を一意に特定するＩＤ（以下、取引番号）が付番される取引において、ＥＤＩで商取引する２社のうちどちらかが、製品一つひとつを区別して業務履歴情報を収集可能であれば、ＥＤＩでやり取りする商取引情報（以下、ＥＤＩメッセージ）を活用することにより、製品一つひとつを区別できるレベル（以下、個品レベル）で情報を収集不可能な企業が実施した業務の履歴情報を、個品レベルで補完できる。これにより、ある製品に関して、検索可能な業務履歴の範囲を広げることができる。また、欠品等により、取引の途中で製品の数量が変動した際にも、ＥＤＩ取引先にエラーを返すだけではなく、確率値や仮想的なＩＤを利用して業務履歴を推定し、補完することより、業務履歴の検索を実現できる。
【図面の簡単な説明】
【００１５】
【図１】本発明の一実施形態に係るシステムの全体構成図である。
【図２】業者ｍ１００が出荷した製品数と、業者ｍ２００が入荷した製品数と、が一致している場合のレコードが登録されている、業務履歴補完装置３００の記憶装置３０３のＥＤＩメッセージＤＢのテーブル構成図である。
【図３】業者ｍ１００が出荷した製品数よりも、業者ｍ２００が入荷した製品数が少ない場合のレコードが登録されている、業務履歴補完装置３００の記憶装置３０３のＥＤＩメッセージＤＢのテーブル構成図である。
【図４】業者ｍ１００が出荷した製品数よりも、業者ｍ２００が入荷した製品数が多い場合のレコードが登録されている、業務履歴補完装置３００の記憶装置３０３のＥＤＩメッセージＤＢのテーブル構成図である。
【図５】業務履歴補完プログラム３２０により入荷履歴を補完する前のレコードが登録されている、業務履歴補完装置３００の記憶装置３０３の業務履歴ＤＢのテーブル構成図である。
【図６】業者ｍ１００が出荷した製品数と、業者ｍ２００が入荷した製品数と、が一致している場合における、業務履歴補完プログラム３２０により入荷履歴を補完した後のレコードが登録されている、業務履歴補完装置３００の記憶装置３０３の業務履歴ＤＢのテーブル構成図である。
【図７】業者ｍ１００が出荷した製品数よりも、業者ｍ２００が入荷した製品数が少ない場合における、業務履歴補完プログラム３２０により入荷履歴を補完した後のレコードが登録されている、業務履歴補完装置３００の記憶装置３０３の業務履歴ＤＢのテーブル構成図である。
【図８】業者ｍ１００が出荷した製品数よりも、業者ｍ２００が入荷した製品数が多い場合における、業務履歴補完プログラム３２０により入荷履歴を補完した後のレコードが登録されている、業務履歴補完装置３００の記憶装置３０３の業務履歴ＤＢのテーブル構成図である。
【図９】業務履歴補完装置３００の記憶装置３０３の補完処理判別ＤＢのテーブル構成図である。
【図１０】情報受付処理のフロー図である。
【図１１】業務履歴補完処理のフロー図である。
【図１２】業務履歴推定処理のフロー図である。
【発明を実施するための形態】
【００１６】
以下、図面を参照しつつ、本発明の一実施形態について説明する。
【００１７】
図１は、本実施形態に係るシステムの全体構成図であり、業務履歴補完装置３００と、リーダ（例えばバーコードリーダや二次元コードリーダ、ＲＦＩＤリーダなどであり、タグから少なくとも個品ＩＤを読み取る。）を保有する少なくとも１つ以上の業者ｍ１００の情報処理装置１００と、リーダを保有しない少なくとも１つ以上の業者ｍ２００の情報処理装置２００と、少なくとも１つ以上の製品に添付されているタグ６００と、通信路５００と、から構成される。通信路５００は、業務履歴補完装置３００や情報処理装置１００、情報処理装置２００などをつなぐ。通信路５００は、例えば有線ＬＡＮや無線ＬＡＮなどといった規格の通信路で実現される。
【００１８】
次に、タグ６００は、例えばバーコードや二次元コード、ＲＦＩＤタグなど、当該タグ６００が添付されている製品を個品レベルで（同じ種類の製品でも、１つ１つを区別できるレベルで）一意に特定する個品ＩＤを少なくとも記録した媒体である。
【００１９】
次に、情報処理装置１００は、例えばＰＣなどといったいわゆるコンピュータ装置であり、業者ｍ１００が、製品の出荷履歴を、個品レベルで管理し、出荷履歴情報から、ＥＤＩでやり取りする商取引情報（以下、ＥＤＩメッセージ）を作成し、個品レベルの出荷履歴情報、ＥＤＩメッセージ（出荷）を業務履歴補完装置３００に送信するものである。情報処理装置１００は、少なくともＣＰＵ１０１と、メモリ１０２と、記憶装置１０３と、通信インタフェース１０４と、リーダ１０５と、から構成される。リーダ１０５は、例えばバーコードリーダや二次元コードリーダ、ＲＦＩＤリーダなどであり、タグ６００から少なくとも個品ＩＤを読み取る。通信インタフェース１０４は、例えば有線ＬＡＮカードや無線ＬＡＮカードなどといったインタフェースであり、業務履歴補完装置３００と通信路５００を介して通信する。記憶装置１０３は、例えばハードディスクやフラッシュメモリなど、プログラムやデータを記憶する装置である。記憶装置１０３に記憶されているプログラムは、メモリ１０２に読み込まれ、ＣＰＵ１０１に実行されることにより、後述する各処理が実行される。
【００２０】
次に、情報処理装置２００は、例えばＰＣなどといった装置であり、業者ｍ２００が、製品の入荷履歴を、単品レベルで（製品コードなど、製品を種類単位で区別できるレベルで）管理し、入荷履歴情報からＥＤＩメッセージ（入荷）を作成し、ＥＤＩメッセージ（入荷）を業務履歴補完装置３００に送信するものである。情報処理装置２００は、少なくともＣＰＵ２０１と、メモリ２０２と、記憶装置２０３と、通信インタフェース２０４と、から構成される。通信インタフェース２０４は、例えば有線ＬＡＮカードや無線ＬＡＮカードなどといったインタフェースであり、業務履歴補完装置３００と通信路５００を介して通信する。記憶装置２０３は、例えばハードディスクやフラッシュメモリなど、プログラムやデータを記憶する装置である。記憶装置２０３に記憶されているプログラムは、メモリ２０２に読み込まれ、ＣＰＵ２０１に実行されることにより、後述する各処理が実行される。
【００２１】
次に、業務履歴補完装置３００は、例えばＰＣなどといった装置であり、情報処理装置１００、情報処理装置２００から個品レベルの業務履歴、ＥＤＩメッセージの提供を受け、それらの情報をもとに、個品レベルで入荷履歴情報を生成し、管理するものである。業務履歴補完装置３００は、少なくともＣＰＵ３０１と、メモリ３０２と、記憶装置３０３と、通信インタフェース３０４と、から構成される。通信インタフェース３０４は、例えば有線ＬＡＮカードや無線ＬＡＮカードなどといったインタフェースであり、情報処理装置１００や情報処理装置２００と通信路５００を介して通信する。記憶装置３０３は、例えばハードディスクやフラッシュメモリなど、プログラムやデータを記憶する装置であり、プログラムとして少なくとも情報受付プログラム３１０、業務履歴補完プログラム３２０と、業務履歴推定プログラム３３０と、検索プログラム３４０と、を含み、データとして少なくともＥＤＩメッセージＤＢ３６０と、業務履歴ＤＢ３７０と、補完処理判別ＤＢ３８０と、を含む。
【００２２】
ＥＤＩメッセージＤＢ３６０は、リーダを保有する業者ｍ１００の情報処理装置１００、リーダを保有しない業者ｍ２００の情報処理装置２００から取得した、業者ｍ１００、業者ｍ２００の間でＥＤＩを通じてやり取りした商取引情報を管理するためのデータベースである。ＥＤＩメッセージＤＢ３６０の構成は、後述する図２、図３、図４の説明に示される。
【００２３】
業務履歴ＤＢ３７０は、リーダを保有する業者ｍ１００の情報処理装置１００から取得した、または業務履歴補完プログラム３２０が生成した、製品に関する業務履歴情報を管理するためのデータベースである。業務履歴ＤＢ３７０の構成は、後述する図５、図６、図７、図８の説明で示す。
【００２４】
補完処理判別ＤＢ３８０は、当該装置を利用する以前に設定した、業務履歴補完処理の契機となる情報を管理するためのデータベースである。補完処理判別ＤＢ３８０の構成は、後述する図９の説明で示す。
【００２５】
情報受付プログラム３１０は、情報処理装置１００、情報処理装置２００から、ＥＤＩメッセージ、または業務履歴情報を受信した後に、各データをＥＤＩメッセージＤＢ３６０、業務履歴ＤＢ３７０に登録し、業務履歴補完プログラム３２０に送信するプログラムである。情報受付プログラム３１０が実行する情報受付処理フローについては、後述する図１０の説明で示す。
【００２６】
業務履歴補完プログラム３２０は、情報受付プログラム３１０から、ＥＤＩメッセージ、または業務履歴情報の送信を受けて、受信した前記データと、ＥＤＩメッセージＤＢ３６０、業務履歴ＤＢ３７０に登録してあるデータと、をもとに、個品レベルでは情報を収集不可能な企業ｍ２００が実施した業務の履歴情報を個品レベルで生成し、管理するプログラムである。業務履歴補完プログラム３２０が実行する業務履歴補完処理フローについては、後述する図１１の説明で示す。
【００２７】
業務履歴推定プログラム３３０は、業務履歴補完プログラム３２０から、業務履歴の推定要求を受けて、その結果を提供するプログラムである。業務履歴推定プログラム３３０が実行する業務履歴推定処理フローについては、後述する図１２の説明で示す。
【００２８】
検索プログラム３４０は、業者ｍ１００、または業者ｍ２００から、業務履歴の検索依頼を受信した際に、要求された検索条件に該当するレコードを業務履歴ＤＢ３７０から取得し、返信するプログラムである。
【００２９】
記憶装置３０３が記憶するプログラムは、メモリ３０２に読み込まれ、ＣＰＵ３０１に実行されることにより、処理が実行される。
【００３０】
また、上述の図１のシステムの構成では、出荷と入荷の業務を例に記載したが、ターンアラウンド型取引の特徴である、取引を一意に特定するＩＤが付番される注文業務から入出荷業務、検査業務、検収業務、支払業務のうち、どの業務についても適用できる。
【００３１】
また、上述の図１のシステムの構成では、情報処理装置１００、情報処理装置２００と、業務履歴補完装置３００と、を別々に記載していたが、業務履歴補完装置３００を、情報処理装置１００、または情報処理装置２００に統合する形態も考えられる。
【００３２】
次に、ＥＤＩメッセージＤＢ３６０の構成図を図２、図３、図４に示す。図２は、業者ｍ１００が出荷した製品数と、業者ｍ２００が入荷した製品数と、が一致している場合のＥＤＩメッセージの例を表したものであり、図３は、業者ｍ１００が出荷した製品数よりも、業者ｍ２００が入荷した製品数が少ない場合のＥＤＩメッセージの例を表したものであり、図４は、業者ｍ１００が出荷した製品数よりも、業者ｍ２００が入荷した製品数が多い場合のＥＤＩメッセージの例を表したものである。ＥＤＩメッセージＤＢ３６０は、レコードのフィールドとして、少なくとも情報区分３６０ａと、受注者コード３６０ｂと、発注者コード３６０ｃと、取引番号３６０ｄと、製品コード３６０ｅと、数量３６０ｆと、日時３６０ｇと、を含む。
【００３３】
情報区分３６０ａには、当該ＥＤＩメッセージが表す業務の種類を特定するコードが設定(記録)される。
【００３４】
受注者コード３６０ｂには、当該ＥＤＩメッセージに関連した取引の受注者を一意に特定するコードが設定(記録)される。  発注者コード３６０ｃには、当該ＥＤＩメッセージに関連した取引の発注者を一意に特定するコードが設定(記録)される。  取引番号３６０ｄには、当該ＥＤＩメッセージに関連した取引を一意に特定する番号が設定(記録)される。当該番号は、注文から入出荷、検査、検収、支払いに亘る取引の一連業務において、取引を一意に特定するために同じＩＤが付番されたものである。
【００３５】
製品コード３６０ｅには、当該ＥＤＩメッセージが表す業務に関連する製品の種類を一意に特定するコードが(記録)設定される。  数量３６０ｆには、当該ＥＤＩメッセージが表す業務に関連する製品の数量が設定(記録)される。  日時３６０ｇには、当該ＥＤＩメッセージが表す業務が行われた日時が設定(記録)される。
【００３６】
次に、業務履歴ＤＢ３７０の構成図について図５、図６、図７、図８に示す。図５は、業務履歴補完プログラム３２０により入荷履歴を補完する前の業務履歴情報の例を表したものであり、図６は、業者ｍ１００が出荷した製品数と、業者ｍ２００が入荷した製品数と、が一致している場合における、入荷履歴を補完した後の業務履歴情報の例を表したものであり、図７は、業者ｍ１００が出荷した製品数よりも、業者ｍ２００が入荷した製品数が少ない場合における、入荷履歴を補完した後の業務履歴情報例を表したものであり、図８は、業者ｍ１００が出荷した製品数よりも、業者ｍ２００が入荷した製品数が多い場合における、入荷履歴を補完した後の業務履歴情報の例を表したものである。業務履歴ＤＢ３７０は、レコードのフィールドとして、少なくとも個品ＩＤ３７０ａと、製品コード３７０ｂと、拠点ＩＤ３７０ｃと、日時３７０ｄと、作業タイプ３７０ｅと、取引番号３７０ｆと、確率３７０ｇと、を含む。
【００３７】
個品ＩＤ３７０ａには、タグ６００を読み取るなどして取得した、製品一つひとつを一意に特定できるＩＤが設定(記録)される。
【００３８】
製品コード３７０ｂには、個品ＩＤ３６０ａにより特定される製品の種類を一意に特定するコードが設定(記録)される。
【００３９】
拠点ＩＤ３７０ｃには、当該業務履歴情報のもととなる業務が行われた拠点を一意に特定するＩＤが設定される。例えば、出荷業務を実施した製造業者を一意に特定するＩＤ（ｍ１００）や、製造業者の工場などを一意に特定するＩＤなどが設定(記録)される。
【００４０】
日時３７０ｄには、当該業務履歴情報のもととなる業務が行われた日時が設定(記録)される。
【００４１】
作業タイプ３７０ｅには、当該業務履歴情報がどのような業務において生成されたものであるか、その作業名が設定(記録)される。例えば、出荷業務において生成された業務履歴情報であれば「出荷」が設定(記録)される。  取引番号３７０ｆには、当該業務履歴情報のもととなる業務、に関連する取引を一意に特定する番号が設定(記録)される。  確率３７０ｇには、個品ＩＤ３７０ａの製品が当該業務履歴情報のもととなる業務、において存在していた確率値が設定(記録)される。
【００４２】
次に、補完処理判別ＤＢ３８０の構成図について図９を用いて説明する。補完処理判別ＤＢ３８０は、レコードのフィールドとして、少なくとも作業タイプ３８０ａと、情報区分３８０ｂと、を含む。
【００４３】
作業タイプ３８０ａには、業務履歴補完処理の契機となる情報が業務履歴情報である場合に、その業務履歴情報がどのような業務において生成されたものであるかを示すその作業名が設定(記録)される。
【００４４】
情報区分３８０ｂには、業務履歴補完処理の契機となる情報がＥＤＩメッセージである場合に、そのＥＤＩメッセージが表す業務の種別を特定するコードが設定(記録)される。
【００４５】
次に図１０は、情報受付処理のフロー図であり、当該フローに従って、情報受付処理プログラム３１０は、リーダを保有する業者ｍ１００の情報処理装置１００、リーダを保有しない業者ｍ２００の情報処理装置２００から受け付けた、ＥＤＩメッセージ、または業務履歴情報を、ＥＤＩメッセージＤＢ３６０、業務履歴ＤＢ３７０に登録し、業務履歴補完プログラム３２０への送信を行う。
【００４６】
まず、前記フローは、情報受付プログラム３１０が情報処理装置１００、情報処理装置２００からＥＤＩメッセージ、または業務履歴情報を受信することを契機に開始される（Ｓ３１０１）。
【００４７】
前記フローが開始されると、情報受付プログラム３１０は、ステップＳ３１０１で受信したＥＤＩメッセージ、または業務履歴情報のそれぞれをＥＤＩメッセージＤＢ３６０、業務履歴ＤＢ３７０に登録する（Ｓ３１０２）。
【００４８】
そして、情報受付プログラム３１０は、ステップＳ３１０１で受信したＥＤＩメッセージ、または業務履歴情報を、業務履歴補完プログラム３２０に送信する（Ｓ３１０３）。
【００４９】
次に、図１１は、業務履歴補完処理のフロー図であり、当該フローに従って、業務履歴補完プログラム３２０は、情報受付プログラム３１０から受信した、ＥＤＩメッセージ、または業務履歴情報と、ＥＤＩメッセージＤＢ３６０、業務履歴ＤＢ３７０に登録してあるデータと、をもとに、個品レベルでは情報を収集不可能な企業ｍ２００が実施した業務の履歴情報を個品レベルで生成し、業務履歴ＤＢ３７０への登録を行う。
【００５０】
まず、前記フローは、業務履歴補完プログラム３２０が、情報受付プログラム３１０からＥＤＩメッセージ、または業務履歴情報を受信することを契機に開始される（Ｓ３２０１）。
【００５１】
前記フローが開始されると、業務履歴補完プログラム３２０は、ステップＳ３２０１で受信したＥＤＩメッセージの中から情報区分を取得し、当該情報区分を検索キーとして補完処理判別ＤＢ３８０から該当レコードを抽出、あるいは、ステップＳ３２０１で受信した業務履歴情報の中から作業タイプを取得し、当該作業タイプを検索キーとして補完処理判別ＤＢ３８０から該当レコードを抽出し、該当するデータが存在しない場合は処理を終了し、存在した場合はステップＳ３２０３に処理を移す。例えば、ステップＳ３２０１で受信したデータがＥＤＩメッセージであり、当該ＥＤＩメッセージの内容が、ステップＳ３１０２で登録した図２の３６０１のレコード、あるいは図３の３６０２のレコード、あるいは図４の３６０３のレコードであったとき、情報区分３６０ａの値「入荷」を検索キーにして補完処理判別ＤＢ３８０を検索することで、図９の３８００のレコードを取得できるのでステップＳ３２０３に処理を移す。
【００５２】
ステップＳ３２０３において、業務履歴補完プログラム３２０は、ステップＳ３２０１で受信した情報が、業務履歴情報ではなくＥＤＩメッセージのみである場合はステップＳ３２０４に処理を移し、業務履歴情報である場合はステップＳ３２０６に処理を移す。
【００５３】
ステップＳ３２０４において、業務履歴補完プログラム３２０は、ステップＳ３２０３で該当したＥＤＩメッセージの中から取引番号を取得し、当該取引番号を検索キーとして業務履歴ＤＢ３７０から業務履歴情報を抽出する。例えば、ステップＳ３２０１で受信したデータがＥＤＩメッセージであり、当該ＥＤＩメッセージの内容が、ステップＳ３１０２で登録した図２の３６０１のレコード、あるいは図３の３６０２のレコード、あるいは図４の３６０３のレコードであったとき、取引番号３６０ｄの値が「１００１」であることから、業務履歴ＤＢ３７０に登録されていた図５の３７００、３７０１、３７０２、３７０３、３７０４の５つのレコードが抽出される。
【００５４】
そして、ステップＳ３２０５において、業務履歴補完プログラム３２０は、前記検索結果が存在しない場合は処理を終了し、存在する場合はステップＳ３２０８に処理を移す。
【００５５】
一方、ステップＳ３２０６において、業務履歴補完プログラム３２０は、ステップＳ３２０３で該当した業務履歴情報の中から取引番号を取得し、当該取引番号を検索キーとしてＥＤＩメッセージＤＢ３６０からＥＤＩメッセージを抽出する。
【００５６】
そして、ステップＳ３２０７において、業務履歴補完プログラム３２０は、前記検索結果が存在しない場合は処理を終了し、存在する場合はステップＳ３２０８に処理を移す。
【００５７】
ステップＳ３２０８において、業務履歴補完プログラム３２０は、ステップＳ３２０４で抽出した業務履歴情報のレコード数と、ステップＳ３２０３で該当したＥＤＩメッセージの中から取得した数量の値と、が一致、あるいは、ステップＳ３２０３で該当した業務履歴情報のレコード数と、ステップＳ３２０６で抽出したＥＤＩメッセージの中から取得した数量の値と、が一致した場合は、ステップＳ３２０９に処理を移し、一致しない場合はステップＳ３２１０に処理を移す。
【００５８】
ステップＳ３２０９において、業務履歴補完プログラム３２０は、ステップＳ３２０４で抽出、あるいはステップＳ３２０３で該当した業務履歴情報の個品ＩＤについて、ステップＳ３２０３で該当、あるいはステップＳ３２０６で抽出したＥＤＩメッセージの情報区分コード、発注者コード、受注者コード、取引番号、製品コード、数量、日時のフィールドの値をもとに、製品一つひとつの業務履歴情報を生成する。例えば、例えば、ステップＳ３２０１で受信したデータがＥＤＩメッセージであり、当該ＥＤＩメッセージの内容がステップＳ３１０２で登録した図２の３６０１のレコードであったとき、（個品ＩＤ３７０ａ、製品コード３７０ｂ、拠点ＩＤ３７０ｃ、日時３７０ｄ、作業タイプ３７０ｅ、取引番号３７０ｆ、確率３７０ｇ）の組み合わせが図６に示す３７０５、３７０６、３７０７、３７０８、３７０９の５つのレコードが生成される。
【００５９】
一方、ステップＳ３２１０において、業務履歴補完プログラム３２０は、ステップＳ３２０３で該当、あるいはステップＳ３２０６で抽出したＥＤＩメッセージと、ステップＳ３２０４で抽出、あるいはステップＳ３２０３で該当した業務履歴情報と、を業務履歴推定プログラム３３０に通知することによって、業務履歴の推定を要求し、その結果を受信する（Ｓ３２１１）。
【００６０】
そして、業務履歴補完プログラム３２０は、ステップＳ３２０９、ステップＳ３２１１で生成した業務履歴情報を業務履歴ＤＢ３７０に登録する（Ｓ３２１２）。
【００６１】
次に、図１２は、業務履歴推定処理のフロー図であり、当該フローに従って、業務履歴推定プログラム３３０は、業務履歴補完プログラム３２０から受信したＥＤＩメッセージと、業務履歴情報と、をもとに業務履歴を個品レベルで推定し、業務履歴補完プログラム３２０に送信する。
【００６２】
まず、前記フローは、業務履歴推定プログラム３３０が、業務履歴補完プログラム３２０からＥＤＩメッセージと、業務履歴情報と、を通知されることで、製品一つひとつの業務履歴の推定要求を受信することを契機に開始される（Ｓ３３０１）。
【００６３】
前記フローが開始されると、ステップＳ３３０２において、履歴推定処理プログラム３３０は、前記業務履歴情報のレコード数と、前記ＥＤＩメッセージの中から取得した数量の値と、を比較し、業務履歴情報のレコード数のほうが多い場合はステップＳ３３０３に処理を移し、少ない場合はステップＳ３３０４に処理を移す。
【００６４】
ステップＳ３３０３において、業務履歴推定プログラム３３０は、前記業務履歴情報のレコード数と、前記ＥＤＩメッセージの中から取得した数量の値と、を利用して、前記業務履歴情報の各個品ＩＤに対応する製品が履歴情報を補完する業務において存在していた確率値を算出する。例えば、ステップＳ３２０１で受信したデータがＥＤＩメッセージであり、当該ＥＤＩメッセージの内容がステップＳ３１０２で登録した図４の３６０３のレコードであったとき、業務履歴情報の５つの個品ＩＤ（Ａ００１、Ａ００２、Ａ００３、Ａ００４、Ａ００５）に対応する製品のうち、３つが入荷したこととなるので、各個品ＩＤに対応する製品が当該入荷業務において存在していた確率値として「６０％」が算出される。
【００６５】
一方、ステップＳ３３０４において、業務履歴推定プログラム３３０は、前記業務履歴情報のレコード数と、前記ＥＤＩメッセージの中から取得した数量の値と、の差分の数だけ、タグ６００のように製品に添付されているＩＤではないが、製品一つひとつを一意に特定できる仮想的な個品ＩＤを採番する。例えば、ステップＳ３２０１で受信したデータがＥＤＩメッセージであり、当該ＥＤＩメッセージの内容がステップＳ３１０２で登録した図３の３６０２のレコードであったとき、ＥＤＩメッセージの中から取得した数量の値よりも、業務履歴情報のレコード数の方が２つ少ないので、仮想的な個品ＩＤとして「α」、「β」を採番する。
【００６６】
そして、業務履歴推定プログラム３３０は、ステップＳ３３０３で算出した確率値、または、ステップＳ３３０４で採番した仮想ＩＤをもとに、ステップＳ３３０１で通知された業務履歴情報の個品ＩＤについて、ＥＤＩメッセージの情報区分コード、受注者コード、発注者コード、取引番号、製品コード、数量、日時のフィールドの値をもとに、製品一つひとつの業務履歴情報を生成する（Ｓ３３０５）。例えば、ステップＳ３２０１で受信したデータがＥＤＩメッセージであり、当該ＥＤＩメッセージの内容がステップＳ３１０２で登録した図４の３６０３のレコードであったとき、（個品ＩＤ３７０ａ、製品コード３７０ｂ、拠点ＩＤ３７０ｃ、日時３７０ｄ、作業タイプ３７０ｅ、取引番号３７０ｆ、確率３７０ｇ）の組み合わせが図７に示す３７１０、３７１１、３７１２、３７１３、３７１４の５つのレコードが生成される。また、ステップＳ３２０１で受信したデータがＥＤＩメッセージであり、当該ＥＤＩメッセージの内容がステップＳ３１０２で登録した図３の３６０２のレコードであったとき、（個品ＩＤ３７０ａ、製品コード３７０ｂ、拠点ＩＤ３７０ｃ、日時３７０ｄ、作業タイプ３７０ｅ、取引番号３７０ｆ、確率３７０ｇ）の組み合わせが図８に示す３７１５、３７１６、３７１７、３７１８、３７１９、３７２０、３７２１の７つのレコードが生成される。
【００６７】
そして、業務履歴推定プログラム３３０は、ステップＳ３３０５で生成した業務履歴情報を、業務履歴補完プログラム３２０に送信する（Ｓ３３０６）。
【００６８】
以上、本発明を実施するための形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【００６９】
例えば、図１のシステムの構成では、出荷元である業者ｍ１００の情報処理装置１００にリーダ１０５が存在する構成であったが、入荷元である業者ｍ２００の情報処理装置２００にリーダが存在する構成でもよい。その際、業者ｍ１００から受信したＥＤＩメッセージ（出荷）と、業者ｍ２００から受信した入荷履歴情報をもとに、製品履歴補完装置３００により、出荷履歴情報を補完することとなる。
【００７０】
また、本実施形態では、ステップＳ３２０８において、業務履歴情報のレコード数と、ＥＤＩメッセージの中から取得した数量の値と、が一致しない場合は、業務履歴推定プログラム３３０により業務履歴情報を推定したが、その後、本取引において輸送中に欠品した製品が発見されて入荷された際には確率値を再計算など、業務履歴推定プログラム３３０を利用して再推定を実施してもよい。
【００７１】
また、本実施形態では、業務履歴情報のレコード数と、ＥＤＩメッセージの中から取得した数量の値と、が一致しない場合に、ステップＳ３３０３、ステップＳ３３０４の推定処理を実施しているが、推定処理と同時に、数量が異なっている旨をＥＤＩ取引先に通知してもよい。
【００７２】
以上の実施形態によれば、注文から入出荷、検査、検収、支払いに亘る取引の一連業務で、取引を一意に特定するＩＤ（以下、取引番号）が付番される取引において、ＥＤＩで商取引する２社のうちどちらかが、製品一つひとつを区別して業務履歴情報を収集可能であれば、ＥＤＩでやり取りする商取引情報（以下、ＥＤＩメッセージ）を活用することにより、製品一つひとつを区別できるレベル（以下、個品レベル）で情報を収集不可能な企業が実施した業務の履歴情報を、個品レベルで補完できる。これにより、ある製品に関して、検索可能な業務履歴の範囲を広げることができる。また、欠品等により、取引の途中で製品の数量が変動した際にも、ＥＤＩ取引先にエラーを返すだけではなく、確率値や仮想的なＩＤを利用して業務履歴を推定し、補完することより、業務履歴の検索を実現できる。
【符号の説明】
【００７３】
１００  情報処理装置
１０５  リーダ
２００  情報処理装置
３００  業務履歴補完装置
３２０  業務履歴補完プログラム
３３０  業務履歴推定プログラム
３６０  ＥＤＩメッセージＤＢ
３７０  業務履歴ＤＢ
３８０  補完処理種別ＤＢ
６００  タグ
【図１】
2011215981.tif 000003
【図２】
2011215981.tif 000004
【図３】
2011215981.tif 000005
【図４】
2011215981.tif 000006
【図５】
2011215981.tif 000007
【図６】
2011215981.tif 000008
【図７】
2011215981.tif 000009
【図８】
2011215981.tif 000010
【図９】
2011215981.tif 000011
【図１０】
2011215981.tif 000012
【図１１】
2011215981.tif 000013
【図１２】
2011215981.tif 000014