This Post is about Oracle applications RFQ to Receipt Cycle.In this Post I will explain the Cycle from RFQ to PO Receipt with screen shots.

High -Lights of this Cycle is  to Create:

  • RFQ
  • Quote
  • Purchase Order
  • Receive against PO.

Once RFQ is created , Submit concurrent job “Request to Print the RFQ” for a supplier. On completion this job will increment print count for that supplier as shown below.

In below  Oracle Apps UIs we can see
  1. RFQ # 308,
  2. Supplier Info from Supplier List and
  3. Price Breaks.
 
Print RFQ for all the Suppliers by means of Concurrent Program available in Oracle Apps


Once we print the RFQ , status of RFQ become Printed , and print count will increment for all suppliers .Since we got response from the Office Supplier , Inc Site – OFFICESUPPLIER , Responded field populated for this supplier only . 

  
 
From the RFQ , Select Tools > Copy Doc .It will Create Quotations as shown below.
  1. Enter the Supplier Name for whom you want to create Quote.
  2. Press OK and it will Create Quotation.
  1.  Query for Quotation # 502.
  2. Create Purchase Order Agreement from Quotation by selected Tools > Copy Doc
  3. Press Ok and it will Create Purchase Order Agreement. 
 Query for PO Agreement and Approve it
Once Oracle Purchase agreement got approved , creates the releases for Blanket PO Agreement .In our example PO Agreement Release we have item Test001 , BUT Item Test001 has restricted to be ordered from supplier from “Approval Supplier list”, and as  our Supplier is not part of any Approve Supplier list , system will throw Error.
 
For my test , I just remove the Item Test001 and Approve the Oracle Purchase Order Release and finally did the receipt against PO.

Back Orders

·         The Oracle “term” backorder is a “status” on the order line or delivery line indicating that you have tried to release an order for picking in your warehouse, but that the pick release was UNSUCCESSFUL because there was no available inventory.(Backorder can be partial or complete). The Oracle term backorder does NOT mean that you have open purchase orders for the out-of-stock item from your vendors.

·         The term backorder is also used in business a little differently than in Oracle. The term “An item is on backorder” usually means that the item is not in stock, but the shipping company has already placed purchase orders from their suppliers to restock the item.

·         Back Order is when you do not fulfill the Sales Order, or if the inventory is out of stock for delivery to customer.

Back to Back Orders (B2B)


In Drop-ship items are directly shipped to customer from the supplier and only logical receiving is performed in Oracle. In B2B orders items are physically received to Oracle from supplier and later they are shipped to customers.

Ex: When an order for Laptop is placed, you cannot send laptop and charger differently to the customer. If the company is not interested in maintaining the inventory of chargers, B2B is perfect solution as laptop charger order will go out when ever an order is created for laptop.And the charger is received to oracle and can be shipped with the Laptop.

Flow status code of the order line –FSC
Item reservation type ….IRT

1. Enter sales order …source code Internal
2. Book the order, at this time FSC – Supply Eligible
3. Perform progress order … and FSC –PO Req. Requested & IRT inventory
4. Req. Import –FSC –PO Req. Created & IRT external requisition
5. Auto Create PO –FSC – PO created & IRT PO order
6. Perform receiving transaction— FSC Awaiting shipping& IRT Inventory
After this complete the order as normal sales order.

Important Notes:
Items used in Back to back order should be ATO enabled, Build in WIP flag checked and in general planning set the Buy flag.
In B2B order at some point we will physically receive goods before shipping them out, where as in Drop ship goods are directly shipped to Customer
Drop ship order may connect to more than one PO but B2B is connected to single PO.

Batch Close Variances can occur in the following situations when using Actual Costing,
  • If the batch was released in one cost period and the debit to WIP is valued at one cost, but the batch was completed in a later cost period when the credit to WIP for the same quantities is valued at a different cost.
    This results in a left over balance WIP due to the cost change and must be cleared out.
  • Batch is released in one period and closed in the next period and has ingredient issues after last product yield and no product yield in next period.

  • When the Ingredient consumptions and product yields are recorded in a period, and in the next period the ingredient, resource, or byproduct consumptions for these batches are updated without any further product yields.
  • Ingredient issued in one period and returned back in next period with cost changes for ingredient across periods.
    – Essentially Ingredient/By-product transactions should be posted prior to product transactions in general, and certainly at least prior to last of product transaction so that such transactions do not contribute to batch close variance.

  • Cost Allocation factors on the Formula are not same as Cost Allocation Factors on the Batch Material details which could happen when using Dynamic Cost Allocation factors (profile option – GMF: Cost Allocation Factor Calculation – set to “Dynamic”)
    Any cost allocation factor change made after a Batch is released ( as it happens in case of dynamic cost allocation factors) would require re-layering.
    Re-layering these Batches followed by running the Actual Cost Process, Cost Update and OPM-Preprocessor will eliminate the Batch Close Variances for these Batches.

  • The profile option – ‘GMF: Batch Actual Cost Calculation Basis’ is set to ‘Use Virtual Incremental Backflush Quantities’ for a situation where on a Batch all the Ingredients and Resources are not issued out Upfront.
    Virtual Incremental Backflush is essentially designed to address a common situation in process industries where most or all ingredients are issued upfront and there are multiple product yields. 
    Without using the Virtual Incremental Backflush, the first yield would be posted at very high cost and subsequent yields would be posted at zero cost.
    With Virtual Incremental Back flush, costs are apportioned based on the Formula setup even before transactions occur.
    Thus if those transactions do not actually occur prior to batch close, Batch Close Variances would result.

  • Use of Virtual Incremental Backflush with consumption activity and cost changes for ingredients across periods.