Creating Parties, Customer Accounts and Sites and creating party relationships

Creating Parties, Customer Accounts and Sites and creating party relationships:

The customer data is an important master data for all enterprises. The Oracle Trading Community Architecture (TCA) creates a central repository for the entire E-Business Suite to store information relating to all members of a trading community (including customers) versus separate tables for each member. The TCA model helps enterprises to record complex business relationships between Trading Community entities (including 3rd party relationships) and it supports all business models, industries, and geographies.

Yum Brands is the parent company for Pizza Hut and Taco Bell. This post explains how your company can think of modeling these three companies in your customer master based on industry best practices.

If your company has ‘Business Relationship’ with all three companies, they will need to be individually created as separate parties.

If your company has ‘Selling Relationship’ with all three companies, they will also need to be individually created as separate accounts.

The below screen shots explains how the three companies can be defined as three separate parties with individual customer accounts and sites. All of the invoices for all the three companies will be sent to Yum Brands headquarters in Delray Beach, FL. But the services are performed at 3 separate locations which are modeled below:

Once the parties, customer accounts and sites are created, we are now ready to assign relationships to the three parties. For this we navigate to ‘Relationship Manager’ and setup YUM BRANDS as a Parent of PIZZA HUT and TACO BELL as below:

Evaluating Customer MDM Options

Many enterprises are faced with the challenge to implement a robust customer MDM solution. One of my clients had a very similar challenge and in this post I have explained in detail the approach we took to evaluate two different customer MDM options and the recommendation we made at the end of the evaluation.

The client in question had Siebel CRM as the front end Prospect and Customer Account creation system. The client had implemented Oracle R12.1.3 Ebusiness suite for their Order to Cash solution.

Customer MDM Option 1:

• Siebel will be the single point of entry for Customers and Address records
• Siebel will integrate with Trillium and D&B
• Oracle EBS will be the source of truth for Customer Records (GOLDEN RECORD)
• Other Enterprise Systems will subscribe to EBS for Customer Data
  
  

Customer MDM Option 2:

• Oracle EBS will integrate with Trillium and D&B
• Oracle EBS will be the source of truth for Customer Records (GOLDEN RECORD)
• Other Systems will subscribe to Oracle EBS for Customer Data
• In future Source systems can be added/removed without a significant change to the process

 

 

Comparision between Option 1 and Option 2:

Recommending Option 1 for the client:

• Recommended approach
• EBS is the master and system of record for Party and Customer Accounts
• Siebel would be the system of record to initiate it with data cleansing and validation
• Leverage client's current knowledge base and use of Trillium, D&B, SDR
• Use Trillium Realtime connector for data cleansing and enrichment
• Define D&B call details for enrichment
• Data Stewarts would exist both within Siebel Apps and EBS for addressing data relating to:
• Customer and Party attributes, including relationships
• EBS specific attributes for customer accounts etc (for example ACH, Credit card No, etc)

Credit Card Payment Processing in AR

Many clients will have the requirement to process customer credit card payments in a seamless fashion within Oracle AR. The Oracle Payments (previously iPayments in Rel 11) module enables this functionality working with Oracle AR using a 3 step process:

• Create Invoices: Create invoices in AR with payment method= ‘credit card’
• Credit Card Authorization: Create and approve receipt which includes getting approval codes through Oracle payments and Payment gateway/Payment Processor. Tyco is currently using Chase Paymenttech as a payment processor which Oracle has certified for R12 (Metalink Doc. ID: 471385.1) so we may want to use the same in the future.
• Credit Card Fund Capture: Generating remittances and capture fund through Oracle payments and Payment gateway/Payment Processor. 

What is PSON?

• PSON stands for Payment Server Order Number and this is used by Payments during the funds capture settlement process. This field is located at receipt workbench and is populated by Oracle Payments after authorizing fund.
• Process for ACH processing:
• Oracle Payment, through Funds capture, supports ACH payment and can be integrated with any Payment system for Electronic fund transfer. For Tyco, Payment system can be their remittance banks. 
• Process for ACH processing is same as credit card processing (Create Invoices, Authorization and Fund Capture/ Settlement) with following differences: 
• Authorization step is optional for ACH
• ACH does not block funds during authorization
• Bank information is validated only once and then it is stored as a profile in Oracle payments whereas credit card payment needs approval (PSON) for every transaction.

   

Why TCA Matters for Clients running Oracle Ebusiness Suite

Why TCA Matters - What clients get from the TCA architecture:

• Architecture to model your customers and other trading partners as you see best for your business
• Architecture that will grow with your requirements
• Features to maintain extremely reliable customer information (e.g. ABC Co. is now sure that their supplier John of XYZ Inc is the same person as their customer, John of XYZ Inc)
• Glue that ties several E-Business Suite flows in a seamless way
• Customer Data Integration solution even if you are not running a single E-Business Suite module
• Platform that can play a key role in your IT landscape for Master Data Management

Why TCA Matters - What clients have to do:

• Take a close look at how you do business and how your business processes are most efficiently performed
• Ask questions about how you should model customer information e.g. which entities should be modeled as parties; when should you create an account; should you create multiple accounts for some parties; should you create multiple billing sites for an account; should you create account relationships
• Even if you are implementing few modules of E-Business Suite to start with, keep in mind the bigger picture about customer information

Oracle TCA uptakes in Oracle Release 12

TCA update in R12 to additional entities:

• Banks & Bank Branches
• Suppliers
• Legal Entity

TCA in R12 - New Bank Account Model:

• Central place to define internal bank accounts
• Keep track of all bank accounts in one place
• Explicitly grant account access to multiple operating units/functions and users
• Multi-Org Access - In the new model, bank accounts are owned by Legal Entities with the option to grant account use to Operating Unit (Payables, Receivables), Legal Entity (Treasury), Business Group (Payroll)

TCA in R12 - Bank model benefits:

• Reduce number of access points to manage bank accounts - Centralized user interface
• Improve visibility and control of bank accounts - Multi-org access control
• Simplify bank reconciliation - Single bank statement can be reconciled across multiple Operating Units
• Increase percentage of automatically reconciled transactions - Bank account level reconciliation parameters add flexibility

TCA in R12 - Supplier Representation:

• Supplier organizations are in TCA
• Terms of doing business with the supplier are in Purchasing / Payables
• Supplier organization, address, contact, phone, email etc. are all in TCA
• Employees are already in TCA, Payables using the same employee records in TCA
• New supplier maintenance UI using TCA UI components

TCA in R12 - Benefits of Supplier representation:

• Single repository for suppliers data
• AR/AP netting
• Oracle Payments serves as a payment data repository on top of the Trading Community Architecture (TCA) data model. The TCA model holds the party information. Oracle Payments then stores all of the party’s payment information and its payment instruments (including credit cards, debit cards, customer bank accounts, and supplier bank accounts).

TCA in R12 - Legal Entities:

• Legal entity is created as a party of party type ORGANIZATION or PERSON
• An establishment is created as a party of party type ORGANIZATION
• TCA creates a new classification category called “Business Function”. It is used mainly to model what business functions a party can perform in E-Business Suite
• For modeling legal entities and establishments in TCA, classification code “Legal Entity” and “Establishment” are created under the “Business Function” class category
• An establishment is created as a party and always link to a party that is classified as a legal entity through the relationship model

TCA in R12 - Integration with HRMS:

• TCA creates the global view of person
• TCA enables you to store person Information at a corporate level
• Person is stored as party in TCA
• Comprehensive duplicate person check when entering a new person – Across the business group
• Propagate some information entered in one business group to the record in the other business group
• PER_ALL_PEOPLE_F.PARTY_ID is a foreign key to the HZ_PARTIES table, an integral part of Oracle's "Trading Community Architecture" (TCA).

Oracle Trading Community Architecture (TCA) - key concepts

I have seen many clients who do not understand the power of TCA architecture and how they can effectively use the TCA model to design their customer master. In this post I will explain the key TCA concepts and I will also try (in later posts) to take a real world example of customers and model it in the Oracle Release 12.1.3 environment.

TCA = Trading Community Architecture; Data Model and not Module. TCA provides a single, universal definition of trading partners across applications and job function.

A Trading Community Architecture is a way to understand who our trading partners interact with inside and outside the enterprise. TCA puts a foundation in place for a trading partner model:

• Linking Suppliers and Customers
• Online Marketplace
• Shared Service Centers

How did TCA come about?

• First introduced in 11i
• Introduction of Oracle CRM application
• Requirement for a common customer model for all Oracle Applications
• Model evolved from working with ERP and CRM teams to create a view of the customer base which supports all flows throughout the E-Business Suite
• To support both B2B and B2C business models
• Re-architected to enable future support for entire trading Community

Guiding Principles of TCA:

• Create a central repository for the entire E-Business Suite to store information relating to all members of a trading community versus separate tables for each member
• Prospects, Customers, Contacts, Employees, Partners, Distributors, Suppliers, Banks, etc.
• Record complex business relationships between Trading Community entities (including 3rd party relationships)
• Support all business models, industries, and geographies

TCA Data Model: Parties vs. Accounts:

• From an application perspective, one of the most important things to understand about the TCA model is that the concept of “customer” is separated into two layers: The Party layer and the Account layer.
• When CRM applications refer to “Customer” they are referring to the Party Layer.
• On the other hand, when ERP applications refer to “Customer” they are referring to the Account Layer.
• Thus, confusion arises because both are using the word “Customer” to refer to two different things.

Other features of TCA:

• Public API’s for data manipulation of TCA tables
• Common Party User Interface Components
• Hierarchy Model
• Bulk Import of customer data and D&B Integration
• DQM for duplicate prevention
• Party and Account Merge

TCA data dictionary:

• HZ Parties - Stores basic information about parties and their relationship. Party ID is the primary key. Party id, Party Number, Party Name and Party Type are key columns. Establishes the Business Relationships.
• HZ Locations - Stores delivery or postal address. Location ID is the primary key. Not to be used for modeling party hierarchical relationships (use party relationships). Identifies the Party and its Account. Location can cross Parties and a Party can have multiple Locations. Account (beneath the Party) inherits the Locations defined for the Party.
• HZ Party Sites - Table that links HZ Parties with HZ Locations. Party Site ID is the primary key.
• HZ Cust Accounts - Different instances of Business Relationships (Selling, etc). Multiple Accounts can exist for a Party. Cust Account ID is the primary key.
• HZ Cust Acct Sites All - Site reference to the Account . Partitioned by Org Id. Primary Key is Cust Acct Site Id.
• HZ Cust Site Uses All - Stores business purpose usage (Bill To, Ship To, etc) for the Customer Account. Site Use Id is the Primary Key. Integrated with HZ Cust Acct Sites All.
• HZ Customer Profiles - Stores credit characteristics of Party, Account, Site.
• HZ Party Relationships - Stores relationships between parties.
• HZ Cust Profile Classes - Stores credit characteristics that is common across a group of Accounts

Customer model in Oracle 11i

Features of Customer Model:

• The 11i customer model is build to handle the new requirements of CRM and e-commerce. These new requirements introduced new features and user interfaces for the 11i Customer Model

• The customer model is based on a new foundation that provides for a number of important new features in Release 11i+ and Release 12

• The 11i Customer Model handles customer types of organizations and people.

• Modify customer form to match against and link with global registry

• Establish global registry of organizations, people, locations, and the relationships among them

Global: Parties, Party sites, Locations, Customer accounts
Org-Specific: Customer account sites

• Customer addresses do not have to be duplicated across operating units -- they can be created once then referenced by different operating units

• Provides foundation for linking suppliers and customers in future.

• AR customer modules do not expose all capabilities and attributes from new model

• Party Registry

 Information about your different relationships are tied to one “source of truth” representation of the person or business
 A Party is anything that can enter into business relationships with another party


• Customer Addresses

 Multiple parties can do business at one location
 Addresses are global, not specific to operating units
 Address validation using Vertex or Tax Ware information
 Flexible address formatting with seeded and custom formats

Oracle AR 12i - how to configure and use Credit Card Chargeback features

Credit Card Chargeback:

A credit card chargeback takes place when a credit card holder disputes a charge with the credit card company (e.g. VISA) and the credit card company issues a chargeback to the customer for the disputed amount and notifies the vendor that they have issued a chargeback to the customer.
A cardholder can request a charge back for many reasons including, but not limited to:
•Charges for undelivered goods
•Charges for goods or services different from what was ordered or if they received the wrong quantity of the goods or services ordered.
•Charges for goods that were not timely delivered

In release 11i, we already have the functionality for the vendor to issue a chargeback directly to the customer. The customer can however also request a chargeback from the credit card issuer, so in release 12 - we are introducing the functionality for the vendor to also be able to register and process a chargeback that a card issuer has already issued to the customer.

Benefits:
•Reduce costs by automating the credit card chargeback process

Credit Card Chargeback Process:
After having received the credit card chargeback notification from the card issuers, the vendor will:
•Find the receipt for which the chargeback was requested.
•Un-apply the application line and subtract the amount of the credit card chargeback.
•Apply the credit card chargeback activity on a new application line on the receipt. This automatically generates a negative miscellaneous receipt to the value of the chargeback.

If the vendor finds the chargeback to be valid, the vendor creates a credit memo to credit the invoice with the amount charged back.

If the vendor can prove to the credit card company that the chargeback was not valid, the vendor reverses the application of the credit card chargeback by:
•Finding the receipt
•Un-applying the credit card chargeback activity from the receipt. This automatically reverses the negative miscellaneous receipt
•Restoring the original amount on the application line.

It is important to understand how our new Credit Card Chargeback functionality differs from the Credit Card Refunds we already have in 11i:
•Credit card refunds: The merchant needs to refund the customer. So the negative misc. receipt must be remitted.
•Credit card chargebacks: The customer has already received the chargeback, so the vendor will just need to record that a chargeback has taken place. The purpose of the misc. receipt is just to keep the accounting in place.

Business Process Steps:
The business process that takes place when a credit card chargeback needs to be recorded is a three step process:
1.The vendor receives the receipt, records it and applies it to the invoice.
2.The vendor receives the Credit Card Chargeback notification and records the credit card chargeback by applying the credit card chargeback to the receipt
3.The vendor then needs to investigate if the Credit Card Chargeback is valid or not. Based on the outcome, the vendor can choose to either:
-Acknowledge the credit card chargeback and credit the invoice, or
-Prove that the credit card chargeback was not valid, and after acknowledgement un-apply the credit card chargeback from the receipt

Credit Card Chargeback Process Receive Receipt:
Example:
•A customer visits a web store and orders goods for $100 using their credit card
•The credit card company authorizes the payment and notifies the vendor of the receipt of $100
•The vendor processes the receipt and applies it to the invoice.
Please note that there are no changes in how these activities are carried out in R12.

Let’s now take a look at the credit card chargeback process.
•The customer receives the goods, but finds that goods for $25 are missing.
•The customer files a dispute with the credit card company for $25
•The credit card company credits the customer $25 and notifies the vendor that a chargeback of $25 has taken place.
•The vendor applies the credit card chargeback to the receipt which generates a miscellaneous receipt to decrease cash with $25
Here we can see how the clearing account for the receivable activity of type ‘Credit Card Chargeback’ is used. It gets credited when the credit card charge back is applied and gets debited when the misc. receipt is generated.

Accounting Entries:

•Un-apply the receipt
–DR Receivables $25
–CR Unapplied $25
•Apply the credit card chargeback
–DR Unapplied $25
–CR Credit Card Chargeback $25
•Misc. receipt is generated
–DR Credit Card Chargeback $25
–CR Cash $25

Chargeback Process for Vendor:
1.Find receipt
2.Un-apply the receipt
3.Decrease the value on the receipt application line to $75
4.Apply $25 to receipt activity ‘Credit Card Chargeback’ (creates a negative misc. receipt of $25)

Validate Credit Card Chargeback:
After the vendor has analyzed the credit card chargeback, the vendor can find the credit chargeback to be either valid or invalid.
The vendor can now either:
•Acknowledge the credit card charge back and credit the invoice.
•Prove to the credit card company that the credit card chargeback was invalid and un-apply the credit card chargeback from the receipt once it has been acknowledged by the credit card company that the credit card chargeback was invalid.

If the vendor acknowledges the credit card chargeback, the vendor simply credits the invoice by creating a credit memo for $25.

•Credit the invoice by creating a credit memo
–DR Revenue $25
–CR Receivables $25

Vendor proves the chargeback to be invalid:

•Un-apply the credit card chargeback
–DR Credit Card Chargeback $25
–CR Unapplied $25
•Misc. receipt is automatically reversed
–DR Cash $25
–CR Credit Card Chargeback $25
•Reapply the receipt
–DR Unapplied $25
–CR Receivables $25

Credit Card Chargeback Setup:
•Responsibility: Receivables
•Navigation: Receipts > Receipts > (B) Apply > Applications > (B) Chargeback
Release 12 comes with the seeded Receivables Activity Type of ‘Credit Card Chargeback’.
The only setup step required is to create a new receivables activity of type credit card chargeback and specify the GL clearing account for the new activity.
Note: Only one activity of this type can be active.

Balance Forward Billing in Oracle AR 12i

Balance Forward Billing in 12i:

Balance Forward Billing replaces Consolidated Billing feature with enhancements to bill creation and presentation.
•Billing Cycles
-Billing cycles are no longer just monthly. Easily create daily, weekly, monthly, bi-monthly, quarterly, and annual billings
-Bill on specific days of the month. User can not only specify the day of the month for the billing date, or even multiple days like “every 15th and last day of month”. User can also elect to bill on a specific day of the week, such as every Friday.
-Choose to exclude weekends. User can skip weekends when determining billing dates, so billing dates only fall on workdays
-For importing transactions with specific dates, there is an External Billing Cycle
•Consolidate invoices at different customer levels
•Activity can be consolidated across account sites, or by each billing site. This means one bill can be sent for each billing location, or a single bill can be sent incorporating all invoices for that customer account within an organization
•Not all billing sites for a customer must consolidate their invoices. A site can be excluded from the account level bill. If a site prefers to receive individual invoices, that site can be excluded from the Balance Forward bill.
•specific invoices can be excluded from the Balance Forward Bill. By changing the payment term on an invoice, it can be printed separately

Enhanced viewing and printing:
•Balance Forward Billing integrates with Oracle Bill Management, which provides formats with a more appealing layout that can be easily modified.
In 11i, there are five consolidated bill programs. The new feature consolidates these programs into three.

Benefits:
1. Flexibility
•In 11i, you had to choose between consolidating all invoices for a customer into one monthly bill, or printing all invoices separately. Plus, if you needed different billing formats that meant customizing print layouts.
•Now you have expanded billing periods definition by using the new billing cycle concept; varied levels of consolidation; the ability to exclude specific invoices, and unlimited formats that are easily created and maintained and selected automatically by a rules engine

2. Clearer communication with the customer
•User views the balance forward bill online exactly as the customer sees it
Accurate Aging
•In 11i Consolidated Billing, the payment term assigned to the transaction was ignored if consolidated billing was enabled. This meant that the due date on an individual invoice may be different then on the consolidated bill if the payment term assigned to the invoice was different than the default payment term assigned to the customer. Aging is based on due date of the individual invoice, while payment due date was based on the payment term assigned to the customer. This caused aging to be out of sync with bills due date. Now all Invoices that are consolidated on the same bill have the same payment term and due date, guaranteeing the individual invoices will age simultaneously.

Setup and Process:
The key setup steps are:
1.Define a Billing Cycle
2.Define or update the Payment term and assign it the Billing Cycle
3.Enable Balance Forward Billing for customers wishing consolidated bills at either the site or account level.
The process is then executed as follows:
1.Enter transactions or import them using AutoInvoice or Transaction API
2.Run the Generate Balance Forward Bill Program to create the bills as either draft or final, or set it up to run automatically
•The generate program will kick off the print program in BPA to create either draft or final bills.
•In Draft format, they can be reviewed before sending.
•If the process is mature, you may elect to run Generate Balance Forward Bill Program in the create Final Bill format. In which case, the BPA program will create final bills.
3.If you create bills in draft mode, you can either reject or accept the bills using the Confirm Balance Forward Bills Program.
•You can choose to reprint draft bills via the BPA Print Program by selecting the concurrent request ID.

Balance Forward Billing Setup - Define Billing Cycle:
•Responsibility: Receivables
•Navigation: Setup:Print > Balance Forward Billing Cycles
•For Daily, you can pick the number of days before the next bill. Also choose whether to include weekends in the number of days. For example, you can choose a daily cycle that is every 5 days, not including weekends in the daily count.
•For Weekly, you can pick the number of weeks before the next bill. Also, choose the day of the week the bill will be created. For example, you can choose bi-weekly billing that occurs every other Friday.

Balance Forward Billing Setup - Define Billing Cycle:
•For the monthly cycle, choose the number of months before the next bill. For example, choose 3 months if you need quarterly billing, or 6 months if you need bi-annual billing.
•Also choose the day of the month to create the bill. This option allows you to choose more than one date so billing can occur bi-monthly on the same days each month. For example, you can set it so billing occurs on the 15th and last of day of each month.
•By choosing Type of Day, you can elect to create the bills only on the workdays Monday through Friday. When you chose “Exclude Saturdays and Sundays”, if the billing date falls on a Saturday or Sunday, the billing date automatically changes to the date of the following Monday.

Balance Forward Billing Setup - Define Payment Term:
•Responsibility: Receivables
•Navigation: Setup : Transactions > Payment Terms
•Billing Cycle is a new attribute of the Payment term and must be assigned to the payment term to process balance forward billing. This field is not updateable if the payment term has been used.
•Cutoff Date information is now setup on the billing cycle, therefore the Cutoff Date block has been removed from the payment term setup window.
•The payment schedule dates:
-Due Date is calculated based on the cycle and billing date therefore, the Due Date is not enterable for Balance Forward Bills
-The Due Days field can indicate how many days after the billing date the bill is due for daily and weekly cycles
-Day of Month and Months ahead can be used with the Monthly billing cycle. It is recommended that these only be used when a single bill day is used otherwise the due date will be the same for all the bills created during the calendar month.
•After a balance forward billing payment term has been attached to a customer profile, the cycle will not be updateable.
•Existing payment terms cannot be updated to balance forward billing payment terms and vice versa.
•Consolidated or Proxima billing terms created in 11i will automatically be updated to balance forward billing payment terms.

Balance Forward Billing Setup - Customer Profile Class:
•Responsibility: Receivables
•Navigation: Customers > Profile Classes
•The customer profile class can be updated with the Balance Forward Billing information, which can then default to the profile on the customer account record.
•This region replaces the Consolidated Bill region in 11i.
•The Enable Checkbox must be checked to select a payment term with a Balance Forward Billing cycle.
•Balance Forward Bills can be created in summary or detail format: summary is at invoice total level; detail is at the invoice line level. Imported is used for the Imported Billing Number feature that was introduced in 11i.
-Note: The default print formats use this customer profile. If you do not want to use this option, you can create rules in BPA to ignore this value. When creating a rule, use the attribute “Display Format” to look at the value in this field.
•The Payment Term field allows you to choose either a Balance Forward if the Enabled checkbox is selected, or a Non-balance forward term if the Enable checkbox is not selected.
•The Override Terms checkbox means that the default Balance Forward bill payment term on an invoice can be changed. You can only select a non-balance forward payment term if you are overriding the default. Changing the payment term on the invoice means that you do not want this invoice to be included on the bill.
•Note: This is different functionality then 11i Consolidated billing which included all in voices on the bill regardless of the payment term assigned if consolidated billing was enabled.

Oracle BPA Rules Setup:
•Rules in BPA determine which template is used for printing and viewing Balance Forward Bills. Rules are created and then the templates get assigned to them.
•If you wish to have similar functionality as was provided by Consolidated Billing, use the default rules delivered with the feature. If you wish to create new BPA rules, and you want to use the Summary/Detail Type assigned to the customer profile option, use the BPA attribute called “Display Format”.
•BPA uses the following information to create the default rules:
-The Primary Data Source must be Oracle Receivables Balance Forward. Use this source when creating your own BPA rules.
-There are two Default rules: 1) one rule uses the attribute “Display Format” = Detail, 2) another rule uses the attribute “Display Format” = Summary
-These rules are then included in the rule hierarchy.
-Templates are assigned to each of rules. You can use the delivered summary and detail templates provided by BPA, or create and use your own templates
•When you run Generate Balance Forward Bills, BPA looks at the customer profile for the value assigned to the Summary/Detail Type to determine which template to choose.

RMA (Return) Order Cycle

RMA Defined:

•Permission for a customer to return lines.
•Oracle Order Management allows you to authorize the return of your sales orders as well as sales made by other dealers or suppliers, as long as the items are part of your item master and price list.

Standard Return Flow:

Typical RMA Business Processes:

•RMA with credit only
–Your company issues a credit without the customer returning the product.
–Accept returns for credit by applying credits to original invoices or creating on account credits.
•RMA with receipt and credit
–Customer returns a product and receives credit.
•RMA with receipt and no credit
–Your customer returns a product you sent to them on a trial basis or at no charge, therefore they receive no credit.

Other RMA Types:

•RMA with repair
–Your customer returns a damaged product. Your company repairs and returns the product to the customer.
•RMA with replacement
–Your customer returns a product and your company sends a replacement product rather than issuing a credit.
•Returned item fails inspection
–Customer returns product, company inspects product and rejects it. Company scraps product or sends product back to customer.
•Trade in
–Return line on the same order as the product that the customer is purchasing.

Accounting Impact:

•During receipt of RMA in Receiving Inventory
Receiving Inventory Dr.
COGS Cr.
•During receipt into Subinventory
Material Dr.
Receiving Inventory Cr.
•During generation of Credit Memo
Revenue a/c Dr. to Receivables a/c Cr.

Tables that get updated:

•OE_ORDER_HEADERS_ALL
•OE_ORDER_LINES_ALL
•RCV_SHIPMENT_HEADERS
•RCV_SHIPMENT_LINES
•RCV_TRANSACTIONS
•RA_INTERFACE_LINES
•RA_CUSTOMER_TRX_LINES_ALL
•RA_CUSTOMER_TRX_ALL

Accounting entries in Receivables

A quick re-cap of accounting entries generated in Oracle Receivables:

Invoices:
When you enter a regular invoice through the Transactions window, Receivables creates the following journal entry:
DR Receivables
CR Revenue
CR Tax (if you charge tax)
CR Freight (if you charge freight)

If you enter an invoice with a Bill in Arrears invoicing rule with a three month fixed duration accounting rule, Receivables creates the following journal entries:
In the first period of the rule:
DR Unbilled Receivables
CR Revenue

In the second period of the rule:
DR Unbilled Receivables
CR Revenue

In the third and final period of the rule:
DR Unbilled Receivables
CR Revenue

DR Receivables
CR Unbilled Receivables
CR Tax (if you charge tax)
CR Freight (if you charge freight)

If you enter an invoice with a Bill in Advance invoicing rule, Receivables creates the following journal entries:

In the first period of the rule:
DR Receivables
CR Unearned Revenue
CR Tax (if you charge tax)
CR Freight (if you charge freight)

DR Unearned Revenue
CR Revenue

In all periods of the rule for the portion that is recognized.
DR Unearned Revenue
CR Revenue

Credit Memos:
When you credit an invoice, debit memo, or chargeback through the Credit Transactions window, Receivables creates the following journal entry:
DR Revenue
DR Tax (if you credit tax)
DR Freight (if you credit freight)
CR Receivables (Credit Memo)

DR Receivables (Credit Memo)
CR Receivables (Invoice)

When you credit a commitment, Receivables creates the following journal entries:
DR Revenue
CR Receivables

When you enter a credit memo against an installment, Receivables lets you choose between the following methods: LIFO, FIFO, and Prorate. When you enter a credit memo against an invoice with invoicing and accounting rules, Receivables lets you choose between the following methods: LIFO, Prorate, and Unit.

If the profile option AR: Use Invoice Accounting for Credit Memos is set to Yes, Receivables credits the accounts of the original transaction. If this profile option is set to No, Receivables uses AutoAccounting to determine the Freight, Receivables, Revenue, and Tax accounts. Receivables uses the account information for on-account credits that you specified in your AutoAccounting structure to create your journal entries.

Receivables lets you update accounting information for your credit memo after it has posted to your general ledger. Receivables keeps the original accounting information as an audit trail while it creates an offsetting entry and the new entry.

Commitments:
When you enter a deposit, Receivables creates the following journal entry:
DR Receivables (Deposit)
CR Offset Account

Use the AR: Deposit Offset Account Source profile option to determine how Receivables derives the Offset Account to credit for this deposit.

When you enter an invoice against this deposit, Receivables creates the following journal entries:
DR Receivables (Invoice)
CR Revenue
CR Tax (if you charge tax)
CR Freight (if you charge freight)

DR Offset Account (such as Unearned Revenue)
CR Receivables (Invoice)

When you apply an invoice to a deposit, Receivables creates a receivable adjustment against the invoice. Receivables uses the account information that you specified in your AutoAccounting structure to create these entries.

When cash is received against this deposit, Receivables creates the following journal entry:
DR Cash
CR Receivables (Deposit)

When you enter a guarantee, Receivables creates the following journal entry:
DR Receivables
CR Revenue

Receivables uses the Receivable Account and Revenue Account fields on this guarantee's transaction type to obtain the accounting flexfields for the Unbilled Receivables and Unearned Revenue accounts, respectively.

When you enter an invoice against this guarantee, Receivables creates the following journal entry:
DR Receivables (Invoice)
CR Revenue
CR Tax (if you charge tax)
CR Freight (if you charge freight)

DR Revenue
CR Receivables

When you apply an invoice to a guarantee, Receivables creates a receivable adjustment against the guarantee. Receivables uses the account information you specified in your AutoAccounting structure to create these entries.

When cash is received against this guarantee, Receivables creates the following journal entry:
DR Cash
CR Receivables (Invoice)

Receipts:
When you enter a receipt, Receivables creates the following journal entries:
DR Cash
CR Receivables

When you fully apply a receipt to an invoice, Receivables creates the following journal entry:
DR Cash
DR Unapplied Cash
CR Unapplied Cash
CR Receivables

Note: These examples assume that the receipt has a Remittance Method of No Remittance and a Clearance Method of Directly.

When you enter an unidentified receipt, Receivables creates the following journal entry:
DR Cash
CR Unidentified

When you enter an on-account receipt, Receivables creates the following journal entry:
DR Cash
CR Unapplied

DR Unapplied
CR On-Account

When your receipt includes a discount, Receivables creates the following journal entry:
DR Receivables
CR Revenue

DR Cash
CR Receivables

DR Earned/Unearned Discount
CR Receivables

Receivables uses the default Cash, Unapplied, Unidentified, On-Account, Unearned, and Earned accounts that you specified in the Remittance Banks window for this receipt class.

When you enter a receipt and combine it with an on-account credit (which increases the balance of the receipt), Receivables creates the following journal entry:
DR Cash
CR Unapplied Cash

To close the receivable on the credit memo and increase the unapplied cash balance, Receivables creates the following journal entry:
DR Receivables
CR Unapplied Cash

When you enter a receipt and combine it with a negative adjustment, Receivables creates the following journal entries:
DR Cash
CR Receivables (Invoice)

DR Write-Off
CR Receivables (Invoice)

You set up a Write-Off account when defining your Receivables Activity.

When you enter a receipt and combine it with a positive adjustment, Receivables creates the following journal entries:
DR Cash
CR Receivables (Invoice)

DR Receivables (Invoice)
CR Write-Off

When you enter a receipt and combine it with a Chargeback, Receivables creates the following journal entries:
DR Cash
CR Receivables (Invoice)

DR Receivables (Chargeback)
CR Chargeback (Activity)

DR Chargeback (Activity)
CR Receivables (Invoice)

You set up a Chargeback account when defining your Receivables Activity.

Remittances:
When you create a receipt that requires remittance to your bank, Receivables debits the Confirmation account instead of Cash. An example of a receipt requiring remittance would be a check before it was cashed. Receivables creates the following journal entry when you enter such a receipt:
DR Confirmation
CR Receivables

You can then remit the receipt to your remittance bank using one of the two remittance methods: Standard or Factoring. If you remit your receipt using the standard method of remittance, Receivables creates the following journal entry:
DR Remittance
CR Confirmation

When you clear the receipt, Receivables creates the following journal entry:
DR Cash
DR Bank Charges
CR Remittance

If you remit your receipt using the factoring remittance method, Receivables creates the following journal entry:
DR Factor
CR Confirmation

When you clear the receipt, Receivables creates a short-term liability for receipts that mature at a future date. The factoring process let you receive cash before the maturity date, and assumes that you are liable for the receipt amount until the customer pays the balance on the maturity date. When you receive payment, Receivables creates the following journal entry:
DR Cash
DR Bank Charges
CR Short-Term Debt

On the maturity date, Receivables reverses the short term liability and creates the following journal entry:
DR Short-Term Debt
CR Factor

Adjustments:
When you enter a negative adjustment against an invoice, Receivables creates the following journal entry:
DR Write-Off
CR Receivables (Invoice)

When you enter a positive adjustment against an invoice, Receivables creates the following journal entry:
DR Receivables (Invoice)
CR Write-Off

Debit Memos:
When you enter a debit memo in the Transactions window, Receivables creates the following journal entries:
DR Receivables
CR Revenue (if you enter line amounts)
CR Tax (if you charge tax)
CR Freight (if you charge freight)

DR Receivables
CR Finance Charges

On-Account Credits:
When you enter an on-account credit in the Applications window, Receivables creates the following journal entry:
DR Revenue (if you credit line amounts)
DR Tax (if you credit tax)
DR Freight (if you credit freight)
CR Receivables (On-account Credit)

Receivables uses the Freight, Receivable, Revenue, and Tax accounts that you specified in your AutoAccounting structure to create these entries.

Once the on-account credit is applied to an invoice, the following journal entry is created:
DR Receivables (On-account Credit)
CR Receivables (Invoice)

Revenue Recognition and Invoicing Rules explained

Revenue recognition principle is an important accounting principle, which is the main difference between cash basis accounting and accrual basis accounting. In cash basis accounting revenues are simply recognized when cash is received no matter when and how the services were performed or goods delivered. In accrual basis accounting revenues are recognized when they are (1) realized or realizable and (2) earned no matter when cash is received.

Revenue recognition criteria according to US GAAP:
USSEC's SAB104 states that revenue generally is realized or realizable and earned when all of the following criteria are met:
1. Persuasive evidence of an arrangement exists;
2. Delivery has occurred or services have been rendered;
3. The seller's price to the buyer is fixed or determinable; and
4. Collectability is reasonably assured

Invoicing Rules and Accounting Rules:
In Oracle AR, the invoicing and accounting rules help create invoices that span several accounting periods. Accounting rules determine the accounting period or periods in which the revenue distributions for an invoice line are recorded. Invoicing rules determine the accounting period in which the receivable amount is recorded.




Accounting Rules:
Accounting rules determines revenue recognition schedules for invoice lines. Different accounting rules can be assigned to each invoice line. Using Accounting rules, the number of periods and the percentage of the total revenue to recognize in each period can be specified. Also accounting rules can be Fixed or Variable Duration.

Clients can also create rules that will defer revenue to an unearned revenue account. This helps in the delay of specifying the revenue recognition schedule until the exact details are known. When these details are known, clients use the Actions wizard to recognize the revenue.

Invoicing Rules:
Invoicing rules determines when to recognize receivable for invoices that span more than one accounting period. Clients can only assign one invoicing rule to an invoice. Receivables provides the following invoicing rules:
• Bill In Advance: Use this rule to recognize your receivable immediately.
• Bill In Arrears: Use this rule if you want to record the receivable at the end of the revenue recognition schedule.

Using Invoices with Rules:



Assigning Invoicing Rules:
• Invoicing rules determine whether to recognize receivables in the first or in the last accounting period.
• Once the invoice is saved, you cannot update an invoicing rule.
• If Bill in Arrears is the invoicing rule, Oracle Receivables updates the GL Date and invoice date of the invoice to the last accounting period for the accounting rule.



Assigning Accounting Rules To Invoice Lines:
• Accounting rules determine when to recognize revenue amounts.
• Each invoice line can have different accounting rule.



Creating Accounting Entries:
• Accounting distributions are created only after the Revenue Recognition program is run.
• For Bill in Advance, the offset account to accounts receivable is Unearned Revenue.
• For Bill in Arrears, the offset account to accounts receivable is Unbilled Receivables.
• Accounting distributions are created for all periods when Revenue Recognition is run.

Running The Revenue Recognition Program:
• The Revenue Recognition program gives control over the creation of accounting entries.
• Submit the Revenue Recognition program manually through the Run Revenue Recognition window.
• The Revenue Recognition program will also be submitted when posting to Oracle GL.
• The program processes revenue by transaction, rather than by accounting period.
• Only new transactions are selected each time the process is run.

How to create Custom Address Styles in Oracle Apps

Client – Clients who are having Global Rollouts and need for multiple address styles.

Business Case – Need to add country specific address style formats for addresses information which are stored in the different core modules of Oracle Apps including Receivables (for Customer and Remit to Addresses), Payables (Supplier and Payment Addresses), Banks (Bank Branch addresses)

Out of the box address styles - Oracle Applications provides one default and five predefined address styles. These address styles cover the basic entry requirements of many countries. The different address styles provided out of the box are:
• Default,
• Japanese,
• Northern European and Southern European,
• South American,
• United Kingdom/Asia/Australasia,
• United States

How to add a new Address Style -

Let us say the client has a Business requirement to add a new address style for ‘Canada’. The following high level steps can be followed to define this new ‘Canada’ address style.

1. Choose address style database columns for your ‘Canada’ address style.

First you need to decide (as per client’s requirements) which columns from the database you are going to use and how you are going to order them. All the seeded address styles include the following database columns and some additional columns.

• Bank Addresses
• AP_BANK_BRANCHES.ADDRESS_LINE1
• AP_BANK_BRANCHES.CITY
• AP_BANK_BRANCHES.STATE
• AP_BANK_BRANCHES.ZIP

• Customer and Remit-To Addresses
• HZ_LOCATIONS.ADDRESS1
• HZ_LOCATIONS.CITY
• HZ_LOCATIONS.POSTAL_CODE
• HZ_LOCATIONS.STATE

• Supplier Addresses
• PO_VENDOR_SITES.ADDRESS_LINE1
• PO_VENDOR_SITES.CITY
• PO_VENDOR_SITES.STATE
• PO_VENDOR_SITES.ZIP

• Payment Addresses
• AP_CHECKS.ADDRESS_LINE1
• AP_CHECKS.CITY
• AP_CHECKS.STATE
• AP_CHECKS.ZIP

For example, in the Japanese address style, the address element called Province maps onto the STATE database column and that in the United Kingdom/Africa/Australasia address style the address element called County also maps onto the STATE database column. Oracle recommends that all custom address styles also include at least the above database columns because these address columns are used extensively throughout Oracle for printing and displaying.
Note: Most reports do not display the PROVINCE, COUNTY, or ADDRESS4/ADDRESS_LINE4 database columns for addresses.

The following screenshot gives you an idea of how to setup database columns for your ‘Canada’ address style:



2. Define ’Canada’ address style to database columns using Define Descriptive Flexfield Segments Window.

Next step is to create a new context value for each of the descriptive flexfields.

Payables – Bank Address:



Payables – Site Address:



Receivables – Address:



Receivables - Remit Address Information:



3. Add address style to the address style lookup:

Add the ‘Canada’ address style name to the Address Style Special lookup so that you will be able to assign the style to countries and territories.

To add a new style to the address style lookup:
A. Using the Application Developer responsibility, navigate to Applications > Lookups > Application Object Library.
B. Query the ADDRESS_STYLE lookup.
Receivables displays all of the address styles used by Flexible Addresses.
C. Add your new ‘Canada’ address style, as follows:



D. Enable this style by checking the Enabled check box.

4. Assign the address style to the appropriate country using the Countries and Territories window.

· Using Receivable or Payables Superuser responsibility navigate to Setup > System > Countries. · Query for Country = ‘Canada’
· Attach the ‘Canada’ Address Style created to the Canada Country
· Save the record



5. This completes the setup for the new ‘Canada’ address style, now you can use this new address style while adding new Canada Customers, Suppliers etc. See screenshot below on how the Customer Form displays the new ‘Canada’ address style:



Click on the Address filed and you will get a popup window with the new ‘Canada’ address style:

Lockbox Reconciliation Extension

Client Industry – Applicable to all clients implementing/ implemented AR Auto Lockbox

Business Case – Client wants to be able to handle lockbox reconciliation advance cash receipts and receipt matching in EBS by reading from the receipt lines present in the electronic version of the bank statements received from the bank. Client needs an automated way to match the detailed lockbox receipts in the Oracle A/R module to the summary level deposit information processed through the BAI2 file in the Oracle Cash Management module

Solution – A custom auto lockbox reconcile extension was developed which will match the detailed lockbox receipts in the Oracle A/R module to the summary level deposit information processed through the BAI2 file in the Oracle Cash Management module. The Cash Management module matches the receipt transaction in the A/R module to the BAI2 bank statement file and creates an appropriate accounting entry in General Ledger when the amounts are different.

An additional custom form developed will store all the accounting reference into the GL Account code column for discount, charge back, bank charges item types for both lockbox and credit / debit card settlements. The Custom Lockbox Reconciliation program will derive the account and create an accounting entry in General Ledger to reconcile the receipt.

Detailed Approach - When BAI2 files are received from the Bank they are processed in the Cash Management module. The Custom Lockbox Reconciliation will match the sum of all the receipt amount for the AR receipts batch in (AR_Cash_Receipts) with the net amount received in the Bank.

On a daily basis, the lockbox reconciliation extension will process and check the bank statement transaction details and match based on the unique identifiers with receipts in Receivables, it will create an accounting in GL for difference amount of receipt from bank deposit and accounting entries for any charge.