Showing posts with label Oracle Receivables. Show all posts
Showing posts with label Oracle Receivables. Show all posts

Friday, May 16, 2008

Conversion (Data Migration) of Invoices in Receivables

Whenever we are going in for implementation of Receivables module, we have to consider the necessity of bringing in customer open balances from the old system to Oracle Receivables.

Some of the key questions that needs to be addressed before we take up a conversion activity. This is just a sample list and not an exhaustive one:

1. What are the different types of invoices in existing system Provide invoice samples? (invoices, credit/ debit memos, commitments, chargebacks)

2. Do we need to migrate only open invoices?

3. Do we migrate closed invoices also, if yes, then for what time period?

4. Please explain the invoice numbering mechanism? Is it automatic?

5. What are the interfaces from/to your existing receivables system?

6. Will the old system still be in place for querying and reporting purpose?


One can adopt one of the following three strategies for conversion:

1. Consolidate all the open balances customer-wise and create a single open invoice for each customer in the new Oracle system. The advantage of this system is that it is quite easy and not data intensive and makes good business sense in case of small businesses with very few customers. The major demerit of this approach is that later on one cannot track the individual invoices which the customer had sent and can become an audit issue also. In case of dispute over payment, this invoice will remain open till the dispute is resolved. Also, aging of invoices and dunning history will be lost.

2. Bring in all the open and partially paid invoices, credit/debit memos into the new system. Migrate all the unapplied and partially applied receipts to the new system. The advantage of this process of conversion is that you can track all open invoices individually and apply the correct receipt to correct invoice. Also, the conversion effort will be moderately low compared to case if you migrate all open and closed invoices. The disadvantage of this approach is that you cannot have a track of closed invoices in the new system. Also, it would be tough to handle scenarios where there is a dispute regarding incorrect receipt application, etc. This is the most common approach taken for receivables invoice, credit/debit memo and receipt migration.

3. Migrate all open and closed invoices to the new system. Reapply the migrated receipts to invoices in the new system. This approach makes sense if your receivables data is quite small else the effort involved in migrating all closed invoices and credit memos to the new system does not make much business sense.

The next question that arises is how we should migrate the invoices, credit/debit memos and receipts to the new system. Oracle provides standard interfaces to load the same. We can also use tools like Dataloader or manually key in the data into Oracle.

In this article i will talk of invoice, credit/debit memo conversion only. Prior to invoice migration, customer migration should be over apart from other pre-requisites. Following is the list of pre-requisites that should be completed prior to invoice, credit/debit memo conversion:

•Set-up of Customer Payment Terms should be complete

•Set-up of Currencies should be complete (this is necessary in case you have foreign currency invoices also)

•Set-up of Transaction Types should be complete

•Set-up of Accounting Rules should be complete

•Set-up of Tax rates and Tax codes should be complete

•Set up for sales representative should be complete

•Set up for debtor area should be complete

•Set up for income category should be complete

•Automatic customer invoice numbering should be set to 'No'

•Customer and Customer address should be migrated in the system

•Disable the Invoice interface purge program so that the data successfully imported should not get purged in the interface table.

•Set up for invoice batch source name should be complete

In the next step extract Invoice data from the legacy files and using SQL loader populate the interface tables RA_INTERFACE_LINES_ALL and RA_INTERFACE_DISTRIBUTIONS_ALL. Submit the Auto Invoice open interface program. Data from the two interface tables will be uploaded to the following base tables using the Invoice open interface program:

•RA_CUSTOMER_TRX_ALL

•RA_CUSTOMER_TRX_LINES_ALL

•RA_CUST_TRX_LINE_GL_DIST_ALL

•RA_BATCHES_ALL

•RA_CUST_TRX_LINE_SALESREPS_ALL

•AR_RECEIVABLE_APPLICATIONS_ALL

•AR_PAYMENT_SCHEDULES_ALL

•RA_INTERFACE_ERRORS_ALL

Ensure that the Purge Interface check box is not checked when you submit the Autoinvoice program. In the Autoinvoice errors form you can see the error corresponding to failed records. Correct the errors in the interface table and rerun the Autoinvoice program. Submit the Autoinvoice Purge Program separately. Only records that have been successfully processed by Autoinvoice are purged.

Using autoinvoice you can migrate invoices, credit/debit memos and on-account credits into Oracle. However, you have to set grouping rules (Navigation > Setup > Transactions > Autoinvoice > Grouping Rule) to group lines to create one transaction and ordering rules (Navigation > Setup > Transactions > Autoinvoice > Line Ordering Rules) to determine the order of the transaction lines on a particular invoice.

Sunday, April 20, 2008

Business case - Customer on Credit Hold

Business Scenario:
There is a requirement to put all open orders in Order Management on Hold by putting a Credit Hold on customer under the following two conditions:
1. Customer exceeds the Credit limit set
2. Cutomer has not paid an invoice even after 'x' days of the invoice due date on invoice. However, this customer may not have exceeded the credit limit.

Solution:
The solution to the first scenario is to enable the Credit Check for the customer and put an amount in the Credit Limit field for the customer. Oracle Order Management would use this information to place an order on hold.
However, for the second scenario there is no standard solution. We have to create custom program to put the customer on a 'Credit Hold'.
Step1: Enable a DFF (we can name it as say 'Over Due Days') for the customer which would hold the maximum number of days the payment is overdue that is accecptable to the business.
Step2: Write a small program that would check daily for all customers where the system date is greater than the due date by the number of days specified in the DFF. A report would also be an output of the program which is something very similar to the standard report "Past Due Invoice Report" with a couple of additional fields to capture the days beyond the maximum number of days after due date as per DFF. This program would put all customer on a Credit Hold where the invoice Due date is greater than 'Due Date + No of days in DFF'.
Ensure that the program is scheduled to run just after midnight to so that the program does not miss out on any new invoices created.

Friday, April 11, 2008

Customer Refund in Receivables

There are cases when customers overpay, or pay one invoice twice. In all such cases the customer is due for a refund. The easiest approach would be to ask the customer to absorb the overpayment if the amount is small. However, if the amount is large the customer would no doubt ask for a refund. There are basically three ways to handle customer refunds:
1. Issue a manual check for refund to the customer and record a Debit Memo in Receivables and match this to the receipt.
2. Ask the customer to leave the cash as "on-account" and apply this later to any other open invoice.
3. Setup customer as supplier in Payables, and issue a check out of payables. The third option is more cumbersome but will make bank reconciliation a lot smoother. First create a debit memo in receivables, using a clearing account (the clearing account should always show zero balance). Match the receipt to this Debit Memo. Then create an invoice for this customer (set as supplier in AP), using the same clearing account as the expense account in the invoice. Pay the invoice in the normal way and do a bank reconciliation.
The above process of customer refund is only limited to 11i. In Oracle R12, Oracle Receivables is fully integrated with Oracle Payables to deliver a seamless, automated process to generate check and bank account transfer refunds for eligible receipts and credit memos.

Sunday, February 03, 2008

Sample Accounts Receivable Questionnaire

There has been a lot of requests to post sample questions for other financials modules also. Here i am posting a small sample of questions on Oracle Receivables.
1. Provide an overview of AR invoice processing.
2. Provide an overview of AR cash receipt processing.
3. How do you adjust receivables?
4. Do you receive deposits and/or prepayments?
5. Explain Customer Creation and Maintenance Process. Provide samples of customer master records with Payment Terms.
6. Do you track and record relationships between customers e.g. franchises, subsidiaries etc.?
7. Do you create reciprocal customer relationships whenever you create a relationship between customers for tracking purposes?
8. Do you have multiple "remit to’s"?How are multiple "remit to’s" determined for each customer?
9. What credit information is tracked for each customer?
10. How do you group your customers for credit limits, credit checks?
11. Do you do miscellaneous invoicing? Please explain with examples.
12. Do you send customers statements? If so please describe the process and highlight any exceptions.
13. How are the revenue, receivable, freight and tax accounts configured for each invoice type?14. Explain Debit Memo & Credit Memo Process.
15. Do you bill customers in a foreign currency?How many invoice types do you have? Provide invoice samples. (Credit Memo, Debit Memo etc.)
16. How do you number your invoices?
17. Where are the invoices printed? How many printers and where are they? Pre-printed forms?
18. How do you calculate your tax charges? What are the rates? Explain Tax Structure.
19. Do you validate the tax rate against a Customer’s Ship To address when preparing invoices? If so please describe how.
20. Do you charge finance charges? If so - how do you charge finance charges?
21. Explain your dunning and Collection Process. Please provide dunning statement formats.
22. Do collectors actively call customers on delinquent items?
23. What sort of buckets do you use for cash requirements forecasting? (i.e. 30, 60, 90...)
24. Do you write off receivable? Is there a specific dollar amount or time frame used by your Company for write-offs?
25. Do you have Chargeback? Explain.
26. Explain Revenue Recognition Process and explain the scenarious.
27. Explain Bills Receivable?
28. Do you associate Revenue to Sales Person.
29. How is Sales Territory Information for tracking purposes derived? (i.e. customer, salesperson etc.)
30. How do your customers generally pay invoices? single check—single invoice/single check—multiple invoices/multiple checks—multiple invoicesProvide list of Banks and Purpose?
31. Explain Payment Process?
32. Are you using Automatic Receipts? Explain?
33. Explain Remittance Process?
34. Explain your Auto Lock Box Proces if you have enabled it?
35. What types of payments are received and input? (i.e. check, cash etc.)
36. Explain Receipt Reconcilliation Process?
37. What reports do you currently generate for Invoicing, Sales and Revenue tracking? Provide samples including frequency and distribution.

About Me

My photo
India
Krishanu's Oracle Applications Blog - Oracle Apps consulting services scenario in India. Also, an inside view of Oracle Apps outsource services in India. Also the blog features new developments in Oracle Apps and my learning's in this field. The views expressed are my own only and not of my employer Wipro Technologies. The views and opinions expressed by visitors to this blog are theirs and do not necessarily reflect mine.