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.

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.

Oracle Apps Marketing for Upgrade projects - A small tip

It has been my observation that a lot of time and effort goes waste knocking the wrong door for Oracle Apps project. Then the question arises, how to know which door to knock. Obviously, one should not waste precious resources uselessly pursuing organizations that are running on a fully supported version of Oracle Apps like R12, 11.5.10, 11.5.9, unless the organization comes to you with a view to upgrade to R12 or 11.5.10. Please refer chart below to find the support time lines for different releases of Oracle E- Business suite and plan accordingly which organizations to target and whom to avoid.