クラウド・レディネス / Oracle Fusion Cloud Procurement
新機能
すべて展開


  1. 更新23D
  1. 改訂履歴
  2. 概要
  3. 任意の新機能の導入(オプトイン)
  4. 機能のサマリー
  5. サプライ・チェーン・オーケストレーション
    1. サプライ・チェーン・オーケストレーション
        1. 「バック・トゥ・バック販売オーダーの手動予約の表示」機能の拡張
        2. 購買オーダーが外注加工フローで準備できるまで製造からの変更を保留
        3. 再設計されたページを使用した供給転送要求の作成
  6. コラボレーション・メッセージング・フレームワーク
    1. コラボレーション・メッセージング・フレームワーク
        1. Avalaraを使用した取引先とのB2Bメッセージの交換
        2. Webサービスを使用して送信されたB2Bメッセージに関する合理化されたエラー・メッセージ・レポートの受信
        3. 他のOracleクラウド企業との購買オーダーの交換の簡略化
  7. 調達共通
    1. 共通調達
        1. RESTリソースを使用した調達の統合および拡張
        2. 休暇ルールに基づく他のユーザーへのポジション階層ルーティング委任
  8. 調達
    1. 購買
        1. 依頼者が開始した変更のバイヤーによる処理が必要
        2. ディープ・リンクを使用して依頼者として購買オーダーを表示
        3. 標準文書形式を使用したマイナス金額の購買オーダー明細の作成
        4. 納期および要求日のみが更新された場合の購買オーダー変更の通信の回避
        5. スプレッドシートを使用したコスト・センターに基づくバイヤー割当ルールのアップロード
        6. 自動否認済購買文書の否認事由の表示
        7. この更新で選択された購買不具合修正
      1. 品目の置換
        1. 品目置換タスクの定義中における追加情報の取得
    2. サプライヤ・モデル
        1. サプライヤを費用承認済にプロモートするには銀行口座が必要
        2. 文書をサプライヤ銀行口座に添付
    3. ソーシング
        1. サプライヤへの参加依頼時におけるサプライヤ・サイトおよび担当のデフォルト設定
        2. クローズ済ネゴシエーションの取消
        3. サプライヤが応答を送信したときに確認をEメール送信
        4. オンライン・メッセージ通知に添付を含める
        5. 500人を超えるサプライヤに対するネゴシエーションへの参加依頼
        6. この更新で選択されたソーシング不具合修正
        7. 見込みサプライヤを落札する場合は銀行口座が必要
    4. 費用分類
        1. ルールの新しい条件による分類結果の拡張
    5. 調達契約
        1. Adobe Acrobat Signによる契約の署名
        2. 契約のEメール送信時における文書の添付
        3. 契約検索からの承認履歴の表示
        4. 契約承認通知の構成
  9. 重要な処理と考慮事項

更新23D

改訂履歴

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

日付 モジュール 機能 ノート
2023年9月1日     初版作成。

概要

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

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

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

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

免責事項

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

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

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

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で提供される、実行準備が完了したレポート。

UIまたはプロセスベース: 小規模 = これらのUIまたはプロセスベースの機能は通常、フィールド、検証またはプログラムの小さな変更で構成されています。したがって、ユーザーに対する潜在的な影響は最小になります。

UIまたはプロセスベース: 大規模* = これらのUIまたはプロセスベースの機能は、より複雑に設計されています。したがって、ユーザーに対する潜在的な影響は高くなります。

すぐ使用できない状態で提供される機能 = エンド・ユーザーがこれらの機能を使用できるようにするには、処理が必要です。これらの機能は無効化されており、有効にするかどうかとその時期は自分で選択します。たとえば、a)新しいまたは拡張されたBIサブジェクト領域を最初にレポートに組み込む必要がある、b)新しいWebサービスを使用するには統合が必要である、c)機能にアクセスするには、ユーザー・ロールに機能を割り当てる必要があるなどです。

エンド・ユーザーがすぐに使用可能
(機能が使用可能な状態で提供)

レポートおよび小規模なUIまたはプロセスベースの新機能は、更新後のユーザーに対する影響を最小限に抑えます。したがって、顧客受入テストでは、大規模UIまたはプロセスベース*の新機能に焦点を当てる必要があります。

エンド・ユーザーによる使用の前に顧客はアクションが必要
(機能はすぐ使用できない状態で提供)

これらの機能を使用可能にするために処理が必要になるため、中断されません。選択的に使用するよう選択すると、テストおよびロールアウトのタイミングを設定できます。

機能

レポート

UIまたは
プロセスベース:
小規模

UIまたは
プロセスベース:
大規模*

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

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

「バック・トゥ・バック販売オーダーの手動予約の表示」機能の拡張

購買オーダーが外注加工フローで準備できるまで製造からの変更を保留

再設計されたページを使用した供給転送要求の作成

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

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

Avalaraを使用した取引先とのB2Bメッセージの交換

Webサービスを使用して送信されたB2Bメッセージに関する合理化されたエラー・メッセージ・レポートの受信

他のOracleクラウド企業との購買オーダーの交換の簡略化

調達共通

共通調達

RESTリソースを使用した調達の統合および拡張

休暇ルールに基づく他のユーザーへのポジション階層ルーティング委任

調達

購買

依頼者が開始した変更のバイヤーによる処理が必要

ディープ・リンクを使用して依頼者として購買オーダーを表示

標準文書形式を使用したマイナス金額の購買オーダー明細の作成

納期および要求日のみが更新された場合の購買オーダー変更の通信の回避

スプレッドシートを使用したコスト・センターに基づくバイヤー割当ルールのアップロード

自動否認済購買文書の否認事由の表示

この更新で選択された購買不具合修正

品目の置換

品目置換タスクの定義中における追加情報の取得

サプライヤ・モデル

サプライヤを費用承認済にプロモートするには銀行口座が必要

文書をサプライヤ銀行口座に添付

ソーシング

サプライヤへの参加依頼時におけるサプライヤ・サイトおよび担当のデフォルト設定

クローズ済ネゴシエーションの取消

サプライヤが応答を送信したときに確認をEメール送信

オンライン・メッセージ通知に添付を含める

500人を超えるサプライヤに対するネゴシエーションへの参加依頼

この更新で選択されたソーシング不具合修正

見込みサプライヤを落札する場合は銀行口座が必要

費用分類

ルールの新しい条件による分類結果の拡張

調達契約

Adobe Acrobat Signによる契約の署名

契約のEメール送信時における文書の添付

契約検索からの承認履歴の表示

契約承認通知の構成

>>クリックして重要な処理と考慮事項を表示

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

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

「バック・トゥ・バック販売オーダーの手動予約の表示」機能の拡張

「バック・トゥ・バック販売オーダーの手動予約の表示」機能の拡張により、手動で作成したすべての予約をバック・トゥ・バック・フローで表示できるようにします。このリリースより前のリリースでは、供給オーダーに「未割当」供給タイプがある明細に対してのみ手動予約を表示できました。現在は、Oracle Supply Chain Orchestrationがその供給を処理している間も、すべての手動予約を満たす供給オーダー、転送オーダー、購買オーダーおよび作業オーダーを表示できるようになりました。また、このリリースより前は、オーダー明細の取消時に手動予約は取り消せませんでした。次のことが可能になりました。

手動予約によって超過供給が発生する可能性がある場合、「供給オーケストレーション」作業領域では供給明細に新しいアイコンが表示されます。マウスのポインタを重ねると、「超過供給」テキストが表示されます。

バック・トゥ・バック・フローの各販売オーダーに対して予約した超過供給をすばやく確認します。

有効化のステップ

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

ヒントと考慮事項

  • 更新24Aまで、バック・トゥ・バック販売オーダーの手動予約の表示機能を手動でオプト・インする必要があります。
  • サプライ・チェーン・オーケストレーションでは、Oracle Order Managementから受け取った需要の変化に対する手動予約は自動的には変更されません。予約を手動で変更する必要があります。
  • 他の要求でも作業オーダー、購買要求または転送オーダーが使用される可能性があるため、作業オーダー、購買要求または転送オーダーの数量は、予約の数量や供給明細またはトラッキング明細上の数量とは異なる場合があります。

アクセス要件

この機能は、販売オーダーを作成および送信できるすべての権限で使用できます。

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

  • オーダーの開始(FOM_CREATE_ORDER_PRIV)
  • オーダーの発行(FOM_SUBMIT_ORDER_PRIV)

購買オーダーが外注加工フローで準備できるまで製造からの変更を保留

Oracle Supply Chain Orchestrationを使用して、Oracle Manufacturingから受け取る変更を一時的に保持します。作業オーダーまたは工程が変更されたが、Oracle Purchasingで購買オーダーが作成されていないか改訂中の場合、外注加工フローでこの機能を使用します。

仕組み:

  1. 作業オーダーまたは工程が外注加工フローで変更され、Oracle Manufacturingによってサプライ・チェーン・オーケストレーションに更新要求が送信されます。製造では、作業オーダーや工程が変更されるたびに、別の要求が送信される場合があります。
  1. 購買では、購買オーダーが作成されていないか、購買オーダーが改訂中の場合、サプライ・チェーン・オーケストレーションは一時的に更新要求を保持します。
  1. 購買では、購買オーダーの改訂を作成または終了すると、サプライ・チェーン・オーケストレーションは、Oracle Manufacturingから購買に受け取った最新の更新要求を自動的に送信します。

処理効率を高め、更新要求を購買に送信したときに発生する障害を防止します。サプライ・チェーン・オーケストレーションが製造から購買に受信したすべての要求を送信するかわりに、購買が購買オーダーの改訂を作成または終了するまで待機してから、最新の要求のみを送信します。

有効化のステップ

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

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

主なリソース

アクセス要件

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

  • 供給オーダー・インタフェースの処理(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)

この機能をサポートするために導入された新規の権限はありません。

再設計されたページを使用した供給転送要求の作成

再設計されたページを使用して、デスクトップ、タブレットまたはモバイル・デバイスで転送要求を作成できます。サプライ・チェーン・オーケストレーションには、要求に最適な履行を提供する供給ソースがデフォルトで表示されます。デフォルトの供給ソースを受け入れるか、要求の作成時にソースのリストから別の供給ソースを選択できます。標準品目またはプロジェクトの一部である品目の要求を作成できます。

デスクトップ、タブレットまたはモバイル・デバイスで転送要求を作成する必要がある場合のユーザー・エクスペリエンスを向上させます。

有効化のステップ

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

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

ヒントと考慮事項

次に、実行できる新しい操作をいくつか示します。

  • 「サプライ・チェーン・オーケストレーション」作業領域の「新規供給要求」タスクを使用して、転送要求を作成します
  • 要求を作成するには、「在庫管理」作業領域の「品目数量の管理」タスクを使用します。
  • 要求の「搬送先タイプ」属性を「在庫」または「費用」に設定します。
  • 要求の「転送タイプ」属性を「組織間」または「組織内」に設定します。
  • 1つ以上の搬送先組織に対して複数の要求を作成して発行します。
  • 要求では、品目のプライマリ単位または非プライマリ単位を使用できます。
  • 最適な履行を提供する供給ソースを受け入れるか、または可用性に応じてサプライ・チェーン・オーケストレーションが自動的にランク付けするソースのリストから別のソースを選択します。
  • プロジェクトの転送要求を作成します。

主なリソース

アクセス要件

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

  • 供給オーダー・インタフェースの処理(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を使用した取引先とのB2Bメッセージの交換

新しい事前定義済サービス・プロバイダであるAvalaraは、電子請求のニーズに使用できます。Avalaraのサービスにサブスクライブすると、Pan-European Public Procurement Online (PEPPOL)ネットワークを介して取引先に接続できます。Avalara社は、認定されたPEPPOLアクセス・ポイントおよびソリューション・プロバイダです。

Avalaraのメッセージおよび配信方法は事前定義されているため、コラボレーション・メッセージング作業領域でのB2B設定が合理化されます。

有効化のステップ

有効化のステップ

概要レベルでは、事前定義済のAvalaraサービス・プロバイダを設定します。

  1. Avalaraを構成して、取引先とメッセージを交換します。
  2. 取引先を作成します。
  3. 取引先をサプライヤまたは顧客に関連付けます。
  4. サプライヤまたは顧客と交換する文書を選択します。

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

事前定義済サービス・プロバイダAvalaraの構成

  1. 「タスク」パネル・タブから「コラボレーション・メッセージング・サービス・プロバイダの管理」を選択し、Avalaraサービス・プロバイダを検索します。
  1. 「コラボレーション・メッセージング・サービス・プロバイダの編集」ページで、「アウトバウンド配信接続タイプ」フィールドで「テスト」または「本番」を選択して、設定する環境を反映します。
  1. 「配信方法」タブを選択し、選択した接続タイプのユーザー名とパスワードを入力します。

「コラボレーション・メッセージング」作業領域を使用して新しいサービス・プロバイダを設定する方法を示すスクリーン・キャプチャ。

アウトバウンド配信接続タイプおよび配信方法

  1. 「アウトバウンド・コラボレーション・メッセージ」タブを選択し、配信方法をメッセージにリンクして、取引先と交換するメッセージをアクティブ化します。
  • UBL 2.1 PEPPOL請求書アウトバウンド(Avalara_UBL-2.1-PEPPOL-Invoice-Out)

新しいサービス・プロバイダの配信方法およびステータスを示すスクリーン・キャプチャ。

Avalaraアウトバウンド・コラボレーション・メッセージ

  1. 「インバウンド・コラボレーション・メッセージ」タブを選択し、使用するメッセージをアクティブ化します。次のメッセージを使用できます。
  • UBL 2.1請求書アプリケーション応答インバウンド(Avalara_UBL-2-1-InvoiceApplicationResponse-In)
  • UBL 2.1 PEPPOL請求書インバウンド(Avalara_UBL-2.1-PEPPOL-Invoice-In)

新規サービス・プロバイダのインバウンド・コラボレーション・メッセージの詳細を示すスクリーン・キャプチャ。

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

取引先の作成

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

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

新規サービス・プロバイダの取引先を作成する方法を示すスクリーン・キャプチャ。

取引先の作成

取引先とサプライヤまたは顧客との関連付け

次に、取引先を電子請求文書のサプライヤまたは顧客に関連付けます。

  1. 「タスク」パネル・タブで「サプライヤB2B構成の管理」を選択して、サプライヤを検索します。
  1. サプライヤを選択して、「サプライヤB2B構成の編集」を選択します。
  1. 「サプライヤB2B構成の編集」ページで、「取引先割当」タブを選択し、「処理」「行の追加」をクリックして、取引先とAvalaraサービス・プロバイダを追加します。

新規サービス・プロバイダ用に作成された取引先の割当詳細を示すスクリーン・キャプチャ。

サプライヤ取引先割当

  1. 「サプライヤB2B構成の編集」ページで、「文書設定」タブを選択し、選択したサプライヤと交換する請求書 - インバウンドを追加します。

取引先に設定された文書の詳細を示すスクリーン・キャプチャ。

サプライヤ文書設定

  1. 「タスク」パネル・タブで「顧客アカウント・コラボレーション構成の管理」を選択し、顧客を検索します。
  1. 顧客を選択します。「顧客アカウント・コラボレーション構成の編集」ページで、「関連サービス・プロバイダ」セクションでAvalaraサービス・プロバイダおよび取引先を選択します。
  1. 「サービス・プロバイダ用のコラボレーション文書」セクションで、交換する文書(アウトバウンド請求書またはインバウンド請求書の確認)を選択します。

新しいサービス・プロバイダ用にサプライヤと文書を交換する方法を示すスクリーン・キャプチャ。

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

ヒントと考慮事項

「サービス・プロバイダの編集」ページの「アウトバウンド配信接続タイプ」フィールドで、メッセージ配信の正しいエンドポイント(「テスト」または「本番」)を選択していることを確認します。メッセージ配信タイプを選択しない場合、メッセージ処理中に、Avalaraのエンドポイントを指定しなかったことを示すエラー・メッセージが表示されます。

主なリソース

アクセス要件

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

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

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

Webサービスを使用して送信されたB2Bメッセージに関する合理化されたエラー・メッセージ・レポートの受信

同期Webサービス操作を介して受信したインバウンド・メッセージの検証プロセスが改善されました。現在、コール元は、メッセージの処理前に修正可能な関連エラーおよび修正可能なエラーのみを受信します。調整されたプロセスでは、次のことが検証されます。

  • 認証: サービスのコール元が有効なユーザーです。
  • 認可: Webサービスのコール元には、コラボレーション・メッセージ・インバウンド・サービスの起動(CMK_INVOKE_INBOUND_COLLAB_DOC_SERVICE_PRIV)権限を持つジョブ・ロールが割り当てられます。
  • 送信者パーティ: ペイロードのSENDER_IDおよびSENDER_ID_TYPEには、有効な取引先IDおよびIDタイプがあります。
  • 外部メッセージ定義: ペイロードの外部メッセージ定義はOracle Collaboration Messaging Frameworkに存在します。
  • 無効なオーダー番号購買オーダー確認、請求書、出荷などの購買オーダーを参照するインバウンド・メッセージに有効な購買オーダー番号があります

その他のB2B設定エラーは、コラボレーション・メッセージング作業領域に記録され、管理されます。非同期操作は変更されず、資格証明が検証され、無効な資格証明に対してエラーが返されます。

B2Bメッセージの送信者として、修正の制御下にあるエラーのみを受信します。B2Bメッセージの受信者として、修正へのアクセス権があるコラボレーション・メッセージング・フレームワークのエラーをレビューして、B2Bメッセージの交換中に発生した問題をトラブルシューティングするより効率的なプロセスを確保できます。

有効化のステップ

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

主なリソース

他のOracleクラウド企業との購買オーダーの交換の簡略化

購買オーダーの送受信に使用できる新しいメッセージ定義が6つあります。これらのメッセージ定義では、Oracle B2Bメッセージング標準が使用され、購買オーダーを取引先、B2Bサービス・プロバイダおよびその他のOracleクラウド企業と直接交換できます。

  • Oracle-1-0-B2B-Purchase-Order-In
  • Oracle-1-0-B2B-Purchase-Order-Change-In
  • Oracle-1-0-B2B-Purchase-Order-Cancel-In
  • Oracle-1-0-B2B-Purchase-Order-Out
  • Oracle-1-0-B2B-Purchase-Order-Change-Out
  • Oracle-1-0-B2B-Purchase-Order-Cancel-Out

これらのメッセージには、購買オーダーを取引先およびB2Bサービス・プロバイダと交換するための追加オプションが用意されています。

有効化のステップ

上位レベルでは、次のメッセージ定義を有効にする2つのステップがあります。

  1. サービス・プロバイダまたは取引先を使用して、メッセージ定義を直接設定します。
  2. 取引先をサプライヤまたは顧客に関連付けます。

サービス・プロバイダまたは取引先によるメッセージ定義の設定

  1. 「タスク」パネル・タブから「コラボレーション・メッセージング・サービス・プロバイダの管理」または「B2B取引先の管理」を選択し、設定するサービス・プロバイダまたは取引先を検索します。
  1. 購買オーダーを送信する場合は、「アウトバウンド・コラボレーション・メッセージ」タブで、取引先と交換する新しいアウトバウンド購買オーダー・メッセージ定義を選択します。
  • Oracle-1-0-B2B-Purchase-Order-Out
  • Oracle-1-0-B2B-Purchase-Order-Change-Out
  • Oracle-1-0-B2B-Purchase-Order-Cancel-Out
  1. 配信方法をメッセージ定義に関連付け、ステータスを「アクティブ」に設定します。

サービス・プロバイダまたは取引先とのメッセージ定義の設定方法を示すスクリーン・キャプチャ。

アウトバウンド購買オーダー・メッセージ

  1. 購買オーダーを受け取る場合は、「インバウンド・コラボレーション・メッセージ」タブで、取引先と交換する新しいインバウンド購買オーダー・メッセージ定義を選択し、ステータスを「アクティブ」に設定します。
  • Oracle-1-0-B2B-Purchase-Order-In
  • Oracle-1-0-B2B-Purchase-Order-Change-In
  • Oracle-1-0-B2B-Purchase-Order-Cancel-In

サービス・プロバイダまたは取引先とのメッセージ定義の設定方法を示すスクリーン・キャプチャ。

インバウンド購買オーダー・メッセージ

取引先とサプライヤまたは顧客との関連付け

次に、取引先をサプライヤまたは顧客に関連付けて、購買オーダーを交換します。

  1. 「サプライヤB2B構成の管理」を「タスク」パネル・タブで選択し、サプライヤを検索します。
  1. サプライヤを選択して、「サプライヤB2B構成の編集」を選択します。
  1. 「サプライヤB2B構成の編集」ページで「取引先割当」タブを選択し、「処理」「行の追加」をクリックして取引先を追加し、取引先を選択します。
  1. 選択したサプライヤと交換する「文書設定」タブを選択し、購買オーダー文書(購買オーダー - アウトバウンド、購買オーダー変更 - アウトバウンド、購買オーダー取消 - アウトバウンド)を追加します。

サプライヤと交換する文書の詳細を示すスクリーン・キャプチャ。

サプライヤおよび関連購買オーダー文書

  1. 「タスク」パネル・タブで「顧客コラボレーション構成の管理」を選択し、顧客を検索します。
  1. 顧客を選択します。「顧客コラボレーション構成の編集」ページで、「関連サービス・プロバイダ」セクションで取引先を選択します。
  1. 「サービス・プロバイダ用のコラボレーション文書」セクションで、交換する購買オーダー文書(購買オーダー - インバウンド、購買オーダー変更 - インバウンド、購買オーダー取消 - インバウンド)を選択します。

主なリソース

アクセス要件

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

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

調達供給

共通調達

RESTリソースを使用した調達の統合および拡張

この更新のOracle Fusion Cloud ProcurementおよびOracle Fusion Cloud Self Service Procurementでは、外部システムとの統合を有効化および簡略化するために、変更されたRESTリソースが提供されます。

次のRESTリソースは以前に使用でき、更新されました。

  • 購買依頼
    • 送信処理は、新しい資金予約ポイントである送信をサポートするように拡張されています。
    • checkFundsカスタム処理を使用して、購買依頼が資金チェックに合格したか失敗したかを示す、購買依頼の資金をチェックします。
    • DestinationSubinventory属性を使用して、購買依頼明細の搬送先保管場所(搬送先タイプが在庫の場合)を設定または更新します。
    • 取消カスタム処理(ヘッダー・レベル)は、オーダーに適用されていない特定の明細の取消をサポートするように拡張されています。
    • RejectedReason属性を使用して、購買依頼が自動的に否認された事由を表示します。
  • 購買依頼プリファレンス
    • DestinationSubinventory属性を使用して、プリファレンス設定で搬送先保管場所(搬送先タイプ=在庫)を選択します。
    • 新しい購買ニュース子RESTリソースを使用して、プリファレンスで構成された購買依頼発行ビジネス・ユニットの購買ニュース情報を取得します。
  • ショッピング・カタログ品目詳細
    • getItemExtendedAttributesカスタム処理を使用して、「製品情報管理」作業領域で構成されたマスター品目の拡張可能フレックスフィールド(EFF)詳細を取得します。
  • 下書き購買オーダー
    • deleteChangeOrderカスタム処理を使用して、調達依頼者またはバイヤーとして未完了の変更オーダーを削除します。
    • updateAllLinesカスタム処理を使用して、調達依頼者として変更オーダーの明細の属性を一括更新します。
    • トランザクション勘定科目ビルダーの税金決定要因または入力ソースが購買オーダーで変更された場合、調達依頼者またはバイヤーとしてcalculateTaxAndAccountingカスタム処理を使用して税金を計算し、借方勘定を導出します。
    • summaryAttributesカスタム処理を調達依頼者として使用して、購買オーダーの明細、スケジュールおよび配分から搬送先事業所、借方勘定、プロジェクト、依頼者および金額に関する要約情報を取得します。
  • 調達承認済サプライヤ・リスト・エントリ
    • GET、POSTおよびPATCHは、承認済サプライヤ・リスト・エントリの付加フレックスフィールド(DFF)属性でサポートされます。
  • 承認済サプライヤ・リスト・ソース文書
    • GET、POSTおよびPATCHは、承認済サプライヤ・リスト・エントリごとにソース文書のDFF属性に対してサポートされます。
  • サプライヤ・ネゴシエーション応答
    • GETは、応答でサプライヤによって提示される価格分岐と数量ベースの価格階層でサポートされます。

これらの新しいRESTリソースおよび変更されたRESTサービスを使用して統合を簡略化し、他のアプリケーションや外部システムとの標準ベースの相互運用性をサポートできます。

有効化のステップ

REST APIガイドのRESTサービス定義を確認して利用します(Oracle Help Center関心のあるアプリケーション・サービス領域→「APIおよびスキーマ」から使用可能)。OracleのRESTサービスを初めて利用する場合は、クイック・スタートに関する項から開始してください。

主なリソース

アクセス要件

Oracle Help Centerで入手可能なOracle Fusion Cloud Procurement REST APIドキュメントの権限の項を参照してください。

休暇ルールに基づく他のユーザーへのポジション階層ルーティング委任

ユーザーが休暇を取得するときは、休暇ルールを定義して、不在時にタスクが再割当または委任されるようにできます。ポジション・リスト・ビルダーを使用してワークフロー・タスクをルーティングする場合、タスクが割り当てられたポジションを持つユーザーにアクティブな休暇ルールがあると、そのポジションにあるユーザーが5人以下であり、タスクが再割当または委任されている場合にかぎり、そのルールが有効になります。

ポジションベースの割当ては、休暇ルールに従って再割り当てまたは委任されます。

有効化のステップ

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

主なリソース

調達

購買

依頼者が開始した変更のバイヤーによる処理が必要

オープン購買オーダーに対する依頼者が開始した変更をレビューおよび処理することをバイヤーに要求します。この機能を有効にすると、依頼者が提案した変更は内部変更オーダーとして自動的に作成されます。これは、提案された変更に、購買オーダー文書の改訂を作成するサプライヤ対応属性が含まれている場合にも適用されます。

内部変更オーダーが承認されると、バイヤーは通知を受信し、依頼者が開始した変更に対して処理を実行する必要があります。依頼者変更オーダーの「購買担当保留処理」ステータスは、購買担当が提示された変更をレビューして変更するか、そのまま送信するか、否認する必要があることを示します。

バイヤーが提示された変更内容を変更するか、変更内容をそのまま送信すると、バイヤーが開始した変更オーダーが作成され、承認のために発行されるか、バイヤーがさらに編集するために未完了ステータスのままになります。

これらのスクリーン・キャプチャは、次の機能を示しています。

依頼者は、オープン購買オーダーで依頼者が開始した変更を作成します。

依頼者が開始した変更

依頼者が開始した変更で処理が必要な場合、バイヤーに通知されます。依頼者が開始した変更要処理通知は、Oracle Analytics Publisherで購買オーダー承認通知レイアウト・テンプレートを更新することで変更できます。

依頼者が開始した変更要処理通知

バイヤーは、「バイヤー処理待ち」ステータスで依頼者が開始した変更をレビューします。

バイヤー処理待ちの依頼者開始変更

バイヤーが編集処理を行うと、バイヤーが開始した変更オーダーが作成され、その詳細は依頼者が開始した変更からコピーされます。

バイヤー変更オーダー

依頼者が開始した変更をバイヤーが編集するか、発行処理を実行すると、購買オーダー文書履歴の依頼者変更オーダーに対して「受入」処理が記録されます。

購買オーダー文書履歴

「変更要求」という新しいインフォレットが、「購買オーダー」作業領域でバイヤーに使用できるようになりました。このインフォレットには、バイヤー処理を必要とする保留中の要求者変更オーダーの数が表示されます。

変更要求インフォレット

有効化のステップ

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

オファリング: 調達

ヒントと考慮事項

  • 「変更要求」インフォレットはデフォルトで非表示になり、「購買オーダー」作業領域の「自分のインフォレット」アイコンをクリックして公開できます。
  • 新しい承認属性である「依頼者が開始した変更からバイヤーにより処理済」を使用して、承認ルールを作成できます。バイヤー変更オーダーが依頼者が開始した変更から発生したかどうかを確認し、それに応じて承認のためにルーティングする条件を設定できます。
  • セルフサービス調達、レスポンシブ・セルフサービス調達アプリケーションおよび下書き購買オーダーRESTリソースを使用して、依頼者が開始した変更を作成できます。

主なリソース

  • この機能の詳細は、Require Buyers to Process Requester-Initiated Changesのレディネス・トレーニングをご覧ください。

アクセス要件

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

  • 調達依頼者としての購買オーダーの変更(PO_CHANGE_PURCHASE_ORDER_AS_PROCUREMENT_REQUESTER_PRIV)
  • 購買オーダーの変更(PO_CHANGE_PURCHASE_ORDER_PRIV)

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

ディープ・リンクを使用して依頼者として購買オーダーを表示

ディープ・リンクを使用して、自分が依頼者または作成者となっている購買依頼に関連付けられた購買オーダーを表示します。リンクを使用して、これらの購買オーダーにビジネス・インテリジェンス・レポートまたは外部アプリケーションから直接アクセスできます。

ディープ・リンクを使用して、購買依頼に関連付けられた購買オーダーを表示してオーダーの処理を実行し、ライフサイクル、明細、スケジュールおよび配分に関する詳細情報を取得できます。

オーダー・ライフサイクルおよび処理メニュー

使用可能明細詳細アイコン

使用可能スケジュール詳細アイコン

使用可能配分詳細アイコン

有効化のステップ

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

主なリソース

アクセス要件

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

  • 購買依頼の表示 - すべて(POR_VIEW_REQUISITION_ALL_PRIV)
  • 調達依頼者として発注を表示(PO_VIEW_PURCHASE_ORDER_AS_PROCUREMENT_REQUESTER_PRIV)

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

標準文書形式を使用したマイナス金額の購買オーダー明細の作成

標準文書形式を使用する購買オーダーのクレジットを記録するために、マイナスの金額の購買オーダー明細を作成します。標準文書形式でクレジット明細タイプを使用可能にした後、標準形式を使用する既存の購買オーダーまたは新規購買オーダーにクレジット明細を追加できます。

更新23Aでは、ユーザー定義文書形式でのみクレジット明細タイプを使用可能にできました。この更新では、標準文書形式でクレジット与信明細タイプを使用可能にできます。

有効化のステップ

「文書形式の管理」で標準文書形式を開き、「クレジット明細タイプ使用可能」設定を有効にします。設定を有効にすると、無効にできません。

標準文書形式でのクレジット明細タイプの使用可能

ヒントと考慮事項

「クレジット明細タイプ使用可能」設定は、標準文書形式で有効にした後は無効にできません。

主なリソース

マイナス金額の購買オーダー明細を作成して、サプライヤとネゴシエーションしたオーダー金額に対するクレジットを記録できます。詳細は、Oracle Fusion Procurement Cloud新機能更新23Aでマイナス金額の購買オーダー明細の作成機能を参照してください。

アクセス要件

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

  • 購買オーダーの作成(PO_CREATE_PURCHASE_ORDER_PRIV)
  • 購買オーダーの変更(PO_CHANGE_PURCHASE_ORDER_PRIV)

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

この機能を設定するには、次の既存の権限を含む構成済ジョブ・ロールが必要です。

  • 調達構成の管理(PO_MANAGE_PROCUREMENT_CONFIGURATION_PRIV)

納期および要求日のみが更新された場合の購買オーダー変更の通信の回避

納期および要求日のみが更新された場合、サプライヤへの購買オーダー変更の通信を回避します。

この更新の前は、購買オーダーの納期および要求日に対する変更がサプライヤに伝達されました。この更新では、変更オーダー・テンプレートを構成して、これらの属性を更新した場合に購買オーダーを改訂する必要があるかどうかを指定できるようになりました。

有効化のステップ

  1. 「設定および保守」作業領域で、「変更オーダー・テンプレートの管理」タスクを使用します。
    • オファリング: 調達 
    • 機能領域: 調達ファウンデーション
  1. 新しい変更オーダー・テンプレートを作成します。
  1. 約束搬送日、要求搬送日、約束出荷日、要求出荷日、最終許容搬送日および最終許容出荷日の「改訂文書」チェック・ボックスの選択を解除します。

変更オーダー・テンプレート

次のステップを使用して、新しい変更オーダー・テンプレートを調達ビジネス・ユニットに関連付けられます。

  1. 「設定および保守」作業領域で、「調達ビジネス機能の構成」タスクを使用します。
    • オファリング: 調達 
    • 機能領域: 調達ファウンデーション
  1. 「文書タイプ」にナビゲートします。
  1. 購買オーダー文書タイプを選択します。
  1. 新しく作成した変更オーダー・テンプレートを選択します。

調達ビジネス・ユニット構成

ヒントと考慮事項

  • 最新の変更オーダー・テンプレートは、承認のために送信されていない変更オーダーに適用されます。
  • 既存の変更オーダー・テンプレートの「納期」および「要求日」属性は、デフォルトで読取り専用モードで選択されます。

主なリソース

アクセス要件

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

  • 購買オーダーの変更(PO_CHANGE_PURCHASE_ORDER_PRIV)

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

この機能を設定するには、次の既存の権限を含む構成済ジョブ・ロールが必要です。

  • 購買変更オーダー・テンプレートの管理(PO_MANAGE_PO_CHANGE_ORDER_TEMPLATE_PRIV)

スプレッドシートを使用したコスト・センターに基づくバイヤー割当ルールのアップロード

ADFdiスプレッドシートを使用して、購買依頼配分のコスト・センターに基づいてバイヤー割当ルールを作成および更新します。

この更新の前は、コスト・センター属性を使用してバイヤー割当ルールを作成または管理するために、UIのみが使用できました。この更新では、スプレッドシートを使用して、コスト・センター属性を使用してバイヤー割当ルールを一括で作成または管理できます。

このスクリーン・キャプチャは、この機能を示しています。

バイヤー割当ルール・スプレッドシート

有効化のステップ

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

主なリソース

アクセス要件

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

  • バイヤー割当ルールの管理(PO_MANAGE_BUYER_ASSIGNMENT_RULES_PRIV)

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

自動否認済購買文書の否認事由の表示

否認されたFYI通知および文書履歴で、承認プロセス中に自動的に否認された購買オーダーおよび契約の否認事由を表示します。自動的に否認される購買文書の適切な否認事由を構成できるようになりました。

この更新の前は、バイヤーまたは依頼者は、購買文書が自動否認された事由を把握できませんでした。この更新では、自動否認ルールの否認事由を構成し、オンラインおよびEメール通知を介して事由をバイヤーまたは依頼者と共有し、文書履歴内の否認事由を追跡できます。

これらのスクリーン・キャプチャは、次の機能を示しています。

自動否認ルール

否認事由を構成するための標準参照コード

否認済FYI通知

購買オーダー文書履歴

有効化のステップ

  1. 「設定と保守」作業領域で、「標準参照の管理」タスクに移動します。
  1. 参照タイプORA_POR_AUTO_REJECT_REASONを検索します。
  1. 自動否認事由の新しい参照コードを作成します。
  1. 自動否認ルール名は参照コードとして使用する必要がありますが、自動否認ルールの参照コードを指定する場合は、ルール名に含まれる空白を削除する必要があります。

否認事由を構成するための標準参照コード

ヒントと考慮事項

  • 自動否認ルールに対して構成された参照コードに対応する摘要が指定されていない場合、ルール名は否認事由として表示されます。
  • 参照コードには、自動否認ルールの否認事由を定義するための30文字の制限があります。

アクセス要件

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

  • 購買オーダーの作成(PO_CREATE_PURCHASE_ORDER_PRIV)
  • 購買オーダーの変更(PO_CHANGE_PURCHASE_ORDER_PRIV)

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

この機能を設定するには、次の既存の権限を含む構成済ジョブ・ロールが必要です。

  • アプリケーション標準参照の管理(FND_APP_MANAGE_STANDARD_LOOKUP_PRIV)

この更新で選択された購買不具合修正

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

外貨を使用した価格許容範囲チェックの実行

この更新の前は、購買依頼と購買オーダーの間の価格変更許容範囲の検証プロセスで、比較に機能通貨が使用されました。ただし、購買依頼と購買オーダーの換算レートの差異が原因で、トランザクション通貨に実際の価格変更がない場合でも、検証が誤ってトリガーされました。

この更新後、購買依頼と購買オーダーの間の価格変更許容範囲の検証プロセスでは、購買依頼通貨と購買オーダー通貨が一致しない場合にのみ、機能通貨が比較に使用されます。

Oracleリファレンス: 35387314

有効化のステップ

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

品目の置換

品目置換タスクの定義中における追加情報の取得

品目置換タスクの作成中に供給中断の事由を取得できるようになりました。一時的な置換である場合、中断した品目の予想使用可能日をサプライヤから取得することもできます。この日付は、中断した品目を置換する終了日となる予定で、この日付より後に置換タスクで再稼働処理を開始する必要があります。永続的な置換タスクには、予想使用可能日属性がありません。

新規品目置換

供給の中断および予想使用可能日が、置換および再稼働を開始する「置換詳細」ページで表示されるようになりました。

置換の詳細

品目置換タスクでこれらの属性を取得すると、供給の中断を分析し、根本原因を特定し、サプライヤのパフォーマンスを評価できるため、ソーシングの意思決定をより適切に行えるため、業務効率が向上します。

有効化のステップ

この機能を使用するには、供給中断事由の参照コードを定義して、供給中断の様々な事由に基づいて品目置換タスクを分類できるようにする必要があります。

「設定および保守」作業領域で、「標準参照の管理」タスクを検索します。タスク・ウィンドウで、「内容」フィールドに供給中断の事由を入力し、「検索」をクリックします。ORA_SCH_PR_SUP_DIS_ REASON: 参照コードの下に新しい参照コードを作成します。

供給中断事由参照値

主なリソース

  • Oracle Help Centerの調達の使用の品目置換を参照してください。

アクセス要件

「品目置換の管理」(SCH_MANAGE_ITEM_REPLACEMENT)権限を含む構成済ジョブ・ロールが割り当てられているユーザーは、この機能にアクセスできます。

サプライヤ・モデル

サプライヤを費用承認済にプロモートするには銀行口座が必要

サプライヤに電子的に支払うには、サプライヤ・プロファイルに銀行口座が必要です。サプライヤの費用承認済へのプロモーション要求が銀行口座なしで送信されると、承認プロセスが遅くなり、承認者による手動介入が必要になります。費用承認要求を発行する前に、サプライヤ・プロファイルに有効な銀行口座があることを要求する機能により、承認処理がより円滑になり、サプライヤとより早く取引できます。

有効な銀行口座または銀行口座割当がない見込みサプライヤをプロモーションすると、プロモーションを続行できないようにエラーが表示されます。

銀行口座のないサプライヤのプロモーション不可

有効化のステップ

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

オファリング: 調達

ヒントと考慮事項

機能にオプトインする場合は、次の点を考慮してください。

  • 費用承認済登録では、サプライヤ登録が承認されてサプライヤが作成されると、費用承認の承認が自動的に開始されます。サプライヤが費用承認のレビュー時に銀行口座情報が取得されるように、費用承認済登録の設定で必要に応じて銀行口座を構成する必要があります。

アクセス要件

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

  • サプライヤの保守(POZ_MAINTAIN_SUPPLIER_PRIV)

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

文書をサプライヤ銀行口座に添付

サプライヤ銀行口座が正しく設定されていることを確認し、サプライヤに対して有効であることを確認するには、適切なドキュメントが必要です。サプライヤ銀行口座を検証するための正確な文書がない場合、支払遅延や不正支払など、リスクの可能性が高くなります。サプライヤ銀行口座を使用して適切な文書を安全に収集および保存する機能により、口座の所有権を確認できるため、不正な支払を防止できます。

この機能を使用すると、サプライヤ銀行口座を作成または更新するときに文書を添付できるようになりました。銀行口座検証に関して厳格なポリシーを実装するために、必要に応じて添付を構成するためのオプションが用意されています。必要に応じて構成する場合は、新しい銀行口座を作成するとき、または既存の銀行口座の属性(国、口座番号、銀行名、支店名、IBANおよび通貨)のいずれかを更新するときに、サポート文書を添付する必要があります。

セルフサービス・サプライヤ登録要求での銀行口座の作成

内部プロファイル変更要求での銀行口座の作成

変更要求での添付の追加

承認プロセス中に、サプライヤ登録またはプロファイル変更要求に対して、承認者が銀行口座の正確性を確認できるように添付文書を使用できます。要求が承認されると、添付文書がサプライヤのプロファイルに銀行口座とともに保存され、後で参照できるようになります。

承認者に使用可能な銀行口座添付

有効化のステップ

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

オファリング: 調達

  • サプライヤ銀行口座添付にアクセスする必要がある内部ユーザー(承認者、サプライヤ管理者またはマネージャ)に、「サプライヤ銀行口座添付の保守」権限を付与します。この更新ではこの権限が新しくなり、サプライヤ銀行口座添付の表示および管理アクセスの両方が許可されます。

ノート: サプライヤ担当者は、Oracle Supplier Portalからこれらの添付にアクセスするためにこの権限を必要としません。銀行口座をレビューするセルフサービス登録またはプロファイル変更要求の承認者には、銀行口座の検証に必要な添付文書を表示できるように、この権限が付与されている必要があります。

また、この設定はオプションです。使用方法は要件によって異なります。

  • 「サプライヤ登録およびプロファイル変更要求の構成」設定タスクで、必要に応じて銀行口座添付を構成します。次世代のセルフサービス・サプライヤ登録およびサプライヤ・プロファイル変更要求の必要に応じて銀行口座添付を構成するためのオプションは、それぞれ「サプライヤ登録」タブと「サプライヤ・プロファイル変更要求」タブで使用できます。

ヒントと考慮事項

  • 銀行口座添付は、内部および外部サプライヤ・プロファイル変更要求と次世代のセルフサービス・サプライヤ登録フローの両方でサポートされています。
  • 銀行口座が変更管理に対して使用可能になっていない場合、銀行口座添付もサプライヤ・プロファイルでサポートされます。
  • セキュリティ上の理由から、Eメール通知で銀行口座添付は使用できません。承認者は、アプリケーションのワークリスト通知からのみアクセスできます。
  • すぐに使用できるドキュメント・カテゴリとして、ACHリクエスト・フォーム、銀行通知書、IBAN証明書、その他のドキュメントおよびスキャンされた小切手がサポートされています。セルフサービス・サプライヤ登録要求に添付された銀行口座添付は、「その他の文書」カテゴリで保存されます。

ソーシング

サプライヤへの参加依頼時におけるサプライヤ・サイトおよび担当のデフォルト設定

現在、サプライヤを招待する際には、サプライヤ・サイトとサプライヤ担当者を選択する必要があります。または、すべての担当者に通知できます。サプライヤごとにサイトと担当者を選択すると、特にサプライヤのサイトが1つのみの場合や、担当者が1つのみの場合、面倒な場合があります。

現在は、サプライヤを追加するときに、サプライヤにサイトが1つしかなく、サイトに関連付けられた担当が1つしかない場合、サプライヤ・サイトおよびサプライヤ担当がデフォルト設定されます。

サプライヤの選択への追加時にデフォルト設定されるサプライヤ・サイト

サプライヤへの返品ステップでデフォルトとなるサプライヤ担当

現在は、多くのサプライヤを効率的に検索して追加し、ネゴシエーションをすばやく公開できるようになりました。

有効化のステップ

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

アクセス要件

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

  • サプライヤ・ネゴシエーションの作成(PON_CREATE_SUPPLIER_NEGOTIATION_PRIV)
  • サプライヤ・ネゴシエーション・テンプレートの作成(PON_CREATE_SUPPLIER_NEGOTIATION_TEMPLATE_PRIV)
  • サプライヤ・ネゴシエーションの編集(PON_EDIT_SUPPLIER_NEGOTIATION_PRIV)
  • ネゴシエーション・サプライヤへの参加依頼の管理(PON_MANAGE_NEGOTIATION_SUPPLIER_INVITATION_PRIV)

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

クローズ済ネゴシエーションの取消

この機能を使用すると、購買文書が作成される前に、すべてのステータスのネゴシエーションを取り消すことができるようになりました。参加依頼済および参加中のすべてのサプライヤに取消が通知されます。

現在、応答表示が「オープン」および「ブラインド」のネゴシエーションはクローズ前に取り消すことができます。また、応答表示が「封印」のネゴシエーションは、落札に進む前に取り消せます。ただし、次のような落札につながらないシナリオがあります。

  • ライブ・オークション前にモック・オークションを実行する場合
  • 予算に制約がある場合
  • ネゴシエーション済の品目が要求者側で不要になった場合
  • ネゴシエーションが応答を受信せずにクローズされたが、ネゴシエーションを延長する必要がない場合

これらのビジネス・シナリオでは、ネゴシエーションを取り消して、ネゴシエーション・プロセスが完了しないことをサプライヤに通知する必要があります。

クローズ済ネゴシエーションの取消

現在は、ビジネス・ニーズに基づいて、ネゴシエーション・ライフサイクル全体でネゴシエーションを取り消せるようになりました。

有効化のステップ

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

オファリング: 調達 オプションではなくなった開始バージョン: 更新24B

ヒントと考慮事項

この機能を使用するための考慮事項は次のとおりです。

  • ネゴシエーション・ライフサイクルの終了に達したため、次のステータスのネゴシエーションを取り消せません。
    • 完了、購買文書は作成されました
    • 修正済
    • ラウンド完了
  • 承認処理中のネゴシエーションを取り消すことはできません。まず承認を取り下げ、ネゴシエーションを編集してから続行する必要があります。
    • 承認処理中
    • 取下済
    • 落札承認は処理中
    • 落札取下げ

アクセス要件

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

  • サプライヤ・ネゴシエーションの取消(PON_CANCEL_SUPPLIER_NEGOTIATION_PRIV)

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

サプライヤが応答を送信したときに確認をEメール送信

サプライヤは、ネゴシエーション応答が正常に送信されたことを確認する通知を受信できるようになりました。新規Eメールおよびアプリケーション内通知が、応答を発行するサプライヤ担当に送信されます。Oracle Analytics Publisherテンプレートを使用して、ビジネス・ニーズに応じて通知のレイアウトおよびコンテンツを構成できます。

応答が送信されると、次のように確認メッセージが表示されます。

応答送信の確認メッセージ

サプライヤへの応答送信通知

サプライヤとのコミュニケーションを改善し、サプライヤの応答が受信されたことを信頼します。

有効化のステップ

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

オファリング: 調達 オプションではなくなった開始バージョン: 更新24B

「設定および保守」作業領域で、「ネゴシエーション形式の管理」タスクに移動します。

  • オファリング: 調達
  • 機能領域: ソーシング
  • タスク: ソーシング通知の管理

「ソーシング通知の管理」ページで、新しい通知「サプライヤへの応答送信済確認」が使用可能になり、RFIおよびRFQネゴシエーション・タイプに対してデフォルトで有効になります。業務の必要に応じて、「オークション」に対して有効にすることもできます。

新規タスクによるソーシング通知の管理

ヒントと考慮事項

  • 代理応答またはRESTから発行された応答に対する通知は送信されません。

主なリソース

アクセス要件

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

  • サプライヤ・ネゴシエーションの作成( PON_CREATE_SUPPLIER_NEGOTIATION_PRIV)
  • サプライヤ・ネゴシエーションの編集(PON_EDIT_SUPPLIER_NEGOTIATION_PRIV)
  • レスポンスの作成(PON_CREATE_SUPPLIER_NEGOTIATION_RESPONSE_PRIV)
  • レスポンスの編集(PON_EDIT_SUPPLIER_NEGOTIATION_RESPONSE_PRIV)
  • サプライヤ・ネゴシエーション応答の送信(PON_SUBMIT_SUPPLIER_NEGOTIATION_RESPONSE_PRIV)

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

オンライン・メッセージ通知に添付を含める

この更新では、サプライヤまたはUIのチーム・メンバーへのオンライン・メッセージに追加された添付も、受信者に送信されるEメールおよびアプリ内通知に含まれます。

Oracle Analytics Publisherテンプレートに基づくオンライン・メッセージ通知

ネゴシエーション関係者(サプライヤとチーム・メンバーの両方)は、アプリケーションにログインしなくても、Eメールのメッセージ添付に簡単にアクセスできます。

有効化のステップ

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

主なリソース

  • Update 23Bで入手可能なOracle Analytics Publisherを使用したオンライン・メッセージ通知の構成の新機能を参照してください。

アクセス要件

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

  • サプライヤ・ネゴシエーション・オンライン・メッセージの作成(PON_CREATE_ONLINE_MESSAGE_PRIV)
  • サプライヤ・ネゴシエーション・オンラインへの返信メッセージ (PON_REPLY_ONLINE_MESSAGE_PRIV)
  • サプライヤとしてのサプライヤ・ネゴシエーション・オンライン・メッセージの作成(PON_CREATE_ONLINE_MESSAGE_SUPPLIER_FACING_PRIV)
  • サプライヤとしてのサプライヤ・ネゴシエーション・オンライン・メッセージの応答(PON_REPLY_ONLINE_MESSAGE_SUPPLIER_FACING_PRIV)

これらの権限は、この更新よりも前から使用可能でした

500人を超えるサプライヤに対するネゴシエーションへの参加依頼

多くの組織、特に公共部門では、サプライヤが登録した製品およびサービスに基づいてソーシング・ネゴシエーションへの参加を依頼しています。一部の製品およびサービス・カテゴリには、500人以上のサプライヤが登録されています。カテゴリ・マネージャは、これらのカテゴリに登録されているすべてのサプライヤがネゴシエーションに招待されるようにする必要があります。

更新23Dの前は、500人のサプライヤのみを追加でき、UIに表示されていました。この更新では制限が拡張されるため、500人を超えるサプライヤを表示および追加できます。

規制要件を満たし、公正な市場機会を提供するために、必要に応じてすべてのサプライヤを招待できるようになりました。これらのサプライヤはUIおよびスプレッドシートで確認できます。

有効化のステップ

「設定および保守」作業領域で、「プロファイル・オプションの管理」タスクを検索します。プロファイル・オプションを検索して更新します。

プロファイル・オプション・コード: ORA_PON_INVITE_500_PLUS_SUPPLIERS

プロファイル・オプション名: 500人を超えるサプライヤの参加依頼

摘要: ネゴシエーションで500人を超えるサプライヤを追加および表示できます。

サイトのプロファイル・オプション値が「はい」に設定されると、UIから500人以上のサプライヤを検索および追加でき、REST Webサービスを使用してビジュアル・ビルダー・プラグインを使用したExcelスプレッドシートを使用して追加できます。

ヒントと考慮事項

追加できるサプライヤの数は、ネゴシエーション明細の数、明細詳細、Eメール・サーバー容量、環境内のネットワーク構成など、いくつかの要因によって異なる場合があります。サプライヤは、ネゴシエーションの公開後に参加依頼Eメールの受信に時間がかかる場合があります。制限を設定するための一般的なビジネス要件をテストし、それに応じてユーザーにガイダンスを提供することをお薦めします。ネゴシエーションでは2000を超えるサプライヤはお薦めしません。

アクセス要件

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

  • サプライヤ・ネゴシエーションの作成(PON_CREATE_SUPPLIER_NEGOTIATION_PRIV)   
  • サプライヤ・ネゴシエーション・テンプレートの作成(PON_CREATE_SUPPLIER_NEGOTIATION_TEMPLATE_PRIV)   
  • サプライヤ・ネゴシエーションの編集(PON_EDIT_SUPPLIER_NEGOTIATION_PRIV)

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

この更新で選択されたソーシング不具合修正

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

MACデバイスでの大規模ネゴシエーション用のネゴシエーション明細のインポート・テンプレートの使用

FBDI (ファイルベース・データ・インポート・プロセス)のネゴシエーション明細XLSMフォーマットのインポート・テンプレートをMACデバイスで使用できるようになりました。つまり、MAC OSを使用するコンピュータでテンプレートをダウンロードし、それを使用して、ネゴシエーション明細を大規模ネゴシエーションにインポートするためのCSV形式ファイルを生成できます。

Oracleリファレンス: 35124333

ネゴシエーション・ベース契約の作成時に正しい品目マスター組織の導出

この更新の前は、ネゴシエーションで基本契約を作成すると、調達BUのデフォルトの在庫組織セットは、契約に含まれる品目マスター組織になりました。ただし、BUのデフォルトの在庫組織は品目マスターと異なる可能性があるため、常にそうなるわけではありません。現在は、正しい品目マスター組織が調達BUのデフォルトの在庫組織から導出され、ベース契約の作成に使用されます。

Oracleリファレンス: 35348635

大規模ネゴシエーションの落札済見込みサプライヤに対する費用承認の承認

この修正後、大規模なネゴシエーションで落札結果に見込みサプライヤが含まれる場合は、落札の完了時に費用承認要求が正常に開始されます。

Oracleリファレンス: 35695195

有効化のステップ

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

見込みサプライヤを落札する場合は銀行口座が必要

銀行口座がないか無効な銀行口座がある見込みサプライヤに落札すると、落札を続行できないようにエラーが表示されます。サプライヤ管理者は、費用承認プロモーションのサプライヤのプロファイルを完了するための処理を実行し、購買オーダー・ライフサイクルのダウンストリームの影響を回避できます。

銀行口座のない見込みサプライヤが落札された場合のエラー表示

落札済見込みサプライヤが費用承認の準備ができていることを確認し、落札後に購買文書を正常に作成できるようにします。

有効化のステップ

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

オファリング: 調達

ヒントと考慮事項

この機能を使用するには、サプライヤ機能であるサプライヤを費用承認済にプロモートするには銀行口座が必要にオプトインする必要があります。

主なリソース

  • 詳しくは、サプライヤ・モデルのサプライヤを費用承認済にプロモートするには銀行口座が必要機能を参照してください。

アクセス要件

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

  • サプライヤ・ネゴシエーションの落札(PON_AWARD_SUPPLIER_NEGOTIATION_PRIV)
  • 所有者としてのサプライヤ・ネゴシエーションの落札(PON_AWARD_SUPPLIER_NEGOTIATION_OWNED_BY_SELF_PRIV)

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

費用分類

ルールの新しい条件による分類結果の拡張

ルール定義の作成時に設定できる条件を改善して、分類の効率を高めます。これらの機能改善には、キーワードの使用方法、デフォルト・カテゴリを割り当てる条件、トランザクションを作成および編集するための新しいドロワー・コンポーネント、拡張検索オプションの変更が含まれます。

ルールを定義するときに、特定の属性内ではなくすべての属性を含め、各トランザクション全体でキーワードまたは文字列をチェックする条件を追加できるようになりました。たとえば、明細摘要、品目摘要またはヘッダー摘要の一部となる各トランザクション内で油またはガソリンというキーワードを検索する場合は、次の例に示すように、属性「トランザクション・テキスト」を使用して条件を定義できるようになりました。

トランザクション・テキスト

カテゴリ予測は、キーワードの信頼度が低い、または一致するキーワードがないことに基づく場合があります。このような場合、予測信頼度が指定のしきい値より低い場合、または未分類トランザクションとトレーニング・データの間に一致するキーワードがない場合、デフォルト・カテゴリを割り当てるルールを作成できます。この例では、一致確度が30%を下回ると、購買タクソノミ属性に事務用品の定数値が割り当てられます。

信頼パーセント

新しい拡張検索機能を使用して、カテゴリを検索してルールの処理に追加します。カテゴリの拡張検索を使用すると、ルールで処理を定義しながら、カテゴリ値を簡単に検索して選択できるようになりました。

拡張検索

条件を作成または編集する改善された方法を使用して、データ入力の問題を排除します。条件を追加または編集すると、UIにドロワーが開き、属性、演算子および値を入力する簡単な方法が提供されます。

条件の作成および編集

条件の使用に対するこれらの機能拡張により、ルールの定義が簡単かつ柔軟になるため、分類予測に対する制御を強化できます。

有効化のステップ

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

主なリソース

  • Oracle Procurement Cloudドキュメントの費用分類の章を参照してください(Oracle Help Centerを参照)。

アクセス要件

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

  • 費用分類アプリケーションの管理(POI_ADMINISTER_SPEND_CLASSIFICATION_PRIV)
  • 費用分類バッチの管理(POI_MANAGE_SPEND_CLASSIFICATION_BATCH_PRIV)
  • 費用分類作業領域の表示(POI_SPEND_CLASSIFICATION_WORKAREA_PRIV)

調達契約

Adobe Acrobat Signによる契約の署名

Adobe Acrobat Signを使用して、企業契約で作成された契約文書の電子署名プロセスを管理できるようになりました。契約を署名用に送信する際に、オプションで「CC」受信者を追加し、署名順序を指定し、署名者ごとに非公開メッセージを追加できます。Acrobat Signによって署名用に文書が送信され、契約の「署名の管理」処理または「履歴」タブから進捗をトラッキングできます。すべての署名者が契約に署名すると、契約のステータスは自動的に「アクティブ」に設定されます。

署名用の契約の送信

Acrobat Signが使用可能となっている契約タイプから契約を作成した場合は、「パーティ」ページで1つ以上のパーティの担当者を署名者として指名し、その担当者の有効なEメール・アドレスを入力できます。契約のステータスが「署名待ち」である場合は、契約の編集権限を持つユーザーが、署名を求めるために、指名された署名者に電子メールで契約を送信できます。このような送信を行うユーザーは、管理ユーザーか、対象の契約に対してフル・アクセス権を持つユーザーです。署名用に契約を送信することを予定している契約作成者は、有効なEメール・アドレスを持っている必要があります。また、電子署名設定で指定されるAdobe Acrobat Signアカウントでユーザーとして設定されている必要があります。ユーザーのFusion Applications EメールIDは、Adobe Acrobat SignアカウントのEメールIDと一致する必要があります。「契約の署名」をクリックすると、統合UIでAcrobat Sign契約が作成されます。契約にタグの追加、署名者の追加、署名者へのプライベート・メッセージの追加などを行うことができます。

「契約パーティ」タブ

このタブには、署名順序を持つ内部パーティおよび外部パーティ用の署名者が追加されます。署名者を情報のみとしてタグ付けするオプションがあります。

電子署名プロセスを管理する

Acrobat SignからEメールを受信した署名者は、署名を行うか、署名を拒否することができます。署名者が署名を拒否すると、契約のステータスは、「署名用に送付済」から、以前の「署名待ち」に戻ります。契約の送信者は、契約に対して必要な修正を加えてから、署名のために契約を再送信できます。契約が署名用に送信された後、送信者は契約を変更してファイルを追加でき、すべての署名者に更新された文書が表示されます。送信者は契約を取り消すことができ、すべての署名者が取消に関するEメールを受信します。

契約検証

「契約」カテゴリの「文書」タブで追加された文書は、署名用に送信されるときに契約に追加されます。.pdf、.doc、.docx、.xls、.xlsx、.ppt、.pptx、.rtf、.txt、.htm、.html、.bmp、.jpg、.jpeg、.gif、.png、.tifおよび.tiffの形式は、Acrobat Signでサポートされています。他の文書タイプが追加されると、契約検証プロセスによってエラーになります。

電子署名履歴の表示

送信者は、「履歴」ページの署名リージョンで、契約の現在のバージョンの電子署名履歴を確認できます。

電子署名ステータスのトラッキング

このスケジュール済プロセスでは、電子署名プロセスが追跡され、結果契約ステータスが更新されます。すべての署名者が署名すると、このプロセスによってAcrobat Signから署名済契約文書が取得され、「文書」タブに格納されます。契約のステータスは「アクティブ」に設定されます。

このプロセスを実行することで、契約を署名用に自動的に送信できます。契約ステータスが「保留署名」で、AutoSendForSignature = 'Y' (フラグはWebサービスを使用して契約ヘッダーで設定)の場合、契約は署名用に送信され、契約のステータスは「署名用に送信済」に設定されます。

契約署名プロセスは、Adobe Acrobat Signを使用して効率的で簡単かつ安全になります。契約の生成から署名の追跡まで、署名プロセス全体を契約内で管理できます。

有効化のステップ

前提条件

  1. まず、Adobe Acrobat Signから直接ライセンスを登録し、取得する必要があります。
  1. ライセンスを取得したら、Acrobat SignのWebサイトで組織のアカウントを設定する必要があります。サイトに管理者アカウントを作成する必要があります。これは1回かぎりのアクティビティであることに注意してください。
  1. Acrobat Signで管理者アカウントに使用されるEメール・アドレスとパスワードを書き留めます。
  1. 契約アプリケーションで構成できる電子署名プロバイダは1つのみです。

Adobe Acrobat Signの構成

ナビゲーション→「設定および保守」→「電子署名の管理」

ソリューション・プロバイダとしてAdobe Acrobat Signを選択し、「接続」ボタンをクリックします。

Acrobat Signの構成

Acrobat Signログイン・ウィンドウが別のタブで開きます。管理者アカウントのEメール・アドレスとパスワードを入力し、「Sign In」ボタンをクリックします。

Acrobat Signのログイン

アクセス確認ページが表示されます。「Allow Access」ボタンをクリックします。

アクセスの許可

接続ステータス・ページが表示されます。

接続ステータス

「電子署名の管理」UIに戻り、「リフレッシュ」ボタンをクリックします。接続に成功すると、最終接続日およびエンド・ポイントURLが表示されます。設定プロセス中に障害が発生した場合は、「接続」ボタンをクリックして設定を再試行してください。

Acrobat Signの正常な接続

Adobe Acrobat Signの契約タイプの使用可能

ナビゲーション→「設定および保守」→「契約タイプの管理」

契約タイプの管理

  • 「概要」タブでの「署名が必要」の選択
  • 「電子署名」タブでの「電子署名使用可能」の選択
  • 「ソリューション・プロバイダ」としてのAdobe Acrobat Signの選択
  • Adobe Acrobat Signテンプレートの使用可能 - Adobe Signアカウントで構成されるテンプレート
  • Eメール・メッセージ - 意味のある値

署名タグが付加されている条件レイアウト・テンプレートを電子署名のデフォルトのテンプレートとして選択しなかった場合は、契約を署名用に送信する前に、署名に関するタグを「契約への署名」ページで手動で構成する必要があります。

ヒントと考慮事項

契約アプリケーションで一度に構成できるのは、単一の電子署名プロバイダのみです。Adobe Acrobat Sign、DocuSignまたはOneSpanを構成できます。

主なリソース

契約のEメール送信時における文書の添付

「Eメール」処理を使用して契約を送信する場合は、「添付」セクションを使用して他の文書を添付し、契約とともに送信できます。

Eメール契約

添付ファイルを追加するには、ファイルをこのウィンドウにドラッグするか、添付するファイルを参照します。

Eメールへのドキュメントの添付

添付は、.DOCX、.PDF、.JPG、.PPT、.CSV、.HTMLなど、様々なファイル・タイプにすることができます。

「プレビュー」ボタンを使用してEメールを送信する前に、契約をプレビューできます。これにより、「契約の編集」ページの「プレビュー」処理と同じ方法で契約のPDFが開きますが、Eメールに添付した文書のプレビューは含まれません。

すべてを1つのEメールにまとめて送信することで、受信者は、契約とそれに関連するドキュメントを確認するために必要な完全なコンテキストを取得し、Eメールに返信できるようになります。

有効化のステップ

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

契約検索からの承認履歴の表示

「承認待ち」ステータスの契約の承認進捗は、契約検索結果から直接チェックできます。契約ランディング・ページ、「テキストによる契約の検索」または「契約の管理」タスクから、「承認待ち」ステータスの契約にはステータス列のリンクが含まれます。

検索結果からの承認待ちリンク

「承認待ち」リンクをクリックすると、「承認者のレビュー」ページが開き、契約の承認階層を表示できます。

承認待ちリンクからの承認者のレビュー

この機能を使用すると、検索基準を入力して適切な契約に集中し、どこに滞留しているのかを確認して、それらを前進させることができます。

有効化のステップ

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

ヒントと考慮事項

契約ランディング・ページの「承認待ち」タブの「承認者のレビュー」列から承認進捗をモニターすることもできます。

契約承認通知の構成

契約承認通知の構成によって、ビジネス・ニーズに応じてコンテンツとレイアウトを設定できます。Oracle Business Intelligence (BI) Publisherレポートは、レイアウト変更用のRTFテンプレートおよびコンテンツ変更用のBIデータ・モデルを使用して変更できます。デフォルト・レポートで構成できるコンポーネントの一部を次に示します。

  • ロゴ: Eメール通知のブランド・ロゴを変更します。
  • 本文: 既存の属性を追加または削除し、新しい表を追加します。これには、任意の表、付加フレックスフィールドおよびアプリケーション・コンポーザ属性の標準属性が含まれます。
  • 処理ボタン: ボタンのテキストを変更します。
  • フッター・リンク: トランザクション・ページまたはワークフロー通知へのリンクを非表示にします。
  • スタイル: フォント・サイズ、色、表の境界などの書式設定を変更します。

承認通知の構成方法によっては、契約承認RTFテンプレート、サブテンプレートおよびデータ・モデルの1つ以上のコンポーネントを変更する必要がある場合があります。

Eメール通知

通知をカスタマイズして、ビジネスに関連する追加情報を含めることができ、より適切な意思決定が可能になります。他のFusionアプリケーションの通知と一致するように、ロゴの追加、属性のフォーマット、フォント、スタイルおよび色の変更を行えます。

有効化のステップ

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

オファリング: エンタープライズ契約 オプションなし: 更新24D

ヒントと考慮事項

24D以降、この機能はオプトイン制御されておらず、使用可能なデフォルト機能になります。

主なリソース

重要な処理と考慮事項

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

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

この項では、削除されるこのクラウド・サービスの機能を示します。

モジュール 削除される機能 削除予定 置換後の機能 置換時期 追加情報
共通テクノロジ

AIニュース・フィードの提案

未定

該当なし

該当なし

更新23Dでは、制限付提供機能であるAIニュース・フィードの提案はサポートまたは強化されなくなり、この機能の制限付提供プログラムに新しいお客様は受け入れられません。この機能を使用中の場合、無効にする必要があります。AIニュース・フィードの提案機能を無効にする方法の詳細は、Fusion Applications: AIニュースフィードの提案 - リリース23Dでのライフサイクルの終了(ドキュメントID 2969200.1)を参照してください。