Oracle Business Applications

Further to this post on this error. Here is another reason why this error occurs. If you happened to use the seeded accounting rule called Immediate in your transaction (be it in Service Contract or Sales Order) you need to make sure that the period type used in ledger or set of books matches to the Period type used in Immediate accounting rule.

As you can see below, Immediate accounting rule comes with period type called Month (this cannot be changed). Say in your implementation you do not use Month as your period type but something else like 4-4-5 or Monthly.  In that case, if you bill a contract or invoice an order line with Immediate accounting rule, you are bound to get this error when you run autoinvoice import.

To get around this, you need to define your own accounting rule with your period type that matches to your ledger. When use that accounting rule, phew, that error goes away.

Recently had a situation. An order was shipped with two lines at zero price and one line at some price. This order’s invoice was eligible for a revenue contingency which dictates that the the revenue will be recognized only upon customer pays. As a result of which all the lines are waiting in the Deferred or Unearned revenue bucket till the customer paid.

Eventually customer paid the invoice but two lines which are at zero price in the invoice never got out of unearned revenue (one line which has price did get recognized for revenue). What is the issue here? Issue is not as much as with Revenue but with COGS. Since COGS recognition depends on the revenue recognition it never got recognized since there was no revenue. As a result, cost of this order line continues to be in Deferred COGS (No revenue, No COGS and Deferred Revenue equals Deferred COGS and that makes sense). But we need COGS to be recognized.

But why is the revenue not getting recognized for the lines with Zero price? It is not that hard to guess. Revenue Adjustment can take place only if there is some value to the invoice line (R12.0.6 base). Eventually ended up getting a patch 7454302. Looks like this may solve the issue!

It is weird to see why I cannot unapply a credit memo that I created by crediting the invoice. But I can do so if I create on-account credit first and then apply that to an invoice of your choice.

Case1:

1. Pull up an invoice in AR
2. Credit the invoice from actions and complete it.
3. Now query up the credit memo
4. From Actions try looking at Applications where we usually unapply the invoice.
5. Applications option is disabled hence I cannot unapply the invoice from Credit Memo.

Case2:

1. Create an invoice and complete it
2. Create a credit memo and complete it
3. While you are still in credit memo choose actions–>applications
4. Apply the invoice you have created in the first step and save
5. From the same credit memo you can now navigate to applications and unapply the invoice.

What is the argument here?

1. Is tax calculation is driven off of the original invoice’s tax amount? Does not hold good as I have not see that. Probably configurable.
2. Is accounting driven off of the original invoice? With SLA this is pretty much useless unless you are using standard accounting. I will be a little surprised with that if anyone still using standard accounting after SLA is in place.

Or anything that I am missing that some of you can enlighten me.

Common wisdom is that transaction numbers in AR are decided by the batch source. But what if you wanted to have numbering specific to transaction type of these transactions that use the same batch source (invoice should have one sequence number and Credit Memos should have different sequences and so on)? Also some users of Oracle AR in different countries need to follow the sequence numbers specific to periods (every year or every month I want follow different sequence numbering). Well, here is the presentation that gives you simple steps to achieve the same. Hope this is useful.

Every country has its own address style. For example in Ireland there is no need for the maintaining the postal code but at the same time it is required if the country is UK. So when you maintaining the customers and suppliers in a global instance we need to have that flexibility to maintain addresses in that country’s address format. This is not new but is there from, as far as I remember, 10.7 GUI. This is achieved by a feature called Flexible Address Format.

There are simply three steps to it:

1. Create country specific address format.
2. Add this style to the lookup
3. Assign this style to the country that is needs this style.

The first step is nothing but creating a context in a descriptive flexfield called Address. This is under application Receivables. Query up that DFF add your ISO country code as the context. And then add necessary segments as per your needs under that context. You can make fields as required or not while defining your segments, which is a standard feature.

In the next step, you need to add this address style (context) as a lookup code in a lookup type called ADDRESS_STYLE. Unfortunately this is not available under receivables lookups with in receivables manager responsibility. You have to access this in Application Developer–>Application–>Lookups–>Application Object Library. Query the above mentioned lookup type and add the lookup code as your ISO country code (which is same as your context).

In the third step we assign this address style to the country of your choice. The reason we did the second step is to accomplish this third step. For some reason the LOV of address style in this step is from the lookup codes and not directly from the contexts of the DFF Address that we used in the first step.

Once you assign your address style to the country code of your choice, the address segments will show up the way you have defined under that country context in the DFF.

A good part of SLA functionality is deriving correct account based on business rules. This functionality is called defining account derivation rules. The outcome of accounting derivation rule sometimes is an entire account (famously known as code combination) or simply a segment in the code combination. If only a segment is derived then each of the segment in the chart of accounts is weaved together just like the way it is done in workflow account generator. Take for example revenue account. Oracle gives us a default account from the transaction in AR which is generated using Auto Accounting. What we can do is, take that account and plant a specific segment, say, natural account under specific condition. Also the whole account can be replaced with a new one under specific conditions.

The difference between workflow account generator and SLA accounting derivation rules is that, the conditions under which the account or a segment derived reside in code in first one but are visible to the business users in later one. They understand the conditions under which an account is derived because it is configured in the screens and not sitting some cryptic code. Also little room for bugs, so to speak.

Usually we generate the account for either credit or debit line of a journal entry. An accounting entry, at a minimum, has a debit and credit. These are called are journal lines (a debit line and a credit line). An accounting derivation rule is for a specific journal line. Going a little further this journal entry is for a transaction. This transaction event is called event class. These two make up the heart of SLA setups.

Taking the same example of revenue account, revenue account is a journal line. Revenue is one side or one line in an accounting entry. The other usually is a receivables account (in case of AR transaction). These two together make a journal entry. And this journal entry belongs to an event class called Invoice (in case it is invoice).But if you have observed the line definitions under invoice event class you might have noticed way more than these two lines. That is because each of them is used in different ways depending on the nature of transaction.

Implementation: What is in it? What kind of work is involved?

Traditionally we have accounting in each application or a process flow is taken care of by individual specialist in that area. For example an AR specialist used to get the accounting needs implemented as per the requirement and cost management or order management specialist gets the cost accounting right. So a business process owner for accounting has to run around each of these specialists to get the accounting taken care of. Also prior to SLA the functionality provided in Oracle is rigid in some application areas and very flexible in a number of other areas. To cater to these flexible needs a number of tools were also available like Workflow account generators, Post or Pre hooks or some setups to generate accounting based on business rules.

SLA is a game changer from that perspective. We can throw away workflow accounting generator and post or pre-hooks coding. And also one specialist, who understands enterprise accounting and business needs of accounting department, can implement complete SLA solution in all applications and processes. This is new and emerging consulting role.

Implementing SLA involves writing rules to arrive at accurate accounting under specific conditions for a specific transaction event. To achieve what you need, we may need to write some coding in custom sources but in general that is far simpler than workflow. All you need to know if writing simple pl/sql code.

But for a SLA specialist the challenge is in understanding transactions and event class is mapping to these transactions. Sometimes it is self explanatory. An event class like Sales Order issue in Cost Management or Invoice in AR tells you that these are for COGS and Revenue respectively. But not all are so straight forward. But if you have knowledge about the transactions performed in each application areas and some technical background it is pretty easy to get there.

Apart from generating accounts there are a lot of other features in SLA. We will explore them in further posts.

We all know SLA is rule driven to derive accounts for create accounting process. If you are not using standard (seeded) accounting rules, but have created a new one with a new application accounting method for a specific application, how create accounting program uses these rules to derive correct accounting?

We talked about SLA earlier here. If you follow the earlier article, we are talking about using application accounting method (custom) to derive an account for a specific journal line type (debit or credit). To achieve custom accounting you assign this accounting derivation rule to this journal line type. These journal line types roll into event classes (invoices or deposits) and entities (AR transactions) to form Application Specific Accounting Method. This accounting method is assigned to an application of interest where this desired accounting is expected. This accounting method has to be validated (Validation Program) for this to be used.

This validation process actually creates a database package where all these rules are coded and maintained. To identify the package you can use this simple script which gives you the package name. Parameters to this package have to be sourced from the table XLA_PRODUCT_RULES_B. This tables stores the application accounting definitions that we talked about earlier. For example you want to get the custom application accounting method you have created for Receivables, you can simply use this SQL to get that.

Pass the values from the above SQL to this simple function get that package. If you want to see standard rules, change product rule type code from C to S. If you have more than one product rule code (application accounting method), you should know which one you are looking for. If you open this database package your technical eyes can see what is happening in create accounting program.

select application_id,
product_rule_code,
product_rule_type_code,product_rule_hash_id from xla_product_rules_b
where application_id=222 –Receivables
and product_rule_type_code=’C';

DECLARE
c_package_name CONSTANT VARCHAR2 (30) := ‘XLA_$id1$_AAD_$id2$_$id3$_PKG’;
l_package_name VARCHAR2 (1000);

FUNCTION getpackagename (
p_application_id IN NUMBER,
p_product_rule_type_code IN VARCHAR2,
p_product_rule_hash_id IN NUMBER
)
RETURN VARCHAR2
IS
l_name VARCHAR2 (30);
l_hashapplication VARCHAR2 (30);
l_hashrulecode VARCHAR2 (30);
l_log_module VARCHAR2 (240);

BEGIN
l_hashapplication := LPAD (SUBSTR (TO_CHAR (ABS (p_application_id)), 1, 5), 5, ’0′);
l_hashrulecode := LPAD (SUBSTR (TO_CHAR (p_product_rule_hash_id), 1, 6), 6, ’0′);
l_name := c_package_name;
l_name := REPLACE (l_name, ‘$id1$’, l_hashapplication);
l_name := REPLACE (l_name, ‘$id2$’, p_product_rule_type_code);
l_name := REPLACE (l_name, ‘$id3$’, l_hashrulecode);
RETURN l_name;
EXCEPTION
WHEN OTHERS
THEN
NULL;
END getpackagename;
BEGIN
l_package_name :=
getpackagename (p_application_id => 222,–application ID
p_product_rule_type_code => ‘C’, –Rule type
p_product_rule_hash_id => 18 –Hash value
);
DBMS_OUTPUT.put_line (l_package_name);
END;

One of many cool features in SLA is creating manual journal entries. Many times we have a need to pass manual entries to reverse the entries happened a source transaction because the account is wrong or date is wrong or even the value is wrong. All sub ledgers give you a way to reverse the transaction and hence reverse the associated accounting entry. But sometimes you may run out of time and luck and resort to manual entries in GL. Once we are GL to enter manual entries for transactions that pertain to sub ledger, we lose an opportunity to reconcile as we do not have primary references for which we have created this accounting entry for. If we have any reports that are based on SLA tables the reconciliation becomes harder as we cannot link anything that happened in the GL with the SLA. After all, the purpose of SLA is to eliminate this risk of reconciliation with GL.

Also, I guess, Oracle Support uses this route (manual journal entries) to fix any entries that were corrupted in the original transaction.

While entering these manual entries we can capture original transaction attributes using supporting references feature where you can capture attributes like asset_id if it is Assets related entry, transaction_id if it is related to Inventory, invoice_Id for AP and customer_trx_id or cash_receipt_id if it is AR invoice or cash respectively, These give meaning to the manual journal entries.

Process comes in three steps: Creating entries, saving them as incomplete entries with in SLA to be posted later and finally completing this so that this will automatically transfer to GL, journal Import and Post them as needed. To create manual entries you need to assign a sub-function SLA: Create Subledger Journal Entry to the menu. It will appear as a button in the view journal entries page.

The same can be achieved with an API XLA_JOURNAL_ENTRIES_PUB_PKG. Also this is immensely useful if you want to create accounting entries related to transactions in legacy or related systems. You can capture the supporting references related to the related system for reconciliation purpose.

The best part of using this API is that, we do not have to separately code for Journal Import and Posting (with complete journals parameter to complete, transfer and post). The value you pass to this parameter takes care of that.

Sources:Oracle Financial Accounting Hub Implementation Guide (Chapter 12 on Manual Sub ledger Journal Entries API) and Oracle Subledger Accounting Implementation Guide (Chapter 6 Sub ledger Journal Entries).

There are at least 40 search hits on this blog for this error:

“Please define all periods in which revenue is to be recognized or credited. Note that revenue cannot be recognized or credited in closed and close pending periods.”

Just thought throw some light on why this error occurs. This error is defined in Receivables (AR) and here is the background.

We all know about accounting rules accounting rule duration in AR. Accounting rule tells the system how to recognize the revenue (Variable vs. Fixed) and whether it is deferred or not. On the other hand accounting rule duration (in fixed case we define this in Rule and in case of variable we enter this in transaction) decides how many periods into the future the revenue recognition should happen starting from the rule start date (which usually is transaction date).

The key word here is “future”. For example, if you enter 36 as duration (either fixed or variable), Revenue Recognition process tries to create that many distributions with “future” GL date (36 periods, assuming that the accounting rule is not defined as Deferred). But what if that many number of periods are not even defined in the accounting calendar associated with Ledger or Set of Books? That is where this error comes up.

When you get this error, this simply means that all the periods (number of periods in duration) from the accounting rule start date should be defined in accounting calendar (not required to open or future status). Just define that many number of periods in calendar and this error goes away.

Prepayments in business are not unusual. In Payables, we prepay employees for their expenses ahead of their trip; we prepay suppliers in advance for the goods to be delivered in future. The same can happen with your customers as well. You customers would like to prepay (commitments) in advance for the goods to be delivered in future. These commitments can be against

·         Pricing agreements that they have contractually agreed for a specific product

·         Only for a specific product without any pricing agreement

·         Or just a commitment in general which can be used against any purchase without any agreement

This article focuses on how these commitments and pricing agreements are used in sales orders and AR transactions. Also it discusses what happens to the customer balances and accounting when this sales order line is invoiced.

We all know the order to cash process. We

·         Enter an Order

·         Ship that order

·         Invoice that order

·         Collect and apply cash against that invoice

But just reverse the cycle where you will see

·         Receive cash from customer in advance

·         Create deposit transaction and apply that cash receipt against the deposit

·         Enter and ship an order. While doing so you specify which deposit transaction (commitment) you are shipping goods against.

·         Invoice the order

·         Invoice balance gets adjusted and applying the prior commitment (invoice adjustment).

Commitments in are created in AR in the form of transactions. Commitments can be of two types: Deposits and Guarantees. User guide defines these two transactions as follows:

Deposits: Customer’s prepayment for goods or services that you will provide in the future.

Guarantees: Contractual agreement with your customer to conduct business over a specified period of time.

Technically there is no difference, but business process wise these two transaction types help identify the transaction in a different perspective. While creating these commitments, you can refer to a pricing agreement created for this customer in OM. This will help qualify when you are referring to commitment in order line.

If a customer pays $10,000 in advance, you get a check without any invoice reference. It can come through the lock box as well. Based on this you create a deposit and apply this check to it making the balance in deposit to zero. Now you have commitment.

Next step is to enter a sales order. While entering the sales order line, you can choose the commitment you just created in AR in the LOV in the commitment field (available in order lines).You ship the goods and invoice the customer for the same. When you run auto-invoice import for the same you will see that Prepayment Matching program automatically kicks off. What this program does is to apply an adjustment to this invoice to the extent of the deposited amount. By doing so this invoice balance is reduced. So now you have

·         Deposit

·         Cash receipt

·         Invoice for sales order

·         Adjustment to reduce the balance on this invoice

Each one of them has accounting as follows. You can follow serial number logic to identify which account is getting cleared in which transaction.

When cash receipt is created:

When Deposit created:

When cash receipt is applied against this deposit:

When order line is invoiced:

At the time invoicing since customer has already paid for these goods, an adjustment is created making this invoice balance to zero

The net entry at the end of all these transactions is:

There are a lot business process steps that need to be filled in (communication of cash receipt and creation of commitment so on) and some automation is possible to create transactions.

 Let me know your views on this process.

A reader asked a question on how to convert the invoices from the legacy system that are already paid by the customer but have deferred (unearned revenue) to be recognized in Oracle after conversion. Thought it makes sense write a post on this topic as the topic has enough to cover.

Basically here is the scenario. Say you have sold service or subscription for entire year in advance. Example is the yearly subscription price I pay in advance for my HBR copy. I pay about 144 USD in advance. What HBR does with this advance payment I make? Basically they had an invoice created on my name for that amount. But since the magazine needs to be delivered 12 months into the future, they have to recognize the revenue appropriately every month for each issue that is delivered. They cannot recognize the revenue in one month for all the144 USD. But I have already paid for it so they apply cash to this invoice thus bringing down the receivables to zero.

Imagine if HBSP was using a legacy system when I was a subscriber and would like to move to Oracle in the middle of my subscription. My subscription is from Jan-09 to Jan-10 and if they are migrating in Aug-09, how will this invoice converted?

In general this invoice is not considered as open because I have already paid for it (usually we convert open invoices only). So the invoice that is converted should have zero outstanding balance but outstanding revenue or in other words deferred or unearned revenue.

Why is this hard? The reason is accounting. Let us take the same example and create accounting entries for the same. In the first month when the invoice is created here is the entry.

Since the one issue of the magazine will be delivered in this month they need to recognize 12 USD in the month of Jan-09. Also mind that I am paying this invoice. Accounting entries are:

When cash is applied against the invoice:

When revenue is recognized:

And this recognition continues till August in the legacy system. In August when we convert the invoice into Oracle, how to convert this? Should we convert the entire balance of receivables and unearned revenue or only the remaining unearned revenue about should be the amount in the invoice to convert?

In general cases are:

1.     Invoice is completely paid, and unearned amount is greater than receivables amount (receivables is zero)

2.     Invoice is partially paid and remaining receivable balance is less than the remaining unearned amount.

3.     Invoice is partially paid and the open balance on the invoice is more than the unearned amount.

Two important things to keep in mind are: how much should be the invoice value in all these cases? This question is relevant because receivables balance is not the same as the original invoice amount in the legacy system. And the second question is which GL date to use? And we need an accounting rule to make this happen. As invoices in the legacy can have different number of periods to recognize revenue, we define this rule as Variable type? As we schedule the revenue as soon the revenue recognition is run, we do not check the deferred flag in the accounting rule.

You can convert the invoice amount as is from the legacy and then use adjustments to reduce the receivables balance to appropriate number(zero or partial).  As for the revenue use the rule start date as the equal to the transaction date (as it is in the source). If you keep only current period open gl date will be current for all the past revenue (when revenue recognition is run) and future date for the future periods as per the schedule till the end of it. The future revenue will be recognized on that appropriate date.

But again this falls into bigger picture of your migration strategy and depends on how you convert GL balances for these accounts.

This is extension to this article. In R11i all sub-ledgers by default use gl_interface to transfer the journal entries to GL.

But in R12, when SLA transfers entries to GL, it uses multi-table insert concept in Journal Import. In Multi-table concept you can create your own table dynamically using gl_journal_import_pkg.create table and use this as a mirror for gl_interface table. Then you insert this table name into gl_interface_control against the interface_run_id and group_id. When you submit Journal Import it looks at this table for rows to import rather than gl_interface table. You can find more information on the multi-table insert for journal import in General Ledger User guide.

So the idea of updating the gl_interface table discussed in this article in journal import does not work, as this table is not used at all. We need to slightly modify the script to update the dynamic table in order to effectively use the gl_import_hook_pkg in order to achieve the objective.

Here is the requirement. We need to update the journal header name for journals coming from AP. The standard way of naming the journal headers is concatenation of reference4, user_je_category_name and currency_code. This should be changed to something else to append time stamp to it. So there are two options: get the rows into gl_interface and have a custom program to update the reference4 to our choice or use gl_import_hook_pkg.

All we need to do in the first option is to set the profile SLA: Disable Journal Import to Yes. This will not submit the journal import program when running create accounting program. All it does is to insert records into the gl_interface table. Then you can have a custom program to update what you need to and then run Journal Import program.

The second option is dynamic which uses gl_import_hook_pkg. Here you set the profile value for SLA: Disable Journal Import as No (this is standard). As this process does not use gl_interface table, we have to update the dynamic table used in this process. Here is the script for the same. Modified gl_import_hook_pkg is here.

Have you ever needed something to be done after GL transfer from sources like Receivables, Payables or Inventory and before Journal Import is run? There are couple questions on the forums on this topic. Take a look at this one and also this requirement. While the first requirement is to do something before journal import is run and the second one is after before GL posting is done.

Usually we resort to solutions like creating a new program and sandwiching that program between GL transfer and Journal Import program. It works, but again, we need run the Gl interface program setting the value for the parameter Journal Import as ‘No’. This approach has inherent issues. What should we do if the custom program fails? Should we let the journal import run?  If it runs, the objective is failed. On the other hand if you want to stop the journal import from picking the rows, you need to manage the status in the interface table (one way of doing it). This gets complicated as you need to manage all the rows that go in as pair of accounting entries. On top of it the issue gets complicated based on summary posting versus detail posting. So let the journal import manage the business of balancing of accounting entries and let us do our part of managing the rows in the gl_interface table the way we want it.

So this post is to address the first one where the requirement is to update one of the references in gl_interface with the comments from the Miscellaneous Cash Receipts coming from Receivables. This update will happen after your transfer to GL from Receivables and before Journal Import is run. I can understand why this is a common requirement. Usually people who use GL as well as auditors require reasons why the miscellaneous cash was posted. Updating these reference columns makes those comments visible in journal entries screen. Just to warn you, this works only if you transfer from source in Detail and not in Summary mode. See the images of miscellaneous cash receipt and journal entries screen.

This is just an example on one use of this package. It can be used for any of your needs either be pre or post journal import program. You can take the sample code here and modified gl_import_hook_pkg here. Just make sure to compile only package body given in the gl_import_hook_pkg.

We all know Order to Cash process. We are also aware of RMA to credit process. But now you can extend that process further to refund the customer.

• The process steps are:
• Customer orders a product
• Product is shipped and invoice is sent.
• This invoice is paid by the customer
• Now customer finds an issue with the product and would like to return.
• RMA is created and product is returned (order or invoice can be referenced in RMA).
• Now customer can ask for Refund for the return or he can tell us to keep the money as on-account credit.

Up until recently the only option we had was creating on-account credit for RMAs and manage the process from there. But isn’t it nice to have an option where you can decide to keep it on-account or refund based on customer’s request? Yes the wish is granted. Now you can manage this process completely with standard functionality starting R12 (probably in 11.5.10 as well with a patch or it is already there in that version). Please take a look at the presentation (you can view in full screen is the screens are not visible).

You can either automate this process by with setup at batch source level in AR setup or you can manually perform refund transaction this using applications screen using Refund receivables activity. Refund is a sedeed recevables activity.

In 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.

Just to recap, if you have 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).