How to Adjust Average Cost with Invoice Price Variances (IPV)

If you want to get your inventory cost, and ultimately your cost of goods, to reflect the actual cost you paid for your items, then you will want to interface the Invoice Price Variance (IPV) from Oracle Payables to Oracle Inventory/Cost Management.  The ability to perform this update of inventory cost is only for inventory organizations using the average cost costing method.  To understand this process, let’s look at the flow of cost from PO receipt to Transfer of Invoice Variances.  Here’s an overview of each step:

1.       Create and approve a PO

2.       Receive the item

3.       Enter and match an AP invoice (release any holds if necessary)

4.       Generate accounting for the AP invoice

5.       Transfer invoice variances to Inventory

Step 2 in the process (PO receipt) sets the initial average cost.  This cost will be used on all issues or shipments out of inventory.  Remember in average costing, we receive at PO price and issue out at average.

Once steps 3 (enter and match an AP invoice) and 4 (generate accounting) are complete, we are ready to run the Transfer Invoice Variance to Inventory program.  You can run the program from Cost Management for one inventory organization at a time.  This program will sum the difference between the invoice price and the PO price for each item/organization combination and then create an average cost update transaction.  This transaction will have an amount but not a quantity.  This amount is then applied to the remaining inventory on-hand.  So let’s look at a couple of examples and how your average cost will change.

Example 1:

• PO Price $10
• Receipt Quantity 100
• Invoice Price $12
• On-Hand 100
• Beginning Average Cost $10
• Ending Average Cost $12

In this example, we will apply the IPV of $2 to all 100 units in inventory.  So the average cost before the IPV transfer is $10 and the average cost after the IPV transfer is $12.  This would correctly value our inventory at actual cost.

Example 2:

• PO Price $10
• Receipt Quantity 100
• Invoice Price $12
• On-Hand 10 (sold 90 units)
• Beginning Average Cost $10
• Ending Average Cost $30  (($200/10) + $10 = $30

In this example, we will apply the IPV of $2 to remaining 20 units in inventory.  So the average cost before the IPV transfer is $10 and the average cost after the IPV transfer is $30.  This would result in lower margins the next time we sell and ship this item.

Example 3:

• PO Price $10
• Receipt Quantity 100
• Invoice Price $12
• On-Hand 0 (sold 100 units)
• Beginning Average Cost $10
• Ending Average Cost $10

In this example, we wouldn’t apply the IPV of $2 because the on-hand quantity is zero.  So the average cost before the IPV transfer is $10 and the average cost after the IPV transfer would also be $10.

Journal Approval

FAQs About Journal Approval

Questions and Answers

Can the preparer of the journal batch approve the journal?

Yes, preparer can approve the journal when below two conditions are met
1. When the Journals: Allow Preparer Approval profile option is set to ‘Yes’
2. Preparer authorization limit is more than maximum absolute amount of journal batch

Preparer authorization limit can be obtained using below query

R11:
SELECT nvl(authorization_limit, 0)
FROM GL_AUTHORIZATION_LIMITS a, fnd_user b,gl_set_of_books c
WHERE a.employee_id = b.employee_id
AND a.set_of_books_id =c.set_of_books_id
And b.user_name=’&peparer_id’
And c.name=’&set_of_books_name’;

R12:

SELECT nvl(authorization_limit, 0)
FROM GL_AUTHORIZATION_LIMITS a, fnd_user b,gl_ledgers c
WHERE a.employee_id = b.employee_id
AND a.ledger_id =c.ledger_id
And b.user_name=’&preparer_id’
And c.name=’&ledger_name’;

Maximum line amount of journal batch can be found using below query

SELECT max(abs(nvl(JEL.accounted_dr, 0) – nvl(JEL.accounted_cr, 0)))
FROM GL_JE_LINES JEL,
GL_JE_HEADERS JEH,
GL_JE_BATCHES JEB
WHERE JEH.je_batch_id = JEB.je_batch_id
AND JEH.je_header_id = JEL.je_header_id
AND JEH.currency_code <> ‘STAT’
And JEB.name=&journal_batch_name;

Is preparer same as creator of journal batch?

No, Preparer is the one who initiates the journal batch approval process and he/she need not be the journal
batch creator.

How to find supervisor of the user and the authorization limit of  the user and supervisor?

Use below query to get the user’s supervisor details and authorization limits of the user and his supervisor.
R11:
select a.user_name user_id ,b.full_name user_full_name,
c.d_supervisor_id supervisor_user_id ,
d.authorization_limit User_auth_limit ,
e.authorization_limit Supervisor_auth_limit
from
fnd_user a,
per_all_people_f b,
PER_ASSIGNMENTS_V7 c,
gl_authorization_limits_v d,
gl_authorization_limits_v e
Where a.employee_id=b.person_id
and b.person_id=c.person_id(+)
and a.employee_id=d.employee_id(+)
and c.supervisor_id=e.employee_id(+)
and a.user_name=’&preparer_id’;

R12:
select a.user_name user_id ,b.full_name user_full_name,
c.d_supervisor_id supervisor_user_id ,
d.authorization_limit User_auth_limit ,
e.authorization_limit Supervisor_auth_limit
from
fnd_user a,
per_all_people_f b,
PER_ASSIGNMENTS_V7 c,
gl_authorization_limits_v d,
gl_authorization_limits_v e
Where a.employee_id=b.person_id
and b.person_id=c.person_id(+)
and a.employee_id=d.employee_id(+)
and c.supervisor_id=e.employee_id(+)
and a.user_name=’&preparer_id’;

How to find all work flow notification details of specific journal batch?

Use below queries to find work flow activity status & notification details of the journal batch

select * from wf_notifications where notification_id in
(select notification_id from WF_ITEM_ACTIVITY_STATUSES where
item_type=’GLBATCH’ and item_key like ‘&je_batch_id%’ );

Select * from WF_ITEM_ACTIVITY_STATUSES where
item_type=’GLBATCH’ and item_key like ‘&je_batch_id%’;

je_batch_id can be obtained using below query
select je_batch_id from gl_je_batches where name=&je_batch_name;

What are different types of approver methods and how to set approver method?

There are 3 types of approver methods

1.Go Up Management Chain –Goes up in HRMS manager hierarchy
2.Go Direct —Goes directly to the person with authorization limit
3.One Stop Then Go Direct – Goes to the immediate manager then directly to the person with authorization limit

T

Journal Approval in General Ledger

1. Enabled Journal Approval in Ledger Setup (Accounting Setup)
2. Defined journal sources that require journal approval
3. Entered all employees who are involved in preparing and approving journal entries.
4. Create an approval hierarchy:
- If using a shared install of Oracle Human Resources, use the Enter Person form of GL to enter all employees who are involved and preparing and approving journal entries and batches
- If using a full install of Oracle Human Resources, enter employees in the People window from the Human Resources Responsibility (required)
- When entering employee, enter the employee’s supervisor or manager name (this is the default next approver for journal entries and batches)
5. Defined Journal authorization limits

6. Add journals and approve, notifications will sent to next approval (Supervisor)

Oracle Cost Management

Costing Reports and Reconciliation

Costing Reports and Reconciliation

When closing an accounting period the ‘Close accounting period’ concurrent process (INCTPC) is kicked off as well as the ‘Transfer transactions to GL’ concurrent process (INCTGL). The ‘Close accounting period’ process summarizes the costs related inventory and manufacturing activities for a given account period. The ‘Transfer transactions to GL’ process distributes those cost to the general ledger.

Oracle provides a variety of reports for evaluating current inventory quantity and value as well as reconciling inventory and manufacturing transaction to what has been transferred to GL for a given period. The following is a list of the costing reports that should reconcile if run with the correct parameters dependent on the organization set up:

Period Close Reconciliation Report:
(Available 11.5.10, Executable CSTRPCRE) This concurrent program and report is used to create summarized transaction records. It displays the differences between accounted value and inventory in the Discrepancy column. The inventory value is used as the baseline for calculation for the next period summarization values. The Period Close Reconciliation report can be run at any time during the period or automatically during the Period Close Process by setting the profile option CST:Period Summary to either automatic or manual. If it is generated for an open period, you are creating a simulation, or snapshot of the period. If the program is run for an accounting period that is not in a Closed status, the report reads directly from a temporary table, The simulation status is indicated in the report title. (See Note 295182.1)

Standard Costing Organization, PJM/WMS Not enabled:
-Period Close Value Summary
-Inventory Value Report
-Subinventory Account Value Report
-Elemental Inventory Value Report
-Transaction Historical Summary report

Average Costing Organization, PJM/WMS Not enabled:-Period Close Value Summary (for organization level balance only)
-Elemental Inventory Value Report – Average Costing
-All Inventory Value Report – Average Costing
-Transaction Value Historical Summary-Average Costing

FIFO/LIFO Costing Organization, PJM/WMS Not enabled:
-Period Close Value Summary (if there are no unsummarized intransit balance or layer cost update, for organization level balance only)
-Elemental Inventory Value Report-Average Costing
-All Inventory Value Report-Average Costing
-Transaction Value Historical Summary-Average Costing

Standard Costing Organization, PJM/WMS enabled:
-Period Close Value Summary – Warehouse Management
-Inventory Value Report – Warehouse Management
-Cost Group Account Value Report
-Elemental Inventory Value Report – Warehouse Management
-Transaction Historical Summary Report (for organization level balance only) with option value ‘Roll back to first Date’ set to the last day of the current period.

Average Costing Organization, PJM/WMS enabled:
-Period Close Value Summary – Warehouse Management
-Elemental Inventory Value Report – Average Costing
-All Inventory Value Report-Average Costing
-Transaction Value Historical Summary-Average Costing (if there are no intransit transactions in another organization that affects the intransit quantity in this organization)

FIFO/LIFO Costing Organization, PJM/WMS enabled:-Period Close Value Summary-Warehouse Management (if there are no un summarized intransit balance)
-Elemental Inventory Value Report-Average Costing
-All Inventory Value Report-Average Costing
-Transaction Value Historical Summary-Average Costing (if there is no intransit transactions in another organization that affects the intransit quantity in this organization)

Reconciling Reports

-When reconciling reports insure that the correct report is being used depending on the organizational set up. Some customers do use other report combinations to reconcile and in some cases this is acceptable.

-Make sure that the reports (other than the Period Close Value Summary (-Warehouse Management), the Transaction Historical Summary Report and the Transaction Value Historical Summary-Average Costing) are run after all the transactions in the current period are costed and before transactions in the subsequent period are created.

-Back Dating Transactions: Oracle does allow customer to back date transactions for their business needs. Customers need to understand that back dating transactions can affect the balance when doing reconciliation but reconciliation issues can be avoided when back dating transactions by utilizing the Cost Cut off field in the Organization Parameter screen insuring that back dated transactions are costed in the correct sequence. The issue with back dating transactions is explained in the “PERIOD CLOSE SUMMARY ALGORITHM” document available at the url:
Please Contact Oracle Support
To verify if there have been back dated transactions, the following script can be run to check the type of transaction the dates and the periods affected:

SELECT DISTINCT
mmt1.transaction_id,
mmt1.transaction_date,
mcacd1.transaction_costed_date,
mmt2.transaction_id,
mmt2.transaction_date,
mcacd2.transaction_costed_date,
mmt1.inventory_item_id,
mmt1.cost_group_id
FROM org_acct_periods oap,
mtl_material_transactions mmt1,
mtl_material_transactions mmt2,
mtl_cst_actual_cost_details mcacd1,
mtl_cst_actual_cost_details mcacd2
WHERE oap.acct_period_id = &acct_period_id
AND mmt1.transaction_date
BETWEEN oap.period_start_date
AND oap.schedule_close_date
AND mmt1.inventory_item_id = mmt2.inventory_item_id
AND mmt1.cost_group_id = mmt2.cost_group_id
AND mmt1.transaction_date < mmt2.transaction_date
AND mcacd1.transaction_id = mmt1.transaction_id
AND mcacd2.transaction_id = mmt2.transaction_id
AND mcacd1.transaction_costed_date >
mcacd2.transaction_costed_date

(Receipt transaction may appear to be back dated transactions because they will not be time stamped and TRANSACTION_DATE will be null)

-Data corruption where onhand quantity does not match with the values in the MTL_MATERIAL_TRANSACTIONS can also cause reports not to reconcile. The following scripts can be run in an 11.5.10 or higher environment to see if this type of data corruption exists:

SELECT TXN.inventory_item_id,
TXN.mmt_qty ,
ONHAND.qty
FROM (SELECT mmt.inventory_item_id ,
SUM(mmt.primary_quantity) mmt_qty,
mmt.organization_id
FROM mtl_material_transactions mmt,
mtl_system_items msi ,
mtl_secondary_inventories mse
WHERE msi.organization_id = mmt.organization_id
AND msi.inventory_item_id = mmt.inventory_item_id
AND msi.inventory_asset_flag = 'Y'
AND mse.secondary_inventory_name= mmt.subinventory_code
AND mse.asset_inventory = 1
AND mse.organization_id = mmt.organization_id
AND mmt.transaction_action_id not in (5,6,24,30,50,51,52,55,26,7,11,17,10,9,13,14)
AND nvl(mmt.logical_transaction,0) <> 1
GROUP BY mmt.inventory_item_id,
mmt.organization_id
)
TXN ,
(SELECT moq.inventory_item_id ,
SUM(moq.primary_transaction_quantity) qty,
moq.organization_id
FROM mtl_onhand_quantities_detail moq,
mtl_system_items msi ,
mtl_secondary_inventories mse
WHERE msi.organization_id = moq.organization_id
AND msi.inventory_item_id = moq.inventory_item_id
AND msi.inventory_asset_flag = 'Y'
AND mse.secondary_inventory_name= moq.subinventory_code
AND mse.asset_inventory = 1
AND mse.organization_id = moq.organization_id
GROUP BY moq.inventory_item_id,
moq.organization_id
)
ONHAND,
mtl_parameters mp
WHERE TXN.inventory_item_id = ONHAND.inventory_item_id (+)
AND TXN.mmt_qty <> NVL(ONHAND.qty,0)
AND mp.organization_id = &org_id
AND TXN.organization_id = mp.organization_id
AND ONHAND.organization_id = TXN.organization_id
AND NVL(mp.wms_enabled_flag,'N') = 'N';

How Subledger Accounting Event Classes Map to Inventory, Purchasing, and Cost Management Module Transactions

In Cost Management module, we have 31 event classes that can be divided into four categories.  The categories are material related, receiving related, work-order related, and write-off related.

Material Related Events

The material related events are based on transactions that can affect one or more of the following: an inventory item’s on-hand quantity, the inventory item’s value, or the inventory item’s item accounting.  The flow from the creation of the material transaction to the Subledger accounting has four steps.  The first step is the creation of the material transactions.  This step can be accomplished by using a form, by running a program or workflow, or by running an API.  In the second step of the flow, the Oracle Inventory module records material transactions in the Material Transaction form.  After the material transaction is recorded, the Cost Manager program performs the third step and calculates the cost and assigns the default accounting.  After the material transactions is costed and is assigned default accounting, the Create Accounting program creates the Subledger accounting entries.

Subledger Event Class	Transaction Entry Form or Program
Consigned Inventory Ownership Transfer	Consigned Transactions
Direct Interorg Receipt	Inter-organiztional Transfer
Direct Interorg Shipment	Inter-organiztional Transfer
Recipient-side Intransit Interorg Receipt for FOB Receipt	Receipt (internal order when the shipping network FOB terms = receipt)
Sender-side Intransit Interorg Receipt for FOB Receipt	Receipt (internal order when the shipping network FOB terms = receipt)
Intransit Interorg Shipment for FOB Receipt	Shipping  (internal order when the shipping network FOB terms = receipt)
Intransit Interorg Receipt for FOB Shipment	Receipt (internal order when the shipping network FOB terms = shipment)
Recipient-side Intransit Interorg Shipment for FOB Shipment	Shipping (internal order when the shipping network FOB terms = shipment)
Sender-side Intransit Interorg Shipment for FOB Shipment	Shipping (internal order when the shipping network FOB terms = shipment)
Intraorg Transfer	Subinventory Transfer
Internal Order to Expense	Shipping (internal order when the item is an expense item)
Logical Intercompany	Shipping or Receipt when intercompany transfer requires accounting entry but doesn’t require physical movement
WIP Material Lot	WIP Material Transactions
Miscellaneous	Miscellaneous Transactions
Material Cost Update	Average Cost Update, Standard Cost Update
PO Delivery into Inventory	Receipt (Receiving into an Asset Subinventory)
Retroactive Price Adjustment	Retroactive Price Update on Purchasing Documents
Sales Order Issue	Shipping (Ship confirm external  sales order)
User Defined Inventory Transaction Class	Based on transaction setups
WIP Material	WIP Material Transactions

Receiving Related Events

The receiving related events are based on transactions that affect the cost of a receipt, the accounting for the accrual of the receipt, and the initial accounting of the receipt from the supplier.

Subledger Event Class	Transaction Entry Form or Program
Delivery to Expense Destination	Receipt (Receiving into Expense Subinventory)
Landed Cost Adjustment to Delivery	TBD – New Module
Landed Cost Adjustment to Receipt	TBD – New Module
Period End Accrual	Period End Close Process
Receipt into Receiving Inspection	Receipt
Retroactive Price Adjustment to Delivery	Retroactive Price Update on Purchasing Documents
Retroactive Price Adjustment to Receipt	Retroactive Price Update on Purchasing Documents

Work-in-Process Related Events

The work-in-process related events are based on transactions that affect the value of the assembly as it moves through production.

Subledger Event Class	Transaction Entry Form or Program
WIP Absorption	Move Transactions
Outside Processing	Receipt (Outside Processing PO)
WIP Variance	Close Discrete Jobs, Period End Close for non-standard jobs
WIP Cost Update	Average Cost Update, Standard Cost Update
WIP Lot	Completion Transactions

Write-Off Events

The work-in-process related event uses the transactions generated from the Accrual Write-Off process.

How to Adjust Average Cost with Invoice Price Variances (IPV)

If you want to get your inventory cost, and ultimately your cost of goods, to reflect the actual cost you paid for your items, then you will want to interface the Invoice Price Variance (IPV) from Oracle Payables to Oracle Inventory/Cost Management.  The ability to perform this update of inventory cost is only for inventory organizations using the average cost costing method.  To understand this process, let’s look at the flow of cost from PO receipt to Transfer of Invoice Variances.  Here’s an overview of each step:

1.       Create and approve a PO

2.       Receive the item

3.       Enter and match an AP invoice (release any holds if necessary)

4.       Generate accounting for the AP invoice

5.       Transfer invoice variances to Inventory

Step 2 in the process (PO receipt) sets the initial average cost.  This cost will be used on all issues or shipments out of inventory.  Remember in average costing, we receive at PO price and issue out at average.

Once steps 3 (enter and match an AP invoice) and 4 (generate accounting) are complete, we are ready to run the Transfer Invoice Variance to Inventory program.  You can run the program from Cost Management for one inventory organization at a time.  This program will sum the difference between the invoice price and the PO price for each item/organization combination and then create an average cost update transaction.  This transaction will have an amount but not a quantity.  This amount is then applied to the remaining inventory on-hand.  So let’s look at a couple of examples and how your average cost will change.

Example 1:

• PO Price $10
• Receipt Quantity 100
• Invoice Price $12
• On-Hand 100
• Beginning Average Cost $10
• Ending Average Cost $12

In this example, we will apply the IPV of $2 to all 100 units in inventory.  So the average cost before the IPV transfer is $10 and the average cost after the IPV transfer is $12.  This would correctly value our inventory at actual cost.

Example 2:

• PO Price $10
• Receipt Quantity 100
• Invoice Price $12
• On-Hand 10 (sold 90 units)
• Beginning Average Cost $10
• Ending Average Cost $30  (($200/10) + $10 = $30

In this example, we will apply the IPV of $2 to remaining 20 units in inventory.  So the average cost before the IPV transfer is $10 and the average cost after the IPV transfer is $30.  This would result in lower margins the next time we sell and ship this item.

Example 3:

• PO Price $10
• Receipt Quantity 100
• Invoice Price $12
• On-Hand 0 (sold 100 units)
• Beginning Average Cost $10
• Ending Average Cost $10

In this example, we wouldn’t apply the IPV of $2 because the on-hand quantity is zero.  So the average cost before the IPV transfer is $10 and the average cost after the IPV transfer would also be $10.

How to make a Form as READ ONLY

Follow the following steps inorder to make a form as Query only/Read Only.

1. Login into the System Administrator/Application Developer responsibility.
2. Navigate to ‘Security -> Responsibility -> Define’
3. Query for the responsibility for which you want to make the form as ‘Query Only’ and copy the ‘Menu’ name.
4. Navigate to ‘Application -> Menu’ and query with the menu name which we got in step 3 in ‘User Menu Name’
5. Now look out for the form (Prompt) you want to make it as query only. Copy the value in the ‘Function’ field w.r.t the form that needs to be made as ‘Query Only’.
6. Navigate to ‘Application -> Funtion’ and query with the function name we got in Step 5 in ‘User Function Name’ field.
7. Identify the correct Function for your form and then naviagate to the ‘Form’ tab.
8. Enter the value: QUERY_ONLY=YES in the parameters section in the Form tab, if you already have another value existing in the parameter form then you need to seperate them with a space..

Example: MODE=”PROJECT” QUERY_ONLY=YES

FAQ on Oracle Workflow Background Engine

1. What is Workflow Background Engine?

2. How the Background Engine is called?

3. How to Run the Background Engine from Oracle Applications?

4. How to Run the Background Engine from SQL*Plus?

5. Why to run the Background Engine?

6. Is it necessary to schedule the Background Engine?

——————-

1. What is Workflow Background Engine?

The Background Engine is a PL/SQL procedure. The Background Engine checks for and executes any deferred or timed out activities that satisfy the arguments of the procedure at the time the procedure is invoked. If new activities are deferred or timed out after the initiation of the current Background Engine, the procedure will check one more time for any new activities to execute prior to ending. The procedure ends once all matching activities are executed.

 2. How the Background Engine is called?

Following is the Background Engine API which takes the mentioned parameters. WF_ENGINE.BACKGROUND( itemtype        in varchar2,

minthreshold    in number default null,

maxthreshold    in number default null,

process_deferred    in boolean default TRUE,

process_timeout    in boolean default TRUE)

3. How to Run the Background Engine from Oracle Applications?

Submit the Workflow Background Process Concurrent Program through

Navigate > Sysadmin > Request > Run

Item Type – Select the appropriate Item Type (say PO Approval)

Min and Max tershould – (specify 0 to 100 or you can leave it blank)

Defered = Yes (so that all defered activities are processed)

Timed out=Yes (so that all timedout activities are processed)

4. How to Run the Background Engine from SQL*Plus?

From SQL Prompt run the following command

SQL> EXEC WF_ENGINE.BACKGROUND

or from unix prompt

$ $FND_TOP/Admin/Sql/wfbkg.sql

5. Why run the Background Engine?

WF Engine does not handle all the activities. For the reasons like Timed Out, Defered or sometimes errored activities will be forwared to Workflow Background Engine. If that time the Workflow Background is not running then these process will be stuck in process only. Unless you start the Background these will not be processed. Even if you start the background engine with Defered = No and Timedout = No then also these will not be processed.

 6. Is it necessary to schedule the Background Engine?

In continuation to the above answer to to the Question 5, Workflow Background Engine will process the activities only which are forwarded by the Workflow Engine for reasons like timed out, defered etc. Once these activities are processed, the Workflow Background Engine goes down. You need to start the Workflow Background Engine again for any new activities which are forwarded. Therefore, it is usually recommended to schedule the Workflow Background Engine periodically especially for the Item Types such as PO Approval etc..

Data flow for Order-to-Cash cycle

Data flow for Order-to-Cash cycle  

Hello friends, here we are having one of the contribution from “Devendra Gulve” , very precise and useful explaination on O2C cycle. hope this be helpful to you.

For more details please visit http://functionalguy.blogspot.com

 

1. Order Entry
This is first stage, When the order is entered in the system, it creates a record in order headers and Order Lines table.

• Enter header details: Once you enter details on the order header and save it or move it to lines, record goes to one table oe_order_headers_all
  • No record exists in any other table for this order till now.
• Enter Line details for this order: Enter different item numbers, quantity and other details in line tab. When the record gets saved, it goes to one table. Order header details will be linked with line details by order HEADER_ID.

2. Order Booking
This is next stage, when Order is booked then the Flow status changed from Entered to Booked. At this stage, these below table get affected.

• oe_order_headers_alL
• oe_order_lines_all
• wsh_delivery_details
• wsh_delivery_assignments

*In shipping transaction form order status remains “Ready to Release”.

At the same time, Demand interface program runs in background and insert into inventory tables mtl_demand.

3. Reservation
This step is required for doing reservations SCHEDULE ORDER PROGRAM runs in the background and quantities are reserved. Once this program get successfully get completed, the mtl_demand and mtl_reservations table get updated.

4. Pick Release
Pick Release is the process of putting reservation on on-hand quantity available in the inventory and pick them for particular sales order.

Pick release can be done from ‘Release Sales Order’ form or ‘Pick release SRS’ program can be scheduled in background. In both of these cases all lines of the order gets pick released depending on the Picking rule used. If specific line/s needs to be pick release it can be done from ‘Shipping Transaction form. For this case Pick Release is done from ‘Release Sales Order’ form with Pick Confirm=NO.
Once pick release is done these are the tables get affected:

• If step 3 is not done then MTL_RESERVATIONS gets updated now.
• wsh_new_deliveries
• wsh_delivery_assignments
• wsh_delivery_details
• MTL_TXN_REQUEST_HEADERS
• MTL_TXN_REQUEST_LINES
• Mtl_material_transactions_temp
• MTL_SERIAL_NUMBERS_TEMP
• MTL_SERIAL_NUMBERS

*In shipping transaction form order status remains “Released to Warehouse” and all the material still remains in source sub-inventory. We need to do Move Order Transaction for this order. Till this no material transaction has been posted to MTL_MATERIAL_TRANSACTIONS

5. Pick Confirm/ Move Order Transaction

Items are transferred from source sub-inventory to staging Sub-inventory. Here material transaction occurs.

Order line status becomes ‘Picked’ on Sales Order and ‘Staged/Pick Confirmed’ on Shipping Transaction Form.

• MTL_MATERIAL_TRANSACTIONS_TEMP
• oe_order_lines_all
• MTL_MATERIAL_TRANSACTIONS
• mtl_transaction_accounts
• wsh_delivery_details
• wsh_delivery_assignments
• MTL_ONHAND_QUANTITIES
• MTL_SERIAL_NUMBERS_TEMP
• MTL_SERIAL_NUMBERS

* This step can be eliminated if we set Pick Confirm=YES at the time of Pick Release 

6. Ship Confirm
Here ship confirm interface program runs in background. Data removed from wsh_new_deliveries. 

The items on the delivery gets shipped to customer at this stage.

• oe_order_lines_all
• wsh_delivery_details
• WSH_SERIAL_NUMBERS
• mtl_transaction_interface
• mtl_material_TRANSACTIONS
• mtl_transaction_accounts
• mtl_demand, MTL_reservations
• MTL_ONHAND_QUANTITIES
• MTL_SERIAL_NUMBERS_TEMP
• MTL_SERIAL_NUMBERS

7. Enter Invoice 

After shipping the order the order lines gets eligible to get transferred to RA_INTERFACE_LINES_ALL. Workflow background engine picks those records and post it to RA_INTERFACE_LINES_ALL. This is also called Receivables interface, that mean information moved to accounting area for invoicing details. Invoicing workflow activity transfers shipped item information to Oracle Receivables. At the same time records also goes in the table RA_INTERFACE_SALESCREDITS_ALL which hold details of sales credit for the particular order.

ra_interface_lines_all (interface table into which the data is transferred from order management) Then Auto-invoice program imports data from this table which get affected into this stage are receivables base table. At the same time records goes in ra_customer_trx_all and ra_customer_trx_lines_all

8. Complete Line
In this stage order line level table get updated with Flow status and open flag.
oe_order_lines_all

9. Close Order
This is last step of Order Processing. In this stage only oe_order_lines_all table get updated. These are the table get affected in this step.

oe_order_lines_all

oe_order_HEADERS_all