(57)【要約】【課題】注文形式が異なる発注企業に対しても、新たなシステム化投資をすることなく対応できる受発注システムを提供する。【解決手段】この受発注システムは、複数の企業からなる発注先から注文データを受信し、その注文データのデータ形式を受注側が処理しうるデータ形式に変換テーブル１２４で変換し、その変換された注文データによって電子商取引を行うものであって、変換テーブル１２４を発注先ごとに用意し、変換テーブル１２４には、受注側の１つのデータ項目に対して発注先の１つ以上のデータ項目を組み合わせて定義しておき、発注先から注文データを受信した場合、変換テーブル１２４で受注側の受発注システムで処理し得るデータの形式に変換してから受注処理を行うようにした。【選択図】        図２
2004178190.tif 000002
【特許請求の範囲】
【請求項１】
複数の企業からなる発注先から注文データを受信し、その注文データのデータ形式を受注側が処理しうるデータ形式に変換テーブルで変換し、その変換された注文データによって電子商取引を行う受発注システムにおいて、前記変換テーブルを発注先ごとに用意し、前記変換テーブルには、前記受注側の１つのデータ項目に対して前記発注先の１つ以上のデータ項目を組み合わせて定義しておき、前記発注先から注文データを受信した場合、前記変換テーブルで受注側の受発注システムで処理し得るデータの形式に変換してから受注処理を行うことを特徴とする受発注システム。
【請求項２】
請求項１に記載の受発注システムにおいて、前記注文データを変換するときに、その注文データ中に発注先の使用するコード体系のコードがあるときに、そのコードを受注側で使用するコード体系のコードへ変換するようにしたことを特徴とする受発注システム。
【請求項３】
請求項１または２に記載の受発注システムにおいて、前記発注先からの注文データの送信をＷｅｂサービスあるいは電子メールで行うようにしたことを特徴とする受発注システム。
【請求項４】
請求項１、２または３に記載の受発注システムにおいて、前記変換されたデータをチェックし、エラーがあった場合には、受注受付担当者へ通知することを特徴とする受発注システム。
【請求項５】
請求項４に記載の受発注システムにおいて、エラーの通知を受けた前記受注受付担当者から該エラーのみを入力させて注文データを修正することを特徴とする受発注システム。
【請求項６】
請求項５に記載の受発注システムにおいて、エラーが修正されるのを監視し、修正された注文データを再度チェックするようにしたことを特徴とする受発注システム。
【請求項７】
請求項１乃至６のいずれかに記載の受発注システムにおいて、前記受注処理した結果の納期データを当該注文データに付して、受注確認情報として返信することを特徴とする受発注システム。
【請求項８】
請求項７に記載の受発注システムにおいて、発注先への受注確認の返信は、発注先が注文データを送信してきたときの送信形式と同じ形式とすることを特徴とする受発注システム。
【請求項９】
複数の企業からなる発注先から送信された注文データによって受注側と電子商取引を行う受発注システムにおいて、前記発注先ごとに、受注側の１つのデータ項目に対して発注先の１つ以上のデータ項目を組み合わせて定義した変換テーブルと、前記変換テーブルを用いて、前記発注先から受信した注文データを前記受注側の受発注システムで処理し得るデータの形式に変換するデータ変換手段とを備えることを特徴とする受発注システム。
【請求項１０】
コンピュータに、請求項１乃至９のいずれかに記載の受発注システムの機能を実行させるためのプログラム。
【請求項１１】
請求項１０に記載の受発注システムのプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、受発注システム、プログラムおよび記録媒体に関し、具体的には、企業間で電子データ交換によって商取引を行うときに、発注企業から送られてきたデータを受注企業における受発注システムで処理できるデータとして変換する技術に関する。
【０００２】
【従来の技術】
従来からＥＤＩ（Ｅｌｅｃｔｒｏｎｉｃ  Ｄａｔａ  Ｉｎｔｅｒｃｈａｎｇｅ：電子データ交換）を使って、基幹業務（生産計画、在庫管理、購買等）において、特定企業間でのデータ交換を効率化してきた。このため商取引で使用する紙ベースの各種帳票を電子データ化し、システム間でのデータ交換を標準化した。
この標準化されたＥＤＩは、専用回線やＶＡＮ（付加価値情報ネットワーク）のような閉じたネットワーク上で特定企業間のデータ交換に利用されている。
【０００３】
しかし、専用回線やＶＡＮを使うＥＤＩでは、導入コストおよび運用コストが高いため、導入できるのは大企業に限られていた。
このため、インターネットが普及するにつれて、専用回線やＶＡＮの代わりにインターネットを使うＷｅｂ−ＥＤＩが使われるようになった。
【０００４】
このＷｅｂ−ＥＤＩでは、Ｗｅｂブラウザを通じてインターネット上で取引できるため、低コストの導入・維持ができるので、従来はＥＤＩを導入しにくかった中小の取引先や取引頻度の少ない取引先を情報の共有化のメンバーとして取り込めるようになり、新規の取引先においても最初から電子商取引を行うことができるようになった。
【０００５】
また、異なる企業の基幹業務システム間でデータ交換を行うためには、データ記述を共通化しなければならなくなった。このため、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）でデータを記述することによって、特定の企業やシステム環境に依存しないＥＤＩ（これをＸＭＬ−ＥＤＩと呼んでいる）を実現できるようになっている。
【０００６】
【特許文献１】
特開平０５−６１７４５号公報
【特許文献２】
特開２００２−９９７５４号公報
【特許文献３】
特開２００１−３２５５３７号公報
【０００７】
【発明が解決しようとする課題】
しかしながら、多数の発注企業から受注する受注企業の場合、発注企業ごとに電子データ交換の仕様（注文フォーマットやデータコード等）が異なっているため、受信したデータを自社の基幹業務システムで処理するために、個別にシステム化対応を実施する必要があり、システム化投資もその都度発生していた。
【０００８】
上述した注文フォーマットが異なる場合を解決するため、特許文献１の「フォーマットの変換装置」は、受発注システムで使われるフォーマットに対して、予め変換前後のフォーマットの定義に基づいて変換テーブルを作成しておき、入力されたデータを判別して変換テーブルを選択してフォーマットの変換を行うようにした。この変換に際して、１対１に変換が取れないものや特別に変換を伴う場合には、変換に先立って例外処理を施した後に変換テーブルを使ってフォーマット変換を行う。これにより、ユーザのフォーマット変更要求に対し柔軟に対応することができる。
【０００９】
しかし、この特許文献１による方法では、変換前後のフォーマット上の項目が１対１に対応しない場合には、特別な処理を行う必要があるため、相変わらず個別にシステム化対応をしなければならない。
【００１０】
また、一旦発注企業から送られてきた電子データにエラーが含まれていることが分かった場合には、従来では、発注企業に連絡または発注企業側でエラー状況を監視する等をしてもう一度データを作成して、送り直してもらっていた。例えば、特許文献２の「受注システム」では、インターネット上にサーバをホストに繋いだシステムを構築しておき、発注先は、インターネット経由でサーバにアクセスして発注情報を入力する。
サーバでは、入力された発注情報をチェックし、サーバ内のファイルに仮受付けオーダとして格納するとともに、このオーダを定期的にホストに送信する。
【００１１】
ホストは、これを正式オーダとして登録し、チェックおよび在庫引当を経てホスト内のファイルに格納し、このオーダのデータを定期的にサーバのファイルに送信する。
他方、ホストが正式オーダとし得ない仮受付けオーダは、エラーデータとしてホスト内のファイルに格納し、定期的にサーバのファイルに送信する。
サーバは、ホストから受信した正式オーダとしての登録オーダまたはエラーデータを、得意先に電子メールにて送信したり、得意先がインターネット経由でサーバにアクセスして受注オーダの状況を確認することができるようにした。
【００１２】
一方、企業間の注文では、発注側へ返信することなく、受注側で対処することが一般的であるが、この特許文献２の発明ではエラーとなった注文データは発注側へ送り返されるので、修正して送り返さなければならなくなる。
【００１３】
また、発注企業で使われているコード体系と受注企業で使われているコード体系では一致していないのが一般的である。
これらのエラー修正や発注企業で使われているコード体系をそのまま使えるようにできれば顧客満足を得るものとなる。
【００１４】
また、特許文献３の「インターネットを介する受発注システム」では、統一注文フォーマットを定めて、それを発注企業が使って注文書を作成し、この注文書をインターネット上に設けた仲介装置へ送って受注企業の業種フォーマットに変換して受注企業に送るようにした。
【００１５】
しかしながら、会員として登録した企業全てに共通した統一注文フォーマットを作成したり、様々なコード体系に対応するために、仲介装置を維持管理することは難しい。
【００１６】
本発明は、上述した実情を考慮してなされたもので、注文書式が異なる発注企業に対しても、新たなシステム化投資をすることなく対応できる受発注システム、受発注システムの機能を実行するためのプログラムおよびそのプログラムを記録したコンピュータ読み取り可能な記録媒体を提供することを目的とする。
【００１７】
【課題を解決するための手段】
上記課題を解決するために、本発明の請求項１は、複数の企業からなる発注先から注文データを受信し、その注文データのデータ形式を受注側が処理しうるデータ形式に変換テーブルで変換し、その変換された注文データによって電子商取引を行う受発注システムにおいて、前記変換テーブルを発注先ごとに用意し、前記変換テーブルには、前記受注側の１つのデータ項目に対して前記発注先の１つ以上のデータ項目を組み合わせて定義しておき、前記発注先から注文データを受信した場合、前記変換テーブルで受注側の受発注システムで処理し得るデータの形式に変換してから受注処理を行うことを特徴とする。
【００１８】
また、本発明の請求項２は、請求項１に記載の受発注システムにおいて、前記注文データを変換するときに、その注文データ中に発注先の使用するコード体系のコードがあるときに、そのコードを受注側で使用するコード体系のコードへ変換するようにしたことを特徴とする。
また、本発明の請求項３は、請求項１または２に記載の受発注システムにおいて、前記発注先からの注文データの送信をＷｅｂサービスあるいは電子メールで行うようにしたことを特徴とする。
また、本発明の請求項４は、請求項１、２または３に記載の受発注システムにおいて、前記変換されたデータをチェックし、エラーがあった場合には、受注受付担当者へ通知することを特徴とする。
また、本発明の請求項５は、請求項４に記載の受発注システムにおいて、エラーの通知を受けた前記受注受付担当者から該エラーのみを入力させて注文データを修正することを特徴とする。
【００１９】
また、本発明の請求項６は、請求項５に記載の受発注システムにおいて、エラーが修正されるのを監視し、修正された注文データを再度チェックするようにしたことを特徴とする。
また、本発明の請求項７は、請求項１乃至６のいずれかに記載の受発注システムにおいて、前記受注処理した結果の納期データを当該注文データに付して、受注確認情報として返信することを特徴とする。
また、本発明の請求項８は、請求項７に記載の受発注システムにおいて、発注先への受注確認の返信は、発注先が注文データを送信してきたときの送信形式と同じ形式とすることを特徴とする。
【００２０】
また、本発明の請求項９は、複数の企業からなる発注先から送信された注文データによって受注側と電子商取引を行う受発注システムにおいて、前記発注先ごとに、受注側の１つのデータ項目に対して発注先の１つ以上のデータ項目を組み合わせて定義した変換テーブルと、前記変換テーブルを用いて、前記発注先から受信した注文データを前記受注側の受発注システムで処理し得るデータの形式に変換するデータ変換手段とを備えることを特徴とする。
【００２１】
また、本発明の請求項１０のプログラムは、コンピュータに、請求項１乃至９のいずれかに記載の受発注システムの機能を実行させるためのプログラムである。
また、本発明の請求項１１の記録媒体は、請求項１０に記載の受発注システムのプログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００２２】
以上の構成により、受注側の企業が、発注企業ごとに異なる注文データの形式を受注側の基幹業務システムが必要とする形式へ変換テーブルで変換するようにしたので、新たに発注企業が増えてもシステム化投資が短期間・低コストで対応することができる。
この変換においては、データ項目の１対１の変換だけでなく、複数の項目を組み合わせて１つの項目に対応付けることができるので、より柔軟な変換が行える。
また、発注側の企業で利用しているコード体系や文字列を受注側のコード体系に変換できるようにしたことにより、さらに発注側の入力負荷が低減される。
【００２３】
また、発注側の注文データに不備がある場合に、受注受付担当者が修正を行えるようにしたので、不備データについて受信データを活用して修正でき、受注入力の負荷が低減できる。
更に、受注側では注文データに対する納期情報を自動的に発注側へ送信するので、納期回答業務の負荷が低減できる。
一方、発注側の発注担当者としては、注文データに対する修正や納期情報の送信を受注側が行ってくれるので、修正や納期情報の確認作業がなくなり、業務の負荷が低減できる。
【００２４】
【発明の実施の形態】
以下、図面を参照して、本発明の受発注システムに係る好適な実施形態を説明する。
図１は、本実施形態の受発注システムの構成を示すブロック図である。
図１において、受発注システムは、複数の発注企業が所有する発注側システム２００と、受注管理を行う受注企業が所有する受注側システム１００とをネットワーク３００で接続している。ここで１つの発注企業で複数の発注側システムを所有してもよいが、本実施形態の説明では、１つの発注企業で１つの発注側システムを所有するとして説明する。また、企業ではなく、個人や中小企業や小規模な商店であっても同様に利用することができる。
【００２５】
ネットワーク３００は、専用回線網や公衆回線網を利用して、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）またはインターネットのいずれであってもよく、このネットワークを介して発注側システムと受注側システムとはｈｔｔｐプロトコルやｓｍｔｐプロトコル等の通信プロトコルによってデータをやり取りする。
【００２６】
発注側システム２００としては、発注側の受発注管理を行うコンピュータや単に注文データのみを送信するパーソナルコンピュータ（ノート型、デスクトップ型等）、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）や携帯電話等のいずれであってもよい。
【００２７】
更に、受注側システム１００は、Ｗｅｂサーバ１１０、注文管理システム１２０、基幹業務システム１４０、１台以上の担当者端末１５０とをネットワーク１６０で接続し、セキュリティ確保のためファイアウォールを介在させている。
ネットワーク１６０は、受注企業内に設置されたＷｅｂサーバ１１０、注文管理システム１２０、基幹業務システム１４０、１台以上の担当者端末１５０とを接続するＷＡＮまたはＬＡＮである。
【００２８】
Ｗｅｂサーバ１１０は、ネットワーク３００を介して発注側システム２００から注文データを受信し、ネットワーク１６０を介してこのデータを注文管理システム１２０へ送信する。
また、Ｗｅｂサーバ１１０は、ネットワーク１６０を介して注文管理システム１２０から処理された受注確認・納期データを受信し、注文データを受信したときと同じ通信プロトコルによってネットワーク３００を介して発注側システム２００へ返信する。
通信プロトコルがｈｔｔｐプロトコルの場合には、通信文をＸＭＬ伝送プロトコルによって送信し、ｓｍｔｐプロトコルの場合には、電子メールとして通信文を送信する。
【００２９】
注文管理システム１２０は、受注した注文データをチェックし、エラーがあれば担当者が修正した注文データを基幹業務システム１４０へ送信する。また、基幹業務システム１４０からの受注確認と納期を発注先のデータ形式へ逆変換して発注側システム２００へ返信する。
これを行うために、注文管理システム１２０は、注文データ、注文処理状況および納期の保管管理を行う。
【００３０】
基幹業務システム１４０は、既存の受注管理、生産管理や在庫管理等を処理するシステムであって、注文データを登録するとともに、注文データに対して在庫状況や生産状況を参照して納期を決定して、納期を注文管理システム１２０へ返信する。
【００３１】
また、担当者端末１５０は、注文データにエラーがあったときに、注文管理システム１２０からエラー通知を受信する受注受付担当者用の端末であり、また、そのエラーが起きた注文データを修正する端末でもある。
【００３２】
このような構成において、発注企業の発注担当者が購入する商品や部品等を決定して、ＰＣ等の端末（発注側システム２００）から注文データをＷｅｂサービスを利用して、ＸＭＬデータやメールの電文をｈｔｔｐやｓｍｔｐプロトコルによってネットワーク３００を介してＷｅｂサーバ１１０へ送信する。
【００３３】
注文管理システム１２０は、Ｗｅｂサーバ１１０が受信した注文データの送信先が登録されている発注企業であるかを認証し、メールやＸＭＬによる通信文を基幹業務システム１４０が保持するデータベースが扱える項目へ変換するとともに、データ入力漏れやデータミス等をチェックし、エラーがなければ変換したデータを基幹業務システム１４０へ送信する。
【００３４】
一方、注文データにエラーが見つかれば、受注受付担当者の担当者端末１５０へエラー通知を電子メールで出す。この担当者は通知された注文データのエラーを修正する。注文管理システム１２０は、修正された注文データを再度チェックする。
【００３５】
また、注文管理システム１２０は、注文データを保管するとともに、基幹業務システム１４０から送信された納期を注文データと関連付けて保存するとともに、注文データに納期を付加して注文確認データとして、Ｗｅｂサーバ１１０を介して発注側システム２００へ返信する。
【００３６】
以下、注文管理システム１２０についてより詳細に説明する。図２は、注文管理システム１２０の機能構成を示すブロック図であり、図２において、注文管理システム１２０は、認証手段１２１、認証データベース（ＤＢ）１２２、データ変換手段１２３、変換テーブル１２４、テーブル保守手段１２５、注文受付手段１２６、受付管理データベース（ＤＢ）１２７、データ修正手段１２８、納期入力手段１２９、納期通知手段１３０を少なくとも備えている。
【００３７】
認証手段１２１は、送信先のメールアドレス、または通信文中の発注先を特定するデータを抽出し、送信先がすでに認証ＤＢ１２２に登録されているかをチェックする。
認証ＤＢ１２２には、注文データを送信する前に、予め発注先を特定するデータと発注先ＩＤとを対応させて登録しておく必要がある。
また、認証手段１２１は、正常に認証が済むと、Ｗｅｂサーバ１１０の受信した注文データがＸＭＬ形式かまたは電子メール形式かを識別し、この形式の区別（ＸＭＬ形式、電子メール形式）、通信文および発注先ＩＤをデータ変換手段１２３へ渡す。
ここで、注文データが添付された電子メールの場合には、この添付された注文データを通信文としてデータ変換手段１２３へ渡す。
【００３８】
データ変換手段１２３は、認証手段１２１から渡された注文データを基幹業務システム１４０のデータベースで扱えるデータ項目へ変換テーブル１２４を参照して変換し、発注先ＩＤ、通信文、通信形式の区別および変換結果を注文受付手段１２６へ渡す。
【００３９】
まず、注文データの通信文のデータ形式について説明する。
（１）ＸＭＬ形式の場合
発注企業側の設定した図３（Ａ）に示すようなタグとそのコンテンツとから記述する。
タグには、商品コード、数量、発注先の企業名、届け先の住所、発注の担当者等があり、コンテンツにはそのタグに対応するデータ内容が記述され、これらのコンテンツはタグによって参照することができる。
【００４０】
（２）電子メール形式の場合
これには、図３（Ｂ）に示すような区切り記号（カンマ、タブ、セミコロン等）で区切られる可変長形式と、図３（Ｃ）に示すような固定長形式とがあり、どちらを用いるかは、発注先ごとに契約時に決定しておく。
また、データの記述順序とデータ項目との対応関係も契約時に決めておく。
可変長形式の場合には、区切り記号で区切られる順に順番号を付け、この順番号によって各項目の内容が参照される。例えば、図３（Ｂ）の場合には、順番号１の項目の内容は「ＡＢＣ株式会社」、順番号２の項目の内容は「１００００」、順番号３の項目の内容は「１」等である。
【００４１】
また、固定長形式の場合には、開始文字位置と終了文字位置で各項目を区切る。または、開始文字位置と項目の長さで表してもよい。
例えば、図３（Ｃ）の場合には、開始文字位置１から終了文字位置１４の項目の内容は「ＡＢＣ株式会社」、開始文字位置１６から終了文字位置２１の項目の内容は「１００００」、開始文字位置２３から終了文字位置２５の項目の内容は「１」等である。
【００４２】
次に、注文データから基幹業務システム１４０のデータベースで扱えるデータ項目へ変換する変換テーブル１２４について説明する。
図４は変換テーブル１２４のデータ構造を示す図である。同図において、変換テーブル１２４は、変換テーブルヘッダ５００、データ位置テーブル５１０、項目変換テーブル５２０、コード変換テーブル５３０とから構成される。
【００４３】
変換テーブルヘッダ５００は、発注企業ごとに次の項目を保持する。
（１）発注先ＩＤ
（２）注文データの形式の区別（ＸＭＬ形式、電子メール形式等）
（３）上記の区別が電子メール形式であり、注文データを可変長形式で表現しているときの区切り記号
ＸＭＬ形式の時には、この項目はＮＵＬＬである。
（４）上記の区別が電子メール形式であり、注文データを固定長形式で表現しているときの項目の位置を表すデータ位置テーブル５１０へのポインタ
ＸＭＬ形式および可変長形式の時には、この項目はＮＵＬＬである。
（５）項目変換テーブル５２０へのポインタ
（６）コード変換テーブル５３０へのポインタ
【００４４】
更に、データ位置テーブル５１０は、注文データが固定長形式の通信文として記述されているときに、各項目を識別するために、図５（Ａ）に示すような、項目順に開始文字位置と終了文字位置とを並べたデータ構造となっている。
例えば、図５において、順番号が１番の項目は開始文字位置が１であり、終了文字位置が１４である、１４桁の文字列からなることを示している。同様に、順番号が７番の項目は開始文字位置が７５であり、終了文字位置が８８である、１４桁の文字列からなることを示している。
また、データ位置テーブル５１０が、開始文字位置と項目の長さからなっている場合には、図５（Ｂ）に示すようなデータ構造となっている。
【００４５】
項目変換テーブル５２０は、注文データの項目と基幹業務システム１４０のデータベースで扱える形式に変換するための変換テーブルであり、図６に示すようなデータ構造をしている。
その構造は、注文データ上の項目の組み合わせからなる「データ位置情報」と基幹業務システムのデータベース上の項目とを対応付けた表である。
（１）ＸＭＬ形式の場合（図６（Ａ）参照）
注文データ上の項目はタグで示され、基幹業務システムのデータベース上の項目と対応付けられる。
（２）電子メール形式の場合（図６（Ｂ）参照）
注文データ上の項目は通信文中の項目の並びを示す順番号で示され、基幹業務システムのデータベース上の項目と対応付けられる。
または、固定長形式の場合、注文データ上の項目を上述のような順番号ではなく、開始文字位置と終了文字位置、または開始文字位置と項目の長さを使って、直接表現してもよい。例えば、（開始文字位置，終了文字位置）または（開始文字位置，項目の長さ）という２つの組みで通信文上の各項目のデータ位置を表現し、データ位置テーブル５１０のデータ位置情報を
（２７，４４）＋（７５，８８）＋（６０，３０）＋“様”
または
（２７，１８）＋（７５，１４）＋（６０，１４）＋“様”
とし、これを基幹システムのデータベースの項目「住所」へ対応付けるようにしてもよい。
【００４６】
更に、基幹業務システムのデータベース上の１項目に対して、注文データ上の１つ以上の項目および固定的な文字または数字等を組み合わせてもよい。
例えば、基幹業務システムのデータベース上の項目「住所」は、注文データ上の項目「住所１」および「住所２」を連結し、届け先の「購買担当者」の名前を連結し、固定的な文字「様」を追加して構成する。
【００４７】
発注側の企業としては、注文するときに自企業で使用しているコード体系が使えると便利である。しかし、受注する側の基幹業務システム１４０で処理しているコード体系と必ずしも一致していない。
この場合には、発注企業と受注企業が取引を契約したときに、図７に示すような発注側のコード体系と受注側のコード体系との対応表をコード変換テーブル５３０として作成する。このコード体系は、コードを表す項目名（電子メール形式の場合には、順番号）とその項目の中に含まれるコードとを対比したものである。
例えば、届け先のコードが発注企業では「１００」であり、受注企業側では「２４１０１−００」であれば、これらを対応させてコード変換テーブル５３０へ登録しておく。
【００４８】
図８のフローチャートを用いて、データ変換手段１２３の処理手順を説明する。
認証手段１２１から発注先ＩＤ、通信文、通信形式の区別を受け取る（ステップＳ１）。
通信形式の区別がＸＭＬ形式である場合は（ステップＳ２の「ＸＭＬ」）、通信文の中のタグとそのデータの内容とを抽出して、タグと内容との対応表（Ｔ１）を作成する（ステップＳ３）。
【００４９】
変換テーブルヘッダ５００の発注先ＩＤに該当する項目変換テーブルへのポインタおよびコード変換テーブルへのポインタを参照して、項目変換テーブル５２０とコード変換テーブル５３０（存在するときのみ）を取り出す（ステップＳ４）。
項目変換テーブル５２０中の基幹業務システムのデータベースの項目に対応する「データ位置情報」を取り出す。この「データ位置情報」に含まれるタグおよび固定情報との組み合わせのうち、タグを上記の対応表（Ｔ１）に格納されているタグの内容で置換して、基幹業務システムのデータベースの項目と対応付けた対応表（Ｔ２）を作成する（ステップＳ５）。
このとき、タグとその内容に対応する発注先のコードがあれば、コード変換テーブル５３０を参照して受注先のコードに置き換える。
【００５０】
一方、ステップＳ２で通信の形式が「電子メール」の場合、変換テーブルヘッダ５００の発注先ＩＤに対して「区切り」が存在するかを調べる（ステップＳ６）。
「区切り」が存在しない場合は、データ位置テーブルのポインタを参照して、データ位置テーブル５１０を取り出す。このデータ位置テーブル５１０の開始文字位置と終了文字位置（または項目の長さ）とから、通信文から順次内容を取り出して、順番号と内容との対応表（Ｋ１）作成する（ステップＳ７）。
他方、「区切り」が存在する場合には、区切り記号によって通信文から順次内容を取り出して、順番号と内容との対応表（Ｋ１）作成する（ステップＳ８）。
【００５１】
次に、変換テーブルヘッダ５００の発注先ＩＤに該当する項目変換テーブルへのポインタおよびコード変換テーブルへのポインタを参照して、項目変換テーブル５２０とコード変換テーブル５３０（存在するときのみ）を取り出す（ステップＳ９）。
項目変換テーブル５２０中の基幹業務システムのデータベースの項目に対応する「データ位置情報」を取り出す。このデータ位置情報に含まれる順番号および固定情報との組み合わせのうち、順番号を上記の対応表（Ｋ１）に格納されているデータの内容で置換して、基幹業務システムのデータベースの項目と対応付けた対応表（Ｔ２）を作成する（ステップＳ１０）。
このとき、順番号とその内容に対応する発注先のコードがあれば、コード変換テーブル５３０を参照して受注先のコードに置き換える。
【００５２】
テーブル保守手段１２５は、注文管理システム１２０の管理者が新規発注企業を追加したとき、また契約を打ち切ったとき、あるいは注文データの書式やコード体系が変更になったときに、必要に応じて変換テーブル１２４（変換テーブルヘッダ５００、データ位置テーブル５１０、項目変換テーブル５２０、コード変換テーブル５３０）の登録、削除または更新を行う。
【００５３】
注文受付手段１２６は、データ変換手段１２３から渡された発注先ＩＤ、通信文、通信形式の区別、変換結果（上記の対応表Ｔ２）を受け取り、受付管理データベース（ＤＢ）１２７へ受注受付番号を採番して仮登録を行い、同時に変換結果の形式チェックを行う。この受付管理ＤＢ１２７では、受注受付番号ごとに次のようなデータ項目を保管管理する。
（１）注文データを受信した日時（受信日時）
（２）注文データの処理状況（受注状況）
（３）エラー詳細、修正状況
（４）基幹業務システムから通知された注文の納入日時（納期）
（５）発注先ＩＤ
（６）注文データとして送られてきた通信文（原文）
（７）通信文を変換したデータ（上記の対応表Ｔ２）
【００５４】
注文データを受信した注文受付手段１２６は、次のことを実行する。
まず、受注受付番号を採番し、それをキーとして、受信日時、発注先ＩＤ、通信文、変換されたデータおよび受注状況として「ＯＥ送信待ち」をそれぞれ受付管理ＤＢ１２７へ登録する。
次に、例えば、変換された各データ項目に対して次のようなチェックをする。
・必要なデータが指定されていない（入力漏れ）
・データ変換時のエラー（対応コードなし）
・発注先と変換データ中の客先コードが不一致
・数値データ中に文字データが存在する
・数値が大きすぎる等
【００５５】
チェックの結果エラーがあれば、受注受付担当者の担当者端末１５０へエラーが検出されたことを電子メールで通知するとともに、受注状況として「ＯＥ送信エラー」、エラー詳細として上記したようなエラーの理由、修正状況として「未処理」を、受付管理ＤＢ１２７の当該受注受付番号に対応して登録する。
また、受注受付担当者へは、例えば、次のような通信文が送信される。
【００５６】
通信タイトルとしては、
「Ｏ／Ｅデータ送信処理」
通信文としては、
「受注受付番号＝ＸＸＸＸＸＸ
（どの項目に対して、どのようなエラーが起きたかを説明した文）
受注データ一覧画面で確認してください。」
【００５７】
変換データをチェックしてエラーが見つからなければ、受注状況を「基幹業務システムへの送信待ち」、エラー詳細を「ＯＥ受信正常」として、受付管理ＤＢ１２７の当該受注受付番号に対応して更新し、基幹業務システム１４０への送信キューに登録する。この送信が完了すると受注状況は「納期入力待ち」に更新される。
【００５８】
また、注文受付手段１２６は、受付管理ＤＢ１２７のエラー修正が完了した受注受付番号を監視する。これは受注状況が「ＯＥ送信待ち」でエラーの処理状況「エラー有り」のものを探すことによって、監視できる。
注文受付手段１２６は、エラーの修正が完了したものが見つかった場合、再度、上述したようなエラーチェックを行う。
【００５９】
受注受付担当者は、上述したようなエラー通知の電子メールを受け取ると、担当者端末１５０を操作してデータ修正手段１２８を起動させ、エラーを修正する。
データ修正手段１２８は、まず、図９のような受注データ一覧画面を表示する。
受注受付担当者は、表示された一覧から受信日時や未処理データ等を指定して検索することによって、絞り込んだ一覧表示から修正すべき受注受付番号を見つける。
【００６０】
更に、見つけた受注受付番号の欄をマウスでクリックすると、データ修正手段１２８は、図１０のような明細画面を表示する。この図中、テキストボックスとして表示されているところが修正可能な項目である。
受注受付担当者は、エラー通知のエラー詳細に書かれていた項目を修正して、画面右上の「更新」をクリックする。
データ修正手段１２８は、受付管理ＤＢ１２７の修正された項目を更新し、エラーの修正状況を「ＯＥ送信待ち」に更新する。
【００６１】
納期入力手段１２９は、基幹業務システム１４０から注文データが受け付けられ、その納期が送信されてくると、該当受注受付番号の納期および受注状況を「お客様への結果送信待ち」として受付管理ＤＢ１２７を更新する。
【００６２】
納期通知手段１３０は、受付管理ＤＢ１２７の受注状況が「お客様への結果送信待ち」となっている受注受付番号を監視する。
納期通知手段１３０は、「お客様への結果送信待ち」の受注受付番号を見つけると、受付管理ＤＢ１２７から注文データの原文および納期とを、受信した時の通信形式へ逆変換して発注先へ返信する。このとき、受注受付担当者が修正したデータがあれば、発注先の通信形式へ逆変換して通信文に付加して送信する。
この逆変換は、データ変換テーブル１２４を用いてデータ変換手段１２３で行う。
【００６３】
上述した受付管理ＤＢ１２７では、注文データの原文を保存するようにしたが、原文を保存しないようにして受付管理ＤＢ１２７のデータ容量を減らすことができる。この場合、発注先への受注確認の送信に使われる注文データは、変換されていたデータを逆変換することによって発注先のデータ形式へ戻す。
【００６４】
本発明は、上述した実施形態のみに限定されたものではない。上述した実施形態の受発注システムを構成する各機能をそれぞれプログラム化し、あらかじめＣＤ−ＲＯＭ等の記録媒体に書き込んでおき、コンピュータに搭載したＣＤ−ＲＯＭドライブのような媒体駆動装置にこのＣＤ−ＲＯＭ等を装着して、これらのプログラムをコンピュータのメモリあるいは記憶装置に格納し、それを実行することによって、本発明の目的が達成されることは言うまでもない。
この場合、記録媒体から読み出されたプログラム自体が上述した実施形態の機能を実現することになり、そのプログラムおよびそのプログラムを記録した記録媒体も本発明を構成することになる。
【００６５】
なお、プログラムを格納する記録媒体としては半導体媒体（例えば、ＲＯＭ、不揮発性メモリ等）、光媒体（例えば、ＤＶＤ、ＭＯ、ＭＤ、ＣＤ等）、磁気媒体（例えば、磁気テープ、フレキシブルディスク等）等のいずれであってもよい。
【００６６】
また、ロードしたプログラムを実行することにより上述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、オペレーティングシステムあるいは他のアプリケーションプログラム等と共同して処理することによって上述した実施形態の機能が実現される場合も含まれる。
【００６７】
市場に流通させる場合には、可搬型の記録媒体にプログラムを格納して流通させたり、インターネット等の通信網を介して接続されたサーバコンピュータの記憶装置に格納しておき、通信網を通じて他のコンピュータに転送することもできる。この場合、このサーバコンピュータの記憶装置も本発明の記録媒体に含まれる。なお、コンピュータでは、可搬型の記録媒体上のプログラム、または転送されてくるプログラムを、コンピュータに接続された記憶装置にインストールし、そのインストールされたプログラムを実行することによって上述した実施形態の機能が実現される。
【００６８】
【発明の効果】
以上説明したように本発明によれば、受注側の企業が、発注企業ごとに異なる注文データの形式を受注側の基幹業務システムが必要とする形式へ変換テーブルで変換するようにしたので、新たに発注企業が増えてもシステム化投資が短期間・低コストで対応することができる。
この変換においては、データ項目の１対１の変換だけでなく、複数の項目を組み合わせて１つの項目に対応付けることができるので、より柔軟な変換が行える。
また、発注側の企業で利用しているコード体系や文字列を受注側のコード体系に変換できるようにしたことにより、さらに発注側の入力負荷が低減される。
【００６９】
また、発注側の注文データに不備がある場合に、受注受付担当者が修正を行えるようにしたので、不備データについて受信データを活用して修正でき、受注入力の負荷が低減できる。
更に、受注側では注文データに対する納期情報を自動的に発注側へ送信するので、納期回答業務の負荷が低減できる。
一方、発注側の発注担当者としては、注文データに対する修正や納期情報の送信を受注側が行ってくれるので、修正や納期情報の確認作業がなくなり、業務の負荷が低減できる。
【図面の簡単な説明】
【図１】実施形態に係る受発注システムの構成を示すブロック図である。
【図２】実施形態に係る注文管理システムの機能構成を示すブロック図である。
【図３】注文データの通信文を示す例である。
【図４】変換テーブルのデータ構造を示す図である。
【図５】データ位置テーブルの例である。
【図６】項目変換テーブルの例である。
【図７】コード変換テーブルの例である。
【図８】データ変換手段の処理手順を示すフローチャートである。
【図９】受注データ一覧画面の例である。
【図１０】受注データの詳細表示画面の例である。
【符号の説明】
１００…受注側システム、１１０…Ｗｅｂサーバ、１２０…注文管理システム、１２１…認証手段、１２２…認証ＤＢ、１２３…データ変換手段、１２４…変換テーブル、１２５…テーブル保守手段、１２６…注文受付手段、１２７…受付管理ＤＢ、１２８…データ修正手段、１２９…納期入力手段、１３０…納期通知手段、１４０…基幹業務システム、１５０…担当者端末、１６０…ネットワーク、２００…発注側システム、３００…ネットワーク、５００…変換テーブルヘッダ、５１０…データ位置テーブル、５２０…項目変換テーブル、５３０…コード変換テーブル。
【図１】
2004178190.tif 000003
【図２】
2004178190.tif 000004
【図３】
2004178190.tif 000005
【図４】
2004178190.tif 000006
【図５】
2004178190.tif 000007
【図６】
2004178190.tif 000008
【図７】
2004178190.tif 000009
【図８】
2004178190.tif 000010
【図９】
2004178190.tif 000011
【図１０】
2004178190.tif 000012