新機能

更新24B

改訂履歴

本書は、既存の項の変更と、新規情報の追加に伴って、今後も引き続き更新されます。これまでの更新内容は次の表のとおりです。

概要

お客様のアイデアをお聞かせください

ご意見をお待ちしています。クラウド・サービスをさらに改善する方法について提案がございましたらどうぞお教えください。アイデアを送信するにはいくつかの方法があります。たとえば、Oracle Customer ConnectのIdeas Labを使用します。機能名の後にこのアイコンが表示されている箇所は、お客様のアイデアを実現した機能です。

フィードバックをお寄せください

本書の内容改善のため、ご意見やご提案をお待ちしております。フィードバックは、oracle_fusion_applications_help_ww_grp@oracle.comまでお送りください。

免責事項

この文書に記載された情報には、オラクルの製品開発プランに関する説明文が含まれていることがあります。オラクルの製品開発プランと、今後の製品リリースの本質および時期に対し、様々な要因が大きく影響を及ぼします。したがって、この情報はあくまで情報として提供されるものであり、マテリアルやコード、機能を提供することのコミットメント(確約)ではないため、購買決定を行う際の判断材料になさらないでください。記載されている機能の開発、リリースおよび時期については、オラクルの単独の裁量により決定されます。

この情報は、オラクルおよびその子会社や関連会社との契約を構成するものではありません。特にこの情報についてオラクルは一切の責任を負いかねます。詳細は、法律上の注意点および使用条件を参照してください。

更新前および更新後のタスク

クラウド・アプリケーションで使用している機能によっては、四半期更新の直前または直後に特定のステップを実行する必要がある場合があります。これらの更新前および更新後のステップおよび影響を受ける製品領域の詳細は、My Oracle SupportでOracle Fusion Cloud SCM: Performing Your Quarterly Update (文書ID 2337485.1)を参照してください。

任意の新機能の導入(オプトイン)

Oracle Cloudアプリケーションは、四半期ごとに新しい更新を配信します。つまり、ビジネスの効率的かつ効果的な管理に役立つ新しい機能を3か月ごとに受け取ります。一部の機能は使用可能な状態でされ、エンド・ユーザーが即時に使用できます。その他の機能はすぐ使用できない状態で提供され、使用可能にするために処理を実行する必要があります。無効化の状態で提供されている機能は、次のステップでエンド・ユーザーに対してアクティブ化できます。これを行うには、次の権限を使用します。

• アプリケーション・オファリングのレビュー(ASM_REVIEW_APPLICATIONS_OFFERINGS_PRIV)
• Oracle Fusion Applicationsオファリングの構成(ASM_CONFIGURE_OFFERING_PRIV)

新機能をオプトインする方法を次に示します。

1. 「ナビゲータ」→「自分の企業」→「新機能」をクリックします。
2. 機能の概要のページで、オファリングを選択し、それに固有の新機能をレビューします。または、デフォルトの選択である「すべての使用可能オファリング」をそのまま使用して、すべてのオファリングの新機能を確認できます。
3. 「新機能」タブで、新機能を確認し、「使用可能」列で機能のオプトイン・ステータスを確認します。機能がすでに有効化されている場合は、チェック・マークが表示されます。それ以外の場合は、機能を使用可能にするアイコンが表示されます。
4. 「使用可能」列にあるアイコンをクリックし、機能を使用可能にするステップを完了します。

「新機能」作業領域に表示されない機能をオプトインすることもできます。オプト・インする方法を次に示します。

1. 「ナビゲータ」→「自分の企業」→「オファリング」をクリックします。
2. 「オファリング」ページで、オファリングを選択し、「オプト・イン」機能をクリックします。
3. 「オプトイン」ページで、オファリングまたは機能が含まれている機能領域の「機能の編集」(鉛筆)アイコンをクリックします。
4. 「機能の編集」ページで、機能を使用可能にするためのステップを完了します。

オファリングの新機能をオプトインする方法の詳細および詳細な手順は、オファリングの構成を参照してください。

オプト・イン失効

オプトインを介して無効化された状態で提供される機能は、将来の更新で自動的に有効化される場合があります。これはオプト・イン失効と呼ばれます。クラウド・サービスにオプト・イン失効がある場合、このドキュメントに関連タブが表示されます。このタブをクリックすると、最初に機能が無効状態で提供されたのはいつか、そしてこの機能のオプト・インがいつ失効し、自動で使用可能となる見込みかが表示されます。ここをクリックして、すべてのOracle Cloudアプリケーションのオプト・インが失効した機能を確認することもできます。

機能のサマリー

サプライ・チェーン・オーケストレーション

サプライ・チェーン・オーケストレーション

再設計されたページを使用した供給要求の表示

再設計されたページを使用して、デスクトップ、タブレットまたはモバイル・デバイスで供給要求とその詳細を表示します。供給要求参照、供給オーダー、供給文書または品目を使用して、供給要求を検索できるようになりました。独自のデフォルト検索を作成して保存します。供給の要求日、要求搬送日、要求ステータスなどに従って検索結果をフィルタします。例外を削除するために必要な推奨処理を表示します。Oracle Supply Chain Orchestrationが各要求に対して作成した供給文書を表示します。要求明細の詳細を表示し、処理を実行します。

この機能を使用するには、「供給オーケストレーション」作業領域に移動し、「タスク」>「供給要求」をクリックしてから、供給要求を検索します。

供給要求を検索および表示する際の効率が向上します。

有効化のステップ

この機能を有効にするには、オプト・インUIを使用します。手順は、この文書の「新機能のオプションの取込み」の項を参照してください。

オファリング: 製造およびサプライ・チェーン資材管理

ヒントと考慮事項

次の属性を使用して、供給要求を検索します。

• 供給要求参照
• 供給オーダー
• 供給文書
• 品目

次の属性を使用して検索結果をフィルタ処理します。

• 供給要求日
• 要求搬送日
• 供給ステータス
• 供給タイプ
• ビジネス・フロー

詳細:

• 各供給要求の供給文書に関する詳細を表示します。
• 独自の検索を作成して保存します。その検索をデフォルトの検索にします。
• 供給要求にドリルダウンして、供給要求および存在する可能性のある例外メッセージの詳細を取得します。
• 供給要求が例外の場合、修正するための推奨処理を表示できます。
• 各供給要求に対して様々な処理を実行します。

主なリソース

• Oracle Help Centerのサプライ・チェーン・オーケストレーションの使用およびサプライ・チェーン・オーケストレーションを参照してください。

アクセス要件

ユーザーにこの機能へのアクセス権を付与するために、事前定義済ジョブ・ロールを割り当てるか、自分で構成したジョブ・ロールを割り当てるかに応じていくつかのオプションがあります。

• 次の事前定義済ジョブ・ロールのいずれかが割り当てられているユーザーは、この機能にアクセスできます。
  • サプライ・チェーン運用マネージャ(ORA_DOS_SUPPLY_CHAIN_OPERATIONS_MANAGER_JOB)

• 次の権限を含む構成済ジョブ・ロールが割り当てられているユーザーは、この機能にアクセスできます。
  • 供給オーダー・インタフェースの処理(DOS_PROCESS_SUPPLY_ORDER_INTERFACE_PRIV)
  • 供給オーダーの表示(DOS_VIEW_SUPPLY_ORDERS_PRIV)
  • 供給要求例外の管理(DOS_MANAGE_SUPPLY_REQUEST_EXCEPTIONS_PRIV)
  • 供給オーダー例外およびステータスの表示(DOS_VIEW_SUPPLY_ORDER_EXCEPTIONS_AND_STATUS_PRIV)

独自のジョブ・ロールを保守している場合、この機能をサポートするための新しい権限は導入されていません。

コラボレーション・メッセージング・フレームワーク

コラボレーション・メッセージング・フレームワーク

AvalaraおよびTIE Kinetixサービス・プロバイダのB2B設定の簡略化

B2B設定のプロセスは、AvalaraおよびTIE Kinetix事前定義済サービス・プロバイダに対して合理化されています。サービスにサブスクライブしている場合は、取引先と接続し、より簡単にメッセージを交換できます。

これらのサービス・プロバイダのエンドポイントが事前定義され、「コラボレーション・メッセージング」作業領域でのB2B設定を合理化する新しい簡易プロセスが提供されます。

有効化のステップ

これらのサービス・プロバイダを設定するには、概して次の手順に従います。

1. 取引先とメッセージを交換するようにサービス・プロバイダを構成します。
2. 取引先を作成します。
3. 顧客またはサプライヤに取引先を関連付け、交換する文書を選択します。

これらのステップの詳細は、Oracle Fusion Cloud SCMのB2Bメッセージングの構成および管理ガイドを参照してください。

事前定義済サービス・プロバイダAvalaraまたはTIE Kinetixを、取引先とのメッセージ交換用に構成します。

1. 「タスク」パネル・タブから「コラボレーション・メッセージング・サービス・プロバイダの管理」を選択し、「Avalara」または「TIE Kinetix」のいずれかを検索して、「処理」>「編集」を選択します。

「概要」タブには、サービス・プロバイダに関する次の詳細が表示されます。

• 構成されている接続タイプ(「テスト」または「本番」)。
• 資格証明が構成されているかどうかを示すチェック・ボックス。
• サービス・プロバイダに対して構成された取引先の数。
• 上書きメッセージ定義がある取引先の数。
• サービス・プロバイダで設定されている顧客の数。

TIE Kinetixのサービス・プロバイダの概要

2. アウトバウンド・メッセージ配信の設定を構成するには、「処理」 > 「配信設定の管理」を選択します。

• • 「アウトバウンド配信接続タイプ」ドロップダウンで、設定している環境に応じて「テスト」または「本番」を選択します。

• • 「サービス・プロバイダ・ユーザー名」および「パスワード」フィールドに、ネットワークにメッセージを送信するためにAvalaraまたはTIE Kinetixによって提供されるユーザー名とパスワードを入力します。

配信設定の管理

3. 「アウトバウンド・メッセージ設定」タブを選択して、アウトバウンド・メッセージをアクティブ化します。

Avalaraで使用可能なアウトバウンド・メッセージは次のとおりです。

• 請求書

TIE Kinetixで使用可能なアウトバウンド・メッセージは次のとおりです。

• 請求書
• 購買オーダー
• 購買オーダーの変更

Avalara - アウトバウンド・メッセージ設定

4. 「インバウンド・メッセージ設定」タブを選択して、インバウンド購買オーダーをアクティブ化します。

Avalaraで使用可能なインバウンド・メッセージは次のとおりです。

• 請求書の確認
• 請求書

TIE Kinetixで使用可能なインバウンド・メッセージは次のとおりです。

• 請求書の確認
• 購買オーダーの確認
• 請求書
• 出荷

Avalara - インバウンド・メッセージ設定

取引先の作成

サービス・プロバイダの設定が完了したら、取引先を作成します。

1. 「タスク」パネル・タブで「B2B取引先の管理」を選択します。
2. 「B2B取引先の管理」ページで、「処理」 > 「作成」を選択し、取引先を追加します。
3. 「Avalara」または「TIE Kinetix」を使用しているサービス・プロバイダとして選択します。

取引先の作成

取引先と顧客の関連付け

次に、取引先を顧客に関連付け、交換する予定の文書を選択します。

1. 「タスク」パネル・タブで「顧客アカウント・コラボレーション構成の管理」を選択して、顧客を検索します。

2. 顧客を選択し、「コラボレーション構成の編集」を選択します。

3. 「関連サービス・プロバイダ」セクションを「顧客アカウント・コラボレーション構成の編集: {CUSTOMER_NAME}」ページで選択し、「処理」>「行の追加」を選択し、取引先とサービス・プロバイダを追加します。

4. 「サービス・プロバイダ用のコラボレーション文書」セクションで、「処理」>「行の追加」を選択し、交換する文書を追加し、それらの「関連ステータス」を「使用可能」に設定します。

AvalaraおよびTIE Kinetixサービス・プロバイダには、次の文書があります。

• 請求書確認インバウンド
• 請求書アウトバウンド

顧客アカウント・コラボレーション構成

取引先とサプライヤの関連付け

1. 「タスク」パネル・タブで「サプライヤB2B構成の管理」を選択し、サプライヤを検索します。

2. サプライヤを選択して、「サプライヤB2B構成の編集」を選択します。

3. 「サプライヤB2B構成の編集」ページで、「取引先割当」タブを選択し、「処理」>「行の追加」をクリックして、取引先とAvalaraまたはTIE Kinetixサービス・プロバイダを追加します。

Avalaraサービス・プロバイダには、次の文書を設定できます。

• 請求書 - インバウンド

TIE Kinetixサービス・プロバイダには、設定に使用できる次の文書があります。

• 事前出荷通知 - インバウンド
• 購買オーダー確認 - インバウンド
• 請求書 - インバウンド
• 購買オーダー - アウトバウンド
• 購買オーダー変更 - アウトバウンド

サプライヤ・サイトの文書設定

ヒントと考慮事項

このリリースより前にTIE Kinetixサービスを使用した場合は、メッセージ定義名の先頭に'TIEKinetix_'が付けられていることがわかります。「コラボレーション・メッセージ定義の管理」タスクのサービス・プロバイダのリストから「TIE Kinetix」を選択して、メッセージ定義を検索できます。

主なリソース

• Oracle Help CenterでOracle Fusion Cloud SCMのB2Bメッセージングの構成と管理ガイドを参照してください。

アクセス要件

次の権限を含む構成済ジョブ・ロールが割り当てられているユーザーは、この機能にアクセスできます。

• B2B顧客取引先の管理(CMK_B2B_CUSTOMER_TRADING_PARTNERS_PRIV)
• 顧客アカウント・コラボレーション構成の管理(CMK_B2B_CUSTOMER_ACCOUNT_TRADING_PARTNERS_PRIV)
• B2B取引先の管理(CMK_B2B_TRADING_PARTNERS_PRIV)
• サービス・プロバイダの管理(CMK_MANAGE_SERVICE_PROVIDER_PRIV)

これらの権限はこの更新の前から使用可能でした。

PDFファイルとしての購買オーダーの送信

「購買オーダーPDFが唯一の添付の場合に未圧縮ファイルとして送信」チェック・ボックスを使用して、サプライヤにEメールで非圧縮PDFファイルとして購買オーダーを送信できます。このオプションは、購買オーダーがメッセージで使用可能な唯一の添付である場合に適用できます。

この機能により、自動システムを持たない小規模なサプライヤは、受け取った購買オーダーを読みやすくなります。

有効化のステップ

Eメール配信方法は、サービス・プロバイダまたは取引先に対して、購買オーダーPDFを解凍ファイルとして送信するように構成できます。このオプションを有効にするには、次の操作を実行します。

1. 「タスク」パネル・タブから「コラボレーション・メッセージング・サービス・プロバイダの管理」を選択し、B2Bメッセージの配信に使用するサービス・プロバイダを検索します。メッセージの送受信にサービス・プロバイダを使用しない場合は、「タスク」パネルから「B2B取引先の管理」を選択します。

2. 「配信方法」タブを選択し、Eメール配信方法で、「購買オーダーPDFが唯一の添付の場合に未圧縮ファイルとして送信」チェック・ボックスを選択します。

「配信方法」タブの「購買オーダーPDFが唯一の添付の場合に未圧縮ファイルとして送信」

3. 「保存してクローズ」を選択します。

ヒントと考慮事項

購買オーダーPDFが、メッセージの唯一の添付ファイルである場合、圧縮されていないファイルとして送信されます。追加の添付がある場合、購買オーダーPDFを含むすべての添付が圧縮され、ZIPファイルとして送信されます。サプライヤがZIPファイルを受信できない場合は、Eメール配信方法の「ファイル拡張子」フィールドを使用して、Eメールで送信されるファイルの拡張子を設定できます。

主なリソース

• Oracle Help CenterのOracle Fusion Cloud SCMのB2Bメッセージングの構成および管理ガイドを参照してください。

アクセス要件

次の権限を含む構成済ジョブ・ロールが割り当てられているユーザーは、この機能にアクセスできます。

• B2B取引先の管理(CMK_B2B_TRADING_PARTNERS_PRIV)
• サービス・プロバイダの管理(CMK_MANAGE_SERVICE_PROVIDER_PRIV)

これらの権限はこの更新の前から使用可能でした。

オーダー管理

SCM共通コンポーネント

Visual Builder Studioを使用したSCM Redwoodアプリケーション・ページの拡張

Oracle Visual Builder Studioを使用して、企業のユーザーのシームレスなエクスペリエンスを調整します。Visual Builder Studioのエクスプレス・モードでビジネス・ルールを使用すると、次のことができます:

• ページのフィールドおよびリージョンを必須またはオプションにします
• ページのフィールドおよびリージョンを読取専用または編集可能にします
• 特定の基準に応じてフィールドおよびリージョンを表示または非表示にします
• 特定のビジネス・ニーズにあわせてRedwoodページを構成します。たとえば、「受入搬送」ページに表示する処理を制御したり、「PAR棚卸概要」ページで使用可能なデフォルトの日付範囲を設定できます。

ページに対して行える変更のタイプは、変更するページによって異なります。

ノート: この更新では、ビジネス・ルールはまだすべてのSCM Redwoodページではサポートされていません。

Visual Builder Studioを使用して特定のページを拡張できるかどうかを判断するには、ページに移動して「設定およびアクション」メニューを開きます。Visual Builder Studioの「ページの編集」タスクを探します。

「設定およびアクション」メニュー

「Visual Builder Studioでページを編集」タスクが表示されない場合、VB Studioでページを編集するために必要な権限が割り当てられていないか、または現在VB Studioでページを編集できないため、Visual Builder Studioを使用してページを編集することはできません。

Visual Builder Studioでページを開くときは、エクスプレス・モードのみを使用してページを拡張します。拡張モードはサポートされていません。VB Studioでページを開いたときにエクスプレス・モードを使用できない場合は、VB Studioでページを拡張できません。エクスプレス・モードは、Visual Builder Studioのヘッダー・リージョンにあります:

Visual Builder Studioのヘッダー・リージョン

Expressモードでアプリケーション・ページを拡張する方法の詳細は、Visual Builder Studio ExpressモードでのOracle Cloud Applicationsの拡張を参照してください。

有効化のステップ

Visual Builder Studioを活用して、アプリケーションを公開します。Visual Builderを使用したアプリケーションの拡張の詳細は、Oracle Help Center→関心のあるアプリケーション・サービス領域→「Books」→「Configuration and Extension」を参照してください。

Visual Builder Studioの使用を開始する前に、システム管理者が初期設定を完了する必要があります。手順については、Oracle Cloudアプリケーションを拡張するためのVB Studioの設定を参照してください。

ヒントと考慮事項

Visual Builder Studioのエクスプレス・モードで作業している間は、「ページ」リストを閉じたままにします。リストを閉じると、拡張しているページがよりわかりやすく表示されます。

Visual Builder Studioのエクスプレス・モードでは、フィールド値のデフォルト設定および検証をサポートする機能が表示される場合があります。この機能は、更新24BのSCM Redwoodページではサポートされていません。今後の更新では、選択したSCM Redwoodページのデフォルト設定および検証を使用できるようになります。

VB Studioのエクスプレス・モードでのデフォルトのフィールド値およびフィールド値の検証

主なリソース

Visual Builder Studioでアプリケーション・ページの拡張を開始するには、Visual Builder Studioへのアクセスの手順に従います。作業中は、次のリソースで追加情報を確認できます:

• Visual Builderのエクスプレス・モードでのOracle Cloud Applicationsの拡張
• Oracle Fusion Cloud HCMおよびSCM: Visual Builder Studioを使用したHCMおよびSCM用のRedwoodアプリケーションの拡張

アクセス要件

Visual Builder Studioを使用してアプリケーション・ページを拡張するには、次の権限を含む構成済ジョブ・ロールが割り当てられている必要があります:

• サンドボックスの管理(FND_ADMINISTER_SANDBOX_PRIV)

この権限はこの更新の前から使用可能でした。

オーダー管理

部分直接出荷における分割オーダー明細の属性の更新

サプライヤが直接出荷フローでオーダー明細の一部を出荷するときにOracle Order Managementによって作成される分割オーダー明細の属性を更新します。要求日にオーダー明細の一部の数量のみが使用可能である場合、直接出荷サプライヤはその数量を出荷し、オーダー管理は残りの数量のオーダー明細を分割します。更新24B以降、分割履行明細の属性を更新できます。

この機能を使用すると、Oracle Procurementが直接出荷フローでオーダー明細の一部を出荷するときにオーダー管理が作成する分割オーダー明細の属性を更新できます。

この文書で説明するすべての使用方法には、直接出荷で出荷する分割明細が含まれます。

シナリオ

サプライヤは、顧客需要を満たすために直接出荷する履行明細の一部を出荷できます。要求日にオーダー明細の一部の数量のみが使用可能である場合、サプライヤは出荷可能な数量を出荷し、オーダー管理は残りの数量の分割オーダー明細を作成します。サプライヤがまだ出荷する必要がある残数量を含む新しい履行明細があります。

サプライヤがオーダー明細の一部を出荷した後に、オーダー管理の新しい分割明細の属性を更新する必要がある場合があります。たとえば、サプライヤBに、出荷されていない明細を履行するための十分な供給があることがわかっているとします。その明細のサプライヤおよびサプライヤ・サイト属性をサプライヤBに改訂し、改訂を発行すると、オーダー管理はこれらの詳細を調達に送信して、調達がサプライヤBの新規購買オーダーを作成し、サプライヤBが要求を履行できるようにします。

分割オーダー明細の属性の更新

次のことが可能です。

• 数量、予定日、出荷事業所、出荷方法、サプライヤまたはサプライヤ・サイトを変更します。
• オーダー明細の拡張可能フレックスフィールドを使用して、購買オーダー明細の価格を変更します。
• 明細のスケジュールを取り消すか、品目を置換します。
• 「手動スケジューリング要」ステータスの明細をスケジュールまたは分割します。

オーダー管理の分割明細の属性値を更新し、その値を使用して次のことができます。

• 価格を再設定して税金を再計算します。
• 分割明細を履行して収益を認識し、請求します。
• トランザクションの原価を計算し、Oracle Cost Managementで分割明細の売上原価を認識します。
• 財務詳細をオーケストレーションし、Oracle Supply Chain Financial Orchestrationで分割明細のトランザクションを処理します。

これらの更新は、オーダー管理作業領域、REST API、またはOracle Backlog ManagementやOracle Global Order Promisingなどの他のアプリケーションを介して実行します。

購買オーダーの属性の更新

購買オーダーの一部出荷済明細の属性を更新できます。

• 納期、出荷方法または数量を変更します。
• 行のスケジュールを分割します。
• 購買オーダーの明細を取り消します。

調達が購買オーダーで受け取ったことがない明細の属性、および明細に構成品目、キットまたは品目が出荷セットに含まれている場合は、その明細の属性を更新できます。

• 数量を変更するか、スケジュールを分割します。
• 購買オーダーの明細を取り消します。

これらの更新は、調達、REST API、またはOracleサプライヤ・ポータルを介して実行します。

オーダー管理の使用

直接出荷で分割および出荷するオーダー明細で、1つ以上の属性を更新できるようになりました。

• 分割されておらず、出荷待ちの明細の属性を更新する場合と同様に、明細属性を更新します。履行ビューで処理を使用してこれを行うこともできます。

• オプションとして、「明細の更新」処理を使用して、同時に選択したすべての明細の属性を更新します。この機能にオプト・インした場合、分割明細および調達でバックオーダーするオーダー明細に対してこの処理を使用できます。

• オーダー・ヘッダーの属性を更新すると、オーダー管理によって、上書きしていないすべての分割明細に更新がカスケードされます。「オーダー明細の上書き」処理を使用して、分割明細の属性を更新することもできます。

• オーダー管理拡張または変換後ルールを使用して、分割明細の属性を更新します。

ノート:

• 出荷セットで明細を出荷し、これらの明細の少なくとも1つを一部出荷するかまたは出荷しない場合、オーダー管理では出荷していない明細がセットから削除されます。出荷セットにない明細と同様に、削除された明細の属性を更新できるようになりました。
<

• REST APIを介して、または他のアプリケーション(バックログ管理、グローバル・オーダー納期回答など)を使用して分割明細の属性を更新したものの、オーダー管理で更新できない分割明細の場合は、エラーが表示されます。

• 1つ以上の分割明細に対して予定解除処理を実行し、選択した明細の少なくとも1つの履行許容範囲が0でない場合、オーダー管理では処理の確認を求められます。背景は、「出荷許容範囲の設定に関するガイドライン」を参照してください。

履行ビューで処理を使用して分割明細を更新し、選択内容に次のものが含まれている場合、次のようになります。

• オーダー管理で更新できない分割明細のみ。この機能を使用しないと、オーダー管理に表示されるエラーと同じエラーが表示されます。

• オーダー管理で更新できる分割明細。オーダー管理によって更新され、更新できない分割明細は更新されません。

次の場合は、属性を更新できません。

• 構成品目の残余明細にあります。

• これは、Oracle Receivingが返品明細を一部受入したときにオーダー管理が作成した明細です。

• 部分直接出荷における分割オーダー明細の属性の更新機能にオプト・インする前に送信済の販売オーダーのものです。直接出荷する分割明細の属性は、この機能のオプト・イン後に送信した販売オーダーについてのみ更新できます。

オーダー管理での変更の処理方法

オーダー管理ユーザーによる属性の更新

オーダー管理では、分割されていない明細および出荷待ちの明細の変更を処理する方法と同じように分割明細の変更を処理します。更新する属性またはオーダー管理が補正する履行タスクに基づいて、異なる報酬パターンを使用できます。

分割明細の属性を更新し、オーケストレーション・プロセスでその属性を使用して履行タスクの変更を識別した場合、分割明細の更新された属性値がオーケストレーション・プロセスによって調達に送信されます。たとえば、分割明細でオーダー数量、出荷方法、予定日、出荷事業所などの属性を更新すると、オーダー管理によって調達タスクが補正され、更新された属性値が調達に送信されます。

• オーケストレーション・プロセスではすべての履行タスクを補正し、分割明細を調達に送信します。

• この機能を使用できるようになる前と同じように、販売オーダーの分割明細を取り消したり、属性を更新せずに履行できます。調達では、分割明細を履行する購買オーダー明細がクローズされます。

• 部分出荷の分割明細を取り消すと、オーダー管理において分割明細の親明細は補正されなくなります。

品目を代替するか、予定解除処理を実行するか、履行を直接出荷から標準倉庫フローまたはバック・トゥ・バック・フローに変更すると、オーダー管理は、購買オーダーをクローズするための要求を調達に送信します。

• たとえば、品目を代替すると、調達によって古い購買オーダーがクローズされ、新しい品目に対して新しい購買オーダーが作成されます。

• 分割明細の予定を取り消す場合は、明細を新しいサプライヤまたは倉庫に再スケジュールできます。

• 分割明細を改訂してサプライヤを削除し、倉庫を追加すると、調達によって購買オーダーがクローズされ、オーダー管理によって明細が倉庫にインタフェースされて履行されます。

調達のバイヤーまたはサプライヤによる属性の更新

ここでは、調達が数量の一部のみを受け取り、購買担当またはサプライヤが調達の分割明細の属性を更新したときに、オーダー管理が購買オーダーの更新を処理する方法の例をいくつか示します。

調達プロセスの変更方法

ここでは、調達がスケジュールの一部のみを受け取った場合に、オーダー管理の販売オーダーの分割明細の属性に対して行った更新を調達で処理する方法の例を示します。

サプライ・チェーン財務オーケストレーションおよび原価管理プロセスの変更方法

オーダー管理のオーダー明細の拡張可能フレックスフィールドを使用して、購買オーダーの新しい価格を追加するとします。その後、調達によって購買オーダー明細の価格が更新されます。

1. 財務オーケストレーションは、後続の各直接出荷について、更新された購買オーダー明細の価格に従って振替価格を計算します。

2. 原価管理は、後続の各直接出荷を処理するときに新しい価格を使用します。また、購買オーダー明細の新しい価格に従って、以前の各直接出荷の価格も調整されます。

3. 販売オーダー明細のサプライヤまたはサプライヤ・サイトを変更すると、調達によって新しい購買オーダーが作成され、財務オーケストレーションによって後続の直接出荷ごとに新しい財務契約が作成されます。

手持供給が使用可能になると仮定して、販売オーダー明細の供給詳細を更新し、倉庫からまだ出荷していない残数量を出荷します。この変更により、販売オーダーのフローが直接出荷から標準フローまたは関係会社間移動に変更されます。財務オーケストレーションおよび原価管理では、後続の各出荷を処理および原価計算するときに、新しいフローが使用されます。

次のような利点があります。

• 直接出荷明細の一部を出荷した後に、オーダー明細の属性を更新します。
• 出荷明細の属性の更新のみが必要な場合に、分割明細を取り消して新しい明細を手動で再作成する必要はありません。
• オーダー明細の一部を出荷した後にその明細の変更を処理するのに必要なステップの数と時間を減らします。
• 明細の一部を出荷した後の、明細の変更処理の効率および精度が向上します。
• 複数の出荷で履行する明細のトラッキングとレポートを改善します。
• 顧客満足度が向上します。

有効化のステップ

この機能を有効にするには、オプト・インUIを使用します。手順は、この文書の「新機能のオプションの取込み」の項を参照してください。

オファリング: オーダー管理

ヒントと考慮事項

• 販売オーダーをオプト・インして送信した後は、部分直接出荷における分割オーダー明細の属性の更新機能をオプト・アウトできません。この時点で、この機能を使用するようにコミットされています。

• 分割されておらず、出荷待ちの明細の属性を更新する場合と同様に、直接出荷し、構成済品目またはキットを持つ分割明細の属性は更新できますが、分割明細の構成品目は変更できません。

• 分割明細の属性を更新すると、Oracle Pricingでは、分割されていない、出荷待ちの明細の属性を更新する場合と同様に、明細の価格が再設定されます。

• 分割明細を標準フローまたはバック・トゥ・バック・フローで直接出荷する場合は、分割明細でサプライヤおよびサプライヤ・サイトを設定できます。

• 分割明細の品目を代替する場合、または品目をスケジュール解除する場合、および明細の履行許容範囲が0でない場合、履行システムは分割オーダー明細に履行許容範囲を適用しますが、すべてのオーダー明細の履行明細にわたってすでに出荷されている累計数量は考慮されません。かわりに、履行システムでは、出荷する履行明細の数量のみが考慮されます。

• Application Development FrameworkからWebサービスを使用して直接出荷する分割明細の属性を更新することはできません。

調達が数量の一部のみを受け取った場合に、バイヤーまたはサプライヤが購買オーダー明細で実行できることの要約を次に示します。

バックオーダー明細でサポートされているバイヤーおよびサプライヤの変更の要約

ノート:

• 「依存」は「はい」を意味します。ただし、標準品目またはオーダー組立品目の場合のみです。

• 品目が構成品目、キットまたは出荷セットであり、日付または出荷方法を変更する場合は、構成品目、キットまたはセットの一部であるすべての明細に同じ日付または出荷方法を適用する必要があります。

調達が数量のうちのどれも受け取っていない場合でも、出荷セットとの差異の数量に対する変更を除き、調達が数量の一部のみを受け取ったときに行える変更は、すべて行えます。

調達が数量のうちのどれも受け取っていない場合でも、出荷セットとの差異の数量に対する変更を除き、調達が数量の一部のみを受け取ったときに行える変更は、すべて行えます。

主なリソース

• 背景の詳細は、次を参照してください。
  • オーダー管理での直接出荷の概要
  • 部分出荷の分割オーダー明細の属性の更新

• 詳細は、Oracle Help Centerの次の文書を参照してください。
  • オーダー管理の実装
  • 製造およびサプライ・チェーン資材管理の実装
  • 原価会計の実装
  • 原価会計および受入会計の使用
  • サプライ・チェーン・オーケストレーションの使用
  • Functional Setup Managerの使用

アクセス要件

ユーザーにこの機能へのアクセス権を付与するために、事前定義済ジョブ・ロールを割り当てるか、自分で構成したジョブ・ロールを割り当てるかに応じていくつかのオプションがあります。

• 次の権限が含まれる構成済ジョブ・ロールが割り当てられているユーザーは、この機能にアクセスできます。
  • オーダーの開始(FOM_CREATE_ORDER_PRIV)
  • オーダーの改訂(FOM_REVISE_ORDER_PRIV)
  • オーダーの表示(FOM_VIEW_ORDERS_PRIV)
  • 購買オーダーの変更(PO_CHANGE_PURCHASE_ORDER_PRIV)
  • サプライ・チェーン財務オーケストレーション・フローの保守(FOS_MAINTAIN_SUPPLY_CHAIN_FINANCIAL_TRADE_AGREEMENT_PRIV)
  • 原価会計配分の作成(CST_CREATE_COST_DISTRIBUTIONS_PRIV)
  • 原価配分のレビュー(CST_REVIEW_COST_DISTRIBUTIONS_PRIV)

独自のジョブ・ロールを保守している場合、この機能をサポートするための新しい権限は導入されていません。

この更新で選択されたオーダー管理のバグ修正

この更新には、Oracle Order Managementの動作を変更する不具合修正が含まれています。これは、この更新のすべてのバグ修正の完全なリストではありません。このリストには、アプリケーションの動作に顕著な変化をもたらす可能性のあるバグ修正が含まれています。

オーダー改訂処理時の凍結属性の検証

販売オーダーに価格詳細が含まれていて、再計算または再評価しない場合は、オーダーの送信時に「価格設定および出荷手数料の凍結」および「税金の凍結」属性を「はい」に設定できます。更新24Bより前は、オーダー改訂を発行したときに、凍結属性の値が初期オーダーを発行したときに使用した値と一致していることを確認する必要がありました。たとえば、初期オーダーを発行したときに「価格の凍結」属性を「はい」に設定した場合は、発行したすべての後続のオーダー改訂の「価格の凍結」に「はい」が含まれていることを確認する必要がありました。

更新24B以降では、オーダー改訂の発行時に凍結属性の値を変更すると、Oracle Order Managementでエラーが表示され、属性を元の値に戻すよう要求されます。

改訂の詳細は、送信済の販売オーダーの改訂を参照してください。

Oracleリファレンス: 36038237

インポート時に価格設定を凍結するときに価格設定データを含める

更新24Bより前は、インポート時に価格設定を凍結したが、インポート・ペイロードに必要なすべての価格設定値が含まれていない場合、ダウンストリーム履行システムで問題が発生している可能性があります。たとえば、オーダー明細を売掛管理に送信する準備が整ったときに、Oracle Order Managementでエラーが発生する場合があります。

更新24B以降では、インポート・ペイロードで価格設定の凍結、出荷手数料の凍結または税金の凍結を行い、そのペイロードに「ヘッダー通貨単価」属性および「ヘッダー通貨拡張金額」属性の値が含まれていない場合、オーダー管理はインポートを拒否します。

インポート中に価格を凍結する方法の詳細は、「販売オーダーの価格の凍結」を参照してください。

Oracleリファレンス: 35851319

購買オーダー・イベントに関連するエラーからのリカバリ

バイヤーがOracle Self Service Procurementから購買依頼を戻すか取り消すと、Oracle ProcurementによってREQ_LINE_CANCELイベントが呼び出されます。更新24Bより前は、オーダー管理がこのイベントを受信したときに障害が発生した場合、販売オーダーがスタックしていました。問題を修正するには、Oracleサポートからペイロードおよびデータ修正を取得する必要がありました。更新24B以降では、「オーダーのリカバリ」処理を使用するか、「エラーのリカバリ」スケジュール済プロセスを実行して問題を修正できます。バックグラウンドの詳細は、すべての販売オーダーのエラー修正を参照してください。これらのイベントの詳細は、「オーダー管理での直接出荷の仕組み」を参照してください。

Oracleリファレンス: 35264467

有効化のステップ

この機能を有効にするために何もする必要はありません。

販売オーダー・バックオーダーを自動的に取り消して単一出荷を強制

多くの業界では、顧客契約によって、顧客のバックオーダー受け入れや複数の出荷の受け入れの可否など、特定の履行条件が指定されます。この更新の前は、顧客がバックオーダーまたは複数の出荷を受け入れなかった場合は、約束搬送日までに履行できなかった数量を手動で取り消す必要がありました。現在は、ピック確認または出荷確認中に手持数量不足のために履行できない数量を自動的に取り消すオプションがあります。さらに、オーダーを履行するために使用可能な手持数量がある場合でも、最初の出荷後に残りのオープン数量を自動的に取り消すことを選択できます(顧客がオーダーごとに1つの出荷のみを受け入れる場合)。

この機能を使用すると、Oracle Order ManagementとOracle Shippingで次の属性が追加されます。

• バックオーダーの取消: ピックのリリース、ピックの確認、出荷の確認または外部実行システムへのアウトバウンド出荷要求の作成中に手持数量不足のために履行できない数量を自動的に取り消す場合は、このオプションを「はい」に設定します。

• 単一出荷の強制: 最初の出荷が確認されてクローズされた後、オーダーの残りのオープン数量を自動的に取り消す場合は、このオプションを「はい」に設定します。

オーダー明細のこれらの属性は、「オーダー管理」作業領域の「オーダーの作成」ページ、「オーダー管理」拡張、オーダー・ハブの販売オーダー要求REST API、またはファイルベースのデータ・インポートを使用した販売オーダーのインポート(RESTバックエンドを介したFBDI)を使用して設定できます。

オーダーの作成

明細が出荷とインタフェースされると、在庫管理作業領域の「出荷明細の管理」ページで属性値を表示できます。

「出荷明細の管理」ページ

明細が「バックオーダーの取消」に設定されている場合:

• 「ピック・ウェーブの作成」プロセスでは、手持数量不足のためにバックオーダーされた出荷明細が自動的に取り消されます。

• 「出荷要求の生成」プロセスでは、手持数量不足のためにWMSまたは3PLとインタフェースできない出荷明細が自動的に取り消されます。

• 組織に対して「出荷セットの強制」出荷パラメータが使用可能になっており、手持数量不足のために出荷セット内の明細が取り消されると、出荷セット内のすべての明細が取り消されます。

• ピック確認時に、要求数量未満がピックされ、数量例外事由がバックオーダー・タイプである場合、残数量は取り消されます。

• 出荷明細でバックオーダーとして指定された数量は、出荷が確認されると取り消されます。

• 出荷明細がWMSまたは3PLとインタフェースされ、出荷明細のバックオーダーに出荷明細変更要求REST APIが使用されると、バックオーダー数量が取り消されます。

• 出荷明細がWMSまたは3PLとインタフェースされ、出荷トランザクション要求REST APIまたは出荷トランザクション・インポートの実行FBDIを使用して出荷トランザクションを実行すると、バックオーダーするように指定された数量は取り消されます。

次のシナリオでは、バックオーダーを取り消す明細を設定しても出荷明細が取り消されないインスタンスの概要を示します。

• PTOモデルまたはキットに属する出荷明細が一部バックオーダーされている場合。
• 出荷明細が出荷セットの一部であり、ピック確認時にバックオーダーされる場合。
• 出荷明細が「出荷明細および出荷の管理」ページの「バックオーダー」または「循環棚卸に送信」処理を使用してバックオーダーされる場合。

オーダーの明細が「単一出荷の強制」に設定されている場合:

• オーダーの一部出荷の場合、そのオーダー内の未出荷数量および明細は取り消されます。

• WMSまたは3PLが関係するシナリオでは、オーダーが出荷トランザクション要求REST APIを使用して部分的に出荷された場合、または出荷トランザクション・インポートFBDIを実行した場合、WMS/3PLにインタフェースされていない出荷明細は取り消されます。ただし、出荷明細がすでにWMS/3PLとインタフェースされている場合、その明細は取り消されません。

• 複数の出荷が1つのオーダーに割り当てられている場合、出荷確認、積荷目録要求の送信および会計文書生成は許可されません。

• Oracle Transportation Managementまたはその他の輸送管理システムを輸送出荷計画に使用する場合、複数の輸送出荷をオーダーに割り当てることはできません。

出荷明細が出荷で取り消されると、履行明細の取消詳細を更新するために、「オーダー履行からの応答の処理」スケジュール済プロセスが開始されます。

• オーダー数量および取消数量は、オーダーで更新されます。シード済取消事由「バックオーダーの取消」は、出荷から開始された取消に使用されます。

• オーダー明細の手数料コンポーネントは、新規オーダー数量で再計算されます。

• オーダー・ヘッダー合計は、「販売オーダー合計の更新」スケジュール済プロセスを実行またはスケジュールすることで更新されます。

• 貸方承認がオーダー明細に適用可能な場合、金額は新規オーダー数量に基づいて調整されます。「クレジット承認の金額の調整」スケジュール済プロセスを実行するか、顧客クレジット金額を調整するようにスケジュールする必要があります。

• 「バックオーダーの取消時の供給の取消」オーダー管理パラメータが「はい」に設定されている場合、部分取消の場合は供給オーダーが更新されます。待ち状態数量の供給オーダーおよびバッキング供給文書(購買オーダーや作業オーダーなど)を取消またはクローズします。

• 「ビジネス・イベント・トリガー・ポイントの管理」タスクで「バックオーダーの取消」ビジネス・イベントが有効になっている場合、取消が出荷から開始されたときにイベントが発生します。

この機能により、未履行数量を自動的に取り消し、手動工数を減らすことで、顧客の履行契約への準拠が容易になります。

有効化のステップ

この機能を有効にするには、オプト・インUIを使用します。手順は、この文書の「新機能のオプションの取込み」の項を参照してください。

オファリング: 製造およびサプライ・チェーン資材管理 オプションではなくなった開始バージョン: 更新24D

ヒントと考慮事項

• 販売オーダー・バックオーダーを自動的に取り消して単一出荷を強制のデモをご覧ください。

• 「バックオーダーの取消」および「単一出荷の強制」オプションは、明細レベルでのみ設定でき、ヘッダーからデフォルト設定することはできません。

• オーダーが送信されると、「バックオーダーの取消」および「単一出荷の強制」設定を更新できません。ただし、新しい行を追加して、必要に応じて属性を設定できます。

• カスタム・オーケストレーション・プロセスを使用する場合は、「出荷待ち」タスクの終了基準に「取消済」と「出荷済」を含める必要があります。それ以外の場合、「出荷待機」タスク・インスタンスは、完全な取消の場合にアクティブなままになることがあります。

• 出荷明細が「出荷」で取り消されると、「オーダー履行からの応答の処理」スケジュール済プロセスが開始され、履行明細の取消詳細が更新されます。プロセスが自動的に発行されない場合は、「ピック・ウェーブの作成」、「出荷要求の生成」、「ピック確認」および「出荷確認」処理を実行するユーザーが、次のいずれかの権限を含む構成済ジョブ・ロールに割り当てられているかどうかを確認します。
  • 出荷インタフェースの管理(WSH_MANAGE_DELIVERY_INTERFACE_PRIV)
  • 履行応答の処理(DOO_PROCESS_FULFILLMENT_RESPONSE_PRIV)

• 「オーダー履行からの応答の処理」スケジュール済プロセスでオーダーの取消詳細を更新できなかった場合は、スケジュール済プロセスを再送信してください。最初に発行されたときにOracle Order Managementインタフェース表から処理できなかった取消詳細を処理するには、定期的にスケジュールで実行するようにプロセスを設定することをお薦めします。
  • 「タスク・タイプ」を「出荷」に設定します
  • 「レコード・セット」を「失敗したレコードの処理」に設定します。

主なリソース

• Oracle Fusion Cloud SCM: 製造およびサプライ・チェーン資材管理の実装ガイド(Oracle Help Centerからアクセスできます)。
• Oracle Fusion Cloud SCM: Shippingの使用ガイド(Oracle Help Centerからアクセスできます)。
• Oracle Fusion Cloud SCM: Order Managementの実装ガイド(Oracle Help Centerからアクセスできます)。
• Oracle Fusion Cloud SCM: Order Managementの使用ガイド(Oracle Help Centerからアクセスできます)。
• 販売オーダー・バックオーダーを自動的に取り消して単一出荷を強制のデモをご覧ください。

アクセス要件

次の権限を含む構成済ジョブ・ロールが割り当てられているユーザーは、この機能にアクセスできます。

• ピック・ウェーブの作成(WSH_CREATE_PICK_WAVE_PRIV)
• ピック・スリップの確認(INV_CONFIRM_PICK_SLIP_PRIV)
• 出荷要求の生成(WSH_GENERATE_SHIPMENT_REQUEST_PRIV)
• 出荷の管理(WSH_MANAGE_DELIVERY_PRIV)
• 出荷および出荷明細の管理(WSH_MANAGE_SHIPMENT_AND_SHIPMENT_LINE_PRIV)
• 出荷インタフェースの管理(WSH_MANAGE_DELIVERY_INTERFACE_PRIV)
• 履行応答の処理(DOO_PROCESS_FULFILLMENT_RESPONSE_PRIV)

これらの権限はこの更新の前から使用可能でした。

価格設定

品目のカテゴリに応じた割引の適用

カタログ内の1つ以上のカテゴリに従って割引を適用します。更新24B以降、カテゴリ内の属性に従って価格設定される割引リストに価格設定マトリックスを設定できるようになりました。

販売カタログがあり、「コンピュータ」カテゴリが含まれ、「コンピュータ」カテゴリに「デスクトップ」、「ラップトップ」および「プリンタ」という3つの子カテゴリが含まれているとします。各子には品目が含まれます。たとえば、デスクトップにはAS54888コンピュータが含まれます。子デスクトップ・カテゴリの品目に割引を適用するルールを作成できます。また、すべてのデスクトップ、ラップトップ、プリンタなど、親の「コンピュータ」カテゴリにあるすべての品目に割引を適用するルールを作成することもできます。

演習

このトピックではサンプル値を使用します。ビジネス要件によっては、別の値が必要になる場合があります。

「製品情報管理」作業領域に移動し、カテゴリの階層を設定し、ABC Laptop品目をQP_Laptopsカテゴリに割り当てます。次に例を示します。

「製品ハブ・スナップショットのリフレッシュ」スケジュール済プロセスを実行します。

「設定および保守」作業領域に移動し、「価格設定パラメータの管理」ページを検索して開き、「製品カタログ」パラメータを使用して、価格設定で各品目の割引の計算時に使用する製品カタログを指定します。

「マトリックス区分の管理」ページを使用して、価格設定マトリックスを設定します。次の値を使用します。

次に例を示します。

割引リストにルールを作成します。この手順で前に作成した「Category In」条件を使用します。この例では、Laptopsカテゴリのすべての品目が15%の割引の対象となります。次の値を設定します。

次に例を示します。

作業内容をテストします。「オーダー管理」作業領域に移動し、販売オーダーを作成し、品目をオーダー明細に追加してから、価格内訳を確認します。内訳に次の内容が表示されていることを確認します。

Category In: QP_Laptops In Hierarchy QP_Laptopsであるため、属性ベースの割引ルールが適用

次に例を示します。

カテゴリ階層に従って割引を適用

親カテゴリを条件として使用するようにルールを設定できます。たとえば、「Laptops」カテゴリが親の「Computers & Accessories」カテゴリの子である場合は、ABC Laptop品目に10%の割引を適用します。

親カテゴリを条件として使用するルールの設定

内訳に次の内容が表示されていることを確認します。

Category In: QP_Laptops In Hierarchy QP_Computers & Accessoriesであるため、属性ベースの割引ルールが適用

次に例を示します。

内訳が示す内容の確認

カテゴリの除外

「Computers & Accessories」割引ルールがあり、「Printers」カテゴリを除外する必要があるとします。ABC Laptop品目に12%の割引を適用しますが、ABC Printer品目には割引を適用しないようにする必要があります。

次の値を設定します。

次に例を示します。

カテゴリの除外

カテゴリの参照

別のカテゴリを参照するようにルールを設定することもできます。たとえば、「Laptops」カテゴリの割引ルールで指定した条件から「New Releases」カテゴリを参照します。実行時に、「New Releases」カテゴリの割引をABC Laptopに適用します。

次のような利点があります。

• カテゴリ割引をより効率的に追跡します。
• 財務および価格設定分析を改善します。
• より複雑な価格設定要件を満たします。
• カテゴリ価格設定を伴う意思決定を改善します。

有効化のステップ

1. カテゴリの階層を設定し、そのカテゴリに品目を割り当てます。
2. 「製品ハブ・スナップショットのリフレッシュ」スケジュール済プロセスを実行します。
3. 「製品カタログ」価格設定パラメータを使用して、ルールで使用するカタログを割り当てます。
4. 「マトリックス区分の管理」ページを使用して、価格設定マトリックスを設定します。
5. 割引リストにルールを作成します。

ヒントと考慮事項

次の手順を実行する必要があります。

• 「マトリックス区分の管理」ページで条件を作成する場合は、新しい「Item Category」ドメイン・タイプを使用します。

• ルールの「比較」属性を「In Hierarchy」または「Not In Hierarchy」に設定します。

• ルールの設定時に「価格設定管理」作業領域に関連するカテゴリが表示されるように、カタログを条件名に割り当てます。

その他の詳細:

• 価格設定管理作業領域、ファイルベース・データ・インポートまたはREST APIを使用して、マトリックス調整ルールを管理できます。

• 複数のマトリックス・ルールが割引の適用に適格である場合、価格設定では、品目の価格設定時に階層内で最も深いカテゴリを持つルールが使用されます。

アクセス要件

次の権限を含む構成済ジョブ・ロールが割り当てられているユーザーは、この機能にアクセスできます。

•  
• 割引リストの管理(QP_MANAGE_DISCOUNT_LISTS)
• 進行中の割引リストの管理(QP_MANAGE_IN_PROGRESS_DISCOUNT_LISTS)
• 割引リストの表示(QP_VIEW_DISCOUNT_LISTS)
• 割引リストの承認(QP_APPROVE_DISCOUNT_LISTS)
• 割引リストのインポート(QP_DISCOUNT_LIST_IMPORT)
• 承認済割引リストのインポート(QP_DISCOUNT_LIST_APPROVED_IMPORT)
• マトリックス区分の管理(QP_MANAGE_MATRIX_CLASS)

これらの権限はこの更新の前から使用可能でした。

品目のカテゴリに応じた価格の調整

価格調整マトリックスを使用して、カタログ内の1つ以上のカテゴリに従って価格表の価格を調整します。販売カタログがあり、「コンピュータ」カテゴリが含まれ、「コンピュータ」カテゴリに「デスクトップ」、「ラップトップ」および「プリンタ」という3つの子カテゴリが含まれているとします。各子には品目が含まれます。たとえば、デスクトップにはAS54888コンピュータが含まれます。子デスクトップ・カテゴリの品目についてのみ価格を調整するルールを作成できます。すべてのデスクトップ、ラップトップ、プリンタなど、親の「Computers」カテゴリのすべての品目の価格を調整するルールを作成することもできます。

• 財務および価格設定分析を改善します。
• より複雑な価格設定要件を満たします。
• カテゴリ価格設定を伴う意思決定を改善します。

有効化のステップ

1. カテゴリの階層を設定し、そのカテゴリに品目を割り当てます。
2. 「製品ハブ・スナップショットのリフレッシュ」スケジュール済プロセスを実行します。
3. 「製品カタログ」価格設定パラメータを使用して、ルールで使用するカタログを割り当てます。
4. 「マトリックス区分の管理」ページを使用して、価格設定マトリックスを設定します。
5. 価格表にルールを作成します。

ヒントと考慮事項

この機能は、品目のカテゴリに応じた割引の適用機能とほぼ同じです。たとえば、価格表の価格を属性、カテゴリの階層に従って調整したり、カテゴリを除外したり、割引リストと同様にカテゴリを参照できます。主な違いは、割引リストではなく価格表に設定することです。

次の手順を実行する必要があります。

• 「マトリックス区分の管理」ページで条件を作成する場合は、新しい「Item Category」ドメイン・タイプを使用します。

• ルールの「比較」属性を「In Hierarchy」または「Not In Hierarchy」に設定します。

• ルールの設定時に「価格設定管理」作業領域に関連するカテゴリが表示されるように、カタログを条件名に割り当てます。

その他の詳細:

• 価格設定管理作業領域、ファイルベース・データ・インポートまたはREST APIを使用して、マトリックス調整ルールを管理できます。

• 複数のマトリックス・ルールが割引の適用に適格である場合、価格設定では、品目の価格設定時に階層内で最も深いカテゴリを持つルールが使用されます。

アクセス要件

次の権限を含む構成済ジョブ・ロールが割り当てられているユーザーは、この機能にアクセスできます。

•  
• 価格表の管理(QP_MANAGE_PRICE_LISTS)
• 進行中の価格表の管理(QP_MANAGE_IN_PROGRESS_PRICE_LISTS)
• 価格表の表示 (QP_VIEW_PRICE_LISTS)
• 価格表の承認(QP_APPROVE_PRICE_LISTS)
• 承認済価格表のインポート(QP_PRICE_LIST_APPROVED_IMPORT)
• 価格表のインポート(QP_PRICE_LIST_IMPORT)
• マトリックス区分の管理(QP_MANAGE_MATRIX_CLASS)
• 価格設定パラメータ値の管理(QP_MANAGE_PRICING_PARAMETER_VALUES)
• 価格設定パラメータ値の表示(QP_VIEW_PRICING_PARAMETER_VALUES)

これらの権限はこの更新の前から使用可能でした。

チャネル収益管理

Redwoodエクスペリエンス

これらの機能は、Oracleの次世代ユーザー・エクスペリエンスであるRedwoodで構築されました。Redwoodは、デバイス全体で最先端のコンシューマ・グレードのユーザー・エクスペリエンスを、Oracleが実現する高度なエンタープライズ・シナリオにもたらします。

チャネル収益管理ユーザーの就業者としての定義

チャネル収益管理ユーザーの就業者としての定義を実行し、上長ベースの承認をサポートします。ユーザーは、名前およびEメール・アドレスに基づいて所有者を表示および検索し、サプライヤおよび顧客プログラム、サプライヤおよび顧客要求およびサプライヤ調整に割り当てることができます。

このリリースでは、所有者をHCM就業者として義務付けています。

要求所有者値リスト

プログラム所有者値リスト

所有者名またはEメールで検索

この機能では:

• 上長ベースのBPM承認をサポートします。

有効化のステップ

この機能を有効にするには、オプト・インUIを使用します。手順は、この文書の「新機能のオプションの取込み」の項を参照してください。

オファリング: オーダー管理

1. 「チャネル所有者データの検証」プロセスを実行して、HCM就業者ではない所有者についてレポートします。HCM就業者ではないすべての所有者を識別するには、「所有者ユーザー名」パラメータを空白のままにします。

2. すべての所有者がHCM就業者であることを確認します。

3. HCMのライセンスがない場合は、「ナビゲータ」>「自分のチーム」>「ユーザーとロール」>「作成」を使用して、最小限のHCM就業者を作成します。

ヒントと考慮事項

このリリースより前のリリースでは、所有者がHCM就業者として設定されていない場合は、要求、プログラムまたは調整にナビゲートすると、警告メッセージが表示されます。

主なリソース

• 詳細は、SCMのスケジュール済プロセス・ガイド>「オーダー管理のスケジュール済プロセス」>「チャネル収益管理」>「チャネル所有者データの検証」を参照してください。

• 詳細は、SCMの保護ガイド>アプリケーション・ユーザー管理>ユーザーの作成を参照してください。

• 最小限のHCM就業者の作成の詳細は、HCMの保護ガイド>「ユーザーの作成タスクを使用したOracle HCM Cloudユーザーの作成」を参照してください。

アクセス要件

1. 次の権限を含む構成済ジョブ・ロールが割り当てられているユーザーは、スケジュール済プロセスを実行できます。

• チャネル所有者データの検証(CJM_VALIDATE_CHANNEL_OWNER_DATA_PRIV)

この権限は、この更新の前から使用可能でした。

2. 構成済ジョブ・ロールが割り当てられているユーザーは、HCM就業者を作成できます。

• 「人事担当者」ジョブ・ロール

このロールは、この更新の前に使用できました。

顧客チャネル管理

顧客取引プログラムを作成および管理します。これにより、サプライ・チェーン全体でのプログラムおよびプロモーションの実行および影響が最適化されます。

顧客協力プログラムの管理

協力広告は、製造業者または販売業者とそのチャネル・パートナとの間の協定です。協力プログラムでは、プログラムの有効日全体の売上に基づいてリベートを獲得します。このプログラム・タイプは、年間プログラムのバリエーションです。これらのプログラムはすべての顧客に適用され、リベートは各製品ルールについて定義されます。品目別、カテゴリ別、またはすべての品目について製品の適格性を定義できます。製品適格性では、品目またはカテゴリ別の除外がサポートされます。対象となる売上は、CSVファイルを使用してインポートされる販売オーダーから取得されます。

協力プログラムの作成

協力プログラム

製品除外

プログラム・チェックブック

顧客支払への処理中および支払済ドリルダウン

顧客チェックブック

この機能では:

• 製造業者または販売業者の製品とサービスの差別化とチャネル認識を向上
• 協力マーケティング資金の追跡と支払いを合理化および自動化
• 協力プログラムの負債に対する財務の可視性を向上

有効化のステップ

この機能を有効にするには、オプト・インUIを使用します。手順は、この文書の「新機能のオプションの取込み」の項を参照してください。

オファリング: オーダー管理

顧客チャネル・プログラムを実装していない場合は、実装ガイドの「チャネル収益管理の実装」の「顧客プロモーションの設定のロードマップ」の章を参照してください。

顧客チャネル・プログラムを実装した後:

1. Fusion Product Information Managementでのカタログの設定

2. 協力販売トランザクションを集計するための期間の識別に使用するカレンダの構成

• カテゴリ= 顧客チャネルでチャネル設定「カレンダ」を設定します

3. 製品ルールで活用されるカテゴリの識別に使用するカタログの構成

• 「カテゴリ」でチャネル設定「カタログ」を「顧客チャネル」に設定します。
• カタログ内のすべての日付有効性は無視され、リーフ・ノード・カテゴリのみを製品ルールに割り当てることができます。

4. 顧客協力プログラム・テンプレートに基づいて、1つ以上のプログラム・タイプを構成します。

5. 構成済プログラム・タイプに基づいてプログラムを定義します。

6. 「協力プログラムの経過勘定の作成」プロセスをスケジュールします(通常は月次)。

カレンダおよびカタログ・チャネルの設定

協力プログラム・タイプの「機能」タブ

協力プログラム・タイプの「クオリファイア」タブ

協力プログラム・タイプの「経過勘定計算」タブ

協力プログラム・タイプのオプションのデフォルト設定タブ

ヒントと考慮事項

プログラム・チェックブックの進行中金額および支払済金額から顧客支払へのドリルダウンは、(顧客ボリューム・プログラムのみでなく)すべての販売側プログラムで使用できます。

主なリソース

• 顧客協力プログラムの管理デモをご覧ください。
• 顧客チャネル管理の概要をご覧ください。
• Channel Revenue Managementの詳細は、オーダー管理に関するOracle Cloud Readinessのコンテンツを参照してください。
• Oracle SCM Cloud: Oracle Channel Revenue Management Cloudの使用(Oracle Help Centerからアクセスできます)
• Oracle SCM Cloud: Oracle Channel Revenue Management Cloudの実装(Oracle Help Centerからアクセスできます)
• Oracle SCM Cloud: Oracle SCM CloudのREST API (Oracle Help Centerからアクセスできます)

アクセス要件

1. 次の権限を含む構成済ジョブ・ロールが割り当てられているユーザーは、承認のためにプログラムを送信できます。

• 顧客プログラムの管理(CJM_MANAGE_CUSTOMER_PROGRAMS_PRIV)

この権限は、この更新の前から使用可能でした。

2. 次の権限を含む構成済ジョブ・ロールが割り当てられているユーザーは、プログラムを表示できます。

• 顧客プログラムの表示(CJM_VIEW_CUSTOMER_PROGRAMS_PRIV)

この権限は、この更新の前から使用可能でした。

3. ワークフロー・ベースの承認を有効にするには、「BPMワークフローによる顧客プログラムの承認」機能を有効にする必要があります。

ChannelCustomerProgramsApprovalTaskタスクのタスク構成を管理するには、BPMワークフロー・システム管理ロール(BPMWorkflowAdmin)を含むカスタム・ロールが必要です。

この権限を含む構成済ジョブ・ロールが割り当てられているプログラム承認者は、承認通知を表示できます。

• 顧客プログラムの承認(CJM_APPROVE_CUSTOMER_PROGRAMS_PRIV)

この権限は、この更新の前から使用可能でした。

顧客ボリューム・プログラムの管理

顧客ボリューム・リベート・プログラムを管理して、オーダー間の累積売上高に基づいてリベートを獲得します。売上額の達成階層に基づいてパーセント・リベートを定義し、売上数量の達成階層に基づいてユニット当たりの金額リベートを定義できます。遡及的および段階的計算がサポートされており、品目別、またはすべての品目について除外ありで製品の適格性を定義できます。対象となる売上は、CSVファイルを使用してインポートされる販売オーダーから取得されます。

ボリューム・プログラムの作成

ボリューム・プログラム

階層ボリューム・ルール

顧客ボリューム・プログラムと顧客年間ボリューム・プログラムの両方について、Excelから製品ルールをインポートおよびエクスポートできます。

顧客年間ボリューム・プログラムのExcelからの製品ルールのアップロードに成功

除外

プログラム・チェックブック

プログラム・チェックブックから顧客支払への進行中および支払済ドリルダウン

特定のプログラムの顧客支払は、すべての販売側プログラムで使用できます。

プログラムの顧客支払

顧客チェックブック

この機能では:

• チャネル顧客に、事前定義済の購買ボリューム・レベルに到達するよう奨励します。
• ボリューム・リベートの追跡と支払を合理化および自動化します。
• ボリューム・プログラム負債に対する財務の可視性を向上させます。

有効化のステップ

この機能を有効にするには、オプト・インUIを使用します。手順は、この文書の「新機能のオプションの取込み」の項を参照してください。

オファリング: オーダー管理

顧客チャネル・プログラムを実装していない場合は、実装ガイドの「チャネル収益管理の実装」の「顧客プロモーションの設定のロードマップ」の章を参照してください。

顧客チャネル・プログラムを実装した後:

1. 顧客ボリューム・プログラム・テンプレートに基づいて、1つ以上のプログラム・タイプを構成します。

2. 構成されたプログラム・タイプに基づいてプログラムを定義およびアクティブ化します。

3. 「チャネル・バッチの経過勘定の作成」プロセスをスケジュールします(通常は夜間)。これにより、サプライヤ・リベート、顧客プログラムおよび顧客ボリューム・プログラムが処理されます。

ボリューム・プログラム・タイプの「機能」タブ

ボリューム・プログラム・タイプの「クオリファイア」タブ

ボリューム・プログラム・タイプの「経過勘定計算」タブ

ボリューム・プログラム・タイプのオプションのデフォルト設定タブ

ヒントと考慮事項

顧客ボリューム・プログラムは、月次販売トランザクションを集計するのではなく、各販売トランザクションが個別に計算される点を除き、顧客の年間ボリューム・プログラムに似ています。

プログラム・チェックブックの進行中金額および支払済金額から顧客支払へのドリルダウンは、(顧客ボリューム・プログラムのみでなく)すべての販売側プログラムで使用できます。

Excelへの製品ルールのインポート/エクスポートは、顧客ボリューム・プログラムと顧客年間ボリューム・プログラムの両方で使用できます。これは、Windowsオペレーティング・システムでのみサポートされています。Oracle Visual Builder Excelアドインを利用しています。これは、使用前に1回インストールします。

1. 「製品」リージョンの「Excelで管理」をクリックして、プログラムを暗黙的に保存し、スプレッドシートをダウンロードします。

2. アドインのインストール方法およびスプレッドシートの使用方法の「指示」タブに従います。

3. 「Oracle Visual Builder」メニュー>「データのダウンロード」処理を使用して、ボリューム・ルールをスプレッドシートにダウンロードします。「ボリューム・ルール」タブは読取専用ですが、製品ルールのボリューム・ルールを識別するときにコピー元のボリューム・ルールの名前を指定します。

4. 「製品ルール」タブで、製品ルールを入力し、「Oracle Visual Builder」メニュー>「変更内容のアップロード」処理を介してアップロードします。アップロードのステータスがExcelで提供され、対応する検証エラーも表示されます。

5. 「Excel後にプログラムを更新」をクリックして、プログラムUIにアップロードされた製品を表示します。

起動されるRESTサービスが同期されるように、新しいリリースごとに新しいスプレッドシートを毎回ダウンロードすることをお薦めします。スプレッドシートを毎回ダウンロードしない場合は、Excelで製品ルールを作成する前に、ボリューム・ルールを保存する必要があります。各スプレッドシート・セッションでは、ログインによる認証が必要です。

Excelアップロード後のリフレッシュ済製品ルール

読取専用ボリューム・ルール・タブはダウンロード後に移入

変更内容をアップロードする前に製品ルールを入力したスプレッドシート

変更内容のアップロード後に製品ルールが正常に作成

主なリソース

• 顧客ボリューム・プログラムの管理デモをご覧ください。
• 顧客チャネル管理の概要をご覧ください。
• Channel Revenue Managementの詳細は、オーダー管理に関するOracle Cloud Readinessのコンテンツを参照してください。
• Oracle SCM Cloud: Oracle Channel Revenue Management Cloudの使用(Oracle Help Centerからアクセスできます)
• Oracle SCM Cloud: Oracle Channel Revenue Management Cloudの実装(Oracle Help Centerからアクセスできます)
• Oracle SCM Cloud: Oracle SCM CloudのREST API (Oracle Help Centerからアクセスできます)

アクセス要件

1. 次の権限を含む構成済ジョブ・ロールが割り当てられているユーザーは、承認のためにプログラムを送信できます。

• 顧客プログラムの管理(CJM_MANAGE_CUSTOMER_PROGRAMS_PRIV)

この権限は、この更新の前から使用可能でした。

2. 次の権限を含む構成済ジョブ・ロールが割り当てられているユーザーは、プログラムを表示できます。

• 顧客プログラムの表示(CJM_VIEW_CUSTOMER_PROGRAMS_PRIV)

この権限は、この更新の前から使用可能でした。

3. この権限を含む構成済ジョブ・ロールが割り当てられているプログラム承認者は、承認通知を表示できます。

• 顧客プログラムの承認(CJM_APPROVE_CUSTOMER_PROGRAMS_PRIV)

ChannelCustomerProgramsApprovalTaskタスクのタスク構成を管理するには、BPMワークフロー・システム管理ロール(BPMWorkflowAdmin)を含むカスタム・ロールが必要です。

この権限は、この更新の前から使用可能でした。

控除および決済

調査、管理、分析および決済の各機能を提供して、控除と決済の要求をすばやく解決し、顧客関係および全体的な財務パフォーマンスを向上させます。

顧客要求決済方法の拡張

要求決済オプションを拡張し、手動要求に対してビジネス・プロセスに固有の決済方法を作成します。たとえば、外部アプリケーションを介して作成された要求の場合、この機能を使用して、外部アプリケーションの売掛/未収金または買掛/未払金でこれらの要求を決済します。

カスタム決済方法は、プロモーションまたはプロモーション以外の手動請求に使用できます。プロモーション請求の場合、カスタム決済方法ではチャネル収益会計も処理されます。

カスタム決済方法としてのEBS AP小切手

カスタム決済方法別請求決済の確認

アプリケーションで要求番号を生成しない場合は、手動要求に対して要求番号を指定できます。ソース・システムを取得するために手動要求UIに2つのソース・フィールドが追加され、ソース・システムから要求番号が追加されました。

2つのソース・フィールドおよび編集可能な要求番号を持つ手動要求

この機能により、請求の決済をサード・パーティの財務システムまたは控除管理システムに統合するための時間と労力を削減できます。

現在の顧客要求機能では、要求を決済する様々な方法について、すぐに使用できるFusion Financials Cloudとの統合が提供されます。ただし、追加の決済要件がある場合があります。

カスタム決済方法を使用できる一般的なシナリオを次に示します。

• レガシーまたはサードパーティの財務システムで決済を処理します。

• 超過支払のAR文書で決済します(負のチャージバックと同様に、ARトランザクションを使用して超過支払の顧客に返金します)。

• 電信送金またはEFTで支払います。これは、ヨーロッパの顧客との一般的な決済方法です。

• 無料の商品を顧客に請求に対して発行する場合は、無料の商品で精算します。カスタム決済は、要求に対するオーダー管理システムでの販売オーダー決済をサポートできます。

有効化のステップ

この機能を有効にするには、オプト・インUIを使用します。手順は、この文書の「新機能のオプションの取込み」の項を参照してください。

オファリング: オーダー管理

Redwoodで顧客チャネル要求を実装していない場合は、実装ガイド、チャネル収益管理の実装の顧客要求の設定のロードマップの章を参照してください。

1. 新しいカスタム決済方法をORA_CJM_SETTLEMENT_METHOD参照に追加します。

• 「設定および保守」作業領域で、「チャネル収益管理」機能領域の「チャネル参照の管理」に移動します。
• 参照タイプORA_CJM_SETTLEMENT_METHODを検索します。
• 新しい決済方法を表す新しい参照コードを追加します。

2. 適用可能な要求ソースに基づいてカスタム決済方法を構成します。

• 「設定および保守」作業領域で、「チャネル収益管理」機能領域の「要求ソースの管理」タスクに移動します。
• 適用可能な要求ソースを選択し、カスタム決済方法を追加します。

3. 補助元帳会計基準を構成します。

ORA_CJM_SETTLEMENT_METHOD参照へのカスタム決済方法の追加

手動要求に対するカスタム決済方法の構成

ヒントと考慮事項

サードパーティ売掛管理システムの実装決定ツリー:

ノート: 要求ごとに1つの手段のみがサポートされます。手段は、サードパーティ売掛/未収金システムのARトランザクションです。これは、channelCustomerClaims RESTのinstruments子リソースにマップされます。

1. 支払が売掛管理に適用できないため、channelCustomerClaims RESTのpayments子リソースは適用できません。

2. 統合では、サードパーティ手段顧客を要求顧客から導出する必要があります。

3. 次のinstrumentsの詳細がチャネルに返されます。

• InstrumentTypeまたはInstrumentTypeCode (必須)
• InstrumentNumber (必須)
• InstrumentDate (必須)
• InstrumentAmount (必須)
• InstrumentTax (オプション)
• InstrumentStatus (必須)

4. 手段は、手動要求で請求先に発行されます。

サードパーティ買掛管理システムの実装決定ツリー:

ノート: 要求ごとに1つの手段に対して複数の支払がサポートされています。手段は、サードパーティ買掛/未払金システムのAPトランザクションです。支払は小切手または電信振込です。これは、channelCustomerClaims RESTのinstrumentsおよびpayments子リソースにマップされます。

1. Fusionでサプライヤをすでに管理しているかどうか

2. そうでない場合、統合は請求顧客から手段サプライヤを導出する必要があります。

3. はいの場合、調査中にサプライヤ・サイトを指定できます。統合によって、提供されたサプライヤ・サイトからサードパーティの手段受取人を導出できます。

4. 次のinstrumentsの詳細がチャネルに返されます。

• InstrumentTypeまたはInstrumentTypeCode (必須)

• InstrumentNumber (必須)

• InstrumentDate (必須)

• InstrumentAmount (必須)

• InstrumentStatus (必須)

• 要求アナリストが調査中にサプライヤ・サイトを渡す場合、ThirdPartyInstrumentPayeeNameはオプションです。

• 統合によって請求顧客から手段サプライヤが導出される場合、ThirdPartyInstrumentPayeeNameは必須の自由形式テキスト・フィールドです。

• 統合によって請求顧客から手段サプライヤが導出されますが、Fusionサプライヤ・サイトへのマッピングが保守される場合、統合によって手段のサプライヤ詳細が渡されます。

5. 次のpaymentsの詳細がチャネルに返されます。

• PaymentMethodまたはPaymentMethodCode (必須)
• PaymentNumber (必須)
• PaymentDate (必須)
• PaymentAmount (必須)
• PaymentStatus (必須)
• PayeeSupplier
• PayeeSupplierSite
• PayeeSupplierSiteId
• PayeeParty
• PayeePartyId
• PayeePartySite
• PayeePartySiteId
• ThirdPartyPayeeName

サードパーティ・システムで決済するための統合を構築します。

1. channelCustomerClaims RESTのPOSTアクションを使用して、サードパーティ・システムからの手動要求を取り込みます。

2. 要求アナリストは、カスタム決済方法を使用して、Redwood UIでサードパーティの手動要求を決済します。

3. サードパーティ・システムが処理するために、定期的に、最小限の夜間に、カスタム決済方法を使用して「決済保留」ステータスの手動請求を取得します。channelCustomerClaims RESTに対してGETアクションを使用して、処理する要求詳細を収集します。

4. これらの請求は、サードパーティ・システムで処理します。

5. サードパーティ・システムで正常に決済されると、統合によってchannelCustomerClaims RESTに対してPATCH処理がコールされ、決済手段および支払詳細がチャネルに戻されます。

6. channelCustomerClaims RESTに対してsettleCustom処理を使用して、残りの金額を子要求に分割し、要求を「決済済」ステータスに移動します。

7. サードパーティ・システムが要求の決済を処理できない場合、統合では、channelCustomerClaims RESTに対してreopenCustom処理をコールして要求を再オープンし、要求会計イベントを逆仕訳する必要があります。

主なリソース

• Redwoodページを使用した控除要求の管理をご覧ください。

• 顧客チャネル管理の概要をご覧ください。

• Channel Revenue Managementの詳細は、オーダー管理に関するOracle Cloud Readinessのコンテンツを参照してください。

• 売掛/未収金とのチャネル収益管理統合の詳細は、財務に関するOracle Cloud Readinessのコンテンツを参照してください

• Oracle SCM Cloud: Oracle Channel Revenue Management Cloudの使用(Oracle Help Centerからアクセスできます)

• Oracle SCM Cloud: Oracle Channel Revenue Management Cloudの実装(Oracle Help Centerからアクセスできます)

• Oracle SCM Cloud: Oracle SCM CloudのREST API (Oracle Help Centerからアクセスできます)

アクセス要件

1. 次の権限を含む構成済ジョブ・ロールが割り当てられているユーザーは、承認のために要求を発行できます。

• 顧客要求の管理(CJM_MANAGE_CUSTOMER_CLAIMS_PRIV)

この権限は、この更新の前から使用可能でした。

2. 次の権限を含む構成済ジョブ・ロールが割り当てられているユーザーは、要求を表示できます。

• 顧客請求の表示(CJM_VIEW_CUSTOMER_CLAIMS_PRIV)

この権限は、この更新の前から使用可能でした。

3. この権限を含む構成済ジョブ・ロールが割り当てられている要求承認者は、承認通知を表示できます。

• CustomerClaimsの承認(CJM_APPROVE_CUSTOMER_CLAIMS_PRIV)

ChannelCustomerClaimsApprovalTaskタスクのタスク構成を管理するには、BPMワークフロー・システム管理ロール(BPMWorkflowAdmin)を含むカスタム・ロールが必要です。

この権限は、この更新の前から使用可能でした。

グローバル・オーダー納期回答

製造コンポーネント、資材およびリソースの消費のタイプおよびレートのインポート

以前は、Oracle Manufacturingの作業定義から値を収集することで、製造工程ごとに固定設定および変動サイクル時間を構成できました。組織でOracle Manufacturingを使用していない場合は、ファイルベース・データ・インポート(FBDI)プロセスを介して消費のタイプとレートも更新できるようになりました。

サプライ・チェーン・プランニングのリソース構成表FBDIテンプレートを使用して、固定および可変の使用数量を持つコンポーネントとリソースを含む組立品目のリソース構成表をロードします。テンプレートの「基準タイプ」列は、コンポーネント品目またはリソース使用数量が可変か固定かを示します。同じコンポーネントまたはリソースの複数のインスタンスを、リソース構成表の異なる基準タイプ情報でモデル化できます。

サプライ・チェーン・プランニングのリソース構成表FBDIテンプレートScpBillOfResourcesImportTemplate.xlsm

ファイルからデータをロードした後、「プラン入力」作業領域の「リソース構成表の集計」表でリソース構成表をレビューできます。

「プラン入力」作業領域の「リソース構成表」集計

グローバル・オーダー納期回答では、リソース構成表に定義されている基準タイプ情報を考慮して、コンポーネントとリソースの使用量が消費されます。

有効化のステップ

この機能を有効にするために何もする必要はありません。

ヒントと考慮事項

• 「リソース構成表の作成」スケジュール済プロセスを使用して、レガシー・システムからロードされた工順および品目構成データからリソース構成表を生成できます。グローバル・オーダー納期回答では、リソース構成表を使用して、需要を満たすために必要なコンポーネントとリソースの数量を決定します。リソース構成表の作成を参照してください。

• Oracle Manufacturingを使用しない実装用のリソース構成表データをロードできます。

• サプライ・チェーン・プランニングのリソース構成表FBDIテンプレート(ScpBillOfResourcesImportTemplate.xlsm)は、組立品目のコンポーネントとリソースの有効日を引き続きサポートします。

• 有効日が重複するコンポーネントまたはリソースは定義できません。

• 部分組立品または組立品目の作成に使用されるコンポーネントおよびリソースの1つ以上のインスタンスに対して、固定または可変の基準タイプを定義できます。

主なリソース

• Oracle Cloud Application Update Readinessで、グローバル・オーダー納期回答の更新24A以降使用可能なリソース構成表の製造コンポーネント、資材およびリソースの消費のタイプおよびレートの変動機能に関するレディネス・トレーニングをご覧ください。

アクセス要件

次の権限を含む構成済ジョブ・ロールが割り当てられているユーザーは、この機能にアクセスできます。

• オーダー・オーケストレーションおよびプランニング・データのロードの実行(MSP_PERFORM_ORDER_ORCHESTRATION_AND_PLANNING_DATA_LOAD_PRIV)
• 「オーダー納期回答」作業領域のモニター(MSC_MONITOR_ORDER_PROMISING_WORK_AREA_PRIV)
• リソース構成表の表示(MSC_VIEW_BILLS_OF_RESOURCES_PRIV)
• 履行明細のスケジュール(MSP_SCHEDULE_ORCHESTRATION_ORDER_FULFILLMENT_LINE_PRIV)

これらの権限はこの更新の前から使用可能でした。

コンポーネントが使用可能になった後にのみリソース生産能力を消費

Oracle Global Order Promisingでは、品目を並行して製造するために複数の資材およびコンポーネントをスケジュールできます。ただし、一部の製造リソースが業務を行う前に、すべての資材およびコンポーネントを手元に置く必要がある場合があります。この更新から計画外アイドル時間を防止するために、すべてのコンポーネントおよび資材が使用可能になるまでリソース消費日を遅延するように選択できるようになりました。

この機能は、コンポーネント可用性とリソースの可用性を同時に考慮するのではなく、最初にコンポーネントの可用性、次にリソースの可用性を考慮する納期回答結果が必要な場合に使用します。更新24Bの前に、Oracle Global Order Promisingはリソース生産能力を消費し、各コンポーネントの供給を同時に累計したため、納期が早すぎた日付があります。

更新24B以降では、製造を開始するために必要なすべてのコンポーネントがファクトリにある場合にのみ、リソースの消費を開始するように納期回答を設定できます。コンポーネントの可用性により、製造開始日が決定され、より現実的な納期になります。

リード・タイム

リソース構成表にリード・タイムが最も長いコンポーネントは、製造の開始日を決定するのに役立ちます。この機能で納期回答がどのようにリード・タイムを使用するかを次に示します。

• 後処理リード・タイムを使用して、リード・タイム・オフセットを計算します。

• 各リソースの開始日がコンポーネントの開始日以降であることを確認します。

• 各リソースのリード・タイムが、販売オーダーの期日を満たす製造終了日になるようにします。

• リソース構成表の作成では、リード・タイム・オフセットを計算する際に、クリティカル・リソースの親組立品の処理リード・タイムは含まれません。これにより、各リソースの終了日が製造の終了日と一致していることを確認できます。

背景の詳細は、次を参照してください。

• 後処理リード・タイムの設定
• 製品情報管理での品目の設定
• 納期回答でのリソース構成表の使用の概要

例

リソース構成表には次の階層があるとします。

次のように仮定します。

• 「リソース構成表の作成」スケジュール済プロセスでは、この階層が使用されます。納期回答では、リソースおよびコンポーネントのみが考慮されます。操作は考慮されません。

• 今日の日付は4月1日です。

• C1のリード・タイムは10日で、C2のリード・タイムも10日です。

• R1では、1単位の作成に2時間かかります。

• R2では、1単位の作成に3時間かかります。

コンポーネントのリード・タイムの指定、リソースのリード・タイムの指定および可用性の制約なし

次のように仮定します。

• 4月15日は、販売オーダーSO1の要求日です。
• 後処理リード・タイムは0です。
• リソース・リード・タイムは、リソース構成表の0です。

納期回答では、リソース構成表のデータとSO1の数量を使用して、製造業者がすてきな花束を作成するために必要なコンポーネントの数量とリソースの数量を計算します。数量10個の花束が必要だとします。

納期回答では、リソース構成表を使用して、リード・タイムに従って販売オーダーSO1に対して製造業者が10個の花束を作成する必要がある数量を決定します。

次の使用可能性を考慮します。

各値は次のとおりです。

• 緑はコンポーネント消費です。

• 青はリソース消費です。

• 使用可能な数量は累積で、逆にカウントされます。たとえば、C2の場合は4月3日に数量20を使用できます(4月3日は5、4月2日は5、4月1日は10)。

納期回答でこれらの消費日を決定する方法を次に示します。

1. 要求日を4月15日に設定します。

2. 製造の終了日を4月15日に設定します。これは、期日から花束の後処理リード・タイムを差し引いたものです。

3. 製造の開始日を決定します。納期回答は4月15日に開始され、それが使用できる最も早い製造開始日が検索され、引き続きコンポーネントおよびリソースのリード・タイム要件を満たします。

• リード・タイムが最大のコンポーネントまたはリソースを識別します。C2のリード・タイムが最大であり、12日間です。

• 製造の開始日を4月3日に設定します(4月15日からC2の12日間のリード・タイムを引いた値)。

• 4月3日にコンポーネントが使用可能であることを確認します。製造では、C1に数量10、C2に数量20が必要です。この例では、4月3日にC1に対して累積数量11が使用可能で、C2に対して数量20が使用可能なため、実行することをお薦めします。

• 4月3日から4月15日までのリソースが使用可能であることを確認します。製造では、R1に50時間、R2に20時間が必要です。リソース・リード・タイムはゼロで、リソースを消費する終了日は4月15日です。R1は4月15日に130時間使用可能で、R2は39時間使用可能であるため、4月15日に需要を満たすのに十分な累積リソース時間があります。

• 各コンポーネントおよびリソースに必要な数量が製造に含まれていないことが納期回答で判明した場合は、翌日が製造の終了日として使用され、再試行します。

4. 結果をファイナライズします。

コンポーネントおよびリソースのリード・タイムの指定および可用性の制約なし

次のように仮定します。

• 4月15日は、販売オーダーSO2の要求日です。
• 後処理リード・タイムは0です。

納期回答では、リソース構成表のデータとSO2の数量を使用して、製造で花束を作成するために必要なコンポーネントの数量とリソースの数量を計算します。数量10個の花束が必要だとします。

納期回答で製造が計算される数量は、リード・タイムに従って販売オーダーSO2に対して10個の花束を作成するために必要です。

次の使用可能性を考慮します。

納期回答でこれらの消費日を決定する方法を次に示します。

1. 要求日を4月15日に設定します。

2. 製造の終了日を4月15日に設定します。これは、期日から花束の後処理リード・タイムを差し引いたものです。

3. 製造の開始日を決定します。納期回答は4月15日に開始され、コンポーネントおよびリソースのリード・タイム要件を満たすために使用できる最も早い製造開始日を見つけるために後方に動作します。

• リード・タイムが最大のコンポーネントまたはリソースを識別します。R1のリード・タイムが最大であり、13日間です。

• 製造の開始日を4月2日に設定します(4月15日からR1の13日間のリード・タイムを引いた値)。

• 4月2日にコンポーネントおよびリソースが使用可能になるようにします。製造では、C1に数量10が必要です。ただし、C1の累積数量は4月2日に9のみであるため、納期回答は次の日に移動して再試行します。

• 次の反復では、納期回答は製造の終了日を4月18日に、R1の終了日を4月5日に設定します(4月18日からR1の13日間のリード・タイムを引いた値)。R1には、必要な50時間の需要を満たす十分な容量があり、R1の開始日は4月1日として計算されます。ただし、C1の数量は0で、C2の数量は4月1日に10のみであるため、納期回答では結果が破棄され、翌日に移動します。

• 納期回答は、コンポーネントおよびリソースに対する製造の需要を満たす日付が見つかるまで、このプロセスを繰り返します。繰り返すごとに、リード・タイムを適用し、各コンポーネントおよびリソースの可用性をチェックして、製造の終了日および開始日の需要を満たせるかどうかを確認します。

4. 何回か繰り返した後、納期回答は次のように処理します。

• 製造の終了日を4月20日に設定します。
• R1の終了日を4月7日(4月20日-R1の13日リード・タイム)に設定し、R1の開始日を4月3日に設定します。
• R2の終了日を4月11日に設定します(4月20日からR2の9日間のリード・タイムを引いた値)。
• C1とC2の両方に、本番を開始するのに十分な数量が4月3日に設定されていることを確認し、その結果を確定します。

コンポーネントおよびリソースのリード・タイムの指定および可用性の制約

次のように仮定します。

• 4月10日は、販売オーダーSO3の要求日です。
• 後処理リード・タイムは0です。

納期回答で製造が計算される数量は、リード・タイムに従って販売オーダーSO3に対して10個の花束を作成するために必要です。

次の使用可能性を考慮します。

納期回答でこれらの消費日を決定する方法を次に示します。

1. 要求日を4月10日に設定します。

2. 製造の終了日を4月10日に設定します。これは、期日から花束の後処理リード・タイムを差し引いたものです。

3. 製造の開始日を決定します。納期回答は4月10日に開始され、コンポーネントおよびリソースのリード・タイム要件を満たすために使用できる最も早い製造開始日を見つけるために後方に動作します。

• リード・タイムが最大のコンポーネントまたはリソースを識別します。R1のリード・タイムが最大であり、5日間です。

• 製造の開始日を4月5日に設定します(4月10日からR1の5日間のリード・タイムを引いた値)。

• 4月5日にコンポーネントおよびリソースが使用可能になるようにします。製造では、R1に50時間、R2に20時間が必要です。ただし、R1の累積数量は4月5日に7時間のみで、R2の累積数量は4月5日に14時間のみであるため、納期回答は次の日に移動して再試行します。

• このプロセスを繰り返します。最終的に、納期回答では製造の終了日が4月16日に設定されるため、製造の開始日は4月11日になり、R1の開始日は4月4日になります。リソースは4月4日に使用可能ですが、コンポーネントは使用できません。製造では、C1に数量10、C2に数量20が必要です。ただし、C1の累積数量は4月4日に5のみで、C2の数量は12のみであるため、納期回答はプロセスを反復し続けます。

• もう少し繰り返した後、納期回答では製造の終了日が4月20日に設定され、その結果、製造の開始日は4月15日になり、R1の開始日は4月9日になります。4月9日のC2の開始日には、需要を満たすのに十分な数量があります。製造に必要なすべてのコンポーネントおよびリソースが使用可能であり、この反復はリード・タイム要件を満たしているため、納期回答によって結果が確定されます。

有効化のステップ

「オーダー納期回答」作業領域に移動し、「タスク」>「オーダー納期回答オプション」をクリックし、「コンポーネントが使用可能になった後にリソースを考慮」オプションにチェック・マークを追加します。

ヒントと考慮事項

• 製造では、すべてのコンポーネントの可用性を納期回答で確認した日付以降に組立品目の作成を開始できます。

• 納期回答では、代替リソースまたは代替コンポーネントと同じロジックが適用されます。納期回答では、プライマリまたは代替を使用して、販売オーダーが納期どおりまたは最小遅延で納期処理されるようにします。

• クリティカル・コンポーネントおよび階層のレベルをスキップするリソースを含むリソース構成表を使用する場合など、パフォーマンスをわずかに高速化し、納期回答結果の正確性をやや下げてもよい場合は、この機能を使用しないでください。デフォルトの動作に従って、引き続き納期を設定できます。

リソース構成表

• 納期回答では、工場がリソース構成表の最終品目を作成するために必要な各部分組立品、コンポーネントおよびリソースにマークを付けます。これにより、納期回答では、これらの各部分組立品、コンポーネントおよびリソースが考慮されます。

• ファイル・ベース・データ・インポート(FBDI)を使用してリソース構成表をインポートする場合、納期回答では、インポート・ファイルで指定したリード・タイムが使用されます。

• この機能を使用可能または使用不可にするたびに、「リソース構成表の作成」スケジュール済プロセスを再実行する必要はありません。

• リソース構成表に複数の組織が含まれていて、クリティカルでない部分組立品があり、アップストリーム組織に属する部分組立品がある場合、コンポーネントまたはリソースのリード・タイムが長くなり、納期が遅れる可能性があります。製造組織でリソースが使用可能であり、そのリソースのコンポーネントが上流組織からのもので、そのコンポーネントの移動時間が長いとします。これにより、リソース構成表のコンポーネントのリード・タイムがリソースのリード・タイムより長くなる可能性があります。納期回答では、コンポーネントのリード・タイム要件を満たすまで、納期を後の日付に移動できます。このシナリオを回避するには、部分組立品目をアップストリーム組織でクリティカルとしてマークしてから、「リソース構成表の作成」スケジュール済プロセスを再実行します。

• 「リソース構成表の作成」スケジュール済プロセスでは、後処理リード・タイムが使用されます。今後のリリースでは、固定リード・タイムと数量を足して変動リード・タイムを掛けた、異なるリード・タイムを使用する式を作成できます。

主なリソース

• 納期回答でのリソース構成表の使用の概要
• Oracle Application UpdateレディネスのSupport Capable-to-Promise for Manufactured Items 22A Global Order Promisingトレーニング

アクセス要件

次の権限を含む構成済ジョブ・ロールが割り当てられているユーザーは、この機能にアクセスできます。

• 履行明細のスケジュール(MSP_SCHEDULE_ORCHESTRATION_ORDER_FULFILLMENT_LINE_PRIV)
• リソース構成表の編集(MSC_EDIT_BILLS_OF_RESOURCES_PRIV)
• リソース構成表の表示(MSC_VIEW_BILLS_OF_RESOURCES_PRIV)

これらの権限はこの更新の前から使用可能でした。

未割当エンティティを考慮したプラン・データの保護

プラン・データを保護し、顧客、サプライヤ、組織または製品ディメンションの階層の最下位レベルで未割当メンバーを表示できるようにします。この更新では、ディメンションに現在適用できないデータを表示できます。たとえば、特定の組織をユーザーに割り当てることで、組織によってストライプ化されていないメジャー(サプライヤ生産能力など)を表示できるようになりました。

製品、組織、顧客およびサプライヤ・エンティティの未割当メンバーを含める拡張オプションを使用して、プランニング・データ・セキュリティを構成できます。これにより、ディメンションの階層レベルを使用しないメジャーにアクセスできます。たとえば、「サプライヤ生産能力使用可能」メジャーには、「製品」、「組織」、「サプライヤ」および「時間」ディメンションが含まれます。メジャーは、「製品」、「サプライヤ」および「時間」ディメンションの「品目」、「サプライヤ - サプライヤ・サイト」および「日」レベルで計算されます。メジャー値は組織に固有ではないため、組織レベルはメジャーの計算に含まれません。このようなシナリオでは、特定の組織および組織に固有でないメジャー(使用可能なサプライヤ生産能力など)にアクセスするためのデータ・アクセス・セットを設定できます。

次に、「すべての未割当プランニング・レベル・メンバーを含める」チェック・ボックスが選択されている組織エンティティを使用してデータ・セキュリティを構成することで値を表示できる供給プランニング・メジャーの例を示します。

• 使用可能サプライヤ生産能力
• 所要サプライヤ生産能力
• 使用可能正味サプライヤ生産能力
• サプライヤ生産能力稼働率
• サプライヤ生産能力制約日までに必要なサプライヤ生産能力
• サプライヤ生産能力制約日までに必要な追加生産能力

未割当エンティティを考慮したセキュア・プランは、製品ディメンション、組織ディメンション、顧客ディメンションおよびサプライヤ・ディメンションの階層の最下位レベルに適用されます。これは、供給プランニング、需要プランニング、需要および供給プランニング、セールス・アンド・オペレーションズ・プランニング、補充プランニング、グローバル・オーダー納期回答およびバックログ管理の製品ディメンション、組織ディメンション、顧客ディメンションおよびサプライヤ・ディメンションのメジャーおよびプランニング分析の詳細を表示するビューに適用できます。

データ・セキュリティの管理ビューは、次のように拡張されました。

• データ・アクセス・セット条件構成には、新しい「すべての未割当プランニング・レベル・メンバーを含める」チェック・ボックスがあります。このチェック・ボックスを選択できるのは、作成中の条件に、最下位階層レベルの製品エンティティ、組織エンティティ、顧客エンティティまたはサプライヤ・エンティティが含まれている場合のみです。

• 「すべての未割当プランニング・レベル・メンバーを含める」チェック・ボックスは、製品階層、組織階層、顧客階層およびサプライヤ階層の他の最下位レベル・メンバーとともに選択できます。

未割当メンバーでプラン・データを保護するには、次のステップを実行します。

1. データ・アクセス・セットのエンティティとして「製品」、「組織」、「顧客」または「サプライヤ」を選択します。

2. 「製品」、「組織」、「顧客」または「サプライヤ」の最下位レベルを選択します。

「プランニング・セキュリティの管理」ページでのデータ・アクセス・セットの作成

3. 「作成」処理を選択して条件名の条件を作成し、「すべての未割当プランニング・レベル・メンバーを含める」チェック・ボックスを選択します。

組織エンティティの条件の作成

4. 条件名を指定し、「すべての未割当プランニング・レベル・メンバーを含める」チェック・ボックスを選択して条件を作成します。必要に応じて、データ条件を構成するために他のレベル・メンバーを追加します。

新規の「すべての未割当プランニング・レベル・メンバーを含める」チェック・ボックス

5. 条件を保存し、選択したエンティティに割り当てます。

組織エンティティへの条件の割当て

供給プランニング作業領域で「すべての未割当プランニング・レベル・メンバーを含める」チェック・ボックスが選択されている場合に表示されるサプライヤ生産能力メジャー詳細の例をいくつか紹介します。

前述のスクリーンショットで構成されたデータ・アクセス・セットが表のメジャー値にどのように適用されるかを確認します。次のピボット表は、組織レベル・メンバーM1およびM2の計画オーダー・メジャー値、および未割当組織レベル・メンバーのサプライヤ生産能力メジャー値を示しています。この例は、組織レベルのメンバーM1およびM2を使用してデータ・セキュリティ条件が作成され、「すべての未割当プランニング・レベル・メンバーを含める」チェック・ボックスが選択されていることを示しています。

組織レベルのメンバーを使用して作成されたピボット表

「すべての未割当プランニング・レベル・メンバーを含める」チェック・ボックスが選択されているデータ・アクセス・セットと他の最下位レベルのメンバーで構成した場合の動作を見てみましょう。データ・セキュリティは「次に含まれる」条件を適用します。次のスクリーンショットでは、組織に対して「すべての未割当プランニング・レベル・メンバーを含める」、M1およびM2を選択して、データ・セキュリティ条件が作成されました。この条件は、組織値を割当て解除できるメジャー、M1またはM2にデータ・セキュリティを適用します。

ピボット表には、データ・セキュリティ条件がM1、M2および未割当の組織レベルのメンバーで構成されている場合の「計画オーダー」および「サプライヤ使用可能生産能力」メジャーの値が表示されます。

組織レベルのメンバーおよびピボット表の詳細のデータ・セキュリティ条件

データ・アクセス・セット内の複数のエンティティにわたってすべての未割当プランニング・レベル・メンバーを含めることができます。データ・アクセス・セット内で有効にすると、セキュリティはAND条件として適用されます。

組織および顧客エンティティに対して「すべての未割当プランニング・レベル・メンバーを含める」を選択すると、組織と顧客の両方の組合せがピボット表で未割当の場合に、メジャーに対してデータ・セキュリティが適用されて表示されます。

ピボット表には、組織および顧客エンティティの未割当レベル・メンバーを持つユーザー定義メジャーの値が表示されます。

組織レベルおよび顧客レベルのメンバーとピボット表の詳細のデータ・セキュリティ条件

データ・アクセス・セット全体で「すべての未割当プランニング・レベル・メンバーを含める」を有効にすると、セキュリティがOR条件として適用されます。

次の例では、データ・アクセス・セット1の「品目」の「すべての未割当プランニング・レベル・メンバーを含める」を有効にし、データ・アクセス・セット2の「組織」エンティティを有効にすると、「品目」または「組織」のいずれかがピボット表の最下位レベル・メンバーとして割当解除されている場合に、メジャーに対してデータ・セキュリティが適用されて表示されます。

ピボット表には、組織または顧客エンティティに対して未割当のレベル・メンバーを持つユーザー定義メジャーの値が表示されます。

データ・セットおよびピボット表の詳細のデータ・セキュリティ条件

有効化のステップ

この機能を有効にするために何もする必要はありません。

ヒントと考慮事項

• Oracle Global Order Promisingでは、組織エンティティのデータ・セキュリティのみが考慮されます。

• 顧客およびサプライヤのデータ・セキュリティ構成は、供給プランニング、需要プランニング、需要および供給プランニング、セールス・アンド・オペレーションズ・プランニングおよび補充プランニングの各作業領域で、ピボット表やグラフなどのプランニング分析ユーザー・インタフェースに適用されます。

• 既存のデータ条件に対して「すべての未割当プランニング・レベル・メンバーを含める」を有効にすることはできません。新しいデータ条件を作成して有効にする必要があります。

• 「条件の管理」を使用して「すべての未割当プランニング・レベル・メンバーを含める」のデータ条件を削除できるのは、条件がデータ・アクセス・セット全体でエンティティに割り当てられていない場合のみです。

アクセス要件

次の権限を含む構成済ジョブ・ロールが割り当てられているユーザーは、この機能にアクセスできます。

• プランニング・セキュリティの管理(MSC_ADMINISTER_PLANNING_SECURITY_PRIV)

この権限はこの更新の前から使用可能でした。

重要な処理および考慮事項

交換および削除された機能

オラクル社は、既存のクラウド・サービスの機能を新しい機能に置き換えたり、既存の機能を削除することがあります。置換された機能は、削除するパスに配置されることがあります。新しいバージョンが使用可能になり次第、置き換えられた機能の新しいバージョンを使用することがベスト・プラクティスとなります。

このセクションでは、このクラウド・サービスで置換された機能、または削除される予定の機能を示します。

オーダー管理拡張でサポートされているパブリック・ビュー・オブジェクトのみの使用

更新24Cの前は、オーダー管理拡張でパブリック・ビュー・オブジェクト(PVO)を使用してOracleアプリケーションからデータを取得する場合、Oracle Order Managementでは、拡張の検証時にそのPVOがサポートされるかどうかは確認されませんでした。

更新24C以降、Order Managementでは、拡張の検証時にそのPVOがポートされることが確認されます。OracleでサポートされているPVOのみを使用する必要があります。この変更に備えるには、更新24B以降の拡張でサポートされているPVOのみを使用する必要があります。

サポートされているPVOのリストは、My Oracle SupportのOracle Applications Cloudのパブリック・ビュー・オブジェクト(文書ID 2386411.1)を参照してください。詳細は、拡張機能を使用してOracle Applicationsからデータを取得するためのガイドラインを参照してください。

価格設定アルゴリズムの変更

Oracle Pricingの一部のアルゴリズムがこの更新で変更されており、変更によって処理が必要になる場合があります。

変更済アルゴリズム

新しいアルゴリズム

また、Oracle Help Centerで『Oracle Fusion Cloud SCM: 価格設定の管理』の現在のリリースへの価格設定アルゴリズムの促進のトピックを参照してください。四半期ごとの更新ごとにアルゴリズムを確認および促進することをお薦めします。

ファイルベース・データ・インポート(FBDI)テンプレートの変更点

サプライ・チェーン・プランニングFBDIテンプレートの一部がこの更新で変更されました。各変更の詳細は、次のFBDIテンプレートの指示タブを参照してください。

• ATPルール(ScpATPRulesImportTemplate)
• リソース構成表(ScpBillOfResourcesImportTemplate)
• 購買オーダー出荷受入履歴(ScpPurchaseOrderRcvHistoryImportTemplate)

最新のテンプレートは、Oracle Help CenterのOracle Fusion Cloud SCM: File-Based Data Import (FBDI) for SCMのサプライ・チェーン・プランニングの項にあります。

ShippingおよびReceivablesからOrder Managementへの統合に対する変更

更新24B以降、Oracle ShippingおよびOracle ReceivablesからOracle Order Managementへの統合でインタフェース表が考慮されるようになりました。「オーダー履行からの応答の処理」スケジュール済プロセスが事前定義され、表内のデータが自動的に処理されるようになりました。「レコード・セット」パラメータを「失敗したレコードの処理」に設定し、「タスク・タイプ」パラメータを次のいずれかの値に設定して、毎日1回実行されます。

• 請求書
• 出荷

スケジュール済プロセスの1つのインスタンスが請求書に対して実行され、別のインスタンスが出荷に対して実行されます。どちらのインスタンスも、UTC午前00:00:00に開始されます。

任意の日に、Shippingでは出荷が確認され、Receivablesでは販売オーダーが請求されます。Shippingでの出荷の確認時に「出荷インタフェースの管理」スケジュール済プロセスによってインタフェース表にデータが保存され、Receivablesでの販売オーダーの請求時に「フィーダ・システムへの売掛/未収金トランザクションの通知」スケジュール済プロセスによって表にデータが保存されます。

時間とともに、多数の失敗したレコードが表に累積される場合があります。これらのレコードにより、Shippingでの出荷の確認時にオーケストレーション・プロセスの出荷ステップを超えてオーダー明細を移動したり、Receivablesでの販売オーダーの請求時に請求書ステップを超えてオーダー明細を移動することができない可能性があります。「オーダー履行からの応答の処理」で多数のレコードを同時に処理する必要がある場合も、失敗したレコードによってパフォーマンスが低下する可能性があります。「オーダー履行からの応答の処理」スケジュール済プロセスを毎日1回実行することで、これらの問題を回避できます。毎日のボリュームや、レコードが失敗することが多い時間帯に応じて、実行頻度を変更できます。

保留コードに対する変更

更新24C以降、保留を処理する際の問題を回避するために、保留コードが更新されるため、Code属性にカンマ(,)またはアポストロフィ(')を含めることはできません。現在、24B実装のCode属性にカンマまたはアポストロフィがある場合は、その保留コードを終了し、販売オーダーに適用できないようにすることをお薦めします。Code属性にカンマやアポストロフィを含まない新しい保留を作成します。この変更は、保留コードをインポートするか「設定および保守」作業領域で定義するかに関係なく適用されます。詳細は、保留を使用したオーケストレーション・プロセスの停止を参照してください。

販売オーダーへの保留の適用に対する変更

更新24B以降、販売オーダーに保留を適用するためのパフォーマンスと信頼性が改善されました。次のガイドラインを使用して、保留が正常に機能していることを確認します。

ガイドライン

• 変更オーダーに保留を適用する場合は、オーダー管理から変更オーダーの報酬完了イベントを受信した後にのみ適用することをお薦めします。オーダー管理では、現在報酬を支払っているタスクは保持されません。背景は、オーダー履行中に発生する変更の管理の概要を参照してください。
• オーダー管理は、エラー・リカバリ中の販売オーダーまたはオーダー明細の保留要求を処理またはリリースしません。エラーを修正してから、保留を再試行する必要があります。

保留要求が失敗し、保留要求からの応答にFOM-4515574エラー・コードが含まれている場合は、次のことを確認してください:

• 現在、オーダー明細を更新していない。
• オーケストレーション・プロセスは現在待機ステップにあり、明細の処理を試行していない。
• オーダー明細がエラー・ステータスではない。

拡張またはREST APIの使用

オーダー管理拡張またはREST APIを使用して、保留を適用できます。

独自のタスク・タイプの使用

独自のタスク・タイプを使用する場合:

• 待機ステップを使用する必要があります。詳細は、販売オーダーで保留を設定するためのガイドラインを参照してください。
• 即時応答を送信した後にのみ保留を適用し、少なくとも2分間待機します。詳細は、履行システムへのオーダー管理の接続の概要を参照してください。
• 応答を調べて、成功していることを確認します。応答が失敗した場合は、再送信します。

詳細は、独自のタスク・タイプを使用した保留の適用を参照してください。

非推奨

更新24C以降、オーダー受入要求サービスのRequestHold操作およびReleaseHold操作が非推奨になります。これらの操作を現在使用している場合は、その使用をREST APIに置き換えることをお薦めします。

新規オーダー管理パラメータ

今後通知があるまで、Oracle Order Managementで「オーダー・ヘッダー値をオーダー明細にカスケード」パラメータを使用しないでください。このパラメータは、将来の使用のために用意されています。