Oracle Order Managementインプリメンテーション・マニュアル リリース11i B25742-01 | ![]() 目次 | ![]() 戻る | ![]() 次へ |
受注インポートは、受注および返品の入力、変更または取消を行うためのOrder Managementのオープン・インタフェースです。受注インポートを使用すると、外部システム、レガシー・システム、EDI、または社内購買依頼を履行するためにOracle Purchasingで作成された社内受注などの社内システムから受注をインポートできます。
受注インポートは、受注データや返品データとともにロードする必要があるインタフェース表のセットおよびそのデータを処理するAPIのセットとして実装されています。APIをコールして、データ処理を開始するコンカレント・プログラムが用意されています。さらに、インタフェース表から受注を問い合せたり、そのデータを修正または変更したり、インポート処理を再度開始できるフォームも用意されています。インポートに失敗した受注は、その表に保持されるため、このフォームを使用して問合せおよび訂正を実行できます。受注がインポートされなかった場合は、理由の詳細を示すメッセージが表示されます。
受注インポートは、基本的なOrder ManagementのAPI(具体的には、受注処理API)をコールして、受注ベース表のデータの検証と挿入または更新を行います。これによって、一貫性のある処理が保証されます。
受注インポートにおける問合せは、データベースのコストベース・オプティマイザを使用して最適化されます。このコストベース・オプティマイザは、問合せを最適化するために、生成された統計情報を使用します。「受注インポート統計値」コンカレント・プログラムが、コストベース・オプティマイザにより使用される統計値を収集します。このコンカレント・プログラムは、データがインタフェース表に移入された後に実行する必要があります。
コストベース・オプティマイザでは、最適レコード処理を決定するために、受注インポートに関連したすべてのインタフェース表の表解析が実行されます。「受注インポート」コンカレント・プログラムを発行する前に、毎回このプログラムを発行するオプションがあります。通常の処理でインタフェース・レコード数が類似している場合は、一般的にこのプログラムを発行する必要はありません。
受注インポートには、外部システムおよび他の種類のシステムの受注データを統合する作業を簡素化するための機能が多数用意されています。
受注インポートの主要タスクは、大量の受注をOrder Managementに人手をかけずに入力するバッチに似た機能を提供することです。この機能は、コンカレント要求として実行できるため、1日を通して特定の間隔で、たとえば、フィード・システムの時間にあわせて計画できます。受注がOrder Managementのベース表にインポートされると、受注と明細のワークフローが開始されます。ソース処理や予定作成処理など、それ以降の処理操作はすべて、受注が手動で入力されたときと同じように開始されます。
受注インポートには、データに対する独自の検証ルーチンがありません。かわりに、受注処理APIをコールします。このAPIは、「受注」ウィンドウを使用して受注をキー入力した場合にその受注の検証と挿入に使用されるAPIと同じです。この設計によって、メンテナンス性が向上します。これは、受注処理に対して実行された拡張機能や不具合の修正が、即時に受注のインポートにも反映されるためです。受注処理APIは、処理制約を使用して、受注に対する変更要求が実行可能かどうかを評価します。受注インポートでは、受注処理APIを使用するため、すべての処理制約が評価されます。すべての制約違反が記録され、「訂正」フォームと「メッセージ」ウィンドウを使用して検討できます。受注インポートには、検証のみのモードで実行し、バッチで受注を事前表示し、インポート前にすべてのエラーを訂正できる機能があります。1つの受注にエラーがあると、全受注がインポート表に保持されます。インポート操作は、受注単位で行われる二者択一のプロセスです。
Order Managementには、受注インポート表にあるデータの検討と訂正に使用できる一連のフォームがあります。これらのフォームは、受注インポート訂正フォームと呼ばれており、「受注インポート」ウィンドウに移動して、データ・インポート時のすべてのエラーを表示するボタンもあります。インポートした受注に関するエラーや警告メッセージが表示されると、リリース11のOrder Entryバージョンの受注インポートで使用されている受注インポート例外処理レポートが置換されます。大部分のフィールドには、そのウィンドウ内に検証機能または値リストがありません。したがって、フィールド上でキー入力によってフォームを訂正した場合、検証または再インポートするまで、その訂正が適切であったかどうかを判断できません。間違った受注や明細がインポート表にあると判断した場合は、「ステータス」タブのReject_Flagを「Y」に設定し、処理を続行しないことを示します。間違った受注または明細は、受注インポートの次の実行時に削除されます。Reject_Flagの詳細は、以降の「フラグ」の項を参照してください。このフラグは、受注をフォームで訂正することが非常に難しい場合に役立ちます。また、このフラグは、受注をフィーダ・システム内で修正して再インポートしたり、フィーダ・システムを重複して実行した場合に発生した可能性がある受注をパージするためにも使用できます。
「訂正」フォームのユーザー・インタフェースはフォルダ・ウィンドウです。このフォームは、ボタンを使用した再検証や再インポートに対する複数選択に対応していません。ヘッダーと明細のインポート表のデータは、各種タブ上に論理的に編成されたデータとともにフォームに表示されます。その他のフォーム(「値引」、「販売実績」、「支払」、「価格設定属性」および「処理」)は、単一タブのフォームです。「検索」画面と「受注」ウィンドウのスクリーン・ショットは、『Oracle Order Managementユーザーズ・ガイド』を参照してください。
受注インポートでは、最小限のデータを使用して新規の顧客アカウントを販売先レベルで受注ヘッダーに入力できます。新規の顧客アカウントは、出荷先、請求先または搬送先の各レベルで受注ヘッダーまたは受注明細に入力できます。顧客追加インタフェース表がこれに対応します。この表がロードされた場合は新規の顧客アカウントを作成することを意味し、新規アカウントに関して必要なフィールドが移入されます。受注インポートでは、次に新規の顧客アカウントが作成され、インタフェース表内に必要なデータがすべて存在して有効な場合にはパーティが作成されます。新規の顧客アカウントを、インタフェース表内にパーティ(組織または個人)の番号を指定することで既存のパーティと関連付けることもできます。その列がNULLのままになっている場合は、受注インポートにより顧客アカウントに加えてパーティが作成されます。新規顧客は、各種の会計および与信チェック情報を指定するデフォルトの顧客プロファイル区分に割り当てられます。
受注インポートを介して、受注をインポートおよび記帳します。受注が記帳の検証に失敗した場合でも、インポートは実行されますが、「入力済」ステータスのままです。「メッセージ」ウィンドウを使用すると、受注の記帳に失敗した理由を確認できます。あるいは、「記帳(&&B)」ボタンを使用して記帳を実行すると、エラーが表示されます。受注の記帳が必要なことを示すには2つの方法があります。OPERATION_CODE列にBOOK_ORDERの値を設定した処理インタフェース表OE_ACTIONS_IFACE_ALLをロードして記帳済ステータスの受注をインポートするか、記帳済フラグを設定できます。詳細は、以降の「処理表」に関する項を参照してください。
顧客品目番号またはUPC番号は、手動で作成した受注と同じ方法で受注インポートに入力できます。ただし、受注インポートの実行前に相互参照と相互参照タイプが設定されている必要があります。インタフェース表には、CUSTOMER_ITEM_NAMEという列に受注した品目を入力する必要があります。品目番号の種類(顧客番号、在庫品目番号または一般的な相互参照番号)がわかっている場合は、そのタイプをCUSTOMER_ITEM_ID_TYPEに入力できます。
既存の受注に対する受注の変更と取消は、受注インポートのオープン・インタフェース表を使用して入力します。OPERATION_CODEというインタフェース表にはそれぞれ列があり、そこで「INSERT」、「UPDATE」または「DELETE」と入力します。NULLは、「INSERT」と同じです。受注を変更する場合は、「UPDATE」のOPERATION_CODEを指定する必要があります。明細を取り消す場合は、「UPDATE」の操作を使用して、受注数量を0(ゼロ)に設定します。部分的な取消の場合は、明細上に残す受注数量を新規数量に変更します。受注全体を取り消す場合は、ヘッダーで「UPDATE」の操作を使用し、CANCEL-FLAGを「Y」に設定します。受注の変更と取消はすべて、定義した処理制約に従って行われます。
返品のインポートは、受注のインポートと同じで、返品明細タイプをサポートしている受注タイプを選択します。また、混合受注もインポートできます。混合受注とは、アウトバウンド明細とインバウンド(返品)明細を含む受注です。明細が従うパスは、その明細タイプに添付されているワークフローによって決まります。返品または返品明細のインポートは、レガシー・システムまたは実行中の他の受注システムから実行できます。見越ロット/シリアル番号をインポートできる別のインタフェース表があります。ただし、この表は返品明細のみに使用されます。
受注インポートを使用して入力する受注には、プロファイル・オプション「OM: 自動添付の適用」の設定に基づいて、ルール・ベースの添付が自動的に適用されます。このプロファイル・オプションを「No」に設定した場合も、処理インタフェース表を使用すると、受注基準で添付を受注に自動的に適用できます。この表の詳細は、以降の項を参照してください。現在のところ、ノート・テキストをインポートする方法または添付をオープン・インタフェース経由で作成する方法はありません。
インポート対象の受注に価格を設定する方法は2つあります。1つは、システムで価格を計算する方法、もう1つは、明細インタフェース表の価格フィールドに請求する価格を挿入し、さらに価格調整インタフェース表に結果として正味価格になる価格調整を挿入する方法です。どちらを使用するかは、明細インタフェース表のCALCULATE_PRICE_FLAGに設定する値によって示します。「価格計算」フラグが「Y」の場合、システムは、「価格」フィールドにロードされた価格設定値をすべて無視し、価格設定エンジンを使用して価格を計算します。「価格計算」フラグが「N」の場合は、定価と正味価格の差異を明らかにするために、単価、正味単価および価格調整をインタフェース表に挿入する必要があります。
EDI顧客からの共通の要件は、顧客が送信した価格と支払条件をシステムが決定した内容と照合して検証する機能です。通常、EDI顧客は、顧客が送信した価格または条件を受け入れません。ただし、取得の必要があると考えられる場合は、顧客が送信した価格または条件を継続記録する必要があります。顧客サービス担当は通常、その顧客と連絡をとり、不一致を解決します。たとえば、顧客が営業担当が見積もった価格を送信する場合があります。この価格にはある程度の値引きが想定されています。おそらく、その値引きは、受注のインポート時には失効してしまっていた可能性があります。このような場合、顧客サービス担当は、発生した不一致を調査する必要があります。
受注インポートでは、受注明細インタフェース表にCUSTOMER_ITEM_NET_PRICEおよびCUSTOMER_PAYMENT_TERMという2つの属性を挿入することで、この要件をサポートします。これらの列のいずれかにデータが含まれている場合、受注インポートでは、システムが決定した価格または支払条件とこの列の値を比較し、差異がある場合は、警告を表示します。その受注にそれ以外のエラーがない場合、その受注はそのままインポートされます。いずれの場合も、受注処理に使用されるのは、システムが決定した値です。顧客の値は、参照用として受注ベース表の受注明細上に保持されます。
次の表に、顧客の価格とシステムの価格の間で差異が発生した場合の例を示します。さらに「価格計算フラグ」が処理に与える影響も示します。
価格計算フラグ | 顧客が提供した価格 | システムが算出した価格 | 処理 |
---|---|---|---|
N | 20 | - | 顧客の価格を受け入れます。 |
Y | 20 | 20 | 顧客の価格を受け入れます(システム = 顧客)。 |
Y | 20 | 10 | 顧客の価格を受け入れます(システム < 顧客)。 |
Y | 20 | 30 | 顧客の価格を受け入れません。エラーをレポートします(システム > 顧客)。 |
受注インポートでは、受注処理APIを使用してインタフェース表の受注データを検証および処理します。オープン・インタフェースに関する詳細は、『Oracle Manufacturing APIs and Open Interfaces Manual』を参照してください。
受注インポートの場合は、ワークフローについて特別考慮する必要はありません。
OM: 顧客の追加 (受注インポート)
このプロファイルは、受注インポートで顧客、所在地および担当者を作成する権限をユーザーが持つかどうかを制御します。
OM: XML用受注インポート実行
このプロファイルは、XMLデータのインポート時に常に同期して受注インポートを実行するかどうかを制御します。
OM: 各顧客に対して一意の受注ソース、 当初システム文書参照組合せ
このプロファイルは、当該データの一意性を顧客単位または顧客全体に強制するかどうかを制御します。
受注インポートに対する特別な設定は1つのみです。それ以外は、受注をインポートする前に、手動で受注をキー入力する場合に必要な設定と同じ設定が完了している必要があります。
受注のインポート元のソース名を設定します。Order Managementには特別の設定ウィンドウがあり、それを使用してソースの名前と説明を定義できます。インポート・ソースは、「受注インポート」コンカレント・プログラムの発行時に使用できるパラメータです。また、このソースは、受注インポートの「訂正」ウィンドウの「検索」ウィンドウにある問合せ可能なフィールドの1つでもあります。インポート・ソースは受注ヘッダーにも渡されます。したがって、受注の出所を識別できます。シード済の受注インポート・ソースには、EDIと社内受注が含まれます。
受注インポートを実行するユーザーの営業単位に設定されている「品目検証組織」パラメータによって、品目と部品構成表構造の検証に使用する組織を判断します。品目検証組織とは、各営業単位に設定されるOrder Managementのパラメータです。
受注のインポートには、受注インポート表をロードするための方法が必要です。通常は、SQL*Loaderまたは他のプログラミング言語を使用してプログラムまたはスクリプトを作成し、使用しているフィーダ・システムのデータを受注インポートで実行できる標準データ形式に変換します。
Oracle Purchasingには、社内購買依頼に関するデータをPurchasingスキーマから取得し、受注インポート表にロードするプログラム(「社内受注の作成」)があります。同様に、e-Commerceゲートウェイ製品には、インバウンド発注EDI取引セットのインポート表をロードするプログラム(「発注インバウンド」)が用意されています。表のロードに必要な独自のプログラムを作成するときに、このコードを参照すると便利です。
Order Managementにデフォルト・ルールを設定し、受注と明細に関する情報を使用環境にできるだけ多くデフォルト設定することをお薦めします。このデフォルト・ルールによって、インポート表に挿入するデータ量が減少します。
インポート表のセットには、機能が自明でない特定の列や表があります。表の正常なロードに役立つ属性に関する追加情報を次に示します。
Order Managementのインタフェース表にあるいくつかのフラグは、受注インポート処理に影響を与えます。これらのフラグの有効値はY、NおよびNULLです。NULLは、特定のフラグに従って、その意味が変わります。これらのフラグは、受注インポートの「訂正」フォームの「受注ヘッダー」と「明細」の両方のフォームの「ステータス」タブから表示および更新できます。
適用強制フラグ
(変更取引のみに使用)
変更順序番号の順序が適切でない場合でも、変更取引を適用することを示します。デフォルトは「N」です。NULL値は「N」と同じです。一連の変更を変更順序に関係なく適用する場合、ユーザーは、通常このフラグを「Y」(UIでチェック)に設定します。変更順序番号とその使用方法の詳細は、以降の項を参照してください。
このフラグがあるのは、ヘッダー・レベルのみです。
クローズ済フラグ
インポート対象の明細または受注がクローズ済の状態でインポートされることを示します。履歴データを1つにまとめるために、あるいは返品に関する参照データを提供するために、クローズ済受注をインポートすることがあります。デフォルトは「N」です。NULL値は「N」と同じです。
このフラグは、ヘッダーと明細の両レベルにあります。
取消フラグ
このフラグは通常、インポート対象の明細または受注が取消の状態でインポートされることを示します。デフォルトは「N」です。NULL値は「N」と同じです。
このフラグは、ヘッダーと明細の両レベルにあります。
記帳済フラグ
インポート後に当該受注を記帳済にする場合は、このフラグを「Y」に設定します。デフォルトは「N」で、NULL値は「N」と同じです。
このフラグが使用できるのは、ヘッダー・レベルのみです。
拒否フラグ
これ以上の処理は不要と判断した受注または受注明細が生じる場合があります。この場合は、受注インポートの「訂正」ウィンドウを使用して、処理が不要な受注または明細を選択し、「ステータス」タブに移動して、「拒否済」チェック・ボックスをオンにします。拒否された受注または受注明細は、受注インポート・プログラムの次の実行時に削除されます。デフォルトは「N」です。NULL値は「N」と同じです。
このフラグは、ヘッダーと明細の両レベルにあります。
ERROR_FLAG
検証処理中にエラーが発生した場合、受注インポート・プロセスによって設定されます。デフォルトは「N」です。NULL値は「N」と同じです。
このフラグは、ヘッダーと明細の両レベルにあります。
READY_FLAG
準備完了フラグ。レコードが受注インポート・プロセスの対象になっていることを示します。デフォルトは「Y」です。NULL値は「Y」と同じです。このフラグが「N」の場合、その受注は、受注インポートの実行時に参照されません。
このフラグは、ヘッダー・レベルにあります。
コンカレント・マネージャの検証モード・パラメータ
検証モード・パラメータは、コンカレント・マネージャを介して実行する受注インポートを発行するときに設定できます。このパラメータは、レコードの検証のみを行い、有効なレコードに対してはそれ以上の処理を行わないことをプロセスに指示します。Order Managementベース表では、レコードの挿入、更新または削除は行いません。
READY_FLAG | (限定) 検証 パラメータ | 処理 |
---|---|---|
N | Y | レコードは処理されません。 |
N | N | レコードは処理されません。 |
YまたはNULL | Y | 検証のみの処理。 |
YまたはNULL | N | ベース表での挿入/更新/削除処理。 |
処理表
処理表は、受注管理インタフェース表の1つです。この表によって、Order Managementベース表に挿入された受注に対して実行する処理内容を示すことができます。これは、受注インポートでユーザーが受注を入力後、「受注」ウィンドウの「処理」ボタンを押す操作と同じです。この処理表のOPERATION_CODE列に処理名をロードし、必要に応じて他のデータを挿入すると、受注インポートが正常に終了している場合、受注処理はその処理を実行します。この方法を使用すると、保留状態の受注または明細を保留または解除できます。これは受注インポートを介して受注を記帳する1つの方法であり、他に実行できる処理には、「自動添付の適用」、「構成品目のリンク解除」および構成品目の照合と予約などがあります。次に、OE_ACTIONS_INTERFACE表のOPERATION_CODEに挿入する必要がある文字列と、各処理を実行するために、この表に入力する必要がある他のデータを示します。
処理 | OPERATION_CODE | 他のデータ |
---|---|---|
自動添付の適用 | AUTOMATIC_ATCHMT | なし |
保留の適用 | APPLY_HOLD | hold_id、hold_type_code、hold_type_id、コメント(オプション)、hold_until_date(オプション) |
保留の解除 | RELEASE_HOLD | hold_id、hold_type_code、hold_type_id、コメント(オプション)、release_reason_code |
受注の記帳 | BOOK_ORDER | なし |
構成品目のリンク解除 | DELINK_CONFIG | なし |
ATOモデルに対する構成品目の照合と予約 | MATCH_AND_RESERVE | なし |
インタフェース表の属性には、コードまたは名前とIDの2つがあります。各属性にはコードまたはIDのいずれかを挿入できます。IDを挿入すると、パフォーマンスが向上します。1つの属性にIDとコードの両方を挿入した場合は、IDが使用され、「コード」フィールドの値は無視されます。
受注インポートを使用して受注変更を送信する場合は、変更対象の受注または明細を受注インポートに通知する方法が必要です。ユーザーのフィード・システムが、Order Managementの受注番号を認識している可能性はほとんどありません。認識している場合は、インタフェース列ORDER_NUMBERを挿入して、対象の受注を検索できます。インタフェース表には受注表に移される列のグループがあるため、これらの列を使用して変更対象の受注を検索します。
受注レベルの変更については、次のフィールドがインタフェース表の変更取引と受注表の既存の受注の間で一致している必要があります。
ORIG_SYS_DOCUMENT_REF - 多くの場合、顧客の発注番号です。
ORDER_SOURCE_ID
明細レベルの変更については、次のフィールドがインタフェース表の変更取引と受注表の既存の受注の間で一致している必要があります。
ORIG_SYS_DOCUMENT_REF - 多くの場合、顧客の発注番号です。
ORDER_SOURCE_ID
ORIG_SYS_LINE_REF - 多くの場合、顧客の発注明細番号と出荷番号または現在の顧客要求日が連結したものです。
既存の受注または明細にこれらのフィールドが挿入されていない場合、受注インポートを使用して既存の受注または明細を変更することはできません。
変更順序番号は、受注に適用する一連の変更の順序を制御する方法です。受注インポートでの変更順序番号の使用は省略できます。変更順序番号を最も頻繁に使用するのは、EDI発注変更取引ですが、レガシー・システムやサード・パーティ・システムから変更をインポートする場合に、その変更の適用順序を制御するためにも使用できます。変更順序番号の使用方法の詳細は、『Oracle Order Managementユーザーズ・ガイド』を参照してください。