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));
How and When COGS account hit for transactions
___________________________________________________________________
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));
Share this:
Order Management Basic Setup steps
Define key and descriptive flexfields to capture additional information about orders and transactions. This step is required for Key Flexfields, and optional if you plan on using the functionality surrounding Descriptive Flexfields. Several defaulting values are
provided.
Step 2: Multiple Organizations
Define multiple organizations in Oracle Inventory. This step is optional.
Step 3: Inventory Organizations
Define inventory organizations (warehouses), parameters, subinventories, and picking rules in Oracle Inventory. You must define at least one item validation organization and at least one organization that acts as an inventory source for orders fulfilled internally.
If you plan to drop ship some orders, you must also define at least one logical organization for receiving purposes. Your item validation organization can be the same as your inventory source or your logical receiving organization, but you cannot use one organization for all three purposes. This step is required.
Step 4: Profile Options
Define profile options to specify certain implementation parameters, processing options, and system options. This step is required.
Step 5: Parameters
Set your Order Management Parameters to validate items, enable customer relationships, and operating unit defaults. This step is required.
Step 6: Invoicing
Define invoicing information, including payment terms, invoicing and accounting rules, Autoaccounting parameters, territories, and invoice sources.This step is required if you plan on transferring invoicing information to Oracle Receivables. Several defaulting values are provided.
Step 7: Salespersons
Define information on your sales representatives. This step is optional.
Step 8: Tax
Define tax features, such as codes, rates, exceptions, and exemptions. This step is required.
Step 9: QuickCodes
Define QuickCodes that provide custom values for many lists of values throughout Order Management. This step is required if you plan on creating user defined Quickcodes for utilization within Order Management. Defaulting values are provided.
Step 10: Workflow
Define order and line processing flows to meet different order and line type requirements. This step is required.
Step 11: Document Sequences (Order Numbering)
Define Document Sequences for automatic or manual numbering of orders. This step is required.
Step 12: Order Import Sources
Define sources for importing orders into Order Management. This step is required if you plan on importing orders or returns into Order Management.
Step 13: Units of Measure
Define the units of measure in which you supply items. This step is required.
Step 14: Item Information
Define item information, including item attribute controls, categories, and statuses. This step is required.
Step 15: Items
Define the items that you sell, as well as container items. This step is required.
Step 16: Configurations
Define the configurations that you sell. This step is required if you plan on generating orders or returns for configured items. Several defaulting values are provided.
Step 17: Pricing
Define price lists for each combination of item and unit of measure that you sell. Optionally, you can define pricing rules and parameters to add flexibility. This step is required.
Step 18: Customer Classes
Define customer profile classes. This step is required if you plan on using the functionality surrounding Customer Profiles. Several defaulting values are provided.
Step 19: Customers
Define information on your customers. This step is required.
Step 20: Item Cross References
Define item cross references for ordering by customer part number, UPC, or any generic item number. This step is required if you plan on using the functionality surrounding item cross referencing. Several defaulting values have been provided.
Step 21: Sourcing
Define your sourcing rules for scheduling supply chain ATP functions. This step is optional.
Step 22: Order Management Transaction Types (Order and Line Types)
Define Order Management transaction types to classify orders and returns. For each order type, you can assign a default price list, defaulting rules, order lines, return lines, line types, workflow assignments, payment terms, and freight terms. This step is required.
Note: Order Management provides NO seeded OM transaction types. For existing Oracle Order Entry customers, Order Management will update existing Order Types to OM transaction type during the upgrade process.
Step 23: Cost of Goods Sold (COGS)
Set up your Cost of Goods Sold Accounting Flexfield combination (COGS Account) in Oracle Inventory. This step is required if you plan on utilizing the functionality surrounding COGS.
Step 24: Processing Constraints
Define processing constraints to prevent users from adding updating, deleting,
splitting lines, and cancelling order or return information beyond certain points in your order cycles. Use the constraints Order Management provides, which prevent data integrity violations, or create your own. This step is optional. Several default values for processing constraints have been defined.
Step 25: Defaulting Rules
Define defaulting rules to determine the source and prioritization for defaulting
order information to reduce the amount of information you must enter manually in the Sales Orders window. This step is optional. Several Defaulting rules and corresponding values for have been defined.
Step 26: Credit Checking
Define your credit checking rules. This step is required if you plan on performing any type of order credit checking.
Step 27: Holds
Define automatic holds to apply to orders and returns. This step is required if you plan on performing automatic hold for orders or returns.
Step 28: Attachments
Define standard documents to attach automatically to orders and returns. This step is optional.
Step 29: Freight Charges and Carriers
Define freight charges and freight carriers to specify on orders. This step is required if you plan on charging customers for freight or additional order charges.
Step 30: Shipping
Define shipping parameters in Oracle Shipping Execution. This step is required.
Share this:
Setup – Approval Hierarchies in Oracle Purchasing Position & Supervisor
1. Approval Hierarchies (uses position hierarchies)
2. Employee/Supervisor Relationships (use employee/supervisor relationship)
* Third method of Advanced Approval Support for Requisitions (Release 12 use integration with Oracle Approvals Management) . However in this article, focus here is set on above two most commonly used methods.
1. Position Hierarchies
Position Hierarchies are hierarchies that have a position relationship. Purchasing utilizes positions as a roadmap to determine how and where documents will be routed once the approval process has been initiated. It is first necessary to have created all positions that are going to be used in the system. Once all positions have been created, it is necessary to build the position hierarchy. Each position has approval limits, so when a purchase order exceeds the limits of the position, the purchase order is forwarded onto the next position in the Hierarchy. The hierarchy for positions is defined on the Position Hierarchy form. When this is complete or is changed, the Fill Employee Hierarchy concurrent program must be run for the new hierarchy to come into effect. You must set up Positions if you plan to use either security or approval hierarchies. If you are using Shared HR navigate, Purchasing: Setup: Personnel: Position Hierarchy. Otherwise, if you are using a full install of HR then navigate, Human Resources: Work Structures: Position: Hierarchy.
2. Employee/Supervisor Relationships
This type of hierarchy does not use the Approval Hierarchy form, but is defined by the employee/supervisor relationship. The supervisor of an employee is defined on the Assignment region of the Employee form. If the purchase order entered by the employee exceeds the approval limits, the purchase order is forwarded onto the employees’ supervisor, as defined on the Employee form.
To implement this form of approval routing, you need only to define jobs. The job will then serve as the tie to the Approval group, and based on the approval limits from the Approval Group, the Document will either be Approved or Forwarded to the Employees’ Supervisor. If no Supervisor is able to be located and the job assigned to the employee does not have Approval Authority, then the Approving employee must enter a Forward-to person, or the Document will be returned to an Incomplete status and a notification will be sent to the Approving employee, stating – ‘No Approver Found – Please Select a Forward-To Employee’.
Selecting an approval routing method
There are two forms that determine the route that an approval will take:
1. Financial Options (Purchasing: Setup: Organizations: Financial Options)
2. Document Types (Purchasing: Setup: Document Types)
1. Financial Options
The Human Resources zone on the Financial Options form has an option called Use Approval Hierarchies. This option determines which type of hierarchy is used for the approval process. When checked, the Position Hierarchy is used and when unchecked the Employee/Supervisor relationship (i.e. Jobs) is used.
2. Document Types
There are three attributes on this form that determine the approval path of the document:
a) Forward Method
b) Default Hierarchy
c) Transaction Type (for Requisitions only)
* Each of these 3 options are described in some details below
a) Forward Method
This field has two options that apply regardless as to whether you use a Position Hierarchy or an Employee/Supervisor relationship.
– Direct: the document will pass to the next position or supervisor in the hierarchy who has enough authority to approve the document.
– Hierarchy: the document will pass to the next person in the hierarchy regardless to whether that position or supervisor has enough approval authority to approve.
b) Default Hierarchy
The Default Hierarchy option will only appear on the Document Type form if the option Use Approval Hierarchies is checked on the Human Resources zone on the Financial Options screen. The Default Hierarchy field has a LOV. This list is derived from the hierarchies created using the Position Hierarchy form.
The Default Hierarchy is the one that will be used by the approval process unless the person who submits the document for approval changes it in the Approval Modal form. But, the hierarchy can only be changed on the Approval Modal form if the attribute Can Change Approval Hierarchy is checked on the Document Type form – and this attribute is only enabled if the Use Approval Hierarchies is checked.
When choosing the action of ‘Approve’ for a document, if a Forward-To person is not defined and the person taking action does not have sufficient approval authority, the default hierarchy will first be searched for the employee attempting the approval. This default hierarchy is defined on the Document Types form:
Purchasing: Setup: Purchasing: Document Types
Thus, it is imperative that the low-end users (those with little approval authority) be present in this default hierarchy so the next Forward-To approver can be found. Alternatively, the checkbox Can Change Approval Hierarchies should be selected on the Document Types form. With this checkbox enabled, the user has the option to specify an alternate approval hierarchy; provided that the user belongs to one or more additional hierarchies (i.e. the Approval Hierarchy list of values in the Document Approval window will only contain the hierarchies that this user belongs to).
If the low-end user is not part of the default hierarchy specified in the Document Types form and chooses to approve the document, the end result will be a notification to the user stating ‘No Approver Found’.
A similar scenario of ‘No Approver Found’ will result if the ‘Owner Can Approve’ checkbox (on the Document Types form) is disabled and the person attempting to approve the document is not in the Default Hierarchy. When the Approve button is clicked, this setting is validated and enforced; it is at this time that the requisition and purchase order approval workflows will look to the default approval hierarchy, searching for the current approver’s position in the hierarchy in order for the next approver in line to be located.
c) Transaction Type
For requisitions only, selects the Approval Transaction Type. If you have implemented Oracle Approvals Management, this selection associates the transaction type with the requisition document type. Leave the field blank to use the standard Oracle Purchasing approval logic
Share this:
Inventory Basic Setup steps
Step 1 Define Inventory Flexfield (Required)
Share this:
Purchasing Basic setup steps
Step 2 Set Up Key Flexfields (Required)
Step 3 Set Up Calendars, Currencies, and Set of Books (Required)
Step 4 Set Up Organizations (Required)
Step 5 Set Up Units of Measure (Required)
Step 6 Set Up Items
Define item attribute controls. (Required with defaults)
Define container type QuickCodes. (Required with defaults)
Define status. (Required with defaults)
Define item type QuickCodes. (Required with defaults)
Step 7 Set Up Personnel (Required)
Define employee QuickCodes. (Required with defaults)
Define supplier and employee numbering. For this step, Defining Financial
Options. (Required)
Define employees. (Required)
Define jobs. (Required)
Define positions. (Optional)
Define position hierarchies. (Optional)
Step 8 Set Up Oracle Workflow (Required)
Step 9 Decide How to Use the Account Generator (Required)
Step 10 Define Manufacturing System and User Profiles (Required)
Step 11 Open Inventory and Purchasing Accounting Periods (Required)
Step 12 Define Subinventory Locations (Optional)
Step 13 Set Up Cross-Reference Types
Tax Names, and Location Associations (Optional)
Step 14 Set Up Approval Information
Define approval groups.(Required)
Assign approval groups.(Required)
Fill employee hierarchy.(Optional)
Define document types.(Required with defaults)
Step 15 Set Up Lookups and Classes. (Required)
Define Purchasing lookups.(Required with defaults)
Step 16 Define Standard Attachments (Optional)
Step 17 Set Up Purchasing Flexfields (Required)
Step 18 Define Purchasing Options (Required)
Step 19 Define Buyers (Required)
Step 20 Define Items (Optional)
Step 21 Set Up Document Controls (Required with defaults)
Step 22 Set Up Financial Options (Required)
Step 23 Set Up Receiving Options (Required)
Step 24 Set Up Transaction Managers and Resubmission Intervals. (Required)
Start the following transaction managers.(Required)
Receiving transaction manager
Document approval manager
Step 25 Define Suppliers (Required)
Step 26 Start “Send Notifications for Purchasing Documents” Process (Required)
Step 27 Set Up Document Creation Options (Required with defaults)
Step 28 Set Up Approval Timeout Feature (Optional)
Step 29 Start Workflow Background Process (Optional)
Step 30 Modify Change Order Workflow Options (Optional)
Share this: