Oracle Order Managementインプリメンテーション・マニュアル リリース11i B25742-01

目次

戻る

次へ

アップグレード

Oracle Order Management 11iへのアップグレード

Oracle Order Management 11iのアップグレード・モジュールでは、Oracle Order Entry製品がOracle Order Managementにアップグレードされます。このモジュールにより、データがOracle Order EntryシステムからOracle Order Management 11iシステムに移行されます。

この章に記載されているステップ/ヒントは、Oracle Order Managementのアップグレードにのみ関連するもので、Oracle Order Managementとともにインストールまたはアップグレードする他の製品に関するステップに追加して実行する必要があることに注意してください。

Oracle Applicationsシステムをリリース11iにアップグレードする手順の詳細は、『Oracle Applicationsのアップグレード』を参照してください。

Order Managementファミリには、Order Management、Oracle Shipping ExecutionおよびOracle Advanced Pricingの3つの製品があります。各製品の表には、次のプリフィクスが付いています。

• Order ManagementのプリフィクスはOMです。

• Oracle Shipping ExecutionのプリフィクスはWSHです。

• Oracle Advanced PricingのプリフィクスはQPです。

方法

Oracle Order Managementをインストール対象として選択すると、「Oracle APPSのインストール/アップグレード」の実行中に、このモジュールが起動します。その間に、データベース・サーバー側のコードとクライアント側のコードが、Oracle Order Managementインストール・プロセスの一部としてAPPS環境に適用されます。APPS環境にOracle Order Entryリリース10.7/11.0製品がすでにインストールされている場合は、Oracle Order Managementアップグレード・プロセスが起動します。

Oracle Order Managementのアップグレードにより、設定表が表ごとに移行されますが、取引表はビジネス・オブジェクトごとに移行されます。受注（ヘッダー、明細、価格調整および販売実績）は、ビジネス・オブジェクトとみなされます。

アップグレード時には、最初にヘッダー、次にすべての明細、その価格調整および販売実績の順に移行されます。同じ受注に関するデータのいずれかの部分の移行中にエラーがトラップされると、その受注全体のアップグレードが拒否され、エラー・ログがエラー表OE_UPGRADE_ERRORSに記録されます。正常に移行された受注は、すべてコミットされます。

また、アップグレードでは、アップグレード済取引のパラレル分散も使用され、ほとんどの取引のアップグレードが32のパラレル・プロセスにより書き込まれて処理されます。これにより、使用可能なCPUの使用率を最大限まで高めることができます。

Oracle Order Managementアップグレードの分岐

Oracle Order Management 11iアップグレードの分岐は、Oracle Order Management 11iアップグレードのお客様が使用可能なオプション機能です。これは、大量の受注管理データがあり、Oracle Order Managementのアップグレードを最短のシステム停止時間で完了する必要のあるお客様に対するソリューションを提供します。受注管理取引を限られた時間内でアップグレードできるように、分岐オプションでは11iのアップグレード・プロセス中に有効な取引のみが選択されます。無効な取引は、プロセスの完了後にアップグレード後ステップとしてアップグレードされるか、システムが稼働用にリリースされた後にアップグレードされます。この分岐は、Oracle Order Management、Oracle Shipping ExecutionおよびOracle Advance Pricingデータの取引のアップグレードに影響します。

分岐機能は、2つのフェーズで実行されるように設計されています。最初のフェーズはAutoUpgradeの実行前に適用され、Oracle Order Management、Oracle Shipping ExecutionおよびOracle Advanced Pricingシステム内で有効な取引が識別され、リリース11iのアップグレード・プロセス中にアップグレード対象となるようにマークされます。

分岐フェーズIIは、アップグレード後のステップとして、または11iシステムが稼働用にユーザーにリリースされた後に適用されます。この第2のフェーズでは、分岐したリリース11i Oracle Order Managementのアップグレードで残った無効な取引が実際にアップグレードされます。

Oracle Order Managementの分岐アプローチによる影響

分岐は、限られたシステム停止時間内にOracle Order Managementをアップグレードするための優れたソリューションですが、無効な受注のアップグレードを遅延させるように選択すると、そのレポート、フォームおよび他のユーザー・インタフェース・ツールは、アップグレードされるまで無効な受注にアクセスできなくなることに注意してください。したがって、分岐フェーズIIは、11iシステムのリリース後できるだけ早期に適用することをお薦めします。

受注ごとの明細が数千であり、システムに受注が少数しかないお客様の場合、この分岐にはメリットがありません。

対象ユーザー

この章は、アップグレードするお客様のみを対象としています。

対象となるのは、Oracle Order Entryリリース10.7/11.0をインストール済で、Oracle Order Management 11iへのアップグレードを希望するお客様です（Oracle Order Management 11iのアップグレードでは、Oracle Order Entryリリース10.7/11.0以外のバージョンは、Oracle Order Managementのアップグレード対象としてサポートされていません）。

Oracle Order Management 11iにアップグレードするためのステップ

次のステップは、すでにアップグレード・ガイドに記載されている場合や、アップグレード・ガイドの記載内容に対する単なる追加ステップの場合があります。次のステップはOracle Order Managementのアップグレードに関連する追加ステップ、またはアップグレード・ガイドに従ったOracle Applicationsリリース11iのアップグレードを実行中のチェック・ポイントとみなす必要があります。この項で説明するステップの詳細は、オラクル・サポート・ホームページ経由で入手できるホワイト・ペーパー『Oracle Order Management Upgrade』（ノートID: 121200.1）を参照してください。

1. Oracle Applications 11i製品とサポート用マニュアルを注文します。

   営業担当に連絡し、Oracle Applicationsリリース11i製品を注文します。アップグレード・ガイドを入手済であるかどうかを確認してください。

2. Oracle Order Managementのアップグレード前ステップ（カテゴリ1）を実行します。

   アップグレード・ガイドを入手した後で、ソフトウェアをダウンロードする前に、必要なアップグレード前ステップを実行します。これらのステップについては、「Order Management Pre-Upgrade Tasks」の「Category 1」および「Category 2」を参照してください。これらのステップは、Oracle Order Entryリリース10.7/11.0が稼働中で使用中でも実行できます。つまり、これらのステップの実行中にも、ユーザーはアプリケーションにログインできます。

3. APPS 11iソフトウェアをダウンロードします。

   APPS 11iソフトウェアをダウンロードします。ダウンロードしたソフトウェアには、すべてのOracle Order Managementアップグレード関連ファイルが含まれています。このソフトウェアにより新規のAPPL_TOPが作成され、ここに11iをダウンロードし、Auto-Upgrade/Patchesの実行とアプリケーションへのアクセスに使用します。

4. 必要な場合は、アップグレード前ステップ用にOrder Management Upgrade Mandatory Patchを適用します。

   ソフトウェアのダウンロード後にパッチ1471461を適用する必要があるかどうかは、取得したドット・リリース・バージョンに応じて異なります。このステップオン詳細は、『Order Management Upgrade』ホワイト・ペーパーを参照してください。このドキュメントは、オラクル・サポート・ホームページ経由で入手できます（ドキュメントID: 121200.1）。

5. Oracle Order Managementのアップグレード前ステップ（カテゴリ2）を実行します。

   APPS 11iソフトウェアのダウンロード後に、Oracle Order Managementアップグレード前ステップのカテゴリ2を実行する必要があります。これらのステップを実行できるのは、ソフトウェアのダウンロード後のみですが、システムが稼働中でユーザーがログインしたままでかまいません。システム停止時間は不要です。

6. Oracle Order Managementのアップグレード前ステップ（カテゴリ3）を実行します。

   この段階で、Oracle Order Entryリリース10.7/11.0製品の稼働を終了します。これらのステップの実行中は、ユーザーをログインさせないでください。このカテゴリに記載されている一部のステップは、カテゴリ2に記載されているステップの繰返しです。また、一部のステップでは、アップグレード前データをチェックして、Oracle Order Managementのアップグレードでサポートされるかどうかを確認するように要求されます。記載されているステップを実行し、サポート対象外のデータを含む受注があるかどうかを確認してください。この種の受注が存在する場合は、リリース11iのAutoUpgradeに進む前に、Oracle Order Entryシステムにログインして該当データを訂正する必要があります。この訂正を行わないと、サポート対象外のデータがOracle Order Management 11iにアップグレードされない恐れがあります。また、Oracle Order Managementの起動後はOracle Order Entryリリース10.7/11.0が機能しなくなるため、この種のデータを訂正する機会がなくなります。

7. Oracle Order Managementアップグレードを分岐させる場合は、パッチ1393123（分岐フェーズI）を適用します。

   Oracle Order Managementアップグレードの分岐アプローチを使用しない場合は、このステップをスキップしてください。

   注意: このパッチを適用すると、有効な受注管理取引のみがリリース11iのアップグレード中にアップグレードされます。リリース11iのアップグレード・プロセスの後で分岐フェーズIIのパッチを適用し、有効でない受注管理取引のアップグレードを完了する必要があります。このパッチを適用する前に、Oracle Order Managementアップグレードの分岐アプローチを選択していることを確認してください。

   オラクル・サポート・ホームページからパッチ1393123をダウンロードし、カテゴリ3のアップグレード前ステップとして（パッチのreadme.txtの指示に従って）適用します。このパッチをカテゴリ2のアップグレード前ステップとして（Oracle Order Entryシステムをアップグレード用にシャットダウンする前に）実行することもできますが、このステップはカテゴリ3のアップグレード前ステップとして繰り返すことをお薦めします。このようにして繰り返さなくてもアップグレードは失敗しませんが、前回パッチを適用してからシステムを停止させるまでに記録された無効な取引は、有効な取引として扱われます。

   このパッチには、一連の手動ステップが含まれています。このパッチを何度か適用する計画がある場合は、ファイルを（パッチを初めて適用するときに）コピーし、パッチの再実行が必要になるたびに他の手動手順を繰り返すのみで済みます。

   手動ステップであるSQLスクリプトontup293.sqlを実行するには、コマンドラインでスクリプト名とともにパラメータを指定する必要があります。このパラメータは、受注がクローズされてからの期間を示します。実際には、このスクリプトとともに数値を渡す必要があります。数値60を渡すと、過去60日以内にクローズされた受注も、分岐に使用するために有効な取引とみなされます。このオプションを使用しない場合は、このスクリプトのパラメータとして数値0を使用してください。このパラメータを指定しないと、スクリプトは失敗するため、パッチのreadme.txtに慎重に従ってください。

8. AutoUpgradeの前に、Oracle Order Managementに必要な非受注管理パッチを適用します。

   次の各パッチは非受注管理パッチですが、Oracle Order Managementアップグレードの前提条件であり、AutoUpgradeの起動前に適用する必要があります。

   1253654（データベース8.1.6.1のパッチ）

   1323676（FNDのパッチ）

   注意: このリストは、このマニュアルの作成時点のものであり、完全ではありません。適用する必要のあるパッチの詳細は、オラクル・サポート・ホームページをチェックしてください。次はARU（パッチ）であり、ARU番号はオペレーティング・システムのプラットフォームごとに異なる場合があります。

9. AutoUpgradeを実行します。

   アップグレード前ステップのカテゴリ1〜3が完了し、優先度の高いパッチを適用すると、AutoUpgradeを実行する準備が完了したことになります。これについては、アップグレード後ステップのカテゴリ4でも、最後のステップとして言及しています。Auto-Upgradeの初期化中に、ライセンスを購入済でインストールする製品をすべて選択してください。Oracle Order Managementアップグレードでは、Oracle Order Management製品のアップグレードに関するメッセージが表示されるため、この章ではOracle Order Management製品のアップグレード・ライセンスを購入していることを前提としています。インストール対象製品のリストから、Oracle Order Management製品を選択します。Oracle Shipping Execution（製品コードWSH）が自動的に選択されない場合は、Oracle Order Management（製品コードONT）とともにインストール対象として選択してください。以前にインストール済のOracle Order Entryリリース10.7/11.0があると、このフェーズ中にOracle Order Managementアップグレードが自動的に起動します。Oracle Advanced Pricing（製品コードQP）のライセンスを購入している場合は、AutoUpgradeで次に進む前にQPもインストール対象として選択してください。

10. 必要な場合は、Order Management Upgrade Mandatory Patchを適用します（11iのOracle Order Managementアップグレードの場合のみ）。

    ドット・リリース用のデータベース・パッチを適用する前に、パッチ1471540、1537129、1310156、1311832、1324853および1324884を適用する必要があります。このうち、どのパッチが必要であるかは、使用するドット・リリースに応じて異なります。このステップの詳細は、『Order Management Upgrade』ホワイト・ペーパーを参照してください。

11. 11iのデータベース・アップグレード・パッチを適用します。

    このパッチ用のドライバはソフトウェアに付属しています。ドライバ・ファイルの名前と場所の詳細は、11iのアプリケーション・ソフトウェアのリリース・ノートを参照してください。

12. アップグレード後ステップを実行します。

    アップグレード・ガイドに説明されているその他のアップグレード後ステップを実行します。

13. Order Management Minipackを適用します。

    使用中のドット・リリースに基づいて、パックA、パックBなど、該当するOrder Management Minipackを適用します。このステップの詳細は、『Order Management Upgrade』ホワイト・ペーパーを参照してください。このドキュメントは、オラクル・サポート・ホームページ経由で入手できます（ドキュメントID: 121200.1）。

14. Oracle Order Managementアップグレードを分岐させている場合は、パッチ1393247（分岐フェーズII）を適用します。

    （Oracle Order Managementアップグレードの分岐アプローチを使用しない場合は、このステップを無視してください。）

    注意: このパッチを適用する必要があるのは、アップグレード前ステップとしてパッチ1393123を適用し、Oracle Order Managementアップグレードの分岐アプローチを選択した場合のみです。

アップグレード後ステップとして、またはアップグレードしたリリース11iシステムのリリース後に、パッチ1393247を適用し、Oracle Order Managementアップグレードの分岐によりリリース11iのOracle Order Managementアップグレード・プロセスでアップグレードされなかった残りの取引をアップグレードします。

パッチ・アプリケーションから、コピーしたドライバとデータベース・ドライバを適用するように要求されます。手順は、パッチのreadme.txt内の指示を参照してください。

このパッチの完了には数時間かかる場合もありますが、システムの稼働中にパラレルで実行できるため、システム停止時間は不要です。

Oracle Order Managementアップグレードの概要

Oracle Order Entryリリース10.7/11.0からOracle Order Management 11iの間で、アーキテクチャが大幅に変更されています。Oracle Order Managementアップグレードは、Oracle Order Entryリリース10.7/11.0からOracle Order Management 11iへのデータの移行のみを取り扱います。Oracle Order ManagementとOracle Order Entryではデータ・モデルが大幅に異なるため、データは表単位でのみ移行されます。

Oracle Order Managementのアップグレード中に発生する一部の機能の移行の概要について、次で説明します。

一時オブジェクトのアップグレード

次の各オブジェクトが作成され、アップグレード中にのみ使用されます。アップグレード後にOracle Order Managementで使用されたり、他の機能を提供することはありません。各オブジェクトは次のとおりです。

OE_UPGRADE_LOGは、旧明細IDとアップグレード中に作成される新明細ID間のマッピングを含む表です。この表および関連ビューOE_UPGRADE_LOG_Vを使用すると、アップグレード前とアップグレード後の受注明細のステータスに関する履歴情報を検索できます。この表は、新規に作成される明細やヘッダーごとに1行ずつ含まれるため、非常に大きくなると予想されます。

OE_UPGRADE_WSH_IFACEは、アップグレード中に出荷情報が移入されて後続のアップグレード機能で使用されるアップグレード表です。この表は、予想される新規明細ごとに1つずつレコードが含まれるため、非常に大きくなると予想されます。

OE_UPGRADE_WF_ACT_MAPは、循環処理とそれに相当するワークフロー処理間のマッピング情報を含む、ワークフロー・アップグレード・マッピング表です。この表はアップグレード中に移入され、アップグレード中にのみ使用されます。OE_UPGRADE_WF_HIST_TEMP、OE_UPGRADE_WF_MULGRP_V、OE_UPGRADE_WF_OBS_CODES、OE_UPGRADE_WF_VLD_CYC、OE_UPGRADE_WF_VLD_CYC_Vは、Oracle Workflowのアップグレード中に使用されるその他のアップグレード表です。

OE_UPGRADE_ERRORSはエラー格納表であり、アップグレード中にエラーがトラップされると移入されます。コメント列には、発生したエラーの説明が保持されます。この表のサイズは、トラップされるエラーによって異なります。

CPUの使用率を最大限にするため、移行対象のグループは事前に決定された数の均等グループにグループ化され、その詳細がOE_UPGRADE_DISTRIBUTION表に格納されます。アップグレード・コードが同時に2度以上実行され、コード断片は分散表を参照し、移行対象となるデータのグループを選択します。この方法は、受注、保留、ワークフロー履歴、無効なデータのマーク付け、運送手数料およびサービス明細詳細のアップグレードに使用されます。

表OE_UPGRADE_PC_ATTR_MAP、OE_UPGRADE_PC_CONDNS、OE_UPGRADE_PC_SCOPE、OE_UPGRADE_PC_TEMPは、現在は使用されませんが、このソフトウェアの将来のバージョンで使用される表です。

表QP_UPGRADE_ERRORSは、アップグレード中にエラーが発生した場合に移入されます。ERROR_MODULE列では、価格表や値引など、エラーが発生したモジュールが指定されます。ERROR_TYPE列では、ERROR_MODULE内のエラーの詳細を示します。ERROR_DESC列は、エラーの説明を示します。

表QP_DISCOUNT_MAPPINGは、旧値引IDから新値引IDへのマッピングに使用されます。

SO_PRICE_LISTS_B（価格表）内のレコードごとに、QP_LIST_HEADERS_BおよびQP_LIST_HEADERS_TLにレコードが作成されます。QP_LIST_HEADERS_BおよびQP_LIST_HEADERS_TL内で新規レコードが作成されるときには、SO_PRICE_LISTS_B内の旧PRICE_LIST_IDが保たれます。また、アップグレード対象の価格表は、SO_PRICE_LISTS_Bに指定された第2価格表のクオリファイアとして作成されます。旧値引リストと新値引リストおよび明細間のマッピングは、QP_DISCOUNT_MAPPINGに格納されます。

表QP_UPG_LINES_DISTRIBUTIONは、価格表ID、値引ID、基本契約ID、価格設定ルールIDを32のワーカー間で分散させるために使用されます。これは、アップグレードをパラレルで実行してパフォーマンスを改善するためです。

受注ヘッダー

SO_HEADERS_ALL表は、Oracle Order ManagementのOE_ORDER_HEADERS_ALL表に移行されますが、SO_HEADER_ATTRIBUTES表もOE_ORDER_HEADERS_ALL表自体にマージされます。ヘッダーIDは移行中に保たれます。新規順序のOE_ORDER_HEADERS_Sは、Oracle Order Entryの等価の順序であるSO_HEADERS_S内の最大値でリセットされ、すべての新規受注用にOE_ORDER_HEADERS_ALL表内でヘッダーIDを生成するために使用されます。

受注明細

SO_LINES_ALL表はOE_ORDER_LINES_ALL表に移行されますが、表SO_LINE_ATTRIBUTESおよびSO_LINE_DETAILSもOE_ORDER_LINES_ALL表にマージされます。明細詳細の概念はOracle Order Management 115で廃止になり、ピッキング詳細は明細レベルで格納されるようになったため、それぞれの旧明細（SO_LINES_ALL表内の明細）は1つ以上の新規明細（OE_ORDER_LINES_ALL内の明細）に変換されます。旧明細が複数の新明細に移行されるときに、旧明細IDは新明細の先頭に保たれます。新明細の残りの部分には、新規に生成された明細IDが割り当てられます。新規の順序であるOE_ORDER_LINES_Sは、それに相当するOracle Order Entryの順序であるSO_LINES_S内の最大値でリセットされ、OE_ORDER_LINES_ALL表内で明細IDを生成するために使用されます。SO_LINES_ALL表の付加フレックスフィールド定義は、OE_ORDER_LINES_ALL表に転送されます。

受注明細履歴

これは新しい表であり、アップグレード中に移入されます。この表には主に取消レコードが格納されるため、SO_ORDER_CANCELLATIONSのレコードがこのOE_ORDER_LINES_HISTORY表に移行されます。

価格調整

SO_PRICE_ADJUSTMENTS表は、OE_PRICE_ADJUSTMENTS表に移行されます。アップグレード中に、ヘッダー・レベルの価格調整はレコード単位で移行されますが、明細レベルの価格調整は、旧価格調整レコードごとに複数のレコードになる場合があります。旧明細に価格調整レコードがあった場合は、新規に作成された受注明細ごとに、OE_PRICE_ADJUSTMENTS表に価格調整レコードが生成されます。作成される新規レコード・セットの先頭に旧価格調整IDが保たれますが、残りのレコードのIDはアップグレード中に生成されます。新規の順序であるOE_PRICE_ADJUSTMENTS_Sは、それに相当するOracle Order Entryの順序であるSO_PRICE_ADJUSTMENTS_S内の最大値でリセットされ、OE_PRICE_ADJUSTMENTS表内で価格調整IDを生成するために使用されます。

販売実績

SO_SALES_CREDITS表は、OE_SALES_CREDITS表に移行されます。アップグレード中に、ヘッダー・レベルの販売実績はレコード単位で移行されますが、明細レベルの販売実績は、旧販売実績レコードごとに複数のレコードになる場合があります。旧明細に販売実績レコードがあった場合は、新規に作成された受注明細ごとに、OE_SALES_CREDITS表に販売実績レコードが生成されます。作成される新規レコード・セットの先頭に旧販売実績IDが保たれますが、残りのレコードのIDはアップグレード中に生成されます。新規の順序であるOE_SALES_CREDITS_Sは、それに相当するOracle Order Entryの順序であるSO_SALES_CREDITS_S内の最大値でリセットされ、OE_SALES_CREDITS表内で販売実績IDを生成するために使用されます。

明細セット

Oracle Order Entryの明細がSO_LINE_DETAILS表に複数のレコードを持っている場合、複数のピッキング詳細がある場合または複数の出荷に分割されている場合は、Oracle Order Managementで明細セットが作成されます。アップグレードにより、この種のケースごとにOE_SETS_S表に明細セット・レコードが作成されます。この新規に作成された明細セットは、Oracle Order Entry内の該当する旧明細レコードから作成されるすべての新規明細レコード内で更新されます。セットIDは、新規の順序であるOE_SETS_Sから生成されます。

出荷セット

出荷セットIDは、新規の順序であるOE_SETS_Sから生成されます。

サイクルからワークフローへ

リリース10.7/11.0で、オープン・ヘッダーまたはオープン明細で参照されていたサイクルは、すべてがワークフロー・プロセスに変換されます。ヘッダー・レベルと明細レベルの処理を含むサイクルは、ヘッダー・レベルのワークフローと明細レベルのワークフローに別個に変換されます。サイクル処理は、これらのワークフロー内のワークフロー・アクティビティに変換されます。アップグレードでは、作成された該当ワークフローに受注と明細が適切に割り当てられます。また、すべてのオープン受注とオープン明細の履歴も作成されます。クローズ済の受注や明細については、ワークフロー履歴は作成されません。

取引タイプ

取引タイプはリリース11iではMLSに対応しています。リリース10.7からの名前は_TL表に移されます。

SO_ORDER_TYPES_ALL表は、受注タイプおよび明細タイプとして、SO_ORDER_TYPES_ALL表内の受注タイプごとにOE_TRANSACTION_TYPES_ALL表に移行されます。OE_TRANSACTION_TYPES_ALL表には、1つの受注タイプ・レコードと1つ以上の明細タイプ・レコードが含まれることになります。リリース11iのOE受注明細は、SO明細、SO明細詳細およびSOピック詳細から移入されます。

取引タイプに対するワークフローの割当は、OE_WORKFLOW_ASSIGNMENTS表内で作成されます。順序SO_ORDER_TYPES_SはOE_TRANSACTION_TYPES_S順序に置き換えられ、OE_WORKFLOW_ASSIGNMENTS表用のキーが生成されるように新規の順序であるOE_WF_ASSIGNMENTS_Sが導入されます。

運送費

表SO_FREIGHT_CHARGESはOE_PRICE_ADJUSTMENTS表に移行され、表SO_FREIGHT_CHARGE_TYPESはQP_LIST_HEADERS_B、QP_LIST_HEADERS_TLおよびQP_LIST_LINES表に移行されます。順序SO_FREIGHT_CHARGES_SおよびSO_FREIGHT_CHARGE_TYPES_Sは、Oracle Order Managementリリース11iでは廃止になりました。

直接出荷のソース

SO_DROP_SHIP_SOURCES表は、OE_DROP_SHIP_SOURCES表に移行されます。新規の表OE_DROP_SHIP_SOURCESには、SO_DROP_SHIP_SOURCES表内で参照される旧受注明細用に作成される新規受注明細の数に応じて、旧表SO_DROP_SHIP_SOURCES内のレコードごとに複数のレコードが含まれる場合があります。順序SO_DROP_SHIP_SOURCES_Sは、OE_DROP_SHIP_SOURCES_S順序に置き換えられます。

保留

SO_HOLD_SOURCES_ALL表はOE_HOLD_SOURCES_ALLに、SO_HOLD_RELEASES表はOE_HOLD_SOURCES表に、SO_ORDER_HOLDS_ALL表はOE_ORDER_HOLDS_ALL表に、SO_HOLD_DEFINITIONS表はOE_HOLD_DEFINITIONS表に、それぞれ移行されます。受注明細に関するレコードの移行時には、旧受注明細用に作成される新規受注明細の数に応じて、複数のレコードが挿入される場合があります。順序SO_HOLD_DEFINITIONS_S、SO_HOLD_RELEASES_S、SO_HOLD_SOURCES_SおよびSO_ORDER_HOLDS_Sは、それぞれ順序OE_HOLD_DEFINITIONS_S、OE_HOLD_RELEASES_S、OE_HOLD_SOURCES_SおよびOE_ORDER_HOLDS_Sで置き換えられます。

与信チェック

表SO_CREDIT_CHECK_RULESはOE_CREDIT_CHECK_RULESに、表SO_CREDIT_CHECK_TYPES_ALLはOE_CREDIT_CHECK_TYPES_ALL表に移行されます。順序SO_CREDIT_CHECK_RULES_Sは、順序OE_CREDIT_CHECK_RULES_Sに置き換えられます。

サービス導入詳細

データは、SO_LINE_SERVICE_DETAILSからCS APIを通じてCS製品（CRM）に移行されます。

価格表

SO_PRICE_LISTS_Bのデータは、QP_LIST_HEADERS_B（LIST_TYPE_CODE = ‘PRL'）およびQP_LIST_HEADERS_TLに移行されます。SO_PRICE_LIST_LINES_115のデータは、QP_LIST_LINES（LIST_LINE_TYPE_CODE='PLL'）に移行されます。

値引

SO_DISCOUNTSのデータは、QP_LIST_HEADERS_B（LIST_TYPE_CODE = ‘DLT'）、QP_LIST_HEADERS_TLおよびQP_LIST_LINES（LIST_LINE_TYPE_CODE='DIS'）に移行されます。SO_DISCOUNT_LINES_115のデータは、QP_LIST_LINES（LIST_LINE_TYPE_CODE='DIS'）に移行されます。SO_PRICE_BREAK_LINESのデータはQP_LIST_LINES（LIST_LINE_TYPE_CODE='DIS'または‘PBH'）に、SO_DISCOUNT_CUSTOMERSのデータはQP_QUALIFIERSに移行されます。

基本契約

SO_AGREEMENTS_BおよびSO_AGREEMENTS_TLのデータは、OE_AGREEMENTS_BおよびOE_AGREEMENTS_TLに移行されます。

価格設定ルール

SO_PRICING_RULESのデータは、QP_PRICE_FORMULAS_BおよびQP_PRICE_FORMULAS_TLに移行されます。SO_RULE_FORMULA_COMPONENTSのデータは、QP_LIST_HEADERS_BおよびQP_LIST_HEADERS_TLに移行されます。SO_PRICING_RULE_LINE_VALUESのデータはQP_LIST_LINESおよびQP_PRICING_ATTRIBUTESに、SO_PRICING_RULE_LINESのデータはQP_PRICE_FORMULA_LINESに移行されます。

プロファイル・オプション

107/110のOEシステムから、新規のOMプロファイルOE_ID_FLEX_CODE、ONT_SOURCE_CODE、OE_INVENTORY_ITEM_FOR_FREIGHT、OE_INVOICE_FREIGHT_AS_LINEが移行されます。

Oracle Order Managementアップグレードの分岐

分岐フェーズI

このフェーズでは、SO_HEADERS_ALL表のUPGRADE_FLAG列がマークされ、無効な取引の値がすべて‘D'に、有効な取引の値がすべて‘N'になります。SO_HEADERS_ALL表のUPGRADE_FLAGを手掛かりにして、出荷表と価格設定表が有効または無効としてマークされます（UPGRADE_FLAG列は、ヘッダーとその依存オブジェクトのアップグレード後に、受注管理取引アップグレードにより‘Y'に更新されることに注意してください）。

有効な受注管理取引を定義するには、次の条件をチェックする必要があります。これらの条件を満たすヘッダーは、有効な取引とみなされます。

• すべてのオープン受注

• オープン受注で参照されるすべてのクローズ済受注

• 1つ以上のオープン受注がある搬送の一部となっているすべてのクローズ済受注

• 顧客がパッチ1393123の適用時にクローズ済受注の経過期間オプションで指定した日数の範囲内でクローズされたすべてのクローズ済受注

分岐フェーズII

フェーズIIでは、値DになっているUPGRADE_FLAGが‘N'に設定され、アップグレード・コード・セットが実行され、無効な取引がOracle Order EntryからOracle Order Managementにアップグレードされます。このアップグレード・セット・コードでは、サイクルからワークフローへのアップグレードは対象外のため、有効な受注（主としてオープン受注）をアップグレードするようには設計されていません。無効な（クローズ済）取引のみをアップグレードするように設計されています。

Oracle Order Managementアップグレードの微調整

表や索引など、Oracle Order Management/Oracle Pricing/Oracle Shippingのオブジェクトに独自のサイズ設定パラメータの使用を必要とする場合があります。アップグレードでは、3つのファイルが実行され、この3製品のオブジェクトのオブジェクト・サイズ設定パラメータが設定されます。各ファイルを次に示します。領域要件を完了しているか、オブジェクトのサイズ設定について独自の標準に従おうと考えている場合は、AutoUpgradeを起動する前に、これらのファイルをオブジェクトのサイズ設定パラメータで編集できます。この変更は、リリース11iのアップグレード前ステップの最終ステップとして実行できます。各ファイルを編集しないと、オブジェクトは見積に従ってサイズ設定されます。

オブジェクト・サイズ設定ファイル

Oracle Order Management: $ONT_TOP/patch/115/sql/ontdbprm.sql

Oracle Advanced Pricing: $QP_TOP/patch/115/sql/qpdbprm.sql

Oracle Shipping Execution: $WSH_TOP/patch/115/sql/wshdbprm.sql

オブジェクト・サイズ設定の見積

領域要件の比較（Oracle Order EntryとOracle Order Management）

アップグレード対象取引の領域セットについて、Oracle Order Entryリリース10.7/11.0とOracle Order Management 11iの使用領域の概算比較を次に示します。

注意: 後述のデータは、あくまでも概算であり、少数の大型Oracle Order Managementアップグレードから統計を収集して導出されたものです。

1対1の移行を示す表のほとんどの場合、領域要件は以前のOracle Order Entryリリースのデータベースとほぼ同じで、変動は10%（+/-）です。

原則として、次のデータについては10%（+/-）の変動を見込むことをお薦めします。

サイクルのワークフローへの移行

Oracle Order Managementでは、Oracle Workflowを使用して受注サイクル機能を実装します。この章では、次のアップグレードの方法について説明します。

• 受注タイプを受注取引タイプと明細取引タイプにアップグレードする方法

• 受注番号ソースをAOL文書連番にアップグレードする方法

• ユーザー定義サイクル・データをOracle Workflowの設計時のエンティティにアップグレードする方法

• 受注タイプ - サイクル割当を取引タイプ - ワークフロー割当にアップグレードする方法

• オープン状態の受注および明細に関するサイクル履歴をOracle Workflowの項目アクティビティ・ステータス履歴にアップグレードする方法

Oracle Workflowと受注サイクルの機能の違い

Oracle Order Managementリリース11iでは、受注サイクルがワークフローに置き換えられています。受注サイクル、サイクル処理および承認サイクル処理は廃止になりました。受注の処理期間中に実行される一連のアクティビティを決定するワークフロー・プロセスを定義できます。サイクル処理はこの種のワークフロー・アクティビティに置き換えられ、承認処理はワークフロー通知アクティビティに置き換えられます。次の表に、サイクル・エンティティとリリース11iのワークフローとのマッピングを示します。

注意: ワークフロー・アクティビティ、サブプロセスの推移および通知の詳細は、『Oracle Workflowユーザーズ・ガイド』を参照してください。

次に、一般的な受注ヘッダー・ワークフロー・プロセスの例を示します。

一般的な受注ヘッダー・ワークフロー・プロセス

次の図に、一般的な受注明細ワークフロー・プロセスの例を示します。

一般的な受注明細ワークフロー・プロセス

受注タイプのアップグレード

Order Entryの受注タイプは、ソース管理と取引管理をデフォルト設定するためのプールとしての役割を果たしていました。Oracle Order Managementでは、多数のヘッダー属性を明細で使用でき、明細レベルで管理できます。アプリケーションでは、受注タイプと同様のエンティティを明細に対しても提供しています（明細タイプ）。Oracle Order Managementでは、受注タイプと明細タイプはいずれも取引タイプと呼ばれます。

Order Entryで定義済の受注タイプは、Order Managementの受注取引タイプに自動的にアップグレードされます。受注カテゴリがRまたはPの受注タイプは受注カテゴリの受注取引タイプに、受注カテゴリがRMAの受注タイプは返品カテゴリの受注取引タイプに、受注カテゴリが指定されていない受注タイプは混合カテゴリの受注取引タイプにそれぞれアップグレードされます。混合受注タイプを使用して受注を作成すると、受注明細と返品明細をその受注内で組み合せることができます。

アップグレードされた受注タイプには、アップグレード前の元の受注タイプと同じ名前が付けられます。受注タイプで使用するヘッダー・ワークフロー・プロセスを指定している場合は、アップグレードされた受注タイプを使用して新規の受注を作成できます。取引タイプの定義については、ユーザーズ・ガイドも参照してください。

アップグレードされたすべての受注タイプに対して、1つ以上の明細タイプを作成できます。受注カテゴリの受注タイプにアップグレードされた場合は、受注カテゴリの明細タイプが作成されます。自動作成されたこの明細タイプには、アップグレードされた受注タイプのデフォルト・アウトバウンド明細タイプが設定されます。返品カテゴリの受注タイプにアップグレードされた場合は、返品カテゴリの明細タイプが作成されます。自動作成されたこの明細タイプには、アップグレードされた受注タイプのデフォルト・インバウンド明細タイプが設定されます。混合カテゴリの受注タイプにアップグレードされた場合は、受注カテゴリと返品カテゴリの2つの明細タイプが作成されます。自動作成されたこれらの明細タイプには、アップグレードされた受注タイプのデフォルト・アウトバウンド明細タイプとデフォルト・インバウンド明細タイプがそれぞれ設定されます。これらの明細タイプについて新規のワークフロー割当を定義すると、これらの明細タイプを使用して新規明細を作成できます。取引タイプの定義については、ユーザーズ・ガイドも参照してください。

アップグレードによって作成された明細タイプには、次の名前が付けられます。

UPG_LINE_TYPE_xxx_nnn

xxxは明細タイプのカテゴリで、nnnはアップグレード後の受注タイプの受注タイプID（これに基づいて明細タイプが作成されています）です。Order Managementに正常にアップグレードされた後、自動作成された明細タイプの名前は、ユーザーにわかりやすい名前に変更できます。

例: Order Entryで、次のように明細タイプを定義していたとします。

• 名前: 海外（受注タイプID - 1001）

• カテゴリ: 通常（R）

アップグレードすると、次の受注取引タイプが作成されます。

• 名前: 海外

• カテゴリ: 受注（ORDER）

• デフォルト・アウトバウンド明細タイプ: UPG_LINE_TYPE_ORDER_1001

また、次の明細取引タイプも作成されます。

• 名前: UPG_LINE_TYPE_ORDER_1001

• カテゴリ: 受注（ORDER）

受注番号ソースのアップグレード

Order Entryでは、ユーザー定義の受注番号ソースによって、受注の採番方法が管理されていました。受注番号ソースを定義すると、アプリケーションによってデータベース連番オブジェクトが自動的に作成されました。受注タイプを定義するときは、受注番号ソースの指定が必要でした。

Order Managementでは、AOL文書連番を使用して受注採番を行います。「受注採番用文書連番の定義」も参照してください。

Order Managementへのアップグレード処理によって、Order Entryの有効な番号ソースはAOL文書連番の自動採番タイプに移行されます。アップグレード処理では、AOL文書連番APIをコールしてこれを実行します。連番は、次のように定義されます。

• アプリケーション: Order Management。

• 連番の名前: xxxxxx（xxxxxxは受注番号ソースの名前）。

• 連番のタイプ: 自動採番。

• 開始値: アップグレードされる受注番号ソースに関連付けられた、現在、未使用の連番値。

• 開始日: アップグレードされる受注番号ソースの開始日。NULLの場合は現在日付です。

• 終了日: アップグレードされる受注番号ソースの終了日。

アップグレードされるすべての有効な受注タイプについては、次のように、AOL文書連番カテゴリも作成されます。

• アプリケーション: Order Management。

• 文書連番カテゴリ・コード: nnnn（nnnnは受注タイプID）。

• 名前: xxxxxxx（xxxxxxは受注タイプ名）。

• 摘要: xxxxxxx（xxxxxxxは受注タイプの摘要）。

• 表: OE_TRANSACTION_TYPES_ALL

アップグレード処理では、文書連番と作成済文書連番カテゴリをリンクする文書連番割当も作成されます。受注番号ソースが複数の受注タイプで参照されていた場合は、各文書カテゴリを文書連番にリンクするための複数の文書連番割当が作成されます。

例

受注番号ソース「海外受注」を定義し、受注タイプ「海外」（受注タイプID 1001）に割り当てるとします。

受注番号ソース「海外受注」は、「自動」タイプのAOL文書連番にアップグレードされます。Order Management製品では、この連番が「海外受注」という名前で定義されます。受注タイプは前述した方法でアップグレードされます。また、AOL文書連番カテゴリもコード1001が付けられて作成されます。Order Management製品では、このカテゴリが「海外」という名前で定義されます。カテゴリを連番にリンクする文書連番割当も作成されます。

注意: Oracle Order Managementで受注の番号付けを行うためには、アプリケーションおよび職責レベルでプロファイル・オプション「順次採番」を設定する必要があります。

サイクルとサイクル履歴のアップグレード方法

Order Managementへのアップグレードでは、次の方法に従って、サイクル定義データおよび受注と明細のサイクル履歴をアップグレードします。

サイクル定義データのアップグレード

すべてのカスタム処理、承認および結果参照は、ワークフロー・エンティティにアップグレードされます。Order Entryでは、すべてのサイクルがユーザー定義でした。オープン受注で使用するサイクルは、ワークフロー・プロセスにすべてアップグレードされます。ワークフロー・プロセス定義は、アップグレード時に動的に作成されます。アップグレード処理では、ワークフローAPI（WF_LOAD API）をコールしてワークフロー設計時データを作成します。

サイクル履歴のアップグレード

すべてのオープン受注および明細に関するサイクル履歴は、ワークフロー・ステータス表にアップグレードされます。これを実現するため、アップグレード処理では、すべてのオープン受注に対する適切なヘッダー・フローおよびすべてのオープン明細に対する明細フローを起動します。

ここで、Order Entryですでに実行されていた機能を、アップグレード時に再実行しないでください。たとえば、記帳されてクローズできる受注ヘッダー（明細のクローズ待ち）をアップグレードする場合、Oracle Order Managementでは再記帳しないでください。

つまり、ヘッダー・フローでは、実行済のアクティビティをスキップし、アップグレード前のサイクル内での受注とアップグレード後のフロー内での受注が機能的に同じポイントにあることが必要です。したがって、記帳されてクローズ待ちの受注は、アップグレードされた後も、「クローズ受注」ワークフロー・サブプロセス内で明細のクローズを待機する必要があります。

この章では、次の方法について詳しく説明します。

• Order Entryで実行済のビジネス機能をOrder Managementでスキップする方法

• 受注または明細が、アップグレード後（Order Managementフロー内）に、アップグレード前（Order Entryサイクル内）と機能的に同じポイントに配置される方法

ユーザー定義サイクル・データのアップグレード

次の項では、各サイクル構成部品をワークフローにアップグレードする方法について説明します。

結果とサイクル処理結果のアップグレード

アップグレード処理では、カスタム処理（SO_ACTION_RESULTS内のレコード）で参照されるSO_RESULTSのレコードについて、WF_LOOKUPSにデータを作成します。SO_ACTION_RESULTS内のレコードに基づいて、結果がカスタム・アクティビティと通知アクティビティに自動的にマップされます。

結果がマップされた処理がヘッダー・サイクル処理の場合、参照は、OM受注ヘッダー（OEOH）ワークフロー項目タイプを使用して作成されます。結果がマップされた処理が明細サイクル処理の場合、参照は、OM受注明細（OEOL）ワークフロー項目タイプを使用して作成されます。カスタム処理または承認処理で使用するすべての結果セットについて、参照タイプが作成されます。

参照タイプの作成では、次の命名規則が使用されます。

参照タイプ・コード - UPG_RT_nn（nnは処理ID）

表示名 - UPG_RT_xx（xxは処理名の最初の26文字）

参照コードの作成では、次の命名規則が使用されます。

参照コード - UPG_RC_nn（nnは結果ID）

内容 - XX（XXは結果名）

例: 次のようにサイクル結果を定義するとします。

これらの結果は、次のようにカスタム処理のエクスポートの承認に関連付けられています。

アップグレード処理では、次のようなワークフロー参照タイプが作成されます。

アップグレード処理では、前述の参照タイプを使用して、次のワークフロー参照が作成されます。

シード済サイクル処理

シードされているサイクル処理はアップグレードされません。これは、Order Managementには、すべての機能ワークフロー・サブプロセスのアップグレード固有バージョンがシードされているためです。アップグレード処理では、これらのサブプロセスが作成ブロックとして使用され、サイクル定義に基づいて、受注と明細のワークフロー・プロセス定義が作成されます。

このアップグレード固有の機能サブプロセスは、受注または明細がすでに各ビジネス機能に渡されているかどうかを検出するように設計されています。また、渡されている場合は、アップグレード中に処理を行わないように設計されています。

例

(アップグレード) 記帳 - 受注, 手動（UPG_BOOK_PROCESS_ASYNCH）

記帳 -受注, 手動

これは、シードされている「記帳 - 受注, 手動」サブプロセスのアップグレード固有バージョンです。

このサブプロセスでは、次のような処理が行われます。アップグレードの実行中は、「(アップグレード) 受注記帳済?」機能によって、受注が記帳済かどうかがチェックされます。記帳されていない場合は「No」で完了し、フローは「記帳 - 適格」ブロックに進みます。記帳済の場合は「Yes」で完了し、受注を記帳する機能はスキップします。

アップグレードが実行されていない場合、「(アップグレード) 受注記帳済?」機能は「No」で完了します。

次の表は、Order Entryにシード済の様々なサイクル処理のマップ先である、Order Managementのシード済ワークフロー・サブプロセスの一覧です。

* 明細処理に前提条件として記帳が含まれている場合に使用します。

** 元のサイクルに出荷確認サイクル処理または返品インタフェース・サイクル処理が含まれている場合は、請求処理の前にUPG_FUFILLMENT_SUB（(アップグレード) 履行 - 明細）も追加されることを示します。

*** 構成品目明細に対して特別に作成されたフローで使用します。

**** OMではサービス・インタフェースは廃止されていることを示します。出荷処理では、サービス明細に対して処理不可のように動作します。

サイクル処理の前提条件

以前は、サイクル処理の前提条件によって、受注または明細が特定のサイクル処理に対して適格になる時期を判別していました。ワークフローでは、遷移情報によって、特定ワークフロー・アクティビティの実行時期を判別します。アップグレード処理では、サイクル処理の前提条件に基づいてこの情報が作成されます。また、グループ番号を使用したレコードのグループ化に基づいて、適切なANDアクティビティとORアクティビティが作成されます。

カスタム・サイクル処理

カスタム・サイクル処理とは、シードされていない処理で承認処理以外の処理です。Order Entryでは、このようなサイクル処理は外部で実行されました。このため、受注または明細をカスタム処理の結果に基づいてサイクル内の次のステップに移動するには、CベースのOrder Entry機能をコールする必要がありました。

このようなサイクル処理は、特別なワークフロー・ブロック・アクティビティにアップグレードされます。ブロック・アクティビティは、カスタム・サイクル処理がヘッダー処理の場合はOM受注ヘッダー（OEOH）ワークフロー項目タイプを使用して作成され、カスタム・サイクル処理が明細処理の場合はOM受注明細（OEOL）ワークフロー項目タイプを使用して作成されます。

この特別なブロック・アクティビティの作成では、次の命名規則が使用されます。

内部名 - UPG_AN_nn（nnは処理ID）

表示名 - xxxxxxxxxxxx（xxxxxxxxxxはサイクル処理名）

このアクティビティは、機能OE_WF_UPGRADE_UTIL.UPGRADE_CUSTOM_ACTIVITY_BLOCKをコールするように定義されています。また、アクティビティ属性が作成され、カスタム・サイクル処理がマップされたS列（ステータス列）の名前に設定されます。

プロシージャOE_WF_UPGRADE_UTIL.UPGRADE_CUSTOM_ACTIVITY_BLOCKは、次の処理を実行します。

アップグレードの実行中にアクティビティを実行すると、そのアクティビティ属性からS列の名前が取得されます。次に、Order Entryの受注または明細についてS列の値がチェックされます。S列の値が適格な（18）以外の場合、アクティビティは、アップグレードされたワークフロー参照コード命名規則を使用してその値でブロックを完了します。S列の値が、受注または明細がカスタム処理に対して適格であることを示す「適格」（18）の場合、アクティビティは「通知済」で完了します。

アップグレードが実行されていないときにブロック・アクティビティを実行すると、そのアクティビティは「通知済」で完了します。これは、受注または明細が外部カスタム処理に対して適格であることを示します。

Order Managementに正常にアップグレードした後は、カスタム・サイクル処理を実行した外部処理を完了してから、ワークフローAPIのWF_ENGINE.CompleteActivityInternalName()を使用して、この特別なブロックを完了し、受注または明細をアップグレードする必要があります。

例

Order Entryでは次のようにカスタム処理が定義されているとします。

• 処理ID: 1022

• 処理名: 外部エクスポート処理

• 結果表: SO_HEADERS_ALL

• 結果列: S11

このカスタム処理はサイクル「海外出荷」で使用されています。サイクル処理は、受注が入力されると適格になり、ピック・リリース処理に対する前提条件としての役割を果たします。

サイクル処理に対して、次のレコードがSO_ACTION_RESULTSに定義されます。

サイクル処理は、次のように、OM受注ヘッダー・ワークフロー項目タイプを使用して定義されているブロック・アクティビティにアップグレードされます。

• 内部名: UPG_AN_1022

• 表示名: 外部エクスポート処理

このサイクル処理は、次の2つの参照を持つ参照UPG_RT_1022に関連付けられます。

このブロック・アクティビティに関するアクティビティ属性S_COLUMNの値は、S11に設定されます。

このアクティビティを使用するサイクルをアップグレードしたときに作成されるワークフロー・プロセスを、次の図に示します。

アップグレードされたサイクル・アクティビティのワークフロー

このプロセスでのブロック・アクティビティ「外部エクスポート処理」は、アップグレードされたサイクル処理を表します。このプロセスは機能OE_WF_UPGRADE_UTIL.UPGRADE_CUSTOM_ACTIVITY_BLOCKをコールします。

機能UPG_AN_OEOH_1022_CONT_Lは、このヘッダー処理に関する明細処理の依存性を処理するために作成されます。

サイクル履歴がアップグレードされると、このワークフロー・プロセスを使用してヘッダー・フローが開始されます。受注がこのカスタム処理に対して適格な場合、機能「外部エクスポート処理」自体が「通知済」に設定されます。

受注がこのカスタム処理を「合格」結果で通過した場合、ブロックは「合格」（UPG_RC_1）で完了して続行フローのアクティビティに遷移します。次に、フローは「クローズ受注」プロセスに遷移し、そこで、明細がクローズするのを待機します。

受注がこのカスタム処理を「失敗」結果で通過した場合、ブロックは「失敗」（UPG_RC_2）で完了し、デフォルト遷移を経由して待機アクティビティに遷移します。この遷移した内容は、アップグレード後に再度ブロック・アクティビティに戻り、ブロック・アクティビティ自体が再度「通知済」に設定されます。このカスタム・アクティビティへの戻りは、受注サイクル機能に追随するために行われます。これによって、合格以外の結果で完了した処理は、未処理のままで留まることができます。

アップグレード後は、このカスタム・アクティビティに対して適格な受注が処理されるため、それらの受注は外部で処理する必要があります。カスタム・アクティビティ「外部エクスポート処理」に適格な受注の問合せには、次のようにワークフロー項目アクティビティ・ステータスを問い合せることができます。

SELECT ITEM_KEY

 FROM WF_ITEM_ACTIVITY_STATUSES_V

 WHERE ITEM_TYPE = ‘OEOH'

  AND ACTIVITY_NAME = ‘UPG_AN_1022'

   AND ACTIVITY_STATUS_CODE = ‘NOTIFIED'

  AND SOURCE = ‘R';

この問合せでは、このカスタム・アクティビティで処理待ちになっている全受注（ヘッダーID）が戻されます。外部処理が正常に完了したときは、各受注についてこのブロック・アクティビティを完了して、フローを進行させる必要があります。

これを実行するには、次のパラメータを指定してワークフローAPIのWF_ENGINE.COMPLETEACTIVITYINTERNALNAMEをコールします。

• 項目タイプ: OEOH

• 項目キー: OE_ORDER_HEADERS_ALL.HEADER_ID（処理済の受注の場合）

• アクティビティ名: UPG_AN_1022

• 結果コード: UPG_RC_1

受注の外部処理が失敗した場合は、「受注」フォームでその受注を取り消し、処理を進行させてクローズできます。また、受注処理API（OE_ORDER_PUB.Process_Order）をコールして受注を取り消すこともできます。このパブリックAPIの使用については、オープン・インタフェースのマニュアルを参照してください。

承認処理

承認処理はワークフロー通知アクティビティにアップグレードされます。アップグレード処理では、特別な事前通知アクティビティと通知用のメッセージ・データも作成されます。

通知アクティビティと事前通知アクティビティは、承認が受注レベルの承認処理であった場合、OM受注ヘッダー（OEOH）ワークフロー項目タイプを使用して作成され、承認が明細レベルの承認処理であった場合、OM受注明細（OEOL）ワークフロー項目タイプを使用して作成されます。

通知アクティビティの作成では、次の命名規則が使用されます。

• 内部名: UPG_AN_nn（nnは承認処理ID）

• 表示名: xxxxxxxxxxxx（xxxxxxxxxxは承認処理名）

アップグレード処理の実行中に通知が送信されないように、このアクティビティはコストの高いアクティビティとして定義されます。

通知アクティビティの応答者は、通知の送信先を指定します。この送信先は、ワークフロー項目属性の「通知承認者」からデフォルト設定されます。

サイクル内で使用されるすべての承認処理に対しても事前通知アクティビティが作成されます。事前通知アクティビティの作成では、次の命名規則が使用されます。

• 内部名: UPG_AN_PNOT_nnn（nnnは、後続の通知アクティビティのワークフロー・インスタンスID）

• 表示名: UPG_AN_PNOT_nnn（nnnは、後続の通知アクティビティのインスタンスID）

このアクティビティは、PL/SQL関数OE_WF_UPGRADE_UTIL.UPGRADE_PRE_APPROVALをコールするように定義されています。

アクティビティ属性も作成され、承認サイクル処理がマップされていたS列（ステータス列）の名前に設定されます。

プロシージャOE_WF_UPGRADE_UTIL.UPGRADE_PRE_APPROVALは、次の処理を実行します。

アップグレードの実行中にアクティビティを実行すると、そのアクティビティ属性からS列の名前が取得されます。次に、Order Entryの受注または明細についてS列の値がチェックされます。S列の値が適格な（18）以外の場合、アクティビティはその値で完了します（アップグレードされた参照コード命名規則が使用されます）。

S列の値が、受注または明細が承認処理に対して適格であったことを示す適格な（18）の場合、アクティビティは「未処理」で完了します。アップグレードを実行していないときに事前通知アクティビティを実行すると、そのアクティビティは「未処理」で完了します。

事前通知アクティビティでの「未処理」結果は、各通知アクティビティに遷移します。

通知アクティビティには、関連付けられたメッセージが必要です。アップグレード処理では、次の命名規則を使用して、各承認に対してメッセージが作成されます。

• 表示名: xxxxxxxxxxxx（xxxxxxxxxxは承認処理名）

• メッセージの件名: xxxxxxxxxxxx（xxxxxxxxxxは承認処理名）

シードされているワークフロー項目属性のヘッダーまたは明細の短縮記述子を参照するメッセージ属性が、そのメッセージが受注レベルの承認メッセージか、または明細レベルの承認メッセージかに従って作成されます。

例: Order Entryで次のように承認処理が定義されているとします。

• 処理ID: 1023

• 承認処理名: 法的承認

• 結果表: SO_HEADERS_ALL

• 結果列: S12

この承認処理は、サイクル「海外請求のみ」内で使用され、受注が入力されると適格になります。承認処理は「保留中」、「合格」または「失敗」のいずれかの結果で完了します。「合格」で完了した場合は、売掛管理インタフェース明細処理の前提条件としての役割を果たします。

承認処理に対して、次のレコードがSO_ACTION_RESULTSに定義されます。

この承認処理は、次のように、OM受注ヘッダー・ワークフロー項目タイプを使用して、通知アクティビティにアップグレードされます。

• 内部名: UPG_AN_1023

• 表示名: 法的承認

この承認処理は、次の2つの参照を持つ参照UPG_RT_1023に関連付けられます。

サイクル内で使用されるすべての承認処理に対しても、次のような事前通知アクティビティが作成されます。

• 内部名: UPG_AN_PNOT_51167

• 表示名: UPG_AN_PNOT_51167

この事前通知アクティビティに関するアクティビティ属性S_COLUMNの値は、S12に設定されます。

この承認を使用するサイクルをアップグレードすると、次のようなフローが作成されます。

アップグレードされた承認のサイクル

事前通知アクティビティUPG_AN_PNOT_51167は、通知アクティビティ「法的承認」の前に配置され、機能OE_WF_UPGRADE_UTIL.UPGRADE_PRE_APPROVALをコールします。

受注が「合格」結果で承認を通過している場合は、事前通知アクティビティも「合格」で完了し、フローは継続アクティビティUPG_AN_OEOH_1023_CONT_Lに遷移します。

ヘッダーが承認処理に対して適格な場合、事前通知アクティビティは「未処理」で完了し、ORを使用して通知アクティビティに遷移します。

承認処理が「合格」（通過可能な結果）以外の結果で完了している場合、事前通知アクティビティはその結果で完了し、デフォルト遷移および待機アクティビティを経由して通知アクティビティに遷移します。通知アクティビティはコストの高いアクティビティとして作成されているため、フローはこのアクティビティに到達すると遅延されます。この通知アクティビティへの戻りは、受注サイクル機能に追随するために行われます。これによって、合格以外の結果で完了した処理は、未処理のままで留まることができます。

アップグレード後は、「WF通知」ページから通知に応答できます。これは、Order Managementメニューから実行できます。アップグレード処理で作成された通知は、「OM: 通知承認者」プロファイル・オプションで設定したロールにすべて送信されるように構成されます。

ヘッダーと明細処理の依存性

Order Entryのサイクルでは、ヘッダー処理を前提条件とする明細処理がサポートされていました。ワークフローでは、このような親子関係の調整は、フロー待ち調整アクティビティと継続フロー調整アクティビティによって実現されます。記帳調整（受注が記帳されるまで明細が待機）およびクローズ調整（明細がクローズするまで受注が待機）は、シードされている機能サブプロセスのアップグレード固有バージョンで処理されます。

ただし、次のような依存性は、サイクル定義のアップグレード時に動的に処理されます。

• カスタム・ヘッダー処理または承認を前提条件とするシード済明細処理

• カスタム・ヘッダー処理または承認を前提条件とするカスタム明細処理

このような依存性に対しては、2つの新規アクティビティが作成されます。1つはヘッダー・レベルの継続フロー・アクティビティで、前提条件のヘッダー・アクティビティの直後に配置されます。次のように命名されます。

• 内部名/表示名: UPG_AN_OEOH_nn_CONT_L（nnは前提条件処理の処理ID）

もう1つは明細レベルのフロー待ちアクティビティで、依存する明細処理の直前に配置されます。次のように命名されます。

• 内部名/表示名: UPG_AN_OEOL_nn_WAIT_FOR_H（nnは前提条件処理の処理ID）

調整のために適切なアクティビティ属性が作成されます。複数の明細処理が同一のヘッダー処理に依存している場合は、複数のフロー待ちアクティビティが作成されてマージされます。これは、ワークフローがサポートするのは、1つのフロー待ちアクティビティにリンクされた1つの継続フロー・アクティビティのみであるためです。

例

サイクル「海外請求のみ」は、明細サイクル処理の売掛管理インタフェースが、記帳される受注およびヘッダー・レベルの法的承認（処理IDは1023）を通過した受注に依存するように定義されます。

アップグレードされたサイクルのヘッダー・ワークフローの定義を次の図に示します。

アップグレードされたサイクル - ヘッダー・ワークフローの定義

アクティビティUPG_AN_OEOH_1023_CONT_Lは、通知アクティビティ（法的承認）が「合格」結果で完了したときに実行されるように配置されます。これは、明細フローの継続を示す継続アクティビティです。

明細ワークフローの定義を次の図に示します。

明細ワークフローの定義

「明細の入力」アクティビティは、記帳時に明細の依存性を処理するシード済アクティビティです。このアクティビティには、明細フローを記帳まで待機させる調整アクティビティが含まれています。アクティビティUPG_AN_OEOL_1023_WAIT_FOR_Hは、ヘッダー承認処理への依存性を処理するためにアップグレード処理で動的に作成されるWAIT_FOR_FLOW調整アクティビティです。プロセス定義では、両方のアクティビティは請求サブプロセスへのインタフェースの前提条件であることが示されます。

サイクル定義

Order Entryでは、サイクルはシードされていませんでした。オープン受注または明細で参照されるすべてのユーザー定義サイクルは、ヘッダー・ワークフロー・プロセスおよび明細ワークフロー・プロセスにアップグレードされます。製造工程リリース処理を含むサイクルは、3つのワークフロー・プロセスにアップグレードされます。このうちの3番目は、構成品目明細にのみ固有な明細ワークフロー・プロセスです。

これまでに説明したアップグレード固有の機能サブプロセス、特別なブロック・アクティビティ（カスタム・サイクル処理のアップグレード用）、事前通知アクティビティと通知アクティビティ（承認処理のアップグレード用）、調整アクティビティ（依存性の処理用）、ANDアクティビティとORアクティビティ（前提条件のグループ化用）は、ワークフロー・プロセス定義を定義するための作成ブロックとして使用されます。アップグレード処理では、サイクル定義に基づいて、これらのプロセス定義が動的に作成されます。

ヘッダー・ワークフロー・プロセス定義は、サイクル内にあるヘッダー・レベルのすべてのサイクル処理に基づいて作成されます。明細ワークフロー・プロセス定義は、サイクル内にある明細レベルのすべてのサイクル処理に基づいて作成されます。

これらのワークフロー・プロセスの名前には、次の命名規則が使用されます。

• ヘッダー・ワークフロー・プロセス:

  • 内部名: UPG_PN_OEOH_REG_nn（nnはサイクルID）

  • 表示名: UPG_PN_OEOH_REG_xxxxxxxxxxx（xxはサイクル名）

• 明細ワークフロー・プロセス:

  • 内部名: UPG_PN_OEOL_REG_nn（nnはサイクルID）

  • 表示名: UPG_PN_OEOL_REG_xxxxxxxxxxx（xxxはサイクル名）

• 構成品目明細ワークフロー・プロセス:

  • 内部名: UPG_PN_OEOL_CFG_nn（nnはサイクルID）

  • 表示名: UPG_PN_OEOL_CFG_xxxxxxxxxxx（xxxはサイクル名）

アップグレードされないサイクル定義

Order Entryではサポートされていなかったサイクル定義、廃止された定義または非常に複雑な定義はアップグレードされません。サイクルがアップグレードされない場合は、そのサイクルを参照しているオープン受注もアップグレードされません。

次のようなサイクルについては、ワークフロー・プロセス定義が作成されません。

• 「受注完了」サイクル処理がないサイクル。Order Entryでは、受注サイクルの最後に「明細完了」処理と「受注完了」処理を含める必要がありました。

  このようなサイクルを参照しているオープン受注をアップグレードするには、次のいずれかの処理を実行します。

  • 受注を完全に取り消してクローズします。

  • 「受注完了」ヘッダー処理をサイクル定義に追加します。「動的WHERE句の作成」コンカレント・プログラムが正常終了することを確認します。

• 「明細完了」サイクル処理がないサイクル。Order Entryでは、受注サイクルの最後に「明細完了」処理と「受注完了」処理を含める必要がありました。

  このようなサイクルを参照しているオープン受注をアップグレードするには、次のいずれかの処理を実行します。

  • 受注の全明細を完全に取り消してクローズします。

  • 「明細完了」サイクル処理をサイクルに追加します。「動的WHERE句の作成」コンカレント・プログラムが正常終了することを確認します。

• 受注または明細の取消処理を含むサイクル。Order Entryでは、取消処理を含むサイクルの定義はサポートされていません。また、取消処理の対象となる受注または明細を処理するためのプログラムまたはフォームは提供されていません。

  このようなサイクルを参照しているオープン受注をアップグレードするには、次のいずれかの処理を実行します。

  • 受注サイクルを使用して全受注を処理し、「受注消込」プログラムを使用して全受注をクローズします。

  • 取消処理の対象となる受注または明細がないことを確認します。次に、取消処理をサイクルから削除します。「動的WHERE句の作成」コンカレント・プログラムが正常終了することを確認します。

    サイクル内で明細取消処理を使用して出荷残明細を取り消す場合は、Oracle Order Managementの不足出荷機能を使用できます。不足出荷の許容範囲を適切に設定することで、部分出荷を可能にする一方で完全に履行できます（したがって、未出荷部分の取消が不要になります）。超過出荷と不足出荷の詳細は、『Oracle Order Managementユーザーズ・ガイド』を参照してください。

• 在庫インタフェース処理を含む非出荷サイクル。

  このようなサイクルを参照しているオープン受注をアップグレードするには、次のいずれかの処理を実行します。

  • 受注サイクルを使用して全受注を処理し、「受注消込」プログラムを使用して全受注をクローズします。

  • 在庫インタフェース処理を削除します。このため、オープン状態の全取引をアップグレード前に在庫インタフェースを通過させないかぎり、アップグレード後の取引については、手動で在庫を減らす必要があります。「動的WHERE句の作成」コンカレント・プログラムが正常終了することを確認します。

• 返品インタフェース処理と購買リリース処理の両方を含むサイクル。

  このようなサイクルを参照しているオープン受注をアップグレードするには、次のいずれかの処理を実行します。

  • 受注サイクルを使用して全受注を処理し、「受注消込」プログラムを使用して全受注をクローズします。

  • オープン状態の全受注を処理してクローズし、サイクルから購買リリース処理を削除します。「動的WHERE句の作成」コンカレント・プログラムが正常終了することを確認します。

  • オープン状態の全返品を処理してクローズし、サイクルから返品インタフェース処理を削除します。「動的WHERE句の作成」コンカレント・プログラムが正常終了することを確認します。

• 次のような明細処理を含むサイクル。

  • 前提条件に複数のグループが含まれる場合（OR条件）、かつ

  • グループの1つに複数の前提条件処理が含まれる場合（AND条件）

    かつ

  • そのグループに、1つ以上の前提条件処理としてヘッダー処理が含まれる場合

    このようなサイクルを参照しているオープン受注をアップグレードするには、次のいずれかの処理を実行します。

  • 受注サイクルを使用して全受注を処理し、「受注消込」プログラムを使用して全受注をクローズします。

  • AND条件をOR条件に変換します。同じ機能を保持している場合、この変換ができないことがあります。また、AND条件に適合しなかったためにアップグレード前は適格にならなかった処理が、アップグレード後は適格になる場合もあります。「動的WHERE句の作成」コンカレント・プログラムが正常終了することを確認します。

• 処理と結果の組合せ（サイクル内で他の処理の前提条件として使用）についてSO_ACTION_RESULTS表にレコードがないサイクル。これは、データが破損している場合で、アプリケーション・フォームを使用せずにサイクルを定義したときに発生する可能性があります。

  このようなサイクルを参照しているオープン受注をアップグレードするには、次のいずれかの処理を実行します。

  受注サイクルを使用して全受注を処理し、「受注消込」プログラムを使用して全受注をクローズします。

  処理結果の定義フォームを使用して、必要なレコードをSO_ACTION_RESULTSに作成します。

• 明細レベル処理に依存するヘッダー・レベル処理を含むサイクル。Order Entryでは、このような定義はサポートされていません。

  このようなサイクルを参照しているオープン受注をアップグレードするには、次のいずれかの処理を実行します。

  • 受注サイクルを使用して全受注を処理し、「受注消込」プログラムを使用して全受注をクローズします。

  • 明細レベル処理からヘッダー・レベル処理の依存性を削除します。ヘッダー処理が他のヘッダー・レベル処理に依存していることを確認します。「動的WHERE句の作成」コンカレント・プログラムが正常終了することを確認します。

• Order Entryでは、ピック・リリース、出荷残リリースおよび出荷確認のサイクル処理は、特定の方法で使用する必要があります。出荷確認サイクル処理を含み、前提条件としてピック・リリースまたは出荷残リリース以外の処理を含むサイクルはサポートされていません。

  このようなサイクルを参照しているオープン受注をアップグレードするには、次のいずれかの処理を実行します。

  • 受注サイクルを使用して全受注を処理し、「受注消込」プログラムを使用して全受注をクローズします。

  • このサイクルを使用するすべてのオープン明細が、ピック・リリース処理の前にあることを確認します。つまり、ピック・リリース、出荷残リリースおよび出荷確認の明細ステータス列は、NULL値になります。NULL値でない場合は、その明細を処理してクローズします。出荷確認処理の前提条件として、ピック・リリースまたは出荷残リリース以外の処理が含まれないようにサイクル定義を変更します。「動的WHERE句の作成」コンカレント・プログラムが正常終了することを確認します。

• Order Entryでは、ピック・リリース、出荷残リリースおよび出荷確認のサイクル処理は、特定の方法で使用する必要があります。出荷残リリース処理を含み、前提条件として出荷確認以外の処理を含むサイクルはサポートされていません。

  このようなサイクルを参照しているオープン受注をアップグレードするには、次のいずれかの処理を実行します。

  • 受注サイクルを使用して全受注を処理し、「受注消込」プログラムを使用して全受注をクローズします。

  • このサイクルを使用するすべてのオープン明細が、ピック・リリース処理の前にあることを確認します。つまり、ピック・リリース、出荷残リリースおよび出荷確認の明細ステータス列は、NULL値になります。NULL値でない場合は、その明細を処理してクローズします。出荷残リリース処理の前提条件として、出荷確認以外の処理が含まれないようにサイクル定義を変更します。「動的WHERE句の作成」コンカレント・プログラムが正常終了することを確認します。

• Order Entryでは、ピック・リリース、出荷残リリース、出荷確認および在庫インタフェースのサイクル処理は、特定の方法で使用する必要があります。出荷確認および在庫インタフェースのサイクル処理を含み、在庫インタフェース処理の前提条件として、出荷確認またはサービス・インタフェース以外の処理を含むサイクルはサポートされていません。

  このようなサイクルを参照しているオープン受注をアップグレードするには、次のいずれかの処理を実行します。

  • 受注サイクルを使用して全受注を処理し、「受注消込」プログラムを使用して全受注をクローズします。

  • このサイクルを使用するすべてのオープン明細が、ピック・リリース処理の前にあることを確認します。つまり、ピック・リリース、出荷残リリース、出荷確認、在庫インタフェースおよびサービス・インタフェースの明細ステータス列は、NULL値になります。NULL値でない場合は、その明細を処理してクローズします。在庫インタフェース・サイクル処理の前提条件として、出荷確認またはサービス・インタフェース以外の処理が含まれないようにサイクル定義を変更します。「動的WHERE句の作成」コンカレント・プログラムが正常終了することを確認します。

• 「入力」処理とそれに基づく前提条件定義を伴うサイクルを参照するオープン受注をアップグレードするには、次のいずれかの処理を実行します。

  • 受注サイクルを使用して全受注を処理し、「受注消込」プログラムを使用して全受注をクローズします。

  • 「入力」処理に基づく前提条件がないようにサイクル定義を変更します。

    このようなアップグレード不可のサイクルを識別するために、アップグレード前スクリプト（ontexc08.sql）が用意されています。必要に応じて、このスクリプトをアップグレード前に実行して訂正処理を行います。例外がないことを確認するには、このスクリプトを再実行する必要があります。

サイクル・エンティティのワークフローへのマッピング

サイクル定義データは、次のようにワークフロー定義データにマッピングされます。

ワークフローとサイクルのアーキテクチャはかなり異なるため、アップグレード処理で作成されたワークフロー・プロセス定義は最適とはいえません。アップグレード処理では、特定の試行錯誤的な手法に従って、サイクル定義と機能的に同等のプロセス定義が作成されます。このときに、補助的なANDアクティビティとORアクティビティが作成されます。

アップグレードされたワークフロー・プロセス定義では、アップグレード固有の機能サブプロセスが使用されます。このサブプロセスには、サイクル履歴のアップグレード時に特別な処理を実行する補足的なアクティビティが含まれています。このような理由から、新規の受注および明細の処理には、これらのフローを使用しないことをお薦めします。

受注タイプ - サイクル割当のアップグレード

Order Managementには、取引タイプとして受注タイプと明細タイプがあります。ヘッダー・ワークフロー・プロセスは、受注タイプに割り当てられます。明細ワークフロー・プロセスは、受注タイプ、明細タイプおよび品目タイプの組合せに割り当てられます。詳細は、ユーザーズ・ガイドのワークフロー割当の説明も参照してください。

受注タイプを受注取引タイプと明細取引タイプにアップグレードする方法は、前の項で説明しました。アップグレード処理では、これらの取引タイプに対するワークフロー割当も作成されます。このワークフロー割当は、アップグレードされた受注および明細によってのみ使用され、終了日まで使用されます。アップグレード後の受注取引タイプと明細取引タイプを新規の受注および明細で使用可能にするには、新規のワークフロー割当を定義する必要があります。

アップグレードされたすべての受注タイプに対して、次のようにワークフロー割当が作成されます。

アップグレードされた受注タイプに対して作成されたすべての新規明細タイプについて、次のように明細ワークフロー割当が作成されます。

アップグレード前の受注タイプが参照するサイクルに製造工程リリースがある場合は、構成品目明細をサポートするために、次のワークフロー割当を追加作成します。

サイクル履歴のアップグレード

サイクル履歴は、すべてのオープン受注およびオープン明細についてのみ、ワークフロー・ステータス表にアップグレードされます。サイクル履歴のアップグレードは非常にコストの高い操作であるため、アップグレード前に「受注消込」プログラムを実行して、クローズ可能な全受注/明細をクローズすることをお薦めします。

サポート対象とサポート対象外のサイクル・ステータス

受注および明細をアップグレードするには、特定のステータスであることが必要です。アップグレード前スクリプト（ontexc07.sql）によって、サポート対象外のサイクル・ステータスの受注および明細が識別されます。このスクリプトでリスト表示された例外を処理する必要があります。このような受注または明細は、Order Entryのコンカレント・プログラムまたはフォームを使用して、サポート対象のサイクル・ステータスに移行できます。

取消ステータス履歴

Order Managementでは、受注数量を直接更新する方法として、一部取消がサポートされています。一部取消ステータスは、ワークフローで追跡管理されません。取消履歴は、明細履歴表（OE_ORDER_LINES_HISTORY）に格納されます。

受注または明細が完全に取り消されると、フローは自動的に「クローズ受注」アクティビティまたは「クローズ明細」アクティビティに遷移し、その受注または明細はクローズされます。Order Entryでも、受注ヘッダーまたは明細は完全に取り消されてからクローズされました。これは、完全に取り消されてクローズされた受注/明細のサイクル履歴はアップグレードされないことを意味します。

NULLのサイクル・ステータス

S列に関するNULLステータスはサポートされています。これは、受注または明細がそのサイクル処理に到達していないこと、またはサイクル内にそのサイクル処理が含まれていないことを示すためです。

シード済明細分割処理ステータス

Order Managementには、分割ステータスが格納されていません**。OMでは、明細が部分的に処理されると、その明細は分割され、処理済の部分はフローを進み、作成された新規明細は処理を待ちます。

例: ある明細が部分出荷確認されたとします。その明細は2つの明細に分割されます。元の明細は「出荷明細」アクティビティを完了し、履行および在庫インタフェースに進みます。作成された新規明細は、独自のフローを取得し、ピックおよび出荷まで「出荷明細」アクティビティで待機します。

分割ステータスの受注明細がOrder Managementにアップグレードされると、関連付けられている明細詳細またはピッキング明細詳細の数に応じて、その受注明細は複数の明細に自動的に分割されます。

** - 請求インタフェースは例外で、すべての「出荷後請求」構成部品が履行されていない場合、明細は部分的に請求インタフェースできます。

サポート対象のシード済ヘッダー・サイクル処理のステータス

次の表は、受注ヘッダーに関するサポート対象のステータスとサポート対象外のサイクル・ステータスの一覧です。

サポート対象のシード済受注明細サイクル処理のステータス

次の表は、受注明細に関するサポート対象のステータスとサポート対象外のサイクル・ステータスの一覧です。

注意: 製造工程リリース・サイクル処理の場合、Oracle Order Managementのアップグレード処理では、ステータスが「適格」または「作業指示完了」の明細のみがアップグレードされます。アップグレード前に、オープン状態の作業指示をすべて完了できない場合は、アップグレード前に次の処理を実行します。

注意: 不具合1504523に対するARUを要求します。

注意: 製造工程リリースがリリース済の明細の場合、ARUで提供されているアップグレード前スクリプトを実行します。

製造工程リリースが構成作成済の明細の場合、構成品目のリンクを解除し、ARUで提供されているアップグレード前スクリプトを実行する必要があります。

製造工程リリースが作業指示オープンまたは一部完了（出荷済品目なし）の明細の場合、作業指示および品目のリンクを解除し、ARUで提供されているアップグレード前スクリプトを実行する必要があります。

このスクリプトは、製造工程リリースがリリース済の計画済ATO明細（モデル、区分、オプション）を選択し、そのサイクル・ステータスを「製造工程リリース適格」に更新します。

この更新スクリプトの実行後、アップグレード前スクリプトontexc07.sqlを再実行し、例外レポートに明細が表示されていないことを確認する必要があります。

アップグレードが正常終了した後は、「受注」フォームの品目のリンク処理を使用して構成品目を再リンクしたり、「WIPショップ型製造オーダー」フォームを使用して作業指示を元のように受注明細にリンクできます。

サポート対象のカスタム処理ステータス

Order Managementのアップグレード処理では、カスタム処理を通過したORアクティビティに適格な受注および明細のアップグレードをサポートしています。前述したように、カスタム処理は特別なワークフロー・ブロック・アクティビティにアップグレードされます。受注または明細がカスタム処理に対して適格だった場合は、アップグレード後に、その受注または明細のフローは対応するブロック・アクティビティで停止します（ステータスは「通知済」）。

受注または明細がカスタム処理を通過していた場合、ブロック・アクティビティはその結果で完了します。

カスタム処理では、「保留中」サイクル・ステータス（一時的に合格以外の結果で完了）もサポートされています。この場合も、アップグレード後のブロック・アクティビティのステータスは、ワークフロー・バックグランド・エンジンの実行後に「通知済」になります。

サポート対象の承認ステータス

Order Managementのアップグレード処理では、承認を通過したORアクティビティに対して適格な受注および明細のアップグレードをサポートしています。前述したように、承認処理はワークフロー通知アクティビティにアップグレードされます。受注または明細が承認に対して適格な場合は、アップグレード時に、ワークフロー・バックグランド・エンジンの実行後に対応する通知が送信されます。

受注または明細が承認処理を通過している場合、事前通知アクティビティはその結果で完了し、通知アクティビティをスキップします。

承認処理では、承認保留ステータス（一時的に合格以外の結果で完了）もサポートされています。この場合、通知はワークフロー・バックグランド・エンジンの実行後に再送信されます。

注意: 受注および明細の承認履歴データ（SO_ORDER_APPROVALS、SO_LINE_APPROVALS）はアップグレードされません。Order Managementには、アップグレードする受注および明細に関するOrder Entryデータを表示できる特別なフォームが用意されています。

アップグレードされた受注および明細のフロー作成

Order Managementのアップグレード処理で最後に実行するタスクの1つは、アップグレードされた受注および明細のフロー作成です。このタスクは、サイクル・ステータス履歴をワークフロー・ステータス情報にアップグレードするために実行します。

正常にOrder Managementにアップグレードされたすべての受注について、アップグレード処理では次の処理を実行します。

前述したように、サイクル定義はワークフロー・プロセス定義にアップグレードされます。ヘッダー・フローは受注ヘッダーに対して開始され、Order Entryで参照されていたサイクルにマップするヘッダー・ワークフロー・プロセスが使用されます。ヘッダーIDは、ヘッダー・フローに対する項目キーとして使用されます。

受注の全明細については、Order Entryで参照されていたサイクルにマップする明細ワークフロー・プロセスを使用して明細フローが開始されます。明細IDは、明細フローに対する項目キーとして使用されます。

例

受注に標準品目明細があるとします。この受注では、「海外請求のみ」サイクルを使用します。これは、「ヘッダーと明細処理の依存性」の項で説明したサイクルです。受注は記帳され、「法的承認」サイクル処理に対して適格になります。明細は、受注レベルの承認完了を待機します。サイクルはヘッダー・ワークフロー・プロセス（UPG_PN_OEOH_REG_International Bill-Only）および明細ワークフロー・プロセス（UPG_PN_OEOL_REG_International Bill-Only）にアップグレードされます。アップグレード処理では、UPG_PN_OEOH_REG_International Bill-Onlyプロセスを使用して、受注に対するヘッダー・フローが開始されます。フローは、通知アクティビティ「法的承認」で停止します。明細に対して開始された明細フローは、「法的承認」が完了するまで待機します（フロー待ち調整アクティビティ）。アップグレードが正常終了した後、ワークフロー・バックグラウンド・プロセスを開始すると、「OM: 通知承認者」プロファイル・オプションで指定したロールに通知が送信されます。

アップグレードが正常終了した後は、アップグレード後ステップをいくつか完了する必要があります。その1つは、スクリプトを実行して、アップグレードされたすべての受注および明細のワークフロー項目属性をアップグレードすることです。

サイクル履歴のアップグレードに影響を与えるアップグレード後ステップ

アップグレードされた受注および明細を処理するには、アップグレード後ステップをすべて完了する必要があります。一部のステップは、特定のプロファイル・オプションの設定に関連し、他のステップは、更新スクリプトの実行に関連しています。

プロファイル・オプション「OM: アップグレードされた受注用コンテキスト職責」

Order Managementでは、すべての受注および明細について、次のワークフロー項目属性が設定されます。

• ユーザーID（USER_ID）: 受注/明細を作成したユーザー

• 職責ID（RESPONSIBILITY_ID）: 受注/明細の作成で使用した職責

• アプリケーションID（APPLICATION_ID）: 受注/明細の作成時に有効であったアプリケーション

バックグラウンド・エンジンによって処理する遅延フローが選択された場合、これらの品目属性は、アプリケーション・コンテキストを設定するために使用されます。このアプリケーション・コンテキストによって、環境が指し示す営業単位（組織）と有効なプロファイル・オプションが判別されます。

アップグレードされた受注および明細に関する最初の品目属性が、受注および明細のcreated_by列に基づいて設定できます。他の2つの品目属性を設定するには、特定のアップグレード後ステップを手動で完了する必要があります。

Order Managementの実装の一部として、Order Managementの新規の職責を設定し、受注の作成と管理を行うユーザーにその職責を割り当てます。アップグレード後のスクリプト（ontupg48.sql）によって、各営業単位に対する一意のユーザー（受注/明細の作成者）がすべてリスト表示されます。もう1つのアップグレード後のスクリプト（ontupg49.sql）では、例外（1つの営業単位を指し示す複数の職責を持つユーザーまたは職責を持たないユーザー）がリスト表示されます。前者の場合は、いずれかの職責で「OM: アップグレードされた受注用コンテキスト職責」を「Yes」に設定する必要があります。後者の場合は、必要なプロファイルが正しく設定された適切な職責をそのユーザーに割り当てる必要があります。

スクリプト（ontupg49.sql）で例外がリスト表示されない場合は、スクリプト（後半のアップグレード後ステップにあるontup255.sql）を実行してワークフロー項目属性をアップグレードします。このスクリプトによって、すべての受注および明細で使用するコンテキスト職責を、それを作成したユーザーおよび受注が作成された営業単位に基づいて簡単に識別できます。スクリプトontupg49.sqlでなんらかのレコードが戻された場合、停止してontupg48.sqlの結果を検討し、ontupg49.sqlで空のレポートが戻されるまで適切な職責を設定します。

例

次に、スクリプトontupg48.sqlによって作成されたサンプル・リスト（ontupg48.lst）を示します。

一覧レポート

この例には、（受注または明細を作成した）3つの営業単位に対するアクセス権を持つ4名のユーザーがいます。Order ManagementまたはOM以外（OMの他にカスタム・アプリケーションを使用する場合）の3つの職責を新たに作成できます。例では、複数組織のインストールが示されているため、新規の各職責について「MO: 営業単位」プロファイル・オプションを適切な値に設定する必要があります。各職責について「OM: アップグレードされた受注用コンテキスト職責」を「Yes」に設定すると、サイクル履歴のアップグレードで職責が使用されます。受注を処理するためには、他のプロファイル・オプションも設定する必要があります。

これで、新規の職責が4名のユーザーに適切に割り当てられたため、この4名のユーザーは、以前のリリースと同じ組織にアクセスできます。

ユーザーNDSMITHは2つの営業単位にアクセスするため、このユーザーには2つの異なる職責を割り当てます。これによって、両方の職責とも、それが指し示す営業単位のコンテキスト職責として使用されます。

このステップで実行したユーザー/組織の組合せに対する職責の設定を検証するには、スクリプトontupg49.sqlを実行します。このスクリプトで作成されたレポートにエラーがある場合は、設定を訂正し、スクリプトを再度実行して設定が正しいことを確認します。

プロファイル・オプション - 「OM: 通知承認者」

Order Entryでは、「受注の承認」フォームにアクセス可能なすべてのユーザーが、承認に適格な受注または明細を承認できました。前述したように、承認サイクル処理はワークフロー通知アクティビティに変換されています。応答が必要な通知は、WFロールに送信する必要があります。

「OM: 通知承認者」プロファイル・オプション値によって、アップグレードされた通知の送信先が判別されます。このプロファイル・オプションは、サイト、アプリケーション、職責またはユーザーの各レベルで設定でき、任意のワークフロー・ロール（アプリケーション職責またはユーザー）を設定できます。

Order Entryの承認と同様の機能を使用するには、その機能をアプリケーション職責に設定します。このプロファイルを職責レベルで設定すると、ユーザーには少なくとも、特定の営業単位に対して異なる承認者ロールを指定できます。

アップグレードされた受注または明細上の特定のユーザー、職責およびアプリケーションについて、「OM: 通知承認者」プロファイルにNULL値が設定されている場合、通知はSYSADMINユーザーに送信されます。

承認処理のアップグレードについて前述したように、通知アクティビティの応答者は、ワークフロー項目属性の「通知承認者」値によってデフォルト設定されます。このワークフロー項目属性は、「OM: 通知承認者」プロファイル・オプションの値に基づき、スクリプト（後半のアップグレード後ステップにあるontup255.sql）によって設定されます。

アップグレードされた受注および明細に関するWF項目属性値の更新

Order Managementでヘッダー・フローまたは明細フローを開始すると、特定のワークフロー項目属性値も設定されます。

アップグレード処理でアップグレードされた受注および明細のフローを開始すると、これらの属性の一部が設定されます。ただし、他の特定の属性を設定するには、特定のアップグレード後ステップを手動で完了し、属性を更新するスクリプトを実行する必要があります。

前述したように、アップグレード後スクリプトontupg48.sqlにリスト表示されている全ユーザーに、（Order Management）職責を割り当てる必要があります。次に、スクリプトontupg49.sqlによって、例外がリスト表示されないことを確認します。また、必要に応じて、「OM: 通知承認者」プロファイル・オプションを設定する必要があります。

ここで、スクリプトontupg255.sqlを実行し、アップグレードされた受注フローおよび明細フローについて、次のワークフロー項目属性を更新できます。

職責ID（RESPONSIBILITY_ID）

アプリケーションID（APPLICATION_ID）

通知承認者（NOTIFICATION_APPROVER）

すべてのアップグレード後ステップを正常に完了した場合のみ、Order Managementのワークフロー項目（OM受注ヘッダー、OM受注明細）に対してワークフロー・バックグランド・エンジンを開始できます。

サイクルのアップグレードとその他のOrder Entry機能

サイクルのアップグレードとセキュリティ・ルール

Order Entryのセキュリティ・ルールは、サイクル・ステータスに基づいて定義できました。Order Managementへのアップグレード処理では、次の理由から、ユーザー定義のセキュリティ・ルールはアップグレードされません。

• Order Managementは、Order Entryリリース10/11よりもかなり柔軟性があります。セキュリティ・ルールを検証して、新しい製品でそのセキュリティ・ルールが必要かどうかを決定することをお薦めします。

• Order Managementの制約フレームワークによって、ロールベースの制約を定義できるため、これを使用することを検討してください。

• Order ManagementとOrder Entryではデータ・モデルはかなり異なるため、セキュリティ・ルールを自動的かつ正確にアップグレードできません。

アップグレードされた承認に基づいて制約を定義する場合は、次の点に注意してください。

「処理制約」フレームワークにより、ワークフロー・ステータスに基づいて制約を定義できます。

前述したように、通知のアップグレード処理では、受注または明細がOrder Entryですでに承認処理を通過している場合、実際の通知アクティビティはスキップされます。これは、通知アクティビティのみに基づいて制約を定義できないことを意味します。したがって、事前通知アクティビティに基づいて制約を定義する必要もあります。

例

受注の支払条件は、「法的承認」アクティビティを通過した後は変更できません。

これをサポートするため、次の条件で制約を定義する必要があります。

• 受注が「法的承認」通知アクティビティを「合格」結果で通過すること。

または

• 「法的承認」の前にある事前通知アクティビティを「合格」結果で通過すること。

• 通知アクティビティと事前通知アクティビティの命名規則については、前の項を参照してください。

サイクルのアップグレードと保留

Order Entryでは、一般保留またはサイクル処理固有の保留を定義できました。アップグレード処理では、保留定義を定義した全ユーザーおよびその他の保留データを移行します。シードされていないサイクル処理に基づくサイクル処理固有の保留は、一般保留としてアップグレードされます。シードされているサイクル処理に基づくサイクル処理固有の保留は、アクティビティ固有の保留としてアップグレードされます。

保留が原因で受注または明細がOrder Entryで未処理の場合は、アップグレード後もOrder Managementで保留になります。

例

旧システムの受注が一般保留になっているため記帳できません。受注は記帳適格のままです。アップグレード後、その受注は記帳適格になります。その受注を記帳しようとすると、一般保留になっているため操作に失敗します。

注意: Order Managementの通知アクティビティでは、保留は優先されません。カスタム・アクティビティで保留を優先させる場合は、外部処理を使用して保留をチェックする必要があります。「Oracle Order ManagementでのOracle Workflowの使用」も参照してください。

受注タイプからの移行/アップグレード

旧リリースのOracle Order EntryからOracle Order Managementにアップグレードすると、既存の受注タイプは新規の受注および明細取引タイプにアップグレードされます。既存の受注サイクルは、新規の受注および明細ワークフロー・プロセスにアップグレードされます。このようにアップグレードされたワークフローは、新規受注に使用しないでください。この種のワークフローには、ステータスをチェックする多数のアクティビティが含まれ、アップグレード済の受注には必要ですが、新規受注には非効率的です。アップグレードの一部として、アップグレード後の取引タイプに対応付けられたフローを、新規OM受注用に作成されたシード済またはカスタム・フローとして設定する必要があります。

また、既存の受注番号ソースは文書連番にアップグレードされることに注意してください。アップグレード後の受注タイプに関して文書連番のカテゴリが作成され、適切な連番に割り当てられるため、通常は変更の必要はありません。

直接出荷の変更管理に関するアップグレード時の考慮事項:

ユーザーが受注と発注の差異レポートを実行し、新規のパックにアップグレードする前に差異を修正することをお薦めします。アップグレード後は、差異のある受注上の変更管理はサポートされません。

Oracle Order Managementのプロファイル・オプションの移行

次のリストでは、Order Entryの旧プロファイル・オプションとOrder Managementの新規プロファイル・オプション（ある場合）を対比させています。Order Managementの新規プロファイル・オプションは、表の右側にリストされています。これらのプロファイル・オプションの詳細と使用方法は、このマニュアルの「基本設定」の章を参照してください。

プロファイル・オプション

システム・パラメータの設定

Order Managementでは、旧プロファイル・オプションの「OE: 品目検証組織」と「OE: 顧客関連」がシステム・パラメータに変換されています。これらのプロファイル・オプションは、サイト・レベルでの設定が可能でした。

これらのプロファイル・オプションは、システム・パラメータとして営業単位レベルで設定できるようになりました。設定画面には、Order Managementのスーパーユーザー職責でアクセスでき、「設定」→「パラメータ」にナビゲートします。オープンすると、デフォルトの営業単位（職責に対する「MO: 営業担当」）が表示されます。品目検証組織（在庫組織）の値を設定し、指定した営業単位での品目取引に使用する在庫組織を定義できます。営業単位に対する「顧客関連」フラグによって、受注入力時に、関連する顧客の出荷先事業所と請求先事業所をユーザーが指定できるかどうかが定義されます。

Oracle Order Managementフレックスフィールドの移行

この項では、Order EntryからOrder Management 11iへのフレックスフィールドの移行について説明します。後述するように、OEのフレックスフィールド定義はOMにアップグレードされず、OEの表に含まれているフレックス値のみがOM/QP/WSHの各表にアップグレードされます。対応するOM/QP/WSHフレックスフィールドに対する定義は、お客様が新たに作成する必要があります。

付加フレックスフィールド

注意: 表のヘッダーにあるUpgは、「OEからOM/QP/WSHにアップグレードされる値」を意味します。

Shipping Executionの移行

概要

この項では、Shipping Executionのリリース10.7からリリース11i、およびリリース11からR11iへの移行について説明します。

機能上の相違点

出荷セットの検証

リリース10.7およびリリース11では、ピック・リリース時に、未リリース明細および出荷残明細について出荷セットが検証されます。

リリース11iでは、ピック・リリース時には出荷セットを検証せずに出荷確認時に出荷セットを検証することを選択できます。受注明細は、出荷セット内に含まれるかどうかにかかわらず、有効数量がリリースされます。

「出荷セットおよび出荷モデルの強制」というパラメータ制御があります。この制御が使用可能な（チェックされている）場合、出荷セットは出荷確認時に加え、ピック・リリース時にも検証されます。この制御が使用不可の（チェックされていない）場合、出荷セットは出荷確認時に検証されます。

注意: 出荷セットの細分化を承認した場合、細分化後の出荷は元の出荷セット・グループの一部にはなりません。細分化後の未出荷明細の数量は、個別の明細として出荷セットから分離されます。

注意: 11iには、出荷残明細を出荷セットの一部として残すプロファイル・オプションWSH: 出荷残明細に対する出荷セット/SMCの検証があります。たとえば、出荷セットの一部に明細が4つあり、ピック・リリース中に2つの明細は出荷残に、2つはステージ/ピック確認済になった場合も、すべての明細が出荷セットに残り出荷確認時に検証されます。

出荷モデル完了の検証

リリース10.7およびリリース11では、ピック・リリース時に未リリース・モデルと出荷残モデルについて出荷モデル完了が検証されます。

リリース11iでは、出荷モデル完了は出荷確認時に検証されます。

「出荷セットおよび出荷モデルの強制」というパラメータ制御があります。この制御が使用可能な（チェックされている）場合、出荷モデル完了は出荷確認時に加え、ピック・リリース時にも検証されます。この制御が使用不可の（チェックされていない）場合、出荷モデル完了は出荷確認時に検証されます。

在庫管理

リリース10.7およびリリース11では、プロファイル「OE: 予約」が「Yes」の場合は、ピック・リリース済品目の在庫管理を選択または更新できません。

リリース11iでは、ピック確認時に任意の品目の在庫管理を更新できます（「OE: 予約」は廃止されています）。

出荷確認オープン・インタフェースおよびパブリックAPI

リリース10.7およびリリース11では、出荷確認オープン・インタフェース・プロセスをアプリケーション・メニューから発行できます。

リリース11iでは、出荷確認オープン・インタフェースのアプリケーション・メニューは、パブリックAPIに置き換えられました。

Shipping Execution 11iのパブリックAPIは、オラクル・サポート・ホームページで表示できます。

1. オラクル・サポート・ホームページにサインオンして、「Technical Libraries」をクリックします。

2. 「Apps 11i & Euro Info」をクリックします。

3. 「Documentation」をクリックします。

4. 「Distribution/Supply Chain」領域で「Order Management」をクリックします。

5. 『Oracle Order Management Suite APIおよびオープン・インタフェース・マニュアル』をクリックして、ドキュメントを表示します。このドキュメントはPDF形式であるため、表示するにはAdobe Acrobatがインストールされている必要があります。

出荷確認の最小単位

リリース10.7では、ピック・スリップが出荷確認できる最小単位です。

リリース11およびR11iでは、搬送が出荷確認できる最小単位です。

シリアル番号の入力

リリース10.7およびリリース11では、シリアル番号は、受注明細の出荷確認時に、事前に指定したシリアル管理品目について入力します。

リリース11iでは、シリアル番号は、事前に指定したシリアル管理品目のピック確認時に入力する必要があります。また、出荷確認時にシリアル番号を入力および更新することもできます。

ピック・スリップ、バッチおよび搬送

リリース10.7では、ピック・スリップとオープン・バッチ・レポートの連結が可能です。

リリース11では、オープン状態の搬送を問い合せ、「出荷確認搬送」フォームから搬送を直接処理できます。ピック・スリップ・レポートはそのまま使用できます。

リリース11iでは、オープン状態の搬送を問い合せ、「取引」フォームから搬送を直接処理できます。ピック・スリップ・レポートはそのまま使用できます。

移行: 共通する技術的な考慮点

WSH_DELIVERY_DETAILSには、Shipping Executionで処理が必要なすべての明細が格納されます。SOURCE_CODE = 'OE'によって、OEからインポートされた明細を識別します。

• WSH_DELIVERY_DETAILS.SOURCE_HEADER_NUMBERには、受注番号が格納されます。

• WSH_DELIVERY_DETAILS.SOURCE_HEADER_IDには、OE_ORDER_LINES_ALL.HEADER_IDが格納されます。

• WSH_DELIVERY_DETAILS.SOURCE_LINE_IDには、OE_ORDER_LINES_ALL.LINE_IDが格納されます。

• ORG_FREIGHTの運送業者情報は、参照lookup_type = ‘SHIP_METHOD'で（FND_LOOKUP_VALUES）にアップグレードされます。

アップグレードされる表: ORG_FREIGHTおよびSO_PICKING_RULES

• WSH_CARRIER_SHIP_METHODSには、運送業者と出荷方法との間のリンクが格納されます。また、ORG_FREIGHT内のアップグレード済の各レコードは、FND_LOOKUP_VALUESおよびWSH_CARRIER_SHIP_METHODS内のレコードに対応します。

• すべての文書セットは、参照の目的でアップグレードされます。ユーザーは、文書セット明細を該当する新規レポートの内容に手動で更新する必要があります。

• SO_PICKING_RULESはWSH_PICKING_RULESにアップグレードされますが、document_setはNULLになるため、手動で更新する必要があります。

WSH_DELIVERY_DETAILS.RELEASED_STATUSに設定できる値は、次のとおりです。

• リリース準備: 明細は記帳済ですが、ピック・リリースに発行されていません。

• 倉庫へのリリース: ピック・リリースが開始しているが未完了です。割当が作成されていないか、ピック確認されていません。

• リリース未準備: 搬送明細が手動でShippingにインタフェースされると、このステータスになります。搬送明細は予定作成済ではなく、予約もありません。明細がOrder Managementから自動的にインポートされた場合、このステータスは使用されません。

• 出荷残: 明細はピック・リリース済だが、割当が行われていないか、分割割当が行われています。たとえば、搬送明細の数量が100の品目が割当に引当可能な数が25とした場合、当初搬送明細が分割され、新規明細の未割当分の数量は75でステータスは「出荷残」となります。当初明細の割当分の数量は25で、ステータスは「ステージ残」となります。

• 適用なし: 品目が出荷可能だが取引不可の場合に搬送明細に適用されます。例として、LPN（コンテナ）、作業指示または組立指示があります。

• ステージ/ピック確認済: 明細は正常にピック・リリース（詳細化およびピック確認）されています。このステータスはピック確認後に発生し、ソース事業所から工程内事業所への保管場所の移動が完了したことを示しています。明細のステータスは、出荷確認されるまでステージ残のままです。

• 出荷済: 明細が関連付けられている搬送が「出荷確認済」だが、まだOrder Managementにインタフェースされていません。

• 取消済: 受注が取り消されています。

• インタフェース済: 明細が関連付けられている搬送が出荷確認済でOrder Managementにインタフェースされています。

リリース10.7からリリース11iへの技術的な移行

ピッキング・ヘッダー、搬送およびトリップ

アップグレード後、すべてのクローズ済ピッキング・ヘッダー（SO_PICKING_HEADERS_ALL内）にはdelivery_id（連番から生成）が割り当てられます。リリース11iでは、各搬送はWSH_NEW_DELIVERIESに移動します。

WSH_NEW_DELIVERIESに挿入された各搬送について、トリップが作成され、レコードがWSH_TRIPSに挿入されます。

作成された各搬送について、レコードがWSH_DELIVERY_LEGSに挿入されます。ここで、PICK_UP_STOP_IDは、明細が出荷された倉庫に添付されたlocation_idです。DROP_OFF_STOP_IDは、SO_PICKING_HEADERS_ALL.SHIP_TO_SITE_USE_IDのlocation_idです。

作成された各トリップについて、2つのレコードがWSH_TRIP_STOPSに挿入されます。1つは、明細が出荷される倉庫のlocation_idとしてSTOP_LOCATION_IDが指定されたレコードで、もう1つは、SO_PICKING_HEADERS_ALL.SHIP_TO_SITE_USE_IDのlocation_idです。

出荷残明細

リリース10.7では、すべての出荷残明細は、RELEASED_STATUS = ‘B'およびordered_quantity = backordered_quantityに設定された新規明細としてWSH_DELIVERY_DETAILSに作成されます。Oracle Shipping Executionリリース11iへのアップグレードで、出荷残明細のステータスは「出荷残」に変更されます。

ピック・スリップ、梱包伝票および荷受証

最初にSO_PICKING_HEADERS_ALLに格納されたピック・スリップ番号は、リリース11iにアップグレードされません。

新規のピック・スリップ番号は、MTL_MATERIAL_TRANSACTIONSおよびMTL_MATERIAL_TRANSACTIONS_TEMPに格納されます。

リリース10.7でピック・スリップの出荷確認時に入力されたボックス数（so_picking_headers_all.number-of_boxesに格納されています）は、リリース11iのアップグレード処理時にアップグレードされたり、削除されることはありません。

「出荷取引」フォームのフィールド「LPN数」と、「搬送」タブの付いたリージョンに対しては、so_picking_headers_all内のnumber_of_boxesをWSH_NEW_DELIVERIES内のnumber_of_LPNにアップグレードするスクリプトがあります。

リリース10.7からアップグレードした受注明細については、梱包伝票レポートおよび荷受証レポートは生成できません。

リリース11iでは、一意の連番によってレポートの各インスタンスが識別されます。最初のステップとして、これらのレポートをリリース11iで生成する必要があります。

クローズ済のピッキング・ヘッダーに添付するSO_PICKING_LINE_DETAILS内の各明細は、WSH_DELIVERY_DETAILSに移動しています。

リリース11からリリース11iへの技術的な移行

搬送と搬送レグ

WSH_DELIVERIESのデータはWSH_NEW_DELIVERIESに移動し、WSH_DELIVERIES.DELIVERY_ID = WSH_NEW_DELIVERIES.DELIVERY_IDに設定されます。

すべての搬送について、レコードがWSH_DELIVERY_LEGSに作成されます。

出発とトリップ

WSH_DEPARTURESのデータはWSH_TRIPSに移動し、WSH_DEPARTURES. DEPARTURE_ID = WSH_TRIPS.TRIP_IDに設定されます。

リリース11では、すべての出発について、レコードがWSH_TRIP_STOPSに作成されます。

コンテナと搬送詳細

WSH_PACKED_CONTAINERS内の各コンテナはコンテナ・インスタンスになります。つまり、レコードがWSH_DELIVERY_DETAILSに挿入され、container_flag = Yおよびsource_code = WSHに設定されます。

WSH_PACKED_CONTAINERS内の各コンテナについて、レコードがWSH_DELIVERY_ASSIGNMENTSに挿入されます。

WSH_CONTAINER_LOADは、WSH_CONTAINER_ITEMSにアップグレードされます。

レポート・セットと使用コード

WSH_REPORT_SETSはWSH_REPORT_SETSにアップグレードされます。ただし、usage_codeは、PICK_RELEASE_DELIVERYからPICK_RELEASEに変更され、SHIP_CONFIRM_DELIVERYからSHIP_CONFIRMに変更されます。

ピック・スリップとピック・スリップ・グループ化ルール

WSH_PICK_SLIP_RULESはWSH_PICK_GROUPING_RULESにアップグレードされます。

アップグレードされないデータ

付加フレックスフィールド

付加フレックスフィールドの属性値はアップグレードされますが、その定義はアップグレードされません。付加フレックスフィールドは、アップグレード後に再定義する必要があります。

文書セット

文書セットは、アップグレード後に再定義する必要があります。

プロファイル・オプション

リリース10.7および11.0で使用されているプロファイル・オプションは、アップグレードされません。

コンカレント・プログラムOEIIRA

リリース10.7の売掛管理インタフェースのプログラム名（つまり、実行可能ファイル）はOEIIRAで、リリース11.0での名前はWSHARIでした。

リリース11iでは、売掛管理インタフェースはOracle Shipping ExecutionからOracle Order Managementに移されました。

Copyright © 2000, 2006, Oracle. All rights reserved.