(57)【要約】 【課題】  複数の発注者と複数の受注者の間の発注情報、受注情報、出荷情報、納品情報を容易に変換可能にすると同時に変換方法のデバッグを容易にする受発注データ変換方法、受発注管理コンピュータソフトウェアおよび記憶媒体を提供する。【解決手段】    複数の発注者の発注フォーマットにおいて使用されるパラメータと、複数の受注者の受注フォーマットにおいて使用されるパラメータとを包含する一群のパラメータを設定可能なセンターフォーマットを準備する過程と、  発注者の発注情報を前記発注フォーマットから前記センターフォーマットに変換する過程と、  発注者の発注情報を前記センターフォーマットから当該発注を受ける受注者の前記受注フォーマットに変換する過程を有する受発注データ変換方法。【選択図】  図１
2009245373.tif 000002
【特許請求の範囲】
【請求項１】
複数の発注者の発注フォーマットにおいて使用されるパラメータと、複数の受注者の受注フォーマットにおいて使用されるパラメータとを包含する一群のパラメータを設定可能なセンターフォーマットを準備する過程と、
発注者の発注情報を前記発注フォーマットから前記センターフォーマットに変換する過程と、
発注者の発注情報を前記センターフォーマットから当該発注を受ける受注者の前記受注フォーマットに変換する過程を有する受発注データ変換方法。
【請求項２】
前記センターフォーマットはさらに受注者の出荷フォーマットと、発注者の納品フォーマットにおいて使用されるパラメータを包含し、
受注者の出荷情報を前記出荷フォーマットから前記センターフォーマットに変換する過程と、
受注者の出荷情報を前記センターフォーマットから発注者の前記納品フォーマットに変換する過程を有する請求項１に記載の受発注データ変換方法。
【請求項３】
前記発注者の納品フォーマットにおいて必要な情報が、発注情報に含まれていたにもかかわらず受注者の出荷情報に含まれないとき、前記センターフォーマットから発注者の納品フォーマットへの変換を行う際に、発注者の発注情報に含まれていた前記必要な情報を加えて変換を行う請求項２に記載の受発注データ変換方法。
【請求項４】
前記センターフォーマットは、タグ付きＣＳＶファイルである請求項１ないし３の何れかに記載の受発注データ変換方法。
【請求項５】
複数の発注者の発注フォーマットにおいて使用されるパラメータと、複数の受注者の受注フォーマットにおいて使用されるパラメータとを包含する一群のパラメータを設定可能なセンターフォーマットを備え、
発注者の発注情報を前記発注フォーマットから前記センターフォーマットに変換し、
発注者の発注情報を前記センターフォーマットから当該発注を受ける受注者の前記受注フォーマットに変換する受発注管理コンピュータソフトウェア。
【請求項６】
前記センターフォーマットはさらに受注者の出荷フォーマットと、発注者の納品フォーマットにおいて使用されるパラメータを包含し、
受注者の出荷情報を前記出荷フォーマットから前記センターフォーマットに変換する過程と、
受注者の出荷情報を前記センターフォーマットから発注者の前記納品フォーマットに変換する過程を有する請求項１に記載の受発注管理コンピュータソフトウェア。
【請求項７】
前記発注者の納品フォーマットにおいて必要な情報が、発注情報に含まれていたにもかかわらず受注者の出荷情報に含まれないとき、前記センターフォーマットから発注者の納品フォーマットへの変換を行う際に、発注者の発注情報に含まれていた前記必要な情報を加えて変換を行う請求項６に記載の受発注管理コンピュータソフトウェア。
【請求項８】
前記センターフォーマットは、タグ付きＣＳＶファイルである請求項５ないし７の何れかに記載の受発注管理コンピュータソフトウェア。
【請求項９】
さらに、異なる複数の発注フォーマットのそれぞれからセンターフォーマットへの変換手順と、センターフォーマットから異なる複数の受注フォーマットのそれぞれへの変換手順と、異なる複数の出荷フォーマットのぞれぞれからセンターフォーマットへの変換手順と、センターフォーマットから異なる複数の納品フォーマットへの変換手順とを記憶し、
該手順に基づいて前記発注フォーマットからセンターフォーマットへの変換と、センターフォーマットから受注フォーマットへの変換と、出荷フォーマットからセンターフォーマットへの変換と、センターフォーマットから納品フォーマットへの変換を行う請求項６または７に記載の受発注管理コンピュータソフトウェア。
【請求項１０】
請求項５ないし９の何れかに記載のコンピュータソフトウェアを記憶したコンピュータによって読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の発注者と複数の受注者との間で発注および受注を共通に管理することのできる方法、当該方法を実行可能なコンピュータソフトウェアおよび当該コンピュータソフトウェアを記憶した記憶媒体に関し、特に、発注に関して複数の発注者がそれぞれ異なるフォーマットを用い、受注に関して複数の受注者がそれぞれ異なるフォーマットを用いているような場合であっても効率よく、かつ漏れなく対応可能な方法等に関するものである。
【０００２】
コンピュータ通信による受発注が普及した今日では、発注者（企業または個人）は、物品またはサービスの発注に際して特定の発注フォーマットを使用して、発注票等を電子的に受注者（企業または個人）に送信することが行われている。当該特定の発注フォーマットを利用することは、発注者の側の関連処理（工程管理、経理処理、税務処理等）上は便宜である。しかし、一般に、発注フォーマットは発注者ごとに異なっている。
【０００３】
一方受注者（企業または個人）の側でも、受注に際して特定の受注フォーマットを使用してコンピュータによって関連処理（納期管理、在庫管理、経理処理等）を行っている。受注者の側でも、一般に、受注フォーマットは受注者（企業、個人）ごとに異なっている。
【０００４】
同一業種の企業間で異なる発注フォーマットおよび受注フォーマットを統一して効率化を図る動きも無いではないが、一般に発注側からみた受注側企業（つまり、１つの発注企業にとって物品またはサービスを発注する可能性のある相手企業）は極めて他業種にわたり、受注側からみた発注側企業（１つの受注企業が受注する可能性のある相手企業）についても同様であるために、業種間を越えて受発注フォーマットをすべて統一することは困難な状況である。
【０００５】
一方、発注者と受注者の間で発注フォーマットで記載された発注情報を受注フォーマットに変換して受注者に送付するサービスも存在しえる。しかし、発注者側の複数の企業または個人が合計Ｍ種類のフォーマットを利用しており、受注者側の複数の企業または個人が合計Ｎ種類のフォーマットを利用しているとすれば、Ｍ×Ｎ通りの変換が必要となり、非常に多くの変換を可能にする必要がある。仮にこれらの変換をコンピュータに行わせるものとすれば、コンピュータが変換に要する時間そのものはごく短時間である可能性も有るが、それぞれの変換プログラムにバグは無いか等を確認する作業の負荷は非常に大きい。まして、発注者側と受注者側のデータ変換を行うのが、データ変換のための専門業者であったとすれば、発注者側のフォーマットにも受注者側のフォーマットにも不慣れなために、デバッグ作業の付加は一層大きなものになる。
【０００６】
さらに、発注側は取引を管理するために特定のパラメータを必要としているが（例えば、発注担当者の社内コード等）、受注者の側に当該パラメータを管理する用意が無い場合、発注情報を発注フォーマットから受注フォーマットに変換した際に当該パラメータは失われ、以後の出荷情報、納品情報には当該パラメータは含まれないことになる。発注者の側としては、納品情報に当該パラメータが含まれていることを予定しているので、納品管理上支障を生じることになる。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は、従来技術が有する上記の問題を解決することを目的としたものであって、より具体的には、複数の発注者と複数の受注者の間の発注情報、受注情報、出荷情報、納品情報を容易に変換可能にすると同時に変換方法のデバッグを容易にする受発注データ変換方法、受発注管理コンピュータソフトウェアおよび記憶媒体を提供することを目的とする。
【０００８】
本発明はさらに、前記発注者の納品フォーマットにおいて必要な情報が、発注情報に含まれていたにもかかわらず受注者の出荷情報に含まれないとき、前記センターフォーマットから発注者の納品フォーマットへの変換を行う際に、発注者の発注情報に含まれていた前記必要な情報を加えて変換を行うことで発注者が支障なく処理可能にする方法等を提供する。本発明によって解決されるさらに別の課題および本発明の効果は、明細書の全体を通じて明らかにする。
【課題を解決するための手段】
【０００９】
上記の目的を達成するために、本発明は、複数の発注者の発注フォーマットにおいて使用されるパラメータと、複数の受注者の受注フォーマットにおいて使用されるパラメータとを包含する一群のパラメータを設定可能なセンターフォーマットを準備する過程と、
発注者の発注情報を前記発注フォーマットから前記センターフォーマットに変換する過程と、
発注者の発注情報を前記センターフォーマットから当該発注を受ける受注者の前記受注フォーマットに変換する過程を有する受発注データ変換方法を提案する。
【００１０】
本明細書に於いて「フォーマット」とは、データの記載形式を指す言葉として用いており、ＣＳＶ、ＸＭＬ等の言語形式、特定の言語形式の下でのデータ構造等を表す意味で用いる。発注フォーマットは、いわば発注者が用いる発注票の形式に対応する概念である。パラメータとは、例えば、取引番号、商品コード、発注日、発注数量等の項目である。「発注情報」とは、発注の具体的な内容、例えば、取引番号としての値「２００８０３３１０４５１」、商品コードとしての値「ＡＢ０３２４」等である。
【００１１】
発注者の発注情報を前記発注フォーマットから前記センターフォーマットに変換する過程は、例えば以下のような処理を含む。すなわち、発注フォーマットが、ａ）発注日（平成表示）、ｂ）取引番号、ｃ）商品コードに関する情報をこの順序で記載するものであり、センターフォーマットが、１）取引番号、２）発注日（西暦表示）、３）商品コードをこの順序で記載するものであった場合、上記変換過程は、ｂ）の値を取引番号として記録し、ａ）の値を平成表示から西暦表示に変換した後に発注日として記録し、ｃ）の値を商品コードとして記録する。前記センターフォーマットから当該発注を受ける受注者の前記受注フォーマットに変換する過程もほぼ同様の手順である。
【００１２】
上記のように構成した本発明の場合、複数の発注者と複数の受注者との間で受発注データを変換する際には、変換と変換内容の確認（デバッグ）等の労力が大幅に削減される。それは、複数の発注者がＭ種類の発注フォーマットを使用しており（複数の発注者が共通の発注フォーマットを利用することもあるので、発注者の数と発注フォーマットの数は必ずしも一致しない）、複数の受注者がＮ種類の受注フォーマットを利用している場合、従来の技術によれば、Ｍ×Ｎ通りのフォーマット変換に対応することが必要であったのに対して、本発明を利用した場合は、Ｍ＋Ｎ通りのフォーマット変換に対応すれば足りるからである（Ｍ種類の発注フォーマットからセンターフォーマットへの変換と、センターフォーマットからＮ種類の受注フォーマットへの変換を行えば足りる）。Ｍが１００社、Ｎが１００社であれば、従来技術によれば１０，０００通りの変換が必要であるのに対して、本発明では２００通りであるから、必要な組み合わせの数は１／５０になる。
以下に記載するように、前記センターフォーマットが受注者の出荷フォーマットと発注者の納品フォーマットを包含する場合には、対応すべきフォーマット変換の種類は同様に大幅に少なくなる。
【００１３】
本発明による受発注データ変換方法は、さらに、前記センターフォーマットはさらに受注者の出荷フォーマットと、発注者の納品フォーマットにおいて使用されるパラメータを包含し、
受注者の出荷情報を前記出荷フォーマットから前記センターフォーマットに変換する過程と、
受注者の出荷情報を前記センターフォーマットから発注者の前記納品フォーマットに変換する過程を有するものであってもよい。
【００１４】
受注者の出荷情報を出荷フォーマットからセンターフォーマットに変換する過程は、例えば以下のような処理を含む。すなわち、出荷フォーマットが、ａ）出荷日（平成表示）、ｂ）取引番号、ｃ）商品コードに関する情報をこの順序で記載するものであり、センターフォーマットが、１）取引番号、２）出荷日（西暦表示）、３）商品コードをこの順序で記載するものであった場合、上記変換過程は、ｂ）の値を取引番号として記録し、ａ）の値を平成表示から西暦表示に変換した後に発注日として記録し、ｃ）の値を商品コードとして記録する。前記センターフォーマットから当該発注を受ける受注者の前記受注フォーマットに変換する過程もほぼ同様の手順である。
発注者の発注から受注者の受注、出荷、発注者の納品までの一連の取り引きをセンターフォーマットを介して行った場合、必要なフォーマット変換の種類が大幅に削減されることは既に述べたとおりである。
【００１５】
上述のように、本発明に基づいて出荷情報から納品情報に変換を行うことによって、前述した発注情報から受注情報への変換と同様に、変換の種類を大幅に削減することができる（前記の例に拠れば、従来方法では、Ｍ×Ｎ種類の変換が必要であるのに対して、Ｍ＋Ｎ種類の変換を扱えば足りる）。したがって、変換に要する労力のみならず変換の確認に要する労力が大幅に軽減されることは前述の通りである。
【００１６】
本発明による受発注データ変換方法は、前記発注者の納品フォーマットにおいて必要な情報が、発注情報に含まれていたにもかかわらず受注者の出荷情報に含まれないとき、前記センターフォーマットから発注者の納品フォーマットへの変換を行う際に、発注者の発注情報に含まれていた前記必要な情報を加えて変換を行うものであってもよい。
【００１７】
例えば、発注側の発注フォーマットには発注担当者の氏名を記載する欄があり、発注者指名情報が記載されていたにもかかわらず、受注フォーマットには発注担当者の氏名が含まれていない場合（例えば、受注者側では発注者の企業名と事業所名のみで足りると考えているような場合が考えられる）、従来方法によれば、受注フォーマットへの変換を行うことによって発注担当者の氏名は欠落することになり、その後の手続きである出荷情報に含まれることは無い。したがって、発注者のために出荷情報を納品情報にフォーマット変換しても、発注担当者の氏名は欠落したままになる。発注者側としては、発注情報および納品情報に発注担当者の氏名を含めて取り扱っているとすれば、これでは不便である。
【００１８】
本発明の上記態様によればこの不便を解消することができる。すなわち、発注フォーマットから受注フォーマットへの変換を行う際に、受注フォーマットが必要としない情報であっても、納品情報に必要な情報であれば、これを一旦記憶し、出荷フォーマットを納品フォーマットに変換する際に当該情報を納品フォーマットに含める。そのためには、発注フォーマットに含まれる情報を全て記憶してもよいし、発注フォーマットに含まれていたにもかかわらず受注者の出荷フォーマットに含まれない情報のみを記憶してもよい。
【００１９】
前記センターフォーマットは、タグ付きＣＳＶファイルであるのが好ましい。ここでＣＳＶとはComma Separated Valuesと称するデータをカンマで区切って並べたファイル形式をいう。１データ１ファイルであるＸＭＬ（Extensible markup Language）と比較した場合、ＣＳＶはファイルを結合してもタグによってデータの先頭を判定できるのでファイルサイズを小さくできる利点がある。経験則によれば、ＣＳＶのファイルサイズはＸＭＬの１／１０程度である。
【００２０】
本発明では、異なる複数の発注フォーマットのそれぞれからセンターフォーマットへの変換手順と、センターフォーマットから異なる複数の受注フォーマットのそれぞれへの変換手順と、異なる複数の出荷フォーマットのぞれぞれからセンターフォーマットへの変換手順と、センターフォーマットから異なる複数の納品フォーマットへの変換手順とを記憶し、
該手順に基づいて前記発注フォーマットからセンターフォーマットへの変換と、センターフォーマットから受注フォーマットへの変換と、出荷フォーマットからセンターフォーマットへの変換と、センターフォーマットから納品フォーマットへの変換を行うのが好ましい。
【００２１】
Ｍ種類の発注フォーマット（Ｍ種類の納品フォーマット）とＮ種類の受注フォーマット（Ｎ種類の出荷フォーマット）が存在する場合、前述のようにＭ＋Ｎ種類のフォーマット変換手順が理論上存在することになるので、予めＭ＋Ｎ種類全てのフォーマット変換手順を定めて記憶しておくこともできるし、現実の受発注が生じた時点で必要な変換手順を定めて順次記憶しておくこともできる。
【発明を実施するための最良の形態】
【００２２】
以下に、実施例に基づき本発明を実施するための形態について記載する。以下に記載する実施例は本発明の理解を助けるために記載するものであって、本発明が以下に記載する実施例に限定されることを意味するものではないことは言うまでも無い。
【実施例】
【００２３】
図１は、説明を簡略化するために、２つの発注企業と１つの受注企業間での受発注を例にとって本発明の働きを説明するための流れ図である。
発注企業の発注情報（発注データ）にはパラメータＡ１、Ｂ１、ＣＸ１が含まれているとする。これに対して、受注企業の受注情報にはＡ１とＢ１のみが必要とされている。また、受注企業の出荷情報にはＡ１とＤ１が含まれているが、発注企業の納品情報には、パラメータＡ１、Ｄ１、Ｃ１が必要である。このような状況では、従来方法によって発注情報を受注情報に変換しただけでは発注情報に含まれていたパラメータＣ１が受注情報から欠落し、結果的にＣ１は納品情報にも含まれないことになる。そこで、本発明の場合は、発注フォーマットから受注フォーマットへの変換を行う際にＣ１を一次保存し、出荷フォーマットから納品フォーマットへの変換を行う際に、保存していたＣ１を挿入することで納品フォーマットに適合した納品情報を作成する。
【００２４】
Ｃ１は、発注企業が受発注処理に常に使用するパラメータであってもよいし、特定の期間のみ使用するようなパラメータであってもよい。フォーマット変換を行った後は、フォーマットチェックを行うことが望ましい。
【００２５】
図２は、本発明に基づく、発注企業と受注企業間のデータ変換の流れを図示したものである。この例においては、前出の例でＣ１で示したパラメータ、発注者の納品フォーマットにおいて必要な情報であって、発注情報に含まれていたにもかかわらず受注者の出荷情報に含まれない情報は、販促開始日、販促終了日、出荷場所コード、納品経路である。販促開始日、販促終了日は、比較的変更頻度の高い情報なので、これをフォーマット変換の対象とすると変換後のフォーマットチェック等が作業工数が大きくなるので、フォーマット変換の対象とせずに、単に蓄積と保管を行うだけにするのが好ましい。出荷場所コードや納品経路の様に発注ごとに変わる種類の情報についても同様である。
【００２６】
また、発注から納品までの受発注データを一括して変換する場合には、一連の受発注手続きに１つの取引番号を付与して参照するのが効率的である。例えば、センターフォーマットにおいて発注と納品に共通の識別番号を付加することによって発注から納品までの一環した管理が可能になる。
【００２７】
図３は、本発明に基づくフォーマット変換のうち補完作業に関する作業の流れ図である。まず、発注情報を受けると、発注フォーマットからセンターフォーマットへの変換をおこなう際あるいはセンターフォーマットから受注フォーマットへの変換をおこなう際、補完の要否（有無）を判断する。その際は、発注企業と受注企業の組み合わせ毎に予め定めた補完フラグを参照する。補完フラグが０であれば、補完は不要であると判断して、受注者に、受注フォーマットに基づく受注データを送付する。補完フラグが１であって補完が必要なことを示していれば、必要な補完項目と補完データを取得して保存する。ここで、補完フラグは０または１によって単に補完の要否を示すものであってもよいし、１に代えて補完すべき項目を表す値によってどのパラメータを補完すべきかを具体的に示すものであってもよい。
【００２８】
補完が必要な場合は、出荷フォーマットからセンターフォーマットへの変換の際またはセンターフォーマットから納品フォーマットへの変換の際に、保管すべき項目の情報を補完して納品フォーマットに従って納品情報を作成する。
【００２９】
センターフォーマットはタグ付きのＣＳＶ形式で記載されているのが好ましい。図４は、タグ付きＣＳＶ形式の場合にはデータを記述するためのスクリプト（あるいはデータ長）が、ＸＭＬ等と比較しても短くなることを示すための概念図である。タグ付きＣＳＶの場合には、図示したようにファイルを結合した結果レコードＡ〜Ｄが繰り返し記録されているような場合であっても、Ａレコードが出現したところがデータの先頭であると見分けることができるので、それ以上の記述を必要としない。
【００３０】
図５は、ＸＭＬとタグ付きＣＳＶによる記述を比較したものである。同一の内容を記述したものであるにもかかわらず、タグ付きＣＳＶによる記述はＸＭＬに比較して遥かに短縮されていることが分かる。
【００３１】
センターフォーマットのデータ量を小さくするためには、例えば以下の形式を採用することができる。レコード長（７桁）、ヘッダ長（５桁）、ヘッダ部及びデータ部から成る構成する。また処理内容により以下の４つのヘッダ部を使い分けることができる。分割：        発注者要件により、受注者別にデータを分割する場合に受注者別の情報を特別に持つ。振り分け：受注者要件により、商品分類毎に送信先を振り分ける場合に、振り分け先の情報を特別に持つ。複写：発注者要件により、複写先を指定するものである。
【図面の簡単な説明】
【００３２】
【図１】本発明の一実施例による受発注のフォーマット変換を示す概念図
【図２】本発明の一実施例による受発注のフォーマット変換を示す概念図
【図３】本発明において、補完が必要な場合の判断の流れを示すフロー図
【図４】本発明においてセンターフォーマットにタグ付きＣＳＶ形式を用いる利点を示す概念図
【図５】ＸＭＬとタグ付きＣＳＶによって同一内容を記述したスクリプトの比較を示す概念図
【図１】
2009245373.tif 000003
【図２】
2009245373.tif 000004
【図３】
2009245373.tif 000005
【図４】
2009245373.tif 000006
【図５】
2009245373.tif 000007