(57)【要約】 【課題】  複数の発注者と複数の受注者の間で発注情報、受注情報、出荷情報、納品情報を容易に変換可能にすると同時に、取引の進捗状況を容易に確認できる受発注データ管理方法。【解決手段】  複数の発注者の発注フォーマットにおいて使用されるパラメータと、複数の受注者の受注フォーマットにおいて使用されるパラメータと、取引番号を包含する一群のパラメータを設定可能なセンターフォーマットを準備する過程と、発注者から受信した発注情報を前記発注フォーマットから前記センターフォーマットに変換すると共に、発注者から受信した発注情報に前記取引番号を関連付ける過程と、発注者から受信した発注情報を前記センターフォーマットから発注を受ける受注者の前記受注フォーマットに変換すると共に、受注者に送信する受注情報に前記取引番号を関連付ける過程を有する受発注データ管理方法。【選択図】  図２
2010134771.tif 000002
【特許請求の範囲】
【請求項１】
複数の発注者の発注フォーマットにおいて使用されるパラメータと、複数の受注者の受注フォーマットにおいて使用されるパラメータと、取引番号を包含する一群のパラメータを設定可能なセンターフォーマットを準備する過程と、
発注者から受信した発注情報を前記発注フォーマットから前記センターフォーマットに変換すると共に、発注者から受信した発注情報に前記取引番号を関連付ける過程と、
発注者から受信した発注情報を前記センターフォーマットから発注を受ける受注者の前記受注フォーマットに変換すると共に、受注者に送信する受注情報に前記取引番号を関連付ける過程を有する受発注データ管理方法。
【請求項２】
前記センターフォーマットはさらに受注者の出荷フォーマットと、発注者の納品フォーマットにおいて使用されるパラメータを包含し、
受注者の出荷情報を前記出荷フォーマットから前記センターフォーマットに変換する過程と、
受注者の出荷情報を前記センターフォーマットから発注者の前記納品フォーマットに変換する過程とを有する請求項１に記載の受発注データ管理方法。
【請求項３】
前記発注者から受信した発注情報に複数の受注者が対応する場合、前記発注情報を振分けて、該当する複数の受注者それぞれの受注フォーマットに変換すると共に、各受注者に送信する受注情報に前記取引番号を関連付ける過程を有する前記請求項１又は２に記載の受発注データ管理方法。
【請求項４】
さらに、状況照会に対応して、前記取引番号によって関連付けられた発注情報と、受注情報と、出荷情報と、納品情報と、振分情報のうちの少なくとも１つを含む取引情報を表示する過程を有する請求項１ないし３のいずれかに記載の受発注データ管理方法。
【請求項５】
発注者から、発注フォーマットに従って記述された発注情報をセンターコンピュータに送信可能な発注者コンピュータと、
前記発注者から発注フォーマットに従って記述された発注情報を受信し、該発注情報に取引番号を関連付けて、複数の発注者の発注フォーマットにおいて使用されるパラメータと、複数の受注者の受注フォーマットにおいて使用されるパラメータと、取引番号を包含する一群のパラメータを設定可能なセンターフォーマットに変換し、さらに該取引番号と関連付けられた発注情報を受注者の受注フォーマットに変換して、受注者コンピュータに送信可能なセンターコンピュータと、
前記発注者からの発注情報に基づいて、受注フォーマットに従って作成された受注情報を前記センターコンピュータから受信可能な受注者コンピュータとを備え、
複数の異なる発注フォーマットと複数の異なる受注フォーマットの間で取引番号と関連付けられた受発注データを変換・送受信する受発注システム。
【請求項６】
前記センターフォーマットはさらに受注者の出荷フォーマットと、発注者の納品フォーマットにおいて使用されるパラメータを包含し、
前記センターコンピュータは、取引情報と関連付けられた受注者の出荷情報を前記出荷フォーマットから前記センターフォーマットに変換すると共に、該受注者の出荷情報を前記センターフォーマットから発注者の前記納品フォーマットに変換する請求項５に記載の受発注システム。
【請求項７】
前記発注者から受信した発注情報に複数の受注者が対応する場合、前記センターコンピュータは当該発注情報を振分けて、該当する複数の受注者それぞれの受注フォーマットに変換すると共に、受注情報に前記取引番号を関連付けて各受注者に送信する前記請求項５又は６に記載の受発注システム。
【請求項８】
さらに、状況照会に対応して、前記取引番号によって関連付けられた発注情報と、受注情報と、出荷情報と、納品情報と、振分情報のうちの少なくとも１つを含む取引情報を取得することが可能な請求項５ないし７のいずれかに記載の受発注システム。
【請求項９】
発注者コンピュータから発注フォーマットに従って記述された発注情報を受信し、
該発注情報に取引番号を関連付けて、複数の発注者の発注フォーマットにおいて使用されるパラメータと、複数の受注者の受注フォーマットにおいて使用されるパラメータと、取引番号を包含する一群のパラメータを設定可能なセンターフォーマットに変換し、
前記取引番号と関連付けられた発注情報を受注者の受注フォーマットに変換し、
受注者コンピュータに送信して、
センターコンピュータに、複数の異なる発注者コンピュータと複数の異なる受注者コンピュータの間で取引番号と関連付けられた受発注データを変換・送受信させるコンピュータソフトウェア。
【請求項１０】
前記請求項９に記載のコンピュータソフトウェアを格納した、コンピュータによって読み出し可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の発注者と複数の受注者との間で発注および受注を共通に管理することのできる方法、当該方法を実行可能なシステムおよびコンピュータソフトウェア、当該コンピュータソフトウェアを記憶した記憶媒体に関し、特に、発注に関して複数の発注者がそれぞれ異なるフォーマットを用い、受注に関して複数の受注者がそれぞれ異なるフォーマットを用いているような場合であっても発注、受注、出荷および納品の取引情報を効率よく、かつ漏れなく取得可能な方法等に関するものである。
【０００２】
コンピュータ通信による受発注が普及した今日では、発注者（企業または個人）は、物品またはサービスの発注に際して特定の発注フォーマットを使用して、発注票等を電子的に受注者（企業または個人）に送信することが行われている。当該特定の発注フォーマットを利用することは、発注者の側の関連処理（発注管理、納品管理、工程管理、経理処理、税務処理等）上は便宜である。この時、一般に、発注フォーマットは発注者ごとに異なっている。
【０００３】
一方受注者（企業または個人）の側でも、受注に際して特定の受注フォーマットを使用してコンピュータによって関連処理（受注管理、出荷管理、納期管理、在庫管理、経理処理、税務処理等）を行っている。受注者の側でも、一般に、受注フォーマットは受注者（企業、個人）ごとに異なっている。
【０００４】
同一業種の企業間で異なる発注フォーマットおよび受注フォーマットを統一して効率化を図る動きも無いではないが、一般に発注側からみた受注側企業（つまり、１つの発注企業にとって物品またはサービスを発注する可能性のある相手企業）は極めて他業種にわたり、受注側からみた発注側企業（１つの受注企業が受注する可能性のある相手企業）についても同様であるために、業種間を越えて受発注フォーマットをすべて統一することは困難な状況である。
【０００５】
一方、発注者と受注者の間で発注フォーマットで記載された発注情報を受注フォーマットに変換して受注者に送付するサービスも存在しえる。しかし、発注者側の複数の企業または個人が合計Ｍ種類のフォーマットを利用しており、受注者側の複数の企業または個人が合計Ｎ種類のフォーマットを利用しているとすれば、Ｍ×Ｎ通りの変換が必要となり、非常に多くのファーマット変換に対応する必要がある。仮にこれらの変換をコンピュータに行わせるものとすれば、コンピュータが変換に要する時間そのものはごく短時間である可能性も有るが、それぞれの変換プログラムにバグは無いか等を確認する作業の負荷は非常に大きい。まして、発注者側と受注者側のデータ変換を行うのが、データ変換のための専門業者であったとすれば、発注者側のフォーマットにも受注者側のフォーマットにも不慣れなために、デバッグ作業の付加は一層大きなものになる。
【０００６】
さらに、発注者が、発注済の案件について受注側での進捗の状況を把握したいと考えた場合、受注者側で管理している受注情報または取引情報を発注者が直接見ることはできないために、取引情報を確認可能にするために、またＭ×Ｎ通りの新たなフォーマット変換を準備する必要がある。
【０００７】
また、発注側は取引を管理するために特定のパラメータを必要としているが（例えば、発注担当者の社内コード等）、受注者の側に当該パラメータを管理する用意が無い場合、発注情報を発注フォーマットから受注フォーマットに変換した際に当該パラメータは失われ、以後の出荷情報、納品情報には当該パラメータは含まれないことになる。発注者の側としては、納品情報に当該パラメータが含まれていることを予定しているので、納品管理上支障を生じることになる。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明は、従来技術が有する上記の問題を解決することを目的としたものであって、より具体的には、複数の発注者と複数の受注者の間で発注情報、受注情報、出荷情報、納品情報を容易に変換可能にすると同時に、発注に対して取引番号をユニークに対応させることによって取引情報を容易に取得可能にした受発注データ管理方法、同システム、受発注管理コンピュータソフトウェアおよび同コンピュータソフトウェアを格納した記憶媒体を提供することを目的とする。
【０００９】
本発明はさらに、前記発注者の発注情報に複数の受注者が対応する際に、発注情報を振分けて、該当する複数の受注者それぞれの受注フォーマットに変換すると共に、各受注者に送信する受注情報に前記取引番号を関連付ける受発注データ管理方法等に関するものである。本発明によって解決されるさらに他の課題および本発明の効果は、明細書の全体を通じて明らかにする。
【課題を解決するための手段】
【００１０】
上記の目的を達成するために、本発明は、
複数の発注者の発注フォーマットにおいて使用されるパラメータと、複数の受注者の受注フォーマットにおいて使用されるパラメータと、取引番号を包含する一群のパラメータを設定可能なセンターフォーマットを準備する過程と、
発注者から受信した発注情報を前記発注フォーマットから前記センターフォーマットに変換すると共に、発注者から受信した発注情報に前記取引番号を関連付ける過程と、
発注者から受信した発注情報を前記センターフォーマットから発注を受ける受注者の前記受注フォーマットに変換すると共に、受注者に送信する受注情報に前記取引番号を関連付ける過程を有する受発注データ管理方法を提供する。
【００１１】
本明細書に於いて「フォーマット」とは、データの記載形式を指す言葉として用いており、ＣＳＶ、ＸＭＬ等の言語形式、特定の言語形式の下でのデータ構造等を表す意味で用いる。発注フォーマットは、いわば発注者が用いる発注伝票の形式に対応する概念である。パラメータとは、例えば、発注番号、商品コード、発注日、発注数量、商品コード「ＡＢ０３２４」等の項目である。「発注情報」とは、発注フォーマットにおいて使用されるパラメータの値によって特定された発注者による発注の具体的な内容である。
【００１２】
受注者の受注フォーマットは、受注者が用いる受注伝票の形式に対応する概念であり、パラメータは、例えば、受注番号、顧客コード、商品コード、受注日、受注数量等の項目である。受注情報とは、受注者の受注フォーマットにおいて使用されるパラメータの値によって特定された受注者による受注の具体的な内容である。センターフォーマットは、発注フォーマットから受注フォーマットへの変換あるいはその逆の変換等を仲介するためのデータの記載形式である。発注フォーマット、センターフォーマットおよび受注フォーマットはそれぞれ異なっていても良いが、センターフォーマットは発注フォーマットあるいは受注フォーマットのうちの１つ以上と同じである可能性を排除しない。
【００１３】
取引番号とは、発注者による発注から受注者による受注、受注者による出荷、納品に至る一連の流れに対して付与される番号である。発注者が、発注に、発注者に固有の発注番号を付与しており、受注者が、受注に、受注者に固有の受注番号を付与している場合、取引番号は発注者と受注者を通じて用いられる番号である点において発注番号や受注番号とは異なるのが原則であるが、取引番号は発注番号又は受注番号のいずれかと同一であっても良い。
【００１４】
発注者の発注情報を前記発注フォーマットから前記センターフォーマットに変換する過程は、例えば以下のような処理を含む。すなわち、発注フォーマットが、ａ）発注日（平成表示）、ｂ）発注番号、ｃ）商品コードに関する情報をこの順序で記載するものであり、センターフォーマットが、１）取引番号、２）発注番号、３）発注日（西暦表示）、４）商品コードをこの順序で記載するものであった場合、上記変換過程は、１）取引番号を新たに設定し（例えば、取引番号として値「２００８０３３１０４５１」を設定する）、ｂ）の値を発注番号として記録し、ａ）の値を平成表示から西暦表示に変換した後に発注日として記録し、ｃ）の値を商品コードとして記録する。ここで、取引番号は、異なる発注に対して同一の取引番号が対応付けられることの無いように、ユニークな値が付与されるのが好ましいが、例えば、年度が更新された場合などに、使用済みの取引番号が再利用される可能性を排除しない。
【００１５】
発注者から受信した発注情報と取引番号の関連付けは、発注フォーマットを変換して作成した発注情報を含むセンターフォーマットに、取引情報を記載すること、あるいは、別途発注番号と取引番号との対照表を作成して両者を紐付けることなどによって行うことができる。発注情報を、前記センターフォーマットから発注を受ける受注者の前記受注フォーマットに変換して、受注者に送信する際は、送信情報のヘッダ内又はフォーマット内に取引番号を含めて送信してもよいし、例えば受注者のコード番号と当該受注者が使用する受注番号との組のようにセンターフォーマットの側から見て取引を特定可能な情報と取引番号の対照表を別途作成して参照可能に保持することでも良い。
【００１６】
その他の点については、センターフォーマットから当該発注を受ける受注者の前記受注フォーマットに変換する過程およびその際の受注情報と取引番号の関連付けについても、基本的には発注フォーマットからセンターフォーマットへの変換と同様の手順である。
【００１７】
上記のように構成した本発明の場合、複数の発注者と複数の受注者との間で受発注データを変換する際には、変換のためのプログラムの制作および内容の確認（デバッグ）等の労力が大幅に削減される。それは、複数の発注者がＭ種類の発注フォーマットを使用しており（複数の発注者が共通の発注フォーマットを利用することもあるので、発注者の数と発注フォーマットの数は必ずしも一致しない）、複数の受注者がＮ種類の受注フォーマットを利用している場合、従来の技術によれば、Ｍ×Ｎ通りのフォーマット変換に対応することが必要であったのに対して、本発明を利用した場合は、Ｍ＋Ｎ通りのフォーマット変換に対応すれば足りるからである（Ｍ種類の発注フォーマットからセンターフォーマットへの変換と、センターフォーマットからＮ種類の受注フォーマットへの変換を行えば足りる）。Ｍが１００社、Ｎが１００社であれば、従来技術によれば１０，０００通りの変換が必要であるのに対して、本発明では２００通りであるから、必要な組み合わせの数は１／５０になる。
以下に記載するように、前記センターフォーマットが受注者の出荷フォーマットと発注者の納品フォーマットを包含する場合には、対応すべきフォーマット変換の種類は同様に大幅に少なくなる。
【００１８】
さらに、本発明の場合には、発注情報と受注情報とがユニークな値を持つ（他の受発注に対して同一番号が付与されることの無い）取引番号によって紐付けられているので、１つの発注とこれに起因して発生した受注との対応関係を容易に把握することができる。従来の技術によれば、Ｍ×Ｎ通りのフォーマット変換に対応して、Ｍ×Ｎ通りのフォーマットから受発注の対応関係を読み出す必要があるのに対して、本発明によった場合には、Ｍ＋Ｎ通りのフォーマット変換を扱えば十分である。
【００１９】
本発明に基づく受発注データ管理方法は、センターフォーマットがさらに受注者の出荷フォーマットと、発注者の納品フォーマットにおいて使用されるパラメータを包含し、
受注者の出荷情報を前記出荷フォーマットから前記センターフォーマットに変換する過程と、
受注者の出荷情報を前記センターフォーマットから発注者の前記納品フォーマットに変換する過程とを有する方法であってもよい。
【００２０】
受注者の出荷フォーマットは、例えば、受注番号、出荷番号、出荷年月日、顧客名称、製品コード、数量のように、受注者が当該出荷を特定するために用いる情報を記載する形式である。発注者の納品フォーマットは、例えば、発注番号、納品年月日、受注者名称、製品コード、数量のように、発注者が発注に対する納品を特定するために用いる情報を記載する形式である。
【００２１】
受注者の出荷情報を出荷フォーマットからセンターフォーマットに変換する過程は、例えば以下のような処理を含む。すなわち、出荷フォーマットが、ａ）受注者コード、ｂ）受注番号、ｃ）出荷番号、ｄ）出荷年月日（平成表示）、ｅ）あて先（顧客名称）、ｆ）製品コードに関する情報をこの順序で記載するものであり、センターフォーマットが、１）取引番号、２）受注者、３）受注番号、４）出荷番号、５）出荷年月日（西暦表示）、６）顧客名称、７）製品コードをこの順序で記載するものであった場合、上記変換過程は、ａ）受注者コードとｂ）受注番号の組み合わせから対照表を参照して取引番号を読み出して１）取引番号とし、ａ）の値を２）受注者、ｂ）受注番号を３）受注番号とする等である。
【００２２】
納品フォーマットにおいて必要な情報が、発注情報に含まれていたにもかかわらず受注者の出荷情報に含まれないとき、前記センターフォーマットから発注者の納品フォーマットへの変換を行う際に、発注者の発注情報に含まれていた前記必要な情報を加えて変換を行うことで発注者が支障なく処理可能にしてもよい。
【００２３】
例えば、発注側の発注フォーマットには発注担当者の氏名を記載する欄があり、発注者氏名情報が記載されていたにもかかわらず、受注フォーマットには発注担当者の氏名が含まれていない場合（例えば、受注者側では発注者の企業名と事業所名のみで足りると考えているような場合が考えられる）、従来方法によれば、受注フォーマットへの変換を行うことによって発注担当者の氏名は欠落することになり、その後の手続きである出荷情報に含まれることは無い。したがって、発注者のために出荷情報を納品情報にフォーマット変換しても、発注担当者の氏名は欠落したままになる。発注者側としては、発注情報および納品情報に発注担当者の氏名を含めて取り扱っているとすれば、これでは不便である。
【００２４】
本発明の上記態様によればこの不便を解消することができる。すなわち、発注フォーマットから受注フォーマットへの変換を行う際に、受注フォーマットが必要としない情報であっても、納品情報に必要な情報であれば、これを一旦記憶し、出荷フォーマットを納品フォーマットに変換する際に当該情報を納品フォーマットに含める。そのためには、発注フォーマットに含まれる情報を全て記憶してもよいし、発注フォーマットに含まれていたにもかかわらず受注者の出荷フォーマットに含まれない情報のみを記憶してもよい。
【００２５】
上述のように、本発明に基づいて出荷情報から納品情報に変換を行うことによって、前述した発注情報から受注情報への変換と同様に、変換の種類を大幅に削減することができる（前記の例に拠れば、従来方法では、Ｍ×Ｎ種類の変換が必要であるのに対して、Ｍ＋Ｎ種類の変換を扱えば足りる）。したがって、変換に要する労力のみならず変換の確認に要する労力が大幅に軽減されることは前述の通りである。発注者の発注から受注者の受注、出荷、発注者の納品までの一連の取り引きをセンターフォーマットを介して行った場合、必要なフォーマット変換の種類が大幅に削減されることは既に述べたとおりである。
【００２６】
前記センターフォーマットは、タグ付きＣＳＶファイルであるのが好ましい。ここでＣＳＶとはComma Separated Valuesと称するデータをカンマで区切って並べたファイル形式をいう。１データ１ファイルであるＸＭＬ（Extensible markup Language）と比較した場合、ＣＳＶはファイルを結合してもタグによってデータの先頭を判定できるのでファイルサイズを小さくできる利点がある。経験則によれば、ＣＳＶのファイルサイズはＸＭＬの１／１０程度である。
【００２７】
本発明では、異なる複数の発注フォーマットのそれぞれからセンターフォーマットへの変換手順と、センターフォーマットから異なる複数の受注フォーマットのそれぞれへの変換手順と、異なる複数の出荷フォーマットのそれぞれからセンターフォーマットへの変換手順と、センターフォーマットから異なる複数の納品フォーマットへの変換手順とを記憶し、
該手順に基づいて前記発注フォーマットからセンターフォーマットへの変換と、センターフォーマットから受注フォーマットへの変換と、出荷フォーマットからセンターフォーマットへの変換と、センターフォーマットから納品フォーマットへの変換を行うのが好ましい。
【００２８】
Ｍ種類の発注フォーマット（Ｍ種類の納品フォーマット）とＮ種類の受注フォーマット（Ｎ種類の出荷フォーマット）が存在する場合、前述のようにＭ＋Ｎ種類のフォーマット変換手順が理論上存在することになるので、予めＭ＋Ｎ種類全てのフォーマット変換手順を定めて記憶しておくこともできるし、現実の受発注が生じた時点で必要な変換手順を定めて順次記憶しておくこともできる。
【００２９】
本発明に基づく受発注データ管理方法は、発注者から受信した発注情報に複数の受注者が対応する場合、前記発注情報を振分けて、該当する複数の受注者それぞれの受注フォーマットに変換すると共に、各受注者に送信する受注情報に前記取引番号を関連付ける過程を有してもよい。
【００３０】
発注者から受信した発注情報に複数の受注者が対応する場合とは、例えば、１つのハードウェアの発注に対して、ハードウェアの販売を行う事業者（受注者Ａ）による当該ハードウェアの納入と、ハードウェアの設置と接続、ソフトウェアの初期設定等を行う事業者（受注者Ｂ）による上記作業が必要になるような場合である。この場合、発注情報の振分けとは、前記１つの発注から、受注者Ａと受注者Ｂの受注情報を作成する作業が該当する。この場合、受注者Ａと受注者Ｂの受注情報は、上記ハードウェアの発注に対して付与された取引番号が関連付けられる。上記の場合、発注者は、ハードウェアの発注と同ハードウェアの設置等の作業の発注とに分けて発注を行ってもよく、この場合にはハードウェアと設置等の作業に対してはそれぞれ異なる取引番号が付与されることになる。
【００３１】
本発明に基づく受発注データ管理方法は、状況照会に対応して、前記取引番号によって関連付けられた発注情報と、受注情報と、出荷情報と、納品情報と、振分情報のうちの少なくとも１つを含む取引情報を表示する過程を有してもよい。
【００３２】
状況照会とは、例えば、発注者が、既に発注済みだがまだ納品のない取引について、発注情報が正確に受注者に届いたか否か、既に出荷は行われたか否か等について確認する必要があるという要請にこたえるものである。状況照会は、発注者に限らず、受注者あるいは受発注情報の仲介を行う事業者が行うこともできるものであるのが好ましい。本発明の場合には、発注情報に端を発した受注情報、出荷情報、納品情報、該当する場合には振分情報が何れも取引番号によって関連付けられているために、状況照会に応じた関連情報の抽出は極めて容易且つ迅速である。
【００３３】
本発明は、また、上記受発注データ管理方法を好適に実行可能な受発注システムを提供する。
本発明に基づく受発注システムは、発注者から、発注フォーマットに従って記述された発注情報をセンターコンピュータに送信可能な発注者コンピュータと、
前記発注者から発注フォーマットに従って記述された発注情報を受信し、該発注情報に取引番号を関連付けて、複数の発注者の発注フォーマットにおいて使用されるパラメータと、複数の受注者の受注フォーマットにおいて使用されるパラメータと、取引番号を包含する一群のパラメータを設定可能なセンターフォーマットに変換し、さらに該取引番号と関連付けられた発注情報を受注者の受注フォーマットに変換して、受注者コンピュータに送信可能なセンターコンピュータと、
前記発注者からの発注情報に基づいて、受注フォーマットに従って作成された受注情報を前記センターコンピュータから受信可能な受注者コンピュータとを備え、
複数の異なる発注フォーマットと複数の異なる受注フォーマットの間で取引番号と関連付けられた受発注データを変換・送受信する受発注システムである。
【００３４】
発注者コンピュータ、センターコンピュータ、受注者コンピュータには、上記の機能を有するものであれば、パソコン、サーバー、メインフレーム等、名称のいかんを問わず該当する。データの送受信が有線、無線、デジタル、アナログ何れで行われても良いことは言うまでもない。
【００３５】
本発明に基づく受発注システムには、前記センターフォーマットがさらに受注者の出荷フォーマットと、発注者の納品フォーマットにおいて使用されるパラメータを包含し、
前記センターコンピュータが、取引情報と関連付けられた受注者の出荷情報を前記出荷フォーマットから前記センターフォーマットに変換すると共に、該受注者の出荷情報を前記センターフォーマットから発注者の前記納品フォーマットに変換するシステムが含まれる。
【００３６】
上記受発注システムは、発注者から受信した発注情報に複数の受注者が対応する場合、前記センターコンピュータは当該発注情報を振分けて、該当する複数の受注者それぞれの受注フォーマットに変換すると共に、受注情報に前記取引番号を関連付けて各受注者に送信するものであってもよい。
【００３７】
上記受発注システムは、さらに、状況照会に対応して、前記取引番号によって関連付けられた発注情報と、受注情報と、出荷情報と、納品情報と、振分情報のうちの少なくとも１つを含む取引情報を取得することが可能なシステムであってもよい。
【００３８】
本発明はまた、
発注者コンピュータから発注フォーマットに従って記述された発注情報を受信し、
該発注情報に取引番号を関連付けて、複数の発注者の発注フォーマットにおいて使用されるパラメータと、複数の受注者の受注フォーマットにおいて使用されるパラメータと、取引番号を包含する一群のパラメータを設定可能なセンターフォーマットに変換し、
前記取引番号と関連付けられた発注情報を受注者の受注フォーマットに変換し、
受注者コンピュータに送信して、
センターコンピュータに、複数の異なる発注者コンピュータと複数の異なる受注者コンピュータの間で取引番号と関連付けられた受発注データを変換・送受信させるコンピュータソフトウェアを提供する。
【００３９】
本発明に基づくコンピュータソフトウェアは、前記センターフォーマットがさらに受注者の出荷フォーマットと、発注者の納品フォーマットにおいて使用されるパラメータを包含し、
前記センターコンピュータに、取引情報と関連付けられた受注者の出荷情報を前記出荷フォーマットから前記センターフォーマットに変換させると共に、該受注者の出荷情報を前記センターフォーマットから発注者の前記納品フォーマットに変換させるものであってもよい。
【００４０】
本発明に基づくコンピュータソフトウェアは、発注者から受信した発注情報に複数の受注者が対応する場合、前記センターコンピュータに、当該発注情報を振分けて、該当する複数の受注者それぞれの受注フォーマットに変換させると共に、受注情報に前記取引番号を関連付けて各受注者に送信させるものであってもよい。
【００４１】
上記コンピュータソフトウェアは、さらに、状況照会に対応して、前記センターコンピュータに、前記取引番号によって関連付けられた発注情報と、受注情報と、出荷情報と、納品情報と、振分情報のうちの少なくとも１つを含む取引情報を取得して表示および／または送信させるものであってもよい。
【００４２】
本発明は、また、上記コンピュータソフトウェアを格納した、コンピュータによって読み出し可能な記憶媒体（形式は問わない）を提供する。
【発明を実施するための最良の形態】
【００４３】
以下に、実施例に基づき本発明を実施するための形態について記載する。以下に記載する実施例は本発明の理解を助けるために記載するものであって、本発明が以下に記載する実施例に限定されることを意味するものではないことは言うまでも無い。
【実施例】
【００４４】
図１は、比較のために、従来技術に基づいた場合、つまりセンターフォーマットを使用せずに発注者毎のフォーマットから受注者毎のフォーマットにそれぞれデータフォーマットの変換を行うことを前提として、センターコンピュータが発注者からの発注情報を受信して受注者に受注情報を送信するまでの流れを説明した概念図である。
【００４５】
図１に記載のように、センターコンピュータが発注者からの発注情報を受信１００すると、受信ファイル管理番号発番テーブル１０を参照して、受信ファイルごとに固有の管理番号（受信番号）を発行して、ファイル受信状況２０を記録する。この時、従来技術としては知られていないが、さらに取引番号を発行し、受信ファイルにこれを含めて保存して、以降の使用に備えることも不可能ではない。次に、以降の取引状況を管理するために、取引状況作成３００をおこなう。具体的には、受信番号、取引番号等を含む取引状況３０データを作成する。従来技術には記載されていないが、この時、取引状況データに取引番号を含めることもできる。
【００４６】
１つの発注から複数の受注者による受注が生じるような場合に対応するために、振分３５０を行っても良い。振分を行った場合には、取引状況に変更を生じるので、取引状況３５データを更新する。
【００４７】
次に、受注者に対して受注情報を送信するために、各社個別のフォーマット化４００を行ない、送信ファイル管理番号発番テーブル４０を参照して当該送信の管理番号を取得してセンターコンピュータから受注者コンピュータに受注情報を送信５００する。この時、ファイル送信状況５０を保存するとともに、取引状況６０データを更新する。
【００４８】
上記の従来技術に基づいた場合、問題の１つは、センターコンピュータが発注者から受信した受信ファイルのフォーマットは発注者に固有のものであり（ここでは仮にｍ種類のフォーマットが存在すると仮定する）、これを受注者固有のフォーマット（仮にｎ種類のフォーマットが存在すると仮定する）に変換するとすれば、ｍ×ｎ種類の変換プログラムが必要になることである。さらに、第２の問題は、発注から受注まで１つの取引番号を付与して一貫性を持たせたとしても、ファイル受信状況２０にはＭ種類のフォーマットが用いられており、ファイル送信状況５０にはＮ種類のフォーマットが用いられているので、これらから１つの取引を検索するには結局Ｍ×Ｎ通りのフォーマットの組み合わせを前提に取引番号を検索しなければならないことである。
【００４９】
図２は、本発明の実施例に基づくセンターコンピュータによる処理の流れの概念を示したフロー図である。前出の従来技術に基づくフロー図１との相違点は、発注者からの発注情報をセンターコンピュータが受信１００した後、センターフォーマットへの統一フォーマット化２００が行われることである。したがって、取引状況の作成３００は発注情報が統一されたセンターフォーマットに従って記載されていることを前提に行われ、取引状況３０データは発注者、受注者の如何にかかわらず統一されたフォーマットで記載される。次に、統一されたセンターフォーマットから各受注者が使用しているフォーマットへの各社個別フォーマット化４００が行われ、フォーマット変換された受注情報がセンターコンピュータから送信５００される。この時、取引状況が更新６０されるが、更新された取引状況も統一されたフォーマットで記載されている。
【００５０】
したがって、まず、必要なフォーマット変換の種類としては、Ｍ種類の発注者フォーマットからセンターフォーマットへの変換がＭ種類、センターフォーマットからＮ種類の受注者フォーマットへの変換がＮ種類で、合計Ｍ＋Ｎ種類の変換になり、従来技術の下ではＭ×Ｎ種類の変換を扱う必要があったのに比較して、特にＭ、Ｎが大きな値になれば変換の種類を大幅に削減することができる。さらに、随時交信される取引状況はセンターフォーマットを前提に１種類のフォーマットで作成されているので、１つの取引番号に対応する取引状況を検索することは極めて容易（１種類のフォーマットを扱えば足りる）である。
【００５１】
図３は、本発明の実施例に基づく受発注管理方法が、さらに、振分３５０過程を含む場合の作業の流れを示すフロー図である。前出図２との相違点は、取引状況作成３００の後に、振分３５０が行われる点である。振分によって、１つの発注から複数の受注が派生することになる。したがって、振分を行った後で、取引状況３５のデータを更新しておくことが望ましい。以降の処理は、各社個別フォーマット化４００において、派生した複数の受注者に対してそれぞれ固有のフォーマット化を行い、センターコンピュータからの送信５００を行う点が異なるのみである。
【００５２】
図４は、発注者がセンターコンピュータに送信した発注情報を保存したファイル受信状況２０と、取引状況３０、６０と、受注者への受注情報を保存したファイル送信状況５０における取引番号の関連付けを説明した図である。図の右側に枠で囲って示したように、取引状況３０、６０のデータには取引番号、受信ファイル番号、送信ファイル番号が記録されているので、取引状況３０、６０のデータを介して、受信ファイル番号が記録されているファイル受信状況２０とファイル送信状況５０を相互に関連付けることができる。これは、統一フォーマット化２００の段階で取引番号を発行した場合の例であるが、受信ファイル管理番号発番テーブル１０を参照した際に取引番号を発行し、ファイル受信状況２０とファイル送信状況５０に取引番号を含めることもできる。いずれの場合であっても、最新の取引状況を参照するためには、取引番号を手がかりにセンターフォーマットで記載された取引状況３０、６０を検索すれば足りる。
【００５３】
図５は、センターコンピュータの運営と課金の流れを説明するためのフロー図である。センターコンピュータあるいはセンターコンピュータを運営する事業者は、発注者と受注者に対して上述のような発注データから受注データへのフォーマット変換、出荷データ、納品データのフォーマット変換、取引情報の照会等のサービスを提供する対価として一定の課金を行うものと仮定する。
【００５４】
図示した例では、発注フォーマットからセンターフォーマットへのフォーマット変換と、センターフォーマットから受注フォーマットへのフォーマット変換を含む機能は、バッチ処理として行われることを前提としている。そのため、図では機能ごとに、管理サーバ１、バッチサーバ２、ホスト３と記載されているが、これらは全てセンターコンピュータによって実行されるものであっても良い。上記変換は、バッチ処理ではなく受信からスタートする連続処理であっても良い。
【００５５】
図５によれば、発注情報を受信１００すると、連携スケジューラがバッチ処理のスケジュールを制御し、フォーマット変換（発注フォーマットからセンターフォーマットへのフォーマット変換）と、分割、振分、集約、フォーマット変換（センターフォーマットから受注フォーマットへのフォーマット変換）、および、受注コンピュータへの受注データの送信５００はバッチジョブとして処理される。フォーマット変換時には後の課金のために必要な情報を課金蓄積７０データ、課金基本７２データ、課金詳細７４データとして所定の記憶手段に書き込んで記憶させる。課金情報は課金蓄積情報等が更新されるたびに更新しても良いが、図では、日次あるいは月次で集計８０した上で、まとまった課金情報８２を生成して課金処理８４を行う例を示した。
【００５６】
図６は、課金のために必要な情報として記憶手段に書き込まれる情報の例を示す。図中の２０Ｔは発注情報の受信時に、受信者ごとに作成されるデータを例示したものであり、１つの発注データを受信した際に受信ファイル番号、取引先コード、処理日、受信送信の別と並んで、課金の基礎となるデータのバイト数、発注件数、伝票の数、明細の数が記録される。図中の５０Ｔは、同様に、受注者に対して受注情報の発送時に書き込まれる情報としては、送信ファイル番号、取引先コード、処理日、送受信の別と並んで課金の基礎となるデータのバイト数、発注件数、伝票の数、明細の数が記録される。
【００５７】
表１は毎月行われる課金処理に必要な管理情報の例を示した表である。取引先ごとに、課金種別と、集計と請求を行う処理請求日が異なっている。課金種別とは、課金の基礎を送受信したデータのバイト数に関連付けるか、受発注の件数と関連付けるか、伝票の数に関連付けるか等および計算方法の種別である。
【表１】
2010134771.tif 000003
表２は、課金処理の管理情報の別の例を示したものである。処理の度の段階で課金の基礎情報を取得するかおよび現時点での累積データの量を表示している。
【表２】
2010134771.tif 000004
【図面の簡単な説明】
【００５８】
【図１】従来技術に基づいた場合におけるセンターコンピュータが発注者からの発注情報を受信して受注者に受注情報を送信するまでの流れを説明した概念図
【図２】本発明の実施例に基づくセンターコンピュータによる処理の流れの概念を示したフロー図
【図３】本発明の実施例に基づく受発注管理方法が、さらに、振分過程を含む場合の作業の流れを示すフロー図
【図４】発注者がセンターコンピュータに送信した発注情報を保存したファイル受信状況と、取引状況と、受注者への受注情報を保存したファイル送信状況における取引番号の関連付けを説明した図
【図５】センターコンピュータの運営と課金の流れを説明するためのフロー図
【図６】課金のために必要な情報として記憶手段に書き込まれる情報の例
【符号の説明】
【００５９】
１      管理サーバ
２      バッチサーバ
３      ホスト
１０    受信ファイル管理番号発番テーブル
２０    ファイル受信状況
３０、３５、６０  取引状況
４０    送信ファイル管理番号発番テーブル
５０    ファイル送信状況
７０    課金蓄積
７２    課金基本
７４    課金詳細
１００  センタ受信
２００  統一フォーマット化
３００  取引状況作成
４００  各社個別フォーマット化
５００  センタ送信
【図１】
2010134771.tif 000005
【図２】
2010134771.tif 000006
【図３】
2010134771.tif 000007
【図４】
2010134771.tif 000008
【図５】
2010134771.tif 000009
【図６】
2010134771.tif 000010