How to Upload Documents to Legacy Employment Applications

thirteen/23

Collecting from Legacy Systems

This chapter covers the following topics:

• Overview
• Setting Upwards the Drove of Transaction Data into the Planning Server
• Procedure
• Setting Up Batch Uploads
• Sequence of Data Uploads
• Preprocessing Engine
• Setting Upward Legacy Instance
• Running Legacy Collections Using the Class-Based Awarding (Collect Flat-File Data)
• Running Legacy Collections Using the Self-Service Application (Collect Flat-File Data - Cocky Service)
• Purging Legacy Data
• SRP Streams - Self Service
• Shipment History - Cocky Service

Overview

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

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

• Your not-Oracle (legacy) systems.

• Your trading partners' non-Oracle systems

To collect data from your non-Oracle ERP systems or your trading partners' systems, you can either model each non-Oracle ERP organisation or trading partner as:

• an Oracle Applications arrangement and store their setup and transaction information in that location.

• a 100% Legacy drove, in which case no standard EBS instance is defined or nerveless from.

Setup information includes organization setup, items, bills of material, resources, routings, and sourcing information. Transaction data is of the post-obit types:

• On-manus remainder

• Purchase orders

• Purchase requisition

• Work orders

• Piece of work Order component demand

• Intransit shipment and receipt

• Planned orders

• Local forecasts

• Need schedules

• Sales orders

• Item suppliers

• Supplier capacities

• Supplier flex fences

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

• Load setup data (such equally items, BOMs, Trading Partners) from the trading partner'due south system to apartment files. Load the apartment files to the source (Oracle EBS) instance using the standard interfaces and use standard collections to move information technology to the destination (planning) server.

• Load transaction data from flat files to the staging tables (MSC_ST%) on the planning server. Use legacy collections to move data from the legacy example to the planning server.

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

Data Flow

Setting Up the Collection of Transaction Data into the Planning Server

To set up upwards the collection of transaction information into the Planning Server

• Ascertain two types of organizations in the source instance. The offset arrangement is for OEM and the second is for supplier and customer. You also need to define sourcing rules between the OEM organization and the supplier and customer organisation.

• Import the setup data from your non-Oracle ERP organization into the supplier and customer organisation using the Oracle EBS open interfaces such equally Items open interface, BOM open interface.

  To load the organizations for trading partners, y'all must showtime define the trading partners in previous loads .

• Collect all data from the OEM and supplier and customer organizations into your destination instance (planning server).

• Load transaction data into each supplier and customer organisation'southward apartment files. Using either an Oracle Applications form or the cocky-service application, yous can load data from the non-Oracle ERP system into the organizations. If you are using the self-service method, you can upload a zero file containing all the data.

Process

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

The following diagram shows the movement of information from legacy systems into the Oracle VCP server via staging tables using the batch upload procedure.

Legacy Application

Setting Upwardly Batch Uploads

To set up batch uploads

You must exercise the post-obit to set upwardly the batch uploads:

1. Map the Oracle VCP staging tables' control files (a control file is a template that specifies the input information format) to the legacy system's tables. All the control files (*.ctl) are installed in $MSC_TOP/patch/115/import. All files are named for the staging table to be populated. For example, the Items Base table is MSC_SYSTEM_ITEMS, so we populate MSC_ST_SYSTEM_ITEMS using MSC_ST_SYSTEM_ITEMS.ctl file.

   Note: Control files similar MSC*_F.ctl are for the Advanced Planning Control Centre application and not relevant to the Advanced Supply Chain Planning awarding.

2. Create scripts to excerpt data from the legacy organization in the format prescribed by the command files.

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

   For example, the following is the control file for Purchase Order Supplies (MSC_ST_SUPPLIES_PO.ctl)

OPTIONS (BINDSIZE=one thousand thousand, 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,i)", UNIT_NUMBER, NEW_ORDER_QUANTITY, NEW_DOCK_DATE, PROJECT_NUMBER, TASK_NUMBER, PLANNING_GROUP, DELIVERY_PRICE, QTY_SCRAPPED, FROM_ORGANIZATION_CODE, ORDER_TYPE CONSTANT 'one' DELETED_FLAG "DECODE(:DELETED_FLAG,1,1,2,two,2)", COMPANY_NAME "NVL(:COMPANY_NAME,-one)", 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 Abiding '1', DATA_SOURCE_TYPE CONSTANT 'BATCH', LAST_UPDATE_LOGIN Abiding '-1', LAST_UPDATE_DATE SYSDATE, CREATION_DATE SYSDATE )

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

Gear up Caput OFF'; SET LINESIZE 200; Set PAGESIZE 50000; SPOOL ON; SPOOL MSC_ST_SUPPLIES_PO.dat; SELECT Singled-out ITEM_TAB.ITEM_NAME||'~'|| ITEM_TAB.ORGANIZATION_CODE||'~'|| PO_TAB.EXPECTED_DELIVERY_DATE||'~'|| SITES_TAB.TP_NAME||'~'|| one||'~'|| /* 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||'~'|| Yeah||'~'|| PO_TAB.UNIT_PRICE||'~'|| 0||'~'|| ane ||'~'|| /* All records are either for Insert/Alter. No deletions are being uploaded */ Yes||'~'|| -one||'~'|| 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 go the data files and ftp these to the concurrent manager node. The steps to upload these files into Oracle VCP are described below nether Running Legacy Collections.

Sequence of Information Uploads

Data must be uploaded in a specific sequence because fields from some dat files may employ values that are defined in other dat files. For example, since there are calendar_code references in MSC_ST_TRADING_PARTNERS.ctl, agenda information needs to be loaded before trading partner information.

Load all this data either together or in the following guild:

1. Upload calendar data data. All the calendar data files corresponding to calendar'south command 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 on the VCP server. If calendar already exists in ODS tables on the VCP server and you desire to rebuild the calendar over again, so the entire information (all the above mentioned files) must exist sent again. Also, in this instance for MSC_ST_CALENDARS.ctl the OVERWRITE_FLAG should be sent every bit Y.

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

3. Upload the Need Grade data.

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 exist uploaded along with the trading partner information and also in subsequent runs. Just 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 on the planning server or to a calendar code that you are uploading in this run of collections. If calendar does not exist on the planning server and has not been uploaded either, then the trading partner record is non accepted and is marked every bit mistake.

5. Upload the category sets information. The command file for setting upwardly category sets is MSC_ST_CATEGORY_SETS.ctl

6. Upload the designators information for forecast, MDS and MPS. The command 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 at present or in subsequent runs.

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

8. Upload the items information every bit 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 likewise 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 particular related information; for instance, supplier chapters, supplies and demands, categories, UOM conversions, and sourcing rules. Upload the data as per the preprocessing diagram shown below and brand sure that the items are valid; that is, the items be in the planning arrangement or are existence uploaded in this run of legacy collections.

10. Upload categories using command file MSC_ST_ITEM_CATEGORIES.ctl.

11. Upload sourcing rules using command 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 neb of materials using the following command files: MSC_ST_BOMS.ctl, MSC_ST_BOM_COMPONENTS.ctl, and MSC_ST_COMPONENT_SUBSTITUTES.ctl. You tin 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 fourth dimension or upload these in later runs.

16. Upload supplier chapters using the following control files: MSC_ST_ITEM_SUPPLIERS.ctl, MSC_ST_SUPPLIER_CAPACITIES.ctl, and MSC_ST_SUPPLIER_FLEX_FENCES.ctl. Yous can upload MSC_ST_SUPPLIER_CAPACITIES.ctl with MSC_ST_ITEM_SUPPLIERS.ctl or in subsequent runs. Y'all can likewise upload MSC_ST_SUPPLIER_FLEX_FENCES.ctl with MSC_ST_ITEM_SUPPLIERS.ctl or in subsequent runs.

17. Load fabric supply for work guild after routings are loaded because in that location 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 Engine

Afterward data from the legacy application has been loaded onto the planning server, it undergoes preprocessing before it can exist 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 detail record in the planning organization, the UDK is Instance Code, Organisation code, Item Name and Visitor Name. (Visitor Proper noun is required only if Collaborative Planning is being deployed, which requires that the profile MSC: Configuration is set to the Advanced Supply Chain Planner responsibleness to either 'APS and CP' or 'CP'. For standalone VCP, the contour is set to 'APS' and this value defaults to -1.) A UDK uniquely identifies an existing record in the staging tables. UDKs are used as reference to update existing records in the staging tables.

The preprocessing programme is a concurrent program that runs independently from the Planning engine and Global ATP engine.

Afterward the data files take been brought over to the concurrent managing director node, the legacy drove request sets the pre-processing engine to read and load the data files into the staging tables. It can then preprocess the data and load the data into the primary planning tables (ODS), all in a single run.

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

The effigy 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 equally shown in the diagram. Items, supplies and need records tin farther be cleaved into sub-batches and processed in parallel.

Preprocessing Compages

Preprocessing Compages

The above architecture too makes information technology necessary to ensure that all the setup related data is sent to the planning server to avoid errors while processing the transactions. For instance, a purchase guild line coming into the planning server referring to an item that has not been sent to the server is flagged as an fault. Also, the supplier for the item should have been divers as well.

Records in the staging tables are checked for multiple occurrences of the same UDK combination. For example, in the example of data coming in via XML, if two or more than item records are constitute in the staging table having the same combination of instance code, arrangement lawmaking, particular name and visitor proper 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 staging table having same combination of example code, organization code, item name and company proper noun, preprocessing flags those records as errors because preprocessing is not able to determine which is the correct record to be picked up. Error messages are written to the staging table in cavalcade ERROR_TEXT in each MSC_ST Staging tabular array.

Information Cleansing

Preprocessing cleanses the incoming data to make it fit for the planning engine. Data that are invalid but are not critical for planning purposes are automatically replaced past default values. This is washed to avoid the overhead of resending data. In such cases alert letters are generated. Based on these warning messages, you tin can resend corrected information. These corrected values then supercede the default values.

Mistake Processing

Errors occur in preprocessing if any of the critical validations fail. In such cases the records are immediately flagged with an error status and practice not undergo further processing. These errors are logged in the Oracle VCP table, MSC_ERRORS. These records can be resubmitted later correcting the errors reported by the preprocessing engine.

If XML Gateway is installed, error and warning messages encountered during preprocessing tin exist emailed to the System Administrator, whose email id can be specified in a XML Gateway profile, ECX: System Administrator E-mail Address.

Net Alter

Preprocessing works on the cyberspace alter principle. Users need to send just new and changed information to the planning server between successive program runs. Nonetheless, a purge program has been provided to carry out a complete refresh. Later a consummate refresh, all setup and transaction information have to be pushed over again into the Oracle VCP server. The purge plan also allows partial deletion of supplies and demands. Supply and demand records that fall earlier than a user-specified appointment tin can exist deleted from the VCP server.

Data Transformation

Character fields have been provided in some cases even where the planning engine requires a numeric value for easy accommodation to legacy data. If numeric values are provided in these fields then the preprocessing engine will pass on the aforementioned value to the planning engine. Otherwise it will either generate a new numeric value corresponding to the graphic symbol value or default a pre-adamant constant. For example, the planning engine expects the calendar's shift identifier to be a numeric value. The legacy application may define its workday shifts equally A, B and C. The preprocessing engine would then generate a new numeric value respective to these graphic symbol values. It and so passes these shift numbers to the planning engine for subsequent processing. Other examples of this kind of flexibility are operation sequence number and resource sequence number. If these fields get a nonnumeric value, instead of not accepting the tape, preprocessing replaces these with a numeric constant - one.

Denormalized Tables

To simplify mapping of the staging tables to the legacy awarding's tables, wherever possible the staging tables accept been denormalized. For instance, the sourcing rules can be uploaded using a single table. This information is then broken down past preprocessing and sent to four dissimilar tables within the VCP server. Denormalization has been provided for:

• sourcing rules

• projects and tasks

• resource availability and simulations sets

• forecast sets and forecasts

• routings

Workday Calendar Build

You lot have the option of building the workday calendar in the VCP server past providing just summary information: calendar get-go date, end engagement, shift information, workday design and exceptions. The preprocessor has an embedded agenda build program, which will explode this data to get the working and nonworking days and also the shifts available for each working 24-hour interval. You must specify the workday calendar lawmaking for each planning organization that you upload into the VCP server. Otherwise, the record for the planning organization will not be accepted. You may want to rebuild the calendar if there is a change in the summary information at the source. This tin can be easily accomplished past simply uploading the new summary information with the agenda'south OVERWRITE_FLAG fix to 'Y'.

Purge Program

You can purge all uploaded data or selectively purge supply and demands with dates on or earlier a engagement that yous specify. However, calendars, planning organizations, suppliers and customers cannot exist purged. Except for the calendar, these can be disabled if required.

Customization

You may want to add custom validations to enable preprocessing to filter out unwanted incoming data. The preprocessing engine provides hooks for each entity that can be used to plug in custom validations.

Setting Up Legacy Instance

To ready up legacy example

The system default installation creates one instance partition and five program partitions. Use this process if yous need to create an case sectionalization.

1. From the System Administrator responsibility, select Requests > Run.

   The Submit a New Request screen appears.

2. Select Single Asking and select the OK push.

   The Submit Asking grade 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 Ambassador responsibility. From the Navigator, select Admin > Instances.

   The Application Instances screen appears.

6. Specify the Case Code for the legacy instance and set the Case Type every bit Other. Leave the fields From Source to APS and From APS To Source blank. Fill up the other fields for the instance as specified in the online help.

   Yous are at present set to use the batch upload solution. Using the Running Legacy Collections process described below, upload the Workday Calendar data and Planning Organizations for this instance. This data tin be uploaded along with the other entities' data. Preprocessing has the intelligence to consider the new organizations that take come up in the same batch upload. After Legacy Drove is completed, yous tin can view these organizations using the Organizations button at the bottom of the Example Setup form.

   Notation: 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.

7. Error letters for errors that occurred during preprocessing can be sent to the system administrator if Oracle XML Gateway is installed. You can specify the email address for sending the error messages using the Profile ECS: Arrangement Administrator Electronic mail Address.

8. For enabling XML entering/outbound for the planning organization, yous need to install the Oracle XML Gateway. Later on the planning organizations have been collected, the valid transactions for each of these organizations can be registered in the XML Gateway. To configure the XML Gateway, please refer to the Oracle XML Gateway User Guide.

Running Legacy Collections Using the Grade-Based Application (Collect Flat-File Information)

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

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

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

1. Copy all the data files conforming to the command files in the $MSC_TOP/patch/<version>/import in a directory on the concurrent manager node. If at that place 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 construction. This directory (or all the directories in case of multiple non-NFS mounted concurrent managing director nodes) should accept 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 Avant-garde Supply Chain Planner, Standard responsibility.

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

   The Planning Data Drove screen appears showing 3 programs: Apartment File Loader, Pre-Process Monitor, and Planning ODS Load. Planning ODS Load moves the data from the staging tables to the ODS.

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 Information 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 consummate path and file proper name of each entity in the File Proper name fields. The second option is useful if all the information files are non kept in the same directory.

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

6. When finished inbound data for this screen, choose the OK button.

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

   The Parameters screen appears.

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

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

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

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

10. Choose the Parameters field for Planning ODS Load.

    The Parameters screen appears.

11. This program moves data from the staging tables to Oracle Value Chain Planning's main tables (ODS). Specify whether yous want the Sourcing History to be recalculated or purged subsequently the information has been moved, and whether you want to refresh the collected data in the Advanced Planning Control Center (APCC).

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

    The Planning Data Drove screen appears.

13. Press the Submit button to allow the concurrent director to schedule the request equally per the schedule options that yous specify.

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

15. Using the Advanced Supply Concatenation Planner responsibility, navigate to Collections > View Collected Data menu selection to view the data coming into the planning server.

Running Legacy Collections Using the Self-Service Awarding (Collect Apartment-File Data - Cocky Service)

The self-service awarding is used for small amounts of data.

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

1. From the Advanced Supply Chain Planner (or Advanced Planning Ambassador) responsibility, navigate to Collections > Legacy Systems > Collect Flat File Data - Cocky Service.

   The Oracle Collaborative Planning page appears.

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

   All zipped .dat files, for example, bills of material and agenda announced.

   You tin read the OATemplateReadme.html file for information on how to load diverse entities into Oracle VCP using flat files. Open the ExcelLoad.xlt file, and import your data files from the APS card to view and change them.

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

   • 1: Yes

   • ii: No

   This flag is merely for Oracle Process Manufacturing. Since you cannot use legacy collections with Oracle Process Manufacturing, e'er get out this field nothing.

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

   • Base UOM: LB

   • Standard conversions: KG - LB, Gram - LB, Kiloton - LB, mg - LB, Oz - LB, Ton - LB,

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

3. When all files accept been imported to the templates, aught the files.

4. From the Oracle Collaborative Planning page, File Proper noun field, click Scan to navigate to the zip file location.

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

6. Click Get-go Load Now.

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

   After the completion of this request, navigate to Collections Workbench to view the nerveless information.

Purging Legacy Data

There are two options for purging legacy data:

• Purge Collected Information deletes the information from the ODS table as well as the local id table (MSC_LOCAL_ID_XXX).

• Purge StagingTables purges Oracle Applications and legacy information from the staging tables. Employ information technology before launching new collections when a previous data collection run failed, or if y'all detect data corruption in the staging tables.

To purge collected data

1. Choose the Avant-garde Supply Chain Planner responsibleness.

2. From the Navigator, choose Collections > Legacy Arrangement > Purge Nerveless Information. The Purge Parameters window appears.

   The post-obit table shows the values for this screen.

   Field	Value
   Instance	Legacy source instance confronting which the purge program is to be run.
   Consummate Refresh	Specify whether to perform a consummate refresh or not. Valid values: No, Yes.
   Delete Records Up to Appointment	The date range up to which all the records will exist deleted from the collected data. Defaults to the current date.
   Delete Supplies	Specify whether to delete supply-related entries from the collected data. Valid values: No, Yes (will e'er exist Yes if complete refresh is Yeah).
   Delete Demands	Specify whether to delete demand-related entries from the collected data. Valid values: No, Yep (volition always be Yep if complete refresh is Yes).

Example: Complete Refresh = Yes, Delete Supplies and Demands

In this example, 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 (Hither program updates disable date as current engagement 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 tabular array, which are stored in the Hat table volition be deleted.

Entity Proper 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/Resource
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	Need (MDS)
SALES_ORDER_ID	MSC_LOCAL_ID_DEMAND	Demand (Sales Order)
DEMAND_ID	MSC_LOCAL_ID_DEMAND	Demand (Sales Club)
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 plan does non delete records related to post-obit concern objects from ODS or Chapeau tables.

• Trading partners (system, supplier, customer)

• Calendars

• Category sets

• Sourcing rules

• UOM

Note: For the items in the _LID tables, a complete refresh for ALL organizations deletes the data. When the profile choice MSC: Purge Staging and Entity Key Translation Tables is set to Y, then the ID_LID tables are truncated during the key transformation in the ODS load phase.

Example: Complete Refresh = No, Delete Supplies and Demands

If you lot practise non request a complete refresh, just supply/need business object records and those records whose creation date is less than the user-entered date get deleted from the ODS and Chapeau tables.

To purge staging tables

1. Use the Advanced Supply Concatenation Planner responsibility.

2. From the Navigator, cull Collections > Legacy Arrangement > Purge Interface Tables. The Submit a New Request window appears.

3. Select Single Request and click OK. The Submit Request window appears.

4. Select Purge Interface Tables from the Reports list. The Parameters window appears.

5. Set the parameters and click Submit.

   The following tabular array shows the values for this screen.

   Field	Value
   Instance	Legacy source example against which the purge program is to be run.
   Delete Rejected Records But	Specify whether to delete only the rejected records or all records.

SRP Streams - Self Service

Legacy collections are supported for usage history for Demantra. Legacy collections of Install Base of operations under Contracts are not currently supported. For more information about the EBS Service Parts Planning to Demantra Demand Management Integration, see "Demantra Demand Management to EBS Service Parts Planning Integration" in the Oracle Demantra Integration Guide.

To load usage history

1. From the Advanced Supply Concatenation Planner responsibility, navigate to Collections > Legacy > SRP Streams - Self Service. The Load SRP Streams form appears.

2. File Proper name: Specify the legacy data file. In the case of multiple files, the planner can unload a zip file with the individual .dat files.

   Notation: You tin can download templates for individual .dat files from this page.

3. Launch Download: Bank check this option if you would similar to brainstorm the download and launch the Demantra SPF Full Download workflow.

4. Instance: Cull from the bachelor source instances.

5. Click Kickoff Load Now to load the legacy information file(s) now.

Shipment History - Self Service

Legacy collections are supported for shipment history for Demantra. For more information, see:

• "Demantra Demand Management to EBS Service Parts Planning Integration" in the Oracle Demantra Integration Guide

• "Demantra Predictive Trade Planning to Siebel Integration" in the Oracle Demantra Integration Guide

.

To load usage history

1. From the Advanced Supply Chain Planner responsibility, navigate to Collections > Legacy > Shipment History - Self Service. The Load Shipment History grade appears.

2. File Proper noun: Specify the legacy data file. In the case of multiple files, the planner tin can unload a zippo file with the private .dat files.

   Note: You can download templates for private .dat files from this folio.

3. Launch Download: Check this option if y'all would like to begin the download and launch the Demantra SPF GL Data Download workflow.

4. Instance: Choose from the bachelor instances.

5. Click Start Load Now to load the legacy data file(southward) at present.

lassiterdeareing.blogspot.com

Source: https://docs.oracle.com/cd/E26401_01/doc.122/e48791/T578797T578808.htm

Bagikan Artikel ini