FAQ - Internal Requisition (IR) Internal Sales Order (ISO) - Internal Requisition Change Request

1. When the change from the internal requisition is accepted, who receives the
    notification?
A: The notification is sent to the planner when using Available to Promised (ATP) in the IR-ISO process.

2. Which Workflow process is involved on the IR change?
A: The workflow processes are the same as from the supplier/external requisitions change process: POREQCHA and REQAPPRV.

3. How to get the Internal Requisition Workflow Process statuses.
A: To get the IR workflow statuses execute:
SQL> select  wf_item_type, wf_item_key  from po_change_requests where document_type = 'REQ' and document_header_id = in (select requisition_header_id from po_requisition_headers_all
where segment1 = '&requisition_number');

Replace by the requisition number. Go to $FND_TOP/sql

SQL> @wfstat.sql Replace from previous query. Output shows the activity statuses from the workflow process POREQCHA - PO Requisition Change Request.

4. Where in the Workflow the notification is sent to the planner.
A: The activity sending the notification is: Main Requisition Change Approval/Send internal change notifications.

5.  Sometimes the change in the requisition is not allowed.
A: See Note 1357959.1 - IR - ISO: In Which Conditions Internal Requisition With Internal Sales Order Changes Are Not Allowed. The note lists the conditions where the IR-ISO Change Management is not allowed.

6. Can I start the change request from core form requisition?
A: The change request can be started from core requisiton form. Query the internal requisition which is with a Sales Order. Click Tools in the top menu. Then, choose  Change. The iProcurement change order page will show to enter the changes.  iProcurement needs to be installed in order to execute the change request process from core requisition.

8. Can I execute the change request in an internal requisition without iProcurement license?
A: The internal requisition change request is a feature available from iProcurement. Thus, iProcurement needs to be licensed and configured in the instance in order to execute a change request with IR-ISO.  
Thanks & Regards,
S.Grace Paul Regan
 

FAQ: Oracle Order Management Drop Ship Purchase Orders

Q1. What is a Drop Ship PO?

A: Oracle Order Management and Oracle Purchasing integrate to provide Drop Shipments. Drop Shipments are orders for items that your supplier ships directly to the customer either because you don't stock or currently don't have the items in inventory, or because it's more cost effective for the supplier to ship the item to the customer directly. Drop Shipment was introduced in R11.

Q2. How is a Drop Ship PO created?

A: Drop Shipments are created as Sales Orders in Order Management. The Purchase Release concurrent program or workflow in Order Management creates rows in the Requisition Import tables in Purchasing. Then Purchasing's Requisition Import process creates the requisitions. Drop Shipments are marked with the Source Type of External in Order Management and Supplier in Purchasing.

Q3. What is the setup required for Drop Ship PO?

A: ITEM ATTRIBUTES: 
Navigate: Inventory -> Items - > Organization items 
Purchased (PO) Enabled 
Purchasable (PO) Enabled 
Transactable (INV) Enabled 
Stockable (INV) Optional 
Reservable (INV) Optional 
Inventory Item (INV) Optional 
Customer Ordered (OM) Enabled 
Customer Orders Enabled (OM) Enabled 
Internal Ordered (OM) Disabled 
Internal Orders Enabled (OM) Disabled 
Shippable (OM) Optional 
OE Transactable (OM) Enabled 
All Drop Ship items must be defined in the organization entered in the profile option OE: Item Validation Organization and in the Receiving Organization. 
All Drop Ship sub-inventory must have Reservable box checked. If the sub-inventory is not Reservable the Sales Order issue transaction will not be created in MTL_TRANSACTIONS_INTERFACE. After Drop Ship inventory organization is created, subinventories should be defined. To create the subinventory, go to an inventory responsibility and navigate to Setup -> Organizations -> Subinventories. Asset subinventories must have the reservable and Asset boxes checked. Expense subinventories must have the Reservable box checked and the Asset box unchecked. 
Subinventory Attributes for Asset Subinventory 
Reservable/Allow Reservations 
Asset Subinventory 
Subinventory Attributes for Expense Subinventory 
Reservable 
Asset-must NOT be enabled. 

Q4. How can we avoid the miscounting of supply as logical organization is involved?

A: You must receive drop-ship items in a logical organization. If you use Oracle master Scheduling/MRP and Oracle Supply Chain Planning, to avoid miscounting supply you may not want to include logical organizations in your planning. If you choose to include logical organizations, ensure that doing so does not cause planning and forecasting complications.

Q5. If you make changes to a Sales Order after the Purchase Order (PO) has been generated, will the order changes automatically be updated on the PO?

A: Order changes will not be automatically updated on the PO. Pulling up the Discrepancy report will allow you to view the differences between the Sales Order and PO. However, you will have to manually update the POs in the Purchasing application. Please note: Sales Order changes will be automatically updated on the PO if the PO Status is Incomplete or Require Re-approval. If the PO is already approved, you cannot make changes to the Sales Order line (without un-approving the PO).

Q6. If items on a Drop Ship order are cancelled, does the system automatically generate a PO Change to the PO originally sent to the supplier?

A: No, Drop Ship functionality in this regard remains the same as in R11. There is a discrepancy report available that will report differences between the PO and the Sales Order.

Q7. Does Order Management 11i have functionality to do serial number management with Drop Shipments?

A: You are able to receive serial numbered Drop Ship stock. Order Management will receive the serial number noted on the PO.

Q8. Can Configurable Items be Drop Shipped?

A: Currently only Standard Items can be Drop Shipped. Functionality for Configurable Items will be added in future releases.

Q9. How do I Drop Ship across operating units?

A: Release 11i does not currently support this functionality.

Q10. How are over/under shipments handled in Drop Shipment?

A: If part of a drop-ship line ships, and you do not wish to fulfill the remaining quantity, cancel the line. Over shipments must also be handled manually. If the supplier ships more than the ordered quantity, you can bill your customer for the additional quantity or request that they return the item. Use the Drop Ship Order Discrepancy Report to view differences between your drop-ship Sales Orders and their associated purchase requisitions and orders.

Q11. Will Blanket PO's work with Drop Shipment?

A: Blanket PO's will not work with Drop Shipment because the PO must be created when OM notifies PO that a Drop Ship order has been created. This PO is linked to the Drop Ship order so that when the receipt is done (partial or complete) .OM is updated to receiving interface eligible. Drop Ship lines do not use the pick release, ship confirm or inv interface order cycles.

Q12. Is it possible to create releases based on drop shipment orders for the items in the blanket agreement when a valid Blanket PO is created ?

A: Yes, it is possible to create releases from drop ship orders automatically or via Autocreate window, if the drop ship Requisition has the correct Blanket Information (Source)

1.Set up the ASL entry for the supplier site desired.
2.Depending on the hierachy determine which assignment  better suits and define sourcing rule according to the required level with   the required supplier,site. 

Also ensure that ASL entry exists for the above supplier/site.

For automatic sourcing to be done also set profile  'PO:Allow Automatic Sourcing' to Yes so that the source document will be determined automatically depending on the creation dates and the type of the document.

Q13. Can we cancel Drop Shipment after it is received?

A: Drop Shipments cannot be cancelled once Oracle Purchasing obtains the receipt. A user who wants to cancel a Drop Ship Sales Order line must ensure no receipts have been created against the line and that the requisition and/or Purchase Order associated with the line is cancelled. Cancellation of a Partial Drop Ship receipt is allowable. But only the portion that has not been received can be cancelled. If you cancel a Drop Shipment line for which you have not shipped the entire quantity, the order processing splits the line. The first line contains the quantity shipped and the second line contains the non-shipped quantity in backorder. You can cancel the second line the backorder on the Sales Order. The PO line quantity should be changed to reflect the new quantity.

Q14. What debugging tools are available for Drop Shipments?

A: 1. Note 133464.1 contains a diagnostic script that can be used for troubleshooting problems with Sales Orders.
2. Debugging receipt transaction or the Sales Order issue transaction, Set the following profile options:
RCV: Processing Mode to Immediate or Batch
RCV: Debug Mode to Yes
OM: Debug Level to 5
INV: Debug Trace to Yes
INV: Debug level to 10
TP: INV Transaction processing mode to Background
-Then go to Sys Admin: Concurrent: Program: Define; query up the Receiving Transaction Processor and check the Enable Trace box.
-Save the receipt for the deliver transaction (destination type will say Inventory for the deliver transaction).
-View the Receiving Transaction Processor log file, the Inventory Transaction Worker log file, as well as, the trace for the errors.

Q15. What is the Import source and status of PO generated from Drop Shipment?

A: Import source is Order Entry.
Status of PO will always be Approved.

Q16. Can we receive a PO Shipment for which the related Sales Order Line is Cancelled / Closed?

A: PO Shipments for which the relates Sales Order line has been cancelled or closed cannot be received. The PO shipment should be cancelled. A new Sales Order Line should be created, if needed. 

Thanks & Regards,

S.Grace Paul Regan

COGS/ Deferred COGS common problems

No Accounting for COGS Recognition Transaction Symptom:- COGS Recognition Transaction does not have accounting in MTA table. (costed_flag is NULL) Explanation:- If quantity or cost of the item is zero, then COGS Recognition transaction does not have any accounting. According to the standard functionality, When the transaction value is zero no accounting will be created. COGS recognition is like redistributing expense across DCOGS and COGS. If there is no expense to be distributed at all (zero cost), creating zero dummy accounting entries among two expense accounts would be a waste and hurting performance unnecessarily as well. So if the item is having zero cost then COGS journals will not be populated. Use below queries for verification: 1. Select * from cst_revenue_cogs_match_lines Where cogs_om_line_id=&om_line_id; check: Column = Unit_cost 2. Select * from cst_cogs_events Where cogs_om_line_id=&om_line_id; Here refer cogs lines (i.e., event_type = 3 ) quantity i.e., event_quantity. To get sales order line id use below query Select trx_source_line_id "om_line_id" from mtl_material_transactions Where transaction_id=&transaction_id; /* Use COGS Recognition or SO Issue transaction */ Subledger Period close Exception report Symptom:- Subledger Period close exception report shows unprocessed COGS recognition events. Explanation:- If COGS Recognition transaction has zero quantity or zero cost, MTA does not exists but XLA_events data exists. This issue is fixed in COGs code, but if ct. has older version then ct. has to apply datafix. Review Note 738529.1 for more detail For root cause fix, apply latest patch on CSTRCMVB.pls file. COGS Recognition Transaction with 0 quantity Symptom:- Sales Order Line has non-zero quantity but COGS is showing zero quantity. Explanation:- If RMA exists before COGS Recognition then COGS Recognition transaction quantity = Sales Order issue quantity - RMA quantity. Verify the data in CST_COGS_EVENTS table Select * from cst_cogs_events Where cogs_om_line_id= &om_line_id; Note:- Event_type = 1 (Sales Order Issue) = 3 (COGs Recognition) = 2 & 6 (RMA) RMA Accounting Symptom:- RMA accounting hits COGS some times and hits DCOGS sometimes. Explanation:- This depends on when RMA is created i.e., before COGS Recognition or after COGS Recognition. If RMA is created before COGS Recognition then RMA hits DCOGS account. If RMA is created after complete COGS Recognition then RMA hits COGS account. Partial COGS Recognition then RMA hits both COGS & DCOGs accounts based on COGs recognition percentage. Refer to Oracle Cost Manager User Guide - Revenue and COGS Matching chapter - Supported Business Scenarios Scenarios of DCOGS account: Case 1: Transaction Type      Debit      Credit =================        ===== Sales Order Issue     DCOGS   INV COGS Recognition      COGS    DCOGS DCOGS balance will be cleared after COGS Recognition. Case 2: Transaction Type      Debit      Credit =================         ===== Sales Order Issue     DCOGS    INV RMA(Before COGS Rec.) INV     DCOGS DCOGS balance will be cleared after RMA. Case 3: Transaction Type      Debit      Credit =================         ===== Sales Order Issue     DCOGS   INV COGS Recognition      COGS    DCOGS RMA(After COGS Rec.)  INV     COGS DCOGS balance will be cleared after COGS Recognition. Queries select trx_source_line_id "rma_line_id" from mtl_material_transactions where transaction_id=&transaction_id; /* Use RMA Receipt */ select reference_line_id "om_line_id" from oe_order_lines_all where line_id=&rma_line_id; select * from cst_cogs_events where cogs_om_line_id=&om_line_id; Note:- If RMA is not referring to any Sales Order, then RMA accounting hits only COGS account. Duplicate accounting Symptom:- Duplicate accounting for COGS Recognition transactions. Explanation:- This happens when Cost manager and Generate COGS Recognition events programs run in parallel. Issue has been fixed and latest patch is recommended for root cause fix. For old data, ct. has to do manual GL adjustments. Queries- SELECT 3/4*SUM(NVL(ln.accounted_dr,0)-NVL(ln.accounted_cr,0)) , ln.accounting_class_code , ln.code_Combination_id FROM (SELECT mmt.transaction_id , COUNT(mta.inv_sub_ledger_id) , SUM(mta.base_transaction_value) FROM apps.mtl_material_transactions mmt , apps.mtl_transaction_accounts mta WHERE mmt.organization_id = &org_id AND mmt.transaction_type_id = 10008 AND mmt.transaction_date BETWEEN to_date('&from_date','DD-MM-YYYY') AND to_date('&to_date','DD-MM-YYYY') + .99999 AND mmt.transaction_id = mta.transaction_id AND mta.accounting_line_type = 36 AND mta.cost_element_id =1 GROUP BY mmt.transaction_id HAVING COUNT(mta.inv_sub_ledger_id) > 1 ) list , xla_transaction_entities_upg xte , xla_events xe , xla_ae_headers hr , xla_ae_lines ln WHERE xte.ledger_id = &ledger_id AND xte.application_id = 707 AND xte.entity_code = 'MTL_ACCOUNTING_EVENTS' AND NVL(xte.source_id_int_1, -9999) = list.transaction_id AND xe.application_id = 707 AND xte.entity_id = xe.entity_id AND hr.application_id = 707 AND ln.application_id = 707 AND hr.event_id = xe.event_id AND hr.ledger_id = xte.ledger_id AND hr.ae_header_id = ln.ae_header_id GROUP BY ln.accounting_class_code , ln.code_Combination_id; Note:- Accounting is duplicated 2 times in MTA and 4 times in XLA tables. Also review DUPLICATE COGS RECOGNITIONS TRANSACTIONS DCOGS account is not zero Symptom:- Amount exists in DCOGS. Explanation:- Get the output of COGS queries and also output of COGS Revenue Matching Report. Take sample Sales Order/Sales Order Line. Check whether COGS is not recognized. If COGS event/transaction is not created, please check whether revenue information exists in CRRL table or not. If CRRL data does not exist, verify revenue recognition. If not done, do revenue recognition and then run Collect Revenue Recognition Information & Generate COGS Recognition Events programs. If COGS event/transaction exists but still having balance then check whether COGS is recognized fully or not. Also verify whether cogs event/transaction is costed or not 7] COGS Revenue Matching Report Symptom:- a. COGS Revenue Matching Report Performance issue. b. Displaying rows even though cogs & revenue are matching. c. Not displaying quantity correctly. d. RMA accounting does not have credit lines. Explanation:- Apply latest patch. R12 = Patch 13437574:R12.BOM.A to update file to latest version CSTRCMVB.pls 120.37.12000000.51 or higher 12.1 = Patch 13948107:R12.BOM.C file version CSTRCMVB.pls 120.45.12010000.63 or higher 8. In order to recognize revenue for the Cost of Goods Sold and Deferred Cost of Goods Sold, the following steps need to be performed: Run these AR steps: Run autoinvoice and generate the invoice transaction. Run Revenue Recognition Master Program and generate the AR revenue recognition Then the remaining steps: Record Order Management Transactions Collect Revenue Recognition Information Generate COGS Recognition Events ---------------------- A) Once Invoice is created,     Recognize the revenue in AR >     Navigate to : Accounts Receivables>Control>Run Revenue Recognition request B) After recognizing the revenue, accept it.     Navigate to : Accounts Receivables>Control>Revenue Accounting>Enter reference number: SO (ie.SO Number)Manage Revenue>Schedule Revenue C) 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.    4. When querying for COGS Recognition Transactions :           a. Navigate to Inventory > Transactions > Material Transactions           b. Select the 'Include Logical Transactions' checkbox in the Find Material Transactions Form when running your query and the query will return 3 transaction types:                     1) Sales Order Pick                     2) Sales Order Issue                     3) COGS Recognition           c. While on the Sales Order Issue transaction line, select the Distributions button.  Distributions are shown for Inventory Valuation and Deferred Cost of Goods Sold.           d. While on the COGS Recognition transaction line, select the Distributions button. Distributions are shown for Deferred COGS and COGS.   - Cost > View Transactions > Material Transactions       -- Please ensure all the steps are performed and check to see whether COGS Recognition transactions are generated. If you forgot to run COGS Recognition processes and  INV and GL periods are closed,  the COGS Recognition would go to the next open period . The above details are posted from the Oracle Support Document (Doc ID 1314335.1), People having access to Oracle Support can refer the Original document from metalink. Thanks & Regards, S.Grace Paul Regan +965-97100377

Deferred COGS Accounting 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. 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 is no deferred COGS.

Set Up 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 ) 

Thanks & Regards,

S.Grace Paul Regan