You are on page 1of 9

R12 Autoinvoice Import And Revenue Contingencies

: Receivables Tags: ar_deferred_lines_all, ar_line_conts_all, R12


Autoinvoice, ra_interface_lines_all, Revenue contingencies, revenue policy, revenue
recognition Nagamohan @ 1:44 pm continuation with the Revenue Management discussion (earlier
article is here), here I am discussing the role of revenue contingencies in importing invoices using
Auto-Invoice or ar_invoice_api_pub from external sources or partner systems.

revenue policy enabled (as seen in the screen shot here, if one of the options is enabled, it means you
have enabled revenue policy) revenue of all transactions that violate revenue policy will be
automatically deferred. This logic applies to transactions coming from legacy or partner systems also
(using either ar_invoice_api_pub or ra_interface tables). Additional qualification for this is that the
revenue management should be installed (in R12 it is always installed, though, I predict this will be a
separate product in coming releases).

Revenue policy can be violated in AR by using non-standard attributes in a transaction or creating a


transaction for a customer whose profile has credit classification which is part of the revenue policy.
There are two standard attributes: Refund or Payment Terms. If you specify 30 for Standard Payment
term it means your revenue policy is to recognize the revenue (do not defer) as long as the payment
terms are 30 or less number of days. If we use any other payment term (non-standard), it is violating
the Revenue Policy hence revenue recognition should be deferred till the removal event occurs. On the
other hand if you specify 14 days in Standard Refund, that means all the transactions that qualify for
this contingency, can have revenue recognized only after 14 days (since in 14 days customer can
reject the goods).

In addition to the revenue policy, Oracle has seeded some contingencies. Each contingency has a
deferral reason removal event attached to it. This means, only when that removal event occurs,
deferred revenue will be recognized. One example is payment of invoice is deferred removal reason for
all the invoices that have non-standard payment terms (revenue will be recognized only when the
receipt is applied). These removal events are seeded and there is no room for defining custom
removal events. But you can create your own contingency rules and assign these seeded removal
events.
So what this means for AR conversion? If the converted invoice violates the revenue policy will the
revenue be deferred? Are there any options available not to defer the revenue though the revenue
policy is violated? See this screen shot of interface lines in AR. This is what we are concentrating on.

These following simple cases are taken to test. In each case a SQL is used to insert into interface
tables and ran Autoinvoice Import program.

Case1: A non-standard payment term is used to convert invoice. Just two tables are populated :
ra_interface_lines_all and ra_interface_salescredits_all. As I have used non-standard payment term,
revenue was automatically deferred which can only be recognized when the invoice is paid. Your can
find the sql to test this case here.

Case2: A non-standard payment term is used to convert invoice. But three tables are populated:
ra_interface_lines_all, ra_interface_salescredits_all and ra_interface_distributions_all. The last table
was populated for Account class REV which is for revenue for a specific account. Result was revenue
got recognized instantly ignoring the non-standard payment term. The reason for this is this simple: if
we are passing revenue line in the distribution, we are saying that the revenue is already recognized,
hence do not defer again. Your can find the sql to test this case here.

Case3: Objective of this case was to not to defer the revenue though a non-standard payment term is
used. A non-standard payment term is used with the following tables: ra_interface_lines_all and
ra_interface_salescredits_all. In order to achieve the objective, we need to populate another column in
the ra_interface_lines_all table: deferral_exclusion_flag. Once this column is populated as Y, revenue
was not deferred. Your can find the sql to test this case here.

Case4: Finally used a contingency rule. In this case apart from populating ra_interface_lines_all,
ra_interface_salescredits_all, I populated another table ar_interface_conts_all with contingency_id 4
(which is Doubtful Collectibility), taken from ar_deferral_reasons. Revenue was deferred as expected.
Your can find the sql to test this case here.

Apart from the standard destination tables which are populated by auto invoice program
(ra_customer_trx_all, ra_customer_trx_lines_all ra_cust_trx_line_gl_dist_all and
ra_cust_trx_line_salesreps_all), if there is contingency that defers the revenue, these two additional
tables are populated : ar_deferred_lines_all and ar_cont_lines_all. Both these tables can be joined to
the ra_customer_trx_lines_all using customer_trx_line_id.

So to conclude, starting R12, we have to remember contingencies also while converting AR invoices. If
ignored, this will have some bad consequences. If you did not want to recognize the revenue because
it is already recognized in the legacy, but only receivables, we usually use dummy revenue account
while converting AR invoices. But if this gets deferred, (no revenue accounting is generated, but only
unearned revenue ) upon the removal of this contingency, revenue will be posted to the account per
the auto-accounting setup automatically which was not required.

If you do not want any revenue to be deferred when converting using autoinvoice, then you have to
ensure that:

1. There are no revenue policy violations for the invoice or do not create any revenue policy.

2. Use deferral_exclusion_flag in ra_interface_lines_all.

3. Do not use contingencies table (ar_interface_conts_all).

R12 Order Management: Revenue-COGS Matching Part I


Filed under: Order Management Tags: cst_revenue_cogs_match_lines, Deferred COGS, R12
COGS, R12 Cost Management, R12 OM, R12 Order Management, Revenue COGS Match Nagamohan
@ 12:12 am

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 account $100


Dr COGS 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 $100


Dr Deferred COGS Account $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 $100


Dr COGS Account $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 tak
R12 Revenue-COGS Matching Part II : Customer Acceptance
Filed under: Order Management Tags: Customer Acceptance, Deferred COGS, external users
acceptance, Fulfillment Acceptance, installation required, order information portal, Post Billing
Acceptance, Pre Billing Acceptance, Proof of Delivery, R12 Order Management, Revenue COGS
Match Nagamohan @ 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
contingecies, but the removal events are always seeded. So these contigencies 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, delviery 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 contigency 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.

Advertisements

You might also like