In this Document
Purpose
Scope and Application
How to Generate the COGS Account from the Order Type
References
Applies to:
Oracle Order Management – Version: 11.5.1 to 12.0.6 – Release: 11.5 to 12.0
Information in this document applies to any platform.
FORM:OEXDTTYP.FMB – Define Transaction Types
Checked for relevance on 26-Nov-2010
Purpose
In order to generate the COGS account from the Cost of Goods Sold account assigned to the
order type (A.K.A. OM Transaction Type) of the order, the seeded COGS workflow needs to be
modified to change the default node from Get CCID for a line to Get CCID from the Order Type
ID. This bulletin will detail the required changes to accomplish this.
Scope and Application
Familiarity with Workflow and Workflow Builder is required.
How to Generate the COGS Account from the Order Type
Background:
The COGS Account Generator is a Workflow Process that derives the Cost of Goods Sold
account for a transaction interfaced to Inventory from Order Management/Shipping. The
workflow item type ‘OM: Generate Cost of Goods Sold Account’ which has an internal name of
OECOGS encompasses all processes designed to build the COGS. The ‘Generate Default
Account’ is a seeded process which builds the COGS Account. It comes seeded with the function
Get CCID (account ID) for a line. This function will return the CCID assigned to an item as it
exists in the shipping warehouse. The intent of this function is to retrieve the CCID from the
Cost of Goods Sold assigned to the item on the sales order line within the shipping
inventory organization.
Modifying the ‘Generate Default Account’ to derive the Cost of Goods Sold account from
the Order Type:
1. The first step is to copy the existing ‘OM: Generate Default Account’ process. Give it a new
name, e.g. ‘NEW_DEFAULT_ACCOUNT_GENERATOR’, in the property sheet Internal Name
field. Please do not simply modify the existing default process.
2. Double-click on the new process from within the Navigator and continue by deleting the link
between the ‘Start generating Code Combination’ and the ‘Get CCID for a line’ function. Insert
between them the function ‘Get CCID from the Order Type’ by dragging it from the Navigator to
the process screen. Using the right mouse button, draw a line connecting the ‘Start generating
Code Combination’ to the ‘Get CCID from the Order Type’ function. Save this process
definition off to the database.
Point the Chart of Accounts to the new process:
Saving new Workflow Process Definitions to the database is all well and good, but it is of no
benefit unless the Chart of Accounts structure can invoke it. The relationship between the Chart
of Accounts structure and the Workflow Process for the ‘OM: Generate Cost of Good Sold’ item
type is made in the ‘Account Generator Processes’ form (OM: Setup > Financials > Flexfields >
Key > Accounts). Using the flashlight icon choose the applicable Chart of Accounts. Then assign
the new process to the ‘Generate Cost of Goods Sold Account’ Item Type.
Ensure that the new Account Generator points to the correct Chart of Accounts:
Care must be taken to ensure that the new Account Generator points to the correct Chart of
Accounts. To determine the correct Chart of accounts, follow the steps below:
1. Get the value of the Set of Books for the inventory organization for which you wish to
interface the transactions. Get this from the Organization Definitions form. (Inv: Setup >
Organization > Organizations). Query the name of the inventory organization desired, then with
the cursor on the ‘Inventory Organization’ organization classification, click the ‘Others’ button.
Choose ‘Accounting Information’.
2. Determine the Set of Books for the Order Management responsibility for which the order is
assigned. Accomplish this task in the same way as with the inventory organization as
demonstrated above, except place the cursor on the ‘Operating Unit’ line rather than the
‘Inventory Organization’ line. Choose Operating Unit Information.
3. Query this Set of Books up in the Define Set of Books form (Setup > Financials > Books).
Record the value for the ‘Chart of Accounts’.
4. Finally, find the workflow process this chart of accounts uses when building the COGS
account from the Account Generator Processes form (Setup > Financials > Flexfields > Key >
Accounts).
R12 Deferred COGS: New Process for Cost of Goods Sold [ID 567261.1]
In summary :
1. If the SELLING_OU = SHIPPING_OU, during an ‘SO Issue’ transaction always
the deferred COGS would be used and the COGS account would get reflected only
when the actual revenue recognition has happened, till then only the
temporary deferred COGS would hold the cost.
2. If the SELLING_OU <> SHIPPING_OU, during an ‘SO Issue’ transaction
Intercompany flows would come into picture and if a flow exists it would also
check if ‘Advanced Accounting’ is enabled. If ‘Advanced Accounting’ is not
enabled then COGS account would get costed, else Deferred COGS account would
get costed.
See Metalink
Note 416678.1 R12 : Deferred COGS Account[ID 416678.1]- for further details
below
R12 : Deferred COGS Accounting
Applies to:
Oracle Cost Management – Version: 12.0.0 to 12.1 – Release: 12 to 12.1
Information in this document applies to any platform.
Purpose
The purpose of the Bulletin is to make the reader aware of the new enhancement of the Deferred
COGS account.The enhancement is applicable for Release 12 onwards.
Scope and Application
The bulletin is applicable to Release 12 onwards. The reader is assumed to understand the
accounting in the 11i release.
R12 : Deferred COGS Accounting
Introduction :
The deferred COGS of goods account is the new feature introduced in Release 12. The basic
fundamental behind the enhancement is that the COGS is now directly matched to the Revenue.
The same was not possible till now.
Prior to this enhancement, the value of goods shipped from inventory were expensed to COGS
upon ship confirm, despite the fact that revenue may not yet have been earned on that shipment.
With this enhancement, the value of goods shipped from inventory will be put in a Deferred
COGS account. As percentages of Revenue are recognized, a matching percentage of the value
of goods shipped from inventory will be moved from the Deferred COGS account to the COGS
account, thus synchronizing the recognition of revenue and COGS in accordance with the
recommendations of generally accepted accounting principles.
The Matching Principle is a fundamental accounting directive that mandates that revenue and its
associated cost of goods sold must be recognized in the same accounting period. This
enhancement will automate the matching of Cost of Goods Sold (COGS) for a sales order line to
the revenue that is billed for that sales order line.
The deferral of COGS applies to sales orders of both non-configurable and configurable items
(Pick-To-Order and Assemble-To-Order). It applies to sales orders from the customer facing
operating units in the case of drop shipments when the new accounting flow introduced in
11.5.10 is used. And finally, it also applies to RMAs that references a sales order whose COGS
was deferred. Such RMAs will be accounted using the original sales order cost in such a way that
it will maintain the latest known COGS recognition percentage. If RMAs are tied to a sales
order, RMAs will be accounted for such that the distribution of credits between deferred COGS
and actual COGS will maintain the existing proportion that Costing is aware of. If RMAs are not
tied to a sales order, there isno deferred COGS.
SETUP and ACCOUNTING :
To set the deferred COGS account.
Inventory — Setup — Organization — Parameters — Other Accounts
A new account is added which is referred as the Deferred COGS accounts.
Please note that when upgrading from a pre R12 version the DEFERRED_COGS_ACCOUNT
will be populated if it is null with the cost_of_goods_sold_account on the organization
parameter. This can then be changed accordingly if a different account is required.
NEW ACCOUNTING :
Release 12 :
When a Sales order is shipped the following accounting takes place:
Inventory Valuation Account : Credit.
Deferred COGS account : Debit
Once the revenue is recognised, you would need to decide the percentage you wish to recognize
the Revenue. A COGS recognition transaction will be created to reflect a change in the revenue
recognition percentage for a sales order line.
The steps to generate such transactions are as follows:
1. Run the Collect Revenue Recognition Information program. This program will collect the
change in revenue recognition percentage based on AR events within the user specified date
range.
2. Run the Generate COGS Recognition Events. This program will create the COGS recognition
transaction for each sales order line where there is a mismatch between the latest revenue
recognition percentage and the current COGS recognition percentage.
Note that users can choose how often they want to create the COGS Recognition Events.
Navigation to run the COGS recognition request :
– Cost > COGS Recognition > Collect Revenue Recognition Information
– Cost > COGS Recognition > Generate COGS Recognition Events
– Cost > View Transactions > Material Transactions
The distribution for the COGS Recognition transaction associated with the Sales Order
transaction now would be as follows:
Deferred COGS : Debit revenue percentage
COGS : Credit (Actual revenue percentage )
Thus, essentially the recognized COGS balance is to move the value from Deferred COGS to COGS.
This particular COGS recognition transaction actually correspond to a revenue recognition
percentage change.
You can view the transactions as :
Navigation:
– Cost > View Transactions > Material Transactions > Distributions
A new COGS Revenue Matching Report shows the revenue and COGS information of sales
order that fall within the user specified date range by sales order line
SIMPLER TERMS ( Table level details ) :
Once the whole cycle is complete we will have 2 transactions lines in mtl_material_transactions.
1. Sales Order
2. COGS Recognition transaction
Accounting will be in mtl_transaction_accounts and the Subledger accounting tables as follows:
Transaction 1:
Inventory Valuation Account : Credit. (item_cost)
Deferred COGS account : Debit (item_cost)
Transaction 2:
Deferred COGS : Credit (Actual revenue percentage)
COGS : Debit (Actual revenue percentage )
3. R12: COGS To Recognize Cost By Item Types [ID 558044.1]
Solution
Applies to:
Oracle Order Management – Version: 12.0.4 and later [Release: 12.0 and later ]
Information in this document applies to any platform.
*** Checked for relevance on 02-Sept-2010 ***
Goal
How to debit the correct account from R12 COGS workflow to recognize cost by Item Types. In
viewing the Material Distributions, there is no COGS entry for a specific transaction.
Solution
When the shipment transaction is costed, it will not debit COGS account directly. It will debit the
deferred COGS account defined at the organization parameter form. The user needs to run a
series of concurrent programs to match revenue and COGS and transfer from deferred COGS
account to true COGS account.
If using OPM, in the MTL_MATERIAL_TRANSACTIONS table, if
SO_ISSUE_ACCOUNT_TYPE is ‘NULL’, this indicates that the Sales Order line is not setup for
deferred revenue recognition.
Please check if the Sales Orders that are being created are set for deferred revenue recognition
or not. MTL_MATERIAL_TRANSACTIONS.SO_ISSUE_ACCOUNT_TYPE should be ‘2’ if
the Sales Order line is set for deferred revenue recognition.
There is a bug already reported where the COGS recognition event is not recognized for normal
sales order lines (which are NOT set for deferred revenue recognition).
Check version of the following file—
$GMF_TOP/src/common/gmfxoupd.lc
If using OPM, go to OPM_financials and run the 3 steps for COGS recognition.
Run the Create Accounting process in order to generate the Order Management trx accounts.
Verify the Postings in Create Accounting Report/ Detailed Subledger Report for the COGS
journal
line type for the transaction.
The R12 Cost Management Users Guide, available online through Metalink, notes the
following —
Run a set of concurrent processes to record Sales Order and revenue recognition transactions and
to create and cost COGS recognition transactions. These COGS recognition transactions adjust
deferred and earned COGS in an amount that synchronizes the % of earned COGS to earned
revenue on Sales Order shipment lines.
1. Record Order Management Transactions: records new sales order transaction activity such as
shipments and RMA returns in Oracle Order Management.
2. Collect Revenue Recognition Information: determines the percentage of recognized or earned
revenue related to invoiced sales order shipment lines in Oracle Receivables.
3. Generate COGS Recognition Events: creates and costs COGS recognition events for new sales
order shipments/returns and changes in revenue recognition and credits for invoiced sales order
shipment lines.
The matching and synchronization of the earned and deferred components of sales order revenue
and
COGS is accomplished by running the following COGS recognition concurrent processes at
user-defined intervals:
• Record Order Management Transactions
• Collect Revenue Recognition Information
• Generate COGS Recognition Events.
Recent Comments