リリース12
E06012-01
目次
前へ
次へ
| Oracle Advanced Supply Chain Planningインプリメンテーションおよびユーザーズ・ガイド リリース12 E06012-01 | 目次 | 前へ | 次へ |
この章のトピックは、次のとおりです。
Oracle ASCPは、Oracle ASCPの単一インスタンスで1つ以上の取引インスタンスを計画できるコンポーネント・アーキテクチャを備えています。取引インスタンスには混在するリリースを併用できます。Oracle ASCPの計画インスタンス（計画サーバー）は、取引インスタンスと同じインスタンスに配置する方法と、まったく異なるインスタンスを使用する方法があります。いずれの場合も（計画サーバーと計画対象の取引インスタンス間でインスタンスを共有する場合も）、計画対象のデータは収集と呼ばれるプロセスを介して取引インスタンスから計画サーバーに取り込まれます。
この項では、複数の運用ソースからOracle ASCPに計画データを収集する際に使用されるアーキテクチャについて説明します。これらのソースには、Oracle Applicationsの異なるバージョンやインスタンス、または他のレガシー・システムを使用できます。Oracle ASCPでは、インタフェース表を介して公開される計画データ・モデルに基づいて、データ・ストアを使用します。データは指定のデータ・ソースからデータ・ストアにプルされます。Oracle ASCPの「収集」は、データ・ソースが変更される際の同期化を受け持ちます。収集の構成可能性は、AOLコンカレント・プログラム・アーキテクチャに基づくプル・プログラムを介して有効化されます。そのため、たとえば様々なビジネス・オブジェクトを異なる頻度で収集できます。頻繁に変化する供給と需要は頻繁に収集できます。変化の頻度が比較的少ない工順と生産資源は、低い頻度で収集できます。
データ収集プロセスは、「データ・プル」と「工程データ格納ロード」（ODSロード）で構成されています。収集プロセスでは、複数のOracle Applicationsバージョン間での収集が可能で、複数の構成がサポートされています。収集プロセスには、標準および継続という2つのタイプがあります。
標準収集プロセス: 標準収集プロセスを使用すると、3タイプの収集方法（完全リフレッシュ、ネット・チェンジ・リフレッシュ、または特定のビジネス・エンティティを対象とした指定リフレッシュ）を手動で実行できます。
継続収集プロセス: 継続収集プロセスは、ソースを検索することで計画サーバー上のデータを効率的に同期化する、自動化されたデータ収集プロセスです。継続収集を選択した場合、選択したエンティティに対して実行する必要のある収集のタイプはシステムにより自動的に判別されます。継続収集プロセスでは、最小限のユーザー介入でデータがソースから収集されます。継続収集は「継続収集」コンカレント・プログラムにより実行されます。
通貨: Oracle Order ManagementとOracle Purchasingから収集された通貨は、ソースに取引通貨が使用されていても機能通貨で転記されます。
ショップ型製造オーダー: 完了済でクローズされていないショップ型製造オーダーは、収集データに数量0（ゼロ）で表示されます。完了済でクローズ済のショップ型製造オーダーは、収集データに表示されません。
直接出荷発注: 計画エンジンでは直接出荷受注が計画されないため、収集プロセスでは直接出荷発注に対する供給は収集されません。
最終品目代替: 代替セットを定義していない場合は、「収集ワークベンチ」で最終品目代替を確認できます。代替セットを定義済の場合、代替セットと最終品目代替を確認するには「プランナ・ワークベンチ」の「品目」ウィンドウを使用します。
グローバル予測: 「収集ワークベンチ」の水平プランで「当初」および「累積当初」行を使用して、グローバル予測入力を検討できます。
無効な予測: 収集プロセスを「完全リフレッシュ」または「指定リフレッシュ」収集モードで実行すると、無効な予測の需要は収集されません。
工順: 収集プロセスでは、「計画」が「No」の工順工程生産資源は収集されず、工順に表示されません。また、「計画」が「No」の主生産資源の代替生産資源は、代替生産資源自体の「計画」が「Yes」に設定されていても収集されません。
データ収集アーキテクチャを調べる前に、次の用語をよく理解しておく必要があります。
Oracle Applicationsデータ・ストア（ADS）: 計画に関連するデータを含んだ各取引インスタンス内のソース・データ表セット。
工程データ格納（ODS）: 各データ・ソース（ADSとレガシーの両方）から収集されたデータの宛先として機能する、計画サーバー内の計画データ表。
計画データ格納（PDS）: 計画プロセスの出力。PDSはODSと同じデータ表にあります。ただし、PDSデータには対応する計画を示す計画IDが付いていますが、ODSデータの計画IDは-1となっています。
標準データ収集: 標準データ収集プロセスでは、データ収集モードとして完全リフレッシュ、増分リフレッシュまたは指定リフレッシュのいずれかを選択できます。標準データ収集は、次のプロセスで構成されています。
プル・プログラム: ADSからデータを収集してステージング表に格納します。このプル・プログラムは、システム管理者がスケジュールして起動できる登録済AOLコンカレント・プログラムです。レガシー・プログラムを使用している場合は、独自のプル・プログラムを記述する必要があります。
ODSロード: データ変換を実行して、データをステージング表からODSに移動するPL/SQLプログラム。この収集プログラムは、システム管理者がスケジュールして起動できる登録済AOLコンカレント・プログラムです。
継続データ収集: 継続データ収集プロセスでは、ソースを検索して計画サーバー上の表に移入するプロセスが自動化されます。継続データ収集プロセスの場合、最小限のユーザー介入により、各種エンティティに対して実行する収集のタイプが判別されます。継続収集は「継続収集」コンカレント・プロセスにより実行されます。
収集ワークベンチ: 「収集ワークベンチ」は、取引インスタンスから計画サーバーに収集されたデータを表示するためのユーザー・インタフェースです。ここでの機能は「プランナ・ワークベンチ」の機能に類似しています。「プランナ・ワークベンチ」の詳細は、「プランナ・ワークベンチの概要」を参照してください。
収集プロセスの主要な機能は、次のとおりです。
複数のソース・インスタンス
プル・アーキテクチャ
ネット変更の検出によるOracle ApplicationsとOracle ASCPの同期化
マルチプロセス収集アーキテクチャ
データの連結
プロジェクト/タスクおよびセイバン番号
複数のOracle ApplicationsバージョンとRDBMSバージョンのサポート
複数構成のサポート
各Oracle ASCPインストール環境で、必要な数のソース・データ・インスタンスとOracle以外のデータ・ソースを登録できます。
影響を最小限に抑えて新規ソース・データ・インスタンスをOracle ASCPに収集できます。データはOracle ASCPによりソース・データ・インスタンスからプルされます。インスタンスごとに固有のリフレッシュ間隔を設定できます。あるインスタンスでの失敗が他のインスタンスからのデータ収集に影響することはありません。
Oracle Applications取引インスタンス内のデータとOracle ASCP計画サーバーをネット・チェンジ・モードで同期化できます。したがって、変更されたソース・データのみが毎回収集され、収集プロセスに伴う演算上の負荷が軽減されます。
タスクを複数の収集ワーカーに分散することで、プル・プログラムのパフォーマンスを強化できます。
収集プログラムでは、対応するユーザー定義キーに基づいて、次の表に示すエンティティをインスタンス間で連結できます。
| エンティティ | ユーザー・キー |
|---|---|
| MTL_SYSTEM_ITEMS | 連結品目セグメント |
| MTL_CATEGORIES | 連結カテゴリ名 |
| MTL_CATEGORY_SETS | カテゴリ・セット名 |
| PO_VENDORS | 仕入先名 |
| PO_VENDOR_SITES | 仕入先サイト・コード |
| RA_CUSTOMERS | 顧客名 |
| RA_SITE_USES_ALL | 顧客名、サイト使用コード、事業所営業単位 |
| 単位 | 単位コード |
この表に示されていない全エンティティについては、インスタンスIDと各インスタンス内のエンティティ・キーにより各行が一意に識別されます。
Oracle Applicationsインスタンスのコンテキスト内では、プロジェクト、タスクおよびセイバン番号が一意であるとみなすことができます。連結は不要です。
企業の規模や特定のビジネス・ニーズに基づいて、集中型構成と分散型構成を実行できます。ソース・データ・アプリケーションとOracle ASCPを単一サーバーに常駐させる方法と、個別サーバーに常駐させる方法があります。
次の図に示すOracle ASCPのデータ収集アーキテクチャは、ソース・データとOracle ASCPの間のデータ・オブジェクト、プロシージャおよびデータ・フローを示しています。主要リポジトリはADS、ODSおよびPDSです。プロシージャにより、データ・リポジトリ間のデータ整備、データ収集、データ通信およびネット・チェンジ処理が有効化されます。
Oracle ASCPとソース・データが同一インスタンス上にある場合、両者間の通信はPL/SQLベースのパブリックAPIプロシージャまたはインタフェース表により有効化されます。分散環境では、プロシージャ・コールにデータベース・リンクが使用されます。
データ収集アーキテクチャ
Oracle ASCPでは、インストールと配置に関して次の計画構成がサポートされています。
集中型
分散型
これらの構成は、ビジネスの目的に即した計画モードを設計する上で十分な柔軟性を備えています。どちらの構成も、前述のように一貫したアーキテクチャを使用してサポートされています。唯一の違いは、集中型計画ではOracle ASCPデータ・ストアにデータをプルする際にデータベース・リンクが使用されることです。
次の図は、分散型計画構成を示しています。
Oracle ASCPは、複数のソース・データ・インスタンス間の集中計画サーバーとして稼働します。収集プログラムは計画サーバーにインストールされ、インスタンスにより取得されたデータはデータ収集プロセス中にOracle ASCP内のステージング表に移動されます。
計画プロセスの後、結果を各インスタンスにプッシュできます。
次の図は、集中型計画構成を示しています。
Oracle ASCPとそのソース・データは、同じデータベースに常駐しています。この場合、データベース・リンクは不要です。2つのコンポーネントは、計画オブジェクトAPIとOracle Applications内で定義されているインタフェース表を介して通信できます。
この構成では、次の図のように簡略化されたアーキテクチャが使用され、データ変換は不要です。
簡略化されたデータ収集アーキテクチャ
Oracle8iデータベースを含む分散環境で完全収集を実行する場合は、「計画データ・プル」コンカレント・プロセスでの自律型トランザクション・エラーを防止するために、ソース・インスタンス内で各プロファイル・オプションの値を次のように設定する必要があります。
FND: ログ使用可能: No
MO: セキュリティ・プロファイル: NULL
MO: デフォルト営業単位: NULL
MO: 分散環境: Yes
OM: デバッグ・レベル: NULL
Oracle9iリリース2（9.2）データベース以降は、自律型トランザクションはデータベースにより処理されます。
データ収集には、計画サイクル全体の所要時間に比べて長時間かかることがあります。Oracle Advanced Supply Chain Planning（ASCP）には、計画サーバー上にある一部の（すべてではなく）計画関連ビジネス・エンティティに関する情報の更新が必要になった場合に、収集期間を短縮できる収集方法が用意されています。
次の3つの収集方法があります。
「完全リフレッシュ」方法では、全ビジネス・エンティティの全取引データが（収集対象のソース・インスタンスに関して）計画サーバーから消去された後、ユーザーが選択したエンティティに関する情報が上書きコピーされます。この方法には時間がかかることがあります。
「指定リフレッシュ」方法では、ユーザーが選択したビジネス・エンティティの取引データのみが計画サーバーから消去された後、取引インスタンスからのエンティティ情報が上書きコピーされます。選択しなかったエンティティに関する情報は、そのまま計画サーバーに残ります。「指定リフレッシュ」による収集では、計画対象のビジネス・エンティティがすべてサポートされています。エンティティ「取引先」に対して指定リフレッシュを実行する場合は、エンティティ「カレンダ」も収集します。これにより、Oracle Advanced Supply Chain PlanningからOracle Project Manufacturingへのリリース処理に成功するように、Oracle Project Manufacturing組織が「プロセス」組織タイプとして設定されることが保証されます。
「ネット・チェンジ・リフレッシュ」方法では、ビジネス・エンティティに対する増分変更のみが計画サーバーにコピーされます（したがって高速です）が、主として需要および供給のビジネス・エンティティについてのみサポートされています。
ソース・インスタンスから計画サーバーへの収集を初めて実行する際には、「完全リフレッシュ」を使用する必要があります。取引システムの設定データの大部分が変更された後、すべてのソース・インスタンス・ビジネス・エンティティ（品目、部品構成表、ソース・ルール、生産資源など）の最新コピーが計画サーバー上で必要な場合も、「完全リフレッシュ」収集を使用できます。通常、「完全リフレッシュ」収集ではすべてのビジネス・エンティティを収集します。
計画サーバー上の需要および供給データをできるかぎりすばやく更新する必要があり、前回の収集以後にソース・インスタンス上で需要および供給に対して行われた増分変更が需要/供給情報の既存（収集済）部分に比べて広範囲でない場合は、「ネット・チェンジ・リフレッシュ」を使用する必要があります。この場合、計画サーバーの工程データ・ストアに必要な更新を実行するには、「ネット・チェンジ・リフレッシュ」が最も高速な方法です。これは、「ネット・チェンジ・リフレッシュ」では、前回の収集以後に需要および供給に対して行われた増分変更のみがソース・インスタンスから上書きコピーされるためです。
一部の（すべてではなく）ビジネス・エンティティに関する計画サーバー情報を更新する必要があり、対象エンティティの一部が「ネット・チェンジ・リフレッシュ」でサポートされる需要および供給エンティティのカテゴリに含まれていない場合は、「指定リフレッシュ」を使用する必要があります。たとえば、計画サーバーを新規に再作成された製造カレンダで更新するには、カレンダ・ビジネス・エンティティに対してのみ「指定リフレッシュ」収集を実行します。この収集では、計画サーバー上にある他の全ビジネス・エンティティに関するデータは影響を受けません。
また、前回の収集以後にソース・インスタンス上で需要および供給に対して広範囲な増分変更が行われた場合は、最新の需要/供給データを計画サーバーに取り込むために、「指定リフレッシュ」を（「ネット・チェンジ・リフレッシュ」のかわりに）使用します。この場合、「指定リフレッシュ」収集に採用されている更新メカニズム（全体を削除してから計画サーバー上でデータを再作成）の方が、「ネット・チェンジ・リフレッシュ」収集に採用されているメカニズム（計画サーバー上の既存データに増分挿入）よりも高速です。
データ収集モードをシステムに判別させる場合は、「継続収集」を選択します。
「アドバンスト・サプライ・チェーン計画担当」または「アドバンスト・プランニング管理者」職責でサインオンします。
「収集」->「Oracleシステム」->「標準収集」を選択して「計画データ収集」ウィンドウにナビゲートします。
「計画データ収集」ウィンドウが表示されます。
「計画データ収集」ウィンドウ
このウィンドウは、収集プロセスが連続して実行された2つのコンカレント・プログラムで構成されていることを示しています。最初のプログラム「計画データ・プル」では、ソース・インスタンスから計画サーバー上のAPSステージング表に情報がコピーされます。ここで、ステージング表に保持されているデータに対して、ASCPによりなんらかの基本的な整備が実行されます。たとえば、異なるソース・インスタンスから収集された同一名称の品目に同じ内部IDが割当てられている（同一品目として認識されている）ことが確認されます。この時点で、なんらかのカスタム・コンカレント・プログラムを介して、ステージング表に対する付加的な整備操作を実行することもできます（必要な場合）。このカスタム・コンカレント・プログラムは、「計画データ収集」要求セットの「計画データ・プル」と「計画ODSロード」の間に挿入する必要があります。第2のプログラム「計画ODSロード」では、APSステージング表から計画サーバー上の工程データ・ストアに情報がコピーされ、そこで計画中に使用可能になります。
「計画データ・プル」プログラムの「パラメータ」フィールドを選択します。
「計画データ・プル」プログラムの「パラメータ」ウィンドウが表示されます。
「計画データ・プル」プログラムの「パラメータ」ウィンドウ
次の表を参考にして、「計画データ・プル」プログラムの「パラメータ」ウィンドウでパラメータを設定します。
| パラメータ | 値 |
|---|---|
| インスタンス | 値リストからソース・インスタンス・コードを選択します。 |
| ワーカー数 | 1以上を指定します。「計画データ・プル」プロセスに使用できる演算リソース量を増やすには、この値を大きくします。これにより、「データ・プル」用のワーカー数に、「ODSロード」プロセス用に指定されているワーカー数とは異なる値を指定できます。 |
| タイムアウト（分） | 「計画データ・プル」プロセスに割当てる最大時間。指定した時間内に完了しないと、このプロセスはエラーを戻して終了します。 |
| 以前に収集されたデータのパージ | 「Yes」（デフォルト）または「No」。「Yes」に設定すると、収集処理の第1ステップとして、選択したソース・インスタンスに関連したAPS計画サーバーの工程データ・ストアから、すべてのデータがパージされます。「Yes」に設定した場合に選択できる収集方法は、「完全リフレッシュ」のみです。このパラメータを「No」に設定した場合は、収集方法として「指定置換」または「ネット・チェンジ」を選択できます。 |
| 収集方法 | 「完全リフレッシュ」、「指定リフレッシュ」または「ネット・チェンジ・リフレッシュ」。 |
| ステージング表の分析 | 「Yes」または「No」（デフォルト）。「Yes」に設定すると、APSステージング表のデータベース・アクセス統計が定期的に再計算されます。この設定により、以降の「計画ODSロード」プロセスが高速になります。 |
| ユーザー会社関連 | 有効な値は、次のとおりです。
|
「計画データ・プル」プログラムの「パラメータ」ウィンドウの残りのパラメータは、ビジネス・エンティティのリストです。エンティティについて「Yes」を選択すると、そのエンティティに関する情報がソース・インスタンスから収集されます。「No」を選択すると、そのエンティティに関する情報はソース・インスタンスから収集されません。
注意: これらのエンティティの場合、デフォルト値は「Yes」に設定されます。「生産資源可用性」と「ソーシング履歴」の情報収集には長時間かかります。この情報は、必要な場合にのみ収集してください。
「OK」を選択します。
「計画ODSロード」プログラムの「パラメータ」フィールドを選択します。
「パラメータ」ウィンドウが表示されます。
「計画ODSロード」の「パラメータ」ウィンドウ
次の表を参考にして、このウィンドウの各フィールドとオプションを指定します。
「OK」を選択します。
「計画データ収集」ウィンドウで、「発行」を選択して即時に収集を実行するか、または「計画」を選択して後からの収集を計画します。
「計画」を選択すると、「計画」ウィンドウが表示されます。
注意: 増分リフレッシュを頻繁に実行する必要がある場合は、この機能を使用してください。
「計画」ウィンドウ
取引システムからのデータ収集のタイミングと頻度、および計画のタイミングと頻度の管理が完了しました。ネットワーク通信量と、計画の現行ステータスをモニターする必要性とのバランスを管理できます。
「OK」をクリックします。
「計画データ収集」ウィンドウで「発行」を選択します。
ツールバーから「表示」->「要求」を選択して、収集プロセスのステータスを表示します。
「要求の検索」ウィンドウが表示されます。
表示する要求のタイプを選択し、「検索」を選択します。
「要求」ウィンドウにデータ収集の進行状況が表示されます。
収集プロセスの完了後に、結果を表示します。
「スナップショットのリフレッシュ」コンカレント・プロセスが警告で終了し、受注構成品目がある場合は、その品目の設定に問題がある可能性があります。このコンカレント・プロセスでは、受注構成APIがコールされ、構成済の部品構成表が展開されて、正しい製造組織に需要が作成されます。設定の問題の詳細を受注構成APIのログ・ファイルで確認し、訂正処理を実行してください。
収集プロセスをOracle8iデータベース上で実行して失敗した場合は、次のトラブルシューティング情報を参照してください。
「データ・プル」または「計画データ・プル・ワーカー」の実行中のいずれかの時点、または「スナップショットのリフレッシュ」の起動時に、「分散データベース内の自律型トランザクション」のエラーで失敗する場合は、プロファイル・オプション「FND: ログ使用可能」を「No」に設定します。
受注または確定在庫引当の収集時に「計画データ・プル・ワーカー」で失敗する場合は、プロファイル・オプション「OM: デバッグ・レベル」をNULL値または5未満の値に設定します。
「ナビゲータ」ウィンドウで、「収集」->「ワークベンチ」を選択します。
「収集ワークベンチ」
選択したインスタンスからデータが取り込まれていることがわかります。
注意: ユーザーは、計画サーバーに予測を収集できます。収集プログラムで需要予測セットを収集する場合は、需要予測セットを定義する際に「アドバンスト・プランニング収集」チェック・ボックスを選択します。
ネット・チェンジ収集モードを選択（収集パラメータ「完全リフレッシュ」を「No」に設定）すると、次の表に示すデータ変更を収集できます。収集パラメータ「完全リフレッシュ」を「Yes」に設定すると、収集プログラムではエンティティに関するデータ全体が収集されます。
他のすべてのデータ変更は、完全収集を実行（収集パラメータ「完全リフレッシュ」を「Yes」に設定）して収集する必要があります。ネット・チェンジ収集の方が完全収集よりも高速で実行されます。
次の取引のデータ収集は、ネット・チェンジ・モードで実行できます。
| データ要素 | 注釈 |
|---|---|
| 受注 | 受注の取消または変更が取得されます。「プル受注」収集パラメータを「Yes」に設定する必要があります。 |
| 需要に対する予約 | 外部受注および社内受注に対する予約が取得されます。「プル予約」収集パラメータを「Yes」に設定する必要があります。 |
| 基準生産計画需要 | ソース・インスタンスで追加、変更またはリリーフされたMPS需要が取得されます。「プルMPS」収集パラメータを「Yes」に設定する必要があります。 |
| 基準需要計画 | 「プルMDS」収集パラメータを「Yes」に設定する必要があります。 |
| WIP構成部品需要 | WIP製造オーダーの取消、WIP製造オーダーのステータス変更（製造オーダー内の工程が実行または取り消されたなど）および品目情報の変更に伴うWIP製造オーダーの変更による、需要変更が取得されます。「プル仕掛品」収集パラメータを「Yes」に設定する必要があります。 |
| WIPライン型品目需要 | WIPライン型製造オーダーの取消、WIPライン型製造オーダーのステータス変更および品目情報の変更に伴うWIPライン型製造オーダーの変更による、需要変更が取得されます。「プル仕掛品」収集パラメータを「Yes」に設定する必要があります。 |
| 予測需要 | 予測の変更と削除が取得されます。「プル需要予測」収集パラメータを「Yes」に設定する必要があります。 |
| ユーザー需要 | 品目情報の変更に伴うユーザー需要の変更が取得されます。 |
| 基準生産計画供給 | 供給計画または品目情報の変更が取得されます。「プルMPS」収集パラメータを「Yes」に設定する必要があります。 |
| ユーザー供給 | 品目情報の変更に伴うユーザー供給の変更が取得されます。 |
| 発注供給 | 拒否、返品、取消または品目情報の変更に伴う発注供給の変更が取得されます。「プル発注」収集パラメータを「Yes」に設定する必要があります。 |
| 在庫数量供給 | 「プル在庫数量」収集パラメータを「Yes」に設定する必要があります。 |
| Oracle Work in Processの作業指示 | WIP製造オーダーの変更が取得されます。「プル仕掛品」収集パラメータを「Yes」に設定する必要があります。 |
| 生産資源可用性 | 「NRAの再計算」収集パラメータを「Yes」に設定する必要があります。 |
| 仕入先生産能力 | 「プル仕入先生産能力」収集パラメータを「Yes」に設定する必要があります。 |
| 部品構成表 | すべての部品構成表変更（新規構成部品、使用不可の構成部品、構成部品数量、有効日、BOM改訂および構成部品代替）が取得されます。「プル BOM/工順」収集パラメータを「Yes」に設定する必要があります。 |
| 工順工程 | 工程連番の変更（新規工程の追加、工程の無効化または工程日付の変更など）、工順の無効化、工順日付の変更、品目情報の変更（品目の無効化、新規品目の作成など）による、工順工程の変更と削除が取得されます。「プル BOM/工順」収集パラメータを「Yes」に設定する必要があります。 |
| 工順工程に必要な構成部品 | 工順工程に必要な構成部品の変更と削除が取得されます。「プル BOM/工順」収集パラメータを「Yes」に設定する必要があります。 |
| 工順工程に付随する生産資源 | 工順内の工程生産資源または工程生産資源連番の変更と削除が取得されます。「プル BOM/工順」収集パラメータを「Yes」に設定する必要があります。 |
| WIP製造オーダーの生産資源所要量 | WIP製造オーダーの完了、WIP製造オーダー内の工程の完了または品目情報の変更による、WIP製造オーダーの生産資源所要量の変更が取得されます。「プル仕掛品」収集パラメータを「Yes」に設定する必要があります。 |
| 品目または品目カテゴリ | 品目と品目カテゴリの変更が取得されます。 |
| 生産能力 | 仕入先生産能力と生産資源生産能力の変更が取得されます。 |
取引（需要と供給）は、設定エンティティよりも頻繁に変更されます。データ収集後、収集プログラムにより取引エンティティのスナップショットが保守されます。データ収集を実行するたびに、収集プログラムによりスナップショットが検索され、前回の収集以後に取引エンティティに変更があったかどうかが判別されます。変更があった場合は、収集プログラムにより増分データ変更が収集され、スナップショットが更新されます。設定エンティティの方が変更頻度が低いため、収集プロセスでは設定エンティティのスナップショットは保持されず、ネット・チェンジ収集も実行できません。設定については、指定リフレッシュまたは完全リフレッシュを計画してください。
次の設定エンティティの場合、ネット・チェンジ・モードによるデータ収集は実行できません。
カテゴリ・セット
デフォルト品目カテゴリ
シミュレーション・セット
部門生産資源
生産資源シフト設定
確定在庫引当
プロジェクトまたはプロジェクト・タスク
単位（区分換算、換算）
ソーシング情報
生産資源構成表
カレンダ情報（開始日、カレンダ日、カレンダ週、カレンダ・シフト、シフト日付、シフト例外、シフト時間、期間開始日）
組織間出荷方法
パラメータ
計画担当
ビジネス・インテリジェンス・システムの期間
発注の仕入先
生産資源グループ
需要区分
仕入先フレックス・フェンス
ATPルール
取引先（顧客または顧客サイト、仕入先、仕入先サイト、組織、組織サイト、事業所関連、顧客、仕入先、購買担当、担当）
継続収集は、スナップショット対応のデータ・エンティティ（需要と供給）およびスナップショット非対応の設定エンティティ（仕入先、顧客および仕入先ルール）を、ソースと計画サーバーの間で同期化する自動化プロセスです。データ・エンティティと設定エンティティの収集用に個別の収集プログラムを計画できます。
継続収集のプロセスは、「継続収集」コンカレント・プログラムにより実行されます。収集プロセスを自動的に実行する必要のあるビジネス・エンティティのみを選択する必要があります。選択したビジネス・エンティティに適切な収集実行モードは、「継続収集」コンカレント・プログラムにより決定されます。継続収集は次のエンティティに対して実行できます。
スナップショットがソースに関連付けられているエンティティの場合は、しきい値（パーセント）を指定する必要があります。「継続収集」コンカレント・プログラムでは、この値に基づいて収集の実行モード（「指定リフレッシュ」または「ネット・チェンジ・リフレッシュ」）が決定されます。継続収集を頻繁に実行すると、ほとんどのエンティティのデータ収集が「ネット・チェンジ・リフレッシュ」モードで実行されます。
変更があったレコードの比率がしきい率を下回っている場合、コンカレント・プロセスでは変更があったレコードのみがスナップショット・ログから収集されます（ネット・チェンジ・リフレッシュ）。
変更があったレコードの比率がしきい率を上回っている場合、コンカレント・プロセスではスナップショットからすべての行が収集されます（指定変更リフレッシュ）。
変更があったレコードがなければ、コンカレント・プロセスではデータが収集されません。
次の表に、継続収集のサポート対象エンティティにスナップショットが関連付けられているかどうかを示します。
| エンティティ | スナップショットの関連付け |
|---|---|
| 承認済仕入先リスト（仕入先生産能力） | Yes |
| 部品構成表 | Yes |
| 工順 | Yes |
| 生産資源 | Yes |
| 生産資源構成表 | Yes |
| 需要予測 | Yes |
| 品目 | Yes |
| 基準需要計画 | Yes |
| 基準生産計画 | Yes |
| 手持在庫数量 | Yes |
| 発注 | Yes |
| 購買依頼 | Yes |
| 受注 | Yes |
| ユーザー供給および需要 | Yes |
| 仕掛 | Yes |
| ATPルール | No |
| カレンダ | No |
| 需要区分 | No |
| 最終品目代替 | No |
| キー・パフォーマンス・インディケータ・ターゲット | No |
| 計画パラメータ | No |
| 計画担当 | No |
| プロジェクトおよびタスク | No |
| 予約 | No |
| 生産資源可用性 | No |
| 安全在庫 | No |
| ソーシング履歴 | No |
| ソース・ルール | No |
| 保管場所 | No |
| 取引先（顧客および仕入先） | No |
| ユニット番号 | No |
| 単位 | No |
| ユーザー会社関連 | No |
スナップショットが関連付けられていないエンティティの場合、コンカレント・プログラムでは常に指定リフレッシュが開始されます。
大量の取引が関係する場合は、継続収集を使用するように計画できます。たとえば、大量の仕掛取引が発生する製造会社では、20分間隔で実行するように継続収集を設定して手持残高を収集できます。同様に、Oracle Collaborative Planningユーザーが現行の供給ステータスを確認する必要がある場合は、継続収集を2分間隔で実行するように計画できます。
「アドバンスト・サプライ・チェーン計画担当」または「アドバンスト・プランニング管理者」職責でサインオンします。
ナビゲータから、「収集」->「Oracleシステム」->「継続収集」を選択します。
「継続収集」ウィンドウが表示されます。
「継続収集」ウィンドウ
このウィンドウを使用すると、データ収集プロセスを計画し、継続収集の実行に必要なパラメータを設定し、言語作業環境を選択し、継続収集の完了時にトリガーする必要のある通知タスクを指定できます。
「パラメータ」フィールドをクリックし、コンカレント・プログラムで継続収集を実行するために必要な値を設定します。
「パラメータ」ウィンドウが表示されます。
「パラメータ」ウィンドウ
「継続収集」コンカレント・プログラムに収集対象とみなさせるエンティティについて、「Yes」を指定します。このウィンドウのほとんどのフィールドは、「標準収集」プロセスのパラメータ・フィールドと同様です。「継続収集」プロセスを「標準収集」プロセスと区別するパラメータは、「スナップショットしきい値 (%)」です。デフォルトでは、しきい値は40%に設定されます。この値は変更できます。
「OK」を選択します。
「継続収集」ウィンドウで「計画」を選択し、収集を計画します。
「計画」ウィンドウが表示されます。
「計画」ウィンドウ
左ペインで収集の実行頻度を選択します。選択内容に基づいて追加表示される他のフィールドを完了します。
「OK」をクリックします。
「継続収集」ウィンドウで「発行」を選択します。
ツールバーから「表示」->「要求」を選択して、収集プロセスのステータスを表示します。
「要求の検索」ウィンドウが表示されます。
「要求の検索」ウィンドウ
表示する要求のタイプを指定します。
「検索」を選択します。
「要求」ウィンドウに、データ収集プロセスのステータスが表示されます。
「要求」ウィンドウ
収集プロセスの完了後に、「収集ワークベンチ」ウィンドウで結果を確認します。
レガシー収集は、コンサルティングおよびシステム・インテグレータがレガシー・システムからOracle APS/CPにデータを取り込めるように、オープン・フレームワークを提供します。フラット・ファイルのバッチ・アップロードによりデータをアップロードできます。この処理の一部は、インタフェース表機能を拡張することで実行されます。レガシー・アプリケーションから取り込まれたデータは前処理エンジンにより検証され、参照整合性が維持されていることが確認されます。すべてのビジネス・オブジェクトは、フラット・ファイルを使用してAPSにインポートできます。
ERPインスタンスから計画インスタンスにデータを収集するのみでなく、次のシステムからも計画インスタンスにデータを収集できます。
Oracle以外の（レガシー）システム
取引先の、Oracle以外のシステム
Oracle以外のERPシステムまたは取引先のシステムからデータを収集するには、Oracle以外の各ERPシステムまたは取引先をOracle Applications組織としてモデル化し、それぞれの設定と取引データを格納する必要があります。設定情報には、組織設定、品目、部品構成表、生産資源、工順およびソーシング情報などが含まれます。取引データのタイプは、次のとおりです。
手持残高
発注
購買依頼
作業指示
作業指示の構成部品需要
移動中出荷および受入
計画オーダー
ローカル予測
グローバル予測
需要計画
受注
品目仕入先
仕入先生産能力
仕入先フレックス・フェンス
次の手順を実行して、取引先のOracle以外のシステムから計画インスタンスにデータを収集できます。
取引先のシステムから、設定データ（品目、部品構成表、取引先など）をフラット・ファイルにロードします。このフラット・ファイルを、標準インタフェースを使用してソース（Oracle ERP）インスタンスにロードし、標準収集を使用して宛先（計画）サーバーに移動します。
フラット・ファイルから、取引データを計画サーバーのERPインスタンス（Oracle ERPシステムのデータの表現）にロードします。レガシー収集を使用して、データをレガシー・インスタンスから計画サーバーに移動します。
次のダイアグラムに、Oracle以外のERP（レガシー）システムからOracle ERPアプリケーションおよび計画サーバーへのデータ・フローを示します。
データ・フロー
ソース・インスタンス内で2種類の組織を定義します。最初の組織はOEM用で、第2の組織は仕入先および顧客用です。OEM組織と仕入先および顧客組織間のソース・ルールも定義する必要があります。
品目オープン・インタフェースやBOMオープン・インタフェースなどのOracle ERPオープン・インタフェースを使用して、Oracle以外のERPシステムから仕入先および顧客組織に設定データをインポートします。
取引先の組織をロードするには、前回のロード時に取引先を定義しておく必要があります。
OEMと仕入先および顧客組織からの全データを、宛先インスタンス（計画サーバー）に収集します。
各仕入先および顧客組織のフラット・ファイルに取引データをロードします。Oracle Applicationsフォームまたはセルフ・サービス・アプリケーションを使用すると、Oracle以外のERPシステムから組織にデータをロードできます。セルフ・サービス方法を使用する場合は、全データを含んだzipファイルをアップロードできます。
バッチ・アップロードを使用して、レガシー・データ（品目、部品構成表、工順など）をOracle APSインタフェース表にプッシュします。バッチ・アップロードは、Oracle SQL*Loaderを使用して実行されます。SQL*Loaderでは、制御ファイルに記述されたフォーマットでデータが取り込まれる必要があります。オラクル社は、すべてのインタフェース表の制御ファイルを提供しています。制御ファイルのリストは、Oracle iSupportから入手できます。
次のダイアグラムに、「バッチ・アップロード」プロセスを使用し、インタフェース表を介して、レガシー・システムからOracle APSサーバーにデータを移動する様子を示します。
レガシー・アプリケーション
システム・インテグレータは、次の手順でバッチ・アップロードを設定する必要があります。
Oracle APSインタフェース表の制御ファイル（入力データのフォーマットを指定するテンプレート）を、レガシー・システムの表にマップします。制御ファイルのリストは、Oracle iSupportから入手できます。
レガシー・システムからデータを抽出するスクリプトを、制御ファイルに規定されたフォーマットで作成します。
取引先サイトをロードする場合は、組織の事業所の値を入力します（取引先タイプ=3）。顧客および仕入先サイトの場合は、事業所の値を入力しないでください（取引先タイプ=1または2）。
たとえば、発注供給の制御ファイル（MSC_ST_SUPPLIES_PO.ctl）は次のようになります。
OPTIONS (BINDSIZE=1000000, ROWS=1000, SILENT=(FEEDBACK,DISCARDS))
LOAD DATA
INFILE 'MSC_ST_SUPPLIES_PO.DAT'
APPEND
INTO TABLE MSC.MSC_ST_SUPPLIES
FIELDS TERMINATED BY '~'
(
ITEM_NAME,
ORGANIZATION_CODE,
NEW_SCHEDULE_DATE,
SUPPLIER_NAME,
FIRM_PLANNED_TYPE" NVL(:FIRM_PLANNED_TYPE,1)",
SUPPLIER_SITE_CODE,
PURCH_LINE_NUM,
ORDER_NUMBER,
SR_INSTANCE_CODE,
REVISION "NVL(:REVISION,1)",
UNIT_NUMBER,
NEW_ORDER_QUANTITY,
NEW_DOCK_DATE,
PROJECT_NUMBER,
TASK_NUMBER,
PLANNING_GROUP,
DELIVERY_PRICE,
QTY_SCRAPPED,
FROM_ORGANIZATION_CODE,
ORDER_TYPE CONSTANT '1',
DELETED_FLAG "DECODE(:DELETED_FLAG,1,1,2,2,2)",
COMPANY_NAME "NVL(:COMPANY_NAME,-1)",
END_ORDER_NUMBER,
END_ORDER_RELEASE_NUMBER,
END_ORDER_LINE_NUMBER,
ORDER_RELEASE_NUMBER,
COMMENTS,
SHIP_TO_PARTY_NAME,
SHIP_TO_SITE_CODE,
SR_INSTANCE_ID CONSTANT '0',
PROCESS_FLAG CONSTANT '1',
DATA_SOURCE_TYPE CONSTANT 'BATCH',
LAST_UPDATE_LOGIN CONSTANT '-1',
LAST_UPDATE_DATE SYSDATE,
CREATION_DATE SYSDATE
)
このフォーマットの発注データをOracleデータベース上でホストされているレガシー・システムから抽出するスクリプトは、次のようになります。
SET HEAD OFF';
SET LINESIZE 200;
SET PAGESIZE 50000;
SPOOL ON;
SPOOL MSC_ST_SUPPLIES_PO.dat;
SELECT
DISTINCT
ITEM_TAB.ITEM_NAME||'~'||
ITEM_TAB.ORGANIZATION_CODE||'~'||
PO_TAB.EXPECTED_DELIVERY_DATE||'~'||
SITES_TAB.TP_NAME||'~'||
1||'~'|| /* All orders are treated as Firmed */
SITES_TAB.TP_SITE_CODE||'~'||
PO_TAB.LINE_NUM||'~'||
PO_TAB.PO_NUMBER||'~'||
&&SR_INSTANCE_CODE||'~'||
NVL(ITEM_TAB.ITEM_REVISION,1)||'~'||
YES||'~'||
PO_TAB.MRP_PRIMARY_QUANTITY||'~'||
PO_TAB.EXPECTED_DOCK_DATE||'~'||
PO_TAB.PROJECT_ID||'~'||
PO_TAB.TASK_ID||'~'||
YES||'~'||
PO_TAB.UNIT_PRICE||'~'||
0||'~'||
YES||'~'||
1 ||'~'|| /* All records are either for Insert/Change. No deletions are being uploaded */
-1||'~'||
YES||'~'||
YES||'~'||
YES||'~'||
YES||'~'||
YES||'~'||
YES||'~'||
YES||'~'||
0||'~'||
1||'~'||
'BATCH'||'~'||
-1||'~'||
SYSDATE||'~'||
SYSDATE
FROM <LEGACY_SUPPLY_TABLE> PO_TAB,
<LEGACY_ITEMS> ITEM_TAB,
<LEGACY_PARTNER_SITES> SITES_TAB
WHERE PO_TAB.ORGANIZATION_ID = ITEM_TAB.ORGANIZATION_ID
AND PO_TAB.ITEM_ID = ITEM_TAB.INVENTORY_ITEM_ID
AND PO_TAB.VENDOR_ID = SITES_TAB.SR_TP_ID
AND PO_TAB.VENDOR_SITE_ID = SITES_TAB.SR_TP_SITE_ID;
このスクリプトを実行してデータ・ファイルを取得し、それをAPSコンカレント・マネージャ・ノードにFTPします。これらのファイルをOracle APSにアップロードする手順については、「レガシー収集の実行」を参照してください。
この情報は、一括してロードするか、または次の順序でロードします。
カレンダ・データ情報をアップロードします。カレンダの制御ファイル（MSC_ST_CALENDARS.ctl、MSC_ST_WORKDAY_PATTERNS.ctl、MSC_ST_SHIFT_TIMES.ctl、MSC_ST_CALENDAR_EXCEPTIONS.ctl、MSC_ST_SHIFT_EXCEPTIONS.ctl）に対応する全カレンダ・データ・ファイルを、1回の実行でアップロードする必要があります。提供された情報に基づいて、計画システムにカレンダが作成されます。ODS表（計画サーバー）にカレンダが存在し、そのカレンダを再作成する場合は、情報全体（前述の全ファイル）を再送する必要があります。また、この場合はMSC_ST_CALENDARS.ctlのOVERWRITE_FLAGをYとして送信する必要があります。
単位情報をアップロードします。単位情報の制御ファイルはMSC_ST_UNITS_OF_MEASURE.ctlです。
需要区分情報をアップロードします。
取引先情報をアップロードします。取引先設定の制御ファイルは、MSC_ST_TRADING_PARTNERS.ctl、MSC_ST_TRADING_PARTNER_SITES.ctl、MSC_ST_LOCATION_ASSOCIATIONS.ctl、MSC_ST_SUB_INVENTORIES.ctlおよびMSC_ST_PARTNER_CONTACTSです。
取引先サイト、事業所関連、保管場所および担当は、取引先情報とともにアップロードできますが、以降の実行でアップロードすることもできます。初回の実行時にはMSC_ST_TRADING_PARTNERS.ctlのみをアップロードできます。
MSC_ST_TRADING_PARTNERS.ctlには、CALENDAR_CODEフィールドがあります。このフィールドでは、計画システムに存在する有効なカレンダ・コード、または今回の収集実行でアップロードするカレンダ・コードを参照する必要があります。計画システムにカレンダが存在せず、アップロードもしておかなければ、取引先レコードは受け入れられず、エラーとしてマークされます。
カテゴリ・セット情報をアップロードします。カテゴリ・セット設定の制御ファイルは、MSC_ST_CATEGORY_SETS.ctlです。
需要予測、MDSおよびMPSの指標情報をアップロードします。必要な制御ファイルは、MSC_ST_DESIGNATORS_MDS.ctl、MSC_ST_DESIGNATORS_FORECAST.ctlおよびMSC_ST_DESIGNATORS_PLAN_ORDERS.ctlです。需要予測、MDSおよびMPSレコードは、今回または以降の実行時にアップロードできます。
プロジェクトおよびタスク情報をアップロードします。制御ファイル名はMSC_ST_PROJECT_TASKS.ctlです。
MSC_ST_SYSTEM_ITEMS.ctlファイルに従って品目情報をアップロードします。データ・ファイルのUOM_CODEに無効な値（計画システムに存在せず、今回のアップロードでMSC_ST_UNITS_OF_MEASURE.ctlに従って品目とともにアップロードされない値）が指定されている場合、その品目レコードはエラーになります。
品目関連情報（仕入先生産能力、需要/供給、カテゴリ、単位換算およびソース・ルールなど）をアップロードします。後述の前処理ダイアグラムに従ってデータをアップロードし、品目が有効であること（品目が計画システムに存在するか、今回のレガシー収集実行でアップロードされること）を確認します。
制御ファイルMSC_ST_ITEM_CATEGORIES.ctlを使用してカテゴリをアップロードします。
制御ファイルMSC_ST_ITEM_SOURCING.ctlを使用してソース・ルールをアップロードします。
MSC_ST_UOM_CONVERSIONS.ctlおよびMSC_ST_UOM_CLASS_CONVERSIONS.ctlを使用して単位換算をアップロードします。
制御ファイルMSC_ST_DEPARTMENT_RESOURCEs.ctlを使用して生産資源をアップロードします。
制御ファイルMSC_ST_BOMS.ctl、MSC_ST_BOM_COMPONENTS.ctlおよびMSC_ST_COMPONENT_SUBSTITUTES.ctlを使用して、部品構成表をアップロードします。部品構成表の構成部品と代替は、部品構成表に同時にアップロードするか、または以降の実行時にアップロードできます。
制御ファイルMSC_ST_ROUTINGS.ctl、MSC_ST_ROUTING_OPERATIONS.ctlおよびMSC_ST_OPERATION_RESOURCES.ctlを使用して、工順をアップロードします。生産資源を工程に同時にアップロードするか、または以降の実行時にアップロードできます。
制御ファイルMSC_ST_ITEM_SUPPLIERS.ctl、MSC_ST_SUPPLIER_CAPACITIES.ctlおよびMSC_ST_SUPPLIER_FLEX_FENCES.ctlを使用して、仕入先生産能力をアップロードします。MSC_ST_SUPPLIER_CAPACITIES.ctlをMSC_ST_ITEM_SUPPLIERS.ctlとともにアップロードするか、または以降の実行時にアップロードできます。また、MSC_ST_SUPPLIER_FLEX_FENCES.ctlをMSC_ST_ITEM_SUPPLIERS.ctlとともにアップロードするか、または以降の実行時にアップロードできます。
MSC_ST_SUPPLIES_WO.ctlにはROUTING_NAMEフィールドがあるため、工順のロード後に作業指示に関する資材供給をロードします。
制御ファイルMSC_ST_RESOURCE_REQUIREMENTS.ctlを使用して、生産資源需要をアップロードします。WIP_ENTITY_NAMEが有効でない（前にMSC_ST_SUPPLIES_WO.ctlを使用してロードしておらず、今回の実行でもこの制御ファイルを使用してロードしていない）場合、そのレコードはエラーになります。
レガシー・アプリケーションからのデータが計画システムにロードされた後、計画エンジンで使用可能になる前に前処理が実行されます。
前処理により、ユーザー定義キー（UDK）のセットに基づいて、計画システムに取り込まれるエンティティのIDが生成されます。たとえば、計画システム内で品目レコードを識別するためのUDKは「インスタンス・コード」、「組織コード」、「品目名」および「会社名」です（「会社名」は、SCEをインストール済の場合にのみ必須です。スタンドアロンAPSの場合は-1にデフォルト設定されます）。UDKにより、計画システム内の既存レコードが一意に識別されます。UDKは、計画システム内の既存レコードを更新するための参照として使用されます。
前処理プログラムは、計画エンジンおよびグローバルATPエンジンから独立して実行されるコンカレント・プログラムです。
データ・ファイルがコンカレント・マネージャ・ノードに取り込まれた後については、レガシー収集の実行に関する項の後の方で説明されているように、データ・ファイルをインタフェース表に読取りおよびロードするようにレガシー収集の要求セット・プログラムを構成できます。その後、データの前処理とメイン計画表へのデータの最終ロードを、このプログラムの1回の実行ですべて実行できます。
前処理エンジンには、取引データとこの取引の実行に必要な前提条件の設定データを単一のデータ・ロードに共存させるシナリオを処理するインテリジェンス機能があります。
次の図に、アップロード後のデータが前処理エンジンにより処理される順序を示します。前処理エンジンには並列処理機能があります。並列処理は、ダイアグラムに示すように品目および品目関連エンティティの処理に対して使用可能です。品目、需要および供給レコードは、さらにサブバッチに分割してパラレルに処理できます。
前処理
このアーキテクチャでは、取引処理中のエラーを回避するために、すべての設定関連データが計画システムに送られることも確認する必要があります。たとえば、計画システムに取り込まれる発注明細で、システムに送られていない品目を参照している場合、その発注明細にはエラー・フラグが設定されます。また、品目の仕入先も、システムで有効な仕入先として定義しておく必要があります。
ステージング表内のレコードで、同じUDKの組合せが複数発生しないかどうかがチェックされます。たとえば、XMLを介して取り込まれるデータの場合、インスタンス・コード、組織コード、品目名および会社名の同じ組合せを持つ品目レコードがインタフェース表内で複数検出されると、前処理では以降の処理のために最新レコードが取得され、古いレコードにはエラー・フラグが設定されます。たとえば、バッチ・アップロードを介して取り込まれるデータの場合は、インスタンス・コード、組織コード、品目名および会社名の同じ組合せを持つ品目レコードがインタフェース表内で複数検出されると、そのレコードには前処理によりエラー・フラグが設定されます。これは、どれが取得対象として正しいレコードであるかを前処理では判別できないためです。
Oracle APSをインストール済のコンカレント・マネージャ・ノード上で、レガシー統合パッチを適用します。NFSがマウントされていないコンカレント・マネージャ・ノードが複数ある場合は、このパッチを全ノードで適用する必要があります。パッチにより、すべての制御ファイルが$MSC_TOP/patch/<version>/importディレクトリにコピーされます。このディレクトリのフルパスを、レガシー・システムのデータ収集を実行する際に、「フラット・ファイル・ローダー」の「パラメータ」画面で「制御ファイルのディレクトリ」パラメータに値として入力する必要があります。
システム管理者の職責を使用してログインします。
ナビゲータから、「要求」->「実行」を選択します。
「新規要求の発行」画面が表示されます。
「単一要求」を選択し、「OK」ボタンを選択します。
「要求の発行」フォームが表示されます。
「名称」フィールドで「APSパーティションの作成」を選択し、「OK」ボタンを選択します。
「パラメータ」画面が表示されます。
計画パーティションとインスタンス・パーティションの数を入力し、「OK」ボタンを選択します。
パーティションが作成されます。
「アドバンスト・プランニング管理者」職責に変更し、ナビゲータから、「管理」->「インスタンス」を選択します。
「アプリケーション・インスタンス」画面が表示されます。
アプリケーション・インスタンス
レガシー・インスタンスのインスタンス・コードを指定し、「インスタンス・タイプ」を「その他」に設定します。「ソースから APSへ」および「APSから ソースへ」フィールドは空白のままにしておきます。インスタンスに関する他のフィールドには、オンライン・ヘルプの指定に従って入力します。
これで、バッチ・ロード・ソリューションを使用するように設定されます。「レガシー収集の実行」で後述するプロセスに従って、このインスタンス用の稼働日カレンダ・データと計画組織をアップロードします。このデータは、他のエンティティのデータとともにアップロードできます。前処理には、同じバッチ・アップロードで取り込まれた新規組織を考慮するインテリジェンス機能があります。これらの組織は、レガシー収集の完了後に「インスタンス設定」フォームの下部にある「組織」ボタンを使用して確認できます。
注意: バッチ・アップロードの設定ステップとレガシー・インスタンスの設定ステップは、データ・アップロード・スクリプトを作成するまでパラレルに実行できます。ただし、スクリプトからデータ・ファイルを取得する場合は、インスタンス・コードが必要です。
Oracle Applicationsフォームまたはセルフ・サービス・アプリケーション・ページを使用して、データをフラット・ファイルからレガシー・インスタンスにアップロードし、最終的に計画エンジンにアップロードできます。フォームを使用する場合は、各データ・ファイルを個別にアップロードします。
セルフ・サービス方法を使用する場合は、すべてのデータ・ファイルを含んだzipファイルをアップロードできます。作業指示供給やBOMヘッダーなど、各データ・ファイル・タイプはファイル名内のタグを使用して識別されます。ディレクトリ全体をzipするのではなく、必ず個別ファイルをzipファイルに追加してください。
コンカレント・マネージャ・ノードの$MSC_TOP/patch/<version>/importディレクトリにある制御ファイルに従って、全データ・ファイルをコピーします。複数のコンカレント・マネージャ・ノードがあり、各ノードがNFSマウント済でない場合は、データ・ファイルを同じディレクトリ構造で全ノードにコピーする必要があります。SQL*Loaderではエラーのためにアップロードできなかったデータのファイルが破棄されるため、このディレクトリ（または、NFSマウント済でない複数のコンカレント・マネージャ・ノードの場合は全ディレクトリ）の読取り/書込み権限を全ユーザーに付与する必要があります。
「アドバンスト・プランニング管理者」の職責を選択します。
ナビゲータで「収集」->「レガシー・システム」->「フラット・ファイル・データの収集」を選択します。
「計画データ収集」画面が表示され、「フラット・ファイル・ローダー」、「プリ・プロセス・モニター」および「計画ODSロード」という3つのプログラムが示されます。「計画ODSロード」により、データがインタフェース表から計画システムのメイン表に移動されます。
「フラット・ファイル・ローダー」の「パラメータ」フィールドを選択します。
「パラメータ」画面が表示されます。
「フラット・ファイル・ローダー」の「パラメータ」画面
アップロードする全データ・ファイルについて、必須情報とファイル名を入力します。「データ・ファイルのディレクトリ」フィールドにディレクトリ・パスを入力してから、「ファイル名」フィールドにアップロード対象の各エンティティのファイル名を入力する方法と、「データ・ファイルのディレクトリ」フィールドを空白のままにして、「ファイル名」フィールドに各エンティティのフルパスとファイル名を入力する方法があります。第2のオプションは、すべてのデータ・ファイルが同じディレクトリに格納されていない場合に役立ちます。
「合計ワーカー数」フィールドでは、特定の時点でパラレルに実行する必要のあるローダー・ワーカーの最大数を指定します。ローダー・ワーカーは、指定した各ファイル名に対して起動されます。
この画面で情報入力を完了後に、「OK」ボタンを選択します。
「プリ・プロセス・モニター」の「パラメータ」フィールドを選択します。
「パラメータ」画面が表示されます。
「プリ・プロセス・モニター」の「パラメータ」画面
レガシー・インスタンスについて前処理するエンティティを指定します。
「処理バッチ・サイズ」フィールドでは、インタフェース表内のレコードを処理する間のバッチ・サイズを指定します。バッチ・サイズが大きいほど高速になりますが、システム・リソースの所要量も増大します。現行のデフォルト・バッチ・サイズは1000です。
「合計ワーカー数」フィールドでは、データ処理のためにパラレルに起動するコンカレント・プロセスの数を指定します。
この画面で情報入力を完了後に、「OK」ボタンを選択します。
「計画ODSロード」の「パラメータ」フィールドを選択します。
「パラメータ」画面が表示されます。
「計画ODSロード」の「パラメータ」画面
データの移動後に「生産資源可用性」と「ソーシング履歴」を再計算するかどうかを指定します。
この画面で情報入力を完了後に、「OK」ボタンを選択します。
「計画データ収集」画面が表示されます。
「発行」ボタンを押し、コンカレント・マネージャが「次の場合」セクションで指定した計画オプションに従って要求を計画できるようにします。
「要求の表示」フォームを使用して、各種プログラムの進行状況をモニターします。
「ナビゲータ」で、「収集」の下にある「収集データの表示」メニュー・オプションを使用して、計画システムに取込中のデータを確認します。
「収集」->「レガシー・システム」->「フラット・ファイル・データ収集 - セルフ・サービス」をダブルクリックします。
Oracle Collaborative Planning Suiteのページが表示されます。
Collaborative Planning Suiteのページ
「ダウンロード」リンクをクリックして、Oracle Applications（OA）テンプレートをダウンロードします。
zip形式で圧縮された.datファイル（部品構成表やカレンダなど）がすべて表示されます。
フラット・ファイルを使用して各種エンティティをOracle Advanced Planning and Scheduling Suite製品にロードする方法は、OATemplateReadme.htmlファイルに記載されています。ExcelLoad.xltファイルをオープンし、データ・ファイルをインポートして表示し、変更できます。
Oracle Collaborative Planning Suiteのページで、「ブラウズ」をクリックしてデータ・ファイルの場所にナビゲートします。
アップロード対象のデータ・ファイルを含んだzipファイルを選択します。
「ロード開始」をクリックします。
コンカレント要求が開始されます。要求IDをメモしておくと、後で参照できます。
この要求の完了後、「収集ワークベンチ」にナビゲートして収集データを確認します。
パージ・プログラムにより、ODS表とローカルID表（MSC_LOCAL_ID_XXX）からデータが削除されます。パージ・プログラムの動作は、コンカレント・プログラムの発行時に選択したオプションに応じて後述のように異なります。
「アドバンスト・サプライ・チェーン計画担当」の職責を選択します。
ナビゲータから、「収集」->「レガシー・システム」->「収集データのパージ」を選択します。
コンカレント・プログラムの発行時に「完全リフレッシュ」に対して「Yes」を選択した場合は、次の画面が表示されます。
パージの「パラメータ」画面
次の表に、この画面の値を示します。
| フィールド | 値 |
|---|---|
| インスタンス | パージ・プログラムの実行対象となるレガシー・インスタンス。 |
| 完全リフレッシュ | Yes |
| 今までのレコードの削除 | ユーザーが入力した日付（現在の日付にデフォルト設定） |
| 供給の削除 | Yes（「完全リフレッシュ」が「Yes」の場合は常に「Yes」） |
| 需要の削除 | Yes（「完全リフレッシュ」が「Yes」の場合は常に「Yes」） |
この場合、ODSから次の表がパージされます。
MSC_SYSTEM_ITEMS
MSC_BOMS
MSC_BOM_COMPONENTS
MSC_COMPONENT_SUBSTITUTES
MSC_ROUTINGS
MSC_ROUTING_OPERATIONS
MSC_OPERATION_RESOURCES
MSC_OPERATION_COMPONENTS
MSC_OPERATION_RESOURCE_SEQS
MSC_PROCESS_EFFECTIVITY
MSC_DEPARTMENT_RESOURCES
MSC_RESOURCE_SHIFTS
MSC_RESOURCE_CHANGES
MSC_SIMULATION_SETS
MSC_PROJECTS
MSC_PROJECT_TASKS
MSC_ITEM_CATEGORIES
MSC_DESIGNATORS（この場合、プログラムにより無効日が削除されるかわりに現在の日付として更新されます。）
MSC_DEMANDS
MSC_SALES_ORDERS
MSC_SUPPLIES
MSC_INTERORG_SHIP_METHODS
MSC_ABC_CLASSES
MSC_ST_RESOURCE_GROUPS
MSC_ST_DEMAND_CLASSES
MSC_ST_RESERVATIONS MSC_ST_SAFETY_STOCKS
また、LID表に格納されている、次の表に示されるエンティティが削除されます。
| エンティティ名 | LID表名 | ビジネス・オブジェクト |
|---|---|---|
| SR_INVENTORY_ITEM_ID | MSC_LOCAL_ID_ITEM | 品目 |
| ABC_CLASS_ID | MSC_LOCAL_ID_MISC | 品目 |
| BILL_SEQUENCE_ID | MSC_LOCAL_ID_SETUP | 部品構成表 |
| COMPONENT_SEQUENCE_ID | MSC_LOCAL_ID_SETUP | 部品構成表 |
| ROUTING_SEQUENCE_ID | MSC_LOCAL_ID_SETUP | 工順 |
| OPERATION_SEQUENCE_ID | MSC_LOCAL_ID_SETUP | 工順 |
| RESOURCE_SEQ_NUM | MSC_LOCAL_ID_SETUP | 工順 |
| DEPARTMENT_ID | MSC_LOCAL_ID_SETUP | 部門/生産資源 |
| LINE_ID | MSC_LOCAL_ID_SETUP | 部門/生産資源 |
| RESOURCE_ID | MSC_LOCAL_ID_SETUP | 部門/生産資源 |
| PROJECT_ID | MSC_LOCAL_ID_MISC | プロジェクト/タスク |
| TASK_ID | MSC_LOCAL_ID_MISC | プロジェクト/タスク |
| COSTING_GROUP_ID | MSC_LOCAL_ID_MISC | プロジェクト/タスク |
| SR_CATEGORY_ID | MSC_LOCAL_ID_MISC | カテゴリ |
| DISPOSITION_ID_FCT | MSC_LOCAL_ID_DEMAND | 需要（需要予測） |
| DISPOSITION_ID_MDS | MSC_LOCAL_ID_DEMAND | 需要（MDS） |
| SALES_ORDER_ID | MSC_LOCAL_ID_DEMAND | 需要（受注） |
| DEMAND_ID | MSC_LOCAL_ID_DEMAND | 需要（受注） |
| DISPOSITION_ID | MSC_LOCAL_ID_SUPPLY | 供給 |
| PO_LINE_ID | MSC_LOCAL_ID_SUPPLY | 供給（発注/購買依頼） |
| SCHEDULE_GROUP_ID | MSC_LOCAL_ID_SUPPLY | 供給（MPS） |
| DISPOSTION_ID_MPS | MSC_LOCAL_ID_SUPPLY | 供給（MPS） |
| SR_MTL_SUPPLY_ID | MSC_LOCAL_ID_SUPPLY | 供給（手持） |
| WIP_ENTITY_ID | MSC_LOCAL_ID_SUPPLY | 供給（WIP） |
パージ・プログラムでは、次のビジネス・オブジェクトに関連するレコードはODS表またはLID表から削除されません。
取引先（組織、仕入先、顧客）
カレンダ
カテゴリ・セット
ソース・ルール
単位
コンカレント・プログラムの発行時に「完全リフレッシュ」に対して「No」を選択した場合は、次の画面が表示されます。
パージの「パラメータ」画面
次の表に、この画面の値を示します。
| フィールド | 値 |
|---|---|
| インスタンス | パージ・プログラムの実行対象となるレガシー・インスタンス。 |
| 完全リフレッシュ | No |
| 今までのレコードの削除 | ユーザーが入力した日付（現在の日付にデフォルト設定） |
| 供給の削除 | Yes/No（「Yes」にデフォルト設定） |
| 需要の削除 | Yes/No（「Yes」にデフォルト設定） |
この場合、需要/供給ビジネス・オブジェクトのレコードと、作成日がユーザー入力日付よりも前のレコードのみが、ODS表とLID表から削除されます。
Oracle Applicationsフォームまたはセルフ・サービス・アプリケーションを使用して、取引データ（需要/供給）をフラット・ファイルからERPインスタンスにアップロードできます。
取引データを計画サーバーにアップロードする際には、レガシー・システムを直接使用するか、またはOracle ERPアプリケーションを使用してください。二重カウントを回避するために、同じ取引データをレガシー・インスタンスとERPインスタンスの両方にアップロードしないでください。たとえば、ERPインスタンスとレガシー・インスタンスの両方を使用して受注をアップロードしないでください。
.datファイルを初めてインポートする場合、Excelでは次の値を入力するように要求されます。入力後に再入力する必要はありません。
日付形式: datファイル内のすべての日付の形式。
区切り文字: datファイル内の各列を区切るために内部で使用されます。プロファイル・オプション「MSC: セルフ・サービス・ロード区切り」の値と一致していることを確認します。これらの値は、「APSメニュー」->「ユーザー オプション」を選択して変更します。値を変更するためのウィンドウがオープンし、次のいずれかの処理を選択できます。
適用: オープンしているシートに変更内容が適用されます。
適用して保存: オープンしているシートに変更内容が適用され、設定が保存されます。
CSData.datをアップロードする前に、ExcelLoader内の日付形式をYYYY/MM/DDに設定します。
「計画データ収集」フォーム（「収集」->「Oracleシステム」->「フラットファイル使用取引データのロード」）にナビゲートします。
「計画データ収集」フォームが表示され、「取引データのロード」、「取引データの事前処理」および「計画ODSロード」という3つのプログラムが示されます。「取引データのロード」プログラムにより、取引データがフラット・ファイルを介してインタフェース表にロードされます。「取引データのロード」プログラムでは、制御ファイルとデータ・ファイルのパスを含むパラメータ値を指定できます。
「取引データの事前処理」プログラムでは、取引データが前処理されてIDが生成されます。このプログラムでは、取引データをロードするインスタンスを指定できます。
「計画ODSロード」プログラムでは、データがインタフェース表から計画サーバーのメイン表に移動されます。
「計画データ収集」ウィンドウ
「取引データのロード」の「パラメータ」フィールドをクリックします。
「パラメータ」ウィンドウが表示されます。
アップロードする全データ・ファイルについて、必須情報とファイル名を入力します。「タイム・アウト継続期間」フィールドで、コンカレント・プログラムに割当てる最大時間を指定します。「データ・ファイルのディレクトリ」フィールドにディレクトリ・パスを入力してから、「ファイル名」フィールドにアップロード対象の各エンティティのファイル名を入力する方法と、「データ・ファイルのディレクトリ」フィールドを空白のままにして、「ファイル名」フィールドに各エンティティのフルパスとファイル名を入力する方法があります。第2のオプションは、すべてのデータ・ファイルが同じディレクトリに格納されていない場合に役立ちます。
各フィールドへの情報入力の完了後、「OK」をクリックします。
「取引データの事前処理」の「パラメータ」フィールドをクリックします。
「パラメータ」ウィンドウが表示されます。
値リストからインスタンスを選択します。
取引データをロードするインスタンスを指定した後、「タイム・アウト継続期間」フィールドでプロセスの最大許容時間（分）を指定します。
「処理バッチ・サイズ」フィールドでは、インタフェース表内のレコードを前処理する間のバッチ・サイズを指定します。バッチ・サイズが大きいほど高速になりますが、システム・リソースの所要量も増大します。現行のデフォルト・バッチ・サイズは 1000です。
「合計ワーカー数」フィールドでは、データ処理のためにパラレルに起動するコンカレント・プロセスの数を指定します。
ERPインスタンス用に前処理するエンティティを指定します。「Yes」は、前処理する必要のあるエンティティを示します。
各フィールドへの情報入力の完了後、「OK」をクリックします。
「計画ODSロード」の「パラメータ」フィールドをクリックします。
「パラメータ」ウィンドウが表示されます。
「計画ODSロード」の「パラメータ」ウィンドウ
ERPインスタンス内のデータ収集に必須の「計画ODSロード」のパラメータは、レガシー収集の必須パラメータと同様です。
各パラメータの値を指定して「OK」をクリックします。
「計画データ収集」ウィンドウで「発行」をクリックします。
ツールバーから「表示」->「要求」を選択して、収集プロセスのステータスを表示します。
要求が完了すると、「収集ワークベンチ」でデータを確認できます。
「収集」->「Oracleシステム」->「Self Serviceロード使用の取引データのロード」をダブルクリックします。
Oracle Collaborative Planning Suiteのページが表示されます。
Oracle Collaborative Planning Suiteのページ
「ダウンロード」リンクをクリックして、Oracle Applications（OA）テンプレートをダウンロードします。
zip形式で圧縮された.datファイル（部品構成表やカレンダなど）がすべて表示されます。テンプレートの使用方法が記載されたREADMEも、このzipファイルで提供されます。
ExcelLoad.xltファイルをオープンし、データ・ファイルをインポートして表示し、変更します。変更後にデータ・ファイルをエクスポートします。最後に、アップロードする必要のあるデータ・ファイルをすべてzip形式で圧縮します。
「ブラウズ」をクリックしてデータ・ファイルの場所にナビゲートします。
アップロード対象のデータ・ファイルを含んだzipファイルを選択します。
「ロード開始」をクリックします。
コンカレント要求が起動します。
Oracle Collaborative Planning Suiteのページ
この要求の完了後、「収集ワークベンチ」にナビゲートして収集データを確認します。
システム・インテグレータは、前処理で不要な取込データを除外できるように、カスタム検証を追加できます。前処理エンジンには各エンティティ用のフックが用意されており、カスタム検証のプラグインに使用できます。
Oracle Advanced Supply Chain Planningは、組織固有の収集をサポートしています。組織固有の収集は、Oracle E-Business Suiteの単一インスタンスを実行している会社の独立したビジネス単位内で、独立した計画プロセスを維持する上で役立ちます。
ソース・インスタンスのうち指定した組織のデータのみを収集するために、収集を実行できます。これにより、計画プロセスの対象外組織からの不要なデータの収集を排除し、処理時間を短縮できます。
Oracle Advanced Supply Chain Planningでは、次の場合に組織固有の収集が可能です。
標準収集
「完全リフレッシュ」方法
「ネット・チェンジ・リフレッシュ」方法
「指定リフレッシュ」方法
継続収集
注意: 組織固有の収集は、レガシー収集には使用できません。
「アドバンスト・プランニング管理者」職責を選択します。
「管理」->「インスタンス」にナビゲートします。
「アプリケーション・インスタンス」フォームが表示されます。
「アプリケーション・インスタンス」フォーム
インスタンスを定義します。
「組織」をクリックします。
「組織」フォームが表示されます。
「組織」フォーム
定義したインスタンスの組織に対応する「使用可能」チェック・ボックスを選択します。
各組織の収集グループを指定します。
グループ組織が確実に一括して収集されるように、すべての関連組織を同じ収集グループに割当てます。
「アドバンスト・サプライ・チェーン計画担当」職責を選択します。
「収集」->「Oracleシステム」->「標準収集」にナビゲートします。
「計画データ収集」フォームが表示されます。
「計画データ・プル」プログラムの「パラメータ」フィールドをクリックします。
「パラメータ」ウィンドウが表示されます。
「パラメータ」ウィンドウ
「収集グループ」を選択します。
Oracle Advanced Supply Chain Planningでは、「収集グループ」の値に関係なく常に次のデータが収集されます。
ATPルール
需要区分
取引先 (顧客)
取引先 (仕入先)
単位
ユーザー会社関連
ソース・ルールと割当セット
出荷ネットワークと出荷方法
また、収集プログラムでは、全取引先の出荷カレンダと受入カレンダに対処するために、全カレンダが収集されます。
Oracle Advanced Supply Chain Planningでは、単一のソース・インスタンスから複数の宛先インスタンスに収集できます。これは、ボリューム・テストを実行する必要があり、本番の計画サーバー・インスタンスから生産計画を生成しながら、ソースの本番インスタンスからテスト用の宛先インスタンスに収集する必要がある場合に役立ちます。両方の計画サーバー・インスタンスで同じ本番のソース取引インスタンスを共有できます。
単一ソースから複数宛先に収集することで、本番のソース・インスタンスにある設定データと取引データを利用して、テスト用の計画サーバー・インスタンス上でボリューム・テストを実行できます。ソース・インスタンスの複製を回避し、格納および保守コストを大幅に削減できます。
注意: ソース・インスタンスと宛先（計画サーバー）インスタンスの両方で、Oracle Advanced Supply Chain Planningのリリースが同じである必要があります。
「アドバンスト・プランニング管理者」職責を選択します。
「管理」->「インスタンス」にナビゲートします。
「アプリケーション・インスタンス」フォームが表示されます。
各宛先インスタンス内で、宛先インスタンスをソース・インスタンスに個別に関連付けます。
ソース・インスタンスからのATPプロセスで考慮対象となる宛先インスタンスの「ATPの許可」チェック・ボックスを選択します。
「ATPの許可」チェック・ボックスを選択できる宛先は、単一ソースに関連付けられている宛先のうち1つのみです。
ATP対象として複数の宛先を選択しようとすると、計画エンジンによりエラー・メッセージが表示されます。
「アプリケーション・インスタンス」ウィンドウ、エラー・メッセージ
ソース・インスタンスへのリリースを許可する宛先インスタンスの「ATPの許可」チェック・ボックスを選択します。
「使用可能フラグ」チェック・ボックスは、自動リリース・プロセスと手動リリース・プロセスの両方に使用されます。
単一ソースに関連付けられている複数の宛先について、「リリースの許可」チェック・ボックスを選択できます。
「アプリケーション・インスタンス」フォームで計画が定義されているインスタンスの「リリースの許可」チェック・ボックスを選択します。
「計画名」フォームで計画の「製品」チェック・ボックスを選択します。
「計画名」フォーム
例: 「ATPの許可」オプションの使用
次の点を考慮してください。
単一のソース・インスタンスSが2つの宛先インスタンスD1およびD2に関連付けられているとします。
ソースSに関連する宛先インスタンスD1の「ATPの許可」チェック・ボックスが選択されているとします。
ソースSからのATP要求はD1を指します。計画エンジンでは、「計画名」フォームで「ATP」チェック・ボックスが選択されている計画が考慮され、D1でATPプロセスが実行されます。
宛先インスタンスD2には、「計画名」フォームで「ATP」チェック・ボックスが選択されている計画が存在する可能性があります。D2からのATPプロセスでは、これらの計画が使用されます。宛先側の「計画名」フォームで「ATP」チェック・ボックスを選択するかどうかについては、制限はありません。
結論: 「アプリケーション・インスタンス」フォームで「ATPの許可」チェック・ボックスを選択できる宛先は、単一ソースに関連付けられている宛先のうち1つのみです。
例: 「リリースの許可」オプションの使用
次の点を考慮してください。
単一のソース・インスタンスSが2つの宛先インスタンスD1およびD2に関連付けられているとします。
D1ではなくD2の「リリースの許可」チェック・ボックスが選択されているとします。
「計画オプション」フォームで「製品」チェック・ボックスが選択されているD2での計画により、ソースに対する「自動リリース」プロセスがトリガーされます。
D1での計画の「製品」チェック・ボックスを選択できますが、これによりソースに対する「自動リリース」プロセスがトリガーされることはありません。これは、「アプリケーション・インスタンス」フォームでD1の「リリースの許可」チェック・ボックスが選択されていないためです。
結論: 単一ソースに関連付けられている複数の宛先について、「リリースの許可」チェック・ボックスを選択できます。
