JP2004178190A - 受発注システム、プログラムおよび記録媒体 - Google Patents
受発注システム、プログラムおよび記録媒体 Download PDFInfo
- Publication number
- JP2004178190A JP2004178190A JP2002342446A JP2002342446A JP2004178190A JP 2004178190 A JP2004178190 A JP 2004178190A JP 2002342446 A JP2002342446 A JP 2002342446A JP 2002342446 A JP2002342446 A JP 2002342446A JP 2004178190 A JP2004178190 A JP 2004178190A
- Authority
- JP
- Japan
- Prior art keywords
- order
- data
- ordering
- order receiving
- receiving
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
【課題】注文形式が異なる発注企業に対しても、新たなシステム化投資をすることなく対応できる受発注システムを提供する。
【解決手段】この受発注システムは、複数の企業からなる発注先から注文データを受信し、その注文データのデータ形式を受注側が処理しうるデータ形式に変換テーブル124で変換し、その変換された注文データによって電子商取引を行うものであって、変換テーブル124を発注先ごとに用意し、変換テーブル124には、受注側の1つのデータ項目に対して発注先の1つ以上のデータ項目を組み合わせて定義しておき、発注先から注文データを受信した場合、変換テーブル124で受注側の受発注システムで処理し得るデータの形式に変換してから受注処理を行うようにした。
【選択図】 図2
【解決手段】この受発注システムは、複数の企業からなる発注先から注文データを受信し、その注文データのデータ形式を受注側が処理しうるデータ形式に変換テーブル124で変換し、その変換された注文データによって電子商取引を行うものであって、変換テーブル124を発注先ごとに用意し、変換テーブル124には、受注側の1つのデータ項目に対して発注先の1つ以上のデータ項目を組み合わせて定義しておき、発注先から注文データを受信した場合、変換テーブル124で受注側の受発注システムで処理し得るデータの形式に変換してから受注処理を行うようにした。
【選択図】 図2
Description
【0001】
【発明の属する技術分野】
本発明は、受発注システム、プログラムおよび記録媒体に関し、具体的には、企業間で電子データ交換によって商取引を行うときに、発注企業から送られてきたデータを受注企業における受発注システムで処理できるデータとして変換する技術に関する。
【0002】
【従来の技術】
従来からEDI(Electronic Data Interchange:電子データ交換)を使って、基幹業務(生産計画、在庫管理、購買等)において、特定企業間でのデータ交換を効率化してきた。このため商取引で使用する紙ベースの各種帳票を電子データ化し、システム間でのデータ交換を標準化した。
この標準化されたEDIは、専用回線やVAN(付加価値情報ネットワーク)のような閉じたネットワーク上で特定企業間のデータ交換に利用されている。
【0003】
しかし、専用回線やVANを使うEDIでは、導入コストおよび運用コストが高いため、導入できるのは大企業に限られていた。
このため、インターネットが普及するにつれて、専用回線やVANの代わりにインターネットを使うWeb−EDIが使われるようになった。
【0004】
このWeb−EDIでは、Webブラウザを通じてインターネット上で取引できるため、低コストの導入・維持ができるので、従来はEDIを導入しにくかった中小の取引先や取引頻度の少ない取引先を情報の共有化のメンバーとして取り込めるようになり、新規の取引先においても最初から電子商取引を行うことができるようになった。
【0005】
また、異なる企業の基幹業務システム間でデータ交換を行うためには、データ記述を共通化しなければならなくなった。このため、XML(eXtensible Markup Language)でデータを記述することによって、特定の企業やシステム環境に依存しないEDI(これをXML−EDIと呼んでいる)を実現できるようになっている。
【0006】
【特許文献1】
特開平05−61745号公報
【特許文献2】
特開2002−99754号公報
【特許文献3】
特開2001−325537号公報
【0007】
【発明が解決しようとする課題】
しかしながら、多数の発注企業から受注する受注企業の場合、発注企業ごとに電子データ交換の仕様(注文フォーマットやデータコード等)が異なっているため、受信したデータを自社の基幹業務システムで処理するために、個別にシステム化対応を実施する必要があり、システム化投資もその都度発生していた。
【0008】
上述した注文フォーマットが異なる場合を解決するため、特許文献1の「フォーマットの変換装置」は、受発注システムで使われるフォーマットに対して、予め変換前後のフォーマットの定義に基づいて変換テーブルを作成しておき、入力されたデータを判別して変換テーブルを選択してフォーマットの変換を行うようにした。この変換に際して、1対1に変換が取れないものや特別に変換を伴う場合には、変換に先立って例外処理を施した後に変換テーブルを使ってフォーマット変換を行う。これにより、ユーザのフォーマット変更要求に対し柔軟に対応することができる。
【0009】
しかし、この特許文献1による方法では、変換前後のフォーマット上の項目が1対1に対応しない場合には、特別な処理を行う必要があるため、相変わらず個別にシステム化対応をしなければならない。
【0010】
また、一旦発注企業から送られてきた電子データにエラーが含まれていることが分かった場合には、従来では、発注企業に連絡または発注企業側でエラー状況を監視する等をしてもう一度データを作成して、送り直してもらっていた。例えば、特許文献2の「受注システム」では、インターネット上にサーバをホストに繋いだシステムを構築しておき、発注先は、インターネット経由でサーバにアクセスして発注情報を入力する。
サーバでは、入力された発注情報をチェックし、サーバ内のファイルに仮受付けオーダとして格納するとともに、このオーダを定期的にホストに送信する。
【0011】
ホストは、これを正式オーダとして登録し、チェックおよび在庫引当を経てホスト内のファイルに格納し、このオーダのデータを定期的にサーバのファイルに送信する。
他方、ホストが正式オーダとし得ない仮受付けオーダは、エラーデータとしてホスト内のファイルに格納し、定期的にサーバのファイルに送信する。
サーバは、ホストから受信した正式オーダとしての登録オーダまたはエラーデータを、得意先に電子メールにて送信したり、得意先がインターネット経由でサーバにアクセスして受注オーダの状況を確認することができるようにした。
【0012】
一方、企業間の注文では、発注側へ返信することなく、受注側で対処することが一般的であるが、この特許文献2の発明ではエラーとなった注文データは発注側へ送り返されるので、修正して送り返さなければならなくなる。
【0013】
また、発注企業で使われているコード体系と受注企業で使われているコード体系では一致していないのが一般的である。
これらのエラー修正や発注企業で使われているコード体系をそのまま使えるようにできれば顧客満足を得るものとなる。
【0014】
また、特許文献3の「インターネットを介する受発注システム」では、統一注文フォーマットを定めて、それを発注企業が使って注文書を作成し、この注文書をインターネット上に設けた仲介装置へ送って受注企業の業種フォーマットに変換して受注企業に送るようにした。
【0015】
しかしながら、会員として登録した企業全てに共通した統一注文フォーマットを作成したり、様々なコード体系に対応するために、仲介装置を維持管理することは難しい。
【0016】
本発明は、上述した実情を考慮してなされたもので、注文書式が異なる発注企業に対しても、新たなシステム化投資をすることなく対応できる受発注システム、受発注システムの機能を実行するためのプログラムおよびそのプログラムを記録したコンピュータ読み取り可能な記録媒体を提供することを目的とする。
【0017】
【課題を解決するための手段】
上記課題を解決するために、本発明の請求項1は、複数の企業からなる発注先から注文データを受信し、その注文データのデータ形式を受注側が処理しうるデータ形式に変換テーブルで変換し、その変換された注文データによって電子商取引を行う受発注システムにおいて、前記変換テーブルを発注先ごとに用意し、前記変換テーブルには、前記受注側の1つのデータ項目に対して前記発注先の1つ以上のデータ項目を組み合わせて定義しておき、前記発注先から注文データを受信した場合、前記変換テーブルで受注側の受発注システムで処理し得るデータの形式に変換してから受注処理を行うことを特徴とする。
【0018】
また、本発明の請求項2は、請求項1に記載の受発注システムにおいて、前記注文データを変換するときに、その注文データ中に発注先の使用するコード体系のコードがあるときに、そのコードを受注側で使用するコード体系のコードへ変換するようにしたことを特徴とする。
また、本発明の請求項3は、請求項1または2に記載の受発注システムにおいて、前記発注先からの注文データの送信をWebサービスあるいは電子メールで行うようにしたことを特徴とする。
また、本発明の請求項4は、請求項1、2または3に記載の受発注システムにおいて、前記変換されたデータをチェックし、エラーがあった場合には、受注受付担当者へ通知することを特徴とする。
また、本発明の請求項5は、請求項4に記載の受発注システムにおいて、エラーの通知を受けた前記受注受付担当者から該エラーのみを入力させて注文データを修正することを特徴とする。
【0019】
また、本発明の請求項6は、請求項5に記載の受発注システムにおいて、エラーが修正されるのを監視し、修正された注文データを再度チェックするようにしたことを特徴とする。
また、本発明の請求項7は、請求項1乃至6のいずれかに記載の受発注システムにおいて、前記受注処理した結果の納期データを当該注文データに付して、受注確認情報として返信することを特徴とする。
また、本発明の請求項8は、請求項7に記載の受発注システムにおいて、発注先への受注確認の返信は、発注先が注文データを送信してきたときの送信形式と同じ形式とすることを特徴とする。
【0020】
また、本発明の請求項9は、複数の企業からなる発注先から送信された注文データによって受注側と電子商取引を行う受発注システムにおいて、前記発注先ごとに、受注側の1つのデータ項目に対して発注先の1つ以上のデータ項目を組み合わせて定義した変換テーブルと、前記変換テーブルを用いて、前記発注先から受信した注文データを前記受注側の受発注システムで処理し得るデータの形式に変換するデータ変換手段とを備えることを特徴とする。
【0021】
また、本発明の請求項10のプログラムは、コンピュータに、請求項1乃至9のいずれかに記載の受発注システムの機能を実行させるためのプログラムである。
また、本発明の請求項11の記録媒体は、請求項10に記載の受発注システムのプログラムを記録したコンピュータ読み取り可能な記録媒体である。
【0022】
以上の構成により、受注側の企業が、発注企業ごとに異なる注文データの形式を受注側の基幹業務システムが必要とする形式へ変換テーブルで変換するようにしたので、新たに発注企業が増えてもシステム化投資が短期間・低コストで対応することができる。
この変換においては、データ項目の1対1の変換だけでなく、複数の項目を組み合わせて1つの項目に対応付けることができるので、より柔軟な変換が行える。
また、発注側の企業で利用しているコード体系や文字列を受注側のコード体系に変換できるようにしたことにより、さらに発注側の入力負荷が低減される。
【0023】
また、発注側の注文データに不備がある場合に、受注受付担当者が修正を行えるようにしたので、不備データについて受信データを活用して修正でき、受注入力の負荷が低減できる。
更に、受注側では注文データに対する納期情報を自動的に発注側へ送信するので、納期回答業務の負荷が低減できる。
一方、発注側の発注担当者としては、注文データに対する修正や納期情報の送信を受注側が行ってくれるので、修正や納期情報の確認作業がなくなり、業務の負荷が低減できる。
【0024】
【発明の実施の形態】
以下、図面を参照して、本発明の受発注システムに係る好適な実施形態を説明する。
図1は、本実施形態の受発注システムの構成を示すブロック図である。
図1において、受発注システムは、複数の発注企業が所有する発注側システム200と、受注管理を行う受注企業が所有する受注側システム100とをネットワーク300で接続している。ここで1つの発注企業で複数の発注側システムを所有してもよいが、本実施形態の説明では、1つの発注企業で1つの発注側システムを所有するとして説明する。また、企業ではなく、個人や中小企業や小規模な商店であっても同様に利用することができる。
【0025】
ネットワーク300は、専用回線網や公衆回線網を利用して、LAN(Local Area Network)、WAN(Wide Area Network)またはインターネットのいずれであってもよく、このネットワークを介して発注側システムと受注側システムとはhttpプロトコルやsmtpプロトコル等の通信プロトコルによってデータをやり取りする。
【0026】
発注側システム200としては、発注側の受発注管理を行うコンピュータや単に注文データのみを送信するパーソナルコンピュータ(ノート型、デスクトップ型等)、PDA(Personal Digital Assistant)や携帯電話等のいずれであってもよい。
【0027】
更に、受注側システム100は、Webサーバ110、注文管理システム120、基幹業務システム140、1台以上の担当者端末150とをネットワーク160で接続し、セキュリティ確保のためファイアウォールを介在させている。
ネットワーク160は、受注企業内に設置されたWebサーバ110、注文管理システム120、基幹業務システム140、1台以上の担当者端末150とを接続するWANまたはLANである。
【0028】
Webサーバ110は、ネットワーク300を介して発注側システム200から注文データを受信し、ネットワーク160を介してこのデータを注文管理システム120へ送信する。
また、Webサーバ110は、ネットワーク160を介して注文管理システム120から処理された受注確認・納期データを受信し、注文データを受信したときと同じ通信プロトコルによってネットワーク300を介して発注側システム200へ返信する。
通信プロトコルがhttpプロトコルの場合には、通信文をXML伝送プロトコルによって送信し、smtpプロトコルの場合には、電子メールとして通信文を送信する。
【0029】
注文管理システム120は、受注した注文データをチェックし、エラーがあれば担当者が修正した注文データを基幹業務システム140へ送信する。また、基幹業務システム140からの受注確認と納期を発注先のデータ形式へ逆変換して発注側システム200へ返信する。
これを行うために、注文管理システム120は、注文データ、注文処理状況および納期の保管管理を行う。
【0030】
基幹業務システム140は、既存の受注管理、生産管理や在庫管理等を処理するシステムであって、注文データを登録するとともに、注文データに対して在庫状況や生産状況を参照して納期を決定して、納期を注文管理システム120へ返信する。
【0031】
また、担当者端末150は、注文データにエラーがあったときに、注文管理システム120からエラー通知を受信する受注受付担当者用の端末であり、また、そのエラーが起きた注文データを修正する端末でもある。
【0032】
このような構成において、発注企業の発注担当者が購入する商品や部品等を決定して、PC等の端末(発注側システム200)から注文データをWebサービスを利用して、XMLデータやメールの電文をhttpやsmtpプロトコルによってネットワーク300を介してWebサーバ110へ送信する。
【0033】
注文管理システム120は、Webサーバ110が受信した注文データの送信先が登録されている発注企業であるかを認証し、メールやXMLによる通信文を基幹業務システム140が保持するデータベースが扱える項目へ変換するとともに、データ入力漏れやデータミス等をチェックし、エラーがなければ変換したデータを基幹業務システム140へ送信する。
【0034】
一方、注文データにエラーが見つかれば、受注受付担当者の担当者端末150へエラー通知を電子メールで出す。この担当者は通知された注文データのエラーを修正する。注文管理システム120は、修正された注文データを再度チェックする。
【0035】
また、注文管理システム120は、注文データを保管するとともに、基幹業務システム140から送信された納期を注文データと関連付けて保存するとともに、注文データに納期を付加して注文確認データとして、Webサーバ110を介して発注側システム200へ返信する。
【0036】
以下、注文管理システム120についてより詳細に説明する。図2は、注文管理システム120の機能構成を示すブロック図であり、図2において、注文管理システム120は、認証手段121、認証データベース(DB)122、データ変換手段123、変換テーブル124、テーブル保守手段125、注文受付手段126、受付管理データベース(DB)127、データ修正手段128、納期入力手段129、納期通知手段130を少なくとも備えている。
【0037】
認証手段121は、送信先のメールアドレス、または通信文中の発注先を特定するデータを抽出し、送信先がすでに認証DB122に登録されているかをチェックする。
認証DB122には、注文データを送信する前に、予め発注先を特定するデータと発注先IDとを対応させて登録しておく必要がある。
また、認証手段121は、正常に認証が済むと、Webサーバ110の受信した注文データがXML形式かまたは電子メール形式かを識別し、この形式の区別(XML形式、電子メール形式)、通信文および発注先IDをデータ変換手段123へ渡す。
ここで、注文データが添付された電子メールの場合には、この添付された注文データを通信文としてデータ変換手段123へ渡す。
【0038】
データ変換手段123は、認証手段121から渡された注文データを基幹業務システム140のデータベースで扱えるデータ項目へ変換テーブル124を参照して変換し、発注先ID、通信文、通信形式の区別および変換結果を注文受付手段126へ渡す。
【0039】
まず、注文データの通信文のデータ形式について説明する。
(1)XML形式の場合
発注企業側の設定した図3(A)に示すようなタグとそのコンテンツとから記述する。
タグには、商品コード、数量、発注先の企業名、届け先の住所、発注の担当者等があり、コンテンツにはそのタグに対応するデータ内容が記述され、これらのコンテンツはタグによって参照することができる。
【0040】
(2)電子メール形式の場合
これには、図3(B)に示すような区切り記号(カンマ、タブ、セミコロン等)で区切られる可変長形式と、図3(C)に示すような固定長形式とがあり、どちらを用いるかは、発注先ごとに契約時に決定しておく。
また、データの記述順序とデータ項目との対応関係も契約時に決めておく。
可変長形式の場合には、区切り記号で区切られる順に順番号を付け、この順番号によって各項目の内容が参照される。例えば、図3(B)の場合には、順番号1の項目の内容は「ABC株式会社」、順番号2の項目の内容は「10000」、順番号3の項目の内容は「1」等である。
【0041】
また、固定長形式の場合には、開始文字位置と終了文字位置で各項目を区切る。または、開始文字位置と項目の長さで表してもよい。
例えば、図3(C)の場合には、開始文字位置1から終了文字位置14の項目の内容は「ABC株式会社」、開始文字位置16から終了文字位置21の項目の内容は「10000」、開始文字位置23から終了文字位置25の項目の内容は「1」等である。
【0042】
次に、注文データから基幹業務システム140のデータベースで扱えるデータ項目へ変換する変換テーブル124について説明する。
図4は変換テーブル124のデータ構造を示す図である。同図において、変換テーブル124は、変換テーブルヘッダ500、データ位置テーブル510、項目変換テーブル520、コード変換テーブル530とから構成される。
【0043】
変換テーブルヘッダ500は、発注企業ごとに次の項目を保持する。
(1)発注先ID
(2)注文データの形式の区別(XML形式、電子メール形式等)
(3)上記の区別が電子メール形式であり、注文データを可変長形式で表現しているときの区切り記号
XML形式の時には、この項目はNULLである。
(4)上記の区別が電子メール形式であり、注文データを固定長形式で表現しているときの項目の位置を表すデータ位置テーブル510へのポインタ
XML形式および可変長形式の時には、この項目はNULLである。
(5)項目変換テーブル520へのポインタ
(6)コード変換テーブル530へのポインタ
【0044】
更に、データ位置テーブル510は、注文データが固定長形式の通信文として記述されているときに、各項目を識別するために、図5(A)に示すような、項目順に開始文字位置と終了文字位置とを並べたデータ構造となっている。
例えば、図5において、順番号が1番の項目は開始文字位置が1であり、終了文字位置が14である、14桁の文字列からなることを示している。同様に、順番号が7番の項目は開始文字位置が75であり、終了文字位置が88である、14桁の文字列からなることを示している。
また、データ位置テーブル510が、開始文字位置と項目の長さからなっている場合には、図5(B)に示すようなデータ構造となっている。
【0045】
項目変換テーブル520は、注文データの項目と基幹業務システム140のデータベースで扱える形式に変換するための変換テーブルであり、図6に示すようなデータ構造をしている。
その構造は、注文データ上の項目の組み合わせからなる「データ位置情報」と基幹業務システムのデータベース上の項目とを対応付けた表である。
(1)XML形式の場合(図6(A)参照)
注文データ上の項目はタグで示され、基幹業務システムのデータベース上の項目と対応付けられる。
(2)電子メール形式の場合(図6(B)参照)
注文データ上の項目は通信文中の項目の並びを示す順番号で示され、基幹業務システムのデータベース上の項目と対応付けられる。
または、固定長形式の場合、注文データ上の項目を上述のような順番号ではなく、開始文字位置と終了文字位置、または開始文字位置と項目の長さを使って、直接表現してもよい。例えば、(開始文字位置,終了文字位置)または(開始文字位置,項目の長さ)という2つの組みで通信文上の各項目のデータ位置を表現し、データ位置テーブル510のデータ位置情報を
(27,44)+(75,88)+(60,30)+“様”
または
(27,18)+(75,14)+(60,14)+“様”
とし、これを基幹システムのデータベースの項目「住所」へ対応付けるようにしてもよい。
【0046】
更に、基幹業務システムのデータベース上の1項目に対して、注文データ上の1つ以上の項目および固定的な文字または数字等を組み合わせてもよい。
例えば、基幹業務システムのデータベース上の項目「住所」は、注文データ上の項目「住所1」および「住所2」を連結し、届け先の「購買担当者」の名前を連結し、固定的な文字「様」を追加して構成する。
【0047】
発注側の企業としては、注文するときに自企業で使用しているコード体系が使えると便利である。しかし、受注する側の基幹業務システム140で処理しているコード体系と必ずしも一致していない。
この場合には、発注企業と受注企業が取引を契約したときに、図7に示すような発注側のコード体系と受注側のコード体系との対応表をコード変換テーブル530として作成する。このコード体系は、コードを表す項目名(電子メール形式の場合には、順番号)とその項目の中に含まれるコードとを対比したものである。
例えば、届け先のコードが発注企業では「100」であり、受注企業側では「24101−00」であれば、これらを対応させてコード変換テーブル530へ登録しておく。
【0048】
図8のフローチャートを用いて、データ変換手段123の処理手順を説明する。
認証手段121から発注先ID、通信文、通信形式の区別を受け取る(ステップS1)。
通信形式の区別がXML形式である場合は(ステップS2の「XML」)、通信文の中のタグとそのデータの内容とを抽出して、タグと内容との対応表(T1)を作成する(ステップS3)。
【0049】
変換テーブルヘッダ500の発注先IDに該当する項目変換テーブルへのポインタおよびコード変換テーブルへのポインタを参照して、項目変換テーブル520とコード変換テーブル530(存在するときのみ)を取り出す(ステップS4)。
項目変換テーブル520中の基幹業務システムのデータベースの項目に対応する「データ位置情報」を取り出す。この「データ位置情報」に含まれるタグおよび固定情報との組み合わせのうち、タグを上記の対応表(T1)に格納されているタグの内容で置換して、基幹業務システムのデータベースの項目と対応付けた対応表(T2)を作成する(ステップS5)。
このとき、タグとその内容に対応する発注先のコードがあれば、コード変換テーブル530を参照して受注先のコードに置き換える。
【0050】
一方、ステップS2で通信の形式が「電子メール」の場合、変換テーブルヘッダ500の発注先IDに対して「区切り」が存在するかを調べる(ステップS6)。
「区切り」が存在しない場合は、データ位置テーブルのポインタを参照して、データ位置テーブル510を取り出す。このデータ位置テーブル510の開始文字位置と終了文字位置(または項目の長さ)とから、通信文から順次内容を取り出して、順番号と内容との対応表(K1)作成する(ステップS7)。
他方、「区切り」が存在する場合には、区切り記号によって通信文から順次内容を取り出して、順番号と内容との対応表(K1)作成する(ステップS8)。
【0051】
次に、変換テーブルヘッダ500の発注先IDに該当する項目変換テーブルへのポインタおよびコード変換テーブルへのポインタを参照して、項目変換テーブル520とコード変換テーブル530(存在するときのみ)を取り出す(ステップS9)。
項目変換テーブル520中の基幹業務システムのデータベースの項目に対応する「データ位置情報」を取り出す。このデータ位置情報に含まれる順番号および固定情報との組み合わせのうち、順番号を上記の対応表(K1)に格納されているデータの内容で置換して、基幹業務システムのデータベースの項目と対応付けた対応表(T2)を作成する(ステップS10)。
このとき、順番号とその内容に対応する発注先のコードがあれば、コード変換テーブル530を参照して受注先のコードに置き換える。
【0052】
テーブル保守手段125は、注文管理システム120の管理者が新規発注企業を追加したとき、また契約を打ち切ったとき、あるいは注文データの書式やコード体系が変更になったときに、必要に応じて変換テーブル124(変換テーブルヘッダ500、データ位置テーブル510、項目変換テーブル520、コード変換テーブル530)の登録、削除または更新を行う。
【0053】
注文受付手段126は、データ変換手段123から渡された発注先ID、通信文、通信形式の区別、変換結果(上記の対応表T2)を受け取り、受付管理データベース(DB)127へ受注受付番号を採番して仮登録を行い、同時に変換結果の形式チェックを行う。この受付管理DB127では、受注受付番号ごとに次のようなデータ項目を保管管理する。
(1)注文データを受信した日時(受信日時)
(2)注文データの処理状況(受注状況)
(3)エラー詳細、修正状況
(4)基幹業務システムから通知された注文の納入日時(納期)
(5)発注先ID
(6)注文データとして送られてきた通信文(原文)
(7)通信文を変換したデータ(上記の対応表T2)
【0054】
注文データを受信した注文受付手段126は、次のことを実行する。
まず、受注受付番号を採番し、それをキーとして、受信日時、発注先ID、通信文、変換されたデータおよび受注状況として「OE送信待ち」をそれぞれ受付管理DB127へ登録する。
次に、例えば、変換された各データ項目に対して次のようなチェックをする。
・必要なデータが指定されていない(入力漏れ)
・データ変換時のエラー(対応コードなし)
・発注先と変換データ中の客先コードが不一致
・数値データ中に文字データが存在する
・数値が大きすぎる等
【0055】
チェックの結果エラーがあれば、受注受付担当者の担当者端末150へエラーが検出されたことを電子メールで通知するとともに、受注状況として「OE送信エラー」、エラー詳細として上記したようなエラーの理由、修正状況として「未処理」を、受付管理DB127の当該受注受付番号に対応して登録する。
また、受注受付担当者へは、例えば、次のような通信文が送信される。
【0056】
通信タイトルとしては、
「O/Eデータ送信処理」
通信文としては、
「受注受付番号=XXXXXX
(どの項目に対して、どのようなエラーが起きたかを説明した文)
受注データ一覧画面で確認してください。」
【0057】
変換データをチェックしてエラーが見つからなければ、受注状況を「基幹業務システムへの送信待ち」、エラー詳細を「OE受信正常」として、受付管理DB127の当該受注受付番号に対応して更新し、基幹業務システム140への送信キューに登録する。この送信が完了すると受注状況は「納期入力待ち」に更新される。
【0058】
また、注文受付手段126は、受付管理DB127のエラー修正が完了した受注受付番号を監視する。これは受注状況が「OE送信待ち」でエラーの処理状況「エラー有り」のものを探すことによって、監視できる。
注文受付手段126は、エラーの修正が完了したものが見つかった場合、再度、上述したようなエラーチェックを行う。
【0059】
受注受付担当者は、上述したようなエラー通知の電子メールを受け取ると、担当者端末150を操作してデータ修正手段128を起動させ、エラーを修正する。
データ修正手段128は、まず、図9のような受注データ一覧画面を表示する。
受注受付担当者は、表示された一覧から受信日時や未処理データ等を指定して検索することによって、絞り込んだ一覧表示から修正すべき受注受付番号を見つける。
【0060】
更に、見つけた受注受付番号の欄をマウスでクリックすると、データ修正手段128は、図10のような明細画面を表示する。この図中、テキストボックスとして表示されているところが修正可能な項目である。
受注受付担当者は、エラー通知のエラー詳細に書かれていた項目を修正して、画面右上の「更新」をクリックする。
データ修正手段128は、受付管理DB127の修正された項目を更新し、エラーの修正状況を「OE送信待ち」に更新する。
【0061】
納期入力手段129は、基幹業務システム140から注文データが受け付けられ、その納期が送信されてくると、該当受注受付番号の納期および受注状況を「お客様への結果送信待ち」として受付管理DB127を更新する。
【0062】
納期通知手段130は、受付管理DB127の受注状況が「お客様への結果送信待ち」となっている受注受付番号を監視する。
納期通知手段130は、「お客様への結果送信待ち」の受注受付番号を見つけると、受付管理DB127から注文データの原文および納期とを、受信した時の通信形式へ逆変換して発注先へ返信する。このとき、受注受付担当者が修正したデータがあれば、発注先の通信形式へ逆変換して通信文に付加して送信する。
この逆変換は、データ変換テーブル124を用いてデータ変換手段123で行う。
【0063】
上述した受付管理DB127では、注文データの原文を保存するようにしたが、原文を保存しないようにして受付管理DB127のデータ容量を減らすことができる。この場合、発注先への受注確認の送信に使われる注文データは、変換されていたデータを逆変換することによって発注先のデータ形式へ戻す。
【0064】
本発明は、上述した実施形態のみに限定されたものではない。上述した実施形態の受発注システムを構成する各機能をそれぞれプログラム化し、あらかじめCD−ROM等の記録媒体に書き込んでおき、コンピュータに搭載したCD−ROMドライブのような媒体駆動装置にこのCD−ROM等を装着して、これらのプログラムをコンピュータのメモリあるいは記憶装置に格納し、それを実行することによって、本発明の目的が達成されることは言うまでもない。
この場合、記録媒体から読み出されたプログラム自体が上述した実施形態の機能を実現することになり、そのプログラムおよびそのプログラムを記録した記録媒体も本発明を構成することになる。
【0065】
なお、プログラムを格納する記録媒体としては半導体媒体(例えば、ROM、不揮発性メモリ等)、光媒体(例えば、DVD、MO、MD、CD等)、磁気媒体(例えば、磁気テープ、フレキシブルディスク等)等のいずれであってもよい。
【0066】
また、ロードしたプログラムを実行することにより上述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、オペレーティングシステムあるいは他のアプリケーションプログラム等と共同して処理することによって上述した実施形態の機能が実現される場合も含まれる。
【0067】
市場に流通させる場合には、可搬型の記録媒体にプログラムを格納して流通させたり、インターネット等の通信網を介して接続されたサーバコンピュータの記憶装置に格納しておき、通信網を通じて他のコンピュータに転送することもできる。この場合、このサーバコンピュータの記憶装置も本発明の記録媒体に含まれる。なお、コンピュータでは、可搬型の記録媒体上のプログラム、または転送されてくるプログラムを、コンピュータに接続された記憶装置にインストールし、そのインストールされたプログラムを実行することによって上述した実施形態の機能が実現される。
【0068】
【発明の効果】
以上説明したように本発明によれば、受注側の企業が、発注企業ごとに異なる注文データの形式を受注側の基幹業務システムが必要とする形式へ変換テーブルで変換するようにしたので、新たに発注企業が増えてもシステム化投資が短期間・低コストで対応することができる。
この変換においては、データ項目の1対1の変換だけでなく、複数の項目を組み合わせて1つの項目に対応付けることができるので、より柔軟な変換が行える。
また、発注側の企業で利用しているコード体系や文字列を受注側のコード体系に変換できるようにしたことにより、さらに発注側の入力負荷が低減される。
【0069】
また、発注側の注文データに不備がある場合に、受注受付担当者が修正を行えるようにしたので、不備データについて受信データを活用して修正でき、受注入力の負荷が低減できる。
更に、受注側では注文データに対する納期情報を自動的に発注側へ送信するので、納期回答業務の負荷が低減できる。
一方、発注側の発注担当者としては、注文データに対する修正や納期情報の送信を受注側が行ってくれるので、修正や納期情報の確認作業がなくなり、業務の負荷が低減できる。
【図面の簡単な説明】
【図1】実施形態に係る受発注システムの構成を示すブロック図である。
【図2】実施形態に係る注文管理システムの機能構成を示すブロック図である。
【図3】注文データの通信文を示す例である。
【図4】変換テーブルのデータ構造を示す図である。
【図5】データ位置テーブルの例である。
【図6】項目変換テーブルの例である。
【図7】コード変換テーブルの例である。
【図8】データ変換手段の処理手順を示すフローチャートである。
【図9】受注データ一覧画面の例である。
【図10】受注データの詳細表示画面の例である。
【符号の説明】
100…受注側システム、110…Webサーバ、120…注文管理システム、121…認証手段、122…認証DB、123…データ変換手段、124…変換テーブル、125…テーブル保守手段、126…注文受付手段、127…受付管理DB、128…データ修正手段、129…納期入力手段、130…納期通知手段、140…基幹業務システム、150…担当者端末、160…ネットワーク、200…発注側システム、300…ネットワーク、500…変換テーブルヘッダ、510…データ位置テーブル、520…項目変換テーブル、530…コード変換テーブル。
【発明の属する技術分野】
本発明は、受発注システム、プログラムおよび記録媒体に関し、具体的には、企業間で電子データ交換によって商取引を行うときに、発注企業から送られてきたデータを受注企業における受発注システムで処理できるデータとして変換する技術に関する。
【0002】
【従来の技術】
従来からEDI(Electronic Data Interchange:電子データ交換)を使って、基幹業務(生産計画、在庫管理、購買等)において、特定企業間でのデータ交換を効率化してきた。このため商取引で使用する紙ベースの各種帳票を電子データ化し、システム間でのデータ交換を標準化した。
この標準化されたEDIは、専用回線やVAN(付加価値情報ネットワーク)のような閉じたネットワーク上で特定企業間のデータ交換に利用されている。
【0003】
しかし、専用回線やVANを使うEDIでは、導入コストおよび運用コストが高いため、導入できるのは大企業に限られていた。
このため、インターネットが普及するにつれて、専用回線やVANの代わりにインターネットを使うWeb−EDIが使われるようになった。
【0004】
このWeb−EDIでは、Webブラウザを通じてインターネット上で取引できるため、低コストの導入・維持ができるので、従来はEDIを導入しにくかった中小の取引先や取引頻度の少ない取引先を情報の共有化のメンバーとして取り込めるようになり、新規の取引先においても最初から電子商取引を行うことができるようになった。
【0005】
また、異なる企業の基幹業務システム間でデータ交換を行うためには、データ記述を共通化しなければならなくなった。このため、XML(eXtensible Markup Language)でデータを記述することによって、特定の企業やシステム環境に依存しないEDI(これをXML−EDIと呼んでいる)を実現できるようになっている。
【0006】
【特許文献1】
特開平05−61745号公報
【特許文献2】
特開2002−99754号公報
【特許文献3】
特開2001−325537号公報
【0007】
【発明が解決しようとする課題】
しかしながら、多数の発注企業から受注する受注企業の場合、発注企業ごとに電子データ交換の仕様(注文フォーマットやデータコード等)が異なっているため、受信したデータを自社の基幹業務システムで処理するために、個別にシステム化対応を実施する必要があり、システム化投資もその都度発生していた。
【0008】
上述した注文フォーマットが異なる場合を解決するため、特許文献1の「フォーマットの変換装置」は、受発注システムで使われるフォーマットに対して、予め変換前後のフォーマットの定義に基づいて変換テーブルを作成しておき、入力されたデータを判別して変換テーブルを選択してフォーマットの変換を行うようにした。この変換に際して、1対1に変換が取れないものや特別に変換を伴う場合には、変換に先立って例外処理を施した後に変換テーブルを使ってフォーマット変換を行う。これにより、ユーザのフォーマット変更要求に対し柔軟に対応することができる。
【0009】
しかし、この特許文献1による方法では、変換前後のフォーマット上の項目が1対1に対応しない場合には、特別な処理を行う必要があるため、相変わらず個別にシステム化対応をしなければならない。
【0010】
また、一旦発注企業から送られてきた電子データにエラーが含まれていることが分かった場合には、従来では、発注企業に連絡または発注企業側でエラー状況を監視する等をしてもう一度データを作成して、送り直してもらっていた。例えば、特許文献2の「受注システム」では、インターネット上にサーバをホストに繋いだシステムを構築しておき、発注先は、インターネット経由でサーバにアクセスして発注情報を入力する。
サーバでは、入力された発注情報をチェックし、サーバ内のファイルに仮受付けオーダとして格納するとともに、このオーダを定期的にホストに送信する。
【0011】
ホストは、これを正式オーダとして登録し、チェックおよび在庫引当を経てホスト内のファイルに格納し、このオーダのデータを定期的にサーバのファイルに送信する。
他方、ホストが正式オーダとし得ない仮受付けオーダは、エラーデータとしてホスト内のファイルに格納し、定期的にサーバのファイルに送信する。
サーバは、ホストから受信した正式オーダとしての登録オーダまたはエラーデータを、得意先に電子メールにて送信したり、得意先がインターネット経由でサーバにアクセスして受注オーダの状況を確認することができるようにした。
【0012】
一方、企業間の注文では、発注側へ返信することなく、受注側で対処することが一般的であるが、この特許文献2の発明ではエラーとなった注文データは発注側へ送り返されるので、修正して送り返さなければならなくなる。
【0013】
また、発注企業で使われているコード体系と受注企業で使われているコード体系では一致していないのが一般的である。
これらのエラー修正や発注企業で使われているコード体系をそのまま使えるようにできれば顧客満足を得るものとなる。
【0014】
また、特許文献3の「インターネットを介する受発注システム」では、統一注文フォーマットを定めて、それを発注企業が使って注文書を作成し、この注文書をインターネット上に設けた仲介装置へ送って受注企業の業種フォーマットに変換して受注企業に送るようにした。
【0015】
しかしながら、会員として登録した企業全てに共通した統一注文フォーマットを作成したり、様々なコード体系に対応するために、仲介装置を維持管理することは難しい。
【0016】
本発明は、上述した実情を考慮してなされたもので、注文書式が異なる発注企業に対しても、新たなシステム化投資をすることなく対応できる受発注システム、受発注システムの機能を実行するためのプログラムおよびそのプログラムを記録したコンピュータ読み取り可能な記録媒体を提供することを目的とする。
【0017】
【課題を解決するための手段】
上記課題を解決するために、本発明の請求項1は、複数の企業からなる発注先から注文データを受信し、その注文データのデータ形式を受注側が処理しうるデータ形式に変換テーブルで変換し、その変換された注文データによって電子商取引を行う受発注システムにおいて、前記変換テーブルを発注先ごとに用意し、前記変換テーブルには、前記受注側の1つのデータ項目に対して前記発注先の1つ以上のデータ項目を組み合わせて定義しておき、前記発注先から注文データを受信した場合、前記変換テーブルで受注側の受発注システムで処理し得るデータの形式に変換してから受注処理を行うことを特徴とする。
【0018】
また、本発明の請求項2は、請求項1に記載の受発注システムにおいて、前記注文データを変換するときに、その注文データ中に発注先の使用するコード体系のコードがあるときに、そのコードを受注側で使用するコード体系のコードへ変換するようにしたことを特徴とする。
また、本発明の請求項3は、請求項1または2に記載の受発注システムにおいて、前記発注先からの注文データの送信をWebサービスあるいは電子メールで行うようにしたことを特徴とする。
また、本発明の請求項4は、請求項1、2または3に記載の受発注システムにおいて、前記変換されたデータをチェックし、エラーがあった場合には、受注受付担当者へ通知することを特徴とする。
また、本発明の請求項5は、請求項4に記載の受発注システムにおいて、エラーの通知を受けた前記受注受付担当者から該エラーのみを入力させて注文データを修正することを特徴とする。
【0019】
また、本発明の請求項6は、請求項5に記載の受発注システムにおいて、エラーが修正されるのを監視し、修正された注文データを再度チェックするようにしたことを特徴とする。
また、本発明の請求項7は、請求項1乃至6のいずれかに記載の受発注システムにおいて、前記受注処理した結果の納期データを当該注文データに付して、受注確認情報として返信することを特徴とする。
また、本発明の請求項8は、請求項7に記載の受発注システムにおいて、発注先への受注確認の返信は、発注先が注文データを送信してきたときの送信形式と同じ形式とすることを特徴とする。
【0020】
また、本発明の請求項9は、複数の企業からなる発注先から送信された注文データによって受注側と電子商取引を行う受発注システムにおいて、前記発注先ごとに、受注側の1つのデータ項目に対して発注先の1つ以上のデータ項目を組み合わせて定義した変換テーブルと、前記変換テーブルを用いて、前記発注先から受信した注文データを前記受注側の受発注システムで処理し得るデータの形式に変換するデータ変換手段とを備えることを特徴とする。
【0021】
また、本発明の請求項10のプログラムは、コンピュータに、請求項1乃至9のいずれかに記載の受発注システムの機能を実行させるためのプログラムである。
また、本発明の請求項11の記録媒体は、請求項10に記載の受発注システムのプログラムを記録したコンピュータ読み取り可能な記録媒体である。
【0022】
以上の構成により、受注側の企業が、発注企業ごとに異なる注文データの形式を受注側の基幹業務システムが必要とする形式へ変換テーブルで変換するようにしたので、新たに発注企業が増えてもシステム化投資が短期間・低コストで対応することができる。
この変換においては、データ項目の1対1の変換だけでなく、複数の項目を組み合わせて1つの項目に対応付けることができるので、より柔軟な変換が行える。
また、発注側の企業で利用しているコード体系や文字列を受注側のコード体系に変換できるようにしたことにより、さらに発注側の入力負荷が低減される。
【0023】
また、発注側の注文データに不備がある場合に、受注受付担当者が修正を行えるようにしたので、不備データについて受信データを活用して修正でき、受注入力の負荷が低減できる。
更に、受注側では注文データに対する納期情報を自動的に発注側へ送信するので、納期回答業務の負荷が低減できる。
一方、発注側の発注担当者としては、注文データに対する修正や納期情報の送信を受注側が行ってくれるので、修正や納期情報の確認作業がなくなり、業務の負荷が低減できる。
【0024】
【発明の実施の形態】
以下、図面を参照して、本発明の受発注システムに係る好適な実施形態を説明する。
図1は、本実施形態の受発注システムの構成を示すブロック図である。
図1において、受発注システムは、複数の発注企業が所有する発注側システム200と、受注管理を行う受注企業が所有する受注側システム100とをネットワーク300で接続している。ここで1つの発注企業で複数の発注側システムを所有してもよいが、本実施形態の説明では、1つの発注企業で1つの発注側システムを所有するとして説明する。また、企業ではなく、個人や中小企業や小規模な商店であっても同様に利用することができる。
【0025】
ネットワーク300は、専用回線網や公衆回線網を利用して、LAN(Local Area Network)、WAN(Wide Area Network)またはインターネットのいずれであってもよく、このネットワークを介して発注側システムと受注側システムとはhttpプロトコルやsmtpプロトコル等の通信プロトコルによってデータをやり取りする。
【0026】
発注側システム200としては、発注側の受発注管理を行うコンピュータや単に注文データのみを送信するパーソナルコンピュータ(ノート型、デスクトップ型等)、PDA(Personal Digital Assistant)や携帯電話等のいずれであってもよい。
【0027】
更に、受注側システム100は、Webサーバ110、注文管理システム120、基幹業務システム140、1台以上の担当者端末150とをネットワーク160で接続し、セキュリティ確保のためファイアウォールを介在させている。
ネットワーク160は、受注企業内に設置されたWebサーバ110、注文管理システム120、基幹業務システム140、1台以上の担当者端末150とを接続するWANまたはLANである。
【0028】
Webサーバ110は、ネットワーク300を介して発注側システム200から注文データを受信し、ネットワーク160を介してこのデータを注文管理システム120へ送信する。
また、Webサーバ110は、ネットワーク160を介して注文管理システム120から処理された受注確認・納期データを受信し、注文データを受信したときと同じ通信プロトコルによってネットワーク300を介して発注側システム200へ返信する。
通信プロトコルがhttpプロトコルの場合には、通信文をXML伝送プロトコルによって送信し、smtpプロトコルの場合には、電子メールとして通信文を送信する。
【0029】
注文管理システム120は、受注した注文データをチェックし、エラーがあれば担当者が修正した注文データを基幹業務システム140へ送信する。また、基幹業務システム140からの受注確認と納期を発注先のデータ形式へ逆変換して発注側システム200へ返信する。
これを行うために、注文管理システム120は、注文データ、注文処理状況および納期の保管管理を行う。
【0030】
基幹業務システム140は、既存の受注管理、生産管理や在庫管理等を処理するシステムであって、注文データを登録するとともに、注文データに対して在庫状況や生産状況を参照して納期を決定して、納期を注文管理システム120へ返信する。
【0031】
また、担当者端末150は、注文データにエラーがあったときに、注文管理システム120からエラー通知を受信する受注受付担当者用の端末であり、また、そのエラーが起きた注文データを修正する端末でもある。
【0032】
このような構成において、発注企業の発注担当者が購入する商品や部品等を決定して、PC等の端末(発注側システム200)から注文データをWebサービスを利用して、XMLデータやメールの電文をhttpやsmtpプロトコルによってネットワーク300を介してWebサーバ110へ送信する。
【0033】
注文管理システム120は、Webサーバ110が受信した注文データの送信先が登録されている発注企業であるかを認証し、メールやXMLによる通信文を基幹業務システム140が保持するデータベースが扱える項目へ変換するとともに、データ入力漏れやデータミス等をチェックし、エラーがなければ変換したデータを基幹業務システム140へ送信する。
【0034】
一方、注文データにエラーが見つかれば、受注受付担当者の担当者端末150へエラー通知を電子メールで出す。この担当者は通知された注文データのエラーを修正する。注文管理システム120は、修正された注文データを再度チェックする。
【0035】
また、注文管理システム120は、注文データを保管するとともに、基幹業務システム140から送信された納期を注文データと関連付けて保存するとともに、注文データに納期を付加して注文確認データとして、Webサーバ110を介して発注側システム200へ返信する。
【0036】
以下、注文管理システム120についてより詳細に説明する。図2は、注文管理システム120の機能構成を示すブロック図であり、図2において、注文管理システム120は、認証手段121、認証データベース(DB)122、データ変換手段123、変換テーブル124、テーブル保守手段125、注文受付手段126、受付管理データベース(DB)127、データ修正手段128、納期入力手段129、納期通知手段130を少なくとも備えている。
【0037】
認証手段121は、送信先のメールアドレス、または通信文中の発注先を特定するデータを抽出し、送信先がすでに認証DB122に登録されているかをチェックする。
認証DB122には、注文データを送信する前に、予め発注先を特定するデータと発注先IDとを対応させて登録しておく必要がある。
また、認証手段121は、正常に認証が済むと、Webサーバ110の受信した注文データがXML形式かまたは電子メール形式かを識別し、この形式の区別(XML形式、電子メール形式)、通信文および発注先IDをデータ変換手段123へ渡す。
ここで、注文データが添付された電子メールの場合には、この添付された注文データを通信文としてデータ変換手段123へ渡す。
【0038】
データ変換手段123は、認証手段121から渡された注文データを基幹業務システム140のデータベースで扱えるデータ項目へ変換テーブル124を参照して変換し、発注先ID、通信文、通信形式の区別および変換結果を注文受付手段126へ渡す。
【0039】
まず、注文データの通信文のデータ形式について説明する。
(1)XML形式の場合
発注企業側の設定した図3(A)に示すようなタグとそのコンテンツとから記述する。
タグには、商品コード、数量、発注先の企業名、届け先の住所、発注の担当者等があり、コンテンツにはそのタグに対応するデータ内容が記述され、これらのコンテンツはタグによって参照することができる。
【0040】
(2)電子メール形式の場合
これには、図3(B)に示すような区切り記号(カンマ、タブ、セミコロン等)で区切られる可変長形式と、図3(C)に示すような固定長形式とがあり、どちらを用いるかは、発注先ごとに契約時に決定しておく。
また、データの記述順序とデータ項目との対応関係も契約時に決めておく。
可変長形式の場合には、区切り記号で区切られる順に順番号を付け、この順番号によって各項目の内容が参照される。例えば、図3(B)の場合には、順番号1の項目の内容は「ABC株式会社」、順番号2の項目の内容は「10000」、順番号3の項目の内容は「1」等である。
【0041】
また、固定長形式の場合には、開始文字位置と終了文字位置で各項目を区切る。または、開始文字位置と項目の長さで表してもよい。
例えば、図3(C)の場合には、開始文字位置1から終了文字位置14の項目の内容は「ABC株式会社」、開始文字位置16から終了文字位置21の項目の内容は「10000」、開始文字位置23から終了文字位置25の項目の内容は「1」等である。
【0042】
次に、注文データから基幹業務システム140のデータベースで扱えるデータ項目へ変換する変換テーブル124について説明する。
図4は変換テーブル124のデータ構造を示す図である。同図において、変換テーブル124は、変換テーブルヘッダ500、データ位置テーブル510、項目変換テーブル520、コード変換テーブル530とから構成される。
【0043】
変換テーブルヘッダ500は、発注企業ごとに次の項目を保持する。
(1)発注先ID
(2)注文データの形式の区別(XML形式、電子メール形式等)
(3)上記の区別が電子メール形式であり、注文データを可変長形式で表現しているときの区切り記号
XML形式の時には、この項目はNULLである。
(4)上記の区別が電子メール形式であり、注文データを固定長形式で表現しているときの項目の位置を表すデータ位置テーブル510へのポインタ
XML形式および可変長形式の時には、この項目はNULLである。
(5)項目変換テーブル520へのポインタ
(6)コード変換テーブル530へのポインタ
【0044】
更に、データ位置テーブル510は、注文データが固定長形式の通信文として記述されているときに、各項目を識別するために、図5(A)に示すような、項目順に開始文字位置と終了文字位置とを並べたデータ構造となっている。
例えば、図5において、順番号が1番の項目は開始文字位置が1であり、終了文字位置が14である、14桁の文字列からなることを示している。同様に、順番号が7番の項目は開始文字位置が75であり、終了文字位置が88である、14桁の文字列からなることを示している。
また、データ位置テーブル510が、開始文字位置と項目の長さからなっている場合には、図5(B)に示すようなデータ構造となっている。
【0045】
項目変換テーブル520は、注文データの項目と基幹業務システム140のデータベースで扱える形式に変換するための変換テーブルであり、図6に示すようなデータ構造をしている。
その構造は、注文データ上の項目の組み合わせからなる「データ位置情報」と基幹業務システムのデータベース上の項目とを対応付けた表である。
(1)XML形式の場合(図6(A)参照)
注文データ上の項目はタグで示され、基幹業務システムのデータベース上の項目と対応付けられる。
(2)電子メール形式の場合(図6(B)参照)
注文データ上の項目は通信文中の項目の並びを示す順番号で示され、基幹業務システムのデータベース上の項目と対応付けられる。
または、固定長形式の場合、注文データ上の項目を上述のような順番号ではなく、開始文字位置と終了文字位置、または開始文字位置と項目の長さを使って、直接表現してもよい。例えば、(開始文字位置,終了文字位置)または(開始文字位置,項目の長さ)という2つの組みで通信文上の各項目のデータ位置を表現し、データ位置テーブル510のデータ位置情報を
(27,44)+(75,88)+(60,30)+“様”
または
(27,18)+(75,14)+(60,14)+“様”
とし、これを基幹システムのデータベースの項目「住所」へ対応付けるようにしてもよい。
【0046】
更に、基幹業務システムのデータベース上の1項目に対して、注文データ上の1つ以上の項目および固定的な文字または数字等を組み合わせてもよい。
例えば、基幹業務システムのデータベース上の項目「住所」は、注文データ上の項目「住所1」および「住所2」を連結し、届け先の「購買担当者」の名前を連結し、固定的な文字「様」を追加して構成する。
【0047】
発注側の企業としては、注文するときに自企業で使用しているコード体系が使えると便利である。しかし、受注する側の基幹業務システム140で処理しているコード体系と必ずしも一致していない。
この場合には、発注企業と受注企業が取引を契約したときに、図7に示すような発注側のコード体系と受注側のコード体系との対応表をコード変換テーブル530として作成する。このコード体系は、コードを表す項目名(電子メール形式の場合には、順番号)とその項目の中に含まれるコードとを対比したものである。
例えば、届け先のコードが発注企業では「100」であり、受注企業側では「24101−00」であれば、これらを対応させてコード変換テーブル530へ登録しておく。
【0048】
図8のフローチャートを用いて、データ変換手段123の処理手順を説明する。
認証手段121から発注先ID、通信文、通信形式の区別を受け取る(ステップS1)。
通信形式の区別がXML形式である場合は(ステップS2の「XML」)、通信文の中のタグとそのデータの内容とを抽出して、タグと内容との対応表(T1)を作成する(ステップS3)。
【0049】
変換テーブルヘッダ500の発注先IDに該当する項目変換テーブルへのポインタおよびコード変換テーブルへのポインタを参照して、項目変換テーブル520とコード変換テーブル530(存在するときのみ)を取り出す(ステップS4)。
項目変換テーブル520中の基幹業務システムのデータベースの項目に対応する「データ位置情報」を取り出す。この「データ位置情報」に含まれるタグおよび固定情報との組み合わせのうち、タグを上記の対応表(T1)に格納されているタグの内容で置換して、基幹業務システムのデータベースの項目と対応付けた対応表(T2)を作成する(ステップS5)。
このとき、タグとその内容に対応する発注先のコードがあれば、コード変換テーブル530を参照して受注先のコードに置き換える。
【0050】
一方、ステップS2で通信の形式が「電子メール」の場合、変換テーブルヘッダ500の発注先IDに対して「区切り」が存在するかを調べる(ステップS6)。
「区切り」が存在しない場合は、データ位置テーブルのポインタを参照して、データ位置テーブル510を取り出す。このデータ位置テーブル510の開始文字位置と終了文字位置(または項目の長さ)とから、通信文から順次内容を取り出して、順番号と内容との対応表(K1)作成する(ステップS7)。
他方、「区切り」が存在する場合には、区切り記号によって通信文から順次内容を取り出して、順番号と内容との対応表(K1)作成する(ステップS8)。
【0051】
次に、変換テーブルヘッダ500の発注先IDに該当する項目変換テーブルへのポインタおよびコード変換テーブルへのポインタを参照して、項目変換テーブル520とコード変換テーブル530(存在するときのみ)を取り出す(ステップS9)。
項目変換テーブル520中の基幹業務システムのデータベースの項目に対応する「データ位置情報」を取り出す。このデータ位置情報に含まれる順番号および固定情報との組み合わせのうち、順番号を上記の対応表(K1)に格納されているデータの内容で置換して、基幹業務システムのデータベースの項目と対応付けた対応表(T2)を作成する(ステップS10)。
このとき、順番号とその内容に対応する発注先のコードがあれば、コード変換テーブル530を参照して受注先のコードに置き換える。
【0052】
テーブル保守手段125は、注文管理システム120の管理者が新規発注企業を追加したとき、また契約を打ち切ったとき、あるいは注文データの書式やコード体系が変更になったときに、必要に応じて変換テーブル124(変換テーブルヘッダ500、データ位置テーブル510、項目変換テーブル520、コード変換テーブル530)の登録、削除または更新を行う。
【0053】
注文受付手段126は、データ変換手段123から渡された発注先ID、通信文、通信形式の区別、変換結果(上記の対応表T2)を受け取り、受付管理データベース(DB)127へ受注受付番号を採番して仮登録を行い、同時に変換結果の形式チェックを行う。この受付管理DB127では、受注受付番号ごとに次のようなデータ項目を保管管理する。
(1)注文データを受信した日時(受信日時)
(2)注文データの処理状況(受注状況)
(3)エラー詳細、修正状況
(4)基幹業務システムから通知された注文の納入日時(納期)
(5)発注先ID
(6)注文データとして送られてきた通信文(原文)
(7)通信文を変換したデータ(上記の対応表T2)
【0054】
注文データを受信した注文受付手段126は、次のことを実行する。
まず、受注受付番号を採番し、それをキーとして、受信日時、発注先ID、通信文、変換されたデータおよび受注状況として「OE送信待ち」をそれぞれ受付管理DB127へ登録する。
次に、例えば、変換された各データ項目に対して次のようなチェックをする。
・必要なデータが指定されていない(入力漏れ)
・データ変換時のエラー(対応コードなし)
・発注先と変換データ中の客先コードが不一致
・数値データ中に文字データが存在する
・数値が大きすぎる等
【0055】
チェックの結果エラーがあれば、受注受付担当者の担当者端末150へエラーが検出されたことを電子メールで通知するとともに、受注状況として「OE送信エラー」、エラー詳細として上記したようなエラーの理由、修正状況として「未処理」を、受付管理DB127の当該受注受付番号に対応して登録する。
また、受注受付担当者へは、例えば、次のような通信文が送信される。
【0056】
通信タイトルとしては、
「O/Eデータ送信処理」
通信文としては、
「受注受付番号=XXXXXX
(どの項目に対して、どのようなエラーが起きたかを説明した文)
受注データ一覧画面で確認してください。」
【0057】
変換データをチェックしてエラーが見つからなければ、受注状況を「基幹業務システムへの送信待ち」、エラー詳細を「OE受信正常」として、受付管理DB127の当該受注受付番号に対応して更新し、基幹業務システム140への送信キューに登録する。この送信が完了すると受注状況は「納期入力待ち」に更新される。
【0058】
また、注文受付手段126は、受付管理DB127のエラー修正が完了した受注受付番号を監視する。これは受注状況が「OE送信待ち」でエラーの処理状況「エラー有り」のものを探すことによって、監視できる。
注文受付手段126は、エラーの修正が完了したものが見つかった場合、再度、上述したようなエラーチェックを行う。
【0059】
受注受付担当者は、上述したようなエラー通知の電子メールを受け取ると、担当者端末150を操作してデータ修正手段128を起動させ、エラーを修正する。
データ修正手段128は、まず、図9のような受注データ一覧画面を表示する。
受注受付担当者は、表示された一覧から受信日時や未処理データ等を指定して検索することによって、絞り込んだ一覧表示から修正すべき受注受付番号を見つける。
【0060】
更に、見つけた受注受付番号の欄をマウスでクリックすると、データ修正手段128は、図10のような明細画面を表示する。この図中、テキストボックスとして表示されているところが修正可能な項目である。
受注受付担当者は、エラー通知のエラー詳細に書かれていた項目を修正して、画面右上の「更新」をクリックする。
データ修正手段128は、受付管理DB127の修正された項目を更新し、エラーの修正状況を「OE送信待ち」に更新する。
【0061】
納期入力手段129は、基幹業務システム140から注文データが受け付けられ、その納期が送信されてくると、該当受注受付番号の納期および受注状況を「お客様への結果送信待ち」として受付管理DB127を更新する。
【0062】
納期通知手段130は、受付管理DB127の受注状況が「お客様への結果送信待ち」となっている受注受付番号を監視する。
納期通知手段130は、「お客様への結果送信待ち」の受注受付番号を見つけると、受付管理DB127から注文データの原文および納期とを、受信した時の通信形式へ逆変換して発注先へ返信する。このとき、受注受付担当者が修正したデータがあれば、発注先の通信形式へ逆変換して通信文に付加して送信する。
この逆変換は、データ変換テーブル124を用いてデータ変換手段123で行う。
【0063】
上述した受付管理DB127では、注文データの原文を保存するようにしたが、原文を保存しないようにして受付管理DB127のデータ容量を減らすことができる。この場合、発注先への受注確認の送信に使われる注文データは、変換されていたデータを逆変換することによって発注先のデータ形式へ戻す。
【0064】
本発明は、上述した実施形態のみに限定されたものではない。上述した実施形態の受発注システムを構成する各機能をそれぞれプログラム化し、あらかじめCD−ROM等の記録媒体に書き込んでおき、コンピュータに搭載したCD−ROMドライブのような媒体駆動装置にこのCD−ROM等を装着して、これらのプログラムをコンピュータのメモリあるいは記憶装置に格納し、それを実行することによって、本発明の目的が達成されることは言うまでもない。
この場合、記録媒体から読み出されたプログラム自体が上述した実施形態の機能を実現することになり、そのプログラムおよびそのプログラムを記録した記録媒体も本発明を構成することになる。
【0065】
なお、プログラムを格納する記録媒体としては半導体媒体(例えば、ROM、不揮発性メモリ等)、光媒体(例えば、DVD、MO、MD、CD等)、磁気媒体(例えば、磁気テープ、フレキシブルディスク等)等のいずれであってもよい。
【0066】
また、ロードしたプログラムを実行することにより上述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、オペレーティングシステムあるいは他のアプリケーションプログラム等と共同して処理することによって上述した実施形態の機能が実現される場合も含まれる。
【0067】
市場に流通させる場合には、可搬型の記録媒体にプログラムを格納して流通させたり、インターネット等の通信網を介して接続されたサーバコンピュータの記憶装置に格納しておき、通信網を通じて他のコンピュータに転送することもできる。この場合、このサーバコンピュータの記憶装置も本発明の記録媒体に含まれる。なお、コンピュータでは、可搬型の記録媒体上のプログラム、または転送されてくるプログラムを、コンピュータに接続された記憶装置にインストールし、そのインストールされたプログラムを実行することによって上述した実施形態の機能が実現される。
【0068】
【発明の効果】
以上説明したように本発明によれば、受注側の企業が、発注企業ごとに異なる注文データの形式を受注側の基幹業務システムが必要とする形式へ変換テーブルで変換するようにしたので、新たに発注企業が増えてもシステム化投資が短期間・低コストで対応することができる。
この変換においては、データ項目の1対1の変換だけでなく、複数の項目を組み合わせて1つの項目に対応付けることができるので、より柔軟な変換が行える。
また、発注側の企業で利用しているコード体系や文字列を受注側のコード体系に変換できるようにしたことにより、さらに発注側の入力負荷が低減される。
【0069】
また、発注側の注文データに不備がある場合に、受注受付担当者が修正を行えるようにしたので、不備データについて受信データを活用して修正でき、受注入力の負荷が低減できる。
更に、受注側では注文データに対する納期情報を自動的に発注側へ送信するので、納期回答業務の負荷が低減できる。
一方、発注側の発注担当者としては、注文データに対する修正や納期情報の送信を受注側が行ってくれるので、修正や納期情報の確認作業がなくなり、業務の負荷が低減できる。
【図面の簡単な説明】
【図1】実施形態に係る受発注システムの構成を示すブロック図である。
【図2】実施形態に係る注文管理システムの機能構成を示すブロック図である。
【図3】注文データの通信文を示す例である。
【図4】変換テーブルのデータ構造を示す図である。
【図5】データ位置テーブルの例である。
【図6】項目変換テーブルの例である。
【図7】コード変換テーブルの例である。
【図8】データ変換手段の処理手順を示すフローチャートである。
【図9】受注データ一覧画面の例である。
【図10】受注データの詳細表示画面の例である。
【符号の説明】
100…受注側システム、110…Webサーバ、120…注文管理システム、121…認証手段、122…認証DB、123…データ変換手段、124…変換テーブル、125…テーブル保守手段、126…注文受付手段、127…受付管理DB、128…データ修正手段、129…納期入力手段、130…納期通知手段、140…基幹業務システム、150…担当者端末、160…ネットワーク、200…発注側システム、300…ネットワーク、500…変換テーブルヘッダ、510…データ位置テーブル、520…項目変換テーブル、530…コード変換テーブル。
Claims (11)
- 複数の企業からなる発注先から注文データを受信し、その注文データのデータ形式を受注側が処理しうるデータ形式に変換テーブルで変換し、その変換された注文データによって電子商取引を行う受発注システムにおいて、前記変換テーブルを発注先ごとに用意し、前記変換テーブルには、前記受注側の1つのデータ項目に対して前記発注先の1つ以上のデータ項目を組み合わせて定義しておき、前記発注先から注文データを受信した場合、前記変換テーブルで受注側の受発注システムで処理し得るデータの形式に変換してから受注処理を行うことを特徴とする受発注システム。
- 請求項1に記載の受発注システムにおいて、前記注文データを変換するときに、その注文データ中に発注先の使用するコード体系のコードがあるときに、そのコードを受注側で使用するコード体系のコードへ変換するようにしたことを特徴とする受発注システム。
- 請求項1または2に記載の受発注システムにおいて、前記発注先からの注文データの送信をWebサービスあるいは電子メールで行うようにしたことを特徴とする受発注システム。
- 請求項1、2または3に記載の受発注システムにおいて、前記変換されたデータをチェックし、エラーがあった場合には、受注受付担当者へ通知することを特徴とする受発注システム。
- 請求項4に記載の受発注システムにおいて、エラーの通知を受けた前記受注受付担当者から該エラーのみを入力させて注文データを修正することを特徴とする受発注システム。
- 請求項5に記載の受発注システムにおいて、エラーが修正されるのを監視し、修正された注文データを再度チェックするようにしたことを特徴とする受発注システム。
- 請求項1乃至6のいずれかに記載の受発注システムにおいて、前記受注処理した結果の納期データを当該注文データに付して、受注確認情報として返信することを特徴とする受発注システム。
- 請求項7に記載の受発注システムにおいて、発注先への受注確認の返信は、発注先が注文データを送信してきたときの送信形式と同じ形式とすることを特徴とする受発注システム。
- 複数の企業からなる発注先から送信された注文データによって受注側と電子商取引を行う受発注システムにおいて、前記発注先ごとに、受注側の1つのデータ項目に対して発注先の1つ以上のデータ項目を組み合わせて定義した変換テーブルと、前記変換テーブルを用いて、前記発注先から受信した注文データを前記受注側の受発注システムで処理し得るデータの形式に変換するデータ変換手段とを備えることを特徴とする受発注システム。
- コンピュータに、請求項1乃至9のいずれかに記載の受発注システムの機能を実行させるためのプログラム。
- 請求項10に記載の受発注システムのプログラムを記録したコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002342446A JP2004178190A (ja) | 2002-11-26 | 2002-11-26 | 受発注システム、プログラムおよび記録媒体 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002342446A JP2004178190A (ja) | 2002-11-26 | 2002-11-26 | 受発注システム、プログラムおよび記録媒体 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004178190A true JP2004178190A (ja) | 2004-06-24 |
Family
ID=32704514
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002342446A Pending JP2004178190A (ja) | 2002-11-26 | 2002-11-26 | 受発注システム、プログラムおよび記録媒体 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2004178190A (ja) |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009116556A (ja) * | 2007-11-06 | 2009-05-28 | Nippon Information & Communication | 情報処理システム |
JP2009169791A (ja) * | 2008-01-18 | 2009-07-30 | Hitachi Information Systems Ltd | 送受信データ件数確認システムおよび確認方法、ならびにそのプログラム |
JP2009169792A (ja) * | 2008-01-18 | 2009-07-30 | Hitachi Information Systems Ltd | 送受信データ件数確認システムおよびその確認方法、ならびにそのプログラム |
JP2010044627A (ja) * | 2008-08-13 | 2010-02-25 | Nec Corp | データ集配装置、データ集配システム、データ集配方法及びプログラム |
JP2010066874A (ja) * | 2008-09-09 | 2010-03-25 | Hitachi Information Systems Ltd | 電子データ交換コンピュータ及び電子データ交換プログラム |
JP2010527477A (ja) * | 2007-05-10 | 2010-08-12 | トレーディング テクノロジーズ インターナショナル インコーポレイテッド | 取引対象物について電子的な価格提示を提供するためのシステムおよび方法 |
JP2011034186A (ja) * | 2009-07-30 | 2011-02-17 | Yoichiro Kojima | 生産管理システム |
JP2011034185A (ja) * | 2009-07-30 | 2011-02-17 | Yoichiro Kojima | Ediサーバコンピュータ及びediシステム |
WO2012023192A1 (ja) * | 2010-08-18 | 2012-02-23 | 前田建設工業株式会社 | 情報処理装置、情報処理方法、プログラム、および媒体 |
JP2012093997A (ja) * | 2010-10-27 | 2012-05-17 | Toshiba Tec Corp | 予約受付装置およびプログラム |
JP2012238301A (ja) * | 2011-04-28 | 2012-12-06 | Yamato Packing Service Co Ltd | 商品発注支援装置 |
-
2002
- 2002-11-26 JP JP2002342446A patent/JP2004178190A/ja active Pending
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8204817B2 (en) | 2007-05-10 | 2012-06-19 | Trading Technologies International, Inc. | System and method for providing electronic price feeds for tradeable objects |
JP2010527477A (ja) * | 2007-05-10 | 2010-08-12 | トレーディング テクノロジーズ インターナショナル インコーポレイテッド | 取引対象物について電子的な価格提示を提供するためのシステムおよび方法 |
US9501797B2 (en) | 2007-05-10 | 2016-11-22 | Trading Technologies International, Inc. | System and method for providing electronic price feeds for tradeable objects |
US8682782B2 (en) | 2007-05-10 | 2014-03-25 | Trading Technologies International, Inc. | System and method for providing electronic price feeds for tradeable objects |
US8370252B2 (en) | 2007-05-10 | 2013-02-05 | Trading Technologies International, Inc. | System and method for providing electronic price feeds for tradeable objects |
JP2009116556A (ja) * | 2007-11-06 | 2009-05-28 | Nippon Information & Communication | 情報処理システム |
JP2009169791A (ja) * | 2008-01-18 | 2009-07-30 | Hitachi Information Systems Ltd | 送受信データ件数確認システムおよび確認方法、ならびにそのプログラム |
JP2009169792A (ja) * | 2008-01-18 | 2009-07-30 | Hitachi Information Systems Ltd | 送受信データ件数確認システムおよびその確認方法、ならびにそのプログラム |
JP2010044627A (ja) * | 2008-08-13 | 2010-02-25 | Nec Corp | データ集配装置、データ集配システム、データ集配方法及びプログラム |
JP2010066874A (ja) * | 2008-09-09 | 2010-03-25 | Hitachi Information Systems Ltd | 電子データ交換コンピュータ及び電子データ交換プログラム |
JP2011034185A (ja) * | 2009-07-30 | 2011-02-17 | Yoichiro Kojima | Ediサーバコンピュータ及びediシステム |
JP2011034186A (ja) * | 2009-07-30 | 2011-02-17 | Yoichiro Kojima | 生産管理システム |
WO2012023192A1 (ja) * | 2010-08-18 | 2012-02-23 | 前田建設工業株式会社 | 情報処理装置、情報処理方法、プログラム、および媒体 |
JP5512817B2 (ja) * | 2010-08-18 | 2014-06-04 | 前田建設工業株式会社 | 情報処理装置、情報処理方法、プログラム、および媒体 |
JP2012093997A (ja) * | 2010-10-27 | 2012-05-17 | Toshiba Tec Corp | 予約受付装置およびプログラム |
JP2012238301A (ja) * | 2011-04-28 | 2012-12-06 | Yamato Packing Service Co Ltd | 商品発注支援装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7751417B2 (en) | Accelerated system and methods for synchronizing, managing and publishing business information | |
JP6243343B2 (ja) | 電子メールクライアントアプリケーションから企業資源計画機能を提供する技法 | |
US6842749B2 (en) | Method to use the internet for the assembly of parts | |
JP2004178190A (ja) | 受発注システム、プログラムおよび記録媒体 | |
EP3485447A1 (en) | System, device, and method for capturing and managing point of sale transaction related data | |
US20020174148A1 (en) | System and method for formatting international shipping addresses | |
JP2010039955A (ja) | データ交換システム及びデータ交換プログラム | |
CA2647857C (en) | Freight backbone messaging architecture | |
EP1671229B1 (en) | Automatic registration and deregistration of message queues | |
JP2002203096A (ja) | 販売支援システムおよび方法 | |
JP2007179476A (ja) | 電子データ交換システム、電子データ交換方法、および電子データ交換プログラム | |
US20150120355A1 (en) | Mobile terminal management server and mobile terminal management program | |
JP2002092372A (ja) | 受発注処理方法及び受発注処理システム | |
JP7224772B2 (ja) | 試用システム、試用方法、試用処理装置及びそのプログラム | |
US20160104230A1 (en) | Cooperation server, non-transitory computer-readable storage medium storing cooperation program, and ec system | |
JP2001283040A (ja) | 共同利用型商品取引情報処理システム、共同利用型商品取引情報処理方法、記録媒体およびプログラム | |
KR20200102708A (ko) | 전자거래 문서 표준화 방법 | |
JP4234484B2 (ja) | 商品発注装置及びその制御方法、並びに制御プログラム | |
JP2002056064A (ja) | 物流貨物追跡システム | |
JP2021043738A (ja) | データ管理方法およびトレーサビリティユニット | |
KR20210105001A (ko) | 주문 데이터에 특징 정보 태깅을 지원하는 프로그램이 기록된 기록매체 | |
KR20210104997A (ko) | 표준화된 주문 데이터에 대응한 특징 정보 태깅을 지원하는 장치 | |
KR20210104996A (ko) | 표준화된 주문 데이터에 대응한 특징 정보 태깅을 지원하는 장치 및 그 동작 방법 | |
KR20210105000A (ko) | 표준화된 주문 데이터에 대응한 특징 정보 태깅을 지원하는 방법을 컴퓨터에서 실행시키기 위한 프로그램 | |
KR20210104999A (ko) | 표준화된 주문 데이터에 대응한 특징 정보 태깅을 지원하는 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050221 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070806 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070821 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20071218 |