Scribd
Upload
188 views8 pages

Best Practices - Oracle Apps R12 AR Data Import V1.0

This document provides best practices for building data interfaces from non-Oracle legacy systems to Oracle Accounts Receivable R12. It recommends using Oracle sequences to generate unique party references, mapping people based on actual names rather than IDs, automatically reprocessing erroneous records, and having separate error alerts for missing data not caught by Oracle import programs. Justifications provided include low maintenance, flexibility, independence from database instances, and full proof error handling. The practices are intended to help reduce maintenance costs and make the interface more flexible and instance independent.

Uploaded by

dassambit2000
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
188 views8 pages

Best Practices - Oracle Apps R12 AR Data Import V1.0

This document provides best practices for building data interfaces from non-Oracle legacy systems to Oracle Accounts Receivable R12. It recommends using Oracle sequences to generate unique party references, mapping people based on actual names rather than IDs, automatically reprocessing erroneous records, and having separate error alerts for missing data not caught by Oracle import programs. Justifications provided include low maintenance, flexibility, independence from database instances, and full proof error handling. The practices are intended to help reduce maintenance costs and make the interface more flexible and instance independent.

Uploaded by

dassambit2000
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

Best Practice

TCS Internal

Title
Practice: Oracle ERP Name of the project: SABIC Canada R12 Oracle Finance Implementation Name of the author: Amol Jagzap. Date Created: 20th May 2009

24 August 2009

Description
Project / Context
The Oracle Finance R12 implementation for SABIC CANADA region. 2 parts involved: 1. Setup oracle to meet customer requirement. 2. Build interfaces between different Non-Oracle legacy systems and oracle to keep data in sync.

Purpose
Purpose of this document is to share good Practices while building data (Invoice, Customer) Interfaces from Non Oracle legacy systems to oracle AR R12.

24 August 2009

How we did it
Practices recommended:
Use of oracle sequence to generate party reference. Quantity unit should be a Customer selling unit. Automatic Reprocessing of erroneous records. Mapping People between 2 systems based on the Actual names than the people ids. Formation of set of line attributes using Invoice Number, Line Type and line number. Insert/Update flag should be set depending on the existence of data in Oracle than the date comparison. Have separate missing data error alerts for the once which are not alerted by Oracle import programs. Recommended list of fields for Invoice and Customer

Highlights Low maintenance. Flexible. Independent of DB instances. Full proof error handling.
24 August 2009

Why this is a best practice


Justification
Use of oracle sequence to generate party reference. Party Concept is new in Oracle R12. ORIG_SYSTEM_REFERENCE in the HZ_PARTIES table requires a unique value. While importing customers ORIG_SYSTEM_PARTY_REFERENCE is the corresponding field in the Customer Interface table. It is preferable to use Oracle Sequence to get a unique value for this field. So that any kind of Party Imports (Customer, Supplier etc) can access the same sequence without causing any overlap. There are oracle application sequences which are used when parties are created from front end. You can separate out the range of both Sequences by specifying the starting value. Quantity unit should be a Customer selling unit. It is a good practice to use Customer Selling unit on the Front end as it helps for the collection department during follow up.

24 August 2009

Why this is a best practice


Justification
Automatic Reprocessing of erroneous records. In the recurrent incremental interface program, include a model which updates records for the missing data. For example: It might happen that The invoice fails due to missing payment term and that Term is setup by the user later in the day. So the interface while running next time should update the corresponding Id before processing the record Same can happen with Ship To / Bill To Ids etc. Mapping People between 2 systems (Eg. Mapping Sales Person) based on the Actual names than the people ids. Its more logical to map using Person Name than the ID, as IDs might change due to expiration or any other purpose. Formation of set of line attributes using Invoice Number, Line Type and line number. This can uniquely identify the line. Attached is setup instructions for the same.

Interface_Line_DF F

24 August 2009

Why this is a best practice


Justification
Insert/Update flag should be set depending on the existence of the record in Oracle over the date comparison method. This will make the interface independent of Source/Destination Instances (Dev/Test/Prod). Have separate missing data error alerts for the once which are not alerted by Oracle import programs. Fields like Salesperson, Region are not compulsory in Oracle, so the record doesnt error out if that data is missing. This data can actually be missing because say for example the Sales Reps in Legacy system is not setup in Oracle. So its advisable to check for such errors separately and generate alerts as required. Recommended list of fields for Invoice and Customer Attached is the list of fields which we recommend to populate to make sense from the Invoice/Customer that is loaded.
R12 AR Require Fields

24 August 2009

How this may be adapted elsewhere


Benefits
Reprocessing Ability reduces the maintenance cost Customer is benefited due to good error handling and the flexibility of the code. Instance independence saves efforts of TCS team while moving tests between Dev, test instances. The savings on the maintenance cost are recurring.

Replication
Note that these is specifically meant for the data imports from Non Oracle legacy systems to Oracle R12 ERP. I expect this document to help while team is preparing the MD70s and working on the mapping between data attributes of 2 systems.

Contact Info
Amol Jagzap - 161807 [email protected] TCS, Mumbai

24 August 2009

You might also like