, , , , , ,

Oracle EBS Valuation and Other Accounts

Valuation Accounts

You choose a default valuation account when you define organization parameters. Under standard costing, these accounts are defaulted when you define subinventories and can be overridden. Under average costing, these accounts (except for Expense) are used for subinventory transactions and cannot be updated.

Material An asset account that tracks material cost. For average costing, this account holds your inventory and intransit values. Once you perform transactions, you cannot change this account.
Material Overhead An asset account that tracks material overhead cost.
Resource An asset account that tracks resource cost.
Overhead An asset account that tracks resource and outside processing overheads.
Outside processing An asset account that tracks outside processing cost.
Expense The expense account used when tracking a non-asset item.

Other Accounts

Sales The profit and loss (income statement) account that tracks the default revenue account.
Cost of Goods Sold The profit and loss (income statement) account that tracks the default cost of goods sold account.
Purchase Price Variance The variance account used to record differences between purchase order price and standard cost. This account is not used with the average cost method.
Inventory A/P Accrual The liability account that represents all inventory purchase order receipts not matched in Accounts Payable, such as the uninvoiced receipts account.
Invoice Price Variance The variance account used to record differences between purchase order price and invoice price. This account is used by Accounts Payable to record invoice price variance.
Encumbrance An expense account used to recognize the reservation of funds when a purchase order is approved.
Average Cost Variance
Under average costing with negative quantity balances, this account represents the inventory valuation error caused by issuing your inventory before your receipts.




Note: For standard costing, only the Purchase Price Variance, Inventory A/P Accrual, Invoice Price Variance, Expense, Sales and Cost of Goods Sold accounts are required. The other accounts are used as defaults to speed your set up.
Note: For average costing, only the Material, Average Cost Variance, Inventory A/P Accrual, Invoice Price Variance, Expense, Sales and Cost of Goods Sold accounts are required. The other accounts are used as defaults or are not required.

Inter-Organization Transfer Accounts

You define default inter-organization transfer accounts in the Organization Parameters window. These accounts are defaulted when you set up shipping information in the Inter-Organization Shipping Networks window.
Transfer Credit
The default general ledger account used to collect transfer charges when this organization is the shipping organization. This is usually an expense account.
Purchase Price Variance
The default general ledger account used to collect the purchase price variance for inter-organization receipts into standard cost organizations. This is usually an expense account.
Payable
The default general ledger account used as an inter-organization clearing account when this organization is the receiving organization. This is usually a liability account.
Receivable
The default general ledger account used as an inter-organization clearing account when this organization is the shipping organization. This is usually an asset account.
Intransit Inventory
The default general ledger account used to hold intransit inventory value. This is usually an asset account. For average cost organizations, this account is the default material account.

Defining Other Account Parameters

To define Receiving Account information:
1. Navigate to the Organization Parameters window.
2. Select the Other Accounts alternative region.
3. Enter a general ledger account to accumulate Purchase Price Variance for this organization.
This is the variance that you record at the time you receive an item in inventory, and is the difference between the purchase order cost and an item’s standard cost. Purchase price variance is calculated as:
PPV = (PO unit price – standard unit cost) X quantity received
Purchase price variance is not used for average costing.
4. Enter a general ledger account to accumulate Invoice Price Variance for this organization. This is usually an expense account.
Invoice price variance is the difference between the purchase order price for an inventory item and the actual invoice price multiplied by the quantity invoiced. Oracle Inventory passes this account to Oracle Purchasing when the requisition or purchase order is created. When Oracle Payables matches and approves the invoice, Oracle Payables uses the invoice price variance account from the purchase order to record invoice price variance entries. In addition, if you have exchange rate variances, Oracle Payables also records invoice price variance for exchange rate gains and losses.
5. Enter a general ledger account to accumulate Inventory Accounts Payable Accrual for this organization.
This is the account used by Oracle Purchasing to accrue your payable liabilities when you receive your items. This account represents your uninvoiced receipts and is usually part of your Accounts Payable Liabilities in the balance sheet. Oracle Payables relieves this account when the invoice is matched and approved.
6. Enter a default general ledger account to accumulate Encumbrance for this organization. This is the default account when you define your subinventories.
To define Profit and Loss Account information:
1. Select the Other Accounts alternative region.
2. Enter a default Sales revenue account.
When you define your items, this account is defaulted to the item’s sales account in the Invoicing attribute group.
3. Enter a default Cost of Goods Sold account.
When you define your items, this account is defaulted to the item’s cost of goods sold account in the Costing attribute group.
To define Average Cost Account information:
1. Select the Other Accounts alternative region.
2. Under average costing with negative quantity balances, this account represents the inventory valuation error caused by issuing your inventory before processing your receipts. This account is required only when using average costing.
3. Save your work.

Subinventory General Ledger Account Fields

Material
Enter a general ledger account to accumulate material costs for items received into this subinventory. This is usually an asset account used for the value of goods stored in this subinventory.
For asset items, you use this account as a default when you generate purchase requisitions from MRP, min-max organization level planning, or reorder point planning. However, when you receive the purchase order, you use the appropriate valuation or expense account.
Outside Processing
Enter a general ledger account to accumulate outside processing costs for this subinventory. This is usually an asset account. Oracle Work in Process charges this account at standard cost when you receive items for a job or schedule in Oracle Purchasing. Oracle Work in Process relieves this account at standard cost when you issue components to a job or schedule.
Material Overhead
Enter a general ledger account to accumulate material overhead or burden costs for this subinventory. This is usually an asset account.
Overhead
Enter a general ledger account to accumulate resource or department overhead costs for this subinventory. This is usually an asset account. Oracle Work in Process charges this account at standard cost when you complete assemblies from a job or schedule. Oracle Work in Process relieves this account at standard when you issue components to a job or schedule.
Resource
Enter a general ledger account to accumulate resource costs for this subinventory. This is usually an asset account. Oracle Work in Process charges this account at standard cost when you complete assemblies from a job or schedule. Oracle Work in Process relieves this account at standard cost when you issue components to a job or schedule.
Expense
Enter a general ledger account to accumulate expenses for this subinventory. For expense subinventories, this account is charged when you receive any item. For asset subinventories, this account is charged when you receive an expense item.
Encumbrance
ORACLE PURCHASING ONLY
Enter a general ledger account to hold the value of encumbrances against items in this subinventory. This account is used for purchase order receipts and returns.
/by
, , , , , ,

Form Personalization from Sales Order form and Purchase Order form aganist the Item

Form Personalization for Purchase Order and Sales Order while choose Item from procure material from Purchase order form or sell the Material from Sales Order form at the time we should know the that particular material is
  1. VATABLE
  2. EXCISEABLE
  3. RECOVERABLE (CLAIMABLE)
  4. ITEM CLASS ENABLED
    The above all condition satisfied we can proceed to procure material or sell the material other wise give the note message for warning but it should not stop any transaction.
Refer the screen shots below…
Expected output form Sales Order form
Form personalization
Nav:Open the form and choose Object trigger value → Help → Diagnostics → Custom code → Personalize
Condition :
PELEXVAT(${item.LINE.ORDERED_ITEM_DSP.value},${item.LINE.ship_from_org_id.value})=2
 Message Text :
= ‘THIS ‘ || :LINE.ORDERED_ITEM_DSP || ‘ ITEM EXCISE OR VAT NOT DEFINED PLS CHECK.’
 
PELEXVAT (Procedure)
CREATE OR REPLACE FUNCTION APPS.PELEXVAT(ITEM_CODE VARCHAR2,SHIP_ORG_ID NUMBER) RETURN Number 
IS 
FLAG Number;
BEGIN
Select (Case When Flag=0 Then 1 Else 2 End) as Flag Into Flag From(
Select Abs(Sum(F1+F2)-Sum(F3+F4)) Flag From(
Select (Case When Sum(F1)<>0 Then Sum(F1) Else 3 End ) as F1,
(Case When Sum(F2)<>0 Then Sum(F2) Else 4 End) as F2,
(Case When Sum(F3)<>0 Then Sum(F3) Else 5 End)as F3,
(Case When Sum(F4)<>0 Then Sum(F4) Else 6 End) as F4 From (
Select (Case When F1=1 Then Sum(F1) End) as F1,
(Case When F2=1 Then Sum(F2) End) as F2,
(Case When F3=1 Then Sum(F3) End) as F3,
(Case When F4=1 Then Sum(F4) End) as F4 From (
Select Distinct ( Case When ATTRIBUTE_CODE=’EXCISABLE’ And ATTRIBUTE_VALUE=’Y’ Then 1 Else 5 End) as F1,
( Case When ATTRIBUTE_CODE=’MODVATABLE’ And ATTRIBUTE_VALUE=’Y’ Then 1 Else 4 End) as F2,
( Case When ATTRIBUTE_CODE=’RECOVERABLE’ And ATTRIBUTE_VALUE=’Y’ Then 1 Else 4 End) as F3,
( Case When ATTRIBUTE_CODE=’APPLICABLE’ And ATTRIBUTE_VALUE=’Y’ Then 1 Else 11 End) as F4
From ( Select ATTRIBUTE_CODE,ATTRIBUTE_VALUE, SEGMENT1,CREATION_DATE,TEMPLATE_ID,templ_org_regns_id,
ORGANIZATION_ID,RGM_ITEM_REGNS_ID
From (
select Distinct A.ATTRIBUTE_CODE,ATTRIBUTE_VALUE, SEGMENT1,A.CREATION_DATE,A.TEMPLATE_ID,
B.templ_org_regns_id,I.ORGANIZATION_ID,A.RGM_ITEM_REGNS_ID
From JAI_RGM_ITM_TMPL_ATTRS a,
jai_rgm_tmpl_itm_regns b,
jai_rgm_tmpl_org_regns c,
Mtl_System_Items_b I
Where b.inventory_item_id =I.INVENTORY_ITEM_ID
And c.templ_org_regns_id = b.templ_org_regns_id
And C.ORGANIZATION_ID=I.ORGANIZATION_ID
and c.template_id = a.template_id
And (ATTRIBUTE_CODE =’EXCISABLE’ ) And SEGMENT1 =ITEM_CODE
And C.ORGANIZATION_ID=SHIP_ORG_ID
Union All
select Distinct A.ATTRIBUTE_CODE, ATTRIBUTE_VALUE, SEGMENT1 ,A.CREATION_DATE,A.TEMPLATE_ID,
B.templ_org_regns_id,I.ORGANIZATION_ID,A.RGM_ITEM_REGNS_ID
From JAI_RGM_ITM_TMPL_ATTRS a,
jai_rgm_tmpl_itm_regns b,
jai_rgm_tmpl_org_regns c,
Mtl_System_Items_b I
Where b.inventory_item_id =I.INVENTORY_ITEM_ID
And c.templ_org_regns_id = b.templ_org_regns_id
And C.ORGANIZATION_ID=I.ORGANIZATION_ID
and c.template_id = a.template_id
And (ATTRIBUTE_CODE =’MODVATABLE’ ) And SEGMENT1 =ITEM_CODE
And C.ORGANIZATION_ID=SHIP_ORG_ID
Union All
select Distinct A.ATTRIBUTE_CODE, ATTRIBUTE_VALUE, SEGMENT1 ,A.CREATION_DATE,A.TEMPLATE_ID,
B.templ_org_regns_id,I.ORGANIZATION_ID,A.RGM_ITEM_REGNS_ID
From JAI_RGM_ITM_TMPL_ATTRS a,
jai_rgm_tmpl_itm_regns b,
jai_rgm_tmpl_org_regns c,
Mtl_System_Items_b I
Where b.inventory_item_id =I.INVENTORY_ITEM_ID
And c.templ_org_regns_id = b.templ_org_regns_id
And C.ORGANIZATION_ID=I.ORGANIZATION_ID
and c.template_id = a.template_id
And (ATTRIBUTE_CODE =’APPLICABLE’ ) And SEGMENT1 =ITEM_CODE
And C.ORGANIZATION_ID=SHIP_ORG_ID
Union All
select Distinct A.ATTRIBUTE_CODE, ATTRIBUTE_VALUE, SEGMENT1 ,A.CREATION_DATE,A.TEMPLATE_ID,
B.templ_org_regns_id,I.ORGANIZATION_ID,A.RGM_ITEM_REGNS_ID
From JAI_RGM_ITM_TMPL_ATTRS a,
jai_rgm_tmpl_itm_regns b,
jai_rgm_tmpl_org_regns c,
Mtl_System_Items_b I
Where b.inventory_item_id =I.INVENTORY_ITEM_ID
And c.templ_org_regns_id = b.templ_org_regns_id
And C.ORGANIZATION_ID=I.ORGANIZATION_ID
and c.template_id = a.template_id
And (ATTRIBUTE_CODE =’RECOVERABLE’ ) And SEGMENT1 =ITEM_CODE
And C.ORGANIZATION_ID=SHIP_ORG_ID
Union All
select Distinct A.ATTRIBUTE_CODE, ATTRIBUTE_VALUE, SEGMENT1 ,A.CREATION_DATE,A.TEMPLATE_ID,
B.templ_org_regns_id,I.ORGANIZATION_ID,A.RGM_ITEM_REGNS_ID
From JAI_RGM_ITM_TMPL_ATTRS a,
jai_rgm_tmpl_itm_regns b,
jai_rgm_tmpl_org_regns c,
Mtl_System_Items_b I
Where b.inventory_item_id =I.INVENTORY_ITEM_ID
And c.templ_org_regns_id = b.templ_org_regns_id
And C.ORGANIZATION_ID=I.ORGANIZATION_ID
and c.template_id = a.template_id
And (ATTRIBUTE_CODE =’ITEM CLASS’ ) And SEGMENT1 =ITEM_CODE
And C.ORGANIZATION_ID=SHIP_ORG_ID )))Group By F1,F2,F3,F4)));
DBMS_OUTPUT.Put_Line(Flag);
RETURN FLAG;
END;
/
Expected output form Purchase Order form
 
Form personalization
Nav:Open the form and choose Object trigger value → Help → Diagnostics → Custom code → Personalize
Condition :
PELEXITEMVAT(${item.PO_LINES.ITEM_NUMBER.value},
${item.PO_HEADERS.SHIP_TO_ORG_ID.value})<>5
OR
PELEXITEMVAT(${item.PO_LINES.ITEM_NUMBER.value},
${item.PO_HEADERS.SHIP_TO_ORG_ID.value}) =0
PELEXITEMVAT (Procedure)
CREATE OR REPLACE Function APPS.PELEXITEMVAT(ITEM_CODE VARCHAR2,SHIP_ORG_ID NUMBER) RETURN Number
IS
FLAG Number;
BEGIN
Select (Case When Flag Is Null Then 0 Else Flag End ) as Flag Into Flag From (
Select Sum(F1)+Sum(F2)+SUM(F3)+SUM(F4)+SUM(F5) as Flag From (
Select (Case When F1=1 Then Sum(F1) End) as F1,
(Case When F2=1 Then Sum(F2) End) as F2,
(Case When F3=1 Then Sum(F3) End) as F3,
(Case When F4=1 Then Sum(F4) End) as F4,
(Case When F5=1 Then Sum(F5) End) as F5 From (
Select Distinct ( Case When ATTRIBUTE_CODE=’EXCISABLE’ Then 1 Else 5 End) as F1,
( Case When ATTRIBUTE_CODE=’MODVATABLE’ Then 1 Else 4 End) as F2,
( Case When ATTRIBUTE_CODE=’RECOVERABLE’ Then 1 Else 4 End) as F3,
( Case When ATTRIBUTE_CODE=’APPLICABLE’ Then 1 Else 11 End) as F4,
( Case When ATTRIBUTE_CODE=’ITEM’ Then 1 Else 11 End) as F5
From (
Select ATTRIBUTE_CODE,ATTRIBUTE_VALUE, SEGMENT1,CREATION_DATE,TEMPLATE_ID,
templ_org_regns_id,ORGANIZATION_ID,RGM_ITEM_REGNS_ID
From (
select Distinct A.ATTRIBUTE_CODE,ATTRIBUTE_VALUE, SEGMENT1,A.CREATION_DATE,A.TEMPLATE_ID,
B.templ_org_regns_id,I.ORGANIZATION_ID,A.RGM_ITEM_REGNS_ID
From JAI_RGM_ITM_TMPL_ATTRS a,
jai_rgm_tmpl_itm_regns b,
jai_rgm_tmpl_org_regns c,
Mtl_System_Items_b I
Where b.inventory_item_id =I.INVENTORY_ITEM_ID
And c.templ_org_regns_id = b.templ_org_regns_id
And C.ORGANIZATION_ID=I.ORGANIZATION_ID
and c.template_id = a.template_id
And (ATTRIBUTE_CODE =’EXCISABLE’ ) And SEGMENT1 =ITEM_CODE
And C.ORGANIZATION_ID=SHIP_ORG_ID
Union All
select Distinct A.ATTRIBUTE_CODE, ATTRIBUTE_VALUE, SEGMENT1 ,A.CREATION_DATE,A.TEMPLATE_ID,
B.templ_org_regns_id,I.ORGANIZATION_ID,A.RGM_ITEM_REGNS_ID
From JAI_RGM_ITM_TMPL_ATTRS a,
jai_rgm_tmpl_itm_regns b,
jai_rgm_tmpl_org_regns c,
Mtl_System_Items_b I
Where b.inventory_item_id =I.INVENTORY_ITEM_ID
And c.templ_org_regns_id = b.templ_org_regns_id
And C.ORGANIZATION_ID=I.ORGANIZATION_ID
and c.template_id = a.template_id
And (ATTRIBUTE_CODE =’MODVATABLE’ ) And SEGMENT1 =ITEM_CODE
And C.ORGANIZATION_ID=SHIP_ORG_ID
Union All
select Distinct A.ATTRIBUTE_CODE, ATTRIBUTE_VALUE, SEGMENT1 ,A.CREATION_DATE,A.TEMPLATE_ID,
B.templ_org_regns_id,I.ORGANIZATION_ID,A.RGM_ITEM_REGNS_ID
From JAI_RGM_ITM_TMPL_ATTRS a,
jai_rgm_tmpl_itm_regns b,
jai_rgm_tmpl_org_regns c,
Mtl_System_Items_b I
Where b.inventory_item_id =I.INVENTORY_ITEM_ID
And c.templ_org_regns_id = b.templ_org_regns_id
And C.ORGANIZATION_ID=I.ORGANIZATION_ID
and c.template_id = a.template_id
And (ATTRIBUTE_CODE =’APPLICABLE’ ) And SEGMENT1 =ITEM_CODE
And C.ORGANIZATION_ID=SHIP_ORG_ID
Union All
select Distinct A.ATTRIBUTE_CODE, ATTRIBUTE_VALUE, SEGMENT1 ,A.CREATION_DATE,A.TEMPLATE_ID,
B.templ_org_regns_id,I.ORGANIZATION_ID,A.RGM_ITEM_REGNS_ID
From JAI_RGM_ITM_TMPL_ATTRS a,
jai_rgm_tmpl_itm_regns b,
jai_rgm_tmpl_org_regns c,
Mtl_System_Items_b I
Where b.inventory_item_id =I.INVENTORY_ITEM_ID
And c.templ_org_regns_id = b.templ_org_regns_id
And C.ORGANIZATION_ID=I.ORGANIZATION_ID
and c.template_id = a.template_id
And (ATTRIBUTE_CODE =’RECOVERABLE’ ) And SEGMENT1 =ITEM_CODE
And C.ORGANIZATION_ID=SHIP_ORG_ID
Union All
select Distinct A.ATTRIBUTE_CODE, ATTRIBUTE_VALUE, SEGMENT1 ,A.CREATION_DATE,A.TEMPLATE_ID,
B.templ_org_regns_id,I.ORGANIZATION_ID,A.RGM_ITEM_REGNS_ID
From JAI_RGM_ITM_TMPL_ATTRS a,
jai_rgm_tmpl_itm_regns b,
jai_rgm_tmpl_org_regns c,
Mtl_System_Items_b I
Where b.inventory_item_id =I.INVENTORY_ITEM_ID
And c.templ_org_regns_id = b.templ_org_regns_id
And C.ORGANIZATION_ID=I.ORGANIZATION_ID
and c.template_id = a.template_id
And (ATTRIBUTE_CODE =’ITEM CLASS’ ) And SEGMENT1 =ITEM_CODE
And C.ORGANIZATION_ID=SHIP_ORG_ID
Union All
select Distinct ‘ITEM’ as ATTRIBUTE_CODE, ‘ITEM’ as ATTRIBUTE_VALUE, B.SEGMENT1 ,Null as CREATION_DATE,0 as TEMPLATE_ID,0 as templ_org_regns_id,B.ORGANIZATION_ID,0 as RGM_ITEM_REGNS_ID
From jai_rgm_tmpl_itm_regns A,Mtl_System_Items_B B
Where A.INVENTORY_ITEM_ID=B.INVENTORY_ITEM_ID And
B.SEGMENT1 =ITEM_CODE
And B.ORGANIZATION_ID=SHIP_ORG_ID )))Group By F1,F2,F3,F4,F5));
DBMS_OUTPUT.Put_Line(Flag);
RETURN FLAG;
END;
/
/by
, , , ,

Oracle Purchasing Document Style and PO Output Communication

Defining Document Styles
Use the Document Styles window to create and update purchase order styles.
Purchase order document styles allow organizations to control the look and feel of the application to match the usage of the purchasing document.
Through reusable document styles, organizations can turn on or off various Oracle Purchasing features, thereby simplifying the user interface.
In addition, document styles provide the ability to define purchasing document names that align more closely with the naming conventions of your organization’s business.
When a purchasing document is created using a document style, disabled features are hidden.
For example, you can create a document style for a specific commodity, such as temporary labor.
This document style optimizes field labels and presentation for that commodity, thereby simplifying purchase order entry.
Prerequisites
Document styles only apply to authoring documents in the Buyer Work Center.
Document styles are not organization specific.
To define document styles:
1. Navigate to the Document Styles window.
2. If you are defining a new document style click Create. To enter changes to an existing style use the Search region to enter the Name, Description, or the Status. Once you have completed one or all of these fields click Go. Enter your changes by clicking the Update icon for your document style.

Note: Once a style has been saved, you can only update the style to be less restrictive.

3. Enter the Name and Description of the document style. The style name must be unique.
4. Select the Status as Active for a new style or Inactive for a style you no longer want used.
5. You must enter a unique Display Name for the Standard Purchase Order. This is the name that appears in the Buyer Work Center.
6. If you are defining a style that applies to contract purchase agreements or blanket purchase agreements, check their boxes and enter a unique Display Name.
7. If Services Procurement is implemented, check the Purchase Bases that apply to this document style. See: Defining Purchase Basis, .
8. Select whether specific or all Line Types are enabled for this document style. See: Line Types in Purchasing Documents, .
9. If you are defining a style that includes blanket purchase agreements, enable price breaks using the Price Breaks checkbox.
10. If Services Procurement is implemented and you have enabled a Temp Labor basis, use the checkbox to enable Price Differentials.
11. If Services Procurement is implemented, enable the Complex Payments attributes that apply:
• Check Advances if advance payments are to be allowed.
• Check Retainage if withholding of a portion of the payment until all work under a contract is accepted is to be allowed.
• Check Progress Payments to enable partial payments during performance of the contract. If Progress Payments is enabled, at least one pay item must be selected.
• Milestone – Enable for payments based on progress events. Enabled by default for Goods line type.
• Rate – Enable when payment amount is pro-rated based on the percentage of work completed.
• Lump Sum – Enable when payment amount is a fixed amount based on the percentage of work completed.
• Enable Treat Progress Payments as Contract Financing if it applies to this style’s progress payments.

12. Click Apply.
Purchase Order Communication Setup Steps
This section discusses the setup steps which define your supplier’s preferred communication method. Oracle Purchasing supports the following methods of communicating purchase orders:

• Print
• Facsimile (fax)
• Electronic mail (e-mail)
• Extensible Markup Language (XML)
• Electronic Data Interchange (EDI)

Important: It is important to note that enabling PDF output (described below) activates the Communicate selection in the Tools menu of the Purchase Order Summary window.
/by
, , , , , ,

How to Generate the COGS Account from the Order Type [ID 414314.1]

How to Generate the COGS Account from the Order Type [ID 414314.1]
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.

/by
, , , , , ,

How and When COGS account hit for transactions

Inventory Interface generates the cost of goods sold account for transactions when passing the transactions to Oracle Inventory. Receivables Interface generates a receivable account, a revenue account, a tax account, a freight account, and others, but not the cost of goods sold account. Ship confirm and pick release do not generate any accounts.
___________________________________________________________________
Oracle Application R12 COGS 

In Oracle Application R12 COGS process has been changed. Reason for that are aggressive revenue
recognition practices as well as the guidelines from various governing bodies.

Till R11 Cost of goods sold has been recognized as soon as the Order line has shipped, as shown in below
steps

After ship confirm, user run the interface trip stop (ITS).
ITS in turns run the OM Interface and Inventory Interface.
Inventory Interface calls Inventory transaction manager which in turns call COGS WF.
But as per new practices COGS should be recognized along with the revenue.

In R12 used need to define deferred cogs account. These deferred cogs account can be defined at each
inventory org level.

During shipping process Inventory tables will hold the deferred COGS accounts. Only after invoicing has
done in AR, AR will notify the Costing and Costing in turns call the COGS account generator to get the
cogs account .In that way COGS and revenue will be recognized in the same period.

There are few exceptions like how to get the COGS for
1. Ship only line (No Invoice will be created). 
To handle above cases Close-line activity of the order line workflow has modified to call the costing API
to get the cogs value 
What is the Deferred COGS account in R12
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.
To set the deferrred COGS account.
 Inventory –Setup–Organization–Parameters–Other Accounts

A new account is added which is referred as the Deffered COGS accounts.

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:

Deffered COGS : Debit y 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:
Deffered COGS : Credit (Actual revenue percentage)
COGS : Debit (Actual revenue percentage )

COGS (Cost of Goods Sold) in Oracle E-Business Suite Release 12
Deferred COGS is a new feature introduced in Oracle E-Business Suite Release 12. The basic
fundamentals behind the enhancement are that the COGS are now directly matched to the
Revenue.
 
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.
 
While this helps solve some key accounting issues, there are some key issues one needs to be
aware of:
   
• Currently Deferred COGS accounting cannot be turned off in Oracle EBS Release 12.
• The activity of recording COGS recognition is now a multi-step process
• Run AR Revenue Recognition, and Submit Accounting Processes
• Run a set of concurrent processes in Cost Manager 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.
• Record Order Management Transactions: records new sales order transaction activity
such as shipments and RMA returns in Oracle Order Management.
• Collect Revenue Recognition Information: determines the percentage of recognized or
earned revenue related to invoiced sales order shipment lines in Oracle Receivables.
• 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 end result of these activities is a series of COGS Recognition Material Distributions.
However these distributions will not be visible on the Material Transaction screen, unless the
‘Include Logical Transaction’ checkbox is checked.

R12 Order Management: Revenue-COGS Matching Part I
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 period’s 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 take one at a time to discuss in the
coming posts.
SQL statements that help understand the data model are below,
SELECT header_id
  FROM oe_order_headers_all
 WHERE order_number = &your_order_number;

SELECT line_id
  FROM oe_order_lines_all
 WHERE header_id = (SELECT header_id
                      FROM oe_order_headers_all
                     WHERE order_number = &your_order_number);

SELECT *
  FROM mtl_material_transactions
 WHERE trx_source_line_id IN (SELECT line_id
                                FROM oe_order_lines_all
                               WHERE header_id = (SELECT header_id
                                                    FROM oe_order_headers_all
                                                   WHERE order_number =
&your_order_number))
       AND transaction_type_id IN (33, 10008);

SELECT *
  FROM mtl_transaction_accounts
 WHERE transaction_id IN (
          SELECT transaction_id
            FROM mtl_material_transactions
           WHERE trx_source_line_id IN (SELECT line_id
                                          FROM oe_order_lines_all
                                         WHERE header_id = (SELECT header_id
                                                              FROM
oe_order_headers_all
                                                             WHERE
order_number = &your_order_number))
             AND transaction_type_id IN (33, 10008));

SELECT *
  FROM cst_revenue_cogs_match_lines
 WHERE cogs_om_line_id IN (SELECT line_id
                             FROM oe_order_lines_all
                            WHERE header_id = (SELECT header_id
                                                 FROM oe_order_headers_all
                                                WHERE order_number =
&your_order_number));

SELECT *
  FROM cst_cogs_events
 WHERE cogs_om_line_id IN (SELECT line_id
                             FROM oe_order_lines_all
                            WHERE header_id = (SELECT header_id
                                                 FROM oe_order_headers_all
                                                WHERE order_number =
&your_order_number));

SELECT *
  FROM cst_revenue_cogs_control;

SELECT *
  FROM ra_customer_trx_lines_all
 WHERE interface_line_context = ‘ORDER ENTRY’
   AND interface_line_attribute6 IN (SELECT line_id
                                       FROM oe_order_lines_all
                                      WHERE header_id = (SELECT header_id
                                                           FROM
oe_order_headers_all
                                                          WHERE order_number
= &your_order_number));

SELECT *
  FROM ra_cust_trx_line_gl_dist_all
 WHERE customer_trx_line_id IN (
          SELECT customer_trx_line_id
            FROM ra_customer_trx_lines_all
           WHERE interface_line_context = ‘ORDER ENTRY’
             AND interface_line_attribute6 IN (SELECT line_id
                                                 FROM oe_order_lines_all
                                                WHERE header_id = (SELECT
header_id
                                                                     FROM
oe_order_headers_all
                                                                    WHERE
order_number = &your_order_number))
             AND account_set_flag = ‘N’
             AND account_class = ‘REV’);

SELECT *
  FROM cst_revenue_recognition_lines
 WHERE revenue_om_line_id IN (SELECT line_id
                                FROM oe_order_lines_all
                               WHERE header_id = (SELECT header_id
                                                    FROM oe_order_headers_all
                                                   WHERE order_number =
&your_order_number));

SELECT *
  FROM mtl_transaction_accounts
 WHERE transaction_id IN (
          SELECT transaction_id
            FROM mtl_material_transactions
           WHERE trx_source_line_id IN (SELECT line_id
                                          FROM oe_order_lines_all
                                         WHERE header_id = (SELECT header_id
                                                              FROM
oe_order_headers_all
                                                             WHERE
order_number = &your_order_number))
             AND transaction_type_id IN (33, 10008));

/by