Back-to-Back Order – How to


Back-to-Back Order is very useful functionality in Oracle Applications.

Key Business Drivers

  • Data integration

  • Lower inventory cycle time

  • Lower inventory cost

  • Link supply to specific demand

  • Can offer a variety of product to customer

  • Used heavily in contract manufacturing environment where the product is standardized and the company plans to focus more on product design rather than manufacturing

Many times business suffers a loss when data is transferred between quotations, orders, purchase orders or invoices?

Damage to any business due to data loss or corruption is always very high. This can be due to a simple user error or data corruption. During the manual transfer of data, the input of incorrect information or staff errors are very real risks. This can have a profound impact as your business grows and staff are under more pressure to process orders in a market where the client expectation is no longer to have their order processed in days or hours but in real-time.

Back to Back order process allows you to process information and orders in very logical manner ensuring a simplistic and efficient process. The integration between quotations, order processing and stock management means that all orders can be processed in real time and you are no longer dependant on a manual process to be run.

e.g. When the PO is received, reservation gets applied automatically against the Sales Order. This prevents allocating material to some other demand.

The key behind the integration of a system is the ability to seamlessly integrate different pieces of information, this leads us to back-to-back order processing.

The key areas that are focused on as part of the back to back process are:-

  • Quotations

  • Orders

  • Requisition

  • Invoices (in ‘Oracle Accounts Payable’ and ‘Oracle Accounts Receivable’)

  • Purchase Orders

Back to back order processing provides an integrated seamless link from the quotation stage, through to the purchasing of stock (or services), to dispatching, delivering and invoicing your client and the receipt and payment of invoices. It is also extended to invoicing (against PO/receipt) and payment to your supplier. All this process is done using Oracle Work-Flow, standard work flow is given by Oracle but if you want you can modify the same to fulfill business needs. Approval processes are also taken care by Work-Flow.

The entire process can be performed in the minimal amount of time without any redundancy. Each document has reference of some other document so it doesn’t get lost in between. Below are the steps in Back to Back order.

  • Quotations are created and sent to the client.

  • The client places the order and all required acknowledgements are sent.

  • Requisitions / Purchase Orders are automatically created for the required stock.

  • Management of awaiting stock from suppliers.

  • Tracking and managing supplier and customer communication.

  • Receiving of stock and handling of part deliveries.

  • Dispatching the order to your customer with management of delivery locations and methods.

  • Customer Invoicing.

  • Supplier payment.

Some of the important documents that gets created automatically through the different stages in this cycle include (automatic creation of document/s depends on setup).

Quotations, Order Acknowledgements and confirmations, Invoices and Proforma Invoices, Purchase Orders, Stock Receipt Slips, Stock Transfer Slips, Dispatch Notes, Packing to name a few.

For demo please visit two links given below:

Advertisements

Oracle Timecard (OTL) Automation


Recently i have seen many requests for OTL timecard automations in Oracle. One of the reasons is the financial downturn in the martket.

Many companies have announced furlough for employees- meaning the offices and manufacturing units will be shutdonw for a specified amount of time and it will be mandatory for employees to either take that time off from their vacation time, flex time, may be borrow it from next year or simply be unpaid for that time period. Whatever be the case, it saves company a lot of money that it was otherwise obligated to pay in vacation time or paid days. Now because its mandatory, it has to be in the system for the payroll to pick it up.

If the organization uses time entry system – like oracle – to enter vacation/flex time, and processes payroll then following needs to happen in order for a succesfull furlough automation.

– Employees time must be entered on the online timecard.

– The timecard must be approved by manager or Auto-approval process.

– This OTL timecard must be transferred to Batch Element Entries for Payroll.

To automate this process we will use HXC Timecard APIs provided by Oracle. These APIs help us in creating a timecard for a day, week, and also attach elements/ projects to the timecard. Also, the APIs submit the timecard with a workflow process type so it can either be picked for AUTO processing or Manual approval.

Before we go into the details, we have to see how a typical timecard is built. For the sake of simplicity, we will consider Monthly Paid (exempt) employees.

A timecard is a combination of DAYS. Each DAY will be one Row in a table. For Every day that you need to enter time (e.g. Saturday Sunday will not need a time entry being a holiday) you need a DETAIL type row also. And, for each DETAIL record that has to go into an element or project for costing or payroll purpose, we need an ATTRIBUTE also.

These are nothing but the TIME BUILDING BLOCKS. To make things simple, lets go and see these records:

select * from hxc_time_building_blocks

TYPE: MEASURE ( Number of hours to be put in that particular day) or RANGE (For period like week or day).
SCOPE: TIMECARD, DAY, DETAIL or APPLICATION_PERIOD

Now, if you see a typical timecard, this is how it looks (Use the hierarchical Query below):

TIMECARD (12/1/2008  – 12/7/2008) TYPE: RANGE
|_  DAY (12/1/2008 – 12/1/2008) TYPE: RANGE
|_  DETAIL (12/1/2008):  8 HRS   (may have attributes)  TYPE:MEASURE
|_  DAY (12/2/2008 – 12/2/2008)
|_  DETAIL (12/2/2008):  8 HRS
|_  DAY (12/3/2008 – 12/3/2008)
|_  DETAIL (12/3/2008):  8 HRS
|_  DAY (12/4/2008 – 12/4/2008)
|_  DETAIL (12/4/2008):  8 HRS
|_  DAY (12/5/2008 – 12/5/2008)
|_  DETAIL (12/5/2008):  8 HRS
|_  DAY (12/6/2008 – 12/6/2008)
|_  DAY (12/7/2008 – 12/7/2008)

SELECT htbb.time_building_block_id, htbb.TYPE, htbb.measure, htbb.unit_of_measure, htbb.start_time, htbb.stop_time,htbb.parent_building_block_id, ‘N’ parent_is_new, htbb.SCOPE,htbb.object_version_number, htbb.approval_status,htbb.resource_id, htbb.resource_type, htbb.approval_style_id,htbb.date_from, htbb.date_to, htbb.comment_text,htbb.parent_building_block_ovn, ‘N’ NEW, ‘N’ changed,htbb.application_set_id, htbb.translation_display_key
FROM apps.hxc_time_building_blocks htbb START WITH ( htbb.time_building_block_id in (6848088) AND htbb.object_version_number in (1 ) )CONNECT BY PRIOR htbb.time_building_block_id = htbb. parent_building_block_id AND PRIOR htbb.object_version_number = htbb.parent_building_block_ovn ORDER BY htbb.time_building_block_id ASC

NOW Over to APIs….

hxc_timestore_deposit.create_timecard_bb
— Create a Timecard building block (only timecard, no days, or details)
— Here are the parameters it takes
(
p_start_time => to_date(’01-DEC-2008 00:00:00′,’DD-MON-YYYY HH24:MI:SS’) ,
p_stop_time =>  to_date(’07-DEC-2008 23:59:59′,’DD-MON-YYYY HH24:MI:SS’),
p_resource_id => emp.person_id ,
p_comment_text => ‘Automated TimeCard: DEC08’,
p_approval_style_id => 41, –This is your workflow approval style, default to AUTO APPROVE
p_app_blocks => l_tbl_timecard_info,
p_time_building_block_id => l_tc_bb_id –returns the id of  TC Building block
);

hxc_timestore_deposit.create_day_bb
— Creates a DAY building block (only DAY no details)
— Here are the parameters it takes
(
p_day => l_start_date,
p_parent_building_block_id => l_tc_bb_id,
p_comment_text => ‘Automated TimeCard: DEC08’,
p_app_blocks => l_tbl_timecard_info,
p_time_building_block_id => l_day_bb_id
);

hxc_timestore_deposit.create_detail_bb
— Creates a DETAIL building block, in next step we have to attach the attribute to this DETAIL
— Here are the parameters it takes
(
p_type => ‘MEASURE’,
p_measure => 8, –Number of Hours
p_parent_building_block_id => l_day_bb_id,
p_comment_text => ‘Automated TimeCard: DEC08’,
p_app_blocks => l_tbl_timecard_info,
p_app_attributes => l_tbl_attributes_info,
p_time_building_block_id => l_detail_bb_st_id
);
hxc_timestore_deposit.create_attribute (
p_building_block_id=> l_detail_bb_st_id,
p_attribute_name=> ‘Dummy Element Context’,
p_attribute_value=> ‘ELEMENT – 60110’, –This is the Accrual PTO Element we want to update through this API.
p_app_attributes=> l_tbl_attributes_info);

HXC_TIMESTORE_DEPOSIT.EXECUTE_DEPOSIT_PROCESS
–This is the Submission Call. This process will submit the timecard, days and details with attributes. Timecard will stay in SUBMITTED State until approved via Manual or AUTO Approve process.
(
p_validate => FALSE,
p_app_blocks => l_tbl_timecard_info,
p_app_attributes => l_tbl_attributes_info,
p_messages => l_tbl_messages,
p_mode => ‘SUBMIT’,
p_deposit_process => ‘OTL Deposit Process’,
p_retrieval_process => ‘BEE Retrieval Process’,
p_timecard_id => l_new_timecard_id,
p_timecard_ovn => l_new_timecard_ovn
);

Hope this article helped you in understanding the basics of the Time Entry APIs. Please note that this is  the initial and basic knowledge. You will need some more knowledge – like DELETE timecards API for rollback in case of any issues. UPDATE timecard APIs etc for a full fledge capability on OTL timecard automation.

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

 You will get the details of column values getting updated at different stages and table joins information at http://functionalguy.blogspot.com/2008/05/data-flow-for-order-to-cash-cycle.html

devendra gulve — Expert’s page – click here

special Thanks TO dEVENDRA gULVE ( http://functionalguy.blogspot.com/2008/05/data-flow-for-order-to-cash-cycle.html )

Thanks – Shivmohan Purohit