Oracle Cloud ERP Financials – TCA – Suppliers and Customers – Data conversion
Your company is thinking about moving onto the Oracle Cloud ERP system. You’ve been tagged as one of the resources to lead or assist with data conversions.
Very important and difficult data conversion is Suppliers and Customers. There are often tens of thousands of these records built up over decades. A clean conversion into the Oracle Cloud system will ensure that your transition to the Oracle Cloud Accounts Payable and Accounts Receivable modules will be smooth.
A tried and true method of ensuring success in this area is to start early. Develop the Scope, Approach, and Objectives right away, which means “GET ORGANIZED.” This discussion is meant to provide you a roadmap to help you get organized.
What is TCA?
It is important to first understand Oracle’s TCA before diving into the specifics of Suppliers and Customers.
TCA stands for Trading Community Architecture. TCA is a centralized repository of Party information. TCA is designed to minimize duplicative party information. Assume you have a Customer who is also a Supplier; TCA provides a mechanism where only one Party needs to be created, which can support both the Supplier and Customer needs in Accounts Payable and Account Receivable.
Guide to Oracle Cloud: 5 Steps to Ensure a Successful Move to the Cloud
Explore key considerations, integrating the cloud with legacy applications and challenges of current cloud implementations.
Once on Oracle Cloud, the TCA should be your single source of truth for your Party information.
What is a Party?
A Party is an Entity that we interact with. A Party is a Person, a Business, a Contact, a Bank, an Employee, and so on. We can call these entities on the phone, buy from, sell to, have an account with, use as a contact for, etc. They have legal standing and can be used as a named party on a legal contract. We pay to or receive money from Parties. We contact a Party when we have an issue with services rendered, goods delivered, or a Late Payment.
TCA first categorizes every Supplier or Customer Party as a Person or Organization type Party at the highest level. Parties are further categorized to how they are used within Oracle, e.g., a Supplier, Customer, Employee, etc.
How are Parties created?
Oracle automatically creates Parties when creating an Entity that represents a Party. The main types of Parties in Oracle Cloud Financials are Suppliers, Customers, Employees, Banks, Contacts, and the Legal Entities of your company.
For instance, when a user creates a Supplier from the Supplier creation screen, a Party is created with a Supplier usage. Thus, the user is simply creating a “Supplier,” and Oracle does the rest.
How does TCA assist in minimizing duplicative Party data with respect to Supplier and Customers?
Oracle can identify potential duplicate parties when creating either a Supplier or a Customer. When a potential duplicate is identified, the user can either use the existing party, create a new party, or cancel Supplier or Customer creation to allow for further research.
How to prepare Supplier and Customer data for conversion into the Oracle Cloud Financials?
Preparing for the conversion of your Supplier and Customer data can and should start as soon as possible.
Activities that can be undertaken before the project begins to include:
- Identify who from your organization will be your track lead for the conversion.
- Ideally, this is a person or persons central to the creation and management of Supplier and Customer data.
- Have a meeting with the users of Supplier and Customer information
- Users include Procurement, Accounts Payable, Sales and Marketing, Accounts Receivable, and anyone else who uses this data to conduct business or create an analysis.
- Identify all the systems that hold Supplier and Customer data.
- Make a list of the strengths and weaknesses of your current systems concerning this data.
- Make a list of missing features or functions and categorize each as a “must” or “nice to” have
- Determine which system(s) best represents a source of truth
- Identify the population of data to be converted, typically;
- All customers and suppliers who;
- Have an open balance
- Have or have had transactions over the preceding two or three years
- Are newly created that have not yet had a transaction
- Determine how and who will retrieve the data from your source systems
- If possible, extract your data into a single flat file, one for suppliers and one for customers.
- Include system identifiers in the flat files if available
- Some systems have table level id’s that are unique to a record irrespective of user displayed fields.
- Include other identifiers that inbound or outbound satellite systems rely upon if they are live after the implementation
- All customers and suppliers who;
Start cleansing your source data.
This will be the most labor-intensive aspect of your Supplier and Customer conversion. Look for:
- Duplicate Supplier or Customers
- Suppliers who are also Customers and vice versa
- Suppliers and Customers who are parents of other Suppliers or Customers
- Suppliers that share Taxpayer ID’s but have different “doing business as” Names.
- Supplier and Customers’ names should be spelled exactly equal to their Legal Name.
- Spelling conventions – adopt a strategy to adhere to a common approach:
- Don’t mix all uppercase with a proper case for any field.
- Abbreviations should be consistent:
- Street = St., Road = Rd., Post Office Box = PO Box, etc.
- Addresses, ensure each is;
- An address that represents what would go on a mailing
- They are categorized by the proper Country.
- Address Lines, Cities, States, Provinces, and Postal codes are used consistently for each system;
- Address Lines are used only for street addresses and “Attention” type details.
- Cities, States, Provinces, and Postal Codes are pertinent to the Country of the address.
- Whether County information is needed to support US Sales and Use Tax and if so, Counties are present where needed
- Supplier or Customer site definition
- Sites are often used to provide a significant level of defaulting behavior onto transactions.
- For example, your Ledger currency may be USD, but you have a Supplier who invoices in CAD. The site for that Supplier can be set to use CAD as their default Invoice currency, where most other suppliers simply use the Ledger currency of USD
- Sites can also provide a Payment method default for a Supplier that is different than the general Payment method.
- For example, you may have a general rule that all Suppliers are paid by ACH. However, there are a couple of Suppliers who require to be paid by check. Oracle can accommodate both the general rule as a system-level setting and the exception as a supplier site setting.
- Sites are often used to provide a significant level of defaulting behavior onto transactions.
What are some of the critical data fields that are needed for Suppliers and Customers?
- Name of the Supplier or Customer, i.e., the Party Name
- A usage, whether a Supplier or Customer or both.
- Parent Suppliers and Customers and who their children are
- Addresses
- Sites, i.e., how each address is used
- Taxpayer ID’s
- Tax Organization Type – Corporation, Partnership
- Type of Business – Retail, Wholesale, Attorney
- Business classifications – Minority, Woman, Veteran-owned
- Tax Reporting Requirements – US and International
- Form of Payment or Receipt – ACH, Wire, Check
- Contacts – who to call for Payables or Receivables issues at a minimum
- Account Payable Remittance delivery emails for electronic payments
- Bank information for supplier payments or customer receipts
- Relationship to other Suppliers or Customers
- Any other field that your organization uses on its Supplier or Customer data model
