リリース11iから12.2へのアップグレード・ガイド
E51767-01
目次
前へ
次へ
| Oracle E-Business Suite リリース11iから12.2へのアップグレード・ガイド E51767-01 | 目次 | 前へ | 次へ |
この付録では、アップグレードが既存のFinancialsおよびProcurement製品に及ぼす影響を、機能変更が日常業務に及ぼす影響に重点を置いて説明します。この付録はFinancialsおよびProcurement製品ファミリの製品名のアルファベット順に構成されています。
この付録の内容は次のとおりです。
アプリケーションのアップグレードにより、Oracle E-Business Suiteシステムの技術面と機能面の両方が変更されます。テクノロジ・スタックとファイル・システムが変更されるのみでなく、アップグレード後の既存製品の動作およびルック・アンド・フィールに影響する特定の変更も開始されます。これらの機能変更は、日常業務における製品の使用方法に影響します。
注意: この付録では、アップグレードで既存製品が変更される方法の一部を説明します。ここでは、My Oracle Supportの製品固有のリリース内容文書 (RCD) およびTOIに含まれる、リリースR12に付属の新規機能および製品に関する情報を確認していることを前提としています。
この付録では、アップグレードの機能面の説明がFinancialsおよびProcurement製品ファミリの製品別に構成されています。
注意: FinancialsおよびProcurement製品のアップグレードの詳細は、『Oracle Financials and Oracle Procurement Functional Upgrade Guide: Release 11i to Release 12』を参照してください。
この項で説明する製品に対する変更は、FinancialsおよびProcurement製品に影響します。アップグレード開始前に、FinancialsおよびProcurementアプリケーションの担当者は、関連する変更内容に対応できるように計画を作成する必要があります。
この項では、アップグレードに伴うOracle Advanced Collectionsの変更点を説明します。
注意: 詳細は、『Oracle Advanced Collections Implementation Guide』を参照してください。
リリースR12では、Advanced Collections設定データの入力および保守に使用する新規ユーザー・インタフェースが導入されています。
リリースR12では、Advanced Collections専用のテリトリ管理アプリケーションに回収使用が導入されています。回収の「営業使用」テリトリを回収の「回収使用」テリトリに移動するために手動テリトリ移行スクリプトが作成されました。テリトリ管理を使用して顧客に回収エージェントまたはグループを割り当てる場合、この移行は必須です。
「IEX: テリトリ割当」コンカレント・プログラムは、新しい回収使用に対応するためにリライトされました。詳細は、『Oracle Territory Management User Guide』および『Oracle Advanced Collections Implementation Guide』を参照してください。
このリリースでは、ReceivablesのナビゲータにAdvanced Collectionのメニューが表示されます。自動化されたスクリプトがアップグレード中に実行され、回収担当からリソースが作成されます。スクリプトで適切なリソースを判別できない場合は作成されません。アップグレード後に「回収担当」ナビゲータ・メニュー・ページが機能しないことが判明した場合は、リソースを手動で作成してください。
Advanced Collectionsを使用すると、システム・レベルとは別に営業単位別に異なる戦略レベルを定義できます。戦略レベルはパーティ・レベルで上書きすることもできます。Advanced Collectionsは、督促状別の営業単位および戦略別の営業単位に関する設定をサポートしています。
Advanced Collectionsは、期限超過日数方法とは別に段階的督促方法をサポートしています。また、期限超過日数計画の作成中、「対象 現行」、「係争項目を含む」、「未消込入金を含む」および「支払猶予」オプションを指定できます。
回収マネージャ機能は、特定のアカウントのソートおよびフィルタリングを可能にするOAフレームワークを使用してリライトされています。
新しいスコアリング・エンジンが請求書レベルで延滞前ステータスでシードされています。また、すべての請求書ではなく過去60日以内にクローズされた請求書のみを処理するクイック・スコアリング・エンジンも追加されています。スコアリング・エンジンの設定を検証するバッチ・プログラムを実行するのではなく、「回収スコアリング管理」ウィンドウから特定のアカウントについてスコアリング・エンジンをテストできます。
Advanced Collectionsでは、作成予定の作業項目を編集できます。現在の戦略内の作成予定の作業項目は、新しい作業項目を作成せずに新しい待機前/待機後および回収担者を使用して上書きできます。
この項では、アップグレードに伴うOracle Assetsの変更点を説明します。
新しい補助元帳会計アーキテクチャのアップグレードにより、Oracle Assetsが次のように変更されます。
注意: 『Oracle Subledger Accountingインプリメンテーション・ガイド』および『Oracle Financialsインプリメンテーション・ガイド』を参照してください。
資産台帳での取引と各取引に関連する会計明細は、アップグレード中にユーザー指定の期間数についてSubledger Accountingに移行します。当期間減価償却の会計がアップグレードされるのは、その期間の減価償却が実行済で、期間がオープンされたままの場合のみです。アップグレード後は、SLAのアップグレード後プロセスを実行して、前年の取引データの会計をアップグレードできます。詳細は、付録Gの「Assets」を参照してください。
新規プロファイル・オプション「FA: ワークフロー勘定科目生成の使用」の値は、アップグレード中に「Yes」に設定されます。ワークフロー設定の現行のカスタマイズを分析する必要があります。ワークフローでルールを使用して資産取引のコード組合せを生成する必要がある場合は、次の2つのオプションがあります。
Subledger Accountingの勘定科目導出ルールにカスタム・ルールを再実装し、プロファイル・オプションを値「No」に設定します。
ワークフロー・ルールをそのまま使用します (デフォルト) 。
ワークフロー・ベースの勘定科目ジェネレータをカスタマイズしておらず、コード組合せの生成にSubledger Accountingの勘定科目導出ルールを使用する場合は、アップグレード後にプロファイル・オプションを値「No」に設定します。
「仕訳の作成」は「会計の作成」で置き換えられます。
「勘定ドリルダウン・レポート」は、新しい補助元帳会計レポート「勘定科目分析」で置き換えられます。
「仕訳ソース」と「仕訳カテゴリ」の設定は「資産台帳管理」設定フォームに表示されなくなり、「補助元帳会計」に表示されるようになりました。
「資産カテゴリ」設定フォームにある、全カテゴリと台帳の組合せ用の「減価償却費勘定」および「ボーナス減価償却費勘定」は、単一セグメント勘定科目値から勘定科目全体の組合せにアップグレードされます。
「資産台帳管理」フォームでの会社間勘定の設定は、会計設定の「会社間/会社内」設定で置き換えられます。アップグレード時には、関連元帳の移行後の設定を検討する必要があります。
「FA: 一括追加に控除対象外消費税を含む」プロファイル・オプションは廃止され、Subledger Accountingの「会計後プログラム」で置き換えられています。これらのプログラムにより、「一括追加作成」プログラムの対象となるPayablesからAssetsへの全適格明細の設定が管理されます。
AssetsにインタフェースするOracle Payablesからの請求書配分は、「請求書明細番号」を表示するようにアップグレードされます。
取引約定および出資法であるギリシャの付加フレックスフィールドに格納された情報は、「資産ワークベンチ」の名前付きフィールドにアップグレードされます。
この項では、アップグレードにおけるCash Managementの変更点を説明します。詳細は、第1章の「製品間機能」の「Legal Entity Configurator」を参照してください。
新しい集約的銀行口座モデルにより、Oracle Payables、Oracle Receivables、Oracle Payroll、Oracle Cash ManagementおよびOracle Treasuryで当方銀行口座を1箇所で定義および管理できます。各当方銀行口座の所有権は単一の法的エンティティに付与され、使用権は1つ以上の組織に付与されます。また、銀行と支店はOracle Trading Community Architecture (TCA) に移行し、パーティとして定義されます。
銀行支店は、次の属性が同一の場合にマージされます。
銀行番号
金融機関タイプ
国 (NULLの場合はデフォルトの国設定)
銀行名
税金参照
アップグレード中に、Cash Managementにより各当方銀行口座の所有権が1つの法的エンティティに付与されます。所有する法的エンティティは、その口座をリリース11iで所有していた組織から導出されます。
リリース11iでは、銀行口座は単一の営業単位で使用され、これらの口座の保守を制御するために営業単位セキュリティが使用されていました。新しいモデルでは、複数の営業単位が銀行口座にアクセスできますが、所有者は単一の法的エンティティとなります。そのため、銀行口座の作成と更新を保護する銀行口座保守セキュリティは、法的エンティティ・レベルに移動しました。新しい「セキュリティ・ウィザード」を使用すると、1つ以上の法的エンティティが所有する銀行口座を作成および変更するためのアクセス権を、各職責に付与できます。
アップグレード中には、Cash Managementにより、リリース11iで銀行口座フォームへのアクセス権が付与されていた職責ごとに、銀行口座保守セキュリティが設定されます。これらの職責ごとに、リリース11iで職責にアクセス権が付与されていた組織から法的エンティティが導出されます。職責には、この法的エンティティの銀行口座保守セキュリティが付与されます。
調整処理をより柔軟に制御するために、システム・レベル (営業単位) でシステム・パラメータとして定義に使用していた多数のオプションが、銀行口座レベルに移動しました。これらの制御を銀行口座レベルに置くことで、手動と自動の両方の調整処理を銀行口座とその用途に応じて構成できます。また、リリース11iの残りのシステム・パラメータ・オプションおよび制御は、このリリースでは法的エンティティ・レベルで定義します。
Contract Lifecycle Management (CLM) は、連邦政府の顧客を対象としたこのリリースの新製品です。従来の連邦購買を使用していた顧客は、リリース12.2でCLMにアップグレードできます。
Oracle E-Business Suite Taxは、源泉徴収税、インドの税金、およびLatin Tax Engineソリューションで処理される税金を除き、標準的な調達-支払および受注-入金取引の税金を対象としています。これは取引ベースの税金を管理するための単一ポイント・ソリューションをベースとしており、1つのアプリケーション・インタフェースを介してすべてのE-Business Suiteビジネス・フローに税務サービスを均一に提供します。
Oracle E-Business Suite Taxにより、次のOracleリリース11i税金ソリューションが置き換えられます。
受注-入金 - グローバル税金エンジン
調達-支払 - 自動税金計算
調達-支払 - ブラジル買掛管理/購買管理
一般会計 - General Ledger自動税金計算
この完全に自動化されたアップグレードにより、リリース11iの税金設定に対する現行の投資が失われることはなく、ビジネスに最も適したペースで新機能を実装できます。その他のデータは、事前定義済のネーミング方法を使用して自動的に作成されます。
注意: 『Oracle Financials and Oracle Procurement Functional Upgrade Guide: Release 11i to Release 12』を参照してください。
現行アプリケーションでは、通常、税金機能は稼働アプリケーションにより実行されます。たとえば、買掛管理担当は、Payablesで税務処理基準の定義を実行します。リリースR12では、税金設定の職責を税金マネージャに切り替える必要があります。それぞれの税務処理基準が関連する取引とイベントはすべて、Oracle E-Business Taxにより処理されます。
E-Business Taxのアップグレードにおける製品固有の影響の詳細は、次の該当製品に関する項を参照してください。
この項では、Oracle Financials for the Americasの変更点を説明します。
ラテン・アメリカのReceivablesの銀行振替機能では、標準のOracle Receivables会計以外の会計仕訳の金額が格納されます。これらの金額は、文書が回収のために銀行に送付される時点と、顧客からの回収情報が銀行により送付される時点で格納されます。Subledger Accounting、銀行連結および法的エンティティからの指揮命令も、この機能に影響します。
いくつかのフォームが変更され、「営業単位」フィールドが組み込まれました。「銀行支店」および「銀行口座」フォームのグローバル付加フレックスフィールドは、「グローバル入金方法勘定」フォームの標準フィールドとして使用できます。
このリリースのSubledger Accountingで口座データを作成するには、「売掛管理」職責を使用して「標準要求発行」 (SRS) 要求画面からコンカレント・プログラム (「会計の作成」) を実行します。これにより、銀行振替回収文書など、すべてのReceivables取引について補助元帳会計が作成されます。「売掛管理」職責でデータを表示してGeneral Ledgerに転送できます。
Latin Tax Engineは、このリリースのE-Business Taxで置き換えられていません。ただし、リリース11iのLatin Tax Engineは、E-Business TaxとTrading Community Architectureの設定の一部を使用するようにアップグレードされます。
「製品オプション」ページ・フローでE-Business Taxにアップグレードされるオプションは、Receivablesの「システム・オプション」ウィンドウの税金システム・オプション (「課税方法」、「税金コード」、「内税使用」フラグ) および税金システム・オプション/端数処理オプション (「報告通貨」、「精度」、「最小計上可能単位」、「上書きの許可」および「端数処理規則」) です。
リリース11iでは、Trading Community Architectureの顧客、顧客アカウントおよび顧客アカウント・サイト使用にデフォルトの税金コードと税金端数処理ルールを割り当てることができます。顧客レベルでの設定は、Oracle E-Business Taxの「パーティ税金プロファイル」ページ・フローに移動しました。このページ・フローは「顧客」ページ・フローにリンクされています。顧客アカウントおよび顧客アカウント・サイト使用レベルでの設定は、下位互換性を保つために保持されています。
ラテン事業所、会計分類別税金例外および品目別税金例外を設定するLatin Tax Engineの設定フォームでは、事業所要素の選択と表示に参照コードのかわりに新しいTrading Community Architecture地理モデルを使用します。
Inventoryに品目カテゴリ・セット (FISCAL CLASSIFICATION) が作成され、在庫品目のグローバル付加フレックスフィールド (GDF) 属性「会計年度分類」の値が品目に対するカテゴリ割当としてアップグレードされます。
「メモ明細」フォームのGDF属性 (「会計年度分類コード」) は無効化され、値は同じフォームの「製品カテゴリ」属性に移行します。
「税金コード」フォームに「税制コード」、「税金」および「税金ステータス・コード」フィールドが追加されます。Latin Tax Engineの「税カテゴリ」属性値は、「税金コード」フォームの「税金」属性の値になります。
Latin American Extended Withholdingには「会社源泉徴収評価の設定」という設定ステップがあり、そこで既存の法的エンティティを選択し、1つ以上の源泉徴収タイプの源泉徴収義務者として定義できます。リリース11iでは、選択項目としてHR事業所が表示されました。このリリースでは、法的エンティティは新しい法的エンティティ・フローでアップグレードまたは定義され、「ラテン・アメリカ会社評価」フォームに選択項目として表示されます。この変更は会社源泉徴収の設定にほとんど影響しません。
複数組織アクセス管理では、ラテン・アメリカのプロファイル・オプションJLBR_PAYMENT_ACTIONを名前付き列にアップグレードする必要があり、これはブラジル向けOracle Receivablesの利息ソリューションに影響します。このプロファイル・オプションの値は、Receivablesの「システム・オプション」フォームの「支払処理」GDF属性に移動しました。
「仕訳データの入力」フォームのGDF属性「サード・パーティID」の値は、同じフォームの属性「サード・パーティ」にアップグレードされます。
Payablesの「請求書ワークベンチ」フォームのGDFの「文書タイプ」属性の値は、同じフォームの属性「主用途」にアップグレードされます。
次の機能は廃止されました。
ブラジル会社情報 - 「会社」フォームを使用して定義したブラジルの会社は、営業単位の法的エンティティの下の報告組織としてアップグレードされ、このフォームは廃止されます。報告組織の定義には、このリリースで導入されたLegal Entity Configuratorを使用します。
ブラジルJLBRによる支払バッチ名プロファイル (および関連ロジック) の自動移入 - このリリースでは、支払バッチの概念が変更されています。また、支払バッチを順次かつ自動的にネーミングするという法的必要条件はありません。
この項では、Oracle Financials for the Asia/Pacificの変更点を説明します。
リリース11iでHR組織に関連するHR事業所として定義された名称や税金登録番号などの法的エンティティ情報は、同じ法的エンティティ定義を使用してこのリリースの集約的法的エンティティ・モデルに作成されます。新しい法的エンティティ情報を定義したり、アップグレード後に作成された定義を変更するには、新しいLegal Entity Configuratorを使用する必要があります。
Payablesの「税金コード」ウィンドウまたはReceivablesの「VAT税」ウィンドウで定義されていた源泉徴収なしの税金コード設定 (付加価値税 (VAT) 、物品サービス税 (GST) 、仮払税および仮受税など) は、Oracle E-Business Taxモデルにアップグレードされます。新しい税金を定義したりアップグレードされた税金を変更するには、新しい制度-レートを使用する必要があります。
法的所在地でない事業所とそれぞれの税金登録番号は、税金レポート作成用に引き続きHR事業所として定義できます。源泉徴収税コードは、引き続きOracle Payablesの「税金コード」ウィンドウを介して定義します。
「政府書式請求書タイプ」は、Oracle E-Business Taxの文書サブタイプ分類モデルにアップグレードされます。文書サブタイプは、Payablesの「請求書ワークベンチ」とReceivablesの「取引ワークベンチ」で「税金」ウィンドウを使用して入力できます。「ソースおよびタイプ関連」ウィンドウは廃止になりました。
次の変更は、リリース12.1.1用の中国の会計ソフトウェア・データ・インタフェース標準ソリューションに適用されます。
リリース11iの「システム・オプション」ウィンドウで各法的エンティティに特定の貸借一致セグメント値を割り当てるプロセスは、リリース12.1.1から削除されました。そのため、「会計設定マネージャ」を使用して、同じように法的エンティティに対して貸借一致セグメント値の割当を実行する必要があります。
新しい付加フレックスフィールド品目「仕訳の入力:明細」がリリース12.1.1の「付加フレックスフィールド割当」ウィンドウに追加されています。この品目を使用すると、仕訳明細でキャッシュ・フロー項目のマーク付けに使用される、付加フレックスフィールド「仕訳の入力:明細」にコンテキスト列と属性列を指定することができます。
リリース11iでは、「キャッシュ・フロー項目マッピング」ウィンドウは、対応するキャッシュ・フロー項目を含む、Payables請求書カテゴリ、Receivable取引タイプおよびReceivableアクティビティをマップするために使用されます。これに対しリリース12.1.1では、「キャッシュ・フロー項目マッピング」ウィンドウの機能は、サポートする参照値とキャッシュ・フロー項目との間のマッピングを定義する目的に変更されました。
この項では、Oracle Financials各国共通機能の変更点を説明します。
リリースR12では、相殺請求機能が廃止され、Oracle Financials Common Modules製品に導入された新しいネッティング・ソリューションで置き換えられています。アップグレードにより設定が移行しますが、取引は新しいソリューションに移行しません。
注意: 詳細は、この付録の「Financials Common Modules」を参照してください。
このリリースでは、利息請求書機能が廃止され、Oracle Receivables製品に導入された新しい延滞手数料機能で置き換えられています。
注意: 詳細は、この付録の「Receivables」を参照してください。
Oracle Advanced Global Intercompany System (AGIS) は、企業による会社間処理の合理化と会社間取引の容易な消込を可能にする新しいモジュールです。リリース11iのGeneral Ledgerに用意されていたグローバル会社間システム (GIS) 機能は、AGISで置き換えられています。
すべての設定データと取引データは新しいデータ・モデルに移動し、グローバル会社間システムのOracleフォームはすべてブラウザベースのユーザー・インタフェース・ページで置き換えられています。
変更点は次のとおりです。
子会社は会社間組織で置き換えられています。会社間組織は取引先を表し、Advanced Global Intercompany Systemでの取引の起動側および受取者として使用できます。
付与ベースのセキュリティ・モデルの一部として、会社間取引先が職責ではなくユーザーにマップされます。1人のユーザーに対して、ログインに使用した職責に関係なく多数の異なる会社間取引先へのアクセス権を付与できます。
GISの取引タイプは、新しい会社間システム取引タイプにアップグレードされます。
GISで設定した会社間勘定は、新しい会社内貸借一致ルールとしてアップグレードされます。GISで設定した自動会計ルールはアップグレードされず、新しいSubledger Accountingの「取引勘定科目ビルダー」で設定する必要があります。
GISの新規取引と完了取引はすべて、AGISの取引バッチとしてアップグレードされます。通常は、GIS取引ごとにバッチが1つ作成されます。
リリース11i GISのプロファイル・オプションは廃止になり、アップグレードされません。すべてのオプションはAGISの「システム・オプション」ページで使用できます。
リリース11iのOracle Financialsには、3つのネッティング・ソリューションがありました。Oracle Public Sector Financials Internationalの単一サード・パーティ、Oracle Financials for Europeの相殺請求およびOracle U.S. Federal Financialsの売掛管理および買掛管理ネッティングです。この3つはいずれも、このリリースではOracle Financials Common Modulesのネッティング機能で置き換えられています。
リリース11iの相殺請求および売掛管理および買掛管理ネッティング機能に関連する設定は、次のように移行します。
既存の顧客および仕入先関連は保持され、基本契約という新しいエンティティが作成されます。
既存の顧客および仕入先関連は保持され、基本契約という新しいエンティティが作成されます。
この項では、Oracle Financials for Europeの変更点を説明します。
EMEA付加価値税 (VAT) レポート機能により、リリース11iのEMEA用VATレポート・ソリューションがこのリリースに移行します。この移行により、既存の国固有の制限がある場合は解消され、場合によってはパフォーマンスが向上します。
リリース11iには、データ要件の類似する国固有レポートが多数ありました。EMEA VATレポートにより、これらのレポートが連結され、XML Publisherテクノロジを実装する1回の抽出から必要なデータが取得されます。すべてのレポートはテンプレートに変換されるため、特定の書式要件に対する柔軟性が向上します。
Oracle E-Business Taxの導入に伴い、税金定義の基礎がリリース11iから変更されています。EMEA VATレポートには、レポート要件用にE-Business Taxが組み込まれるようになりました。
E-Business Taxでの税金レポートでは、法的報告組織の属性「税金登録番号」 (TRN) がきわめて重要になります。TRN別の集中レポート構成により、配賦ルール、VAT台帳および他の構成属性の定義が法的レポート・エンティティと呼ばれる1つの設定に連結されます。
また、このリリースには、取引履歴の適正なレポート作成をサポートするために、元帳別または貸借一致セグメント別のレポート作成オプションが用意されています。このレポートを会計エンティティ・オプション別に使用するには、適用可能なVAT関連設定を導出できるようにエンティティをTRNにマップする必要があります。
アップグレードの結果、任意の時点で法的エンティティを追加割当することで、1つのGRE/法的エンティティのみを含む会計設定から複数のGRE/法的エンティティを含む会計設定に移行できます。レポート期間中に (税金レポートの場合は暦年など) にアップグレードされた会計設定に法的エンティティを追加すると、法的エンティティ・パラメータにより実行されるレポートでは法的エンティティの完全な履歴は戻されません。法的エンティティ別のレポート機能により、これらのシナリオで取引セットのレポートを作成できます。
このリリースでは、単一のFinancials各国共通 (JG) 表が導入されており、税金レポート元帳 (TRL) や他のコア表から取得された税金関連データが格納されます。このエンティティのデータは、TRLにアクセスする唯一のプロセスである選択プロセスを介して取得されます。抽出により、このJGエンティティからデータが取得されます。これにより各抽出のパフォーマンスが拡張され、TRL関連の全ビジネス・ロジックが選択プロセスのみにカプセル化されます。
取引について税詳細とともに税金以外の詳細をレポートする抽出がいくつかあります。TRLで処理されるのは税金詳細のみであるため、これらはPayablesとReceivablesのコア・アプリケーション表に直接基づきます。ただし、これらの非JG (非TRL) 抽出も、正しいデータを導出するための設定構成に基づいています。
配賦は独立したプロセスであり、ベルギーとポルトガルの配賦に関するリリース11iのビジネス・ロジックがカプセル化されています。
最終レポートも独立したプロセスです。最終レポート後は、単一JG表のデータを変更できません。これにはE-Business Taxとのインタフェースが提供されており、取引がE-Business Taxリポジトリ内で最終レポート済として更新されます。このプロセスとJG税金エンティティは、暫定レポートと最終レポートのフレームワークを提供します。このプロセスには、リリース11iの宣言機能が含まれています。
次の付加フレックスフィールドが代替アプローチで置き換えられています。
インド品目
インド資産のブロック
インド入金
インドRMA入金
仕入先に戻る (インド)
追加明細属性情報
インド支払情報
インド組織情報
インド配分
インドVAT
インド参照コード
インドTDSの当初請求書
Oracle General Ledgerは、国際企業と共有サービス・センターをサポートするために大幅に機能拡張されました。この変更により、企業は情報と設定に関して高水準のセキュリティを維持しつつ、処理効率を最大化できます。
複数のレポート要件に合せた同時会計を実行できます。1つの職責で複数の元帳間や法的エンティティ間のデータを設定、アクセスおよび処理できるようになることからも、処理効率が向上します。さらに、一括配賦や財務諸表生成プログラム (FSG) レポートなどのGL定義および設定定義について、特定のユーザーによる表示や更新、または処理での使用を制限できるため、組織全体での共有と保護が容易になります。
ローカライズ版でのみ使用可能だった多数のグローバル機能がGeneral Ledgerに組み込まれたため、より多数の顧客が利用できるようになっています。
General Ledger関連の用語が次のように変更されていることに注意してください。
「会計帳簿」は「元帳」で置き換えられています。
これは単なる用語変更です。リリース12では、すべての会計帳簿オプションを元帳オプションと呼びます。アップグレードでは、リリース11iの設定がすべて保持されます。
「複数報告通貨」が「報告通貨」で置き換えられています。
報告会計帳簿が報告通貨で置き換えられています。主要会計帳簿に割り当てられていた報告会計帳簿は、主要元帳に割り当てられている報告通貨に自動的にアップグレードされます。複数報告通貨の換算オプションは、すべて報告通貨定義の一部として保持されます。
グローバル会社間システム (GIS) は、拡張グローバル会社間システム (AGIS) で置き換えられています。
新しい「会計設定マネージャ」により、財務アプリケーション間で共有される共通会計管理コンポーネントの会計関連設定が簡素化され、集中化されます。中央の事業所から法的エンティティと会計コンテキスト (法的エンティティの会計を実行する元帳や報告通貨など) を定義できます。
「会計設定マネージャ」を使用すると、各地で操業している国際企業は複数の元帳と報告通貨を使用することで複数のレポート要件を満たすことができます。
すべての会計帳簿は、会計設定の元帳にアップグレードされます。
アップグレードにより、拡張データ・アクセスとデータ・セキュリティ・ポリシーを作成しやすいように、アップグレード済元帳用のデータ・アクセス・セットが作成されます。
標準見越などの補助元帳会計処理基準は、アップグレード済の全元帳に自動的に割り当てられます。
補助元帳会計処理基準により、Subledger Accountingを介してGeneral Ledgerを補助元帳と統合できます。
再評価、クローズおよび変換の副追跡オプションが合理化されています。
報告会計帳簿に関するリリース11iの一部のオプションは、報告通貨定義に移動しました。たとえば、多数のMRCプロファイル・オプションが、報告通貨定義に移動しています。
主要会計帳簿と報告会計帳簿に対して個別に定義されていた多数の会計帳簿オプションは、合理化されています。また、報告通貨用の元帳オプションの多くは、主要元帳からデフォルト設定されます。MRC会計帳簿のアップグレード内容は、現行の構成とユーザー指定の変換オプションに応じて異なります。
複数の主要会計帳簿を持つ単一の転記用会計帳簿は、同じ副元帳を共有する複数の主要元帳にアップグレードされます。
期間レートは日次レートで置き換えられています。
General Ledgerでは再評価テンプレートが変更され、アップグレード前は期間レートを使用していたテンプレートに、対応する日次レートを使用するようになりました。ユーザーの介入は不要です。
再評価セットは、共通勘定体系を共有する元帳間で使用できます。アップグレード後のテンプレートを使用して再評価を実行する前に、副追跡セグメントが関係する再評価セットについて、その副追跡セグメントの入力が必要になる場合があります。
財務諸表生成プログラム・レポート用のレポート・レベル通貨とランタイム通貨は、元帳通貨を表す必要があります。統計残高のレポートが必要な場合は、行レベルまたは列レベルでSTAT通貨を使用するようにレポート定義を変更するか、STAT通貨の通貨管理値を使用します。
このリリースでは、Oracle Global Accounting Engine機能が廃止になりました。Global Accountingの既存の設定オプションとすべての会計データの両方が、Oracle Subledger Accountingに移行しています。
この項では、Oracle Internet Expensesの変更点を説明します。
Internet Expensesでは、一意の親識別子を使用して新しい親明細を作成することで、項目化経費明細の親子関係を表現できます。
Oracle Paymentsとの統合により、暗号化機能を利用できます。クレジット・カード取引データは、Paymentsのセキュア・データ支払中央リポジトリに移動されました。詳細は、この付録の「Payments」を参照してください。
日当とマイレージの取引データは移行しません。ただし、アップグレード前に存在していたデータはそのまま残ります。マイレージと日当の設定データは自動的にアップグレードされます。
アップグレード前に作成された経費精算書には、Oracle Internet Expensesミニパック (11i.OIE.K) より前の書式で情報が表示されます。新規に作成する経費精算書では、新規ユーザー・インタフェースを使用します。
Oracle E-Business Taxとの統合が税金のアップグレードに直接的な影響を及ぼすことはありません。税金明細はOracle Payablesを介して実行されます。詳細は、Oracle Paymentsのマニュアルを参照してください。
Oracle iPaymentはこのリリースで廃止になり、Oracle Paymentsで置き換えられています。詳細は、この付録の「Payments」を参照してください。
この項では、Oracle iProcurementの変更点を説明します。
Oracle iProcurementでは、グローバル包括基本契約 (GBPA) に格納されるコンテンツへのオンライン・オーサリング機能を、カタログ管理者に提供します。既存のバッチ・アップロード・プロセスは、大型カタログ・データ・ファイル・アップロードを処理するように引き続き最適化されます。また、購買担当 (新しい「購買担当ワークセンター」から) および仕入先 (「iSupplier Portal」から) にも使用できます。
iProcurementでバルクロードされた品目は、新規に作成されたGBPAに移行します。抽出プログラムは廃止になり、カタログ・コンテンツはリアルタイムで更新されます。
注意: カタログのアップグレードを開始する前に、承認待ちの基本契約に対する承認処理を完了しておくことをお薦めします。承認済基本契約のコンテンツは、アップグレード後にiProcurementの検索ページで使用できます。
範囲、ストアーおよびカタログに関するリリース11iの機能は結合され、コンテンツ・セキュリティの拡張機能として総称されます。このリリースでは、カタログがコンテンツ・ゾーンで置き換えられています。
カタログ管理者は、ローカル・カタログのコンテンツを品目の仕入先、仕入先サイト、品目カテゴリおよび参照カテゴリ情報に基づいてローカル・コンテンツ・ゾーンにパーティション化できます。コンテンツ・ゾーンを定義した後、特定の職責または営業単位を持つユーザーからアクセス可能にできます。コンテンツ・ゾーンを複数のストアーに割り当てたり、ストアーに複数のコンテンツ・ゾーンを含めることができます。
リリース11.5.10のiSupplier Portalでは、保留変更要求を仕入先所在地と仕入先担当に格納するために、Trading Community Architectureを使用していました。このリリースでは、この保留変更要求は一連のiSupplier Portal表に移動しています。
アップグレード中の前提事項については、『Oracle Financials and Oracle Procurement Functional Upgrade Guide: Release 11i to Release 12』のiSupplier Portalに関する項を参照してください。
営業単位からの法的エンティティの導出
このリリースでは、取引で定義および使用される法的エンティティが導入されています。法的エンティティは営業単位に関連付けられています。取引の入力中に、法的エンティティは営業単位に基づいて導出されます。ただし、必要に応じて変更できるようオプションが用意されています。
アップグレード中に、次のことが行われます。
法的エンティティは営業単位から導出されます。営業単位のコンテキストを含むすべての取引では、GRE/LEを法的エンティティとして使用します。
法的エンティティ機能のアップグレードの一環として、変更されたオブジェクトは法的エンティティ値でアップグレードされます。
OUに関連付けられているGRE/LEは、デフォルト法的コンテキストとしてアップグレードされます。OUに関連付けられている「デフォルト法的コンテキスト」 (DLC) はアップグレード用の値です。
このリリースでは、Lease and Finance Managementの税金エンジン、設定、およびeBTaxへのその統合に関する変更が導入されています。
税金設定のアップグレード
「ユーザー定義会計分類」および「税金基準上書き」の設定ステップは、「見積」取引タイプのかわりに「営業見積」取引タイプを使用するようにアップグレードされます。
税金ソースに税金属性を含めるようにアップグレードします。追加の属性が税金明細 (TAX_LINE_NUMBER、TAX_REGIME_CODE、TAX、TAX_JURISDICTION_TYPE、TAX_JURISDICTIONなど) に追加されるように税金明細をアップグレードし、これらの該当する列に値を設定します。
「取引ビジネス・カテゴリ」定義の設定データを新規エンティティOKL_TAX_ATTRIBUTE_DEFINITIONSに移行します。
契約および取引のアップグレード
既存の契約を「税金予定表適用」フラグにデフォルト値を割り当てるようアップグレードします。この値は、契約の営業単位に定義されたシステム・オプションの設定からデフォルト設定されます。
完了していないすべての「再記帳」取引を取り消します。ステータスが草案、否認済および発行済のすべての終了見積を取り消します。
次の取引タイプについて、取引タイプ表のTAX_INVOICE_YNフラグを「Y」に設定します。
リリース請求
リリース・クレジット・メモ
ロールオーバー請求
ロールオーバー・クレジット・メモ
記帳済でない契約の既存の記帳前取引をアップグレードします。このような取引のtry_idは「記帳」取引のtry_idに変更されます。
既存の「資産事業所変更」取引のステータスを「入力済」から「処理済」にアップグレードします。
「資産事業所変更」取引の「明細」表をアップグレードします。「資産事業所変更」取引のtal_typeはCFAからAGLにアップグレードされ、okl_txl_inst_itemsのdnz_cle_idは、関連する「資産事業所変更」取引の適切な値にアップグレードされます。
「資産事業所変更」取引のヘッダー表をアップグレードします。ヘッダー表の取引タイプは「CFA」から「ALG」にアップグレードされ、関連する「資産事業所変更」取引について発生した日付取引が切り捨てられます。
各「資産事業所変更」取引に対して、取引要求表に要求が作成され、「資産事業所変更」取引が対応する要求IDで更新されます。
eBTaxとの統合
「主用途」のeBTaxソースに対する販売およびオーサリングの下に「機器の使用」フィールドの既存の値を含めます。「販売」の「税金の主用途」フィールドを「機器の使用」の既存の値でアップグレードします。
次の前払い税金明細をeBTaxに移行します。
「渡し済」、「完了」、「承認済」ステータスの契約の記帳/前払税金明細の再記帳は、「レポート可能」フラグ「N」でLease and Finance Managementデータ構造からeBTaxに移行します。
「記帳済」ステータスの契約の記帳/前払税金明細の再記帳は、「レポート可能」フラグ「Y」でLease and Finance Managementデータ構造からeBTaxに移行します。
資産事業所変更税金明細は、「レポート可能」フラグ「Y」でLease and Finance Managementデータ構造からeBTaxに移行します。
Subledger Accounting (SLA) との統合
このリリースでは、補助元帳取引間の会計を管理するためにOracle Subledger Accounting (SLA) が導入されています。Lease and Finance Managementでは会計仕訳が作成されなくなりました。既存のLease and Finance Managementの会計オプションと設定はそのまま残っており、Lease and Finance Managementデータ・モデルでの会計配分の生成に影響します。ただし、Subledger Accountingモジュールでは、会計配分は最終会計を生成するための多数のソースの1つにすぎなくなっています。
アップグレード中:
アップグレードに設定した期間範囲に関係なく、リリース11iデータ・モデルのすべての会計イベント、ヘッダーおよび明細が、新しいSubledger Accountingのイベント、ヘッダーおよび明細データ・モデルにアップグレードされます。
会計取引のヘッダー、明細および配分の識別子は、Subledger Accountingモジュールとの統合を容易にするため、順序を使用してキー更新が行われます。
すべての会計取引の会計ソース値「表示コード」および「表示名」は、それぞれ主要元帳短縮コードおよび主要元帳名に設定されます。
一貫性のある会計取引ステータス
会計イベントと会計取引の間の一貫性を実現し、データの整合性を確保するために、特定の損失引当金、一般損失引当金、その他および見越会計取引は、「入力済」の取引ステータス「処理済」でアップグレードされます。
このリリースでは、Lease and Finance Managementにより、終了会計取引ステータスと終了プロセス・ステータス間の分離が導入されています。アップグレード中、終了取引に対して会計仕訳が生成されている場合、終了プロセス・ステータスは「処理済」に設定されます。会計仕訳が生成されない場合、終了プロセス・ステータスは適切な既存の中間ステータスを使用して移行および設定されます。
中央会計取引リポジトリ
このリリースでは、すべての「資産処分」会計取引は中央会計取引エンティティに自動的に移行されます。
「勘定科目導出」会計システム・オプション
このリリースでは、会計テンプレート明細でGL勘定科目コードを定義する必要があるかどうかを確認するためにLease and Finance Managementによって使用される「勘定科目導出」会計システム・オプションが導入されています。「勘定科目導出」会計システム・オプションは、勘定科目コード (Lease and Finance Managementで会計テンプレート明細に定義されている場合) がSubledger Accountingモジュールで最終会計を生成するための追加の会計ソースとして提供されるかどうかを制御します。
アップグレード中、Lease and Finance Managementでは、「勘定科目導出」会計システム・オプションの値が「会計テンプレート・セット」として設定されます。
Lease and Finance Managementの支出取引表をアップグレードする必要があります。金額がマイナスだった場合、請求書タイプはクレジット・メモになります。
このリリースでは、取引表およびOracle Payablesの請求書ヘッダーと明細の既存のデータに基づき、連結データを移入する必要のある新しい連結表が導入されています。取引表とOracle Payablesの請求書ヘッダーおよび明細表の間のリンクもアップグレードする必要があります。また、Oracle Payablesの内部取引表は、取引表とAR請求書の間の新しいリンクを保持するようにアップグレードされます。
oklupdpassthrupaydate.sql:
このスクリプトにより、NULLの代理回収支払開始日を持つ契約を更新します。これにより、料金/サービスの日付から有効である代理回収支払開始日が更新されます。
oklcrctptpaygrouppmntterm.sql:
このスクリプトにより、ベースおよびエバーグリーン代理回収条件に対してNULLの支払グループおよび支払条件を持つ契約が識別され、仕入先および仕入先サイト設定に基づいてこれらの値が更新されます。仕入先設定が存在しない場合、支払グループおよび支払条件が適切にデフォルト設定されます。
複数組織アクセス管理 (MOAC)
このリリースでは、1つの職責に対して複数の営業単位を使用できます。これは、使用可能な営業単位をセキュリティ・ポリシーに関連付けるとともに、職責に関連付けることにより実現できます。新しいシノニムが作成され、セキュリティ・ポリシーによって保護されています。この結果、多くのオブジェクトが変更されました。
アップグレード中にこのことを実行するために、次のスクリプトが使用されます。
OKLTBRNM.sql - 表を名称変更するためのスクリプト
OKLSECSM.sql - シノニムを作成してセキュリティ・ポリシーを追加するためのスクリプト
OKLORUPG.sql - 次の表に対してorg_idデータをアップグレードするためのスクリプト
OKL_CURE_REPORTS
OKL_SERVICE_FEES
OKL_TXL_RCPT_APPS_ALL_B
OKLPRFUPG.sql ? このスクリプトは特定のORGのプロファイル値を識別し、システム・パラメータ表のプロファイルの値セットを更新します。システム・パラメータ表でORGの値が検索されない場合、表にこれらの値が挿入されます。
OKLPRODEL.sql ? このスクリプトは必要なすべての表からプロファイルを削除します。
Payablesの銀行口座のアップグレード
このリリースでは、Payablesで保守されてきた銀行口座は廃止になっています。銀行口座はCash Management (CE) とOracle Payments (IBY) に配分されます。Cash Managementでは当方銀行口座を保守します。Oracle Paymentsでは外部銀行口座、契約パーティ、T&C、VPA、IAおよび資産の請求設定を保守します。LABACCおよびIBYのアップグレード・インスタンスでは、同じルール参照が使用されます。
リースでは外部銀行口座 (Oracle Payablesで保守されている) のみを使用します。銀行口座情報を取得するための問合せは、IBY表と結合して正しい情報が取得できるように変更する必要があります。
このリリースでは、文書の送信にXML Publisherが使用されます。1対1の資料送付のために顧客によって作成済のプロセス・テンプレートの関連付けは、XML Publisherで使用できるようにアップグレードする必要があります。これは、「プロセス・テンプレート表」をアップグレードすることによって実行できます。XML_TMPLT_CODEの値を、プロセスの対応するシード済「テンプレート・コード」にアップグレードします。すべてのレコードについて、RECIPIENT_TYPEがLESSEEにアップグレードされます。
Oracle ReceivablesでLease and Finance Managementを介して作成された請求書は、請求書にリース取引IDをスタンプすることによって新しいアーキテクチャにアップグレードする必要があります。Lease and Finance Managementの前受入金が廃止されたため、Lease and Finance Managementの既存の未利用ストリーム配賦はOracle Receivablesで対応する入金の対顧客勘定消込として移行されます。
取引表はアップグレードされ、連結表および外部表で現在ホスティングされている追加列が追加されます。取引表内のこれらの追加列のデータはLease and Finance Managementの連結表および外部表内の同等のレコードから移入されます。2レベルの請求取引は、明細表内のすべてのレコードの詳細表にエントリを作成することによって3レベルの請求取引にアップグレードされます。
oklupdinvfrmtid.sql:
このスクリプトにより、契約請求書書式ルールがアップグレードされ、請求書書式情報が名称からIDに置き換えられます。
「二次表示方法」会計システム・オプション
このリリースでは、二次表示会計取引および会計配分を生成するかどうかを決定するためにLease and Finance Managementで使用される「二次表示方法」会計システム・オプションが導入されています。
アップグレード中、11iの事前アップグレード・ステップで「二次表示方法」会計システム・オプションの値が「自動会計」に設定されていない場合、Lease and Finance Managementでは、次のようにこの値が設定されます。
11iで営業単位が複数GAAP営業単位でない場合、二次表示方法の値は「適用不可」に設定されます。
11iで営業単位が複数GAAP営業単位の場合は、二次表示方法の値は「レポート」に設定されます。
「表示タイプ」取引属性
このリリースでは、Lease and Finance Managementにより、会計取引エンティティに「表示タイプ」属性が導入されています。Lease and Finance Managementでは、会計取引ユーザー・インタフェースで会計取引を表示する際に「表示タイプ」属性を使用することにより、選択した表示に属する会計取引を識別します。
アップグレード中、Lease and Finance Managementでは、すべての会計取引ヘッダーについて「表示タイプ」属性の値が「主」に設定されます。
見越計上ストリーム要素インディケータ
アップグレード中、Lease and Finance Managementでは、契約のローカル製品ストリーム要素が累積される日付まで、ストリーム要素エンティティの累積Yes/Noストリーム要素インディケータの値が「Yes」に設定されます。アップグレードされるストリーム要素は、次のとおりです。
複数GAAP契約に属しているレポート・ストリーム要素
「二次表示方法」の値が「自動会計」に設定されている営業単位に属しているストリーム要素
ストリーム・タイプがレポート製品で見越計上可能として定義されているストリーム要素
アップグレード中に、Oracle Loansの会計機能が自動的にSubledger Accountingおよび他の共通データ・モデル・コンポーネントに移行します。
このリリースではOracle Paymentsが導入され、Oracle PayablesとOracle Loansでローン支払処理に使用されます。LoansによりPayablesに支払要求が作成され、PayablesによりOracle Paymentsを介して資金が支出されます。
このリリースでは、補助元帳取引間の会計を管理するためにSubledger Accountingが導入されています。Oracle Loansでは会計仕訳が作成されなくなりました。アップグレード中に、会計オプションと設定およびLoansデータ・モデルの既存の会計仕訳が新しい会計データ・モデルに移動します。これにより、2つのリリース間で業務を確実に継続できます。取引に関連するLoansの会計明細も、すべて移行します。
リリース11iでは、ローンの承認時に会計仕訳がGLインタフェースで作成されていました。このプロセスは同じですが、Subledger Accountingで処理するための会計イベントが作成されます。「会計の作成」コンカレント・プログラムを手動または定期的に実行して仕訳を生成し、Oracle General Ledgerに転送する必要があります。個別ローンの会計も、「ローン会計」タブからリアルタイムで作成できます。
リリース11iの「ローン・タイプ」参照は廃止になりました。このリリースでは、ローン製品とともにローン・タイプを使用して、エージェントおよび申請者間で会社ポリシーを実施し、ローン・エージェントによる申請プロセスを合理化できます。
次のようなデフォルト設定パラメータがあります。
ローンが分割支払かどうか
建設ローンを期間ローンに変換可能かどうか
与信検討が必須かどうか
ローン申請金額および期間の範囲
レート・タイプ
変動レート・ローンの変動頻度
支払頻度
必要な担保と融資比率
承認条件または変換条件
必須手数料
分割支払によるローンの支出計画
アップグレード時に、シード済のローン・タイプがローン・タイプ・エンティティに移行します。企業の要件に基づき、採用企業の組織とアップグレード後のローン・タイプに従って製品を設定する必要があります。
「ローン・タイプ」参照は廃止になっています。検証のために、「ローン管理」職責で「ローン・タイプ」ユーザー・インタフェースからローン・タイプを問い合せてください。
リリースR12では、Oracle Subledger Accounting、E-Business Tax、Ledgers、BanksおよびOracle Payablesで使用されていたその他の共通データ・モデル・コンポーネントが導入されています。
仕入先は、TCAパーティとして定義されるようになりました。アップグレード中に全仕入先のTCAパーティ・レコードが作成または更新され、既存の仕入先エンティティ内のレコードにリンクされ、支払およびバンキング詳細がOracle Paymentsデータ・モデルに移行します。基礎となるデータ・モデルは変更されていますが、引き続き「仕入先」ウィンドウで仕入先を入力したり管理できます。
Oracle Payablesには、請求書ヘッダーと請求書配分の間のエンティティとして請求書明細が導入されています。新しいモデルでは、請求書ヘッダーに変更はなく、引き続き請求書を送付した仕入先に関する情報、請求書属性および送金情報が格納されます。
請求書明細は、商品 (直接または間接資材) 、サービスまたは請求対象の関連税金/運送費/その他手数料 (あるいはそのすべて) を表します。請求書配分には、請求書明細を構成する会計、配賦およびその他の詳細情報が格納されます。以前のリリースで会計配賦の管理に使用していた手数料配賦表は廃止になっています。
アップグレード中に、Oracle Payablesにより既存の全請求書の請求書明細が作成されます。この場合、リリース11iの配分表で使用可能な各配分について明細が1つ作成されます。ただし、逆仕訳のペアについては、金額ゼロの明細が1つ作成されます。
リリース11iで定義した当方銀行および銀行口座はすべて、中央のCash Managementエンティティに自動的に移行されます。銀行口座と支払文書の所有者は、営業単位ではなく法的エンティティとなります。詳細は、この付録の「Cash Management」を参照してください。
また、銀行および銀行支店は前述のようにCash Managementエンティティに集約されます。ただし、仕入先に対して定義した銀行口座は、Payablesエンティティから中央のPaymentsエンティティに移行します。Paymentsでは、外部銀行口座、クレジット・カードおよびデビット・カードなど、すべての支払手段データが集約され、保護されます。詳細は、この付録の「Payments」を参照してください。
リリース11iで支払文書に文書連番を使用していた場合は、文書連番カテゴリが、銀行口座 (つまり法的エンティティ) に関連付けられていた支払文書から銀行口座使用エンティティに移行します。この変更により、営業単位間で異なる文書連番カテゴリを持つオプションが保持されます。
Oracle Payablesでは、請求書支払の処理にOracle Paymentsを使用できます。詳細は、この付録の「Payments」を参照してください。
リリース11iでグローバル付加フレックスフィールドを使用して実装されていた多数のヨーロッパの支払機能は、Oracle Payables、Oracle PaymentsおよびOracle Cash Managementのデータ・モデルに移行されます。
リリースR12では、補助元帳取引間の会計を管理するためにOracle Subledger Accounting (SLA) が導入されています。Payablesでは会計仕訳が作成されなくなりました。アップグレード中に、会計オプションおよびその設定と、Payablesデータ・モデルの既存の会計仕訳が新しいSLA会計データ・モデルに移動します。これにより、2つのリリース間で業務を確実に継続できます。
アップグレード中には、アップグレード用に設定した期間範囲に関係なく、リリース11iデータ・モデルのすべての会計イベント、ヘッダーおよび明細が、新しいSubledger Accountingのイベント、ヘッダーおよび明細データ・モデルにアップグレードされます。
Oracle E-Business Taxでは、E-Business Suite全体の税金が管理されます。以前のリリースでは、Payablesの税金の設定、デフォルト設定および計算は、税金コード、関連レートおよびデフォルト設定オプションの階層を使用してPayablesで管理していました。この方法は、このリリースでも引き続き使用可能です。アップグレード中に、E-Business Tax内の税金コードが必要に応じて移行されるため、税金処理はアップグレード後も従来と同様に機能します。
E-Business Taxで使用される税金属性を追跡するために、仕入先、請求書および請求書明細の各エンティティに新規フィールドが追加されています。これらの属性の多くは、以前のリリースでグローバル付加フレックスフィールドを使用して実装されており、これらのエンティティの標準フィールドにアップグレードされます。
このリリースのOracle E-Business Suiteには、支払の支出と入金を行うための高度に構成可能で堅牢なエンジンであるOracle Paymentsが導入されています。Oracle Paymentsには、新機能に加えて、Oracle iPaymentとして以前にリリースされ、現在は廃止になった機能も組み込まれています。
Oracle Paymentsには、標準XMLテクノロジに基づく新しい書式設定ソリューションが用意されています。以前のリリースでは、独自のOracleレポート・テクノロジで支払書式を作成する必要がありました。リリースR12では、書式をOracle XML Publisherでテンプレートとして作成し、Oracle Paymentsにより生成されたXMLデータ・ファイルに適用します。
アップグレードにより、Oracle Paymentsでサポートされている各支払書式が2つのエンティティ (XML PublisherテンプレートとPaymentsのシード済書式) に変換されます。シード済書式はテンプレートにリンクされています。書式付きデータを検証するためのロジックは書式設定プログラムから分離されており、事前パッケージされた検証ライブラリにアップグレードされます。これらの検証はシード済の支払書式にリンクされ、支払処理中に実行されます。
Oracle Paymentsは、Trading Community Architectureデータ・モデルの最上部にある支払データ・リポジトリとして機能します。この支払データ用共通リポジトリにより、暗号化を集中管理して支払手段情報の管理を隠すことができ、データ・セキュリティが向上します。
アップグレードにより、パーティ情報がOracle Trading Community Architectureに移動します。パーティの支払情報とすべての支払手段 (クレジット・カードや銀行口座など) は、Oracle Paymentsに移動します。パーティの支払情報は、顧客、学生およびグローバル付加フレックスフィールドなどのエンティティから移動し、Oracle Paymentsで支払人レコードとして作成されてパーティにリンクされます。パーティの支払情報は、仕入先やグローバル付加フレックスフィールドなどのエンティティから移動し、Oracle Paymentsで受取人レコードとして作成され、同じくパーティにリンクされます。Oracle Payablesの銀行口座モデルに保持されていた第三者 (顧客と仕入先) の銀行口座は、Oracle Paymentsに移行し、所有支払人または受取人にリンクされます。第三者クレジット・カード詳細は、Payablesデータ・モデルとOrder Managementなどのアプリケーションから、Oracle Paymentsのデータ・リポジトリに移行します。
リリース11iで次の製品に保持されていたクレジット・カード・データは、Oracle Paymentsに移行します。
Oracle Payables
Oracle Order Capture
Oracle Order Management
Oracle Service Contracts
Oracle Student System
Oracle Paymentsには保護電子支払ファイルと支払メッセージの伝送および伝送結果処理機能が用意されており、Oracle iPayment、Oracle Payablesおよびグローバリゼーションの以前の電子伝送機能が置き換えられています。Oracle Payablesの伝送機能は単にカスタマイズをサポートするためのフレームワークだったため、自動アップグレードではこの情報を移行できません。Payablesの伝送アーキテクチャを使用している場合は、Oracle Paymentsの電子伝送機能を確認し、カスタマイズを置き換える計画を作成する必要があります。
Oracle Payablesから支払を発行するプロセスは、リリースR12で新しいOracle Paymentsの資金支出プロセスを使用するように変更されています。この変更は、U.S. Federal Financialsなど、他のバージョンのPayablesや国固有のグローバリゼーションに影響します。
影響を受ける主要領域は、次のとおりです。
支払方法: 支払対象の各文書では、資金支出プロセスでの処理方法を示す支払方法が必要です。支払方法は、必要に応じて広くも狭くも定義できるようになり、シード済値に制限されなくなりました。文書に支払方法を使用できる時期についてルールを設定できます。また、作成時に文書の支払方法をデフォルト設定するためのルールも指定できます。アップグレードにより、Oracle Payablesおよびグローバリゼーションに存在していた支払方法がシードされます。
処理ルール: 文書は、その支払方法によりOracle Paymentsで構成された処理ルールにリンクされます。この設定ルールは、支払プロセス・プロファイルという主要エンティティに保持されます。この処理プロファイルを支払処理に必要な数だけ構成できます。各プロファイルには、文書を支払に組み込む方法、支払を支払指示ファイルに集計する方法、および支払ファイルの書式設定方法に関するルールが保持されます。小切手印刷、電子ファイルの送信、個別送金通知の生成およびその他のオプションに関するルールは、容易に構成できます。
支払システム: 支払システムにより、支払処理に関連する第三者の情報が保持されます。第三者は、支払を支出または決済する金融機関や手形交換所の場合があります。このエンティティは、伝送情報と支払システムへの通信に必要な設定を保持するように定義されます。
アップグレードでは、Oracle Payablesの各種データを使用して、新しい支払プロセス・プロファイルが作成されます。このエンティティが資金支出プロセスの中心となるため、アップグレード・プロセスの概要はここで説明します。
書式定義にリンクされているPayables支払プログラムごとに、Oracle XML Publisherテンプレートが1つ作成され、1つのOracle Payments書式にリンクされます。Oracle Payablesでは、異なる書式定義を作成して同じ支払プログラムにリンクできます。そのため、アップグレードにより、各Payables書式定義ごとに、Oracle Payments書式にリンクされた支払プロセス・プロファイルが1つ作成されます。
支払プロセス・プロファイルの重要部分は使用ルールです。ここで設定する値により、文書にプロファイルを割り当てて支払処理にルーティングできる時期を管理します。使用ルールには、次の4つのカテゴリがあります。
採用企業の当方銀行口座 - 資金の支出元となる口座。銀行口座は、アップグレード時に該当情報が検出された時点で使用ルールとして割り当てられます。最初に、プロファイルの作成に使用された書式定義が検索されます。次に、その書式定義に割り当てられた支払文書がすべて検索されます。支払文書の親である各当方銀行口座が、プロファイルに使用ルールとして割り当てられます。
支払プロセス・プロファイルのうち、もう1つの重要部分は支払システムへのリンクとその設定です。この情報はグローバリゼーションの設定値に基づいてアップグレードされます。該当する国の支払処理を理解しておく必要があります。
Oracle Receivablesは、顧客などの負債者が持つ資金を電子的に受け取るための資金取得処理についてOracle Paymentsと統合されています。Oracle PaymentsはReceivablesと連携して動作し、クレジット・カードによる資金を承認および取得し、クレジット・カードへの払戻しを処理し、銀行口座からの電子送金および受取手形の書式設定を実行します。Oracle Receivablesでは、ロックボックス処理と送金メッセージの電子アップロードに関する既存の機能が保持されることに注意してください。この支払領域のグローバリゼーションの書式と機能も、Oracle Paymentsに移動しています。
影響を受ける主要領域は、次のとおりです。
受取人構成: 受取人は、採用企業が支払を処理するエンティティごとに定義され、通常は企業に必要なのは1ステップのみです。受取人構成では、取引の処理に使用される各種の処理オプションが保持されます。リリース11iのReceivablesでは、自動作成方法を持つ各入金区分がOracle iPaymentの受取人にリンクされていました。リリースR12では、受取人には営業単位が割り当てられます。これにより、アプリケーション間で支払処理の一貫性を保証できます。アップグレード時には、Receivablesの既存の取引に基づいて受取人に営業単位が割り当てられます。
支払方法: 各取引には、資金取得プロセスでの処理方法を示す支払方法が必要です。Oracle Receivablesでは、この支払方法を自動作成方法で定義された入金区分について指定します。Receivablesでは、リリース11iで入金区分の設定に使用していた支払方法という用語が入金方法という用語に変更されたことに注意してください。
処理ルール: 電子資金取得取引の処理ルールは、資金取得プロセス・プロファイルという主要エンティティに保持されます。ユーザーは、これらのプロセス・プロファイルを支払処理に必要な数だけ構成できます。各プロファイルには、承認メッセージと決済ファイルの書式設定方法と送信方法に関する構成が保持されます。バッチへの決済集計、バッチ内の決済の数または金額の制限、支払人への決済通知および受領確認の処理に関するルールを容易に構成できます。
支払システム: 支払システムにより、支払処理に関連する第三者の情報が保持されます。第三者は、支払プロセッサや金融機関の場合があります。このエンティティは、伝送情報と支払システムへの通信に必要な設定を保持するように定義されます。
ルーティング・ルール: ルーティング・ルールを構成して取引の処理方法を指定できます。ルーティング・ルールにより、指定の基準が適用され、資金取得プロセス・プロファイルと使用する支払システムが決定されます。ルーティング・ルールは、受取人構成の一部として定義されます。
アップグレードでは、Oracle Receivablesの各種データを使用して、これらのエンティティが作成されます。これらのエンティティが資金取得プロセスの中心となるため、アップグレード・プロセスの概要はここで説明します。
ReceivablesまたはグローバリゼーションからOracle Paymentsにアップグレードされる書式ごとに、Oracle XML Publisherテンプレートが1つ作成され、1つのOracle Payments書式にリンクされます。資金取得プロセス・プロファイルが作成され、書式がプロファイルにリンクされます。
その他に、アップグレードにより、エンティティとして、1)資金取得支払処理のマスター設定を保持するための受取人が1人、2) 支払システムが1つ、3) 支払システム・アカウントが1つ作成されます。
アップグレードにより、Receivablesの設定から新規ルーティング・ルールが作成されます。作成元は、自動作成方法を持つ各入金区分です。これらの各入金区分について、入金区分の送金方法、当方銀行口座、銀行口座から導出された組織の組合せごとにルーティング・ルールが作成されます。
リリースR12では、Oracle iPaymentが廃止され、Oracle Paymentsアーキテクチャで置き換えられています。前項で説明した一部の主要エンティティが資金取得プロセスで使用されます。資金取得プロセス・プロファイルを除き、これらのエンティティはiPaymentに存在していました。各エンティティでは取引の処理ルールが保持されます。
iPaymentでサポートされる書式ごとに、アップグレードによりOracle XML Publisherテンプレートが1つ作成され、1つのOracle Payments書式にリンクされます。資金取得プロセス・プロファイルが作成され、書式がプロファイルにリンクされます。プロセス・プロファイルの設定は、構成およびサーブレット・ファイルの各種設定に基づきます。
Oracle Paymentsでサポートされている伝送プロトコル用に新規シード・データが作成され、支払システムの設定でプロトコルが指定されます。このデータも構成ファイルに基づいて設定されます。アップグレードでは、プロトコルを使用する伝送構成が作成されます。これらの伝送構成は、資金取得プロセス・プロファイルで指定されます。以前は構成ファイルで保持されていた設定を保持するために、新規支払システム・アカウントが作成されます。この支払システム・アカウントも、プロセス・プロファイルで指定されます。
設定データが技術構成ファイルから新規設定エンティティに移動したことには、ビジネス・ユーザーによる検討と更新が容易になったというメリットがあります。
以前のリリースでは、「マッピング・ルール」を移行するたびに、ルールのバージョン表示名に接頭辞として値(Import)が付けられました。このことは、次のルール・タイプに対して発生していました。
マッピング・ルール
条件
条件ディメンション・コンポーネント
条件データ・コンポーネント
その結果、ルールの表示名に接頭辞として(Import)が複数回付けられていました (例: "(Import)(Import)(Import)") 。
ルール移行機能により、「マッピング・ルール」名に接頭辞として付けられる値(Import)の数が1つに制限され、ディメンション・コンポーネント名から値(Import)が削除されます。
このリリースを適用すると、インポートされて接頭辞"(Import)"を複数含んだ「マッピング・ルール」、「条件」、「ディメンション・コンポーネント」および「データ・コンポーネント」のバージョン表示名をクリーン・アップするスクリプトが実行されます。「マッピング・ルール」および「条件」の場合、新しい表示名には部分文字列接頭辞"(Import)"が1つ含まれます。「ディメンション・コンポーネント」および「データ・コンポーネント」の場合は、表示名に部分文字列"(Import)"は含まれません。
注意: 短縮されたバージョン表示名が重複する名前になるルール・バージョンについては、表示名は更新されません。このような場合には、ユーザーがユーザー・インタフェースを通じてバージョン表示名を手動で更新する必要があります。
リリース12.0.3では、「マッピング・ルール」のローカル条件の概念が削除されています。パッチ・インストール・プロセスにより、すべてのローカル条件がグローバル条件にアップグレードされます。これらのグローバル条件は親マッピング・ルールとして同じフォルダに作成されます。
作成された条件名はLOCAL MAPPING 99999:<Parent Rule Name>になります。
また、収益性分析も影響を受けます。Profitability Manager 12.0.3のリリースまでは、「マッピング・ルール」でローカル条件が許可されていました。「使用箇所」ダッシュボードでは、ユーザーがローカル条件の使用されている場所を識別するのに役立ついくつかの回答が用意されています。
Profitability Manager 12.0.3以降は、ローカル条件を作成するオプションがありません。すべての条件がルールに対してグローバルと見なされます。したがって、ローカル条件の回答にはデータが表示されないため、ダッシュボードから削除する必要があります。
この項では、Oracle Public Sector Financialsの変更点を説明します。
リリース12.1.3以降では、Contract Lifecycle Management (CLM) は、向上した機能とPublic Sector領域向けの最新のテクノロジを備えた代替バージョンとして使用できます。
このリリースでは、補助元帳取引間の会計を管理するためのSubledger Accountingが導入されています。補助元帳の会計仕訳が生成され、集中化されたリポジトリに格納されます。リリース11iでは、これらが補助元帳と総勘定元帳で個別に作成されていました。
Subledger Accountingにはシード済の補助元帳会計処理基準と勘定科目導出ルールが付属しており、補助元帳取引から会計仕訳が生成されます。Public Sectorユーザー向けのシード済の補助元帳会計処理基準には、予算引当見越と予算引当現金があります。これらのルールにより、Public Sectorユーザー固有の適切な会計仕訳が導出されます。たとえば、Oracle Receivablesではマルチファンド会計仕訳が生成され、シード済の補助元帳会計処理基準にはマルチファンド会計仕訳を生成するための仕訳明細定義と勘定科目導出ルールが含まれています。
アップグレード中に、ReceivablesやPayablesなどの補助元帳アプリケーションでの予算引当設定に基づいて、補助元帳会計処理基準が決定されます。Public Sectorでは、General Ledgerの主要元帳と副元帳ごとに、適切な補助元帳会計処理基準が設定されます。報告通貨は、ソース元帳と同じ補助元帳会計処理基準を継承します。
この項では、Oracle Purchasingの変更点を説明します。
このリリースでは、購買契約に関するグローバルとローカルの区別がなくなっています。すべての購買契約を有効化して複数の営業単位間で使用できます。既存の全購買契約は単一の組織割当を持つようにアップグレードされます。この割当では、「要求営業単位」と「購買営業単位」の値はローカル購買契約を所有していた営業単位の値であり、「購買サイト」の値はローカル購買契約上の仕入先サイトです。
このリリースより前までは、iProcurementとPurchasingで別々のカタログを保守していました。このリリースでは、これらのカタログがPurchasing内で結合されています。アップグレード中には、iProcurementにバルクロードされた品目がPurchasingのグローバル包括基本契約に移行します。iProcurementを実装していた場合は、Purchasingの新しいグローバル包括基本契約を確認できます。詳細は、この付録の「iProcurement」を参照してください。
完全に自動化されたE-Business Taxにより、Oracle Purchasing関連の設定が移行します。このため、Purchasingの税金関連機能は従来どおり動作します。新しい税金ソリューションには、税務処理基準を集中管理し、ローカル要件をサポートするように構成するためのオプションが用意されています。
すべての共通税金設定は、E-Business Taxモジュールを介して実行します。「購買オプション」の税金デフォルト階層はE-Business Taxに移行します。
「税詳細」および「税金コード要約」フォームは廃止になりました。この情報は「税金の管理」ページ (メニュー・オプションを介してアクセス可能) に表示されます。また、「発注の入力」、「リリースの入力」および「購買依頼の入力」フォームの「税金コード」フィールドは廃止になりました。税金コードは税分類に名称変更されており、「追加税金情報」ページ (「税金の管理」ページからアクセス) で指定できます。
プロファイル・オプション「税金: 税金コード上書の許可」および「税金: 税金控除率の上書許可」は、それぞれ「eBTax: 税分類コード上書の許可」および「eBTax: 税金控除率の上書許可」に移行します。
この項では、Oracle Receivablesの変更点を説明します。
リリースR12では、E-Business Suite全体で税金を管理するためにOracle E-Business Taxが導入されています。アップグレード中に、税金計算と税金コードのデフォルト設定の制御に使用するシステム・オプションと顧客オプションが、Oracle ReceivablesからOracle E-Business Taxのエンティティに移行します。詳細は、この付録の「E-Business Tax」を参照してください。
リリースR12では、補助元帳取引間の会計を管理するためにSubledger Accountingが導入されています。Receivablesでは会計仕訳が作成されなくなりました。既存のReceivablesの会計オプションと設定はReceivablesデータ・モデルに残っており、会計配分の生成に影響します。ただし、Subledger Accountingモジュールでは、会計配分は最終会計を生成するための多数のソースの1つにすぎなくなっています。
リリース11iでReceivablesの会計表に対するカスタマイズは、Subledger Accountingの新機能を使用しない場合はアップグレード後も引き続き動作します。Subledger Accountingを使用して会計基準や会計の他の側面を更新した場合は、Subledger Accountingデータ・モデルを参照するようにカスタマイズを遷移する必要があります。
会計年度数を指定すると、その期間の取引データがアップグレードされます。指定したアップグレード期間外の取引についてレポートや問合せを実行する場合は、追加期間のアップグレードを起動する必要があります。詳細は、この付録の「Subledger Accounting」を参照してください。
このリリースでは、運用目的で定義した当方銀行および銀行口座がすべて自動的に中央のCash Managementエンティティに移行します。送金銀行口座の所有者は、営業単位ではなく法的エンティティとなります。
銀行および銀行支店は前述のようにOracle Cash Managementエンティティに集約されます。ただし、顧客に対して定義した銀行口座は、Payablesエンティティから中央のPaymentsエンティティに移行します。Oracle Paymentsでは、外部銀行口座、クレジット・カードおよびデビット・カードなど、すべての支払手段データが集約され、保護されます。詳細は、この付録の「Cash Management」を参照してください。
リリースR12ではOracle Paymentsが導入され、Oracle Receivablesで資金取得の処理に使用されます。詳細は、この付録の「Payments」を参照してください。
リリース11iの一括請求書機能が拡張され、サイトまたはアカウント・レベルで請求書を連結したり、ユーザー構成可能なBill Presentment Architectureを使用して繰越残高請求を表示する、より柔軟な請求サイクルが組み込まれています。リリース11iで一括請求書を使用している場合、設定は顧客サイト・レベルで有効化した繰越残高請求に自動的に移行します。
Receivablesの延滞手数料機能が拡張され、グローバル利息請求書の設定、手数料計算ロジックおよび手数料生成プロセスが組み込まれています。延滞支払の手数料を修正、デビット・メモまたは利息請求書として生成できるようになりました。「利息請求書」グローバル付加フレックスフィールドは廃止になっています。リリース11iの延滞金利設定属性は、アカウント・レベルとアカウント・サイト・レベルの延滞手数料設定に自動的にアップグレードされます。
このリリースでは、顧客データの入力と保守に使用する新しいHTMLユーザー・インタフェースが導入されています。詳細は、『Oracle Receivablesユーザーズ・ガイド』を参照してください。
次の機能は廃止されました。
回収ワークベンチ - Oracle Advanced Collectionsモジュールに同様の機能が付属しています。詳細は、『Collections Migration』ホワイト・ペーパーおよび『Oracle Advanced Collections User Guide』を参照してください。
取引会計 - Oracle Trade Managementモジュールとの統合により、同様の機能が提供されます。Trade Management統合は、リリース11iで使用可能です。
為替手形 - この機能は「受取手形」機能で置き換えられています。「受取手形」はリリース11iで使用可能です。
この項では、Oracle Sourcingの変更点を説明します。
このリリースでは、価格ファクタが原価ファクタに名称変更されています。また、原価ファクタに「仕入先」または「購買担当」タイプを使用できます。タイプに応じて仕入先または購買担当が原価ファクタの値を入力します。
ベース・リリース11i.10以前のバージョンのOracle Sourcingからアップグレードすると、すべての原価ファクタが仕入先原価ファクタとしてマーク付けされます。Oracle Sourcing Rollup J (Oracle Sourcingミニパック11i.PON.J) 以降のバージョンの製品からアップグレードする場合、影響はありません。リリース11.5.10以前のOracle Sourcingで使用可能だった価格要素は、このリリースでは仕入先価格ファクタと呼ばれます。
Oracle Sourcingのネゴシエーション・ヘッダー属性は大幅に改善されています。購買担当は自動的に仕入先応答をスコアリングし、入札を評価するスコア記録者のチームを指定できます。この機能も意味がわかりやすいように名称変更されました。ヘッダー属性は要件に、ヘッダー属性グループはセクションに名称変更されています。
再使用可能なセクションを作成するための参照コードは、ソーシング要件セクションと呼ばれます。事前定義済セクション名の変更は、古い文書には反映されません。アップグレード前に作成されたネゴシエーションの場合、古いヘッダー属性はセクション別にグループ化された階層ビューに表示されます。
購買担当は、自動延長をトリガー可能な最下位の入札ランクを指定できます。アップグレード・プロセスの一環として、以前の動作を複製するために既存の全ネゴシエーションが変更され、このランクが1に設定されます。
また、このリリースでは、購買担当が1から9999の数値を入力するか、無制限の拡張を選択することで、自動延長の最大数を従来よりも柔軟に指定できます。アップグレード前に作成されたオークションの場合、アップグレード後も延長数の値は変わりません。
コラボレーション・チームのメンバーは、オンライン・ディスカッションを介してメッセージを交換できます。また、全機能へのアクセス権を持つチーム・メンバーは、仕入先とメッセージを交換できます。以前のリリースでは、外部パーティにメッセージを送信できるのはネゴシエーション作成者のみでした。
コラボレーション・チームのメンバーのアクセス権は、アップグレード後も変わりません。「表示のみ」チェック・ボックスが選択されているチーム・メンバーには引き続き表示のみのアクセス権が付与され、このチェック・ボックスが選択されていないチーム・メンバーには全機能へのアクセス権が付与されます。
アップグレード前に送信された仕入先メッセージの場合は、仕入先の企業名とユーザー名が表示されます。アップグレード前に送信された購買担当メッセージを仕入先が表示すると、個別の (購買組織に所属する) 購買担当名ではなく購買担当の企業名が表示されます。
各テンプレートには、所有営業単位が関連付けられています。テンプレートの作成時には、所属先の営業単位を指定する必要があります。テンプレートは、所有営業単位内で作成されたネゴシエーションに適用されます。すべての営業単位のすべてのネゴシエーションに適用可能なグローバル・テンプレートとしてマーク付けすることもできます。
テンプレート作成ページには、新しい「営業単位」フィールドがあります。アップグレード前に作成された既存の全テンプレートの場合、このフィールドのデフォルト値はサイト・レベルのプロファイル・オプション「MO: 営業単位」から設定されます。グローバル・テンプレート用の新規チェック・ボックスもあります。既存のテンプレートの場合、アップグレード後にこのチェック・ボックスが選択状態になります。このため、そのテンプレートをすべての営業単位内で作成されたネゴシエーションで使用できます。
購買担当は2段階見積依頼を作成できます。2段階見積依頼プロセスはPublic Sectorの組織または政府企業によって使用され、通常、ネゴシエーション・プロセスは、仕入先による見積 (技術見積および商用見積の2つの部分から構成される) の発行の後に続きます。アップグレード後のすべての暫定見積依頼には、ヘッダー・ページにチェックボックスと2段階見積依頼が表示されます。このチェックボックスにより、2段階入札プロセスが可能になります。アップグレード前に公開されたすべての見積依頼では、「見積依頼の表示」ページに表示される2段階見積依頼を含む、選択解除された読取り専用のチェックボックスが表示されます。
仕入先では、購買担当が特定の製品またはサービスに対してコミットしようとする取引高に応じて、異なる単価を柔軟に提示できます。通常、仕入先は、大量の購入に対して優先的な価格設定を提供します。「数量ベースの価格階層」を使用すると、購買担当は「標準発注」、「包括購買契約」または「購買契約」の成果を含むネゴシエーションで、各数量範囲に対して異なる小売価格を指定できます。仕入先は購買担当により定義された階層構造に応じるか、独自の価格階層を提供することができます。
アップグレード前の「包括購買契約」または「購買契約」の成果を含んだネゴシエーションおよびテンプレートについては、「価格階層」フィールドでは「価格値引」としてマーク付けされます。アップグレード前の「標準発注」の成果を含むネゴシエーションおよびテンプレートについては、「価格階層」フィールドでは「なし」としてマーク付けされます。 (この変更は、リリース12へのアップグレード前にOracle Sourcing J Rollup 2を適用していなかった顧客に適用可能です。)
アップグレード前の固定金額の「原価ファクタ」を含むネゴシエーションの場合、新規の「落札価格」列は、すべての落札済明細に対する落札価格が入札/見積価格に設定されている「審査要約」ページに表示されます。 (この変更は、リリース12へのアップグレード前にOracle Sourcing J Rollup 2を適用していなかった顧客に適用可能です。)
「原価ファクタ」を使用すると、購買担当は製品またはサービスの合計原価のモデルを作成できます。「原価ファクタ」は、次の3つの価格設定基準のいずれかに従って機能します。(1) 単位当たりの原価 (2) 単価のパーセント (3) 明細の固定金額
この機能拡張により、固定金額の「原価ファクタ」が使用され、購買担当が仕入先に応答数量よりも少ないまたは多い数量を付与する際の、単位当たりの合計原価の計算が改善されます。以前は、Oracle Sourcingで応答数量を使用して単位当たりの合計原価を計算していたのに対し、新規フォーミュラでは落札数量を使用して、固定金額の「原価ファクタ」を配分することで、より正確な落札金額の計算が可能です。
ソーシング最適化には、購買担当が最適な審査決定を行えるようにいくつかの機能拡張が含まれています。購買担当は、指定した制約の重要性を示すことによって、審査の最適化のために制約の優先度を決定できます。アップグレード前の既存のすべての制約には、「必須」を示す優先度1の制約以外は、優先度リストが表示されます。
Oracle Subledger Accountingには、様々な補助元帳の既存の会計処理を置き換える共通会計エンジンが用意されています。そのため、Oracle Subledger Accountingのアップグレードは、2つのリリース間で業務を継続できるように、既存の会計データを移行する作業で構成されています。ビジネスおよび特定の要件によっては、既存の会計データが顧客ごとに異なる意味を持つ場合があります。
この意味で、また現行のマニュアルの目的にあわせて、会計データの定義は次のようになります。
顧客の全会計関連データ。これには、仕訳、残高、仕訳を生成したベース取引および関連情報 (会計イベントや設定情報など) が含まれます。
Subledger Accountingのアップグレードでは、継続的な業務の一環として、日次ユーザー活動に必要なレポートと照会も考慮されます。この意味では、次のように他の情報を新規インスタンスにアップグレードする必要があります。
様々な製品間での問合せとドリルダウンをサポートするデータ
レポートと問合せ
Oracle Supplier Data Hubは、異種環境間で仕入先レコードを管理できるマスター・データ管理 (MDM) ツールの完全スイートの一部です。Oracle Supplier Data Hubには個別ライセンスが必要です。
Oracle Supplier Lifecycle Management (SLM) は、見込仕入先や既存の仕入先に適した認定およびパフォーマンス評価を実行できる新しいアプリケーションです。主な機能は、次のとおりです。
拡張仕入先プロファイルを使用すると、各仕入先プロファイルに属性セットを無制限に追加できます。
仕入先認定は、仕入先からの主要認定詳細の収集をサポートしており、新しい各仕入先要求の複雑な承認ルーティングを可能にします。
パフォーマンス評価を使用すると、主要利害関係者からのフィードバックを収集およびスコアリングできます。
コンプライアンス管理には、主要コンプライアンス文書を格納および追跡するためのリポジトリが用意されています。
この項では、Oracle Trading Community Architectureの変更点を説明します。
ユーザー・インタフェースに新規データが表示されます。このデータは、Trading Community Architectureの組織、個人パーティおよび担当に関連する変更点を反映したものです。
仕入先および仕入先担当
銀行、銀行支店、手形交換所および手形交換所支店
法的エンティティ
会社間組織
Trading Community Architectureでは、所在地情報がTrading Community Architecture地理モデルに格納されているデータに基づいて検証されます。このモデルにより、以前にリリース11iで実行されていた検証が置き換えられています。Trading Community Architectureでの所在地入力および保守には、アップグレードは影響しません。無効な所在地が入力された場合の応答方法は、ユーザー定義ルールにより決定されます。
注意: 詳細は、『Oracle Financials and Oracle Procurement Functional Upgrade Guide: Release 11i to Release 12』のE-Business Taxに関する項を参照してください。
データ品質管理 (DQM) ツールには、新しい監査詳細レベルと工場出荷時の最大限のパフォーマンスを提供する拡張管理インタフェースが付属しています。新しい概要ページには、重要なDQMプロセスおよび設定のステータスに関連する適時な情報が表示され、より一貫性のある属性と変換のネーミング規則によりユーザー操作が向上しています。
D&Bパスワードの管理には、プロファイル・オプションではなく「管理」タブの「アダプタ」セクションを使用します。現行のD&Bパスワードはアップグレード中に移行します。
リソース・マネージャでロールを管理できるように、新しいHTMLページが追加されています。これらのページは同じ機能の既存フォームを置き換えたものではなく、フォームの代替として提供されます。
「リソース」、「グループ」および「ロール」の各JTTページは廃止になり、同等のHTMLページで置き換えられています。HTMLページではページのレンダリングに同じプロファイル・オプションを使用するため、設定は不要です。Oracle Customers Onlineの「従業員」タブの軽微なメニュー変更など、追加機能が使用可能です。
マージ・ディクショナリ、属性、変換、単語置換および照合ルールの設定は「管理」タブのHTMLページで管理し、DQM設定については削除されています。「顧客標準」フォームは合理化されたHTMLで置き換えられています。
注意: 詳細は、『Oracle Receivablesユーザーズ・ガイド』を参照してください。
この項では、Oracle Treasuryの変更点を説明します。
このリリースまでは、当方銀行口座が同一であっても、それを使用するアプリケーション (TreasuryやPayablesなど) ごとに個別に定義する必要がありました。このため断片化されたデータが作成され、銀行口座の保守は複雑な労働集約型の作業になっていました。
このリリースのCash Managementには、銀行、銀行支店および当方銀行口座の作成と保守に使用する共通データ・モデルと共通ユーザー・インタフェースが用意されています。様々なアプリケーションで使用するための当方銀行口座を集約的なCash Management機能で1回作成すると、すべてのアプリケーションまたは選択したアプリケーションのグループ (ユーザー指定) で使用できます。
この変更に対処するために、既存のすべての会社銀行口座および子会社銀行口座の情報が次のようにアップグレードされます。
すべての会社銀行口座は、新しい集約的データ・モデルに自動的に1対1で移行します。
すべての子会社銀行口座は、新しい集約的データ・モデルに自動的に1対1で移行します。ただし、このような口座は集約的データ・モデルに存在しますが、会社銀行口座とは異なり、新規ユーザー・インタフェースでは参照できないことに注意してください。引き続き「相手方プロファイル」フォームで管理する必要があります。
リリースR12より前に会社または子会社銀行口座で銀行として使用していた相手方はすべて、集約的データ・モデルの銀行および銀行支店に自動的に移行します。このような相手方はそれぞれ、1つの銀行と、この銀行に所属する1つの銀行支店にアップグレードされます。
注意: Treasuryの銀行口座の設定は変更されていますが、その使用方法に変更はありません。
このリリースより前のリリースでは、銀行口座残高の保守と利息計算を使用できるのは、Treasuryの銀行口座の場合のみでした。このリリースでは、Cash Managementで定義されている全銀行口座にこの機能を使用できます。
既存の銀行口座残高情報は、アップグレード中に次のように管理されます。
既存の全銀行口座残高データと残高レベルのレートは、自動的に新しい集約的データ・モデルに移行します。
銀行口座残高のデフォルトの金利設定は移行しません。
Oracle U.S. Federal FinancialsはOracle Financials製品ファミリ (Oracle Payables、Oracle Payments、Oracle General Ledger、Oracle Subledger Accounting、Oracle Receivables、Oracle PurchasingおよびOracle Cash Management) の複数製品と連携します。これらの製品のU.S. Federal Financialsユーザーに対する高レベルの影響については、この付録の該当する項を参照してください。
このリリースでは、補助元帳取引間の会計を管理するためのSubledger Accountingが導入されています。取引の取引コードを入力しなくても、目的の会計を作成できるようになりました。かわりに、Subledger Accountingでは取引の属性を使用して正しい会計を判別する勘定科目導出ルールがシードされています。
リリース11iでは、General Ledgerで仕訳詳細が保存されていたため、取引コード仕訳はSubledger Accountingに移動しません。すべての会計レポートには、General LedgerデータとSubledger Accountingデータを結合したものが表示されます。通常の処理中に、Subledger Accountingコードにより仕訳がSubledger Accountingに存在するかGeneral Ledgerに存在するか (アップグレードされているかどうか) が検出され、適切な補助元帳会計基準を使用して会計が作成されます。
すべてのU.S. Federal Financials会計帳簿は、会計設定の元帳にアップグレードされます。アップグレード済元帳は、General Ledgerの「会計設定マネージャ」を使用して表示できます。アップグレードにより、U.S. Federal Financialsのユーザー職責に割り当てられているアップグレード済元帳ごとにデータ・アクセス・セットが作成されます。これにより、適切なユーザーのみがU.S. Federal Financials内の元帳ベース設定ウィンドウへのアクセス権を確実に取得します。
リリース11iのOracle Financialsには、3つのネッティング・ソリューション (Oracle Public Sector Financials Internationalの単一サード・パーティ、Oracle Financials for Europeの相殺請求およびU.S. Federal Financialsの売掛管理および買掛管理ネッティング) がありました。この3つのソリューションはネッティング機能を提供しますが、対象とするニーズはそれぞれ異なっていました。
Oracle Financials Common Modulesの新しい売掛管理および買掛管理ネッティング・ソリューションでは、標準アプリケーションに組み込まれた1つの総合的なネッティング・ソリューションが提供されます。したがって、U.S. Federal Financialの売掛管理および買掛管理ネッティング・ソリューションは廃止になっています。U.S. Federal Financialsの売掛管理および買掛管理ネッティング・ソリューションで使用していた設定データは、新しい売掛管理および買掛管理ネッティング・ソリューションに移行します。
Oracle Paymentsの導入に伴い、U.S. Federal Financialsの連結支払ファイルがOracle Paymentsで直接生成されるようになりました。
要約計画は、アップグレード後も引き続きU.S. Federal Financialsに存在します。要約計画に関連付けられているリリース11iの全支払バッチ、または未生成の連結支払ファイルは、無効にしてOracle Paymentsで再作成する必要があります。この状況は、リリース11iのU.S. Federal Financialsの「要約計画と連結ファイル」ウィンドウでこれらの支払ファイルを生成することで回避できます。
Copyright © 1996, 2013, Oracle and/or its affiliates.All rights reserved.