JP2000357202A

JP2000357202A - 注文処理システム及び方法

Info

Publication number: JP2000357202A
Application number: JP2000131491A
Authority: JP
Inventors: Gregory Lee Mckee; グレゴリー・リー・マッキー; Sylvain Michel; シルヴァン・ミシェル; Kountz Penny J Peachey; ペニー・ジャネット・ピーチー・カウンツ; James Donald Scott; ジェームズ・ドナルド・スコット
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1999-04-30
Filing date: 2000-04-28
Publication date: 2000-12-26
Also published as: US20020013731A1; EP1049038A2; EP1049038A3; KR100388343B1; US7606742B2; KR20000071765A

Abstract

(57)【要約】（修正有）【課題】電子データ要求が注文処理システムに送られる
前に、前処理するための統合化されたシステム及び方法
を提供する。【解決手段】電子販売注文（ＥＳＯ）を前処理する注文
インターセプタ２０２と、サードパーティの計画予測エ
ンジン２０４へのインターフェースと、注文処理システ
ム２０９〜２１２に送る前にＥＳＯを訂正できるように
する擬似販売注文ワークベンチ２０６と、ＥＳＯに誤り
が含まれるかＥＳＯを満足できない時にＥＳＯを拒否す
る拒否受信確認システム２０７と、からシステムを構成
する。また、注文インターセプタはビジネスルール２１
０に基いて、さまざまな編集及び監査を実行する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、全般的には電子商
取引要求の前処理に関し、具体的には、電子商取引要求
を、注文処理システムに送る前に変更するための方法お
よびシステムに関する。

【０００２】

【従来の技術】電子データ交換（ＥＤＩ）は、人間の介
入を伴わずに、購入注文書、送り状、出荷通知、試験結
果および他の、２つの商取引パートナ間で頻繁に使用さ
れるビジネス文書をすばやく安価に安全に通信する方法
である。ＥＤＩでは、複数のコンピュータが直接に通信
できるようにすることによって、事務処理と情報の遅延
をなくす。これは、当事者のすべてが、合意を得たＥＤ
Ｉデータ・フォーマットおよび通信規格に従うことによ
って達成される。

【０００３】ＥＤＩ参加の最小要件には、パーソナル・
コンピュータ、ミニコンピュータまたはメインフレーム
などのコンピュータ・システムと、内部業務トランザク
ションとＥＤＩ標準フォーマットの間でマッピングを行
う変換ソフトウェアと、ＥＤＩファイルを送受信し、通
信プロトコルをサポートする通信ソフトウェアと、モデ
ムおよび電話回線などの通信ハードウェアが含まれる。
ＥＤＩは、３つの基本構成要素を有する。第１に、共通
の合意を得たデータ・フォーマットおよび通信規格の組
を定義するＥＤＩ規格が存在しなければならない。第２
に、遠隔通信ハードウェアおよびソフトウェアならびに
一般的な通信プロトコルを含めることのできる、通信情
報配送システムが存在しなければならない。最後に、伝
送の両端の、それがなければ互換性を有しないシステム
またはネットワークによって読み取ることができるフォ
ーマットにデータを変換する変換ソフトウェアが必要で
ある。

【０００４】たとえば、コンピュータ・アプリケーショ
ンは、ファイルにロードされる業務トランザクション
（文書）を作成する。このファイルは、ＥＤＩ変換ソフ
トウェアによって処理されて、ＥＤＩ標準データ・フォ
ーマットにマッピングされる。このＥＤＩレコードは、
通信リンクを介して、所定の業務パートナに通信され
る。この業務パートナまたは商取引パートナは、ＥＤＩ
変換ソフトウェアを介してＥＤＩレコードを処理するこ
とによってＥＤＩレコードを復号し、その情報を内部フ
ァイルにダンプする。このファイルが、商取引パートナ
の業務アプリケーションにロードされる。

【０００５】図１からわかるように、電子データ要求
は、顧客から注文サービス・システムに処理のために直
接に送信される。この手法の短所には、マスタ・デー
タ、制御データおよび構成データのＥＤＩサブシステム
へのデータ複製と、注文サービス埋込み処理規則との非
統合が含まれる。具体的に言うと、従来技術のシステム
では、顧客からのＥＤＩ注文は、図示のように機能ブロ
ック１０１で受信される。機能ブロック１０２では、Ｅ
ＤＩ注文が内部フォーマットに変換される。内部フォー
マットに変換されたデータは、その後、機能ブロック１
０３に示されているように、注文サービス・システムに
ロードされる。判断ブロック１０４では、注文サービス
・システムが、ＥＤＩ注文内の不完全なフィールドまた
は、存在しない製品またはサービスを顧客が要求してい
るかどうかの判定など、誤りについて検査する。誤りが
ない場合には、ＥＤＩ注文は、ビジネス・ルールに従っ
て手動で処理される。たとえば、特定の日付および量に
関する要求がある場合には、ビジネス・ルール１は、要
求された日付および量を満足できる場合に限って応答す
ることになる可能性がある。ルール２は、日付を守り、
使用可能なすべての量をとることになる可能性がある。
ルール３は、要求された元々の部品が注文を満たすのに
十分なだけ存在しない場合に、要求された元々の部品を
異なる部品番号に置換することになる可能性がある。Ｅ
ＤＩ注文に誤りが含まれる場合には、機能ブロック１０
６で、操作員が手動で注文を訂正しなければならない。
たとえば、欠けているフィールドに書き込むか、正しい
顧客住所などの情報を供給することができる。機能ブロ
ック１０７で、ＥＤＩ注文を再発行し、このＥＤＩ注文
は、判断ブロック１０４に示されているように、もう一
度誤りについて検査される。判断ブロック１０４でＥＤ
Ｉ注文に誤りが含まれないと判定されるまで、判断ブロ
ック１０４、機能ブロック１０６および１０７を繰り返
す。

【０００６】複数の特許が、プレゼンテーション、文書
および類事物の前処理に関する。しかし、これらの前処
理システムは、ＥＤＩに直接に適用可能ではなく、ＥＤ
Ｉアプリケーションに関して短所を有する。米国特許第
５５７７２５８号明細書では、対話応答時間に起因する
遅延が実質的に除去されるように、顧客に配送されるマ
ルチメディア・プレゼンテーションを前処理するための
装置および方法が開示されている。しかし、この方法
は、ＥＤＩアプリケーションに直接に適用可能ではな
い。

【０００７】欧州特許第ＥＰ０８６３６７８Ａ
２号明細書では、遠隔通信会社のための自動化サービス
提供のための方法が開示されている。発呼者からのデー
タが検証されて、発呼者が、要求されたサービスの権利
を与えられた既存の顧客であるかどうかが判定される。
要求は、自動化された方法のプロセッサとの互換性を有
するデータに変換される。

【０００８】ＰＣＴ特許第ＷＯ９６／２０９５２号明
細書には、文書に対するロジスティックならびに、遠隔
通信システムの操作員側での加入者識別に基づくシステ
ム・アクセスを有する中央前処理システムが開示されて
いる。文書関連データは、前処理され、格納され、文書
情報の標準化された処理のための規則が設けられる。米
国特許第５５９４９１０号明細書では、分散処理対話型
のネットワークおよび動作の方法が開示されている。こ
の方法では、多数のアプリケーションへのアクセスを多
数のユーザに提供する方法と、データ・アクセスを整形
するための異なる方法が開示されている。米国特許第５
７５２２４６号明細書では、異なるクライアントからの
要求を満たすためのワールド・ワイド・ウェブ・ブラウ
ザと、ＷＷＷ上で情報を要求し、処理し、提示する方法
が開示されている。米国特許第５５１７４０６号明細書
では、ミューチュアル・ファンド取引に値段を付け、拡
張し、取引受信確認がプリプロセッサによって確認され
る、ミューチュアル・ファンド関連データを処理するた
めのツールが開示されている。しかし、これらの特許
は、直接にＥＤＩに適用可能ではなく、ＥＤＩシステム
の特徴または便益の実現をもたらさない。

【０００９】

【発明が解決しようとする課題】したがって、本発明の
目的は、電子データ要求が注文処理システムに送られる
前に、その電子データ要求を前処理するための統合化さ
れたシステムおよび方法を提供することである。

【００１０】本発明のもう１つの目的は、材料が所与の
量および納期に関して使用可能であるかどうかを判定す
る計画予測エンジンを提供するシステムへのインターフ
ェースを提供することである。

【００１１】本発明のもう１つの目的は、電子データ要
求が注文処理システムに送られる前に、その電子データ
要求に対する訂正を行うためのシステムおよび方法を提
供することである。

【００１２】本発明のもう１つの目的は、電子データ要
求内で指定されたある判断基準を満足できない時に、電
子データ要求を拒否し、その結果、その電子データ要求
が注文処理システムに送られないようにするためのシス
テムおよび方法を提供することである。

【００１３】

【課題を解決するための手段】この目的のために、電子
販売注文（ＥＳＯ）を前処理する、コンピュータで実施
された注文インターセプタと、サード・パーティの計画
予測エンジンへのインターフェースと、注文処理システ
ムに送る前にＥＳＯを訂正できるようにする擬似販売注
文ワークベンチと、ＥＳＯに誤りが含まれるかＥＳＯを
満足できない時にＥＳＯを拒否する拒否受信確認システ
ムとを提供することを提案する。

【００１４】したがって、本発明の好ましい実施例で
は、注文サービス用のSAP AG Corporationの販売配送モ
ジュールを使用する電子商取引を使用可能にされた供給
業者が、電子販売注文（ＥＳＯ）プリプロセッサ（たと
えば注文インターセプタ）を使用して、販売注文を注文
処理システムにポストする前に非同期使用可能性検査を
（たとえばインターナショナル・ビジネス・マシーンズ
・コーポレイションによるPROFIT Available to Promis
e（ＡＴＰ）または他の適当なサード・パーティ・ソフ
トウェア・パッケージを使用して）実行することができ
る。ＡＴＰシステムは、所与の量および納期に関して材
料が使用可能であるかどうかを判定する計画予測エンジ
ンである。ＡＴＰ検査の結果は、ＥＳＯに格納され、後
に、注文処理システムに適用される。注文インターセプ
タは、ＥＳＯにＳＡＰマスタ・データおよびＳＡＰ構成
データを補うことによって、ＡＴＰ検査用の前提条件デ
ータを導出する。ＡＴＰ検査の結果は、販売組織、部署
および配送チャネル（販売区域）などの販売注文に関す
る主要な情報を判定するのにも使用される。

【００１５】好ましい実施例では、ＳＡＰ内で同一の販
売区域を共有するように構成されていない異なる配送プ
ラントによって供給される複数の行項目が存在する場合
には、ＥＳＯプリプロセッサが、ＥＳＯを複数の要求に
分割する。この機能がないと、供給業者は、この活動を
手動で実行しなければならない。

【００１６】サード・パーティの使用可能性検査のサポ
ートと、後続のＥＳＯの分割の他に、プリプロセッサ
は、供給業者が要求を管理する方法を構成できるように
する、ビジネス・ルールの堅牢な組を提供する。これら
のビジネス・ルールによって、指定された判断基準が満
足される場合にいくつかの機能を自動化することが可能
になる。たとえば、低い階層の顧客からの新規販売注文
要求は、ポストする前に手動でサービスされるように構
成することができる。高い階層の顧客からの同一の要求
は、要求者が最小注文量レベルに含まれる場合など、あ
る条件の下でのみ手動で再検討されるように構成するこ
とができ、同一条件の別の顧客からの同一の要求を、自
動作業工程のために構成することができる。

【００１７】好ましい実施例では、再検討のために保持
されるＥＳＯは、プリプロセッサのワークベンチ構成要
素を使用することによって、表示し編集することができ
る。ワークベンチは、SAP AG Corporationが供給する汎
用ツールを置換する。ワークベンチは、実際の注文入力
画面と同様の外見、印象および挙動を有する、ＥＳＯの
顧客購入注文ビューを提供する。ＥＳＯを表示するほか
に、ワークベンチは、ＥＳＯが再検討のために保持され
た理由を記述した、プリプロセッサから生成されたメッ
セージを表示する。メッセージが実行される時に、ワー
クベンチは、適当なデータ訂正画面に分岐する。この分
岐は、ＥＳＯ内の特定のセグメント、マスタ・データま
たは構成データへの分岐とすることができる。条件が訂
正された後に、ワークベンチは、ＥＳＯプリプロセッサ
を再実行する。これは、すべてのメッセージが訂正され
るか、再検討済みとマークされるまで継続する。供給業
者は、要求を受け入れるか、要求を拒否するか、個々の
行項目を受け入れるかを決定することができる。

【００１８】最後に、好ましい実施例では、要求が拒否
された場合に、ＥＳＯを注文処理システムにポストせず
に、自動拒否受信確認を生成する。要求が受け入れられ
た場合には、ＥＳＯは、ベンダが供給する販売注文用の
機能モジュールに経路指定され、ＥＳＯは注文処理シス
テムにポストされる。部分的な受入は、アウトバウンド
受信確認処理を介して顧客に通信される。

【００１９】本発明の注文インターセプタには、この種
類の他のプリプロセッサと異なる複数の特徴がある。ま
ず、この注文インターセプタは、ＳＡＰのＩＤＯＣ／Ａ
ＬＥアプリケーション層（図６のモジュール６００、ED
I_DATA_INCOMINGモジュール６０１、ＲＳＥＩＮＢ００
モジュール６０２、IDOC_INPUTモジュール６０４および
IDOC_MANUAL_INPUTモジュール６０８を参照されたい）
によってＥＳＯが作成された後、販売注文ポストの前
に、ＳＡＰのテーブル空間の内部で実施される。この種
類の他のプリプロセッサは、すべて、ＳＡＰのＩＤＯＣ
／ＡＬＥアプリケーション層の外部で実施され、通常
は、ＥＳＯフォーマットのフラット・ファイル上で実施
される。この手法を用いると、ＳＡＰのＩＤＯＣ／ＡＬ
Ｅアプリケーション層に固有の追跡、ログ記録および他
の機能のすべてが失われる。本発明の注文インターセプ
タは、したがって、ＥＳＯデータ・セグメントの追加、
変更および削除を行うことができる。ＥＳＯデータ・セ
グメントの階層は、変更がＥＳＯに適用されるたびに再
判定される。ＥＳＯに対する変更のすべてが、ＥＳＯ状
況セグメントにログ記録され、したがって、活動の完全
な監査記録がもたらされる。ＥＳＯを再構築するプログ
ラムは、個々にパッケージ化され、この形でＥＳＯを操
作する必要を有する他のプリプロセッサによって使用す
ることができる。

【００２０】本発明のもう１つの特徴は、注文インター
セプタが、リモート・サーバ上で走行するサード・パー
ティＡＴＰシステムに対する非同期インターフェースを
サポートすることである。使用可能性検査の結果は、独
自の形で構成されたＥＳＯデータ・セグメントに格納さ
れ、ポスト中に販売注文に適用される。使用可能性検査
を開始する前に、ＥＳＯ注文インターセプタは、ＥＳＯ
を分析して、ＡＴＰコミットが存在するかどうかを調べ
る。見つかった場合には、使用可能性検査が迂回され、
販売注文は、すでにＥＳＯ上にあるＡＰＴコミットと共
にポストされる。さらに、ＥＳＯは、ＡＴＰ検査の結果
に基づいて複数のＥＳＯに分割することができる。いつ
ＥＳＯを分割するかに関するビジネス・ルールは、ＥＳ
Ｏを分割する方法とは別に実施される。

【００２１】第３の特徴は、顧客、論理メッセージ型お
よびメッセージ・コードによって構成されるビジネス・
ルールに基づいて、注文インターセプタが、さまざまな
編集および監査を実行することである。たとえば、本発
明の独自の特徴の１つが、アプリケーションへのポスト
の前に、定義済みの条件が生じる時に手動再検討のため
にＥＳＯを保持するようにシステムを構成することであ
る。これによって、供給業者は、SAP AG Corporationに
よって提供されるものを上回る誤りの検出および訂正を
実行する機会を与えられる。ＥＳＯ注文インターセプタ
は、SAP CorporationのＳＭＯＤおよびＣＭＯＤトラン
ザクションを使用して、顧客に固有の要件についてさま
ざまなユーザ出口を提供する。ＳＭＯＤおよびＣＭＯＤ
トランザクションを用いると、ソフトウェアの基本機能
性に対する機能強化を行うことができる。たとえば、追
加処理ステップを、ソフトウェアの基本機能性に追加す
ることができる。追加処理ステップの後に、基本機能性
に関連する処理が再開される。

【００２２】さらに、注文インターセプタのワークベン
チ構成要素は、供給業者に、ＥＳＯを変更し、注文イン
ターセプタによって識別された必要な誤り訂正を実行す
るためのツールを提供する。このワークベンチは、ＳＡ
Ｐによって供給される汎用ツールを置換する。ワークベ
ンチは、ＥＳＯの独自のビューを提示し、その結果、ユ
ーザは、ＥＳＯの構造および修飾子を知る必要がなくな
る。この画面は、販売前の注文フォーマットで提示さ
れ、したがって、「そうなる予定の」販売注文のプレビ
ューを与える。さらに、ワークベンチは、誤り訂正およ
び分析のためのさまざまなSAP AG Corp.のマスタ・デー
タおよび構成データへの分岐ならびにＥＳＯ編集用のSA
P AG Corp.が供給する汎用ツールへの分岐を提供する。
ワークベンチのもう１つの独自の特徴が、自動拒否機能
である。供給業者は、アプリケーションにポストせず
に、完全にベンダのＩＤＯＣ／ＡＬＥ層内で、要求を拒
否し、受信確認を生成することができる。

【００２３】

【発明の実施の形態】ここで図面、具体的には図２を参
照すると、本発明の原理を実施する注文インターセプタ
・システムが示されている。この注文インターセプタ・
システムには、ＥＳＯが注文処理システム２０９にポス
トされる前に、ＥＳＯを前処理するための注文インター
セプタ２０１が含まれる。注文インターセプタ２０１に
は、顧客の注文データを内部フォーマットに変換するた
めのトランスレータ２０２が含まれる。注文データは、
標準的なフォーマットのＥＤＩ伝送２０３を介して受け
取られる。顧客の注文データを内部フォーマットに変換
した後に、注文インターセプタ２０１は、ビジネス・ル
ール・データベース２１０に格納された顧客固有のビジ
ネス・ルールによるデータの処理を開始する。たとえ
ば、低い階層の顧客からの新規販売注文要求は、ポスト
する前に手動でサービスされるように構成することがで
きる。高い階層の顧客からの同一の要求は、要求者が最
小注文量レベルに含まれる場合など、ある条件の下での
み手動再検討されるように構成することができ、同一条
件の別の顧客からの同一の要求を、自動作業工程のため
に構成することができる。注文インターセプタ２０１
が、ＡＴＰ検査が必要であると判定した場合には、注文
インターセプタ２０１は、ＡＴＰシステム２０４とイン
ターフェースして、データ・トランスレータ２０５から
必要なデータを収集する。ＡＴＰシステム２０４は、所
与の量および納期に関して材料が使用可能であるかどう
かを判定する計画予測エンジンとして働く。

【００２４】注文インターセプタ２０１が、ビジネス・
ルール・データベース２１０に格納されたビジネス・ル
ールのいずれかが失敗する、または、他の処理問題があ
ると判定した場合に、注文インターセプタ２０１は、擬
似販売注文ワークベンチ２０６とインターフェースし、
擬似販売注文ワークベンチ２０６は、訂正を行えるよう
にする。擬似販売注文ワークベンチ２０６は、内部フォ
ーマットでの顧客の注文データに対する手動の再検討、
修正および訂正を可能にする。顧客の注文データは、エ
ンド・ユーザがオンラインで注文処理システム２０９内
で注文を処理しているかのようなフォーマットで提示さ
れる。擬似販売注文ワークベンチ２０６は、フィールド
修正ならびに、顧客の注文の拒否などの機能を可能にす
る。

【００２５】処理で注文の拒否が必要になった場合に
は、注文インターセプタ２０１は、拒否受信確認システ
ム２０７とインターフェースして、その拒否を実行し、
その結果、ＥＳＯ要求が、注文処理システム２０９によ
って処理されないようにする。拒否受信確認システム２
０７は、内部フォーマットの顧客の注文データを受け取
り、顧客の注文が拒否された理由を示す拒否コードを含
む受信確認を作成する。たとえば、注文が拒否される理
由の１つが、顧客の注文を満たし、顧客の値に割り当て
るのに十分な在庫がないことである。拒否コードは、顧
客が理解できるフォーマットで顧客に送り返され、その
結果、顧客は、注文が拒否された理由を知る。拒否受信
確認システムは、既存の注文に対して行われる変更も拒
否することができる。さらに、拒否受信確認システム
は、顧客の予測要求の拒否に使用することもできる。た
とえば、顧客が、ある量の部品を、たとえば４ないし６
箇月で供給できるかどうかを問い合わせる場合がある。
拒否受信確認システム２０７は、やはり拒否コードを作
成し、顧客が理解できるフォーマットで顧客に送り返
し、その結果、顧客は予測が拒否された理由を知る。

【００２６】注文インターセプタ２０１が、上で述べた
ように顧客のデータを前処理した後に、ルータ２０８
が、そのデータを、ＩＢＭ社のＯＥＭＬＳ注文処理シス
テム２１１またはSAP AG Corp.の注文処理システム２１
２などの注文処理システム２０９へ、顧客固有の構成を
解釈することによって経路指定する。たとえば、顧客
が、要求日として自分のドックに部品が配送されるよう
求める要求を有する場合、これをドック日付と呼ぶこと
ができる。出荷日は、顧客が供給業者からの部品の出荷
を求めた時として定義される。もう１つの構成は、輸送
時間に基づくものとすることができ、これは、顧客が、
要求した日またはそれ以前に注文を受け取るように、注
文に対して計算に入れることができる。

【００２７】本発明は、ＡＩＸオペレーティング・シス
テム（ＵＮＩＸ（登録商標）オペレーティング・システ
ムのＩＢＭ社版）を使用する共通の傘の下で走行するＩ
ＢＭＲＳ６０００エンジンを使用し、独立型のＵＮＩ
Ｘワーク・ステーションまたはＷｉｎｄｏｗｓＮＴ
（登録商標）ワーク・ステーションもしくはネットワー
ク内のワークステーションなどの高速コンピュータに接
続されることが好ましい。ＩＢＭ社のＡＳ４００および
ＥＳ９０００コンピュータを含むメインフレームを使用
することもできる。

【００２８】図３に、着信販売注文の前処理に含まれる
主要なステップが示されている。この処理は、注文イン
ターセプタのトランスレータ２０２が標準的なＥＤＩ伝
送２０３を受け取る時に開始される。受取の際に、トラ
ンスレータ２０２は、機能ブロック３０４に示されてい
るように、ＥＤＩ伝送２０３のデータを内部フォーマッ
トに変換する。販売区域および配送プラントなどのフィ
ールドが導出され、インバウンドＥＳＯに追加され、注
文量および出荷日などのフィールドを変更することがで
きる。

【００２９】機能ブロック３０５では、注文インターセ
プタ２０１が、ＥＤＩ伝送２０３に含まれるデータを処
理する。処理中に、注文インターセプタ２０１は、判断
ブロック３０６に示されているように、ＡＴＰ検査が必
要であるかどうかを判定する。ＡＴＰシステム２０４
は、所与の量と納期に関して材料が使用可能であるかど
うかを判定する計画予測エンジンである。判断ブロック
３０６で実行されるテストの結果から、ＡＴＰ検査が必
要であることが示される場合には、注文インターセプタ
２０１は、ＡＴＰシステム２０４とインターフェースす
る。判断ブロック３０８では、ＡＴＰシステム２０４
が、ＥＳＯデータを内部フォーマットに変換する必要が
あるかどうかを判定するためにテストする。そうである
場合には、機能ブロック３０７に示されているように、
ＥＳＯがデータ・トランスレータ２０５によって変換さ
れる。機能ブロック３０７でデータが変換された後また
は、判断ブロック３０６のテストからＡＴＰ処理が不要
であることが示された場合または、判断ブロック３０８
のテストからデータを変換する必要がないことが示され
た場合には、判断ブロック３０９でテストを行って、他
の処理問題が存在するかどうか、または、ビジネス・ル
ール・データベース２１０のビジネス・ルールのいずれ
かが失敗したかどうかを判定する。

【００３０】判断ブロック３０９で、ＥＳＯがビジネス
・ルール・データベース２１０の適用可能なビジネス・
ルールのすべてを満足しないと判定される場合または、
ＥＳＯが不完全か、誤りがあるか、手動再検討が必要な
場合には、注文インターセプタ２０１は、機能ブロック
３１０に示されているように、擬似販売注文ワークベン
チ２０６を使用してワークフロー項目を再検討し、修正
できるように、責任を負う人物のインバスケットから実
行できるワークフロー項目を作成する。

【００３１】擬似販売注文ワークベンチ２０６内では、
判断ブロック３１１でテストを行って、ＥＳＯが拒否さ
れたかどうかを判定する。擬似販売注文ワークベンチ２
０６では、内部フォーマットの顧客注文データに対す
る、手動の再検討、修正および訂正が可能である。顧客
の注文データは、エンド・ユーザがオンラインで注文処
理システム２０９内で注文を処理しているかのようなフ
ォーマットで提示される。これによって、フィールド修
正ならびに、顧客の注文の拒否などの機能が可能にな
る。ＥＳＯを拒否する場合には、機能ブロック３１２に
示されているように、ＥＳＯを注文処理システム２０９
にポストせずに、顧客への受信確認を生成する。ＥＳＯ
が擬似販売注文ワークベンチ２０６によって拒否されな
い場合には、機能ブロック３１３に示されているよう
に、ＥＳＯは、注文処理システム２０９に送られ、アプ
リケーションにポストされる。機能ブロック３１２また
は３１３での適当な処置の後に、終了ブロック３１４に
示されているように、処理が停止する。

【００３２】図４は、擬似販売注文ワークベンチ２０６
の機能流れ図である。ＥＳＯの誤りに遭遇した時には、
ワークフロー項目がSAP Workflow４０２によって作成さ
れる。このワークフロー項目は、責任を負う人物のイン
バスケットに送られる。機能ブロック４０１に示されて
いるように、このワーク項目が実行される時には、ワー
ク・フローが、ステップ４０７によって示されているよ
うにユーザ端末に表示される。ユーザが表示端末４０３
で入力した選択判断条件を満足するＥＳＯを、SAP Work
flow４０２から表示することもできる。ワーク・フロー
・メッセージは、定義済みの条件の下で作成され、処置
のために責任を負う人物に経路指定される。この責任を
負う人物は、自分のSAP Office Inbox（図示せず）から
これらのメッセージを見、実行することができる。メッ
セージが実行される時には、ユーザは、その条件を訂正
するために適当なアプリケーションに分岐する。本発明
の好ましい実施例では、ワークフロー・メッセージは、
注文インターセプタ２０１が、エラーに遭遇するか、Ｅ
ＳＯの手動再検討が必要であると判定する時に作成され
る。ユーザは、表示端末４０３の入力画面を介して選択
判断基準を入力して、機能ブロック４０１に示されてい
るように、選択判断基準を満たすＥＳＯを表示すること
もできる。ＥＳＯは、SAP AG Corp.のＥＳＯテーブルす
なわち、ESOControl４０４、ESO Data４０５およびESO
Status４０６に従って格納される。これらのテーブルに
よってＥＳＯ構造が検証され、制御がＡＬＥに渡され、
ＡＬＥでは、ＥＳＯを処理して、販売注文または購入注
文受信確認などの適当なビジネス・オブジェクトにする
ことができる。エラー・メッセージ・テーブル４１５に
よって、機能ブロック４０８に示されているように、エ
ラー・メッセージが表示される。エラー・メッセージが
表示された後に、ユーザは、機能ブロック４０９に示さ
れているように、擬似販売注文ワークベンチ２０６上で
ＥＳＯに関連する諸フィールドを見ることもできる。ユ
ーザは、機能ブロック４１０に示されているように、Ｅ
ＳＯに対してさまざまな動作を実行することもできる。
その後、判断ブロック４１１でテストを行って、ＥＳＯ
が構成規則および更新に従うかどうかを判定する。ＥＳ
Ｏが、構成規則を満足しない場合には、機能ブロック４
１２に示されているように、擬似販売注文ワークベンチ
にメッセージが送られる。ＥＳＯが、すべての構成規則
および更新を満足する場合には、そのＥＳＯが、ESO Co
ntrol４０４、ESO Data４０５、ESO Status４０６およ
びエラー・メッセージ・テーブル４１５内で更新され
る。処理は、機能ブロック４１４に示されているよう
に、リターンする。ユーザが、表示端末４０３を介して
選択判断基準を指定する場合には、このリターンは、ユ
ーザの表示端末４０３へのリターンになる。SAP Workfl
ow４０２がワーク項目を作成する場合には、このリター
ンは、SAPWorkflow４０２へのリターンになる。

【００３３】図５は、拒否受信確認システム２０７の流
れ図である。拒否受信確認処理は、注文インターセプタ
２０１で拒否されたＥＳＯを受け取り、拒否コードと適
当な値を含む、対応するアウトバウンドＥＳＯを作成す
る。拒否受信確認処理は、販売注文、販売注文変更また
は予測の型を有する着信ＥＳＯを拒否するのに使用する
ことができる。これらの型のうちの１つを有するインバ
ウンドＥＳＯは、そのＥＳＯに対する拒否コードを入力
することによって注文インターセプタ２０１から拒否す
ることができる。機能ブロック５０１に示されているよ
うに、拒否されたインバウンドＥＳＯは、テーブルESO
Control４０４、ESO Data４０５およびESO Status４０
６から読み取られる。判断ブロック５０５で、ＥＳＯを
分析して、それがウェブ注文であるかどうかを判定す
る。そうである場合には、機能ブロック５０６に示され
ているように、ＥＳＯがクローズされ、受信確認は送信
されない。判断ブロック５０５で、注文がウェブからの
ものではないと判定される場合には、顧客構成テーブル
５０８を読み取って、応答のために顧客構成を判定す
る。判断ブロック５０７で、顧客が受信確認にＳＡＰ注
文控え帳の値またはそのＥＳＯに関して顧客が送った元
の値を含めることを要求したかどうかを判定する。顧客
が、元のＥＳＯ値を受信確認で送るように要求した場合
には、機能ブロック５０９に示されているように、ＥＳ
Ｏに関して顧客が送信した元の値を読み取り、使用す
る。顧客が、ＳＡＰ注文控え帳からの値を受信確認で送
るように要求した場合には、機能ブロック５１０に示さ
れているように、ＳＡＰ注文テーブル５１１を読み取
り、これらの値を使用する。機能ブロック５０９または
５１０から受信確認のための適当なデータを得た後に、
ブロック５１２で、拒否されたＥＳＯからの拒否コード
を使用してアウトバウンドＥＳＯ受信確認を作成し、Ｅ
ＳＯ構成テーブル５１３を、受信確認ＥＳＯ番号を用い
て更新する。拒否受信確認システムでは、顧客の注文要
求を注文処理システム２０９に送らずに、それが拒否さ
れた理由を顧客に応答することができる。

【００３４】以下は、請求される発明の実施に使用され
るソフトウェア・モジュールの好ましい実施例の説明で
ある。個々のソフトウェア・モジュールを、個別に異な
る機能性を提供できるように設計、配置することがで
き、それと同時に、ソフトウェア・モジュールの全体的
な組合せによって、請求項に記載された機能性が維持さ
れることは、当業者には明白であろう。

【００３５】ソフトウェア・モジュールが互いにインタ
ーフェースされる方法のブロック図を、図６に示す。一
般に、ＳＡＰで満たされるインバウンド販売注文要求
は、フラット・ファイルとして、ＳＡＰがインストール
されているオペレーティング・システムに経路指定され
る。ＥＳＯを表すフラット・ファイルは、新規注文要求
および変更注文要求の両方についてはＳＡＰの公表され
たＯＲＤＥＲＳ０２ＥＳＯフォーマットであり、スケ
ジューリング合意予測およびジャスト・イン・タイム配
送についてはＤＥＬＦＯＲ０１である。ＯＲＤＥＲＳ０
２フォーマットおよびＤＥＬＦＯＲ０１フォーマット
は、ＥＳＯを含むさまざまなデータ・セグメントからな
る。ＯＲＤＥＲＳ０２のデータ・セグメントの例が、Ｅ
１ＥＤＫ０１（ヘッダ一般データ）、Ｅ１ＥＤＫ１４
（ヘッダ編成データ）、Ｅ１ＥＤＰ０１（項目一般デー
タ）およびＥ１ＥＤＰ２０（項目スケジュール行）であ
る。ＤＥＬＦＯＲ０１のデータ・セグメントの例が、Ｅ
１ＥＤＫ０９（ＪＩＴ供給業者用ヘッダ・データ）、Ｅ
１ＥＤＰ１０（ＪＩＴ供給業者用項目データ）およびＥ
１ＥＤＰ１６（ＪＩＴ供給業者用項目スケジュール）で
ある。通常、これらの要求は、ＥＤＩから発するが、こ
れらの要求は、どのような外部インターフェースからも
発することができる。ＥＳＯは、新規注文および変更注
文についてはＳＡＰのＥＳＯＯＲＤＥＲＳ０２フォー
マットの派生物であり、スケジューリング合意予測およ
びジャスト・イン・タイム（ＪＩＴ）リリースについて
はＤＥＬＦＯＲ０１の派生物である。

【００３６】EDI_DATA_INCOMINGモジュール６０１は、
ＥＳＯを表すフラット・ファイルの処理を開始する標準
ＳＡＰ機能モジュールである。EDI_DATA_INCOMINGモジ
ュール６０１は、ＲＳＥＩＮＢ００モジュール６０２を
呼び出し、処理されるＥＳＯを渡す。

【００３７】ＲＳＥＩＮＢ００モジュール６０２は、ア
プリケーションに無関係にインバウンドＥＳＯを処理す
る、SAP Corp.の標準プログラムである。その主目的
は、ＥＳＯのファイル表現をＳＡＰＥＳＯテーブルで
あるESO Control４０４、ESO Data４０５およびESO Sta
tus４０６にロードし、ＥＳＯ構造を検証し、制御をＡ
ＬＥに渡すことであり、ＡＬＥでは、ＥＳＯを処理し
て、販売注文または購入注文受信確認などの適当なビジ
ネス・オブジェクトにすることができる。処理中にエラ
ーが発生した場合には、ＲＳＥＩＮＢ００モジュール６
０２は、ワークフロー項目を作成し、このワークフロー
項目は、標準ＥＳＯワークベンチ・モジュールであるＩ
ＤＯＣワークベンチ・モジュール６０６を使用して、管
理者が処理することができる。ＡＬＥは、いつどのよう
な形でＥＳＯを処理するかを決定する際の堅牢な構成サ
ポートを提供する。インバウンド販売注文要求の場合、
すべての顧客が、プリプロセッサであるZ_IDOC_INPUT_P
RE_PROCESSモジュール６０３を介して経路指定されるよ
うに構成される。このモジュールは、販売注文としてポ
ストする前にＥＳＯの前処理および後処理を実行する、
一連のローカルに開発されるモジュールのうちの最初の
モジュールである。この処理は、ＳＡＰの処理が呼び出
される前にＥＳＯを操作することによって、ＳＡＰが供
給する機能モジュールIDOC_INPUT_ORDERS/ORDCHG/DELIN
S（図示せず）を補足する。

【００３８】ＲＳＥＩＮＢ００モジュール６０２が、Ｅ
ＳＯを検証し、作成した後に、制御は、ＳＡＰのＩＤＯ
Ｃ／ＡＬＥ層内にあるIDOC_INPUTモジュール６０４に渡
される。モジュール６００、EDI_DATA_INCOMINGモジュ
ール６０１、ＲＳＥＩＮＢ００モジュール６０２、IDOC
_INPUTモジュール６０４およびIDOC_MANUAL_INPUTモジ
ュール６０８が、ＩＤＯＣ／ＡＬＥ層を構成する。ここ
で、構成テーブルを分析して、インバウンドＥＳＯを処
理する方法を決定する。やはり、インバウンド販売注文
要求の場合には、ＡＬＥは、ローカル処理のために、最
初の制御をZ_IDOC_INPUT_PRE_PROCESSモジュール６０３
に渡す。

【００３９】ＲＳＥＩＮＢ００モジュール６０２がＥＳ
Ｏの誤りに遭遇した時には、ワークフロー・モジュール
６０５によってワークフロー項目が作成され、責任を負
う人物のインバスケットに送られる。ワーク項目が実行
される時に、ＩＤＯＣワークベンチ・モジュール６０６
が、ユーザ端末上の表示を生成する。ＥＤＩ管理者は、
エラー・テキストと共にＥＳＯの状況を見て、エラーの
原因を判定することができる。管理者は、ＥＳＯの個々
のデータ・セグメントを訂正し、ＥＳＯの再処理を開始
することができる。ＩＤＯＣワークベンチ・モジュール
６０６は、ＥＤＩ管理者が生データを管理できるように
するが、これは、販売注文を入力する人物のためのもの
ではない。ＥＳＯセグメントの関係を知り、コード修飾
子を理解する必要がある。たとえば、データ・セグメン
トＥ１ＥＤＰＩ９、修飾子「００１」は、顧客材料を表
し、修飾子「００２」は、内部材料を表す。ＩＤＯＣワ
ークベンチ・モジュール６０６は、ローカル処理が処理
しないデータ・エラーを訂正することだけを目的とす
る。たとえば、セグメント階層エラーは、プリプロセッ
サが呼び出される前に検出される。重複したＰＯ番号な
どのすべてのアプリケーション関連エラーは、顧客購入
注文（ＰＯ）ワークベンチ・モジュール６０７で処理さ
れる。

【００４０】ＩＤＯＣワークベンチ・モジュール６０６
に関連するワーク項目が実行される時には、IDOC_MANUA
L_INPUTモジュール６０８が呼び出される。この機能モ
ジュールは、制御をＩＤＯＣワークベンチ・モジュール
６０６に渡し、その結果を処理するために待機する。戻
りコードから、ＥＳＯが処理されたことが示される場合
には、制御がIDOC_INPUTモジュール６０４に渡され、適
当なアプリケーションが、ＡＬＥを介して呼び出され
る。ＥＳＯがアプリケーションによって成功裡に処理さ
れた場合には、IDOC_MANUAL_INPUTモジュール６０８
は、ワーク項目の状況を完了に更新し、それをインバス
ケットから除去できることを示す。ＩＤＯＣワークベン
チ・モジュール６０６から処置が行われない場合には、
ワーク項目は、処理中の状況でインバスケット内にとど
まる。アプリケーション処理中にエラーが発生する場合
には、現在のワーク項目は、完了とマークされ、新しい
ワーク項目が、作動可能の状況で作成され、インバスケ
ット内に表示される。この処理は、ローカル処理と共に
使用されるZ_IDOC_MANUAL_INPUTモジュール６０９およ
びZ_IDOC_INPUTモジュール６１０のモデリングにも使用
される。

【００４１】以下の数が、本明細書のこれ以降に記載の
以下の活動に対応することに留意されたい。８５０ − 新規販売注文８５５ − 販売注文に対する受信確認８６０ − 変更注文８６５ − 変更注文に対する受信確認８３０ − 予測８７０ − 予測に対する応答Ｚ０ − ＥＳＯは注文インターセプタのために保持さ
れているＺ１ − ＥＳＯは前処理の状況であるＺ２ − ＥＳＯは擬似販売注文ワークベンチのために
保持されているＺ３ − ＥＳＯは前処理で拒否されたＺ４ − ＥＳＯはＡＴＰ前の状況であるＺ６ − ＥＳＯはアプリケーションへポストされずに
クローズされたＺ７ − ＥＳＯはポストなしでクローズされ、ＯＥＭ
ＬＳに経路指定された

【００４２】すべてのインバウンド販売注文要求につい
て、ＩＤＯＣ／ＡＬＥ層は、制御をローカルのZ_IDOC_I
NPUT_PRE_PROCESSモジュール６０３に渡すように構成さ
れる。今のところ、Z_IDOC_INPUT_PRE_PROCESSモジュー
ル６０３は、ＯＲＤＥＲＳ０２フォーマットおよびＤＥ
ＬＩＮＳＥＳＯフォーマットを使用する要求をサポー
トする。現在、これには、８５０／８６２新規注文要
求、８６０変更注文要求および８３０／Ｅ予測およびＪ
ＩＴスケジューリング・リリースが含まれる。８５０に
は、契約作成および契約への参照を用いる作成も含まれ
る。

【００４３】Z_IDOC_INPUT_PRE_PROCESSモジュール６０
３は、標準ＳＡＰによってサポートされない、ローカル
の注文前の処理が行われる場所である。ＥＳＯのデータ
は、標準ＳＡＰの編集および監査の上位で監査される。
さらに、特定のユーザに固有の変換が実行される。販売
区域および配送プラントなどのフィールドが、導出さ
れ、インバウンドＥＳＯに追加される。注文量および出
荷日などのフィールドは、たとえば（ｉ）材料販売ビュ
ーで定義された最小注文量まで注文量を切り上げるか、
（ｉｉ）輸送時間を用いて要求日をオフセットするなど
のローカル・ビジネス・ルールに基づいて変更すること
ができる。これらの変換のすべてが、要求がＰＲＯＦＩ
Ｔ／ＡＴＰモジュール６１８に経路指定される前に行わ
れる。

【００４４】ＥＳＯが、不完全であるか、誤りがある
か、手動再検討を必要とする場合には、Z_IDOC_INPUT_P
RE_PROCESSモジュール６０３が、ワークフロー項目を作
成し、このワークフロー項目は、顧客ＰＯワークベンチ
・モジュール６０７を使用することによって、要求を再
検討し、修正するために責任を有する人物のインバスケ
ットから実行することができる。ＥＳＯが拒否される場
合には、アプリケーションに文書をポストせずに、受信
確認が生成され、顧客に返される。ＥＳＯの状況には、
Ｚ３がセットされる。ＥＳＯが、完了とマークされる場
合には、ＥＳＯの状況に、Ｚ６がセットされ、アプリケ
ーションにはポストされない。同様に、ＥＳＯがＯＥＭ
ＬＳ注文処理システム（２１１）に再経路指定される場
合には、ＥＳＯの状況にはＺ７がセットされ、アプリケ
ーションにはポストされない。そうではなくて、ＥＳＯ
が完了し、ユーザによって受け入れられる場合には、そ
の要求は、ＥＳＯの１つまたは複数の材料がＰＲＯＦＩ
Ｔ／ＡＴＰモジュール６１８上にある場合にはまずモジ
ュール６１３に経路指定され、その後、文書をポストす
るためにＡＴＰ後モジュール６１５に経路指定される。

【００４５】ユーザは、自分のOfficeインボックスでワ
ーク項目を実行することによるか、アナライザ・ドリル
・ダウン・レポート・モジュール６１１（trx ZEDU）を
使用することによって、Z_IDOC_INPUT_PRE_PROCESSモジ
ュール６０３が保持するＥＳＯにアクセスすることがで
きる。このモジュールは、配送プラント文書型およびＥ
ＳＯ状況などの検索パラメータを可能にするインボック
ス処理に対するフロントエンドを提供し、ドリルダウン
機能および大量処理機能を有するレポート・フォーマッ
トでＥＳＯを表示する。このリストから、ユーザは、顧
客ＰＯワークベンチ・モジュール６０７、既存販売注文
トランザクションまたはネイティブのＩＤＯＣワークベ
ンチ・モジュール６０６に分岐することができる。この
レポートは、トラフィック・ライト・アイコンを使用す
ることによってＥＳＯの状況の視覚的表現を与え、ＥＳ
ＯがZ_IDOC_INPUT_PRE_PROCESSモジュール６０３によっ
て保持された理由を表示することができる。これは、ど
のＥＳＯを最初に処理するかなどの優先順位をユーザが
決定するのに役立つ可能性がある。さらに、このレポー
トは、要求の種類の変更について、ＥＳＯ上のデータを
既存販売注文のデータと比較するのに使用することもで
きる。

【００４６】Z_IDOC_INPUT_PRE_PROCESSモジュール６０
３が、エラーまたは手動再検討条件を検出した場合に、
ワークフロー・モジュール６０５は、責任を有する人物
のインバスケットから使用可能にされるワークフローを
作成する。ワーク項目が実行された後に、顧客ＰＯワー
クベンチ・モジュール６０７は、ユーザ端末に表示を提
供する。このユーザ・インターフェースは、販売注文を
処理するための未完了ログにならってモデリングされて
いる。初期画面には、要求が保持された理由を識別する
メッセージのリストが、ＥＳＯの制御セグメントおよび
データ・レコード・セグメントからの主要な情報と共に
表示される。ユーザが許可される場合には、リストの各
項目を実行し、適当な画面に移してデータの訂正または
再検討を行うことができる。各訂正の後に、ＥＳＯは、
Z_IDOC_INPUT_PRE_PROCESSモジュール６０３によって再
処理される。メッセージを実行した後に、制御は、主画
面に戻る。メッセージは、その規則に関する編集および
監査のすべてに合格する場合には、リストから削除され
る。要求が、手動再検討のために保持された場合には、
ユーザは、概要画面にナビゲートして、ＳＡＰ販売注文
処理の画面に類似した画面を使用して要求を再検討する
ことができる。これらの画面では、販売区域および配送
プラントなどのいくつかのフィールドを更新することが
できる。しかし、一部のフィールドは、特定のメッセー
ジの実行と共に変更することしかできない。たとえば、
顧客のＰＯ番号は、重複エラーが検出された場合に限っ
て変更可能である。８６０変更注文要求の場合、対応す
る販売注文情報を表示して、注文番号フィールドをドリ
ル・ダウンすることによってユーザによる分析を支援す
ることができる。さらに、アナライザ・ドリル・ダウン
・レポート・モジュール６１１によって提供される、Ｅ
ＳＯ番号に対するドリル・ダウンによって、ネイティブ
ＳＡＰＩＤＯＣワークベンチへの分岐を行うことがで
きる。この時点で、顧客ＰＯワークベンチ・モジュール
６０７では使用可能でなかった可能性があるすべてのＥ
ＳＯセグメントおよびデータへのアクセスが可能であ
る。

【００４７】要求のすべてまたは一部を拒否するために
は、ユーザが、ヘッダまたは行レベルのいずれかで、拒
否理由コードを供給しなければならない。顧客とトラン
ザクション・コードによって構成テーブルを検査して、
部分的な拒否が許容されるかどうかを調べる。すべての
行項目が拒否される場合またはヘッダが拒否される場合
には、要求が顧客ＰＯワークベンチ・モジュール６０７
から解放された後に、８５５／８６５受信確認が生成さ
れる。この場合、要求は、絶対に販売注文システムにポ
ストされない。８５０新規注文について、行項目のいず
れかが受け入れられる場合には、注文全体が、ＳＡＰに
ロードされ、拒否された行項目には、適当な理由コード
を用いて拒否済みとしてフラグが立てられる。受信確認
は、販売注文ポスト処理の一部として送信される。８６
０変更注文の場合、受け入れられた行項目だけが、ＳＡ
Ｐ販売注文処理に渡される。拒否された行項目のすべて
が、その拒否コードと共に、後続処理のために記憶され
る。販売注文変更がポストされた後に、受信確認処理
が、ＩＤＯＣワークベンチ・モジュール６０６で拒否さ
れた行を集め、販売注文の受け入れられた行項目と共に
これらを合併し、その注文に関する１つの受信確認を作
成する。ユーザが要求を解放した後に、その注文は、Z_
IDOC_INPUT_PRE_PROCESSモジュール６０３に経路指定さ
れ、誤りも再検討条件も検出されない場合には、その要
求は、ＰＲＯＦＩＴ／ＡＴＰモジュール６１８に経路指
定され、最終的に、ＳＡＰによって供給される機能モジ
ュール６１６および６１７に経路指定されて、注文がポ
ストされる。

【００４８】ユーザが、顧客ＰＯワークベンチ・モジュ
ール６０７で顧客の要求を拒否する場合には、適当なア
ウトバウンドＥＳＯ受信確認（８５５／８６５／８７
０）が、Z_ACK_REJ_CUST_POモジュール６１２によって
自動的に生成される。ＥＳＯは、ヘッダ・レベルで拒否
することによるか、ＥＳＯのすべての行項目を拒否する
ことによるかのいずれかで拒否することができる。拒否
されたＥＳＯは、絶対に販売注文アプリケーションにポ
ストされない。ＥＳＯの状況には、Ｚ３がセットされ
る。Z_ACK_REJ_CUST_POモジュール６１２は、顧客構成
テーブル５０８に基づいて、顧客に拒否の受信確認を返
す方法を２つサポートする。値が「Ａ」または空白の場
合には、受信確認は、元のＥＳＯと適当な拒否コードか
ら構築される。値が「Ｃ」の場合には、新規注文要求に
ついて、受信確認は、拒否コードなしで、元のＥＳＯか
ら構築され、変更注文要求について、受信確認は、拒否
コードなしで、既存の販売注文を使用して構築される。

【００４９】顧客購入注文ワークベンチに関するワーク
項目が実行される時には、Z_IDOC_MANUAL_INPUTモジュ
ール６０９が呼び出される。このモジュールは、顧客Ｐ
Ｏワークベンチ・モジュール６０７に制御を渡し、その
結果を処理するために待機する。戻りコードから、ＥＳ
Ｏを処理しなければならないことが示される場合には、
制御はZ_IDOC_INPUTモジュール６１０に渡され、このモ
ジュールは、この場合にはプリプロセッサを呼び出す。
ＥＳＯがアプリケーションによって成功裡に処理された
場合には、Z_IDOC_MANUAL_INPUTモジュール６０９は、
ワーク項目の状況を完了に更新して、それをインバスケ
ットから除去できることを示す。顧客ＰＯワークベンチ
・モジュール６０７から処置が行われない場合には、ワ
ーク項目は、処理中の状況でインバスケットにとどま
る。アプリケーション処理中にエラーが発生する場合に
は、現在のワーク項目が、完了とマークされ、新しいワ
ーク項目が、作動可能の状況で作成され、インバスケッ
トに表示される。

【００５０】インバウンド要求が、Z_IDOC_INPUT_PRE_P
ROCESSモジュール６０３および顧客ＰＯワークベンチ・
モジュール６０７によって成功裡にクリアされた後に、
ＥＳＯの材料がＰＲＯＦＩＴ／ＡＴＰモジュール６１８
上にある場合には、モジュール６１３のZ_IDOC_INPUT_P
RE_ATPが呼び出される。ここでは、ＰＲＯＦＩＴ／ＡＴ
Ｐインターフェース・ファイルＺＡＴＰＤＥＭが、ＳＡ
Ｐとサード・パーティＡＴＰシステムの間の通信媒体と
して使用される。たとえば、ＩＢＭ社の場合、サード・
パーティＡＴＰシステムはＰＲＯＦＩＴ／ＡＴＰであ
る。このファイルは、ＰＲＯＦＩＴ／ＡＴＰモジュール
６１８によって管理される。ＰＲＯＦＩＴ／ＡＴＰイン
ターフェース・ファイル内の項目を管理するための規則
は、機能モジュール６１７のＳＡＰＭＶ４５Ａで使用さ
れる規則と同一である。「save document（文書保
存）」ユーザ出口は、ＰＲＯＦＩＴ／ＡＴＰ結果を販売
注文に適用するように変更された。ＰＲＯＦＩＴ／ＡＴ
Ｐモジュール６１８によってすでにコミットされている
要求（９ＢＤからの要求）の場合、ＰＲＯＦＩＴ／ＡＴ
Ｐモジュール６１８を迂回するためにダミー予約が作成
される。この場合、要求は、ＰＲＯＦＩＴ／ＡＴＰモジ
ュール６１８によって完了とみなされ、応答は不要であ
る。この場合、制御は、Z_IDOC_INPUT_PRE_PROCESSモジ
ュール６０３に返され、このモジュールは、直接にＡＴ
Ｐ後処理モジュール６１５を開始する。ＰＲＯＦＩＴ／
ＡＴＰモジュール６１８の処置を必要とする要求は、イ
ンターフェース・テーブルに追加され、ＰＲＯＦＩＴ／
ＡＴＰモジュール６１８に送られる。リンクが活動状態
であり、タイムリーな形で応答している場合には、制御
は、Z_IDOC_INPUT_PRE_PROCESSモジュール６０３に返さ
れ、このモジュールは、ＡＴＰ後モジュール６１５のＡ
ＴＰ後処理を直接に開始する。リンクが応答していない
場合には、Z_IDOC_INPUT_PRE_PROCESSモジュール６０３
は、応答がもはや同期式ではないことを示し、応答の後
にＺＭＯＭ１０３モジュール６１９をトリガするための
モードで、モジュール６１３を再開始する。Ｚ４状況で
ＥＳＯを再開始するＺＭＯＭ１０３モジュール６１９
は、ＥＳＯ処理をＡＴＰ後ステップで再開始する。

【００５１】モジュールZ_FORMAT_ATP_DATA（図示せ
ず）は、ＳＡＰからＰＲＯＦＩＴへのインターフェース
をカプセル化するのに使用される。このモジュールは、
テーブルＺＡＴＰＤＥＭ内の項目を、モジュールZ_PROF
IT_DATA_EXTRACT（図示せず）を介してＰＲＯＦＩＴ／
ＡＴＰモジュール６１８にインターフェースする。

【００５２】モジュールZ_PROFIT_DATA_EXTRACT（図示
せず）は、ＳＡＰからＰＲＯＦＩＴ／ＡＴＰモジュール
６１８に予約要求を渡すのに使用される、リモート関数
である。MQSeriesの使用は、アプリケーションにとって
は透過的である。

【００５３】ＰＲＯＦＩＴ／ＡＴＰモジュール６１８
は、Z_PROFIT_DATA_EXTRACTモジュール（図示せず）に
よって行われた要求をサービスする。ＰＲＯＦＩＴ／Ａ
ＴＰモジュール６１８は、リモート関数呼出しZ_PROFIT
_DATA_LOAD（図示せず）を呼び出すことによって、その
応答を通信する。モジュールZ_PROFIT_DATA_LOAD（図示
せず）は、テーブルＺＡＴＰＤＥＭ内の予約のためのコ
ミット・データを更新するために、ＰＲＯＦＩＴ／ＡＴ
Ｐモジュール６１８からリモートに呼び出される。この
テーブルは、その後、コミット・データをＳＡＰ販売注
文処理に通信するのに使用される。インターフェース・
テーブルが更新された後に、リンクがダウンしている時
または応答が遅い時など、ＰＲＯＦＩＴ／ＡＴＰモジュ
ール６１８への要求を同期モードで実行できない場合に
は、イベントZ_EDI_ATP_START（図示せず）が開始され
る。このイベントによって、ＺＭＯＭ１０３モジュール
６１９が開始され、このモジュールが、処理を再開始す
る。

【００５４】Z_IDOC_INPUT_PRE_PROCESSモジュール６０
３が、顧客および所与の購入注文に関する前の要求が、
受信確認を保留していると判定する場合には、インバウ
ンドＥＳＯの状況に、「Queued for Pre-Processor（プ
リプロセッサ用に待ち行列化）」（Ｚ０）がセットされ
る。この場合の未完了の定義は、前のＥＳＯが販売注文
アプリケーションによってポストされていないか、元の
販売注文が未完了またはなんらかの理由でブロックされ
ていることを意味する。この機能は、trx ZEDIを使用し
て顧客構成テーブル５０８の対応する列を変更すること
によって使用不能にすることができる。ＺＭＯＭ１０１
モジュール６１４は、この状況のＥＳＯを処理するため
に毎時走行する再発生するジョブとしてスケジューリン
グされる。結果のそれぞれが、保留中の受信確認につい
て検査される。要求が、処理のためにクリアされる場合
には、制御は、Z_IDOC_INPUTモジュール６１０に渡さ
れ、このモジュールは、プリプロセッサを呼び出し、Ｅ
ＳＯの状況とワーク項目を管理する。そうでない場合に
は、要求は、ＺＭＯＭ１０１モジュール６１４の次の走
行まで保持される。

【００５５】ＥＳＯに含まれる１つまたは複数の材料
が、ＰＲＯＦＩＴ／ＡＴＰモジュール６１８上にある場
合には、そのＥＳＯを、モジュール６１３からZ_IDOC_I
NPUT_PRE_PROCESSモジュール６０３に経路指定しなけれ
ばならない。リンクがダウンしているか、応答が遅い場
合には、ＥＳＯ状況にＺ４をセットして、ＰＲＯＦＩＴ
／ＡＴＰモジュール６１８からの応答を待っていること
を示す。ＥＳＯに対する処理は、すべての応答がＰＲＯ
ＦＩＴ／ＡＴＰモジュール６１８から受け取られるまで
停止される。応答機能モジュールは、イベントZ_EDI_AT
P_START（図示せず）をトリガし、これによって、ＺＭ
ＯＭ１０３モジュール６１９が開始される。ＺＭＯＭ１
０３モジュール６１９は、状況がＺ４のＥＳＯのすべて
を選択し、インターフェース・テーブルを分析して、Ｅ
ＳＯ上のすべてのスケジュールが応答を有するかどうか
を調べる（０コミットは有効な応答とみなされる）。要
求がすべての応答を有する場合には、制御がZ_IDOC_INP
UTモジュール６１０に渡され、このモジュールは、ＡＴ
Ｐ後モジュール６１５を呼び出して、ＥＳＯをアプリケ
ーションにポストする。そうでない場合には、ＥＳＯ
は、ＺＭＯＭ１０３モジュール６１９の次のトリガまで
Ｚ４状況のままになる。

【００５６】ＥＳＯの処理が延期され、ワークフロー項
目が作成されない場合には、Z_IDOC_INPUTモジュール６
１０を使用して、処理を再始動する。このモジュール
は、ワークフロー・モジュール６０５と共に使用される
Z_IDOC_MANUAL_INPUTモジュール６０９と共に、ＳＡＰ
の対応するモジュールを模倣するローカルＩＤＯＣ／Ａ
ＬＥ層である。ＥＳＯは、現在、２つの場合すなわち、
１）前のＥＳＯが保留中であるか、注文がブロックされ
ているので８６０変更注文を処理できない場合（状況は
Ｚ０になる）か、２）ＰＲＯＦＩＴ／ＡＴＰモジュール
６１８へのリンクがタイムリーな形で応答していない場
合（状況はＺ４になる）に延期される。ＺＭＯＭ１０１
モジュール６１４およびＺＭＯＭ１０３モジュール６１
９は、ＰＲＯＦＩＴ／ＡＴＰモジュール６１８を使用し
て、ＥＳＯの状況に基づいて適当な機能モジュールを呼
び出すことによって、ＥＳＯ処理を再始動する。たとえ
ば、ＥＳＯがＺ４状況の場合にはＡＴＰ後モジュール６
１５が呼び出され、ＥＳＯがＺ０の場合にはZ_IDOC_INP
UT_PRE_PROCESSモジュール６０３が呼び出される。この
機能モジュールは、ワークフロー項目を作成し、適当な
機能モジュールからの結果に基づいてＥＳＯの状況を管
理する責任も負う。

【００５７】Z_IDOC_INPUT_POST_ATPであるＡＴＰ後モ
ジュール６１５は、４つの主要な機能を実行する、すな
わち、１）ＥＳＯで表現される１つまたは複数の材料が
ＰＲＯＦＩＴ／ＡＴＰモジュール６１８上にある場合
に、ＰＲＯＦＩＴ／ＡＴＰモジュール６１８からのコミ
ット情報をＥＳＯに適用し、２）配送プラントなどの主
要なデータがＰＲＯＦＩＴ／ＡＴＰモジュール６１８か
ら変化する場合の手動再検討のため、および、複数の配
送プラントによって供給されるＥＳＯの複数の行項目が
ある場合に、新しい注文要求に関してＥＳＯを複数のＥ
ＳＯに分割するために、ＥＳＯを保持し、３）文書（新
規注文、変更注文、契約、契約への参照およびスケジュ
ーリング合意リリース）をポストするために、適当なＳ
ＡＰが供給する機能モジュールを呼び出し、４）呼出ト
ランザクションの失敗、一般的なクリーンアップなどの
場合に、特殊化されたワーク項目を作成するなど、適当
な機能モジュールからの結果に基づいてポスト処理論理
を実行する。

【００５８】ＳＡＰは、新規販売注文をポストするため
の機能モジュールIDOC_INPUT_ORDERS（図示せず）と、
既存販売注文を変更するための機能モジュールIDOC_INP
UT_ORDCHG（図示せず）と、ＦＤＳおよびＪＩＴスケジ
ューリング・リリースを追加するための機能モジュール
IDOC_INPUT_DELINS（図示せず）を供給する。必要に応
じてローカルに変更できるようにするために、処理の主
要な点でユーザ出口が使用可能である。配送プラント、
配送ブロックおよび固定量インジケータなどの追加デー
タをＢＤＣセッションにロードするために、複数のユー
ザ出口が使用可能にされる。配送スケジュールのため
に、IDOC_INPUT_DELINS（図示せず）は、画面論理と共
に、顧客が予想する値段付け条件ＥＤＩ１をサポート
する。これらの出口では、編集も監査も実行されない。
この種の機能は、このステージの前に、モジュール６１
３によって実行され、顧客ＰＯワークベンチ・モジュー
ル６０７で操作される。

【００５９】機能モジュール６１６のZ_IDOC_INPUT_CON
TRACTは、契約を作成し、機能モジュール６１６のZ_IDO
C_INPUT_REF_CONTRACTは、契約への参照を用いる注文を
作成する。この２つのモジュールは、機能モジュール６
１６のIDOC_INPUT_ORDERSの派生物であり、同一のユー
ザ出口を共用する。必要なフィールドおよび画面フロー
をサポートするために、追加論理が追加された。

【００６０】ＳＡＰが供給する、ユーザ出口を有する機
能モジュールである機能モジュール６１６は、新規販売
注文をポストするためにＳＡＰ機能モジュールIDOC_INP
UT_ORDERSを用い、既存販売注文を変更するためにIDOC_
INPUT_ORDCHGを用い、ＦＤＳおよびＪＩＴスケジューリ
ング・リリースを追加するためにIDOC_INPUT_DELINSを
用いて機能する。必要に応じてローカルに修正できるよ
うにするために、処理の主要な点でユーザ出口が使用可
能である。機能モジュール６１６では、配送プラント、
配送ブロック、固定量インジケータ、追加パートナ、値
段付け基準材料などの追加デーをＢＤＣセッションにロ
ードすることができる。配送スケジュールに関して、ID
OC_INPUT_DELINS（図示せず）が、画面論理と共に顧客
が予想する値段付け条件ＥＤＩ１をサポートする。これ
らの出口では、編集も監査も実行されない。この種の機
能は、このステージの前に、Z_IDOC_INPUT_PRE_PROCESS
モジュール６０３によって実行され、ＩＤＯＣワークベ
ンチ・モジュール６０６で操作される。

【００６１】ＳＡＰは、呼出Ｔｒｘユーザ出口（ＳＡＰ
ＭＶ４５Ａ）モジュールである機能モジュール６１７を
供給して、販売注文、契約およびスケジューリング合意
の作成、変更および表示などの、トランザクションの販
売注文入力セットを管理する。ローカル処理要件に対処
するために、主要な処理ポイントでユーザ出口が使用可
能である。本発明の独自のＡＴＰ要件をサポートするた
めに、出口が変更された。

【００６２】以下は、注文インターセプタが機能を制御
する方法の説明である。

【００６３】ＥＳＯの監査と調整以下の監査および調整は、前提条件が満足される場合
に、ＥＳＯに対して実行される。監査が失敗するか手動
再検討が必要な場合には、そのＥＳＯは、顧客ＰＯワー
クベンチ・モジュール６０７での訂正／再検討のために
保持される。ＥＳＯを処理のためにアプリケーションに
解放する前に、顧客ＰＯワークベンチ・モジュール６０
７で条件を訂正するか、再検討済みとマークしなければ
ならない。データが顧客ＰＯワークベンチ・モジュール
６０７で変更される時には、必ず、注文インターセプタ
・モジュールであるZ_IDOC_INPUT_PRE_PROCESSモジュー
ル６０３が監査を再適用する。このサイクルは、すべて
のメッセージが訂正されるか、再検討済みとマークされ
るまで継続する。

【００６４】これらのイベントのすべてが、ＥＳＯがシ
ステムで作成された後、ＥＳＯがアプリケーションにポ
ストされる前に発生する。

【００６５】これらの監査は、注文インターセプタ・モ
ジュールであるZ_IDOC_INPUT_PRE_PROCESSモジュール６
０３がサポートするすべてのＥＳＯ型に適用される。現
在、これには、ＶＡ０１、ＶＡ０２およびＶＡ４１（販
売注文および契約）トランザクションを使用して処理さ
れる要求のためのＺＯＲＤＥＲＳ２と、トランザクショ
ンＶＡ３２（スケジューリング合意）を使用して処理さ
れる要求のためのＺＤＥＬＦＯＲ２が含まれる。

【００６６】論理メッセージ型検証前提条件監査以下の論理メッセージ型が、注文インターセプタによっ
てサポートされる。・ＯＲＤＥＲＳ新規注文・ＯＲＤＣＨＧ変更注文・ＤＥＬＩＮＳスケジューリング合意擬似販売注文ワークベンチ・メッセージメッセージＺＶ３２７。論理メッセージ型＆とメッセ
ージ・コード＆は、注文インターセプタによってサポー
トされない。ＥＳＯは、ワークベンチで完了とマークさ
れなければならず、アプリケーションにポストすること
はできない。

【００６７】ローカルＥＤＩ構成テーブルの項目の検証前提条件なし監査所与の顧客、ＥＳＯの論理メッセージ型（edidc-mesty
p）およびメッセージ・コード（edidc-mescod）につい
て、項目が顧客構成テーブル５０８に存在しなければな
らない。擬似販売注文ワークベンチ・メッセージメッセージＺＶ２２２。ＺＥＤＩＴＣＦＧが、顧客
＆、論理メッセージ型＆およびメッセージ・コード＆に
ついて構成されていない。ＥＳＯをワークベンチから解
放する前に、trx ZEDI→Configuration（構成）→By Cu
stomer/Msg/Material（顧客／メッセージ／材料によ
る）を使用して、ＺＥＤＩＴＣＦＧ内の対応する項目を
作らなければならない。

【００６８】Ｅ１ＥＤＳ０１サマリ総セグメント検証前提条件Ｅ１ＥＤＳ０１がＥＳＯに設けられる場合に、監査が実
行される。監査ＥＤＩトランスレータからのＥＳＯに設けられた以下の
サマリ・セグメント（Ｅ１ＥＤＳ０１−ＳＵＭＩＤおよ
びＳＵＭＭＥ）が、注文インターセプタによって計算さ
れた合計と一致することを検証する。・００１ＥＳＯ上の行項目の総数・００４ＥＳＯ上の配送スケジュール・セグメントか
らの要求された量の合計・Ｚ０１サマリ・セグメントに含まれない、ＥＳＯ上
のセグメントの総数擬似販売注文ワークベンチ・メッセ
ージメッセージＺＶ３５７。注文インターセプタが、サマ
リ・レベル合計の不一致を検出した。ＥＳＯは、ワーク
ベンチ内で完了とマークされなければならず、アプリケ
ーションにポストすることはできない。

【００６９】ＥＤＰＡＲを使用する外部パートナ項目の
検証前提条件監査は、フィールドＰＡＲＴＮ（ＬＩＦＮＲ）なしでＥ
ＳＯ上にＥ１ＥＤＫＡＩまたはＥ１ＥＤＰＡＩが設けら
れる場合に実行される。監査ＳＡＰ内部顧客番号を判定するために、以下のヘッダ・
レベル・パートナ機能（Ｅ１ＥＤＫＡＩ−ＬＩＦＮＲ）
が、ＥＤＰＡＲテーブルを使用して相互参照される。・ＡＧ販売先・ＬＦ供給業者・ＡＢ荷降ろし地点・ＷＥ出荷先・ＳＰ運送業者・ＲＥ請求先・ＲＧ支払者ＳＡＰ内部顧客番号を判定するために、以下の項目レベ
ル・パートナ機能（Ｅ１ＥＤＰＡ１−ＬＩＦＮＲ）が、
ＳＡＰのＥＤＰＡＲテーブルを使用して相互参照され
る。・ＷＥ出荷先・ＲＥ請求先・ＲＧ支払者擬似販売注文ワークベンチ・メッセージメッセージＺＶ２２６。外部パートナ番号＆が、パー
トナ機能＆に対して無効である。trx VOED→Partner
（パートナ）→Application（アプリケーション）→Con
version（変換）を使用するか、ＥＤＰＡＲに一致する
ようにＥＳＯ上の対応するＬＩＦＮＲフィールドを変更
することによって、ＥＤＰＡＲ内の対応する項目を作成
しなければならない。ＥＳＯをワークベンチから解放す
る前に、このメッセージを訂正しなければならない。

【００７０】既存販売注文の検索前提条件論理メッセージ型ＯＲＤＣＨＧ。以下のフィールドがＥＳＯ内に存在しなければならな
い。・顧客のＰＯ（ＶＢＡＰ−ＢＳＴＮＫ）・省略時注文型（ＶＢＡＰ−ＡＵＡＲＴ）監査可能な候補が、顧客の販売先、ＰＯ番号および省略時注
文型を使用してビューM_VMVAAから選択される。項目が
見つからない場合または複数の項目が見つかった場合に
は、擬似販売注文ワークベンチのためにＥＳＯが保持さ
れる。擬似販売注文ワークベンチ・メッセージメッセージＺＶ２４２。既存の販売注文が、顧客＆、
ＰＯ番号＆および行＆について見つからなかった。Over
view（概要）メニューから、顧客のＰＯ番号を訂正す
る。メッセージＺＶ２９９。顧客のＰＯ＆および行＆
について、複数の販売注文が存在する。エラー・メッセ
ージを処理し、処理のために適当な販売注文を選択す
る。ＥＳＯをワークベンチから解放する前に、一致する
販売注文を決定しなければならない。

【００７１】複数のＥＳＯへの変更ＥＳＯの分割前提条件ＥＳＯは、以下の条件の下で分割される。・論理メッセージ型ＯＲＤＣＨＧ・ＥＳＯ上の複数の行項目・顧客のＰＯおよび行項目が別々の別個の販売注文で見
つかる監査ＥＳＯの行項目ごとに、顧客のＰＯおよび行項目（ＶＢ
ＡＰ−ＰＯＳＥＸ）を使用して、対応する販売注文を見
つける。行項目が、複数の販売注文にまたがる場合に
は、販売注文ごとに１つの複数のＥＳＯにＥＳＯを分割
する。たとえば、行項目１、３、４が販売注文００９０
０１６３２３で見つかり、行項目２、６が販売注文００
９００１６５２４で見つかり、行項目５が販売注文００
９００１６５３５で見つかる場合には、３つのＥＳＯが
作成される。ＥＳＯＡには、行項目１、３、４が含ま
れる。ＥＳＯＢには、行項目２、６が含まれる。ＥＳ
ＯＣには、行項目５が含まれる。新しいＥＳＯのそれぞ
れは、パートナ機能および参照データなどのヘッダ・レ
ベル・セグメントのすべてを、元のＥＳＯから継承す
る。元のＥＳＯは、すべてのＥＳＯが成功裡に作成され
た後に完了（状況Ｚ６−アプリケーションへポストせず
にクローズ）とマークされる。その時点から、新しいＥ
ＳＯが、互いに独立に処理される。この例では、ＥＳＯ
Ａを成功裡にポストすることができるが、ＥＳＯＢ
およびＣは、手動再検討のために保持される。擬似販売注文ワークベンチ・メッセージ既存販売注文の検索を参照されたい。これは、既存販売
注文の検索モジュールの下に含まれる。

【００７２】既存スケジューリング合意の検索前提条件論理メッセージ型ＤＥＬＩＮＳ以下のフィールドが、ＥＳＯに存在しなければならな
い。・顧客の材料番号（ＶＢＡＰ−ＫＤＭＡＴ）・任意選択として、顧客のＰＯ（ＶＢＡＫ−ＢＳＴＮ
Ｋ）監査以下の選択判断基準を使用して、ビューM_VLPMAから可
能な候補が選択される。・ＫＤＭＡＴ顧客の材料番号・ＫＵＮＮＲ販売先・ＫＮＲＥＦ顧客のパートナ（プラント、格納位置）
の記述・ＡＢＬＡＤワイルドカード＋荷降ろし地点・ＡＢＲＶＷワイルドカード＋配送スケジュール使用
ＩＤ・ＫＴＥＸＴワイルドカード＋製品提案に関する検索
用語・ＢＳＴＮＫ顧客ＰＯ番号（Ｔ６６３Ａ−ＢＳＴＮＫ
Ｐ）を使用するために任意選択で構成される項目が見つからない場合、または、複数の項目が見つか
った場合には、ＥＳＯは、擬似販売注文ワークベンチの
ために保持される。擬似販売注文ワークベンチ・メッセージメッセージＺＶ３２８。Ｔ６６１Ｗが、ベンダ＆、プ
ラント＆および荷降ろし地点＆について構成されていな
い。エラー・メッセージを処理し（trx OVA1にリンク
し）、適当な項目を作成し、その結果、内部販売先を決
定できるようにする。メッセージＺＶ３２９。Ｔ６６
３Ａが、販売先＆および荷降ろし地点＆について構成さ
れていない。エラー・メッセージを処理し（trx OVA9に
リンクし）、販売先および荷降ろし地点に関する規則を
構成する。メッセージＺＶ３３０。スケジューリング
合意が見つからない。エラー・メッセージを処理し、選
択判断基準を変更し、その結果、適当なスケジューリン
グ合意を選択できるようにする。メッセージＺＶ３３
１。顧客のＰＯ番号を使用してスケジューリング合意を
見つけることができなかった。エラー・メッセージを処
理し、選択判断基準を変更し、その結果、適当なスケジ
ューリング合意を選択できるようにする。これには、顧
客のＰＯ番号が含まれる。メッセージＺＶ３３２。独
自のスケジューリング合意を決定できなかった。エラー
・メッセージを処理し、リストから適当なスケジューリ
ング合意を選択する。メッセージＺＶ３３４。顧客の
ＰＯを使用して独自のスケジューリング合意を見つける
ことができなかった。エラー・メッセージを処理し、リ
ストから適当なスケジューリング合意を選択する。メッ
セージＺＶ３６１。スケジューリング合意に、同一の
顧客の材料番号に関する複数の行が含まれる。エラー・
メッセージを処理し、適当な行項目を選択する。メッセ
ージＺＶ３６３。ＥＳＯの出荷先が、スケジューリン
グ合意の出荷先と一致しない。エラー・メッセージを処
理し、ＥＳＯの出荷先を変更する。ＥＳＯをワークベン
チから解放する前に、一致するスケジューリング合意お
よび行項目を決定しなければならない。

【００７３】ＥＳＯの必須セグメント（ＯＲＤＥＲＳお
よびＯＲＤＣＨＧ）前提条件ＯＲＤＥＲＳおよびＯＲＤＣＨＧ論理メッセージについ
て監査が実行される。監査以下のＥＳＯセグメントが必要である。・Ｅ１ＥＤＫＡＩ注文ヘッダ・Ｅ１ＥＤＰ０１行項目（１つまたは複数）擬似販売注文ワークベンチ・メッセージメッセージＺＶ２１３。必須セグメント＆がＥＳＯ内
で見つからない。ＥＳＯは、ワークベンチ内で完了とマ
ークされなければならず、アプリケーションにポストす
ることはできない。

【００７４】ＥＳＯの必須セグメント（ＤＥＬＩＮＳ）前提条件ＤＥＬＩＮＳ論理メッセージに関して、監査が実行され
る。監査以下のＥＳＯセグメントが必要である。・Ｅ１ＥＤＫ０９リリース・ヘッダ・Ｅ１ＥＤＰ１０行項目（ＥＳＯごとに１つ）・Ｅ１ＥＤＰ１６スケジュールＪＩＴ／ＦＤＳ行擬似販売注文ワークベンチ・メッセージメッセージＺＶ２１３。必須セグメント＆がＥＳＯ内
でみつからない。ＥＳＯは、ワークベンチ内で完了とマ
ークされなければならず、アプリケーションにポストす
ることはできない。

【００７５】ＥＳＯの必須フィールド（ＯＲＤＥＲＳお
よびＯＲＤＣＨＧ）前提条件ＯＲＤＥＲＳおよびＯＲＤＣＨＧ論理メッセージに関し
て、監査が実行される。監査以下のＥＳＯフィールドが必要である。

【００７６】

【表１】

【００７７】擬似販売注文ワークベンチ・メッセージメッセージＺＶ２４４。必須フィールド＆がＥＳＯで
供給されていない。ＥＳＯは、ワークベンチ内で完了と
マークされなければならず、アプリケーションにポスト
することはできない。メッセージＺＶ３４０。決定的
な材料（＆）がＥＳＯで供給されていない。ＥＳＯは、
ワークベンチ内で完了とマークされなければならず、ア
プリケーションにポストすることはできない。任意選択
として、この顧客およびトランザクションに関するロー
カル構成がＺＥＤＩＴＣＦＧで正しいかどうかを検査す
る。

【００７８】ＥＳＯの必須フィールド（ＤＥＬＩＮＳ）前提条件ＤＥＬＩＮＳ論理メッセージについて、監査が実行され
る。監査以下のＥＳＯフィールドが必要である。

【００７９】

【表２】

【００８０】擬似販売注文ワークベンチ・メッセージメッセージＺＶ２４４。必須フィールド＆がＥＳＯで
供給されていない。ＥＳＯは、ワークベンチ内で完了と
マークされなければならず、アプリケーションにポスト
することはできない。

【００８１】ＥＳＯごとの一意の追跡番号前提条件追跡番号がＥＳＯで与えられる場合には、監査が実行さ
れる。監査追跡番号は、さまざまなシステムにまたがる追跡の目的
で、ＥＤＩトランスレータから、Ｅ１ＥＤＫ０２−ＢＥ
ＬＮＲおよびＱＵＡＬＦ 'Ｚ０２'で生成される。追跡
番号は、ＥＳＯごとに一意でなければならない。追跡番
号は、ＺＥＤＩＡＣＫＲ−ＴＲＡＣＫＮＯに格納され、
長さは３５文字までとすることができる。擬似販売注文ワークベンチ・メッセージメッセージＺＶ３６８。追跡番号がすでにＥＳＯに割
り当てられている。ＥＳＯは、ワークベンチで完了とマ
ークされなければならず、アプリケーションにポストす
ることはできない。

【００８２】シーケンス内の改訂番号前提条件以下の条件の下で監査が実行される。・改訂番号がＥＳＯで与えられる・論理メッセージＯＲＤＣＨＧ・ローカルＥＤＩ構成が、シーケンスの変更を処理する
ように設定されている（ＺＥＤＩＴＣＦＧ−ＺＡＣＫＰ
ＥＮＤ）・顧客のＰＯ番号が与えられる・既存の販売注文が判定される監査改訂番号は、ＥＤＩトランスレータから、Ｅ１ＥＤＫ０
２−ＢＥＬＮＲおよびＱＵＡＬＦ 'Ｚ０１'で供給され
る。その目的は、この機能を要求する顧客のために、シ
ーケンス内の顧客からの処理変更を容易にすることであ
る。最初の申し出では、改訂番号がこの販売文書に関し
て最後に処理された改訂番号より大きいことを検査する
だけである。監査は、商取引パートナの要件を理解する
につれてより堅牢になる。改訂番号は、ＺＥＤＩＡＣＫ
Ｒ−ＲＥＶＩＳＩＯＮに格納され、長さは３５文字まで
とすることができる。擬似販売注文ワークベンチ・メッセージメッセージＺＶ３５８。改訂レベル変更が順序から外
れている。ＥＳＯは、ワークベンチで完了とマークされ
なければならず、アプリケーションにポストすることは
できない。

【００８３】注文型の判定前提条件注文型は、以下の条件の下で判定される。・セグメントＥ１ＥＤＫ１４、ｑｕａｌｆ '０１２'、
フィールドＯＲＧＩＤがＥＳＯで提供され「ない」時の
論理メッセージＯＲＤＥＲＳについて・既存販売文書が見つかった時の論理メッセージＯＲＤ
ＣＨＧおよびＤＥＬＩＮＳについて監査新規販売注文要求の場合、注文型は、ＥＳＯの論理メッ
セージ型（edidc-mestyp）およびメッセージ・コード
（edidc-mescod）に基づいて判定される。メッセージ型
がＯＲＤＥＲＳであり、メッセージ・コードがＢＰＯ
（ブランケットＰＯ）と等しくない場合には、注文型
は、標準注文の「ＯＲ」を省略時値とする。メッセージ
型がＯＲＤＥＲＳであり、メッセージ・コードがＢＰＯ
である場合には、注文型は、契約の「ＺＢＯ」を省略時
値とする。内部材料を判定した後に、ローカルＥＤＩ構
成テーブル／フィールドＺＥＤＩＴＣＦＧ−ＺＯＶＲＡ
ＵＡＲＴから省略時注文型を指定変更することができる
（規則は、材料レベルでのみ適用可能である）。既存の
販売文書に対する変更の場合、注文型は、既存文書から
とられる。たとえば、既存の標準注文に対する変更は、
「ＯＲ」になり、スケジューリング合意（新規リリー
ス）に対する変更は、「ＬＺ」になるなどである。擬似販売注文ワークベンチ・メッセージなし

【００８４】販売区域決定前提条件販売区域は、以下の条件の下で決定される。・以下のセグメントがＥＳＯで提供され「ない」（セグ
メントＥ１ＥＤＫ１４、ＱＵＡＬＦｘｘｘ、フィール
ドＯＲＧＩＤ）時の論理メッセージＯＲＤＥＲＳ販売組織ＱＵＡＬＦ '００８' ・販売チャネルＱＵＡＬＦ '００７' 部署ＱＵＡＬＦ '００６' ・既存の販売文書が見つかった時の論理メッセージＯＲ
ＤＣＨＧおよびＤＥＬＩＮＳ監査新規販売注文要求の場合、販売区域は、テーブルＥＤＳ
ＤＣから決定される。このテーブルのキーは、ＫＵＮＮ
Ｒ（顧客番号）およびＬＩＦＮＲ（ＥＤＩと共に送信さ
れるベンダ番号）である。顧客番号は、販売先番号であ
り、ベンダ番号は、ベンダ側での当方の販売先番号を表
す。ＬＩＦＮＲは、ＥＳＯのＬＦパートナ（Ｅ１ＥＤＫ
ＡＩ−ＰＡＲＴＮ）フィールドからとられる。このフィ
ールドが供給されない場合には、ＬＩＦＮＲは、ＥＳＯ
のＡＧパートナ（Ｅ１ＥＤＫＡＩ−ＬＩＦＮＲ）フィー
ルドからとられる。これらのフィールドをあわせて、販
売区域を決定する。既存の販売文書に対する変更の場
合、販売区域は、既存の文書からとられる。擬似販売注文ワークベンチ・メッセージメッセージＺＶ２３３。顧客＆およびベンダ＆につい
て、省略時販売区域を決定できなかった。エラー・メッ
セージを処理し、trx VOED→Partner→Application→Cu
stomer/Supplier（顧客／供給業者）を使用してＥＤＳ
ＤＣ内の対応する項目を作成するか、Overviewメニュー
から、Header（ヘッダ）→Partnerを選択し、ＥＳＯの
対応するＬＩＦＮＲフィールドを、ＥＤＳＤＣに一致す
るように変更する。ＥＳＯをワークベンチから解放する
前に、メッセージを訂正しなければならない。

【００８５】内部材料の決定前提条件内部材料番号は、以下の条件の下で決定される。・内部材料番号が供給され「ず」、再決定される材料に
ついてローカルＥＤＩ構成のＺＥＤＩＴＣＦＧ−ＺＥＤ
ＩＭＡＴＮＲＦ＝'Ｒ'である・顧客の材料番号が供給される・販売区域が決定される論理メッセージＯＲＤＣＨＧの場合、販売注文が存在し
なければならない（顧客のＰＯ番号を使用する）。ＤＥ
ＬＩＮＳ（スケジューリング合意）の場合、スケジュー
リング合意と行項目の両方を決定しなければならない。監査新規販売注文要求または既存注文の変更（行項目の追加
または、顧客の材料番号が、対応する行項目（顧客の行
番号を使用する）の顧客の材料番号と一致しない場合の
変更）の場合、内部材料は、ＳＡＰが供給する機能モジ
ュールRV_CUSTOMER_MATERIAL_READを使用してCustomer
Info Record（顧客情報レコード）から決定される。顧
客の材料番号が変更されない場合の既存販売文書に対す
る変更の場合、内部材料は、注文上の一致する行項目か
らとられる。擬似販売注文ワークベンチ・メッセージメッセージＺＶ２８９。顧客が行＆でＩＢＭ材料＆を
供給した。手動再検討が必要である。

【００８６】配送プラントの決定前提条件配送プラントは、以下の条件の下で決定される。・配送プラントが供給され「ない」・内部材料が決定される・販売区域が決定される論理メッセージＯＲＤＣＨＧの場合、販売注文が存在し
なければならない（顧客のＰＯ番号を使用する）。ＤＥ
ＬＩＮＳの場合（スケジューリング合意）、スケジュー
リング合意と行項目の両方を決定しなければならない監査新規販売注文要求の場合または、既存注文に対する変更
（行項目追加または、顧客の材料番号が、対応する行項
目（顧客の行番号を使用する）の顧客の材料番号と一致
しない場合の変更）の場合、配送プラントは、材料の販
売ビュー（テーブルＭＶＥＣＥ、フィールドＤＷＥＲ
Ｋ）から決定される。顧客の材料番号が変更されない既
存の販売文書に対する変更の場合、内部材料は、注文上
の一致する行項目からとられる。擬似販売注文ワークベンチ・メッセージメッセージＺＶ２２９。材料＆の販売ビューが見つか
らない。エラー・メッセージを処理し、販売区域または
内部材料を変更し、その結果、材料の販売ビューが存在
するようにする。ＥＳＯをワークベンチから解放する前
に、メッセージを訂正しなければならない。

【００８７】行項目および材料による重複販売注文前提条件監査は、以下の条件の下で実行される。・論理メッセージＯＲＤＥＲＳ・顧客のＰＯ番号が供給される・顧客の行項目が供給される・ローカルＥＤＩ構成が重複注文について検査するよう
に設定されている（ＺＥＤＩＴＣＦＧ−ＺＥＤＩＢＳＴ
ＮＫ）・内部材料番号が決定される監査既存の販売注文は、顧客の販売先、ＰＯ番号および省略
時注文型を使用して、ビューM_VMVAAから選択される。
このビューの項目ごとに、対応する行項目がＶＢＡＰか
ら選択される。ＥＳＯの各行項目が、ＶＢＡＰからの項
目と比較される。一致が見つかる場合には、ＥＳＯは、
擬似販売注文ワークベンチのために保持される。擬似販売注文ワークベンチ・メッセージメッセージＺＶ２４３。顧客のＰＯ＆、行＆および材
料に関する重複販売注文。これが重複要求でない場合に
は、Overviewメニューから顧客のＰＯ、行または材料を
変更する。そうでない場合には、顧客の要求を拒否す
る。

【００８８】要求に関するコンテキストでの行項目およ
び処置コードの検証前提条件監査は、以下の条件の下で実行される。・顧客の行項目が供給される・内部材料番号が論理メッセージＯＲＤＣＨＧおよびＤ
ＥＬＩＮＳから決定される・既存の販売注文が論理メッセージＯＲＤＣＨＧおよび
ＤＥＬＩＮＳについて見つかる監査ＥＳＯの行項目のそれぞれが、一意でなければならな
い。さらに、次のマトリックスを使用して、顧客の要求
に関するコンテキストでの処置コードを検証する。

【００８９】

【表３】

【００９０】監査のいずれかが失敗するか、行項目'０
０３'削除が要求された場合には、ＥＳＯは、擬似販売
注文ワークベンチのために保持される。擬似販売注文ワークベンチ・メッセージメッセージＺＶ２４７。顧客の行＆が要求上で一意で
ない。エラー・メッセージを処理し、顧客によって承認
される場合には、ＥＳＯ上で一意になるように顧客の行
項目を変更する。そうでない場合には、顧客の要求を拒
否する。メッセージＺＶ２４６。顧客の行＆および処
置コード＆が、既存注文に対して有効でない。エラー・
メッセージを処理し、処置コードを有効な定義域に変更
する。メッセージＺＶ２４５。顧客の行＆および処置
コード＆が、新規販売注文に対して有効でない。エラー
・メッセージを処理し、処置コードを'００１'に変更す
るか、顧客の要求を拒否する。メッセージＺＶ２７
５。顧客の行＆および処置コード＆が、既存の販売注文
と矛盾する。エラー・メッセージを処理し、一貫性を有
するように行項目または処置コードを変更するか、顧客
の要求を拒否する。メッセージＺＶ２８３。顧客が行
＆の削除を要求した。手動再検討が必要である。

【００９１】出荷先が新規販売注文要求で供給されるこ
との検証前提条件監査は、以下の条件の下で実行される。・論理メッセージＯＲＤＥＲＳ・要求が、契約への参照（Ｅ１ＥＤＫ０２ '００５'ま
たは'００６'修飾子、フィールドＢＥＬＮＲで供給され
る契約への参照）で「ない」監査出荷先当事者は、顧客によってヘッダ・レベルで供給さ
れなければならない。ヘッダ・レベルのパートナは、Ｅ
ＳＯセグメントＥ１ＥＤＫＡ２、ＰＡＲＶＷ＝'ＷＥ'の
フィールドＰＡＲＴＮまたはＬＩＦＮＲにある。出荷先
が供給されない場合には、ＥＳＯは、擬似販売注文ワー
クベンチのために保持される。擬似販売注文ワークベンチ・メッセージメッセージＺＶ２２６。外部パートナ番号＆が、パー
トナ機能＆について有効でない。エラー・メッセージを
処理し、ＥＤＰＡＲ項目のリストまたはＥＤＰＡＲ保守
への高速機能（trx VOED→Partner→Application→Conv
ersion）から選択する。ＥＳＯをワークベンチから解放
する前に、出荷先を供給しなければならない。

【００９２】販売文書としてのコンテキストでのＥＳＯ
の検証前提条件監査は、以下の条件の下で実行される。・販売区域が決定される・内部材料が決定される・配送プラントが決定される監査この監査によって、キー・データ要素の組合せがこの要
求に関して有効であることが保証される。この性質の、
以下の監査が実行される。・有効な販売区域（ＶＢＡＰ−ＶＫＯＲＧ、ＶＴＷＥ
Ｇ、ＳＰＡＲＴ）がＴＶＴＡに存在する・顧客による有効な販売区域（ＶＢＡＰ−ＶＫＯＲＧ、
ＴＶＴＡ−ＶＴＷＥＧ、ＳＰＡＲＴ）がＫＮＶＶに存在
する・内部材料が、材料マスタＭＡＲＡに存在し、削除用の
フラグを立てられていない・内部材料が、販売ビューＭＶＫＥに存在し、削除用の
フラグを立てられていない・ＳＡＰが供給する機能RV_Material_Status_Checkを使
用する、制限付き材料に関する検査・ＳＡＰが供給する機能'Product_List_Exclusion'を使
用する、排除された／リストされた材料に関する検査・販売区域に関する有効な配送プラント（ＶＢＡＰ−Ｖ
ＫＯＲＧ、ＶＴＷＥＧ）がＴＶＫＷＺに存在する・内部材料が、配送プラントＭＡＲＣに存在し、削除用
のフラグを立てられていない擬似販売注文ワークベンチ・メッセージメッセージＺＶ２２７。無効な販売区域＆＆＆。エラ
ー・メッセージを処理し、有効な販売区域を入力する。
ＥＳＯをワークベンチから解放する前に、販売区域を有
効にしなければならない。メッセージＺＶ３７８。販
売区域＆＆＆が、顧客＆について定義されていない。エ
ラー・メッセージを処理し、顧客に対して有効な販売区
域を入力する。ＥＳＯをワークベンチから解放する前
に、販売区域を訂正しなければならない。メッセージＺ
Ｖ２３４。削除用のフラグを立てられた材料＆が見つ
からない。エラー・メッセージを処理し、材料を変更す
るか、顧客の要求を拒否する。メッセージＺＶ２３
５。材料＆が使用を制限されている。エラー・メッセー
ジを処理し、材料を変更するか、顧客の要求を拒否す
る。メッセージＺＶ２８８。材料＆が排除されてい
る。エラー・メッセージを処理し、材料を変更するか、
顧客の要求を拒否する。メッセージＺＶ２８９。材料
＆がリストされておらず、したがって、許可されない。
エラー・メッセージを処理し、材料を変更するか、顧客
の要求を拒否する。メッセージＺＶ２３１。配送プラ
ント＆が、販売区域＆＆について有効でない。エラー・
メッセージを処理し、配送プラント、販売区域または材
料を変更するか、顧客の要求を拒否する。

【００９３】輸送時間を用いる顧客のドック日付の調整前提条件オフセットは、以下の条件の下で実行される。・ＥＳＯに対するＰＲＯＦＩＴ／ＡＴＰコミットなし
（コミットの存在は、ＥＳＯがＯＥＭＬＳインターフェ
ース論理メッセージＯＲＤＥＲＳおよびコード９ＢＤか
らのものであることを暗示する）・顧客の行項目が供給される・ローカルＥＤＩ構成が、顧客のドック日付に設定され
ている（ＺＥＤ１ＴＣＦＧ−ＺＥＤＩＤＡＴＱＡＬ＝'
Ｄ'）・内部材料番号が決定される・配送プラントが決定される・出荷先が決定される第１に、ＥＳＯの行レベルから（Ｅ１ＥＤＰＡ１）第２に、ＥＳＯのヘッダ・レベルから（Ｅ１ＥＤＫＡ
Ｉ）第３に、論理メッセージＯＲＤＣＨＧまたはＤＥＬＩＮ
Ｓの場合に、販売文書から監査顧客の要求ドック日付は、出荷先、配送プラントおよび
材料に関する輸送時間だけオフセットされる。輸送時間
の日数は、trx ZEDI→MasterData（マスタ・データ）→
Transit Time Data（輸送日数）を使用して維持され
る。輸送時間は、次のレベルで維持することができる
（この順序で決定することができる）。配送プラント、材料、出荷先配送プラント、出荷先配送プラントＥＳＯの要求日付のそれぞれが、輸送時間オフセットを
用いて調整される。ＳＡＰの要求日付は、必ずＩＢＭ出
荷日付を表す。

【００９４】最小注文量（ＭＯＱ）および出荷パック量
（ＳＰＱ）の調整前提条件調整は、以下の条件の下で実行される。・販売区域が決定される・内部材料が決定される・行項目処置コードが'００３'（削除）「ではない」・オープンＪＩＴスケジュールの繰上がＭＯＱ／ＳＰＱ
検査の対象「ではない」時に注文インターセプタによっ
てスケジュール行がＥＳＯに追加される監査ＭＯＱおよびＳＰＱ検査が実行される前に、行項目レベ
ルの要求量が、すべての配送スケジュール量の合計と一
致するように調整される。材料の最小注文量および出荷
パック量は、それぞれ販売ビューＭＶＫＥ、フィールド
ＡＵＭＮＧおよびＳＣＭＧに保持される。ＭＯＱ検査
は、材料レベルで実行される（同一材料に関する行項目
が合計される）。要求がＭＯＱから外れる場合には、ロ
ーカルＥＤＩ構成テーブルＺＥＤＩＴＣＦＧ−ＭＯＱか
らの以下の定義域値によって、量を調整する方法が決定
される。この規則は、材料レベルまで構成することがで
きる。

【００９５】

【表４】

【００９６】ＳＰＱ検査は、スケジュール行ごとに実行
される。要求が、ＳＰＱから外れる場合には、ローカル
ＥＤＩ構成テーブルＺＥＤＩＴＣＦＧ−ＳＰＱからの以
下の定義域値によって、量を調節する方法が決定され
る。この規則は、材料レベルまで構成することができ
る。

【００９７】

【表５】

【００９８】擬似販売注文ワークベンチ・メッセージメッセージＺＶ２３２。要求された量は、行＆とスケ
ジュール＆についてＳＰＱから外れている。警告メッセ
ージを処理し、要求量をＳＰＱ内になるように変更する
か、そのまま受け入れる。メッセージＺＶ２３０。要
求された量は、行＆についてＭＯＱから外れている。警
告メッセージを処理し、要求量をＭＯＱ内になるように
変更するか、そのまま受け入れる。

【００９９】注文型に固有の監査前提条件なし監査以下の監査が、ラッシュ注文（ＳＯ注文型）に対して実
行される。・ローカルＥＤＩ構成ＺＥＤＩＴＣＦＧ−ＺＥＤＩＲＥ
ＦＢＰＯに真がセットされ、契約への参照が供給されな
い（Ｅ１ＥＤＫ０２、修飾子'００５'または'００６'、
フィールドＢＥＬＮＲ）場合、手動再検討が必要であ
る。・要求日付＜システム日付の場合、手動再検討が必要で
ある。擬似販売注文ワークベンチ・メッセージメッセージＺＶ３６６。ラッシュ注文は、契約への参
照を必要とする。手動再検討が必要である。メッセージ
ＺＶ３９２。要求日付が過去である。手動再検討が必
要である。

【０１００】販売文書が前のＥＳＯからのＡＴＰパイプ
ライン内に「ない」ことの検証前提条件監査は、以下の条件の下で実行される。・論理メッセージＯＲＤＣＨＧまたはＤＥＬＩＮＳ・既存の販売注文が見つかる監査要求が、既存の販売文書の変更である場合には、販売文
書がＰＲＯＦＩＴ／ＡＴＰによって処理されつつあるか
どうかを調べるために検査を行う（前のＥＳＯからのＡ
ＴＰ結果は注文に適用されない）。ＥＳＯ−ＡＴＰ顧客
注文テーブルＺＡＴＰＧＥＮが、この監査に使用され
る。項目が見つかる場合には、ＥＳＯは、擬似販売注文
ワークベンチのために保持される。擬似販売注文ワークベンチ・メッセージメッセージＺＶ３８１。＆は、ＰＲＯＦＩＴ／ＡＴＰ
（ＥＳＯ＆）によって処理されつつある。後で再試行
する。

【０１０１】変更注文に関する論理メッセージ・コード
の検証前提条件監査は、以下の条件の下で実行される。・論理メッセージＯＲＤＣＨＧ監査以下の論理メッセージ・コードは、注文インターセプタ
によってサポートされない。・契約に対するＢＰＯ変更擬似販売注文ワークベンチ・メッセージメッセージＺＶ３８２。契約に対する変更はサポート
されない。ＥＳＯは、ワークベンチで完了とマークされ
なければならず、アプリケーションにポストすることは
できない。

【０１０２】変更が凍結ゾーン期間内であるかどうかの
検証前提条件監査は、以下の条件の下で実行される。・論理メッセージＯＲＤＣＨＧ・既存の販売注文が見つかる・行項目処置コードから変更または削除が示される監査顧客が、日付、量または材料のいずれかに対する変更を
要求する場合、手動再検討が必要になる。変更が、材料
の凍結ゾーン期間内に発生する場合には、手動再検討メ
ッセージによって、この条件も注記される。注文がコミ
ットされる場合には、要求日付および量は、注文のコミ
ット日付および量と比較される。そうでない場合には、
要求日付および量は、注文の要求日付および量と比較さ
れる。材料の凍結ゾーン日数は、ローカルＥＤＩ構成テ
ーブルＺＥＤＩＴＣＦＧ−ＺＦＲＯＺＯＮＥで定義され
る。材料が構成されていない場合には、凍結ゾーンは、
顧客／論理メッセージ・レベルからとられる。変更は、
要求日付＜（システム日付＋凍結ゾーン日数）の場合に
凍結ゾーン内とみなされる。擬似販売注文ワークベンチ・メッセージメッセージＺＶ３４３。＆および顧客の行項目＆に関
する凍結ゾーン内の変更を再検討する。手動再検討が必
要である。メッセージＺＶ３５１。＆および顧客の行
項目＆に関する変更を再検討する。手動再検討が必要で
ある。

【０１０３】販売注文の変更への出荷の適用前提条件監査は、以下の条件の下で実行される。・論理メッセージＯＲＤＣＨＧ・既存の販売注文が見つかる・行項目処置コードが変更を示す監査出荷は、ＥＳＯのセグメントＥ１ＥＤＰ２０、フィール
ドＡＭＥＮＧに適用され、その後、ワークベンチでの表
示に使用可能になる。さらに、要求量と出荷量の間のデ
ルタが、コミットのためにＰＲＯＦＩＴ／ＡＴＰに送ら
れる（要求量は送られない）。スケジュール行の出荷量
は、テーブルＶＢＥＰ−ＷＭＥＮＧからＶＢＢＥ−ＯＭ
ＥＮＧを減ずることによって導出される（要求量−オー
プン量＝出荷量）。以下の監査も実行される。・スケジュール行がまだオープンされている・ＥＳＯからの要求量＞出荷された量擬似販売注文ワークベンチ・メッセージメッセージＺＶ３８０。スケジュール行がもはやオー
プンされていない。ＥＳＯは、ワークベンチで完了とマ
ークされなければならず、アプリケーションにポストす
ることはできない。メッセージＺＶ３７７。項目＆：
要求量＆が、配送量＆より少ない。ＥＳＯは、ワークベ
ンチで完了とマークされなければならず、アプリケーシ
ョンにポストすることはできない。メッセージＺＶ２
７７。顧客の行項目＆は出荷済みである。要求は、手動
で適用しなければならない（注文インターセプタは、複
数の要求日を有する出荷消費論理をサポートしない）。
ＥＳＯは、ワークベンチで完了とマークされなければな
らず、アプリケーションにポストすることはできない。

【０１０４】契約への参照を用いる販売注文の作成に固
有の監査前提条件監査は、以下の条件の下で実行される。・論理メッセージＯＲＤＥＲＳ・ＥＳＯで契約への参照が供給される（修飾子'００５'
または'００６'を有するＥ１ＥＤＫ０２のフィールドＢ
ＥＬＮ）監査以下の監査は、契約への参照を用いる販売注文を作成す
る時に実行される。・契約への参照が供給される（修飾子'００６'）場合に
は、契約が存在しなければならない・契約への参照が供給されない場合には、ビューM_VMVA
Aを使用して、参照される契約ＰＯ（修飾子'００５'）
から契約を決定する・出荷先は、ＥＳＯで供給されない場合には、参照され
る契約からとられる・ＥＳＯで出荷先が供給される場合には、出荷先は、参
照される契約の出荷先と一致しなければならない・ＥＳＯのすべての材料が、参照される契約にリストさ
れる・要求量＋以前の引出（ＶＢＦＡ−ＲＦＭＮＧ販売文書
フローを使用する）が、契約のオープン量を越える場合
には、手動再検討が必要である擬似販売注文ワークベンチ・メッセージメッセージＺＶ３６４。顧客の契約ＰＯを使用して、
契約が見つからない。エラー・メッセージを処理し、参
照されるＰＯを訂正するか、顧客の要求を拒否する。メ
ッセージＺＶ３６５。顧客の契約ＰＯを使用して、一
意の契約を決定できない。エラー・メッセージを処理
し、参照されるＰＯに一致する契約のリストから契約を
選択する。メッセージＺＶ３４７。参照契約＆が、顧
客＆について見つからない。エラー・メッセージを処理
し、参照される契約を訂正するか、顧客の要求を拒否す
る。メッセージＺＶ３４８。材料＆が、参照される契
約で見つからない。エラー・メッセージを処理し、材料
番号を変更するか、顧客の要求を拒否する。メッセージ
ＺＶ３７１。ＥＳＯの出荷先が、参照される契約の出
荷先と一致しない。エラー・メッセージを処理し、ＥＳ
Ｏの出荷先を変更するか、顧客の要求を拒否する。メッ
セージＺＶ３６７。要求量が、契約のオープン量を超
えている。手動再検討が必要である。

【０１０５】契約作成に固有の監査前提条件監査は、以下の条件の下で実行される。・論理メッセージＯＲＤＥＲＳおよびコードＢＰＯ・内部材料が決定される監査以下の監査は、契約を作成する時に実行される。・同一の材料は、契約に１回しか記載できない（重複な
し）擬似販売注文ワークベンチ・メッセージメッセージＺＶ３８３。材料＆が、契約要求で一意で
ない。

【０１０６】スケジューリング合意リリース作成に固有
の監査前提条件監査は、以下の条件の下で実行される。・論理メッセージＤＥＬＩＮＳ・既存のスケジューリング合意が見つかる・スケジューリング合意の行項目が決定される・日付がドック日付から出荷日付に変換される（「輸送
時間を用いる顧客のドック日付の調整」を参照）監査下記のフィールドが供給されない場合には、下記のフィ
ールドがＥＳＯに追加される。

【０１０７】

【表６】

【０１０８】リリースがＪＩＴ（Ｅ１ＥＤＰ１０−ＳＣ
ＲＥＬ＝'０２'）の場合、以下の追加監査が実行され
る。・ＦＤＳ（予測配送スケジュール）が、テーブルＶＢＬ
ＢのＡＢＡＲＴ＝'１'、ＡＢＲＬＩ＝Ｏに存在すること
を検証する・モードが付加（Ｅ１ＥＤＰ１０−ＬＡＢＫＹ＝'１'）
の場合、すべてのオープン配送スケジュールが、繰り上
げられ、ＥＳＯ（セグメントＥ１ＥＤＰ１６）に配送ス
ケジュールとして付加される。この監査は、１回だけ実
行される。オープン・スケジュールは、テーブルＶＢＥ
ＰとＶＢＢＥを比較することによって決定される。スケ
ジュールがまだオープンされている（項目がＶＢＢＥ
の）場合、配送スケジュールは繰り上げられる。さら
に、配送スケジュールに対する出荷のすべても、ＥＳＯ
（Ｅ１ＥＤＰ１６−ＦＺＡＢＲ）に適用され、その後、
ワークベンチでの表示に使用可能になる。要求量と出荷
量の間のデルタが、コミットのためにＰＲＯＦＩＴ／Ａ
ＴＰに送られる。配送スケジュールに関する出荷量は、
ＶＢＥＰ−ＷＭＥＮＧからＶＢＢＥ−ＯＭＥＮＧを減ず
ることによって導出される。ＥＳＯの下記のフィールド
が、再決定される。

【０１０９】

【表７】

【０１１０】最後に、有効期間（有効開始日／終了日）
が、スケジューリング合意の有効期間（ＶＢＡＫ−ＧＵ
ＥＢＧ有効開始日およびＶＢＡＫ−ＧＵＥＥＮ有効終了
日）と比較される。これらの日付のいずれかが、範囲か
ら外れている場合には、手動再検討が必要である。擬似販売注文ワークベンチ・メッセージメッセージＺＶ３７２。配送スケジュールがＥＳＯで
供給されなかった。顧客の要求を拒否する。メッセージ
ＺＶ３６９。有効開始日が、スケジューリング合意の
有効期間外である。手動再検討が必要である。メッセー
ジＺＶ３７０。有効終了日が、スケジューリング合意
の有効期間外である。手動再検討が必要である。

【０１１１】手動再検討用に構成されているかどうかの
検査前提条件監査は、以下の条件の下で実行される。ローカルＥＤＩ
構成が、手動再検討にセットされている（ＺＥＤＩＴＣ
ＦＧ−ＺＭＡＮＲＥＶＩＥＷ＝'１'または'３'）監査ローカルＥＤＩ構成フィールドＺＥＤＩＴＣＦＧ−ＺＭ
ＡＮＲＥＶＩＷによって、ＥＳＯが手動再検討のために
擬似販売注文ワークベンチに保持されているかどうかが
判定される。この規則は、材料レベルまで構成すること
ができる。定義域は次の通りである。・' ' 手動再検討は不要である・'１' 擬似販売注文ワークベンチのために保持されて
いる・'２' 販売注文と受信確認の提示とがブロックされて
いる・'３' 擬似販売注文ワークベンチのために保持され、
販売注文と受信確認の提示とがブロックされている擬似販売注文ワークベンチ・メッセージメッセージＺＶ２２５。手動再検討が必要である。

【０１１２】ＥＳＯに対する更新の適用前提条件ＥＳＯは、注文インターセプタによって更新が行われる
場合に更新される。監査注文インターセプタは、ＥＳＯにさかのぼる更新が必要
なフィールドおよびセグメントの内部テーブルを維持す
る。これには、新規セグメント、既存セグメントに対す
る変更または削除が含まれる。更新は、すべての監査が
実行された後に、擬似販売注文ワークベンチ、ＡＴＰ前
処理またはＡＴＰ後処理などの後続処理にＥＳＯが渡さ
れる前に、テーブルESO Data（４０５）内のＥＳＯデー
タ・セグメントに適用される。更新を適用する前に、元
のＥＳＯが、状況'７０'を有する新規ＥＳＯにコピーさ
れる。ＥＳＯに対する変更は、状況セグメントESO Stat
us（４０６）に、'６９'の状況と共に記録される。これ
によって、販売区域、内部材料または配送プラントが追
加された場合など、注文インターセプタによって行われ
る変更の完全な監査記録が与えられる。テーブルＥＤＳ
ＹＮは、更新処理中に、ＥＳＯの正しい構文を保証する
ために使用される。機能モジュールZ_IDOC_Update_Data
_Resequenceが、実際のテーブル更新の実行に使用され
る。

【０１１３】擬似販売注文ワークベンチのためのＥＳＯ
の保持前提条件ＥＳＯは、以下の条件の下で擬似販売注文ワークベンチ
に保持される。・監査が失敗するか、手動再検討が必要になる・ヘッダが拒否「されない」（拒否された場合には、す
でにワークベンチ内にあり、リリースの準備ができてい
る）・すべての行項目が、拒否「されない」（拒否された場
合には、すでにワークベンチ内にあり、リリースの準備
ができている）・入力モードが、擬似販売注文ワークベンチから（すで
にワークベンチに保持されていることを暗示する）「で
はない」監査監査が実行される前に、注文インターセプタは、所与の
ＥＳＯに関して擬似販売注文ワークベンチ内で再検討さ
れたすべてのエラー・メッセージの内部テーブルを構築
する。メッセージは、注文インターセプタによって、テ
ーブルＺＥＤＩＷＭＳＧを介して擬似販売注文ワークベ
ンチに通信される。手動再検討（訂正ではなく）を必要
とするメッセージは、適当な処置が講じられる時に、擬
似販売注文ワークベンチによって再検討済みとしてフラ
グを立てられる。注文インターセプタは、すべてのエラ
ー・メッセージおよび手動再検討メッセージを内部テー
ブルに記録し、この内部テーブルは、ＥＳＯを擬似販売
注文ワークベンチのために保持しなければならないかど
うかを調べるために分析される。注文インターセプタが
所有する通信テーブルＺＥＤＩＷＭＳＧのすべての項目
（一部のメッセージは、ＡＴＰ後プロセスおよび呼出ト
ランザクション・プロセスによっても所有される）は、
削除され、内部テーブルから再構築される。項目がＺＥ
ＤＩＷＭＳＧに追加される際に、「再検討済み」内部テ
ーブルが、相互参照され、一致が見つかった場合には、
そのメッセージは、すでに再検討済みとしてフラグを立
てられる。この技法を使用することによって、注文イン
ターセプタは、どのメッセージがユーザによって再検討
されたかを常に記憶する。ヘッダが拒否された場合に
は、メッセージはワークベンチに記録されない。同様
に、行項目に固有のメッセージは、その行項目が拒否さ
れた場合には記録されない。この形で、ユーザは、エラ
ー状態がまだ存在する（ヘッダまたは行レベルの拒否が
必要である）場合であってもＥＳＯを解放することがで
きる。ＺＥＤＩＷＭＳＧに追加される各項目は、メッセ
ージがまだ再検討されていない場合に、'Ｚ１'の状況
（注文インターセプタからのメッセージ）と共にＥＳＯ
の状況テーブルESO Status（４０６）にも追加される。
ＥＳＯの状況には、その後（すでに'Ｚ２'になっていな
ければ）、擬似販売注文ワークベンチのために保持され
ていることを示す'Ｚ２'がセットされる。入力モード
が、擬似販売注文ワークベンチから（ワーク項目がすで
に存在することを意味する）でない場合には、擬似販売
注文ワークベンチ・ワーク項目が、機能モジュール'Z_W
orktlow_Error_Create'を使用して作成される。ワーク
項目テキストは、注文型、注文処置、配送プラント、内
部材料、擬似販売注文および顧客名からなる。

【０１１４】アプリケーションへのポストなしの、ＥＳ
Ｏの拒否および受信確認前提条件ＥＳＯは、以下の条件の下で拒否され、受信確認され
る。・ヘッダが擬似販売注文ワークベンチで拒否された（セ
グメントＺＩＥＤＫ０１、フィールドＺＲＥＪＣＯＤＥ
が空白でない）・すべての行項目が、擬似販売注文ワークベンチで拒否
された（セグメントＥ１ＥＤＰ０１、フィールドＡＢＧ
ＲＵが空白でない）・入力モードが、擬似販売注文ワークベンチから（すで
にワークベンチに保持されていることを意味する）「で
はない」監査ヘッダが拒否された場合またはすべての行項目が擬似販
売注文ワークベンチから拒否された場合には、アウトバ
ウンド受信確認ＥＳＯが、機能モジュール'Z_ACK_REJ_P
O'を使用して作成される。このＥＳＯには、顧客の元の
要求が、理由コードおよびその要求が拒否された理由の
記述と共に含まれる。インバウンドＥＳＯは、完了とマ
ークされ（状況に'Ｚ６'がセットされる）、アプリケー
ションにはポストされない。擬似販売注文ワークベンチ・メッセージ 'Z_ACK_REJ_PO'からのエラー・メッセージが、擬似販売
注文ワークベンチのために記録される。

【０１１５】ＡＴＰ前処理前提条件ＥＳＯは、以下の条件の下でＡＴＰ前（機能モジュー
ル'Z_IDOC_INPUT_PRE_ATP'）に送られる。・ＥＳＯに関するエラー・メッセージも手動再検討メッ
セージ（再検討されていない）も存在しない・ＥＳＯが、拒否されず、完了とマークされず、ＯＥＭ
ＬＳ（１１１）に経路指定されていない・入力方法が、顧客ＰＯワークベンチ・モジュール（６
０７）からではない・注文型がテーブルＺＡＴＰＯで定義されている注：
材料がＡＴＰ部品であるかどうかを調べる検査は行われ
ない監査以下の機能が、要求をZ_IDOC_INPUT_PRE_ATPに送る前に
実行される。・論理メッセージがＤＥＬＩＮＳ（スケジューリング合
意）であり、要求がＪＩＴリリースである場合には、オ
ープンＦＤＳが、ＡＴＰに渡される配送スケジュール内
部テーブルに追加される。同様に、要求がＦＤＳリリー
スである場合には、オープンＪＩＴが、配送スケジュー
ル内部テーブルに追加される。これらのスケジュール
は、ＥＳＯに適用されないことに注目されたい。注：ＰＲＯＦＩＴ／ＡＴＰは、そのＡＴＰ論理を実行す
るためにＦＤＳスケジュールとＪＩＴスケジュールの両
方を必要とする。以下の構造体および内部テーブルは、その後、ＥＳＯお
よび既存の販売注文から構成される。・ＥＳＯ上のヘッダ・データを表すヘッダ構造体ＸＶＢ
ＡＫ・既存の注文上のヘッダ・データを表すヘッダ構造体Ｙ
ＶＢＡＫ・ＥＳＯ上の行項目を表す行項目テーブルＸＶＢＡＰ・既存の注文上の行項目を表す行項目テーブルＹＶＢＡ
Ｐ・ＥＳＯ上の配送を表す配送スケジュール・テーブルＸ
ＶＢＥＰ・既存の注文上の配送を表す配送スケジュール・テーブ
ルＹＶＢＥＰ・ＥＳＯ上のパートナ機能を表すパートナ・テーブルＸ
ＶＢＰＡ（ヘッダ項目と行項目の両方）・既存の注文上のパートナ機能を表すパートナ・テーブ
ルＹＶＢＡＰ・ＯＥＭＬＳ（１１１）などの外部インターフェースか
ら供給されるＥＳＯ上のコミットを表す配送スケジュー
ル・コミット・テーブルＸＶＢＥＰ２特別な詳細：・上にリストしたテーブルおよび構造体の注文番号フィ
ールドＶＢＥＬＮは、次の形で決定される・論理メッセージＯＲＤＥＲＳおよびＷＥＢからの入力
方法の場合→'ＷＢ'＋ＥＳＯ番号の最後の８桁・論理メッセージＯＲＤＥＲＳおよび他のすべての入力
方法の場合→'ＥＤ'＋ＥＳＯ番号の最後の８桁・論理メッセージＯＲＤＣＨＧまたはＤＥＬＩＮＳの場
合→既存の注文番号を使用する・顧客ＰＯワークベンチで拒否された行項目（要求全体
は拒否されない）は、ＡＴＰに送られ「ない」・顧客によって取り消された行項目は、フィールドＸＶ
ＢＥＰ−ＵＰＤＫＺで'Ｄ'を用いて表される・配送スケジュール型は、フィールドＸＶＢＥＰ−ＡＢ
ＡＲＴで表される・' ' 通常・'１' ＦＤＳ・'２' ＪＩＴ・テーブルＺＡＴＰＧＥＮは、ＥＳＯ番号と、ＡＴＰに
送られるＶＢＥＬＮ番号とを相互参照するために更新さ
れる。キー値は次の通りである。ＺＡＴＴＲＩＢ＝'ＺＥＤＩＡＴＰ' ＺＰＡＲＡＭ＝注文番号ＺＲＥＣＩＤ＝１２３４５６ＺＲＥＣＶＡＬＵＥ＝ＥＳＯ番号要求は、その後、ＡＴＰ前（機能モジュールZ_IDOC_INP
UT_PRE_ATP（機能ブロック３１３））に送られ、ＡＴＰ
前モジュールは、ＡＴＰ／ＳＡＰインターフェース・テ
ーブルＺＡＴＰＤＥＭに、ＡＰＩで供給される情報（上
の構造体およびテーブルを参照）を書き込み、ＡＰＩの
指示に従ってMQSeriesを介してＡＴＰにインターフェー
スする。パラメータTRIGGER_ATP（ＡＴＰに送られる'
ｘ'）によって、要求がＡＴＰに送られるかどうかが制
御される。これは、ＥＳＯ上にコミットが存在する（た
とえばＯＥＭＬＳ（１１１）からの）時を除く、すべて
のＥＳＯにあてはまる。パラメータRESEND_COMMITは、
ＥＳＯが顧客によって拒否され、要求がＡＴＰによって
コミットされており、論理メッセージがＯＲＤＣＨＧま
たはＤＥＬＩＮＳの時に限って使用される。RESEND_COM
MIT＝'ｘ'の時には、既存注文上のコミットが、ＡＴＰ
に再送されて、最新のコミットが置換されるが、RESEND
_COMMIT＝' 'は、コミットの要求を意味する。パラメ
ータTRIGGER_ZMOM１０３は、ＡＴＰに、ＡＴＰ結果を返
す際にＺ４状況でのＥＳＯ再始動（ＺＭＯＭＩ０３）モ
ジュール（３１９）をトリガするイベントを送出するよ
うに指示する。ＡＴＰへのリンクが、タイムリーな形で
応答（現在は６０秒に設定）していない場合には、ＡＴ
Ｐ前機能が、トリガに'ｘ'をセットされた状態で再実行
される。ＥＳＯの状況に'Ｚ４'がセットされ、ＥＳＯの
処理は、Ｚ４状況でのＥＳＯ再始動（ＺＭＯＭＩ０３）
モジュール（３１９）がトリガされるまで延期される。
ＡＴＰ前が実行された後に、インターフェース・テーブ
ルＺＡＴＰＤＥＭを３秒ごとにポーリングして、ＡＰＴ
からの結果がポストされたかどうかを調べる。ＥＳＯ上
のすべての配送スケジュールが応答を有する場合には、
ＡＴＰ後（Z_IDOC_INPUT_POST_ATP）が実行される。こ
のループは、すべての配送スケジュールが応答を有する
か、時間制限を過ぎる（２０回までまたは１分の経過時
間まで）まで繰り返される。時間制限を超過した場合に
は、ＡＴＰ前機能が、TRIGGER_ZMOMI03に'ｘ'をセット
した状態で再実行される。Ｚ４状況でのＥＳＯ再始動Ｚ
ＭＯＭＩ０３モジュール３１９がトリガされる時には、
ＡＴＰ後を実行して、ＥＳＯの処理を拾い上げる。擬似販売注文ワークベンチ・メッセージ Z_IDOC_INPUT_PRE_ATPモジュール（機能ブロック３１
３）からのエラー・メッセージが、顧客ＰＯワークベン
チ・モジュール（６０７）のために記録される。

【０１１６】擬似販売注文ワークベンチの説明擬似販売注文ワークベンチである機能ブロック１０６
は、顧客サービス担当者（ＣＳＲ）に、ＳＡＰ販売注文
に処理する前に顧客のインバウンド購入注文を再検討ま
たは変更する能力を与えるツールである。主な特徴の１
つは、顧客の注文要求が擬似販売注文で提示されること
である。現在、ワークベンチおよび注文インターセプタ
によってサポートされるシナリオが４つある。１．ＳＡＰ販売注文（すなわちＶＡ０１、ＶＡ０２）の
作成および変更２．ＳＡＰ契約への参照を用いるＳＡＰ販売注文（すな
わちＶＡ０１、ＶＡ０２）の作成および変更３．ＳＡＰスケジューリング合意アウトライン合意（す
なわちＶＡ３２）の変更４．ＳＡＰ契約合意アウトライン合意（すなわちＶＡ４
１）の作成

【０１１７】必ず自分の注文を手動で再検討するように
特定の顧客を構成するなど、この文書に記載されていな
い、ワークベンチを使用する前に行わなければならない
初期構成がいくつかある。しかし、ＣＳＲは、ワークベ
ンチから、選択された構成処理へ分岐する能力を有する
が、これについてはこの文書の後で詳細に説明する。前
記の注文インターセプタ文書で、顧客固有の規則および
構成が説明されている。

【０１１８】ＣＳＲは、顧客の注文全体を拒否すること
も、注文の特定の行項目だけを拒否することもできる。
量がＭＯＱまたはＳＰＱから外れている場合に、「その
まま受け入れる」機能性もある。ワークベンチの主要な
機能の１つは、インバウンド注文に関連するエラー・メ
ッセージのすべてを再検討または訂正することである。
すべての訂正が、ＥＳＯデータに対して行われ、このＥ
ＳＯデータが、ＳＡＰの販売注文作成／変更処理への入
力になる。データを変更した後に、次の画面に進むか前
の画面に戻る前に、そのデータを保存しなければならな
い。以下のリストは、変更を許可されるデータ・フィー
ルドの種類を表す。・販売区域データ・販売組織、配送チャネル、部署・販売グループ、販売事務所・外部パートナ番号（すなわち、出荷先、請求先など）・ＩＢＭ内部／ＳＡＰ材料番号・配送プラント・要求された日付および日付フォーマット・要求された時刻・要求された量・スケジューリング合意の最新および以前のリリース番
号・スケジューリング合意探索判断基準

【０１１９】エラーに起因して訂正される可能性がある
他のデータ・フィールドには、顧客のＰＯ番号、顧客の
ＰＯ行項目番号、行項目に関するＥＳＯ処置コードおよ
び、ワークベンチに機能が追加される際の他の項目が含
まれる。

【０１２０】すべてのエラーが訂正／再検討された後
に、後に続く処理のために「Releaseto Sales Doc（販
売文書を解放）」して、ＳＡＰ販売注文を作成／変更す
る。なんらかの理由でＳＡＰ販売注文の作成／変更が失
敗した場合には、その失敗は、ワークベンチに「Call t
ransaction VA01 failed....Press HELP(?) for instru
ctions」というメッセージを用いて表示される。その時
点で、ＣＳＲは、トランザクションの失敗を引き起こし
たエラーを判定する方法に関する指示に従わなければな
らない。

【０１２１】図７に、ワークベンチから「擬似販売注
文」ビューを示すための画面の好ましい実施例を示す。

【０１２２】擬似販売注文（販売注文前）概要画面図７からわかるように、顧客ＰＯ（販売注文前）概要画
面には、インバウンド顧客ＰＯからのヘッダおよび行項
目データのすべてが含まれる。この画面は、販売区域デ
ータと、販売先顧客番号、顧客のＰＯ番号、顧客ＰＯ日
付、トランザクションの種類（８５０新規または８６０
変更）および既存ＳＡＰ販売注文番号などの主要顧客デ
ータとを判定する際にＣＳＲを支援するためにデータ・
グルーピングに分割される。その次に、ページ単位で上
下にスクロール可能なすべての項目がある。

【０１２３】エラー・メッセージに対するのか、ユーザ
が「Overview」プッシュボタンを押したかに応じて、い
くつかのフィールドが変更可能になる。項目レベルの日
付または量が変更され、インバウンドＥＳＯが１つの配
送スケジュールを有する場合には、配送スケジュールの
日付も変更される。複数の配送スケジュールが存在する
場合には、項目レベルの日付フィールドおよび量フィー
ルドは、変更可能に「ならない」。

【０１２４】ユーザが、注文全体の拒否を選択する場
合、顧客ＰＯ（販売注文前）概要画面は、拒否理由コー
ドが入力される画面になる。

【０１２５】ＰＲＯＦＩＴコミット・データが存在する
場合には、ＣＳＲは、日付および量がすでにそのプラン
トについてコミットされていることに起因して、どのデ
ータも変更できない。

【０１２６】

【表８】

【表９】

【表１０】

【０１２７】擬似販売注文（販売注文前）配送スケジュ
ール画面図８に示されたこの画面では、ＣＳＲが、行項目に関す
るすべての配送スケジュールを再検討／変更することが
できる。日付と量の両方が、変更可能フィールドであ
る。複数の配送スケジュールがある場合には、それら
は、page upキーおよびpage downキーを介してスクロー
ル可能である。１つまたは複数の配送スケジュールを変
更した場合には、ワークベンチが、項目量フィールドで
更新された合計を自動的に累算することに留意された
い。ＣＳＲは、これが発生する場合に、情報メッセージ
を介して通知される。この画面では、ＣＳＲが、ＭＯＱ
またはＳＰＱ範囲外の量を訂正または受け入れることも
できる。「ＳＡＶＥ」および「SAVE As Is」の両方が、
量フィールドに現在存在する値を保存することによっ
て、同一の形で動作する。

【０１２８】

【表１１】

【表１２】

【０１２９】拒否受信確認の流れと説明図４に示した拒否受信確認処理を、これから詳細に説明
する。拒否受信確認システムである機能ブロック１０７
は、インバウンドＥＳＯを受け取り、拒否コードおよび
適当な値を含む対応するＥＳＯを作成する。これは、販
売注文（８５０）、販売注文変更（８６０）または予測
（８３０）の型を有する着信ＥＳＯを拒否するのに使用
することができる。

【０１３０】インバウンドＥＳＯは、機能ブロック４０
１で、ヘッダレベルのＥＳＯの拒否コードを入力するこ
とによって、販売注文インターセプタ・ワークベンチか
ら拒否される。拒否受信確認で送られる値は、新規販売
注文の場合はインバウンドＥＳＯに基づくものとし、拒
否された変更注文の場合はＳＡＰ内の既存データに基づ
くものとすることができる。この構成は、テーブルＺＥ
ＤＩＴＣＦＧ（フィールドＺＲＥＪＭＥＴＨＯＤ）で設
定される。アウトバウンドＥＳＯが、元の値をとること
に基づいて構築される場合には、拒否コードおよび記述
を含む拒否セグメント（Ｚ１ＥＤＫ０１）が、編集され
たＥＳＯからとられ、アウトバウンド拒否受信確認ＥＳ
Ｏに付加される。最終ステップは、着信ＥＳＯに関する
ＥＳＯ調整テーブル（ＺＥＤＩＡＣＫＲ）の、アウトバ
ウンドＥＳＯ番号による更新である。

【０１３１】拒否受信確認システムを用いると、顧客の
注文要求を注文処理システムに送らずに、顧客に応答す
ることができるようになる。

【０１３２】まとめとして、本発明の構成に関して以下
の事項を開示する。

【０１３３】（１）注文が前記注文処理システムに送ら
れる前に注文を前処理するためのシステムであって、電
子販売注文データを受け取り、処理する注文インターセ
プタと、前記注文インターセプタから前記電子販売注文
データを受け取り、使用可能性検査を実行するインター
フェース・システムであって、前記使用可能性検査が、
前記電子販売注文データの満足できる部分を判定する、
前記インターフェース・システムと、前記電子販売注文
データの少なくとも一部を注文処理システムに送出する
ための手段とを含むシステム。（２）前記注文インターセプタが、前記電子販売注文デ
ータを前記注文インターセプタの内部フォーマットに変
換し、使用可能性検査が必要であるかどうかを判定し、
前記電子販売注文データの少なくとも一部を送出し、前
記電子販売注文データに関連する処理問題があるかどう
かを判定し、ビジネス・ルールに従って前記電子販売注
文データを処理する、上記（１）に記載のシステム。（３）前記注文インターセプタが、前記電子販売注文デ
ータを受け取るための手段と、前記電子販売注文データ
を前記注文インターセプタの内部フォーマットに変換す
るための手段と、使用可能性検査が必要であるかどうか
を判定するための手段と、前記電子販売注文データの少
なくとも一部を送出するための手段と、前記電子販売注
文データに関連する処理問題があるかどうかを判定する
ための手段と、ビジネス・ルールに従って前記電子販売
注文データを処理するための手段とを含む、上記（２）
に記載のシステム。（４）さらに、誤りを含むか不完全である電子販売注文
データを受け取るワークベンチを含む、上記（１）に記
載のシステム。（５）前記ワークベンチが、誤りを含むか不完全である
電子販売注文データを受け取り、表示し、前記電子販売
注文データに関連するエラー・メッセージを表示し、ユ
ーザが前記電子販売注文データを含む少なくとも１つの
データベースを編集、訂正および更新できるようにす
る、上記（４）に記載のシステム。（６）前記ワークベンチが、ａ）誤りを含むか不完全である電子販売注文データを受
け取り、表示するための手段と、ｂ）ステップａ）の前記電子販売注文データに関連する
エラー・メッセージを表示するための手段と、ｃ）電子販売注文データを含む前記少なくとも１つのデ
ータベースを訂正、編集および更新するための手段とを
含む、上記（５）に記載のシステム。（７）前記ワークベンチが、さらに、前記電子販売注文
データの状況を表示し、構成規則が満足されるかどうか
を判定し、前記電子販売注文データの少なくとも一部が
拒否されることの表示を前記注文インターセプタに供給
する、上記（５）に記載のシステム。（８）前記ワークベンチが、さらに、前記電子販売注文
データの前記状況を表示するための手段と、前記構成規
則が満足されるかどうかを判定するための手段と、前記
電子販売注文データの少なくとも一部が拒否されること
を前記注文インターセプタに示すための手段とを含む、
上記（７）に記載のシステム。（９）前記電子販売注文データの少なくとも一部が拒否
されることの表示を前記注文インターセプタから受け取
る拒否受信確認システムをさらに含む、上記（１）に記
載のシステム。（１０）前記否定受信確認システムが、前記電子販売注
文データの前記一部が拒否されたことを示すために、少
なくとも１つのデータベースを更新する、上記（９）に
記載のシステム。（１１）前記拒否受信確認システムが、前記電子販売注
文データの少なくとも一部が拒否されることの表示を前
記注文インターセプタから受け取るための手段と、前記
電子販売注文データの拒否された前記一部を示すために
前記少なくとも１つのデータベースを更新するための手
段とを含む、上記（９）に記載のシステム。（１２）前記拒否受信確認システムが、さらに、前記電
子販売注文データが、ワールド・ワイド・ウェブからの
伝送を介して受け取られたかどうかを判定し、ＥＳＯフ
ォーマットまたはＳＡＰフォーマットのいずれかで前記
少なくとも１つのデータベースを更新する、上記（１
０）に記載のシステム。（１３）前記拒否受信確認システムが、さらに、前記電
子販売注文データが、前記ワールド・ワイド・ウェブか
らの伝送を介して受け取られたかどうかを判定するため
の手段と、ＥＳＯフォーマットまたはＳＡＰフォーマッ
トのいずれかで前記少なくとも１つのデータベースを更
新するための手段とを含む、上記（１２）に記載のシス
テム。（１４）前記注文インターセプタが、標準電子データ交
換（ＥＤＩ）フォーマットで前記電子販売注文データを
受け取る、上記（１）に記載のシステム。（１５）前記システムが、ＳＡＰシステムである、上記
（１）に記載の注文インターセプタ・システム。（１６）前記電子販売注文データが前記注文処理システ
ムに送出される前に、前記電子販売注文データを処理す
る、コンピュータで実施される方法であって、電子販売
注文データを受け取るステップと、前記電子販売注文デ
ータを内部フォーマットに変換するステップと、前記電
子販売注文データの満足できる部分を判定するために使
用可能性検査を実行するインターフェース・システムに
前記電子販売注文データを送出するステップと、前記使
用可能性検査の表示が送出である場合に、前記内部フォ
ーマットのデータの指定された部分を注文処理システム
に送出するステップとを含む方法。（１７）ａ）ビジネス・ルールに従って前記電子販売注
文データを処理するステップと、ｂ）前記電子販売注文データに関連する処理問題がある
かどうかを判定するステップと、ｃ）ステップｂ）で処理問題がある場合に、前記電子販
売注文データが誤りを含むか不完全であることを示す電
子メッセージを少なくとも１つのユーザに送出するステ
ップとをさらに含む、上記（１６）に記載のコンピュー
タで実施される方法。（１８）ユーザが前記電子販売注文データを訂正できる
ようにするステップと、前記訂正された電子販売注文デ
ータを前記注文処理システムに送出するステップとをさ
らに含む、上記（１７）に記載のコンピュータで実施さ
れる方法。（１９）満足できない前記電子販売注文データを拒否す
るステップと、前記電子販売注文データの拒否された前
記部分を示すために少なくとも１つのデータベースを更
新するステップとをさらに含む、上記（１６）に記載の
コンピュータで実施される方法。（２０）前記電子販売注文データが、電子データ交換フ
ォーマットである、上記（１６）に記載のコンピュータ
で実施される方法。（２１）注文が注文処理システムに送出される前に前記
注文を前処理するための、媒体内に埋め込まれたコンピ
ュータ可読プログラム・コードを有するコンピュータ可
用媒体であって、前記コンピュータ・プログラムが、電
子販売注文データを受け取るための第１コンピュータ・
プログラム・コードと、前記電子販売注文データを内部
フォーマットに変換するための第２コンピュータ・プロ
グラム・コードと、注文インターセプタ・データの満足
できる部分を判定するために使用可能性検査を実行する
インターフェース・システムに、前記電子販売注文デー
タを送出するための第３コンピュータ・プログラム・コ
ードと、前記使用可能性検査の表示が、前記注文インタ
ーセプタ・データの少なくとも一部を前記注文処理シス
テムに送出することであるかどうかを判定し、そうであ
る場合に、前記電子販売注文データの指定された部分を
前記注文処理システムに送出するための、第４コンピュ
ータ・プログラム・コードとを含む、コンピュータ可用
媒体。（２２）ビジネス・ルールに従って前記電子販売注文デ
ータを処理するための第５コンピュータ・プログラム・
コードと、前記電子販売注文データに関連する処理問題
があるかどうかを判定するための第６コンピュータ・プ
ログラム・コードと、前記電子販売注文データが誤りを
含むか不完全であることの表示を少なくとも１つのユー
ザに提供するための第７コンピュータ・プログラム・コ
ードとをさらに含む、上記（２１）に記載のコンピュー
タ可用媒体。（２３）ユーザが前記電子販売注文データを訂正できる
ようにするための第８コンピュータ・プログラム・コー
ドと、前記訂正された電子販売注文データを前記注文処
理システムに送出するための第９コンピュータ・プログ
ラム・コードとをさらに含む、上記（２２）に記載のコ
ンピュータ可用媒体。（２４）満足できない前記電子販売注文データを拒否す
る第１０コンピュータ・プログラム・コードと、前記電
子販売注文データの拒否された前記部分を示すために少
なくとも１つのデータベースを更新するための第１１コ
ンピュータ・プログラム・コードとをさらに含む、上記
（２３）に記載のコンピュータ可用媒体。

【図面の簡単な説明】

【図１】従来の方法に従ってＥＤＩ注文が処理される方
法を示す流れ図である。

【図２】注文インターセプタ・システム構成要素の好ま
しい実施形態を示すブロック図である。

【図３】本発明による注文処理システムにポストされる
前の、注文の前処理の全体的な処理を示す流れ図であ
る。

【図４】擬似販売注文ワークベンチの処理を示す流れ図
である。

【図５】拒否受信確認処理の流れ図である。

【図６】注文情報処理システムを含む、ソフトウェア・
モジュールの関係の好ましい実施形態を示すブロック図
である。

【図７】擬似販売注文ワークベンチから表示される販売
前概要メニュー画面の好ましい実施形態を示す図であ
る。

【図８】擬似販売注文ワークベンチから表示される販売
前注文配送スケジュールの好ましい実施形態を示す図で
ある。

【符号の説明】

６００モジュール６０１ EDI_DATA_INCOMINGモジュール６０２ＲＳＥＩＮＢ００モジュール６０３ Z_IDOC_INPUT_PRE_PROCESSモジュール６０４ IDOC_INPUTモジュール６０５ワークフロー・モジュール６０６ＩＤＯＣワークベンチ・モジュール６０７顧客購入注文ワークベンチ・モジュール６０８ IDOC_MANUAL_INPUTモジュール６０９ Z_IDOC_MANUAL_INPUTモジュール６１０ Z_IDOC_INPUTモジュール６１１アナライザ・ドリル・ダウン・レポート・モジ
ュール６１２ Z_ACK_REJ_CUST_POモジュール６１３モジュール６１４ＺＭＯＭ１０１モジュール６１５ＡＴＰ後モジュール６１６機能モジュール６１７機能モジュール６１８ＰＲＯＦＩＴ／ＡＴＰモジュール６１９ＺＭＯＭ１０３モジュール

───────────────────────────────────────────────────── フロントページの続き (72)発明者グレゴリー・リー・マッキーアメリカ合衆国28215 ノースカロライナ州シャーロッテバーント・アンバー・ドライブ 8420 (72)発明者シルヴァン・ミシェルカナダジェイ３ワイ−７エックス１ケベック州サン＝ユベールメゾンヌーヴ 366 (72)発明者ペニー・ジャネット・ピーチー・カウンツアメリカ合衆国05403 バーモント州サウス・バーリントンオークウッド・ドライブ 84 (72)発明者ジェームズ・ドナルド・スコットアメリカ合衆国28212 ノースカロライナ州シャーロッテプレストウィック・レーン 4908

Claims

【特許請求の範囲】

【請求項１】注文が前記注文処理システムに送られる前
に注文を前処理するためのシステムであって、電子販売注文データを受け取り、処理する注文インター
セプタと、前記注文インターセプタから前記電子販売注文データを
受け取り、使用可能性検査を実行するインターフェース
・システムであって、前記使用可能性検査が、前記電子
販売注文データの満足できる部分を判定する、前記イン
ターフェース・システムと、前記電子販売注文データの少なくとも一部を注文処理シ
ステムに送出するための手段とを含むシステム。
【請求項２】前記注文インターセプタが、前記電子販売
注文データを前記注文インターセプタの内部フォーマッ
トに変換し、使用可能性検査が必要であるかどうかを判
定し、前記電子販売注文データの少なくとも一部を送出
し、前記電子販売注文データに関連する処理問題がある
かどうかを判定し、ビジネス・ルールに従って前記電子
販売注文データを処理する、請求項１に記載のシステ
ム。
【請求項３】前記注文インターセプタが、前記電子販売注文データを受け取るための手段と、前記電子販売注文データを前記注文インターセプタの内
部フォーマットに変換するための手段と、使用可能性検査が必要であるかどうかを判定するための
手段と、前記電子販売注文データの少なくとも一部を送出するた
めの手段と、前記電子販売注文データに関連する処理問題があるかど
うかを判定するための手段と、ビジネス・ルールに従って前記電子販売注文データを処
理するための手段とを含む、請求項２に記載のシステ
ム。
【請求項４】さらに、誤りを含むか不完全である電子販
売注文データを受け取るワークベンチを含む、請求項１
に記載のシステム。
【請求項５】前記ワークベンチが、誤りを含むか不完全
である電子販売注文データを受け取り、表示し、前記電
子販売注文データに関連するエラー・メッセージを表示
し、ユーザが前記電子販売注文データを含む少なくとも
１つのデータベースを編集、訂正および更新できるよう
にする、請求項４に記載のシステム。
【請求項６】前記ワークベンチが、ａ）誤りを含むか不完全である電子販売注文データを受
け取り、表示するための手段と、ｂ）ステップａ）の前記電子販売注文データに関連する
エラー・メッセージを表示するための手段と、ｃ）電子販売注文データを含む前記少なくとも１つのデ
ータベースを訂正、編集および更新するための手段とを
含む、請求項５に記載のシステム。
【請求項７】前記ワークベンチが、さらに、前記電子販
売注文データの状況を表示し、構成規則が満足されるか
どうかを判定し、前記電子販売注文データの少なくとも
一部が拒否されることの表示を前記注文インターセプタ
に供給する、請求項５に記載のシステム。
【請求項８】前記ワークベンチが、さらに、前記電子販売注文データの前記状況を表示するための手
段と、前記構成規則が満足されるかどうかを判定するための手
段と、前記電子販売注文データの少なくとも一部が拒否される
ことを前記注文インターセプタに示すための手段とを含
む、請求項７に記載のシステム。
【請求項９】前記電子販売注文データの少なくとも一部
が拒否されることの表示を前記注文インターセプタから
受け取る拒否受信確認システムをさらに含む、請求項１
に記載のシステム。
【請求項１０】前記否定受信確認システムが、前記電子
販売注文データの前記一部が拒否されたことを示すため
に、少なくとも１つのデータベースを更新する、請求項
９に記載のシステム。
【請求項１１】前記拒否受信確認システムが、前記電子販売注文データの少なくとも一部が拒否される
ことの表示を前記注文インターセプタから受け取るため
の手段と、前記電子販売注文データの拒否された前記一部を示すた
めに前記少なくとも１つのデータベースを更新するため
の手段とを含む、請求項９に記載のシステム。
【請求項１２】前記拒否受信確認システムが、さらに、
前記電子販売注文データが、ワールド・ワイド・ウェブ
からの伝送を介して受け取られたかどうかを判定し、Ｅ
ＳＯフォーマットまたはＳＡＰ（登録商標）フォーマッ
トのいずれかで前記少なくとも１つのデータベースを更
新する、請求項１０に記載のシステム。
【請求項１３】前記拒否受信確認システムが、さらに、前記電子販売注文データが、前記ワールド・ワイド・ウ
ェブからの伝送を介して受け取られたかどうかを判定す
るための手段と、ＥＳＯフォーマットまたはＳＡＰフォーマットのいずれ
かで前記少なくとも１つのデータベースを更新するため
の手段とを含む、請求項１２に記載のシステム。
【請求項１４】前記注文インターセプタが、標準電子デ
ータ交換（ＥＤＩ）フォーマットで前記電子販売注文デ
ータを受け取る、請求項１に記載のシステム。
【請求項１５】前記システムが、ＳＡＰシステムであ
る、請求項１に記載の注文インターセプタ・システム。
【請求項１６】前記電子販売注文データが前記注文処理
システムに送出される前に、前記電子販売注文データを
処理する、コンピュータで実施される方法であって、電子販売注文データを受け取るステップと、前記電子販売注文データを内部フォーマットに変換する
ステップと、前記電子販売注文データの満足できる部分を判定するた
めに使用可能性検査を実行するインターフェース・シス
テムに前記電子販売注文データを送出するステップと、前記使用可能性検査の表示が送出である場合に、前記内
部フォーマットのデータの指定された部分を注文処理シ
ステムに送出するステップとを含む方法。
【請求項１７】ａ）ビジネス・ルールに従って前記電子
販売注文データを処理するステップと、ｂ）前記電子販売注文データに関連する処理問題がある
かどうかを判定するステップと、ｃ）ステップｂ）で処理問題がある場合に、前記電子販
売注文データが誤りを含むか不完全であることを示す電
子メッセージを少なくとも１つのユーザに送出するステ
ップとをさらに含む、請求項１６に記載のコンピュータ
で実施される方法。
【請求項１８】ユーザが前記電子販売注文データを訂正
できるようにするステップと、前記訂正された電子販売注文データを前記注文処理シス
テムに送出するステップとをさらに含む、請求項１７に
記載のコンピュータで実施される方法。
【請求項１９】満足できない前記電子販売注文データを
拒否するステップと、前記電子販売注文データの拒否された前記部分を示すた
めに少なくとも１つのデータベースを更新するステップ
とをさらに含む、請求項１６に記載のコンピュータで実
施される方法。
【請求項２０】前記電子販売注文データが、電子データ
交換フォーマットである、請求項１６に記載のコンピュ
ータで実施される方法。
【請求項２１】注文が注文処理システムに送出される前
に前記注文を前処理するための、媒体内に埋め込まれた
コンピュータ可読プログラム・コードを有するコンピュ
ータ可用媒体であって、前記コンピュータ・プログラム
が、電子販売注文データを受け取るための第１コンピュータ
・プログラム・コードと、前記電子販売注文データを内部フォーマットに変換する
ための第２コンピュータ・プログラム・コードと、注文インターセプタ・データの満足できる部分を判定す
るために使用可能性検査を実行するインターフェース・
システムに、前記電子販売注文データを送出するための
第３コンピュータ・プログラム・コードと、前記使用可能性検査の表示が、前記注文インターセプタ
・データの少なくとも一部を前記注文処理システムに送
出することであるかどうかを判定し、そうである場合
に、前記電子販売注文データの指定された部分を前記注
文処理システムに送出するための、第４コンピュータ・
プログラム・コードとを含む、コンピュータ可用媒体。
【請求項２２】ビジネス・ルールに従って前記電子販売
注文データを処理するための第５コンピュータ・プログ
ラム・コードと、前記電子販売注文データに関連する処理問題があるかど
うかを判定するための第６コンピュータ・プログラム・
コードと、前記電子販売注文データが誤りを含むか不完全であるこ
との表示を少なくとも１つのユーザに提供するための第
７コンピュータ・プログラム・コードとをさらに含む、
請求項２１に記載のコンピュータ可用媒体。
【請求項２３】ユーザが前記電子販売注文データを訂正
できるようにするための第８コンピュータ・プログラム
・コードと、前記訂正された電子販売注文データを前記注文処理シス
テムに送出するための第９コンピュータ・プログラム・
コードとをさらに含む、請求項２２に記載のコンピュー
タ可用媒体。
【請求項２４】満足できない前記電子販売注文データを
拒否する第１０コンピュータ・プログラム・コードと、前記電子販売注文データの拒否された前記部分を示すた
めに少なくとも１つのデータベースを更新するための第
１１コンピュータ・プログラム・コードとをさらに含
む、請求項２３に記載のコンピュータ可用媒体。