Running Collections

This chapter covers the following topics:

Overview of Running Collections

Oracle ASCP has a component architecture that allows a single instance of Oracle ASCP to plan one or more transaction instances. The transaction instances can be a mixture of releases. The Oracle ASCP planning instance (referred to as the planning server) can sit on the same instance as one of the transaction instances, or be a separate instance altogether. In either case (even if the planning server shares an instance with the transaction instance to be planned), data to be planned is brought from the transaction instance(s) to the planning server via a process called Collection.

This section describes the architecture used in the collection of planning data from multiple operational sources into Oracle ASCP. These sources could be different versions/instances of Oracle Applications or other legacy systems. Oracle ASCP uses a data store based on the planning data model that is exposed through interface tables. The data is pulled from the designated data sources into its data store; Oracle ASCP Collections are responsible for synchronization as changes are made to the data sources. The configurability of the collections is enabled through a pull program based on AOL concurrent program architecture. Thus, for example, different business objects can be collected at different frequencies. Supplies and demands, which change frequently, can be collected frequently. Routings and resources, which change relatively less often, can be collected less frequently.

The data collection process consists of the Data Pull and the Operational Data Store (ODS) Load. The collection process lets you collect across several Oracle Application versions. It supports several configurations. The two types of collections process are standard and continuous.

Collections Data Notes

Calendar: Oracle recommends that you load calendars separate from all other entities and before all other entities. When you collect all other entities, set Calendar selection to No..

Currency: Currencies collected from Oracle Order Management and Oracle Purchasing are posted in functional currency even if their source is in transactional currency.

Currency Conversion Rates: Collect currency and currency conversion rates for a past, current and future period from the source in order to support displaying the cost in reporting currency. The default value is No. Currency conversion rates are collected only:

See profile options:

Discrete Jobs: A discrete job that is complete and not closed appears in the collected data with quantity zero. A discrete job that is complete and closed does not appear in the collected data. You can control this with profile option MSC: Collect Completed Jobs

Drop ship purchase orders: The collections process does not collect supplies against drop ship purchase orders because the planning engine does not plan drop ship sales orders.

End-Item Substitutes: You can see end-item substitutes in Collections Workbench as long as you have not defined a substitute set. If you have defined a substitute set, use Planner Workbench Items window to see the substitute set and end-item substitute.

Global Forecasts: You can review global forecast entries in Collections Workbench horizontal plan using rows Original and Cumulative Original.

Inactive forecasts: The collections process does not collect the demands of inactive forecasts if run in Full Refresh or Targeted Refresh collections mode

Intransit, Purchase Order, and Requisition: Oracle recommends that you always collect purchase order, requisition and intransit together. To do so, set Planning Data Pull parameter Purchase Orders/Purchase Requisitions to Yes.

Routings: The collections process does not collect routing operation resources with Schedule = No and does not display them in their routings. It also does not collect alternate resources of primary resources that are Schedule = No, even if the alternate resources themselves are Schedule = Yes.

Trading Partners: When loading trading partners, access file Parameters.txt and set Calendar_Overwrite_Flag to N.

Definitions

You should be familiar with the following terms before examining the data collections architecture:

Oracle Applications Data Store (ADS): The set of source data tables in each transaction instance that contain data relevant to planning.

Operational Data Store (ODS): The planning data tables in the planning server that act as destination for the collected data from each of the data sources (both ADS and Legacy).

Planning Data Store (PDS): The outputs of the planning process. The PDS resides in the same data tables as the ODS. However, PDS data are marked with plan IDs that show which plans they correspond to, while ODS data are marked with plan ID = -1.

Standard Data Collection: The standard data collection process enables you to select the mode of data collection. You can use a complete refresh, a net change (increamental) refresh, or a targeted refresh Standard data collection consists of the following processes:

Continuous Data Collection: The continuous data collection process automates the process of looking up the sources to populate the tables on the planning server. With the least user intervention, the continuous data collection process determines the type of collection to perform on each type of entity. The Continuous Collections concurrent process performs continuous collections.

Collection Workbench: The Collection Workbench is a user interface for viewing data collected over to the planning server from the transaction instances. The functionality here is similar to Planner Workbench functionality. For more information on the Planner Workbench, see Overview of Planner Workbench.

Collection Strategy

Major features of the collection process include:

Multiple Source Instances

You can register any number of source data instances and non-Oracle data sources on each Oracle ASCP installation.

Pull Architecture

You can collect new source data instances into Oracle ASCP with minimal impact. The data is pulled from the source data instance by Oracle ASCP. Each instance can have its own refresh interval. A failure in one instance will not affect data collections from other instances.

Detect Net Change to Synchronize Oracle Applications and Oracle ASCP

You can synchronize the data in Oracle Applications transaction instances and the Oracle ASCP planning server in a net change mode. Thus, only the changed source data is collected each time, reducing the computational burden on the collection process.

Multi-Process Collection Architecture

You can enhance the performance of the pull program by distributing the tasks to multiple collection workers.

Data Consolidation

The collection program can consolidate the entities shown in the following table across instances based on the corresponding user-defined keys.

Entity User Key
MTL_SYSTEM_ITEMS Concatenated Item Segments
MTL_CATEGORIES Concatenated Category Name
MTL_CATEGORY_SETS Category Set Name
PO_VENDORS Vendor Name
PO_VENDOR_SITES Vendor Site Code
RA_CUSTOMERS Customer Name
RA_SITE_USES_ALL Customer Name, Site Use Code, Location Operating Unit
Unit Of Measure UOM Code

For all the entities not described in the table, the instance ID together with the entity key in each instance uniquely identifies each row.

Projects/Tasks and Seiban Numbers

You can consider Projects, Tasks, and Seiban Numbers to be unique within the context of an Oracle Applications instance; no consolidation is required.

Support for Several Configurations

You can perform centralized and decentralized configurations based on the scale of the enterprise and specific business needs. Source data applications and Oracle ASCP can reside on one server or on separate servers.

Architecture

Oracle ASCP's data collection architecture, shown in the figure below, depicts the data objects, procedures, and data flow between source data and Oracle ASCP. The major repositories are ADS, ODS, and PDS. Procedures enable data cleansing, data collecting, data communication, and net-change handling between data repositories.

When Oracle ASCP and its source data reside on the same instance, communication between them is enabled by PL/SQL based public API procedures or interface tables. In a distributed environment, procedure calls are made using database links.

Data Collections Architecture

the picture is described in the document text

Supported Configurations

Oracle ASCP supports the following planning configurations for installation and deployment:

These configurations offer you enough flexibility to design a mode of planning that suits your business objectives. Both configurations are supported using a consistent architecture as outlined in the previous section. The sole distinction is that centralized planning uses database links to pull data into the Oracle ASCP data store.

Decentralized Planning

The following figure shows the decentralized planning configuration:

the picture is described in the document text

Oracle ASCP works as a central Planning Server across several source data instances. The collection program is installed on the planning server and the data stripped by instance is moved into staging tables within Oracle ASCP during the data collection process.

After the planning process, results can be pushed back to each instance.

Centralized Planning

This figure shows the centralized planning configuration.

the picture is described in the document text

Oracle ASCP and its source data reside in the same database. No database link is required in this case. Two components can communicate through the planning object APIs and the interface tables defined in Oracle Applications.

In this configuration, shown in the following figure, a simplified architecture is used, and the data transformation is not required.

Simplified Data Collections Architecture

the picture is described in the document text

Collection Methods

Collecting data can take a significant amount of time compared to the time for the overall planning cycle. Oracle Advanced Supply Chain Planning (ASCP) provides a collection method that allows the collections duration to be reduced in cases where information about some - but not all - planning-related business entities on the planning server needs to be updated.

There are three collection methods:

Running Standard Collections

To collect data from an Oracle Applications transaction instance

  1. Sign on using the Advanced Supply Chain Planner responsibility or the Advanced Planning Administrator responsibility.

  2. Navigate to the Planning Data Collection window by selecting Collections > Oracle Systems > Standard Collection.

    The Planning Data Collection window appears.

    This window shows you that the collections process consists of two sequentially executed concurrent programs. The first program, Planning Data Pull, copies information from the source instance into the APS staging tables on the planning server. Here, against the data held in the staging tables, ASCP performs some basic cleansing. For example, it ensures that items with the same names that are collected from different source instances will be assigned the same internal IDs (recognized as the same item). Further cleansing operations on the staging tables (if desired) may be done at this point via any custom concurrent program. This custom concurrent program would need to be inserted into the Planning Data Collection request set, in between Planning Data Pull and Planning ODS Load. The second program, Planning ODS Load, copies information from the APS staging tables into the operation data store on the planning server, where it becomes available for use during planning.

  3. Select the Parameters field for the Planning Data Pull program.

    The Planning Data Pull Parameters window appears.

  4. Use the information in the following table to set up parameters in the Planning Data Pull Parameters window.

    Parameter Values
    Instance Source instance code from list of values.
    Number of Workers One or greater. Increase this number to increase the amount of computational resources to devoted to the Planning Data Pull process. This allows you to specify the number of workers for the Data Pull, which can now be different from the number of workers specified for the ODS load process.
    Timeout (Minutes) The maximum amount of time you would like to allocate to the Planning Data Pull process. If the Planning Data Pull process has not completed within this amount of time, it will be terminated with an error.
    Purge Previously Collected Data Yes (default) or No. Setting this to Yes wipes out all data in the APS planning server operational data store associated with the selected source instance as the first step in the collections process. If you set this to Yes, the only allowable collection method is Complete Refresh. If you set this to No, the allowable collection methods are Targeted Replacement and Net Change.
    Collection Method Complete Refresh/Targeted Refresh/Net Change Refresh.
    Analyze Staging Tables Yes or No (default). Set this to Yes periodically to recompute database access statistics on the APS staging tables. This speeds up the subsequent Planning ODS Load process.
    User Company Association The possible values are:

    • No: During data collections, the destination instance does not accept the following: New users' company association and existing users with changes to their company association.

    • Create users and enable user company association: A user created on one of the source instances can be automatically created on the planning server or destination instance. You can use this option when you need to work with multiple source instances or systems.

      Create a new user, specify the user's contact information during setup, and initiate a data collection. The user is created on the destination instance or planning server and is assigned the Supply Chain Collaboration Planner responsibility. The new user can log onto Oracle Collaborative Planning and view data that is visible to the associated company.

    • Create a new user, specify the user's contact information during setup, and initiate a data collection. The user is created on the destination instance or planning server and is assigned the Supply Chain Collaboration Planner responsibility. The new user can log onto Oracle Collaborative Planning and view data that is visible to the associated company.

      Create a new user on the source instance and specify the user's contact information during the setup. Create the user on the destination instance or planning system and assign the user responsibilities. Start a data collection to complete the user's company association. This ensures that the user has all the assigned responsibilities.

    The remaining parameters in the Planning Data Pull Parameters are a list of business entities. Selecting Yes for an entity means collect the information for that entity over from the source instance. Selecting No for an entity means don't collect the information for that entity over from the source instance.

    Note: The default value for these entities is set to Yes. Collecting information for Resource Availability and Sourcing History takes a significant amount of time. Collect this information only when necessary.

  5. Select OK.

  6. Select the Parameters field for the Planning ODS Load program.

    The Parameters window appears.

  7. Use the information in the following table to specify the fields and options in this window.

    Parameter Values
    Instance Source instance code from list of values.
    Timeout (Minutes) Number of minutes before the concurrent program will end.
    Number of Workers One or greater. Increase this number to increase the amount of computational resources to devoted to the Planning ODS Load process.
    Recalculate Resource Availability This defaults to the value (Yes or No) that you set for the Resources Availability business entity in the Planning Data Pull Parameters window. The value that you set here is the one that actually determines whether resources availability is collected or not.
    Recalculate Sourcing History This defaults to the value (Yes or No) that you set for the Sourcing History business entity in the Planning Data Pull Parameters window. The value that you set here is the one that actually determines whether sourcing history is collected or not. If you select Yes, then ASCP will collect all new sourcing history not already on the planning server in the time range [(today - x months) through (today)] from the source transaction system. The number x is given by the value that you set for the profile option MSC: Sourcing History Start Date Offset (in months). During planning, ASCP will use the total cumulative sourcing history on the planning server in addition to the planned sourcing in the plan to determine whether sourcing percentages in sourcing rules are being respected or not.
    Purge Sourcing History Valid values are Yes and No (default). If you select Yes, then all sourcing history present on the planning server will be deleted before the collection process commences.

  8. Select OK.

  9. Select Submit in the Planning Data Collection window to run collections immediately, or select Schedule to schedule collections for some later time.

    If you select Schedule, the Schedule window appears.

    Note: If you want to perform an incremental refresh frequently, use this feature.

    You have complete control over the timing and frequency of the collection of data from the transaction systems, and the timing and frequency of planning. You can manage the balance between network traffic and the need to monitor current status in your plans.

  10. Select a frequency for running the job in the left pane. Complete any additional fields that appear based on your selection.

  11. Click OK.

  12. Choose Submit in the Planning Data Collection window.

  13. From the toolbar, choose View > Requests to view the status of the collection process.

    The Find Requests window appears.

  14. Select a type of requests to view then select Find.

    The Requests Window displays data collection progress.

  15. After the collection process completes, view your results.

    If concurrent process Refresh Snapshot ends in a warning and you have configure-to-order items, there may be a setup issue with those items. Concurrent process Refresh Snapshot calls the configure-to-order applications programming interface to explode the configured bills of material and create demand in the proper manufacturing organizations. Check the log file of the configure-to-order applications programming interface for details of the setup issues and take corrective action.

    If your collections process runs on an Oracle 8i database and the collections process fails, attend to the following troubleshooting information:

    • If it fails with an Autonomous Transaction within Distributed Databases error either at any point in the Data Pull /Pull Workers run or when launching Refresh Snapshots, set profile option FND:Log Enabled to No.

    • If it fails in Planning Data Pull Worker when collecting sales orders or hard reservations, either set profile option OM:Debug Level to null value or set it to a value lower than 5

  16. From the Navigator window, choose Collection > Workbench.

    Notice that data is brought over from selected instances.

    Note: Users can collect forecasts into the planning server. If you want the collections program to collect a forecast set, select the Advanced Planning Collections checkbox while defining the forecast set.

Data Changes That Can Be Collected in Net Change Mode

When the net change mode for collections is selected (by setting the collections parameter Complete Refresh to No), the data changes shown in the following table can be collected. If you set the collections parameter Complete Refresh to yes, the collections program collects the entire data for the entity.

All other data changes must be collected by running full collections (by setting the collections parameter Complete Refresh to Yes). Net change collections run more quickly than full collections.

You can run data collections in net change mode for these transactions:

Data Element Comments
Sales orders Cancellations of or modifications to sales orders and sales order reservations are captured. Net change collections always collects sales orders; it is not dependent on any parameters or settings, including collection parameter Pull Sales Orders.
Reservations against demands Reservations against both external and internal sales order demands are captured. Set the Planning Data Pull parameter Reservations to Yes.
Master production schedule demands MPS demands that are added, modified or relieved in the source instance are captured. Set the Planning Data Pull parameter Master Production Schedules to Yes.
Master demand schedule Set the Planning Data Pull parameter Master Demand Schedules to Yes.
WIP component demands Demand changes due to cancellation of WIP jobs, changes in the state of WIP jobs (for example, operations within a job have been performed or cancelled), and changes to WIP jobs because of changes in item information are captured. Set the Planning Data Pull parameter Work in Process to Yes.
WIP repetitive item demands Demand changes due to cancellation of WIP repetitive schedules, changes in the state of WIP repetitive schedules, and changes to WIP repetitive schedules because of changes in item information are captured. Set the Planning Data Pull parameter Work in Process to Yes.
Forecast demands Changes and deletions in forecasts are captured. Set the Planning Data Pull parameter Forecasts to Yes.
User demands Changes to user demands because of changes to item information are captured. Set the Planning Data Pull parameter User Supplies and Demands to Yes.
Master production schedule supplies Changes in supply schedules or item information are captured. Set the Planning Data Pull parameter Master Production Schedules to Yes
User supplies Changes to user supplies because of changes to item information are captured. Set the Planning Data Pull parameter User Supplies and Demands to Yes.
Purchase order supplies Changes to PO supplies because of rejections, returns, or cancellations or changes to item information are captured. Set the Planning Data Pull parameter Purchase Orders/Purchase Requisitions to Yes.
On-hand supplies Set the Planning Data Pull parameter On Hand to Yes.
Work orders in Oracle Work in Process Changes in WIP Jobs are captured. Set the Planning Data Pull parameter Work in Process to Yes.
Resource availability You can use net change mode in discrete manufacturing organizations. Set the Planning Data Pull parameter Resource Availability to Collect and Regenerate Data.
If you are a process manufacturing organization, use complete refresh.
Supplier capacity Set the Planning Data Pull parameter Approved Supplier Lists to Yes.
Bills of material All BOM changes are captured: new components, disabled components, component quantities, effectivity dates, BOM revisions, and component substitutes. Set the Planning Data Pull parameter Bills of Materials / Routings / Resources to Yes.
Routing operations Changes to and deletions of routing operations as a result of changes to operation sequences (for example, the addition of new operations, the disabling of operations, or the changing of operation dates), the disabling of a routing, the changing of routing dates, or changes to item information (for example, the disabling of an item, the creation of a new item) are captured. Set the Planning Data Pull parameter Bills of Materials / Routings / Resources to Yes.
Components needed for a routing operation Changes to and deletions of components needed for a routing operation are captured. Set the Planning Data Pull parameter Bills of Materials / Routings / Resources to Yes.
Resources attached to a routing operation Changes to and deletions of operation resources or operation resource sequences within a routing are captured. Set the Planning Data Pull parameter Bills of Materials / Routings / Resources to Yes.
Resource requirements for WIP jobs Changes in resource requirements of WIP jobs because of completion of the WIP jobs, completion of operations within the WIP jobs, or changes in item information are captured. Set the Planning Data Pull parameter Work in Process to Yes.
Items or Item categories Changes in items and items categories are captured. Set the Planning Data Pull parameter Items to Yes.

Transactions (supply and demand) change more frequently than setup entities. After data collections, the collections program maintains snapshots of transaction entities. Each time you run data collections, the collections program looks at the snapshot to determine if the transaction entity has changed since the previous collections. If it has, the collections program collects the incremental data changes and updates the snapshot. As setup entities change less frequently, the collections process does not keep snapshots for these and cannot perform net change collections on them. Schedule either a targeted or a complete refresh for setup.

You cannot run data collections in net change mode for the following setup entities:

Continuous Collections

Continuous collection is an automated process that synchronizes snapshot-enabled data entities (supply and demand) and snapshot-disabled setup entities (suppliers, customers and supplier rules) between the sources and the planning server. You can schedule separate collection programs for collecting data entities and setup entities.

The Continuous Collections concurrent program performs the process of continuous collections. You have to select only those business entities for which the collections process needs to run automatically. The Continuous Collections concurrent program determines the appropriate mode of performing collections for the selected business entities. You can run continuous collections on the following entities:

The following table details whether or not snapshots are associated for the entities supported by continuous collections:

Entities Snapshot Associated
Approved supplier lists (Supplier capacity) Yes
Bills of material Yes
Routings Yes
Resources Yes
Bills of resources Yes
Forecasts Yes
Items Yes
Master demand schedule Yes
Master production schedule Yes
On hand quantity Yes
Purchase orders Yes
Purchase requisitions Yes
Sales orders Yes
User supplies and demands Yes
Work in process Yes
Available to promise rules No
Calendars No
Demand classes No
End item substitution No
Key performance indicator targets No
Planning parameters No
Planners No
Projects and tasks No
Reservations No
Resource availability No
Safety stock No
Sourcing history No
Sourcing rules No
Subinventories No
Trading partners (customers and suppliers) No
Unit numbers No
Units of measure No
User company association No

For entities without snapshots, the concurrent program always initiates targeted refresh.

You can plan to use continuous collections when extensive transactions are involved. For example, a manufacturing company with extensive work in process transactions might setup continuous collections to run every 20 minutes to collect on hand balance. Similarly, Oracle Collaborative Planning users might schedule continuous collections every 2 minutes if they want to view the current supplies status.

Running Continuous Collections

To collect data from an Oracle Applications transaction instance

  1. Sign on using the Advanced Supply Chain Planner responsibility or the Advanced Planning Administrator responsibility.

  2. From the Navigator, select Collections > Oracle Systems > Continuous Collection.

    The Continuous Collections window appears.

    This window enables you to schedule the process of data collection, set parameters that are required for running Continuous collections, select language preferences, and specify the notification tasks that need to be triggered on completion of Continuous collections.

  3. Click in the Parameters field to set values that the concurrent program would require to perform Continuous collections.

    The Parameters window appears.

    Specify Yes for the entities that you want the Continuous Collections concurrent program to consider for collection. Most of the fields in this window are similar to the parameter fields for the Standard collections process. The parameter that distinguishes the Continuous collections process from the Standard collections process is Snapshot Threshold (%). By default, the threshold value is set to 40%. You can change this value.

  4. Select OK.

  5. Select Schedule in the Continuous Collections window to schedule collections.

    The Schedule window appears.

  6. Select the frequency for running collections in the left pane. Complete any additional fields that appear based on your selection.

  7. Click OK.

  8. Select Submit in the Continuous Collections window.

  9. From the toolbar, choose View > Requests to view the status of the collections process.

    The Find Requests window appears.

  10. Specify the type of request you want to view.

  11. Select Find.

    The Requests window displays the status of the data collection process.

    After the collection process completes, view the result in the Collection Workbench.

Legacy Collection

Legacy Collection provides an open framework for consulting and system integrators to bring data from legacy systems into Oracle APS / CP. You can upload data by batch upload of flat files. This is achieved in part by extending the interface table capabilities. A preprocessing engine validates the incoming data from legacy application and ensures that referential integrity is maintained. All business objects can be imported into APS using flat files.

In addition to collecting data from your ERP instance to your planning instance, you can collect data to the Planning instance from:

To collect data from your non-Oracle ERP systems or your trading partners' systems, you model each non-Oracle ERP system or trading partner as an Oracle Applications organization and store their setup and transaction data there. Setup information includes organization setup, items, bills of material, resources, routings, and sourcing information. Transaction data is of the following types:

You can perform the following steps to collect data from your trading partners' non-Oracle systems to your planning instance:

The following diagram illustrates the flow of data from non-Oracle ERP (legacy) systems to an Oracle ERP application and the planning server.

Data Flow

the picture is described in the document text

Setup for Collection of Transaction Data into the Planning Server

Legacy Collections Data Notes

OWNING_PARTNER_SITE_CODE: Organization code

OWNING_TP_TYPE: Valid values are:

PLANNING_PARTNER_SITE_CODE: Organization code

PLANNING_TP_TYPE: Valid values are:

Resource Balance Flag: Indicates whether a resource is load balanced. Valid values are:

This flag is only for Oracle Process Manufacturing. Since you cannot use legacy collections with Oracle Process Manufacturing, always leave this field null.

Unit of Measure: Load all base unit of measure comversions without an item name This creates rows in MSC_UOM_CONVERSIONS with inventory_item_id = 0, for example:

For specific conversions across UOM Class or specific intra-class unit of measure conversions for some items, load them using the item name

Process

You push legacy data, such as items, bills of materials, routings, etc. into Oracle APS interface tables using batch upload. Batch upload is done using Oracle SQL*Loader. SQL*Loader requires that data is brought over in a format described in a control file. Oracle has provided control files for all the interface tables. The list of control files is available in Oracle iSupport.

The following diagram shows the movement of data from legacy systems into the Oracle APS server via interface tables using the batch upload process.

Legacy Application

the picture is described in the document text

Setting up Batch Uploads

The System Integrator must do the following to set up the batch uploads:

  1. Map the Oracle APS interface tables' control files (a control file is a template that specifies the input data format) to the legacy system's tables. The list of control files is available in Oracle iSupport.

  2. Create scripts to extract data from the legacy system in the format prescribed by the control files.

    When loading for trading partner sites, provide values for the location for organizations (Partner Type = 3); do not provide values for the location for customer and supplier sites (Partner Type = 1 or 2).

    For example, the following is the control file for Purchase Order Supplies (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

)

The script to extract Purchase Order data for this format from a legacy system hosted on an Oracle database could look like the following:

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;

  1. Run the scripts to get the Data files and ftp these to the APS concurrent manager node. The steps to upload these files into Oracle APS are described below under Running Legacy Collections.

Sequence of Data Uploads

Load all this information either together or in the following order:

  1. Upload calendar data information. All the calendar data files corresponding to calendar's control files (MSC_ST_CALENDARS.ctl, MSC_ST_WORKDAY_PATTERNS.ctl, MSC_ST_SHIFT_TIMES.ctl, MSC_ST_CALENDAR_EXCEPTIONS.ctl, MSC_ST_SHIFT_EXCEPTIONS.ctl) need to be uploaded in one single run. Based on the information provided, the calendar is built in the planning system. If calendar already exists in ODS tables (Planning System) and you want to rebuild the calendar again, then the entire information (all the above mentioned files) must be sent again. Also, in this case for MSC_ST_CALENDARS.ctl the OVERWRITE_FLAG should be sent as Y.

  2. Upload the UOM information. The control file for this is MSC_ST_UNITS_OF_MEASURE.ctl.

  3. Upload the Demand Class information.

  4. Upload the Trading Partner information. The control files for setting up trading partners are MSC_ST_TRADING_PARTNERS.ctl, MSC_ST_TRADING_PARTNER_SITES.ctl, MSC_ST_LOCATION_ASSOCIATIONS.ctl, MSC_ST_SUB_INVENTORIES.ctl and MSC_ST_PARTNER_CONTACTS.

    The trading partner sites, location associations, sub inventories and contacts can be uploaded along with the trading partner information and also in subsequent runs. Only MSC_ST_TRADING_PARTNERS.ctl can be uploaded in the first run.

    MSC_ST_TRADING_PARTNERS.ctl has CALENDAR_CODE field. This should refer to a valid calendar code existing in the planning system or to a calendar code that you are uploading in this run of collections. If calendar does not exist in the planning system and has not been uploaded either, then the trading partner record is not accepted and is marked as error.

  5. Upload the category sets information. The control file for setting up category sets is MSC_ST_CATEGORY_SETS.ctl

  6. Upload the designators information for forecast, MDS and MPS. The control files required are: MSC_ST_DESIGNATORS_MDS.ctl, MSC_ST_DESIGNATORS_FORECAST.ctl and MSC_ST_DESIGNATORS_PLAN_ORDERS.ctl. The forecast, MDS and MPS records can be uploaded now or in subsequent runs.

  7. Upload the projects and tasks information. The control file name is MSC_ST_PROJECT_TASKS.ctl

  8. Upload the items information as per the MSC_ST_SYSTEM_ITEMS.ctl file. If the UOM_CODE of the data file has an invalid value (that is, a value that does not exist in the planning system and is also not being uploaded along with items as per the MSC_ST_UNITS_OF_MEASURE.ctl in this upload) the item records are errored out.

  9. Upload the item related information; for example, supplier capacity, supplies and demands, categories, UOM conversions, and sourcing rules. Upload the data as per the preprocessing diagram shown below and make sure that the items are valid; that is, the items exist in the planning system or are being uploaded in this run of legacy collections.

  10. Upload categories using control file MSC_ST_ITEM_CATEGORIES.ctl.

  11. Upload sourcing rules using control file MSC_ST_ITEM_SOURCING.ctl.

  12. Upload UOM conversions using MSC_ST_UOM_CONVERSIONS.ctl, MSC_ST_UOM_CLASS_CONVERSIONS.ctl.

  13. Upload resources using control file MSC_ST_DEPARTMENT_RESOURCEs.ctl.

  14. Upload bill of materials using the following control files: MSC_ST_BOMS.ctl, MSC_ST_BOM_COMPONENTS.ctl, and MSC_ST_COMPONENT_SUBSTITUTES.ctl. You can upload BOM components and substitutes to BOM at the same time or upload these in later runs.

  15. Upload routings using the following control files: MSC_ST_ROUTINGS.ctl, MSC_ST_ROUTING_OPERATIONS.ctl, and MSC_ST_OPERATION_RESOURCES.ctl. You can upload resources to operations at the same time or upload these in later runs.

  16. Upload supplier capacity using the following control files: MSC_ST_ITEM_SUPPLIERS.ctl, MSC_ST_SUPPLIER_CAPACITIES.ctl, and MSC_ST_SUPPLIER_FLEX_FENCES.ctl. You can upload MSC_ST_SUPPLIER_CAPACITIES.ctl with MSC_ST_ITEM_SUPPLIERS.ctl or in subsequent runs. You can also upload MSC_ST_SUPPLIER_FLEX_FENCES.ctl with MSC_ST_ITEM_SUPPLIERS.ctl or in subsequent runs.

  17. Load material supply for work order after routings are loaded because there is a field ROUTING_NAME in MSC_ST_SUPPLIES_WO.ctl.

  18. Upload resource demand using the control file MSC_ST_RESOURCE_REQUIREMENTS.ctl. If WIP_ENTITY_NAME is not valid (it was not previously loaded using the MSC_ST_SUPPLIES_WO.ctl and also is not loaded in this run using this control file) the record is errored out.

Preprocessing

After data from legacy application has been loaded into the planning system, it undergoes preprocessing before it can be used by the planning engine.

Preprocessing generates IDs for the entities coming into the planning system based on a set of user-defined keys (UDKs). For example, to identify an item record in the planning system, the UDK is Instance Code, Organization code, Item Name and Company Name (Company Name is required only if SCE is installed. For standalone APS, this is defaulted to -1). A UDK uniquely identifies an existing record in the planning system. UDKs are used as reference to update existing records in the planning system.

The preprocessing program is a concurrent program that runs independently from the planning engine and global ATP engine.

After the data files have been brought over to the concurrent manager node, as described in the Running Legacy Collections section below, the legacy collection's request set program can be configured to read and load the data files into interface tables. Following which, this program can preprocess the data and finally load the data into the main planning tables, all in a single run.

The preprocessing engine has the intelligence to handle scenarios wherein transaction data and any prerequisite setup data needed to perform this transaction co-exist in a single data load.

The figure below shows the sequence in which the uploaded data is processed by the preprocessing engine. The preprocessing engine possesses parallel processing capabilities. Parallel processing is enabled for processing Items and Item-related entities as shown in the diagram. Items, supplies and demand records can further be broken into sub-batches and processed in parallel.

Preprocessing

the picture is described in the document text

The above architecture also makes it necessary to ensure that all the setup related data is sent to the planning system to avoid errors while processing the transactions. For example, a purchase order line coming into the planning system referring to an item that has not been sent to the system is flagged as an error. Also, the supplier for the item should have been defined on the system as a valid one.

Records in the staging tables are checked for multiple occurrences of the same UDK combination. For instance, in the case of data coming in via XML, if two or more item records are found in the interface table having the same combination of instance code, organization code, item name and company name, preprocessing picks the latest record for further processing and the older records are flagged as errors. For instance, for data coming in via batch upload, if two or more item records are found in the interface table having same combination of instance code, organization code, item name and company name, preprocessing flags those records as errors because preprocessing is not able to determine which is the correct record to be picked up.

To set up Legacy Instance

The system default installation creates one instance partition and five plan partitions. Use this process if you need to create an instance partition.

  1. From the Navigator, select Requests > Run.

    The Submit a New Request screen appears.

  2. Select Single Request and select the OK button.

    The Submit Request form appears.

  3. In the Name field, select Create APS Partitions and select the OK button.

    The Parameters screen appears.

  4. Enter the number of plan partitions and instance partitions and select the OK button.

    The partitions are created.

  5. Change to the Advanced Planning Administrator responsibility. From the Navigator, select Admin > Instances.

    The Application Instances screen appears.

  6. Specify the Instance Code for the Legacy Instance and set the Instance Type as Other. Leave the fields From Source to APS and From APS To Source blank. Fill the other fields for the instance as specified in the online help.

    You are now set to use the Batch Load solution. Using the Running Legacy Collections process described below, upload the Workday Calendar data and Planning Organizations for this instance. This data can be uploaded along with the other entities' data. Preprocessing has the intelligence to consider the new organizations that have come in the same batch upload. After Legacy Collection is completed, you can view these organizations using the Organizations button at the bottom of the Instance Setup form.

    Note: Setting up batch uploads and setting up legacy instance steps can occur in parallel up to creation of scripts for data uploads. However, for getting the data files from the scripts, the instance code is required.

Running Legacy Collections

Using either an Oracle Applications form or the self-service application page, you can upload data from flat files to the legacy instance and finally to the planning engine. Using the form, you upload each data file separately.

Using the self-service method, you can upload a zip file containing all data files. Each type of data file, such as work order supply or BOM header, is identified using a tag in the file name. Ensure that you do not zip the entire directory but add individual files to the zip file.

To collect into a legacy instance using the form-based application

  1. Copy all the data files conforming to the control files in the $MSC_TOP/patch/<version>/import in a directory on the concurrent manager node. If there are more than one concurrent manager nodes and if these are not NFS mounted, then the data files need to be copied to all the nodes in same directory structure. This directory (or all the directories in case of multiple non-NFS mounted concurrent manager nodes) should have read/write privileges to all users, because SQL*Loader discards files for the data that could not be uploaded due to errors.

  2. Choose the Advanced Planning Administrator responsibility.

  3. In the Navigator, choose Collections > Legacy Systems > Collect Flat File Data.

    The Planning Data Collection screen appears showing three programs: Flat File Loader, Pre-Process Monitor, and Planning ODS Load. Planning ODS Load moves the data from the interface tables to the planning system's main tables.

  4. Choose the Parameters field for Flat File Loader.

    The Parameters screen appears.

  5. Enter the required information and the File Names for all the data files that you want to upload. You can either enter the directory path in the Data File's Directory field and then enter the file names for each entity to be uploaded in the File Name fields, or you can leave the Data File's Directory field blank and enter the complete path and file name of each entity in the File Name fields. The second option is useful if all the data files are not kept in the same directory.

    The Total Number of Workers field specifies the number of maximum number of loader workers that should be running in parallel at any given point in time. A loader worker is launched for each File Name specified.

  6. When finished entering information for this screen, choose the OK button.

  7. Choose the Parameters field for Pre-Process Monitor.

    The Parameters screen appears.

  8. Specify the entities that you want to be preprocessed for the legacy instance.

    The Processing Batch Size field determines the size of batches while processing the records in the interface tables. A larger batch size is faster but requires more system resources. The current default batch size is 1000.

    The Total Number of Workers field specifies the number of concurrent processes to be launched to process the data in parallel.

  9. When finished entering information for this screen, choose the OK button.

  10. Choose the Parameters field for Planning ODS Load.

    The Parameters screen appears.

  11. Specify whether you want Resource Availability and Sourcing History to be recalculated after the data has been moved.

  12. When finished entering information for this screen, choose the OK button.

    The Planning Data Collection screen appears.

  13. Press the Submit button to allow the concurrent manager to schedule the request as per the schedule options that you specify in the At these Times... section.

  14. Use the View Requests Form to monitor the progress of the different programs.

  15. Use the View Collected Data menu option under Collections in the Navigator to view the data coming into the planning system.

To collect into a legacy instance using the self-service application

  1. Double-click Collections > Legacy Systems Collect Flat File Data - Self Service.

    The Oracle Collaborative Planning suite page appears.

  2. Click the Download link to download the Oracle Applications (OA) template.

    All zipped .dat files, for example, bills of material and calendar appear.

    You can read the OATemplateReadme.html file for information on how to load various entities into Oracle Advanced Planning and Scheduling suite of products using flat files. You can open the ExcelLoad.xlt file and import your data files to view and modify.

  3. In the Collaborative Planning suite page, click Browse to navigate to the data files location.

  4. Select the zip file containing data files to be uploaded.

  5. Click Start Load Now.

    The concurrent request starts. You can note down the request id for your reference.

    After the completion of this request, navigate to Collections Workbench to view the collected data.

Purge Program

The Purge program deletes the data from the ODS table as well as the local id table (MSC_LOCAL_ID_XXX). Depending upon the option selected while submitting the concurrent program, it behaves differently as explained below.

To access purge UI

  1. Choose the Advanced Supply Chain Planner responsibility.

  2. From the Navigator, choose Collections > Legacy System > Purge Collected Data.

    If you selected Yes for Complete Refresh when you submitted the concurrent program, the following screen appears.

    The following table shows the values for this screen.

    Field Value
    Instance Legacy instance against which the purge program is to be run.
    Complete Refresh Yes
    Delete records up to date User-entered date (defaults to the current date)
    Delete supplies Yes (will always be Yes if complete refresh is Yes)
    Delete demands Yes (will always be Yes if complete refresh is Yes)

    In this case, the following tables get purged from 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 (Here program updates disable date as current date instead of deleting)

    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

    In addition, the entities listed in the following table, which are stored in the LID table will be deleted.

    Entity Name LID Table Name Business Object
    SR_INVENTORY_ITEM_ID MSC_LOCAL_ID_ITEM Item
    ABC_CLASS_ID MSC_LOCAL_ID_MISC Item
    BILL_SEQUENCE_ID MSC_LOCAL_ID_SETUP BOM
    COMPONENT_SEQUENCE_ID MSC_LOCAL_ID_SETUP BOM
    ROUTING_SEQUENCE_ID MSC_LOCAL_ID_SETUP Routing
    OPERATION_SEQUENCE_ID MSC_LOCAL_ID_SETUP Routing
    RESOURCE_SEQ_NUM MSC_LOCAL_ID_SETUP Routing
    DEPARTMENT_ID MSC_LOCAL_ID_SETUP Department/Resources
    LINE_ID MSC_LOCAL_ID_SETUP Department/Resources
    RESOURCE_ID MSC_LOCAL_ID_SETUP Department/Resources
    PROJECT_ID MSC_LOCAL_ID_MISC Project/Tasks
    TASK_ID MSC_LOCAL_ID_MISC Project/Tasks
    COSTING_GROUP_ID MSC_LOCAL_ID_MISC Project/Tasks
    SR_CATEGORY_ID MSC_LOCAL_ID_MISC Categories
    DISPOSITION_ID_FCT MSC_LOCAL_ID_DEMAND Demand (Forecast)
    DISPOSITION_ID_MDS MSC_LOCAL_ID_DEMAND Demand (MDS)
    SALES_ORDER_ID MSC_LOCAL_ID_DEMAND Demand (Sales Order)
    DEMAND_ID MSC_LOCAL_ID_DEMAND Demand (Sales Order)
    DISPOSITION_ID MSC_LOCAL_ID_SUPPLY Supplies
    PO_LINE_ID MSC_LOCAL_ID_SUPPLY Supplies (PO/Req)
    SCHEDULE_GROUP_ID MSC_LOCAL_ID_SUPPLY Supplies (MPS)
    DISPOSTION_ID_MPS MSC_LOCAL_ID_SUPPLY Supplies (MPS)
    SR_MTL_SUPPLY_ID MSC_LOCAL_ID_SUPPLY Supplies (On Hand)
    WIP_ENTITY_ID MSC_LOCAL_ID_SUPPLY Supplies (WIP)

    The Purge program does not delete records related to following business objects from ODS or LID tables.

    • Trading partners (organization, supplier, customer)

    • Calendars

    • Category sets

    • Sourcing rules

    • UOM

    If you selected No for Complete Refresh when you submitted the concurrent program, the following screen appears.

    The following table shows the values for this screen.

    Field Value
    Instance Legacy instance against which the purge program is to be run.
    Complete Refresh No
    Delete records up to date User-entered date (defaults to the current date)
    Delete supplies Yes/No (defaults to Yes)
    Delete demands Yes/No (defaults to Yes)

    In this case, only supply/demand business object records and those records whose creation date is less than user-entered date get deleted from the ODS and LID tables.

Loading Transaction Data Using Flat Files Into ERP Instance

Using either an Oracle Applications form or the self-service application, you can upload transaction data (supply and demand) from flat files to the ERP instance.

Ensure that the transaction data is uploaded to the planning server using either legacy systems directly or an Oracle ERP application. To avoid double counting, do not upload the same transaction data to both Legacy and ERP instances. For example, a sales order should not be uploaded using both ERP and Legacy instances.

Loading Transaction Data Notes

If you are importing the .dat file for the first time, then Excel prompts you to enter these values. Once you enter them, you do not need to enter them again:

Before uploading CSData.dat, set the date format in ExcelLoader to YYYY/MM/DD.

To collect into an ERP instance using the form-based application

  1. Navigate to the Planning Data Collection form (Collections > Oracle Systems > Load Transaction Data using Flat Files).

    The Planning Data Collection form appears showing three programs: Load Transaction Data, Pre-Process Transaction Data, and Planning ODS Load. The Load Transaction Data program loads the transaction data through flat files into interface tables. Load Transaction Data accepts parameter values including the path for control and data files.

    The Pre-Process Transaction Data program preprocesses the transaction data and generates ids. Pre-Process Transaction Data enables you to specify the instance in which you want to load the transaction data.

    Planning ODS Load program moves the data from the interface tables to the main tables of the planning server.

  2. Click in the Parameters field for Load Transaction Data.

    The Parameters window appears.

  3. Enter the required information and the file names for all the data files that you want to upload. Specify the maximum amount of time you would like to allocate to the concurrent program in the Time Out Duration field. You can either enter the directory path in the Data File's Directory field and then enter the file names for each entity to be uploaded in the File Name fields, or you can leave the Data File's Directory field blank and enter the complete path and file name of each entity in the File Name fields. The second option is useful if all the data files are not kept in the same directory.

  4. When you finish entering information in the fields, click OK.

  5. Click in the Parameters field for Pre-Process Transaction Data.

    The Parameters window appears.

  6. Select the instance from a list of values.

  7. After specifying the instance in which you want to load the transaction data, specify the maximum time allowed for the process in the Time Out Duration field (in minutes).

    The Processing Batch Size field determines the size of batches while preprocessing the records in the interface tables. A larger batch size is faster but requires more system resources. The current default batch size is 1000.

    The Total Number of Workers field specifies the number of concurrent processes to be launched to process the data in parallel.

  8. Specify the entities that you want to be preprocessed for the ERP instance. Yes indicates the entities that need to be preprocessed.

  9. When you finish entering information in the fields, click OK.

  10. Click in the Parameters field for Planning ODS Load.

    The Parameters window appears.

    The Planning ODS Load parameters required for data collection in the ERP instance is similar to the parameters required for legacy collections.

  11. Specify the values for the parameters and click OK.

  12. Click Submit in the Planning Data Collection window.

  13. From the toolbar, choose View > Requests to view the status of the collections process.

    When the request is complete, you can view the data in Collection Workbench.

To collect into an ERP instance using the self-service application

  1. Double-click Collections > Oracle Systems > Load Transaction Data using Self Service Loads.

    The Oracle Collaborative Planning suite page appears.

  2. Click the Download link to download the Oracle Applications (OA) template.

    All zipped .dat files, for example, bills of material and Calendar appear. A readme providing information on how to use the templates is also provided in this zip file.

  3. Open the ExcelLoad.xlt file and import your data files to view and modify. After making the changes, export the data file. Finally, zip all data files that need to be uploaded.

  4. Click Browse to navigate to the data files location.

  5. Select the zip file containing data files to be uploaded.

  6. Click Start Load Now.

    A concurrent request is triggered.

    After the completion of this request, navigate to Collections Workbench to view the collected data.

Customization

System integrators may want to add custom validations for enabling preprocessing to filter out unwanted incoming data. The preprocessing engine provides hooks for each entity, which can be used to plug-in custom validations.

Organization Specific Collections

Oracle Advanced Supply Chain Planning supports organization-specific collections, which helps you in maintaining independent planning processes in independent business units of a company that is running a single instance of the Oracle e-Business Suite.

You can run collections for collecting data from only specified organizations of a source instance. This helps you in elimination of unnecessary data collection from organizations that are not planned in your planning process and reduce the processing time.

Oracle Advanced Supply Chain Planning allows organization-specific collection for:

To setup organization specific collections

  1. Select Advanced Planning Administrator responsibility.

  2. Navigate to Admin > Instances.

    The Application Instances form appears.

  3. Define the instance.

  4. Click Organizations.

    The Organizations form appears.

  5. Select the Enable check box for the organizations of the defined instance.

  6. Specify Collection Group for the organizations.

    Assign all related organizations to the same collection group to ensure that group organizations are collected together.

To perform organization specific collections

  1. Select the Advanced Supply Chain Planner responsibility.

  2. Navigate to Collections > Oracle Systems > Standard Collections.

  3. The Planning Data Collection form appears.

  4. Click the Parameters field for the Planning Data Pull program.

  5. The Parameters window appears.

  6. Select the Collection Group.

Regardless of the Collection Group value, Oracle Advanced Supply Chain Planning always collects the following:

In addition, the collection programs collects all calendars to accommodate all trading partner shipping and receiving calendars.

Collection from a Single Source to Multiple Destinations

Oracle Advanced Supply Chain Planning allows you to collect a single source instance to multiple destination instances. This is useful when you need to perform volume testing, where you need to collect from a source production instance to a test destination instance while still generating production plans out of a production planning server instance. Both of the planning server instances can share the same production source transaction instance.

Collection from a single source to multiple destinations allows you to leverage the setup and transaction data in the production source instance to do volume testing on the test planning server instance. You can avoid duplicating the source instance and reduce substantial amount of storage and maintenance costs.

Note: The source and destination (planning server) instances do not need to be on the samerelease.

For example, you can have a test R12.1 destination instance and R11i other destination instance. Both can collect from the same R11i e-Business Suite Source instance.

The critical factor in such a design is the patching management.. If you have to apply patch to one instance, you may have to apply the same patch to all three instances. For example, you may patch the R12.1 destination instance and it requires a patch on your R11i e-Business Suite Source instance. Then, you may need to apply the same patch the same patch may need to be applied to your R11i other destination instance.

To setup collection from a single source to multiple destinations

Perform these steps in each In each of your multiple destination instances.

  1. Select Advanced Planning Administrator responsibility.

  2. Navigate to Admin > Instances.

    The Application Instances form appears.

  3. Associate destination instances to source instance in each destination instance separately.

  4. Select the Allow ATP check box for the destination instance that you want to consider in the ATP process from the source instance.

    You can select the Allow ATP check box for only one of the destinations that are associated to a single source.

    The planning engine displays an error message if you attempt to select more than one destination for ATP.

  5. Select the Allow Release ATP check box for the destination instances that are allowed to release to the source instance.

    The Allow Release Flag check box is used for both auto release and manual release processes.

    You can select the Allow Release check box for multiple destinations that are associated to a single source.

To trigger the Auto Release process for a plan:

  1. Select the Allow Release check box for the instance where the plan is defined in the Application Instances form.

  2. Select the Production check box for the plan in the Plan Names form.

Example: Using the Allow ATP option

Consider:

The ATP request from source S points to D1. The planning engine performs the ATP process in D1 taking into consideration the plans that have ATP check box selected in the Plan Names form.

In destination instance D2, there could be plans with the ATP check boxes selected in the Plan Names form. The ATP process from D2 uses these plans. There are no restrictions in checking the ATP check boxes in the Plan Names form in destinations.

Conclusion: You can select the Allow ATP check box in the Application Instances form for only one of the destinations associated to a single source

Example: Using the Allow Release option

Consider:

The plans in D2 with the Production check boxes selected in the Plan Options form trigger the Auto Release process to source.

You can select the Production check boxes for plans in D1 but they will not trigger any Auto Release process to source. This is because the Allow Release check box is not checked for D1 in the Application Instances form.

Conclusion: You can select the Allow Release check box for multiple destinations that are associated to a single source.