A good article on SOA and Business Productivity Creating Credit Memo in AR Using API

R12 Order Management: Revenue-COGS Matching Part I

22nd June 2008, 12:12 am by Nagamohan Uppara

It is a relief to see this much awaited functionality. We heard our accounting departments complaining about the period mismatches in for our COGS and Revenue accounting for one order. We ship an order on the last day of the month and COGS gets posted to this month, but if the invoice is created with next periods GL date as the current AR period is closed by the time the order is invoiced. Now all that is changed. Revenue-COGS matching is a standard functionality now. In simple terms, this means, COGS for an order line will be recognized only if the revenue is recognized for that line making sure that the revenue and COGS are posted in the same month. All of us have spent a lot of time working on COGS accounting workflow to achieve what we want for our clients/companies. In some cases we even customized Revenue accounting generation (avoiding auto accounting logic) by using ra_interface_distributions_all table. We had a handle on accounts generation in this process but not on the actual events of accounting recognition.

We all know this. When we ship the order and run the Interface Trip Stops program, inventory gets reduced and orders get updated to move forward in the workflow to the next activity. Interface Trip Stops program calls the OE_FLEX_COGS_PUB to generate the COGS account as per design. This gets passed on to the mtl_material_transactions table in the distribution_account column. When Cost Manager runs, distribution_account from mtl_material_transactions is picked up to generate accounting as shown.

Cr

Inventory Material Dr COGS Account $100

account

$100

The role of COGS workflow is not changed. It is still the same which generates the account of our choice per workflow design. It still passes the generated account to the mtl_material_transactions table into the distribution_account column. But what changed in R12 is accounting. In order to match Revenue with COGS accounting in terms of timing, COGS account cannot be used at the time shipping. Instead revenue recognition process of the invoice for that order line should generate COGS accounting. To achieve this, a new account called Deferred COGS account is introduced at the inventory organization parameters level. So when the order shipped instead of the above entries the entry will be Cr Inventory Material account Dr Deferred COGS Account $100 $100

When you invoice is this order line, if you have no revenue recognition policies or specialized accounting rules, revenue should be instantly recognized (upon running revenue recognition program). After revenue is recognized, the following programs need to be run to relieve deferred COGS value and debit actual COGS account. Record Order Management Transactions: This program collects all the transactions that belong to transaction types Sales order issue and Logical Sales Order Issue which are not costed and the order line is invoiceable. The source table is mtl_material_transactions. This program inserts rows into two tables: cst_cogs_events and cst_revenue_cogs_match_lines. This program is not necessary to run. When not run, Cost Manager will insert rows into these tables. So from implementation considerations, this program is not required to be run. Collect Revenue Recognition Information: This program collects invoice line information of the order line after the revenue is recognized. The source tables are ra_customer_trx_lines_all and ra_cust_trx_line_gl_dist_all. It will check the percentage of the revenue recognized (we can recognize revenue partially for a specific order line based on accounting rule or contingency rules) and inserts that information into this table: cst_revenue_recognition_lines. Also the table cst_revenue_cogs_control table is updated with the latest run date with high date of this parameter, which is used in the next run of the same program.

Generate COGS Recognition Events: The role of this program is to record a logical material transaction, which is used to create final COGS entry. This program takes information from the above tables and creates one logical

inventory transaction in mtl_material_transactions with a new transaction type called COGS Recognition. In the same program these transactions will be costed (not by the cost manager) creating the following accounting entries. The COGS account in this entry is taken from the distribution_account in mtl_material_transactions table (which was generated earlier by COGS workflow). Cr Deferred account Dr COGS Account $100 $100

This is the concept in simple terms. There are different cases (well documented in the Cost Management User Guide) in this same flow which, I will take one at a time to discuss in the coming posts.

R12 Revenue-COGS Matching Part II : Customer Acceptance

17th July 2008, 11:32 am

This is second article in the series of articles on revenue-COGS matching. As discussed in the first article, with the introduction of deferred COGS accounting, COGS accounting does not take place unless revenue is recognized so that the revenue and COGS recognition happen in the same period. In this article let us discuss customer acceptance process in relation to the revenue COGS matching. In fact introduction of deferred COGS functionality gave room for this feature. What is Customer Acceptance and how it is related to Revenue COGS matching?

Customer acceptance is a process where you cannot recognize revenue and COGS until customer has accepted the delivery. As we have discussed in the earlier article, starting R12, when goods are shipped always Deferred COGS account is debited (instead of actual COGS) irrespective of customer acceptance. As we could delay this recognition, now we can add this extra step of customer acceptance. The following is the table of revenue contingencies that are used in customer acceptance process. Of course we can create custom contingencies, but the removal events are always seeded. So these contingencies are more identified with the removal events rather than contingency name itself. These contingencies are of three types: 1. Prevent creation of invoice if the customer does not accept the goods. But as soon the customer accepts the goods, order is interfaced to AR and invoice is created and revenue is immediately recognized. This is called pre-billing acceptance. The line status is placed in Pre-Billing Acceptance status and removal event is customer acceptance and invoice creation. 2. Create invoice but do not recognize revenue until customer accepts the goods. This is called post billing acceptance. Contingencies Explicit acceptance and Installation required, fall into this category. The line status is placed in Post-Billing Acceptance status. Once the customer accepts the goods, revenue is recognized immediately (invoice is already created) and line is closed. 3. The last one is called proof of delivery. The difference between this one and other two is that, this neither can be defaulted into the order line nor can be picked up manually in the LOV when the order line is created. If the order line attributes (like bill to customer or site, AR transaction type associated with order type or line type so on) match the assignment rules set up in for the revenue contingency, delivery contingency is applied when order line is invoiced. Unfortunately at this point of time there is no user interface to record the proof of delivery. This, I am sure on the

way in the coming releases. But there is a group API that can be used to remove this contingency and the sample code for the same is here. Setup and Behavior

These contingencies can be defaulted into order line based on the setup. As shown in the associated table, value for the OM system parameter, Fulfillment Acceptace Required can be set as Yes. This allows acceptance name to be chosen from the LOV in the order lines when an order line is being created. These are hidden fields in the Others tab and folders can be used to open them up. But if contingency assignment rules are setup, say with bill to customer name parameter and value as Business World, and if the order is entered for the same customer as bill to, acceptance contingency automatically gets defaulted once the order line is saved ( this is delayed request in the order line creation and not part of the defaulting rules). The following the list of parameters that can be used to setup the assignment rules.

In Revenue Management Super User, when these contingencies are assigned to a rule with any of the parameters as shown in the table, order creation process matches the values in the order with the setup rules. If the matching is found, then the contingency is defaulted into the order line. Even if there is no setup done, contingency can be manually assigned to the order line. Finally coming to the transactions, if acceptance exists, when the order line shipped line status is placed in one of the statuses mentioned above based on the type of contingency. Acceptance can be performed by customers themselves or internally by the users. For external users to perform this step, these users should be registered against the customers (as person parties) and should be assigned with a responsibility called Order Information Super User. Once the goods have reached them, they can log in to this customer portal (iStore or iSupport) and accept or reject the goods. Also if they reject them, they can request for RMA. Rest of the process follows as discussed earlier from revenue accounting perspective. For the COGS recognition, the steps mentioned in the part I of this article should be followed.
Category: Order Management | 5 Comments