リリース11iから12.2へのアップグレード・ガイド
E51767-01
目次
前へ
次へ
| Oracle E-Business Suite リリース11iから12.2へのアップグレード・ガイド E51767-01 | 目次 | 前へ | 次へ |
この付録では、取引データが予期したとおりにアップグレードされたことを確認するために実行できるオプション・タスクを説明します。
この付録の内容は次のとおりです。
この項では、Oracle Customer Relationship Management (CRM) 製品ファミリのアップグレード検証タスクを説明します。
これらのタスクは、Oracle Email Centerにのみ適用されます。
アップグレード後は、INTENTを除く全Eメール・アカウントが使用可能になっている必要があります。これらのアカウントは、アップグレード環境のEmail Center管理者コンソール画面から確認できます。管理者は、必要に応じてアカウントのプロパティを更新してアカウントを有効化するように計画する必要があります。
また、管理者は管理者としてログインし、ライブ・キューと「受信ボックス」にあるEメール・メッセージを表示して返信できることを確認する必要があります。
Email Center移行画面を使用すると、メッセージ移行プロセスのステータスをモニターできます。エラーが発生すると、説明的なエラー・メッセージが画面に表示されます。各メッセージを必要に応じて処理する必要があります。移行中に環境に問題が発生した場合は、メッセージを選択して再実行できます。
これらのタスクは、Oracle Incentive Compensationにのみ適用されます。
回収およびフォーミュラ・パッケージを生成するためのコンカレント要求が完了していることを確認します。分類パッケージ、回収パッケージおよびフォーミュラ・パッケージが正常に生成され、有効であることを確認します。必要な場合は、製品を使用する前にこれらのパッケージを再生成します。
システムで外部モジュールを使用する場合は、次の統合ポイントが引き続き有効であることを確認します。
Order Management
Accounts Receivable
Accounts Payable
Oracle Payroll
Territory Manager
これらのタスクは、Oracle Marketingにのみ適用されます。
「キャンペーン・ワークベンチ」で、ヘッダー情報と中間タブが予期したとおりに移行したことを検証します。「活動ワークベンチ」で、ヘッダー情報と様々なチャネル (Eメール、FAX、広告、テレマーケティングを含む) を持つ活動が予期したとおりに移行したことを検証します。
また、「追加情報」中間タブで、OAパーソナライズを使用してディープ・リンクをオンにして、関連付けが正しいことを確認します。
これらのタスクは、Oracle TeleServiceにのみ適用されます。
次の基本機能を実行して、アプリケーションが予期したとおりに動作することを確認します。
サービス要求を作成します。eAMが実装されている場合は、eAMサービス要求も作成します。
サービス要求 (アップグレード前に作成したサービス要求など) を更新します。
手数料を使用している場合は、手数料明細を作成してOrder Managementに発行できることを確認します。
「サービス要求レポート」を表示します。
これらのタスクは、Oracle Territory Managerにのみ適用されます。
ロール・ベース・アクセス管理 (RBAC) へのアップグレードが完了していることを確認するために、ユーザーについて次のことを確認します。
全ユーザーが「テリトリ管理」職責を持っていること。
全ユーザーが適切なテリトリ機能へのアクセス権を持っていること。
全ユーザーが適切な使用 (複数可) へのアクセス権を持っていること。
デフォルトで指定アカウント・タイプが存在する必要があります。リリース11iのシステムに地理テリトリが含まれていた場合は、リリース11.5.10から有効化された地理照合属性を使用して地理タイプを使用可能にする必要があります。リリース11.5.10に存在した非地理および非指定アカウント・テリトリの場合は、有効化された照合属性をすべて含む一般<使用>タイプが必要です。
リリース11iからマップされたテリトリでは適切なテリトリ・タイプを示す必要があり、以前テリトリに終了日がなかった場合は、開始日から+10年にデフォルト設定されている終了日が必要になります。さらに、次の機能も拡張されています。
すべてのリソースの取引アクセス・レベルが「全」に設定されている必要があります。
セルフ・サービス地理テリトリは管理者のテリトリ階層ビューで参照可能ですが、管理者が変更することはできません。すべての変更はセルフ・サービスUIを介して行う必要があります。
エスカレーション・テリトリのリソースは、エスカレーション・テリトリの作成対象となったテリトリが存在する必要があり、リソースのアクセスが「エスカレーション」に設定されている必要があります。
この項では、Oracle FinancialsおよびProcurement製品ファミリのアップグレード検証タスクを説明します。これらステップは、製品担当者または財務ユーザー (あるいはその両方) が実行する必要があります。
検証を設定するには、アップグレード前にリリース11iの特定の取引データに対してベンチマーク・レポートを実行します。次に、アップグレード完了後、同じレポートをアップグレード後のデータに対して実行し、結果をアップグレード前のバージョンと比較します。両方のレポート・セットの取引データが一致する必要があります。
これらのタスクは、Oracle Advanced Global Intercompany Systemにのみ適用されます。
Advanced Global Intercompany Systemの組織を検討し、各組織が法的エンティティに割り当てられていることを確認する必要があります。自動アップグレードでは、いずれかの会社間組織に関連付けられている単一の法的エンティティを識別できない場合があります。その場合、組織は無効化されます。その組織を取引に使用する前に、正しい法的エンティティで更新する必要があります。
これらのタスクは、Oracle Assetsにのみ適用されます。
アップグレード前とアップグレード後の両方で、選択したレポートを実行し、いくつかのオンライン照会を実行して、データに不一致のないことを確認する必要があります。
アップグレード前にリリース11i環境で次のレポートを実行し、アップグレード後に新しい環境で再実行します。結果を比較して、不一致がないかどうかを調べます。各レポートは、過去の期間、過去の期間範囲、または適用可能な場合は現行期間に対して実行できます。ただし、期間を選択する際には、アップグレードの実行対象となった期間範囲内でのみ選択するように注意する必要があります。
取得価額要約レポート
建設仮勘定要約レポート
償却累計額一覧レポート
再評価償却累計額要約レポート
資産取得レポート
資産除・売却レポート
資産振替表
資産振替調整表
資産組替表
資産組替調整表
また、リリース11i環境で「勘定ドリルダウン・レポート」を実行し、同じデータ・セットに対して「勘定科目分析レポート」を実行して、結果を比較する必要があります。
リリース11i環境で「照会」->「財務情報」にナビゲートし、資産をいくつか問い合せます。「資産台帳」->「取引」をクリックし、「ツール」->「会計の表示」にナビゲートします。現行会計年度中に発生した取引の会計が表示されていることを確認します。
新しい環境で同じメニュー・パスを使用し、同じ資産と取引に対してオンライン会計照会を実行して結果を比較します。このリリースでは、同じメニュー・パスでOracle Application Frameworkのページにナビゲートすることに注意してください。
これらのタスクは、Oracle E-Business Taxにのみ適用されます。
取引の税金情報が正しくアップグレードされたことを確認するには、アップグレード前に現行税務期間に対してPayablesの「税務監査証跡レポート」とReceivablesの「税金消込レポート」を実行し、取引情報のベンチマークを設定します。
アップグレード直後に、新しい環境で同じレポートを同じ期間に対して実行し、結果を比較して税金値が同一のままであることを確認します。
Payables取引とReceivables取引のサンプルについて、これらの取引の関連税金詳細を移行前に記録し、アップグレード後に再度問い合せて、税金が正しくアップグレードされたことを確認します。
同じ取引を複製し、再トリガーして、新しいE-Business Taxベースの計算に以前の計算との整合性があることを確認します。
これらのタスクは、Oracle Financials for the Americasにのみ適用されます。
アップグレード前にGeneral Ledgerに転記済の発生分について、Subledger Accountingで作成された仕訳がGeneral Ledgerで作成された仕訳と同期化されていることを確認します。
アップグレード前にはGeneral Ledgerに未転記だった発生分については、「会計の作成」プログラムを草案モード (Receivablesアプリケーション、「ブラジル銀行回収発生文書」および「標準入金」プロセスのカテゴリ・コード用) で実行し、Subledger Accountingの仕訳がリリース11iの場合と同様に作成されることを確認します。
これらのタスクは、Oracle Financials for Indiaにのみ適用されます。
データのアップグレードおよび移行の前と後の両方で、次のサンプル・レポート (標準およびカスタマイズ済) を検証します。各レポートのデータを比較して正確であることを確認します。
次のような標準レポートがあります。
PLA登録レポート
RG 23レポート
RG 23Dレポート
CENVAT月次レポート
RG-Iレポート
TDSレポート (証明書および返品)
サービス税レポート
VATレポート
また、「所得税勘定固定資産スケジュールおよび減価償却詳細レポート」も実行します。
これらのタスクは、Oracle General Ledgerにのみ適用されます。
「一般会計」職責を使用して、「標準要求発行」フォームでアップグレード前に「会計設定マネージャ更新前の診断レポート」を実行し、アップグレード後に「会計設定マネージャ更新後診断レポート」を実行します。
この診断では、次の領域が対象となります。
会計帳簿: 副元帳にアップグレードする会計帳簿の検討
複数報告通貨: 未割当の報告会計帳簿
複数報告通貨: 複数の主要会計帳簿に割り当てられた単一報告会計帳簿
複数報告通貨: 換算済通貨を使用する報告会計帳簿
複数報告通貨: General Ledgerのみの仕訳換算ルール
複数報告通貨: 矛盾したGeneral Ledger仕訳換算ルール
複数報告通貨: 矛盾した設定
複数報告通貨: 未完了の設定
レポートを検討し、アップグレード前レポートで提案された変更内容がアップグレード・プロセス中に実際に実行されたことを確認します。
適切な実務として、アップグレードの前後に財務データと残高を比較する必要があります。「勘定科目分析」、「仕訳レポート」、「残高試算表レポート」および「財務諸表」などの共通レポートを発行して、アップグレード前後の残高と仕訳を比較し、データが正しくアップグレードされたことを確認するようにお薦めします。
次のタスクは、Global Accounting Engineにのみ適用されます。
アップグレード前にGlobal Accounting Engineの会計レポートを実行し、アップグレード後に対応するSubledger Accountingレポートを実行して、アップグレードされた会計データの監査証跡が正しいことを確認する必要があります。実行するレポートは次のとおりです。
| Global Accounting Engine | Subledger Accounting |
|---|---|
| 日次仕訳帳 | 日次仕訳レポート |
| 勘定科目別勘定科目元帳 | 勘定科目分析レポート |
| 勘定科目別仕入先および顧客補助元帳 | 第三者残高要約レポート |
| 勘定科目別仕入先および顧客残高 | 第三者詳細および残高レポート |
これらのタスクは、Oracle iProcurementにのみ適用されます。
iProcurementのアップグレード後のインタフェースでは、「iProcurementカタログ管理」職責で「構成」タブを選択すると、データ例外レポートと、新しく作成されたグローバル包括基本契約のリストを表示できます。リリース12の「要約のアップグレード」では、「構成」タブ下に「例外」および「新規基本契約」という2つのタブが続きます。
「例外」タブのデータ例外レポートに表示されたデータは、iProcurementで使用できません。データの問題を解決するステップは、次のとおりです。
例外レポートで提供されている場合は、XMLファイルをダウンロードします。
アップグレード・プロセスでは、データ例外レポートに表示されるエラー条件に関するXMLファイルをダウンロードできます。仕入先/仕入先サイト/契約/言語の組合せごとに圧縮ファイルが1つ存在します。圧縮ファイルには、データが使用可能な言語ごとに処理SYNC用の複数ファイルが含まれている場合があります。ファイル名は、ItemException_language.xmlです。
ダウンロードしたファイルに表示されるデータを修正します。
グローバル包括基本契約 (GBPA) を作成または検索します。
ファイルの内容をGBPAにロードする必要があります。内容をGBPAにアップロードする方法の詳細は、『Oracle iProcurementインプリメンテーションおよび管理ガイド』のアップロード機能に関する項を参照してください。
注意: アップグレード・データ例外レポートは永続的なレポートです。つまり、提供されたXMLファイルを使用してデータをGBPAにロードしても、レポートにリストされた例外は引き続き表示されます。
アップグレードでは、新しく作成された全GBPAが自動的に検証され承認されます。購買担当はこれらの基本契約にOracle Purchasingを介してアクセスし、依頼者はこれらの基本契約の内容をOracle iProcurementで検索できます。
「新規基本契約」タブには、購買契約 (CPA) に基づいてGBPAがリストされます。GBPAヘッダーでソース・データとして使用されたCPA番号を確認し、CPA添付セクションで生成されたGBPA番号を確認できます。これらの文書の詳細は、『Oracle Purchasingユーザーズ・ガイド』を参照してください。
リリース11.5.9および11.5.10の移行結果として作成されたコンテンツ・ゾーンの場合、アップグレードではコンテンツ・ゾーン名としてカタログ名が使用されます。職責レベルと営業単位レベルのアクセス制限を維持するために、同じカタログ名で複数のコンテンツ・ゾーン・インスタンスが作成される場合があります。
「事務用品」ストアーには、仕入先Aの品目で構成されるローカル・カタログが含まれています。
職責レベルのカテゴリ・レルムが存在するため、「US依頼者」職責のユーザーがアクセスできるのは「事務用品」カテゴリの品目のみです。
「事務用品」ストアーは引き続き存在し、それぞれローカルという名称が付いた2つのコンテンツ・ゾーンが含まれています。
2つのローカル・コンテンツ・ゾーンの一方は「事務用品」カテゴリの品目のみを含むように構成され、iProcurementの職責でアクセスできます。
他方のローカル・コンテンツ・ゾーンは全カタログ品目を含むように構成され、「US依頼者」職責を除き、iProcurement、Purchasing、iSupplier PortalおよびEnterprise Asset Managementの全職責でアクセスできます。
アップグレード・スクリプトの実行後に、E-Content Managerの「コンテンツ・ゾーンの管理」画面を確認します。一部のカタログが完全にアップグレードされていない可能性があります。その場合は、コンテンツ・ゾーン名の横に警告アイコンが表示されます。
注意: 警告アイコン付きで表示されたコンテンツ・ゾーンを正常に機能させるには、さらに手動で構成する必要があります。
このリリースのコンテンツ・セキュリティでは、コンテンツ・ゾーンの定義に使用できる仕入先、仕入先サイトおよびカテゴリの数が制限されます。パフォーマンスの関係で、2000バイトという制限があります。リリース11.5.9および11.5.10では、最大300の特定仕入先を含むローカル・カタログの構成が可能でした。アップグレード・プロセス中に、iProcurementで指定のカタログについてカタログ数の制限を2000バイト未満の文字列に変換できるかどうかが判別されます。変換可能であれば、カタログが新しいコンテンツ・ゾーンに完全かつ自動的に移行されます。それ以上のユーザー処理は不要です。
指定のカタログについてカタログ制限の範囲全体を2000バイトの文字列に含めることができない場合、カタログ全体をコンテンツ・ゾーンに完全には移行できません。その場合は、「コンテンツ・ゾーンの管理」画面でコンテンツ・ゾーンの横に警告アイコンが表示されます。
次の例では、仕入先およびカテゴリ制限のリストを手動で複数のコンテンツ・ゾーンに分割する必要があります。
「事務用品」ストアーに、「ローカル」という名称の単一ローカル・カタログがあるとします。このカタログには、複数の仕入先の選択項目が含まれています。アップグレード・プロセス中には、2000バイトという制限があるため、すべての特定仕入先を単一のコンテンツ・ゾーンに変換できません。そのため、「コンテンツ・ゾーンの管理」画面では「ローカル」コンテンツ・ゾーンの横に警告アイコンが表示されます。
iProcurementで依頼者が経験していたショッピング動作を保持するには、カタログ管理者が「ローカル」コンテンツ・ゾーンで参照されている300の仕入先から一部を手動で削除し、削除した仕入先を含む第2のコンテンツ・ゾーンを作成する必要があります。この2つのコンテンツ・ゾーンの両方を「事務用品」ストアーに含めることができます。
これらのタスクは、Oracle Legal Entity Configuratorにのみ適用されます。
アップグレード完了後にシステム内の法的エンティティと報告組織をすべて検討し、正しい法的体系になっていることを確認する必要があります。この情報には、Legal Entity Configuratorの「検索」ページを使用してアクセスできます。
移行中に行われた想定と国固有のフィールドから移行されたデータの詳細は、『Oracle Financials and Oracle Procurement Functional Upgrade Guide: Release 11i to Release 12』を参照してください。
法的エンティティと報告組織を作成またはアップグレードする必要がある場合の指示については、『Oracle Financialsインプリメンテーション・ガイド』を参照してください。
これらのタスクは、Oracle Payablesにのみ適用されます。
リリース11i環境で、「買掛/未払金残高試算表」、「転記済請求書台帳」および「転記済支払台帳」レポートを実行します。アップグレード後に、アップグレード環境で「オープン勘定科目残高リスト」レポート、「転記済請求書台帳」および「転記済支払台帳」を実行し、結果を比較します。
注意: レポートは、単一営業単位のコンテキスト内ではなく単一の元帳または元帳セットに対して実行されます。リリース11iの「残高試算表」、「転記済請求書台帳」および「転記済支払台帳」は、単一の営業単位内で実行されます。システム構成によっては、リリース11iの複数のレポートを合計して新規バージョンに連結する必要があります。
Oracle Paymentsとの統合と既存請求書のアップグレードを検証するには、少数の請求書を支払うための限定的な選択基準を使用して支払バッチを発行します。
推奨のPayablesテストには次が含まれますが、これらに限定されません。
ビジネス・シナリオのテスト
アップグレード済未払請求書の支払
アップグレード済支払の無効化
アップグレード済請求書の取消
新しい請求書へのアップグレード済前払金の充当
アップグレード済請求書からのアップグレード済前払金の非充当
アップグレード済前払金請求書の取消
新しい請求書の作成
新しい請求書の支払
支払プロセス要求での新しい請求書グループの支払
Payablesパフォーマンス
Payablesレポートの確認
注意: 『EBS R12: Financial Reports impacted by the R12 (12.0 and 12.1) Upgrade』 (Doc ID: 1110684.1) を確認してください。
様々なデータ量に対して「会計の作成」プロセスを実行し、実行環境およびデータ量に基づいて適切な時間内に完了するかどうか検証します。
様々な勘定科目および日付範囲に対して「勘定科目分析レポート」を実行して様々なデータ量を戻し、実行環境およびデータ量に基づいて適切な時間内に完了するかどうか検証します。
注意: 『Oracle Payablesユーザーズ・ガイド、リリース12.2』を参照してください。
この付録の「E-Business Tax」を参照してください。
アップグレード前に未検証の請求書を問い合せて、その請求書の会計を発行します。アップグレード前に会計処理された請求書を問い合せて、取消および支払を実行してから、支払を会計処理します。この付録の「Global Accounting Engine」を参照してください。
Payablesで推奨の補助元帳テストには次が含まれますが、これらに限定されません。
Payablesの補助元帳ビジネス・シナリオのテスト
アップグレード済請求書のオンライン会計処理の作成
アップグレード済支払のオンライン会計処理の作成
アップグレード済請求書の会計処理を作成するための「会計の作成」プロセスの実行
アップグレード済支払の会計処理を作成するための「会計の作成」プロセスの実行
アップグレード後に取り消された請求書の会計処理を作成するための「会計の作成」プロセスの実行
アップグレード後に無効化された支払の会計処理を作成するための「会計の作成」プロセスの実行
新しい請求書に充当されたアップグレード済前払金の会計処理を作成するための「会計の作成」プロセスの実行
アップグレード後に未充当だったが充当されたアップグレード済前払金の会計処理を作成するための「会計の作成」プロセスの実行
新しい請求書の会計処理を作成するための「会計の作成」プロセスの実行
新しい支払の会計処理を作成するための「会計の作成」プロセスの実行
新しい会社間/会社内請求書の作成および会計処理 (該当する場合)
アップグレード済請求書の会計処理の表示
アップグレード済支払の会計処理の表示
新規請求書の会計処理の表示
新規支払の会計処理の表示
GLからアップグレード済Payables請求書/支払へのドリルダウン
GLから新しいPayables請求書/支払へのドリルダウン
アップグレード後に作成された未転送の会計処理を転送するための「GLへの仕訳転送」プロセスの実行
アップグレード後の期間クローズのテスト
これらのタスクは、Oracle Paymentsにのみ適用されます。通常、アップグレード検証計画には次の2つの支払処理領域におけるテストを含める必要があります。
資金支出 - リリース11iで支払の発行にOracle Payablesを使用していた場合は、アップグレード後のデータにビジネス・プロセスが正しく反映されていることを確認するために、以前の支払バッチ・フローに相当する資金支出プロセスをテストするように計画する必要があります。
資金取得 - 口座引落しや受取手形送金などの電子支払処理にOracle Receivablesを使用していた場合は、アップグレード後のデータにビジネス・プロセスが正しく反映されていることを確認するために、これらの領域をテストするように計画する必要があります。クレジット・カードまたは銀行口座引落しによる資金取得にOracle iPaymentを使用していた場合は、アップグレード後のデータが予期したプロセスで処理されることを確認するために、これらのプロセスをテストするように計画する必要があります。
Oracle Paymentsには、この新しいページが用意されており、暗号化、マスキングおよびクレジット・カード・セキュリティのシステム・レベルの設定を制御できます。アップグレード完了時に、このページでシード済の設定を検討し、ビジネス・ニーズを満たしていることを確認するように計画する必要があります。たとえば、リリース11iでは、クレジット・カード値のマスキングはアプリケーション全体で様々な方法で制御されます。このリリースでは、このページの集中設定でマスキングすべてを制御します。このページで設定を検討し、必要に応じて変更します。
アップグレード検証テストに使用するレポートを実行できます。たとえば、Oracle Payablesで「仕入先レポート」を使用して、Oracle Paymentsで作成された受取人の支払詳細と銀行口座に関するデータのアップグレードを検証できます。アップグレード前に実行した任意のレポートを参考にして、アップグレード済データを検証できます。また、支払処理のテスト中に検討して使用する必要のある主要な設定エンティティもいくつか存在します。
支払プロセス・プロファイル - アップグレードにより作成されたシード済プロファイルの設定を検討するように計画する必要があります。これらの設定は多様なソースから取り込まれ、プロファイルにより資金支出フロー全体が駆動されるため、設定によりビジネス・プロセスがサポートされているのを確認することが重要になります。シード済プロファイルの使用ルール・セットについては、アップグレード済値がニーズに合っていない場合は変更できるため、特に注意してください。本番で使用予定の各プロファイルを使用してテスト用支払処理を実行することをお薦めします。
支払方法 - 新しい設定ページが用意されており、そこで支払方法を作成または更新できます。ビジネス・ニーズを確実に満たすように、Oracle Paymentsのシード済支払方法の検討を計画する必要があります。
支払システムと口座 - これらのエンティティをアップグレード後に検証するように計画する必要があります。特に、必須の設定、値および支払プロセス・プロファイルへのリンクを検証します。この設定により資金支出プロセスの重要部分 (支払ファイル伝送など) が制御されるため、この領域をテストして、プロセスが予期したとおりに機能していることを確認する必要があります。
この設定ページでは、資金支出支払処理に使用するシステム・オプションを検討し、設定できます。このページでアップグレード済およびシード済の設定を検討し、ビジネス・ニーズを満たしていることを確認するように計画する必要があります。たとえば、提示支払上にある受取人の銀行口座上書き許可のオプションは、APの「買掛/未払金オプション」での同等設定からアップグレードされます。営業単位ごとに、このオプションがアップグレードにより正しく設定されていることを検証できます。
アップグレード検証テストに使用するレポートを実行できます。たとえば、Oracle Receivablesで「顧客詳細リスト」レポートを実行して、Oracle Paymentsで作成された支払人の支払詳細と銀行口座に関するデータのアップグレードを検証できます。アップグレード前に実行した任意のレポートを参考にして、アップグレード済データを検証できます。また、支払処理のテスト中に検討して使用する必要のある主要な設定エンティティもいくつか存在します。
資金取得プロセス・プロファイル: アップグレードにより作成されたシード済プロファイルの設定を検討するように計画する必要があります。これらの設定は多様なソースから取り込まれ、プロファイルにより支払フロー全体が駆動されるため、設定によりビジネス・プロセスがサポートされているのを確認することが重要になります。本番で使用予定の各プロファイルでテスト用支払処理を実行することをお薦めします。
支払方法: 新しい設定ページが用意されており、そこで支払方法を作成または更新できます。ビジネス・ニーズを確実に満たすように、Oracle Paymentsのシード済支払方法の検討を計画する必要があります。
支払システムと口座: これらのエンティティをアップグレード後に検証するように計画する必要があります。特に、必須の設定、値および資金取得プロセス・プロファイルへのリンクを検証します。この設定により資金取得プロセスの重要部分 (支払ファイル伝送など) が制御されるため、この領域をテストして、プロセスが予期したとおりに機能していることを確認する必要があります。
受取人とルーティング・ルール: アップグレードにより作成されたシステム受取人エンティティを検討する必要があります。特に、ルーティング・ルールが正しいことと、支払処理が予期した結果になることを確認します。
資金取得プロセス・フロー全体の設定を検討するように計画することが重要です。特に、新しいプロセス・プロファイル、伝送構成および支払システム・アカウントにアップグレードされた設定が正しいことを確認する時期を計画する必要があります。アップグレード・プログラムでは、iPaymentで検出された設定が自動的に移行されます。ただし、ネットワーク構成および支払プロセッサとの通信に使用する必須値などの領域は複雑なため、アップグレードではすべての新規データが予期したとおりに作成されない場合があります。
また、アップグレード後に受取人構成を検討するように計画する必要もあります。すべての設定を検討し、特に営業単位割当が予期したとおりに設定されていることを確認する必要があります。これらはOracle Receivablesでの取引に基づいて設定され、新しい資金取得取引が予期したとおりに処理されることを確認するには、アップグレード済の設定を確認する必要があります。
アップグレード済の構成を検討し、必要に応じて訂正した後、本番で使用予定の各構成でテスト用支払処理を実行する必要があります。
Oracle Paymentsの導入により、このリリースの支払処理にはリリース11iとは大幅に異なるデータ・モデルが使用されます。特に、新しいフレームワークとOracle XML Publisherの統合に伴って、支払ファイルのフォーマットが完全に変更されたことに注意してください。カスタム支払フォーマット、機能拡張、またはこのビジネス・エリアで作成した他のカスタマイズを検討し、新機能を使用することで廃止にするか、新しいモデルで動作するように再構築するかを計画することが重要です。カスタム支払フォーマット、機能拡張、その他に作成したカスタマイズをテストすることを計画し、新しい支払アーキテクチャで動作することを検証する必要があります。
これらのタスクは、Oracle Receivablesにのみ適用されます。
請求書を手動で作成し、税分類 (リリース11iでは税金コード) を選択します。請求書を完了し、税金がリリース11iと同様に計算されることを確認します。
本番で使用予定の固有の税務状況ごとに、テスト用の税金計算を実行します。
E-Business Taxと新しいReceivablesの「顧客」ユーザー・インタフェースで税金設定を検証します。
この付録の「E-Business Tax」を参照してください。
現行会計年度中の会計日を持つ転記済取引 (請求書、デビット・メモ、クレジット・メモ、チャージバック、前受/預り金、約定金額、入金、修正など) を問い合せます。「ツール」メニューで「会計の表示」を選択します。仕訳明細が正しく表示される必要があります。
アップグレードされていない会計年度中の取引を問い合せます。「ツール」メニューで「会計の表示」を選択します。Subledger Accountingのアップグレード後プログラムを実行する必要があることを示すメッセージが表示されます。
アップグレードの前後にReceivablesで会計レポートを実行し、データを検証します。
クレジット・カード支払のフラグが付いた請求書に対して自動入金を実行し、入金が正常に作成されて承認されることを確認します。
電子銀行間支払のフラグが付いた入金に対して自動送金を実行し、ファイルがOracle Paymentsで正しくフォーマットされることを確認します。
E-Business Taxと新しいReceivablesの「顧客」ユーザー・インタフェースで税金設定を検証します。
この付録の「Payments」の項を参照してください。
「一括請求」の設定が、サイト・レベルの「繰越残高請求」の設定にアップグレードされたことを確認します。
「繰越残高請求」プログラムを草案モードで実行し、生成された繰越残高請求のデータを確認します。
繰越残高請求の確認 (推奨)
このステップでは、「繰越残高請求の確認」プログラムを発行して、草案請求を承認または拒否する必要があります。適切な「売掛管理」職責で、「管理」->「要求」 ->「実行」にナビゲートし、リストから「繰越残高請求の確認」を選択します。
詳細は、『Oracle Receivablesユーザーズ・ガイド、リリース12.2』を参照してください。
繰越残高請求の印刷 (推奨)
このステップを使用して、草案または最終繰越残高請求を再印刷します。「BPA繰越残高印刷プログラム」を手動で実行し、請求を再印刷する必要があります。
詳細は、『Oracle Receivablesユーザーズ・ガイド、リリース12.2』を参照してください。
「延滞金利」と「グローバル利息請求書フレックスフィールド」の設定が新しい「顧客」ユーザー・インタフェースに正しく移行されたことを確認します。
「延滞手数料生成プログラム」を実行し、延滞手数料が予期したとおりに生成されることを確認します。
アップグレード後の顧客レコードを問い合せて、アカウント、アカウント・サイトおよびビジネス目的の各レベルの設定属性がリリース11iと同じであることを確認します。
次のタスクは、Oracle Sourcingにのみ適用されます。
アップグレード後に、ソーシング・バイヤーとしてログインします。暫定ネゴシエーションを作成し、「ネゴシエーションの作成: ヘッダー」ページに「要件」セクションがあることを確認します。また、「ヘッダー属性」セクションが使用できないことも確認します。「セクション名」が「グループ名」で置き換えられていることを確認します。
アップグレード後に、ソーシング・バイヤーとしてログインします。既存のオークションまたは見積依頼テンプレートを取り出し、ヘッダー・レベルに営業単位用の新規フィールドがあることを確認します。また、「グローバル・テンプレート」チェック・ボックスがあることも確認します。
Subledger Accounting (SLA) のアップグレードが正常に完了したことを確認します。
リリース12へのアップグレード中に、アップグレード対象の期間はすべて最初にgl_period_statuses.migration_status_code=Pとしてマークされ、各レコードは補助元帳 (AP、AR、FAなど) 会計表からSLAの会計表に更新され、最終的にこれらの期間がアップグレード済のgl_period_statuses.migration_status_code=Uとしてマークされます。一部の期間が未アップグレード (gl_period_statuses.migration_status_code=P) として残っている場合、後でSLAのアップグレードまたはアップグレード後パッチの実行時に問題が発生する可能性があります。SLAアップグレードが正常に完了したことを確認するには、次のスクリプトを実行します。
select * from gl_period_statuses where migration_status_code='P';
このSQLでは行は戻されません。戻される場合、適切なOracleサポート・チームに連絡し、不具合の記録を依頼してください。影響を受ける製品を確認し、この問題に関する詳細をさらに確認するには、『R12 SLA Upgrade: Check that the SLA Pre-Upgrade Completed Successfully』 (Doc ID: 747216.1) のApplication_IDリストを参照してください。
次のタスクは、Oracle Trading Community Architectureにのみ適用されます。
所在地チェック設定が正しくアップグレードされたことを確認するために、次のことをチェックしてください。
E-Business Taxについて現行の設定データの移行が完了していることを確認します。
アップグレード後のフレキシブル所在地書式 (FAF) 設定が正しいことを確認します。
顧客設定では、地理使用がユーザーのデータ訂正ポイントとなるため、他の使用におけるデータ入力要件をすべてカバーしていることを確認する必要があります。たとえば、税金使用に「郡市区」が必要な場合は、データ入力時に「郡市区」の入力が必須になるように地理使用に含める必要があります。所在地チェック中のエラーを回避するには、地理使用のマッピングがその国のFAF形式と一致している必要があります。つまり、所在地はユーザー・インタフェースに入力されたデータと同じデータに基づいて検証する必要があります。
「E-Business Taxの欠落事業所値レポート」を実行し、親がNULLになっている事業所を識別し、必要に応じて更新します。詳細は、このマニュアルの「E-Business Tax」の項を参照してください。
次のタスクは、Oracle Treasuryにのみ適用されます。
このリリースでは、当方銀行口座がTreasuryからCash Managementに移行します。アップグレード前に、すべて (会社、子会社および相手方) の銀行口座とそれぞれの全属性のスナップショットを取得します。また、銀行として使用する相手方をすべてメモします。
アップグレード後に、次のステップで銀行口座が正しく移行されたことを確認します。
新しい銀行口座ユーザー・インタフェースで、会社銀行口座を検索します。すべての会社銀行口座が表示されることと、すべての銀行口座属性が存在することを確認します。
新しい銀行口座ユーザー・インタフェースで、子会社と相手方の銀行口座を検索します。すべての子会社銀行口座と相手方銀行口座が表示されないことを確認します。
新しい銀行および銀行支店ユーザー・インタフェースで、アップグレード前に銀行として使用していた相手方を検索します。会社銀行口座および子会社銀行口座用の銀行として使用していた相手方すべてが、銀行および銀行支店として表示されることを確認します (1つの相手方 = 1つの銀行と1つの銀行支店) 。また、「相手方プロファイル」ウィンドウで、相手方が銀行支店としてマーク付けされ、銀行支店にリンクされていることを確認します。
新しい銀行および銀行支店ユーザー・インタフェースで、アップグレード前に銀行として使用していた相手方を検索します。相手方 (外部) 口座用の銀行専用に使用していた相手方が、銀行または銀行支店として表示されないことを確認します。
注意: 詳細は、『Oracle Cash Managementユーザーズ・ガイド』を参照してください。
このリリースでは、銀行口座残高がTreasuryからCash Managementに移行します。アップグレード前に、会社、子会社および想定資金プールの銀行口座のサンプル・セットを識別し、これらの口座の銀行口座残高詳細のスナップショットを取得します。また、銀行口座残高のデフォルト・レートとして設定されている金利すべてのスナップショットも取得します。これらのレートはアップグレードされず、アップグレード後に金利予定表として再作成する必要があります。
アップグレード後に、次のステップで会社および子会社銀行口座が正しく移行されたことを確認します。
新しい銀行口座残高ユーザー・インタフェースで、サンプル・セットの会社および子会社銀行口座を検索します。アップグレード前の銀行口座残高がすべて正しく表示されることを確認します。
アップグレード前の金利データを使用して明細の金利予定表を作成し、金利予定表に銀行口座が未割当の場合は割り当てます。
「銀行口座利息決済」ウィンドウで、残高と利息額が正しいことを確認します。
アップグレード後に、次のステップで想定資金プール残高が正しく移行されたことを確認します。
新しい銀行口座残高ユーザー・インタフェースで、サンプル・セットの想定資金プールを検索します。アップグレード前の残高がすべて正しく表示されることを確認します。
「銀行口座利息決済」ウィンドウで、残高と利息額が正しいことを確認します。
注意: 詳細は、『Oracle Cash Managementユーザーズ・ガイド』を参照してください。
次のタスクは、Oracle U.S. Federal Financialsにのみ適用されます。
Oracle Payablesで、少数の請求書を支払うための限定的な選択基準を使用して支払処理要求を発行します。「財務確認および消込」ウィンドウで、Treasuryに支払指示を確認させ、補助元帳会計が予期したとおりに作成されたことを確認させます。これにより、Paymentsとの統合および既存のPayables請求書のアップグレードのみでなく、U.S. Federal Financialsにおける財務確認プロセスと会計も検証されます。
様々な予算レベルで予算実行取引を入力し、会計が予期したとおりに作成されることを確認します。
この項では、Oracle Projects製品ファミリのアップグレード検証タスクを説明します。
次のタスクは、Oracle Property Managerにのみ適用されます。
次のステップでE-Business Tax、Subledger Accountingおよび法的エンティティ・データが正常にアップグレードされたことを確認します。
「不動産管理」->「リースおよび文書」にナビゲートします。
リリース11iからアップグレードされたリース (税金コードと税金グループで条件が指定されているリース) を問い合せます。
「支払」->「オープン」にナビゲートし、「支払条件」に「税分類コード」が移入されていることを確認します。
「条件テンプレート」にナビゲートし、テンプレートに「税分類コード」が移入されていることを確認します。
「不動産管理」->「リースおよび文書」->「補助元帳会計」->「会計イベント」にナビゲートします。
SLAアップグレードが完了した元帳とともに開始日と終了日を指定します。最後に会計処理された会計イベントのリストが表示されます。
「仕訳の表示」にナビゲートして仕訳を確認します。
ドリルダウンして詳細を確認します。
Receivablesの「自動インボイス・インポート・プログラム」を発行し、バッチ名に「Property Managerバッチ・ソース」を指定して請求書をインポートします。
「売掛管理/買掛管理へのエクスポート」->「取引」->「取引ワークベンチ」にナビゲートします。
法的エンティティが取引に正しく関連付けられている場合は、エクスポートした明細に関する法的エンティティのアップグレードが正常に完了したことを示します。
次のタスクは、Oracle Projectsにのみ適用されます。
リリース11i環境で、クローズ済の現行会計年度中の会計期間に対して「AUD: 収益監査レポート」を実行します。アップグレード後、同じレポートをアップグレード環境で実行し、結果を比較します。
「イベント・タイプ」、「支出タイプ」および「請求書検討」画面を使用して、請求書、イベント・タイプおよび支出タイプをチェックし、正常にアップグレードされたことを確認します。
アップグレードされた計画資源リストはすべて「資源区分の有効化」オプションが「Yes」に設定されます。
アップグレードされた資源分解構造はすべて「資源区分の有効化」オプションが「Yes」に設定されます。
「計画資源リスト」ページで、資源計画リストに正常に移行された既存の資源リストを表示できます。また、計画資源が資源リストのメンバーと同じであることも確認できます。
また、「資源分解構造」ページには、資源リストと同じ名称を持つ資源分解構造が表示されます。資源分解構造の各ノードが資源リストのメンバーと同じであり、資源リストがグループ化されていた場合は同じ2レベル階層になっていることを確認します。
既存の労務費計算ルールには、次の追加属性がデフォルト値とともに含まれる必要があります。
原価計算方法: 標準
見越の有効化: No
有効化 計画: Yes
レート・ソース: プロジェクト
合計時間 原価計算: No
この項では、Oracle Supply Chain Management製品ファミリのアップグレード検証タスクを説明します。
これらのタスクは、Oracle Cost Managementにのみ適用されます。
Subledger Accountingと正常に統合されたことと、データに不一致がないことを確認するステップは、次のとおりです。
アップグレード前の取引の会計イベントがSubledger Accounting (SLA) のイベント・ページで使用できることを確認します。これらの会計イベントについて、対応する仕訳 (ヘッダーと明細) を確認して照合します。
次のレポートを使用して、アップグレード前の会計仕訳から導出された残高と値を表示します。
| レポート名 | 用途 |
|---|---|
| 材料費配分 (詳細および要約) | 在庫取引に賦課された勘定の表示 |
| WIP勘定配分レポート (詳細および要約) | WIP取引の勘定情報の表示 |
| ショップ型製造オーダー・レポート - 平均原価計算およびショップ型製造オーダー・レポート - 標準原価計算 | 各製造オーダーの手数料および差異の裏付けとなる取引要約の分析 |
| 受入会計取引明細レポート | 受入取引の勘定配分の表示 |
「仕訳レポート - 原価管理」を使用して、SLA内でアップグレードされた会計仕訳を組織別および会計区分別に要約します。組織レベルの要約勘定残高を、ステップ2の表にリストしたレポートとSLAの「仕訳入力」レポートの間で比較します。
次のタスクは、Oracle Order Managementにのみ適用されます。
アップグレード・プロセスでは自動的にレポート (ontexc16.lst) が生成され、前払オーダー、システム・パラメータへのプロファイル移動、およびOrder Managementデフォルト・ルールのアップグレードに関する推奨事項、またはそれぞれの実行中に発生したエラーが示されます。このレポートは$APPL_TOP/admin/<SID>SID>/out (UNIX) または%APPL_TOP%\admin\<SID>SID>\out (Windows) にあり、<SID>はORACLE_SIDまたはTWO_TASKの値です。
アップグレードが完了し、Oracle Order Managementを使用する前に、このレポートを検討し、検出された問題があれば解決する必要があります。
次のタスクは、Oracle Product Hubに適用されます。
既存のユーザー定義の属性グループに対して品目または品目改訂ビジネス・エンティティを有効化する必要があります。
シード済の標準運用属性グループは品目組織ビジネス・エンティティでのみ有効化する必要があります。
標準運用属性の既存のシード済ページは品目組織レベルで使用可能にする必要があります。
既存の新規品目要求は変換され、品目の詳細とともに明細が作成されます。NIR明細ステータスはNIRステータスと同じになります。
Copyright © 1996, 2013, Oracle and/or its affiliates.All rights reserved.