次の表の機能は、元々はオプト・インとして提供されましたが、将来の更新で、使用可能にするためのオプト・インは必要なくなります。列Cに示すように、まだ追加の設定または構成をいくつか実行する必要がある場合があります。この将来の「オプト・イン失効」の事前通知は、これらの変更に対応する計画を立てる際にお役立てください。オプト・インが失効すると、上の表に機能が記載されます。
重要なノート: これらの機能をすでに有効にしている場合は、それ以上のアクションは必要ありません。
(A) | (B) | (C) | |||
---|---|---|---|---|---|
機能 | モジュール |
オプト・インUIで有効にする *必要がある* 機能、 最初に提供された時期: |
オプト・インUIで有効にする *必要がない* 機能、 開始時期: |
エンド・ユーザーに対して有効化する必要がある処理がまだあるかどうか | |
いいえ、 使用準備が完了して 提供されます |
はい、 引き続き顧客アクションが 必要です |
||||
更新24A | |||||
バック・トゥ・バック・フローで出荷日を変更する際の後処理日数の追加 | サプライ・チェーン・オーケストレーション | 24A | 24C | (1) | |
サプライ・チェーン・オーケストレーションでの供給または需要の更新後の処理の改善 | サプライ・チェーン・オーケストレーション | 24A | 24B | (1) | |
保守費用に間接材料費を含める | 原価管理 | 24A | 24C | ||
再設計されたページでの保管場所および保管棚の管理 | 在庫管理 | 24A | 24C | (2) | |
更新23D | |||||
購買オーダーが外注加工フローで準備できるまで製造からの変更を保留 | サプライ・チェーン・オーケストレーション | 23D | 24D | (1) | |
拡張ユーザー・インタフェースを使用した積上原価情報の検証 | 原価管理 | 23D | 24B | (2) | |
製造および保守作業オーダー・ピッキング要求の倉庫管理システムとの統合 | 在庫管理 | 23D | 24B | ||
棚入時の転送オーダーのロットおよびシリアル番号のデフォルト設定 | 受入 | 23D | 24B | ||
複数の受入明細の受入日の同時更新 | 受入 | 23D | 24B | ||
トランザクション日を使用した財務オーケストレーション・フローの識別 | サプライ・チェーン財務オーケストレーション | 23D | 24B | (2) | |
更新23C | |||||
「サプライ・チェーン・オーケストレーション」作業領域を使用した供給文書の同期 | サプライ・チェーン・オーケストレーション | 23C | 24A | (1) | |
バック・トゥ・バック販売オーダーの手動予約の表示 | サプライ・チェーン・オーケストレーション | 23C | 24A | (1) | |
複数の原価組織を同時に検証およびクローズ | 原価管理 | 23C | 24A | (1) | |
外部認証システムを介したシングル・サインオンを使用したインベントリ電子レコードの署名 | 在庫管理 | 23C | 24A | ||
転送オーダーの分割出荷およびグローバル購買オーダーの部分受入における転送価格の再計算 | サプライ・チェーン財務オーケストレーション | 23C | 24A | (2) | |
直接出荷における改善されたOracle Payables請求書照合フローの使用 | サプライ・チェーン財務オーケストレーション | 23C | 24A | (1) | |
更新22D | |||||
拡張された原価処理による購買オーダー・トランザクションの取得原価の計算 | 原価管理 | 22D | 24B | (2) |
元はオプト・イン・ユーザー・インタフェースから有効にしていた機能
次の表に示す機能は、最初は無効の状態で提供されていました。つまり、エンド・ユーザーがこの機能を有効にするには、オプト・インUIでのアクションが必要でした(さらに、追加の設定または構成ステップが必要になることもありました)。列Aは、これらの機能がいつ最初に提供されたかを示しています。
列Bに示されている更新バージョン以降、これらの機能はオプト・インUIで有効にする必要がなくなります。ただし、列Cに示すように、ユーザーに機能を使用可能にするために、まだ追加の設定または構成ステップを実行する必要がある場合があります。有効にするために、顧客による追加のアクションが引き続き要求される場合は、機能名をクリックすると詳細情報が表示されます。
重要なノート: オプト・インUIでこれらの機能をすでに有効にしている場合は、それ以上のアクションは必要ありません。
(1)小規模UIまたはプロセスベースの機能: これらの機能は、通常、フィールド、検証またはプログラムの軽微な変更で構成されます。したがって、ユーザーに対する潜在的な影響は最小になります。
(2)大規模UIまたはプロセスベースの機能: これらの機能の設計は、より複雑になります。したがって、ユーザーに対する潜在的な影響は高くなります。つまり、これらの機能は顧客の受入れテストに重点を置く必要があります。