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.

This functionality is not integrated with GL in the form of journal entries yet. It just comes in the form of a report which can be run from the service request screen.

One of the limitation of this feature (as documented) is that this functionality only works with Standard Costing Method. Disappointed, I started tinkering to make this to work with average costing.  Essentially there are two issues in how the cost was sourced.
First issue is that org_id (operating unit) was passed instead of organization_id (inventory organization) to get the cost. If the operating unit is also classified as inventory org and you define cost for the item then there is no issue. But it is hardly true in real world (operating unit also classified as Inventory organization).

Second one is (not essentially a bug), costing method is not passed to the cst_cost_api to get the cost. When you do not pass this API simply assumes standard costing method. My argument is, if we know the organization to get the cost for the item, how hard it is to get the costing method and pass it to this API?

Once I fixed these two in the cs_cost_details_pvt (of course it is standard code), it simply works.

We just need to make sure to update the cost of these non-ttransactable items using average cost update process.

You can see the presentation here.

1. Miscellaneous Receipt
2. Account Alias Receipt
3. Account Receipt
4. PO Receipt into Inventory
5. PO Receipt into Projects
6. Physical Inventory (Receipts)
7. Cycle Counting (Receipts)

But there are companies that manuafacture products and they want to track them in FA. They typically get into inventory with WIP completion transaction. As you can see this transaction is not in the list above.

Recently, to my surprise, I found this patch 7489949 (which was released in 2008) that includes WIP completion also into supported transactions for asset creation. To add to my surprise, support had no clue when they were asked for solution at that time. Of course we came a long way.

BTW, it is included in base release of R12.1.1.

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!

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.