I received an email from one of the Accounts Receivable Manager that he can not find an invoice in the system that was sent out to the customer, the customer was sent an invoice and payment was received but he could not apply the payment as Invoice was missing.
I started my research and confirmed that there was an order placed, shipped, invoice missing. So how could an invoice that was sent to the customer after the order shipped go missing?
This is what was wrong….
AR System options that control Transaction change and deletion:
1. Receivable provides System options that control ability to change printed transactions and allow transaction deletion. Customers can enable these options as per their requirement. I have always recommended customers to disable these options as a means to control accidental changes or deletion.
These options were set at this site to Allow Transaction Deletion (Enabled) but not Allow change to Printed Transactions (Disabled).
2. Receivables does not allow Transaction to be deleted when it is in a COMPLETE status, normally invoices that are interfaced from another module are valid transactions (Complete). In order to delete a Transaction, the status of the transaction would need to be changed to an incomplete status. Transaction workbench provides a toggle button that can change the status of the transaction to complete or incomplete.
Transaction in an incomplete status is not a valid transaction and hence can be deleted by clicking the delete icon on the tool bar provided the system option Allow Transaction Deletion is enabled.
In order to delete a transaction the prerequisite step is to have the status changed from complete to incomplete.
How does the system keep track of whether an Transaction has been printed or not, Oracle has seeded Invoice print processes that not only perform the function of printing the transaction additionally it updates the transaction to mark the printed status, printed date, printed count.
This is how an invoice that is not yet printed looks in the table.
As the invoice is printed the invoice is updated to show that printing has completed, date printed, printing count fields are populated.
Setup and Transaction processing options implemented at the site:
1. Allow change to printed transactions – No
2. Allow transaction deletion – Yes
3. Accounting is created on transactions at Month end only.
4. Invoice(Transaction) is printed and sent to customer by a custom process and not the seeded Invoice print process.
Transaction that is entered during an accounting period and that has no activity against it has scope for change as accounting is not created until end of month. As the invoice print process was custom it was not behaving the same way as standard invoice print program, the internal print flags on the transaction were never updated. Invoice that was printed and sent to customer was still flagged in the system as not printed, because the custom process never updated the print status. This was working against the setup not to allow change to printed transactions, as none of the invoices in the system were marked as printed and that means if they were not accounted, paid, adjusted, credited the transaction could be incomplete and deleted.
In addition to using a custom invoice print process that had opened up the opportunity to allow change on transactions that were printed (assumed to be printed as the flags were not set right), the refund process followed was not right too.
Invoice that was generated as a result of an order is a financial transaction representing the sale, if the need arises to credit the customer for a reason like excess shipping charge, customer satisfaction etc. the right way would be to process a Return for Refund in the order system and process it through to AR as a credit memo. Oracle Order Management does allow for Return Orders (RMA for product returns), Refund Order (RMA for refund no product returns), so it is better to link a refund for any reason against a sale in the source system and flow it to the Finance modules. Process being followed here for refunds was different; they would change the invoice as long as the system allows it.
The AR folks would retrieve the Invoice, incomplete it and then make a change to reduce the product or shipping amount and then complete it back.
This process does achieve the desired change to the customer’s balance, but has created a financial transaction that is different from its source system and not only has that it provided scope for human errors.
The lost invoice:
Putting all the pieces together, it was concluded that somebody accidentally or intentionally deleted the transaction assuming the following actions.
· Order shipped, AR Invoice generated and sent to customer.
· AR Invoice was never flagged as printed, not accounted as it was generated during the start of the month.
· To make a change or accidentally the invoice would have been incomplete and deleted.
· Payment made by customer and no Invoice could be found
It was found that about 15 invoices were missing, that could have been accidentally incomplete and deleted. The culprit here was the custom process that did not update the print flags, ultimately it was fixed.
No comments:
Post a Comment