Skip to main content

Order to Cash Process flow with Technical Details

Order to Cash Process

Order to Cash Transaction Flow
The end result will be a working Order to Cash Business Process.  The ability to take a Sales Order through the following phases: Entry, Booking, Shipping, and Invoice.  Showing the working steps through each phase.


The areas of focus are:
  • Required Setup
    • Create Customer
    • Create Item
    • Organization Overview
    • Available Inventory
    • Price List
    • Defaulting Rules
  • Create Order
  • Shipments
    • Pick Release
    • Ship Confirm
    • Interface Trip Stop (ITS)
  • Invoice
All users who wish to set up, troubleshoot or debug a basic Order to Cash cycle in Order Management (OM), that is to say from order creation to invoicing.
NOTE:  This flow is for a shippable item.  Please refer to the following Notes for additional flows:
  • Bill Only: How Do I Use Workflow Process, LINE FLOW - GENERIC, BILL ONLY WITH INVENTORY INTERFACE Note 1069241.1
  • Back to Back order: Back-to-Back Sales Order Cycle In Order Management Note 751325.1
  • Drop ship: Drop Ship Sales Order Cycle In Order Management Note 749139.1
  • ATO order: ATO Configuration Cycle In Order Management Note 844847.1
  • PTO order: PTO Configuration Cycle In Order Management Note 750059.1
  • Internal orders: Internal Sales Order Cycle In Order Management Note 744481.1

Order Entry Data and Workflow

When the order is entered in the system, it creates a record in Order Headers table: oe_order_headers_all and Order Lines table: oe_order_lines_all.  The header information is stored in OE_ORDER_HEADERS_ALL and the line information in OE_ORDER_LINES_ALL.  The column called FLOW_STATUS_CODE is available in both the headers and lines tables which tells the status of the order or line at each stage.

Enter header details:
Once you enter details on the order header and save it or move it to lines, a record is entered into table oe_order_headers_all with a flow_status_code = ENTERED, booked_flag = N, open_flag = Y.
No record exists in any other table for this order till now.
Enter Line details for this order:
Enter item number, quantity and other details in line tab. When the record is saved, it goes to into table oe_order_lines_all with flow_status_code = ENTERED, booked_flag = N, open_flag = Y.

Order header details will be linked with line details by order HEADER_ID.

Order Booking Data and Workflow

This is next stage, is Order Booking.  When the Order is booked the flow status changes from Entered to Booked. At this stage, these below table get affected.
  • oe_order_headers_alL (flow_status_code as BOOKED, booked_flag updated to Y)
  • oe_order_lines_all (flow_status_code as AWAITING_SHIPPING (as long as scheduling processed successfully), booked_flag updated Y)
  • wsh_delivery_details (DELIVERY_DETAIL_ID is assigned here, released_status ‘R’ ready to release, LINE_ID comes as SOURCE_LINE_ID)
  • wsh_delivery_assignments (DELIVERY_ASSIGNMENT_ID is assigned for DELIVERY_DETAIL_ID present in wsh_delivery_details, DELIVERY_ID remains blank till this stage)
  • Demand interface program runs in background and insert into inventory tables mtl_demand, here LINE_ID come as a reference in DEMAND_SOURCE_LINE.
In Shipping Transaction form order status shows as "Ready to Release".

Reservation Data and workflow

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

LINE_ID is updated in DEMAND_SOURCE_LINE_ID in both the tables.

Pick Release Data and Workflow

Pick Release is the process of putting a reservation on available on-hand quantity 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 are pick released depending on the Picking rule used.

If specific line(s) need to be picked, 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 reservations were not done then MTL_RESERVATIONS is updated, otherwise it was already updated in the Reservation process.
  • wsh_new_deliveries (one record gets inserted with SOURCE_HEADER_ID = order header ID, status_code = OP => open)
  • wsh_delivery_assignments (DELIVERY_ID gets assigned which comes from wsh_new_deliveries)
  • wsh_delivery_details (released_status ‘S’ ‘submitted for release’)
  • MTL_TXN_REQUEST_HEADERS
  • MTL_TXN_REQUEST_LINES (LINE_ID goes as TXN_SOURCE_LINE_ID)
  • Move order tables. Here request is generated to move item from Source (RM or FG) sub-inventory to staging sub-inventory.
  • Mtl_material_transactions_temp (link to above tables through move_order_header_id/line_id, this table holds the record temporally)
  • MTL_SERIAL_NUMBERS_TEMP (if item is serial controlled at receipt then record goes in this table)
  • MTL_SERIAL_NUMBERS (enter value in GROUP_MARK_ID )
In Shipping Transaction form order status remains "Released to Warehouse" and all the material still remains in source sub-inventory.

A Move Order Transaction is then needed to complete the material transaction into MTL_MATERIAL_TRANSACTIONS.

Pick Confirm/ Move Order Transaction

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

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

Once Pick Confirm / Move Order is complete, the following tables are affected:
  • MTL_MATERIAL_TRANSACTIONS_TEMP (Record gets deleted from here and is posted to MTL_MATERIAL_TRANSACTIONS)
  • oe_order_lines_all (flow_status_code ‘PICKED’ )
  • MTL_MATERIAL_TRANSACTIONS (LINE_ID goes as TXN_SOURCE_LINE_ID)
  • mtl_transaction_accounts
  • wsh_delivery_details (released_status becomes ‘Y’ => ‘Released’ )
  • wsh_delivery_assignments
  • MTL_ONHAND_QUANTITIES
  • MTL_SERIAL_NUMBERS_TEMP (record gets inserted after putting details for the item which are serial controlled at 'Sales order issue')
  • MTL_SERIAL_NUMBERS (record gets inserted after putting details for the item which are serial controlled at 'Sales order issue')
NOTE: This step can be eliminated if Pick Confirm = YES is set at the time of Pick Release.

Ship Confirm Data and Workflow

The items on the Delivery are shipped to the customer at this stage. 
Ship confirm is the process of confirming that items have shipped. When you ship confirm a delivery, Shipping Execution confirms that the delivery lines associated with the delivery have shipped.
Data is removed from wsh_new_deliveries.

The following tables are affected during Ship Confirm:
  • oe_order_lines_all (flow_status_code ‘shipped’)
  • wsh_delivery_details (released_status ‘C’ ‘Shipped’, SERIAL_NUMBER if quantity is ONE)
  • WSH_SERIAL_NUMBERS (records gets inserted with the DELIVERY_DETAIL_ID reference, only in case of shipped quantity is two or more)

Interface Trip Stop (ITS) Data and Workflow

The Interface Trip Stop-SRS process runs the interface to update Order Management sales order lines, initiates the generation of Departure Ship Notice Outbound (DSNO) generation, and calls a process to update Oracle Inventory. You can run this process one of two ways:
  1. Automatically: The request will be executed upon ship confirm if the delivery is not assigned to a trip, or the Defer Interface check box is not selected. If the delivery is assigned to a trip, the Interface Trip Stop concurrent request program will be run automatically when the destination Trip Stop is closed. If the delivery is not assigned to a trip, and at the time of ship confirm the Defer Interface is checked, the Interface Trip Stop concurrent request will be automatically run when the destination Trip Stop is closed.
  2. Manually: To manually execute the concurrent request, navigate to the Shipping Interfaces form and select Interface Trip Stop-SRS from the Name field. The parameters window will be displayed.
The following tables are affected during ITS:
  • mtl_transaction_interface
  • mtl_material_TRANSACTIONS (linked through Transaction source header id)
  • mtl_transaction_accounts
  • Data deleted from mtl_demand, MTL_reservations
  • Item deducted from MTL_ONHAND_QUANTITIES
  • MTL_SERIAL_NUMBERS_TEMP (records gets deleted from this table)
  • MTL_SERIAL_NUMBERS (Serial number stauts gets updated CURRENT_STATUS=4 , 'Issued out of store')
  • oe_interfaced_flag in WSH_DELIVERY_DETAILS will be updated with Y

Invoice Data and Workflow

After shipping the order, the order lines are eligible to be transferred to RA_INTERFACE_LINES_ALL.

Workflow background engine picks eligible records and post them to RA_INTERFACE_LINES_ALL with:
INTERFACE_LINE_CONTEXT = ’ORDER ENTRY’
INTERFACE_LINE_ATTRIBUTE1 = Order_number
INTERFACE_LINE_ATTRIBUTE3 = Delivery_id
and spawns Auto Invoice Master Program and Auto Invoice Import Program which creates Invoice for that particular Order.
This is also called Receivables interface, meaning information is moved to accounting area for invoicing details.

Invoicing workflow activity transfers shipped item information to Oracle Receivables.  At the same time records are populated into:
  • RA_INTERFACE_SALESCREDITS_ALL table.  This table will hold details of sales credit for the particular order.
  • ra_interface_lines_all (interface table into which the data is transferred from order management) 

Autoinvoice program imports data from this table which are staged into the receivables base table. At the same time records are populated into:
  • ra_customer_trx_all (cust_trx_id is primary key to link it to trx_lines table and trx_number is the invoice number)
    • The column INTERFACE_HEADER_ATTRIBUTE1 will have the Order Number.
  • ra_customer_trx_lines_all (line_attribute_1 and line_attribute_6 are linked to order number and line_id of the orders)
    • The column INTERFACE_LINE_ATTRIBUTE1 will have the Order Number.
The Invoice created can be seen using the Receivables responsibility.
Navigation: Receivables Super User> Transactions> Transactions.
Query with the Order Number as Reference.


Complete Line

In this stage order line level table get updated with Flow status and open flag.oe_order_lines_all (flow_status_code ‘shipped’, open_flag “N”)

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 (flow_status_code ‘closed’, open_flag “N”)
oe_order_HEADERS_all

References:
Order to Cash Advisor: E-Business Suite (EBS) Order Management (OM) (Doc ID 1485968.1)

Comments

Popular posts from this blog

How to compile all INVALID objects in Oracle

There are five ways to recompile invalid objects in schema. DBMS_DDL DBMS_UTILITY UTL_RECOMP UTLRP.SQL Manually Recompile > Best Approach 1. DBMS_DDL This procedure is equivalent to the following SQL statement: ALTER PROCEDUREFUNCTIONPACKAGE [.] COMPILE [BODY] Syntax Exec dbms_ddl.alter_compile ( type , schema, name); Type : Must be either PROCEDURE, FUNCTION, PACKAGE, PACKAGE BODY or TRIGGER. Schema : Database Username Name : Objects name Example SQL> exec dbms_ddl.alter_compile ('PROCEDURE','SCOTT','TEST'); PL/SQL procedure successfully completed. 2. DBMS_UTILITY This procedure compiles all procedures, functions, packages, and triggers in the specified schema. Syntax Exec dbms_utility.compile_schema ( schema,compile all) Schema : Database Username Compile All : Object type ( procedure, function, packages,trigger) Example SQL> exec dbms_utility.compile_schema('SCOTT'); PL/SQL procedure successfully co

How to setup and use AME - Approval Management Engine

Approval Management Engine - AME For Purchase Requisition Approvals Purchase Requisitions can be routed for approval using the AME Approval Management Engine. This whitepaper describes how to setup AME for use with requisition approvals, and shows how a requisition approval list is built based on the AME setup. Approvers in the AME based approver list are assigned to the requisition based on the AME rules setup for the Purchase Requisition Approval transaction. Similar setup can be done for Requester Change Order Approval and for Internal Requisition Approval, although those are not specifically covered in this whitepaper. The screenshots provided are based on 11i.AME.B, and some of the navigation details are specific to 11i.AME.B. However, most of the details provided are applicable to 11i.AME.A and higher including R12. Assign AME Roles and Responsibilities AME responsibilities in 11i.AME.A are assigned directly to the users. However, In R12 or 11i.AME.B and higher, AME respons

Workflow Important Debug Queries

deq_time is not always populated in WF_DEFERRED. The best way to monitor is to check if there are any READY events select msg_state,count(*) from applsys.aq$wf_deferred  group by msg_state; For getting Item_Type and Display name for Runnable processes. SELECT WFA_ACT.ITEM_TYPE ITEM_TYPE ,   WFA_ACT.NAME PROCESS_NAME ,   WFA_ACT.DISPLAY_NAME DISPLAY_NAME FROM wf_activities_vl wfa_act WHERE wfa_act.runnable_flag = 'Y' AND wfa_act. type            = 'PROCESS' AND sysdate BETWEEN wfa_act.begin_date AND NVL(wfa_act.end_date, sysdate); Query to find records that are pending in each of the workflow agent listener queues SELECT 'select ''' || t.component_name || ' (queue_table: ' || p.queue_table ||        ')''||'' Count: ''||count(*) c from ' || p.owner || '.' || .queue_table ||        ' where deq_time is null and nvl(delay,enq_time)<sysdate-1/24  ||        nvl2(t.correlation_id,