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.

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));

This section contains an overview of each task you need to complete to set up Oracle Inventory.

 Step 1 Define Inventory Flexfield (Required)

  • System Item
  • Item Categories
  • Item Catalogs
  • Stock Locators
  • Accounting Aliases
  • Sales Order
  • Service Item
Step 2 Define Your Locations (Optional)
Step 3 Define Your Employees (Optional)
Step 4 Define Your Organization Calendar (Required)
Step 5 Define Your Organizations (Required)
Step 6 Define Your Organization Parameters (Required)
Step 7 Change Organizations (Required)
Step 8 Define Your Intercompany Relations
Step 9 Define Your Receiving Options (Optional)
Step 10 Define Your Picking Rules (Optional)
Step 11 Define Your ATP Rules (Optional)
Step 12 Define Your Planners (Optional)
Step 13 Define Your Unit of Measure Classes (Required)
Step 14 Define Your Units of Measure (Required)
Step 15 Define Your Unit of Measure Conversions (Optional)
Step 16 Define Your Subinventories (Required)
Step 17 Define Your Stock Locators (Optional)
Step 18 Define Your Item Attribute Controls (Required)
Step 19 Define Your Categories (Required)
Step 20 Define Your Category Set (Required)
Step 21 Define Your Default Category Sets (Required)
Step 22 Define Your Statuses (Required)
Step 23 Define Your Item Catalog Groups (Optional)
Step 24 Define Your Item Types (Optional)
Step 25 Define Your Item Templates (Optional)
Step 26 Define Your Cross-Reference Types (Optional)
Step 27 Define Your Item Delete Constraints (Optional)
Step 28 Define Your Cost Types (Required)
Step 29 Define Your Cost Activities (Optional)
Step 30 Define Your Material Sub-Elements (Optional)
Step 31 Define Your Material Overheads (Optional)
Step 32 Define Your Default Material Overhead Rates (Optional)
Step 33 Define Your Freight Carriers (Optional)
Step 34 Define Your Organization Shipping Network (Optional)
Step 35 Define Your Shipping Methods (Optional)
Step 36 Define Your Movement Statistics Parameters (Optional)
Step 37 Define Your Account Aliases (Optional)
Step 38 Define Your Transaction Source Types (Optional)
Step 39 Define Your Transaction Types (Optional)
Step 40 Define Your Transaction Reasons (Optional)
Step 41 Define Your Purchasing Options (Optional)
Step 42 Open Your Accounting Periods (Required)
Step 43 Request Your Interface Managers (Optional)
Step 44 Set Profile Options (Required)
Step 45 Define Your Container Types (Optional)
Step 46 Define Your Commodity Codes (Optional)
Step 47 Define Your Customer Items (Optional)
Step 48 Define Your Customer Item Cross References (Optional)
oe_order_headers_all,
oe_order_lines_all,
oe_order_holds_all,
oe_transaction_types_tl,
cs_customer_product_statuses,
cs_customer_products_all ,
wsh_delevery_details

For Deemed Products:-

MTL_UNIT_TRANSACTIONS,
MTL_MATERIAL_TRANSACTIONS

oe_order_headers_all,
oe_order_holds_all,
oe_order_sources,
oe_transaction_types_all,
oe_sales_credits,
oe_order_lines_all,
oe_order_lines_history,
oe_reservtns_iface_all,
wsh_delivey_details

To Find Duplicate Item Category Code


SELECT category_set_name, category_concat_segments, COUNT (*)
FROM mtl_category_set_valid_cats_v
WHERE (category_set_id = 1)
GROUP BY category_set_name, category_concat_segments
HAVING COUNT (*) > 1
ORDER BY category_concat_segments

Get Number Of canceled requisition


SELECT a.AUTHORIZATION_STATUS,(a.ORG_ID),(SELECT distinct hr.per_all_people_f.first_name|| ‘ ‘|| hr.per_all_people_f.middle_names|| ‘ ‘|| hr.per_all_people_f.last_name “Employee Name”
FROM hr.per_all_people_f
where hr.per_all_people_f.PERSON_ID in
(select employee_id from fnd_user fu where fu.user_id = a.CREATED_BY)) CREATED_BY,count(SEGMENT1 )
FROM
po_requisition_headers_all a
WHERE
a.creation_date BETWEEN TO_DATE(’01/01/2007′, ‘DD/MM/YYYY’)
and TO_DATE(’30/05/2007′, ‘DD/MM/YYYY’)
and a.AUTHORIZATION_STATUS = ‘CANCELLED’
group by a.AUTHORIZATION_STATUS,a.ORG_ID,a.CREATED_BY

Number of line processed in Order Management


SELECT COUNT (line_id) “Order Line Processed”
FROM oe_order_lines_all
WHERE creation_date BETWEEN TO_DATE (:Fdate, ‘DD/MM/YYYY’)
AND TO_DATE (:tdate, ‘DD/MM/YYYY’)
AND flow_status_code = ‘CLOSED’;

To Check Item Catogry For Inventory master (No Of Segments May Varry)


SELECT ood.organization_name,
segment1|| ‘-‘|| segment2|| ‘-‘|| segment3 catgory
FROM org_organization_definitions ood,
mtl_categories_vl mcv,
mtl_category_sets mcs
WHERE mcs.structure_id = mcv.structure_id
ORDER BY ood.organization_name

Check Locators for inventory Inventory Org Wise(Number of segment may varry)


SELECT mil.segment1 loc_seg1, mil.segment11 loc_seg11, mil.segment2 loc_seg2,
mil.segment3 loc_seg3, mil.segment4 loc_seg4, mil.segment5 loc_seg5,
mil.segment6 loc_seg6,ood.ORGANIZATION_NAME,mil.SUBINVENTORY_CODE
FROM mtl_item_locations mil,org_organization_definitions ood
where mil.ORGANIZATION_ID = ood.ORGANIZATION_ID

Display All Subinventories Setup

select msi.secondary_inventory_name, MSI.SECONDARY_INVENTORY_NAME “Subinventory”, MSI.DESCRIPTION “Description”,
MSI.DISABLE_DATE “Disable Date”, msi.PICKING_ORDER “Picking Order”,
gcc1.concatenated_segments “Material Account”,
gcc2.concatenated_segments “Material Overhead Account”,
gcc3.concatenated_segments “Resource Account”,
gcc4.concatenated_segments “Overhead Account”,
gcc5.concatenated_segments “Outside Processing Account”,
gcc6.concatenated_segments “Expense Account”,
gcc7.concatenated_segments “Encumbrance Account”,
msi.material_overhead_account,
msi.resource_account,
msi.overhead_account,
msi.outside_processing_account,
msi.expense_account,
msi.encumbrance_account
from mtl_secondary_inventories msi,
gl_code_combinations_kfv gcc1,
gl_code_combinations_kfv gcc2,
gl_code_combinations_kfv gcc3,
gl_code_combinations_kfv gcc4,
gl_code_combinations_kfv gcc5,
gl_code_combinations_kfv gcc6,
gl_code_combinations_kfv gcc7
where msi.material_account = gcc1.CODE_COMBINATION_ID(+)
and msi.material_overhead_account = gcc2.CODE_COMBINATION_ID(+)
and msi.resource_account = gcc3.CODE_COMBINATION_ID(+)
and msi.overhead_account = gcc4.CODE_COMBINATION_ID(+)
and msi.outside_processing_account = gcc5.CODE_COMBINATION_ID(+)
and msi.expense_account = gcc6.CODE_COMBINATION_ID(+)
and msi.encumbrance_account = gcc7.CODE_COMBINATION_ID(+)
order by msi.secondary_inventory_name

To Select Unit Of measure exist in ebusiness suite

select uom_code,unit_of_measure
from mtl_units_of_measure

Query to find out Customer Master Information. Customer Name, Account Number, Adress etc.

select p.PARTY_NAME,ca.ACCOUNT_NUMBER,loc.address1,loc.address2,loc.address3,loc.city,loc.postal_code,
loc.country,ca.CUST_ACCOUNT_ID
from apps.ra_customer_trx_all I,
apps.hz_cust_accounts CA,
apps.hz_parties P,
apps.hz_locations Loc,
apps.hz_cust_site_uses_all CSU,
apps.hz_cust_acct_sites_all CAS,
apps.hz_party_sites PS
where I.COMPLETE_FLAG =’Y’
and I.bill_TO_CUSTOMER_ID= CA.CUST_ACCOUNT_ID
and ca.PARTY_ID=p.PARTY_ID
and I.bill_to_site_use_id=csu.site_use_id
and csu.CUST_ACCT_SITE_ID=cas.CUST_ACCT_SITE_ID
and cas.PARTY_SITE_ID=ps.party_site_id
and ps.location_id=loc.LOCATION_ID

Query to Find Responsibilities assigned to particular user.


SELECT b.responsibility_name NAME
FROM apps.fnd_user_resp_groups a,
apps.fnd_responsibility_vl b,
apps.fnd_user u
WHERE a.user_id = u.user_id
AND u.user_id = (select user_id from FND_USER where user_name=:User_name)
AND a.responsibility_id = b.responsibility_id
AND a.responsibility_application_id = b.application_id
AND SYSDATE BETWEEN a.start_date AND NVL (a.end_date, SYSDATE + 1)
AND b.end_date IS NULL
AND u.end_date IS NULL

Query To find the Request Run By Concurrentselect b.user_concurrent_queue_name, c.request_id
from fnd_concurrent_processes a, fnd_concurrent_queues_vl b, fnd_concurrent_requests c
where a.concurrent_queue_id = b.concurrent_queue_id
and a.concurrent_process_id = c.controlling_manager;

Query to find on Hand Quantity

select sum(transaction_quantity) from MTL_ONHAND_QUANTITIES
where inventory_item_id=9
and organization_id=188

Qunatity on order, Expected Deliverselect sum(ordered_quantity),a.SCHEDULE_SHIP_DATE
from oe_order_lines_all a
where inventory_item_id=10
and ship_from_org_id=188
group by a.SCHEDULE_SHIP_DATE

Query to find Item Code, Item Description Oracle Item Master Query(select item, description from mtl_system_items_b
where inventory_item_id=&your_item
and organization_id=&organization_id) item,

Query to Find out On Hand Quantity of specific Item Oracle inventory
(select sum(transaction_quantity) from mtl_onhand_quantity_details
where inventory_item_id=&your_item
and organization_id=&organization_id) onhand,
— Qty Issued by X No clue what you want here
–Qty On Order,Expected deivery date(select sum(ordered_quantity),scheduled_ship_date from oe_order_lines_all
where inventory_item_id=&your_item
and ship_from_org_id=&organization_id
group by scheduled_ship_date) order_info,
–Toatl Received Qty
(select sum(transaction_quantity) from mtl_material_transactions
inventory_item_id=&your_item
and organization_id=&organization_id
and transaction_quantity>0) tot_rec_qty,
–Total received Qty in 9 months
(select sum(transaction_quantity) from mtl_material_transactions
inventory_item_id=&your_item
and organization_id=&organization_id
and transaction_quantity>0
and transaction_date between trunc(sysdate) and trunc(sysdate-270)) tot_rec_qty_9mths,
–Total issued quantity in 9 months(select sum(transaction_quantity) from mtl_material_transactions
inventory_item_id=&your_item
and organization_id=&organization_id
and transaction_quantity<0 and transaction_date between trunc(sysdate) and trunc(sysdate-270)) tot_iss_qty_9mths, –Average monthly consumption
(select sum(transaction_quantity)/30 from mtl_material_transactions
inventory_item_id=&your_item
and organization_id=&organization_id
and transaction_quantity<0) avg_month_consumption; Find detail of specific Applications Running in System System Administrator

SELECT application_id,APPLICATION_NAME
FROM fnd_application_tl
WHERE application_name = ‘Purchasing’
AND rownum = 1;

Find the Request Groups and Concurrent ProgamsSELECT g.request_group_name, c.user_concurrent_program_name,
a.application_name, g.application_id, g.request_group_id,
u.unit_application_id, u.request_unit_id
FROM fnd_request_groups g,
fnd_request_group_units u,
fnd_application_tl a,
fnd_concurrent_programs_tl c
WHERE g.request_group_id = u.request_group_id
AND u.unit_application_id = a.application_id
AND u.request_unit_id = c.concurrent_program_id
–and c.USER_CONCURRENT_PROGRAM_NAME like ‘%Purchase Order%’
ORDER BY C.user_concurrent_program_name, A.application_name, g.request_group_id;

Display all categories that the Item Belongs
SELECTunique micv.CATEGORY_SET_NAME “Category Set”,
micv.CATEGORY_SET_ID “Category Set ID”,
decode( micv.CONTROL_LEVEL,
1, ‘Master’,
2, ‘Org’,
‘Other’) “Control Level”,
micv.CATEGORY_ID “Category ID”,
micv.CATEGORY_CONCAT_SEGS “Category”
FROM
MTL_ITEM_CATEGORIES_V micv

Another Query to Get Onhand Qty With Oranization ID, Item Code,  Quantity
SELECT organization_id,
(SELECT ( msib.segment1|| ‘-‘|| msib.segment2|| ‘-‘|| msib.segment3|| ‘-‘|| msib.segment4)
FROM mtl_system_items_b msib
WHERE msib.inventory_item_id = moq.inventory_item_id
AND msib.organization_id = moq.organization_id) “Item Code”,
(SELECT description
FROM mtl_system_items_b msib
WHERE msib.inventory_item_id =
moq.inventory_item_id
AND msib.organization_id = moq.organization_id)
“item Description”,
SUM (moq.transaction_quantity) onhandqty
FROM mtl_onhand_quantities moq
GROUP BY moq.organization_id, (moq.inventory_item_id)