Sunday, November 24, 2013

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
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. G
o 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

Friday, November 22, 2013

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?

 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?

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 
Asset-must NOT be enabled. 

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

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?

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?

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?

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?

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?

Release 11i does not currently support this functionality.

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

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?

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 ?

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?

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?

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?

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?

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

COGS Recognition Transaction does not have accounting in MTA table. (costed_flag is NULL)


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:


Select *
from cst_revenue_cogs_match_lines
Where cogs_om_line_id=&om_line_id;
check: Column = Unit_cost

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

Subledger Period close exception report shows unprocessed COGS recognition events.

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

Sales Order Line has non-zero quantity but COGS is showing zero quantity.

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;

Event_type = 1 (Sales Order Issue)
= 3 (COGs Recognition)
= 2 & 6 (RMA)

RMA Accounting

RMA accounting hits COGS some times and hits DCOGS sometimes.

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.

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;

If RMA is not referring to any Sales Order, then RMA accounting hits only COGS account.

Duplicate accounting

Duplicate accounting for COGS Recognition transactions.

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.

SELECT 3/4*SUM(NVL(ln.accounted_dr,0)-NVL(ln.accounted_cr,0)) ,
ln.accounting_class_code ,
(SELECT mmt.transaction_id ,
COUNT(mta.inv_sub_ledger_id) ,
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 ,

Accounting is duplicated 2 times in MTA and 4 times in XLA tables.


DCOGS account is not zero

Amount exists in DCOGS.

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

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.


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

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.


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 :
- 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

Thursday, March 24, 2011

OM White Papers

Oracle Order Management Suite White Papers - Set of white paper's which will address most of the Order Management Process. You should be having metalink access in order to download these docs.

Thanks & Regards,
S.Grace Paul Regan

Monday, April 7, 2008

Overview of Order Management in the Order to Cash Process

Order Management receives detailed item information from the Inventory application and price list information from the Pricing application. Orders and returns can be entered manually or imported through an EDI, CRM, or external source. Once in the system the order is ready to be pick released and shipped, if needed by the Shipping application. It can then proceed through the AutoInvoice program into the Oracle Receivables application to be invoiced. All of the accounting information is transferred to the General Ledger by the Inventory and Receivables applications.
Thanks & Regards,
S.Grace Paul Regan

Order to Cash Life Cycle

1--------Enter the Order----- Book-----------Pick Release-------------Ship Confirm----------2 2------- Auto Invoice----------Receivables-----------Invoice------------Receipt------------3-3--------Bank Reconciliation--------3
1. Create Unit of Measure
2. Create a Location
3. Create an Inventory Organization
4. Create a SubInventory
Enter Items:
5. Define Shipping Parameters
6. Create an Item
7. Create a Material Transaction
8. Add an Item to a Price List
Manage Parties and Customer Accounts:
9. Create customer Profile Class
10. Create Customer
11. Create a Customer Account
Enter Order:
12. Create a Sales Order
13. Create a Sales Line
14. Create a Split line and Ship Set
15. Schedule an Order
16. Book an Order
17. Pick Release
18. Ship ConfirmProcess
19. Create an Invoice
20. Process Invoices Using AutoInvoice
21. Enter a Manual Receipt
22. Apply a Receipt

Scheduling: Scheduling provides approximate ship date based on ATP (On-hand, expected supply and demand). Scheduling sets Schedule ship date and Arrival date ( for this Inter location transit time to be set).
Passes the demand to inventory. (Item attribute OE translatable to be enabled).
S.O line demand consumes item’s forecast. Can place reservation if SSD is with in the value of OM: Reservation time fence If product is available on-hand then Schedule ship date = requested date. If the item is non-ATP, then schedule ship date = requested date
OM: Auto schedule- profile option for automatic popup of scheduling window.
In order line, Tools – Scheduling – schedule, reserve, unreserved, reservation details.
In order TT- Scheduling level can be given.
Concurrent “ Schedule Orders” parameters : order number, request date, cust po no, ship to, customer, item.
OM: Schedule lines on hold- profile option to schedule hold lines.
OM: Scheduling role:
CSR only – (Customer service representative) In order organizer, tab scheduling is gray out.
CSR and scheduling – In order organizer all tabs are enabled. If u click (T) scheduling, then rest all the tabs will be gray out and vice versa. Scheduling across orders is possible.
Scheduler only – only (T) scheduling is enabled.
Note: Concurrent “ Reserve orders” to reserve orders.
OM: Source code – defaults to Order entry, OM passed to inventory during scheduling.
Item attribute reservable must be enabled.
Reservation puts soft pegging with the inventory.
Item reservation is removed after ITS.
Dates on Order line:
a) Request date
b) Promise date
c) Scheduled ship date
d) Scheduled arrival date
Price in order lines:
a) unit price/selling price - Price of each qty
b) extended price /line price – unit price x no of qty
c) List price – Price declared in price list
d) Modifiers – factors that change the list price.
e) Qualifiers – factors that qualifies the modifiers.
Order header: acts as primary source to lines, open until all lines are closed, Dependent of lines. They are OU specific.
Order lines: they are dependent on order header, multiple lines and org is possible. Lines takes precedence over header. They are org specific.
Order types:
a) BSA – Blanket sales agreement.
b) Sales order

Sales person: who is getting credited for sale. This is mandatory field.

Quota sales person – More than one sales person can be entered to divide the sales credit. Cumulative should be 100.
Non-Quota sales person – we can enter multiple sales person. But cumulative can be more than 100% eg: middlemen, agents.
Gross margin amount = Extended sales price – unit price. Gross margin hold can be set.

Thanks & Regards,
S.Grace Paul Regan.

Tuesday, January 1, 2008

Enter Sales Order

1. Transaction Types have been defined.
2. Customers exist in the Customer Master, including Contacts, Addresses, and Location
Business Purposes.
3. Price Lists have been defined.
4. Items have been defined in the Item Master and assigned to Price Lists.
5. Discounts have been defined and assigned to Price Lists.
6. Salespersons have been set-up.
7. Tax Codes and Tax Rates have been defined.
8. Invoicing and Accounting Rules have been defined.
9. Freight Carriers, Freight Terms, and FOB options have been defined.
10. Shipping Warehouses have been set-up.
11. Agreements have been defined (if Agreements functionality is required).
12. ATP Rules have been defined (if ATP functionality is required).
13. System Types have been defined (if Systems functionality is required).

Sales Orders Window
The Sales Orders window allows you to enter orders and returns.
The Main Tab region of the Sales Orders Order Information, enter the following:
Enter Customer Name (Customer Number will default in). Customers must first be setup in the Customer Master. If a Customer has not yet been setup, then navigate to the Customer Master either by selecting Quick Customer Entry from the Tools menu or go to full customer entry in Customers > Standard from the Navigator.
Customer Number:
Alternatively, enter Customer Number and the Customer Name will default in.
Order Type:
Select the appropriate Order Type. Order Type determines the order workflow, accounting rules, and other characteristics of the order.
Customer PO:
Enter the Customer Purchase Order Number. A customer purchase order number must be entered if the order type you specified requires a purchase order number. Oracle will give you a warning if the Customer Purchase Order Number has been previously used, but it will not prevent you from using a duplicate Customer Purchase Order Number.
Order Date:
The Current Date will default in as the Order Date. You may change this date.
Enter a Customer contact (optional). Contacts must also first be setup in the Customer Master and then selected from the List of Values. If a Contact has not yet been setup, then navigate to the Customer Master as described above, create the Contact, and then return to the Sales Orders Order Information form to select the Contact in this field.
Order Number:
Oracle will assign the Sales Order Number as soon as the Sales Orders Order Information is saved.
Select the Ship-To customer information. Defaulting rules may allow you to default ship-to address information when choosing the order type.
Select a Salesperson from a List of Values. The Salesperson entered in the Sales Orders Order Information form will receive 100 percent of the sales credit for the order. Sales credits may be apportioned to multiple sales persons in the Sales Credit window.
Select Currency:
Select a currency for the order. The currency selected must match the currency on your price list selected for this order.
Select the Bill-To customer information. Defaulting rules may allow you to default bill-to address information when choosing the order type.
Entry Status:
The initial entry status for a sales order is Entered. After Booking the order, the status will change to Booked.
The Others Tab region of the Sales Orders Order Information, enter the following:
Payment Terms:

Payment Terms are user-definable and must be set-up in advance (Setup >Orders > Payment Terms). Again, you may override the default value in this field.
Sales Channel:
Enter a Sales Channel. Sales Channels must be setup in advance in the Order Management Quick Codes and then may be selected from the List of Values.
Select a Warehouse (inventory organization) from which order line(s) will be shipped.
Shipping Method:
Select the Shipping Method to use for shipments to your customer.
Line Set:
Choose whether to ship lines as a group or to arrive as a group. All lines in the order that have the same ship set number will be shipped or arrive together. The lines must have the same warehouse, scheduled shipment date, ship-to location, shipment priority, and shipment method.
Freight Terms:
Select the Freight Terms. Freight Terms are setup in advance using Order Management QuickCodes.
Select the FOB point.
Shipment Priority:
Select a Shipment Priority. Shipment Priority may be used at Pick Release to prioritize picking. Additional shipment priorities can be defined in the Order Management Lookups window.
Shipping Instructions:
Enter special instructions to the Shipping Organization (Optional). These instructions will appear on the Pick Slip only.
Packing Instructions:
Enter special packing instructions. These instructions will appear on the Pack Slip.
Tax Handling:
Select a Tax Handling Status. The default is Standard Tax Handling. For a tax-exempt customer, create the tax exemption in the Setup > Tax > Exemptions form.
Tax Exempt Number:
If you select Exempt in the Tax Handling field, then you will need to select a Tax Exemption Certificate from the List of Values.
Exempt Reason:
As with the Tax Exempt Number, if you select Exempt in the Tax Handling field, then you will need to select a Tax Exemption Reason from the List of Values. These must first be setup in the Setup > Tax > Exemptions form.
Payment Type:
If the flag Agreement Required is checked on this Order Type, then an Agreement is required. More typically, an Agreement is optional. A Customer Agreement may be used to attach specific Price Lists, Discounts, Payment Terms, Invoicing Rules, and Accounting Rules for sales orders for particular customers or groups of customers. See the Creating and Using Customer Agreements Training document for more information.
The base currency for this sales order.
Price List:
The Price List used for this particular sales order. You may override the default in this field.
Invoicing Rule:
Invoicing Rules must be set at the order Header level and will be applied to all Lines except for Service Lines. The two Invoicing Rules delivered with R2i are Advance Invoice (in which invoicing will take place at the beginning of an invoicing schedule) and Arrears Invoice (in which invoicing will take place at the end an on invoicing schedule).
Payment Terms:
Payment Terms are user-definable and must be set-up in advance (Setup >Orders > Payment Terms). Again, you may override the default value in this field.
Payment Type:

Three Payment Types have been defined: Cash, Check, and Credit Card. If you enter Cash as the Payment Method, only the Amount field will be enabled in this region.
If you enter Check as the Payment Method, then the Amount and Check Number fields will be enabled.
If you enter Credit Card as the Payment Method, then the following fields will be enabled:

Amount, Credit Card Type, Credit Card Number, Card Holder, Expiration Date, and Approval Code. All fields allow free-form data entry except Credit Card which must be set-up with a List of Values in advance. R2i is delivered with the following Credit Cards defined: American Express, Discover, Mastercard, and Visa.
Order Source:

If this order is being imported form another source ( not being manually entered) that source will be identified in this field. This includes if the order is being copied from a previous order.

Line Items Tab

The Sales Orders Line Items Tab consists of the following tabs:
· Main
· Pricing
· Shipping
· Addresses
· Returns
· Services
· Other

In the Main Tab area of the Sales Order Line Item Information, enter the following:
Line Number: This will automatically default as 1.1 when the line information is first entered. If there are existing lines the line number will automatically increment by one.
Ordered Item:Enter the Ordered Item for this order line. Items must be setup in the Item Master and also on a Customer Price List before they may be selected in the Sales Order Line Item field.
Quantity:Enter the Quantity for this particular line item.
UOM:The Unit of Measure will default in form the Item definition.
Unit Selling Price:The Selling Price is the discounted price of the item.
Schedule Ship Date:Select the Schedule Ship Date from the calendar or use Scheduling functionality. See OM Schedule Order Training Documentation.
Line Type:Select or accept the default for Line Type.
Salesrep:Select or accept the default for Salesrep.
Tax Code:Select or accept the default for Tax Code.
In the Pricing Tab area of the Sales Order Line Item Information, enter the following:
Price List:Select a Price List for the order. The value for Price List will default from Sales Orders Order Information tab previously selected.
Unit Selling Price:Modify the Selling Price (Optional). The Extended Price will automatically default when the Unit Selling Price is updated.

In the Shipping Tab area of the Sales Order Line Item Information, enter the following:
Warehouse:This is the default Shipping Warehouse for all sales orders line item information.
Receiving Org:Enter the Receiving Inventory Organization. Only applicable for Drop Ship Orders and Return Material Authorizations (RMAs).
Request Date:The Current Date defaults in as the Request Date. Change it to the date the Customer would like the Product Shipped.
Promise Date:The Current Date defaults in as the Promise Date. Change it to the date the Customer has been promised for shipment date.
Source Type:Enter the Source Type for the item being shipped. If the item is to drop shipped the Source Type will be external. Otherwise the Source Type will default as internal.
Shipping Instructions:Enter special instructions to the Shipping Organization (optional). These instructions will appear on the Pick Slip only.

Packing Instructions:Optionally enter special packing instructions. These instructions will appear on the Pack Slip.

In the Addresses Tab area of the Sales Order Line Item Information, enter the following:
Ship-to Location:The customer’s primary Ship-to Location will default in from the Customer Master.
Bill-to Location:The customer’s primary Bill-to Location will default in from the Customer Master.
Ship-to/Bill-to Contact: (Optional) These default in from the Customer data. If the required contact has not yet been set-up, then they will first need to be created in the Customer Master, and then may be selected from the List of Values on this form.
If the customer has not selected a Bill-to and/or a Ship-to address as primary, then you will need to manually select addresses in this form.
If the required address has not yet been set-up, then navigate to the Customer Master either by selecting Quick Customer Entry from the Tools menu or go to full customer entry in

Customers > Standard from the navigator.
The Ship-to/Bill-to Locations set at the Sales Orders Order Information will default to Line Item Information. You have the option to override the Ship-to Location for individual lines on the order.

Additional Line Information:Active when at the Sales Orders Line Information window displays Holds, Return Activity, Deliveries, Receivables, Internal Requisition, Drop Ship and Quantity History.

Booking the Order
The final step in the Sales Order Entry process is to Book the order.
This signifies that the Order Entry process is complete and that the order is eligible for the next stage in the line flow for this order, as defined by its Transaction Type.
Select the Book Order button
The Entry Status of the Order will change to Booked.

Viewing Workflow Statuses and Processes
The Sales Orders window displays the order header status in the Main tab of the Order Information tabbed region. The order line status is displayed in the Main tab of the Line Items tabbed region.
The Workflow Status option on the Sales Order window Tools menu launches the workflow status page. The window shows in tabular format all the activities an order header or line has completed and the corresponding results. See the OM Order and Line Workflow Overview document for further details on Order Management Workflows.

Close the Order
Closing orders that are complete enhances performance, since many programs, windows and report queries retrieve open orders only. Orders marked as closed are not selected, increasing system speed and efficiency. Closed orders are excluded from many of the standard reports available in Order Management, so you can limit your reporting to the active orders.
Close lines and close orders are implemented using workflow. Order Management provides seeded close line and close order workflow sub-processes to close the order header and line, respectively. These processes, when included in the order header or line workflow, closes the status of the eligible order or lines. Once an order is closed, no lines can be added. The order header close order process checks at the end of every month to see all the lines associated with are closed. It closes the order header if it finds that all the lines are closed.
An order line is eligible to close when it completes all of the line-level activities within the workflow process. Order lines can close independent of each other. Once an order line is closed, no changes can be made to any fields except the descriptive flexfield, for which you can define processing constraints.
Note: Be sure to include the standard sub-processes of close line and close order at the end of all your line and order flows to ensure that your orders and returns close once all prerequisites have been met.

Thanks & Regards,

S.Grace Paul Regan.

Thursday, December 20, 2007

R-12 - Release Content Document (Order Management)

Order Management


Oracle Order Management drives the order fulfillment process of any business. The open,workflow based architecture supports tailored, automated fulfillment processes withoutcustomization. It captures multi-channel demand from sources including EDI, XML,telesales or web storefronts. As part of a complete order to cash solution it enables global order promising integrated to shipment execution


1. Multi-Organization Access Control
2.Inventory Convergence
3.Customer Acceptance
4. Mass Scheduling
5.Enhanced Header Attribute Cascading
6.Exception Management Enhancements
7.Workflow Validation Tool
8.Credit Card Security Code
9.Create Orders in Contact Center
10.Payment Due With Order
11.Recurring Charges
12.Telecommunications Service Orders with Equipment
13.Rosetta Native Message: PO Acknowledgements in Order Management
14.Scheduling ATO Items without BOM
15.Customer Credit Check Hold Source Support across Operating Units
16.Renaming Blanket Sales Agreements to Sales Agreements
17.Oracle Shipping Execution Changes

Thanks & Regards,
S.Grace Paul Regan.