, , , ,

Oracle Back to Back Order in Order Management

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.

/by
, , , ,

What is Batch Close Variance in OPM?

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.
/by
, , , ,

What are all Oracle ASCP Plan Types?

In R12, you can launch three type of plans:

  1. Production Plan
  2. Manufacturing Plan
  3. Master Plan

For MPS Planning item level, you should run Production Plan

And for MRP Planning Item, you should run Manufacturing plan.

Please see the explanation from Dev in similar question from other customers in Oracle Technical forum:

“The below are the 3 plan types :
1. MPP (Master Plan)
2. MPS (Production Plan)
3. MRP (Manufacturing Plan)

A. In 11.5.9, we had three plan types: DRP (Distribution Plan), MPS (Production Plan) and MRP (Manufacturing Plan)

B. In 11.5.10, we had three plan types: MPP, MPS and MRP. We changed the DRP name to MPP.
Why? Because in R12, we introduced a new Distribution Planning engine and having the term DRP used for the old plan type would have caused more confusion than MPP.”

/by
, ,

Methods to Calculate Actual Cost in Oracle Apps

Following are actual cost calculation methods:

1. Period Weighted Average Cost (PWAC)

This is the strict average cost of the raw material during the period, based on the total estimated receipt (or invoiced) price for the entire inventory quantity. The period weighted average cost is a strict average cost for the period based on Period Total Quantity and Estimated or Final Prices.

PWAC is calculated by dividing — the sum of the transaction quantity multiplied by price — by the sum of transaction quantity, as shown in the following illustration:

the picture is described in the document text

Where:

Trans Qty – Receipt Quantities or AP interfaced quantities within the costing period

Price – Receipt estimated prices or AP invoice final prices within the costing period

2. Period Moving Average Cost (PMAC)

OPM calculates the average cost for the period while moving previous period’s cost with last period’s inventory balance and cost:

PMAC is calculated by dividing the result of — the quantity of the prior period inventory balance multiplied by the prior period cost, plus the sum of the transaction quantity multiplied by price — by the prior period inventory balance plus the sum of transaction quantity, as shown in the following illustration.

Where:

Prior Period Inv Balance – This is the prior period inventory balance captured from the inventory period ending balances.

Prior Period Cost – The prior period actual cost component from the cost component details table.

Trans Qty – Receipt Transaction Quantities or AP Interfaced Quantities within the costing period.

Price – Receipt estimated prices or AP invoice final prices within the costing period.

the picture is described in the document text

3. Perpetual Weighted Average Cost (PPAC)

The perpetual weighted average cost type computes the average cost for the entered receipts and quantities within the defined boundaries of the cost calendar. The calendar definition may in turn be identical to a fiscal year, or may span multiple fiscal years providing the flexibility of a variety of Perpetual Weighted Average cost methods.

PPAC is calculated by dividing — the sum of the transaction quantity multiplied by price — by the sum of transaction quantity, as shown in the following illustration:

the picture is described in the document text

Where:

Trans Qty – Receipt Quantities or AP interfaced quantities from the start of the costing calendar to the end of the current period.

Price – Receipt estimated prices or AP invoice final prices within the costing calendar.

Last Transaction Cost

There are two methods for determining last actual cost of a raw material:

LSTT – This method uses the last transaction within the costing period, regardless of whether the transaction is a receipt or an Accounts Payable invoice.

LSTI – This method uses the last Accounts Payable Invoice transaction within the costing period, even if there are latest receipts with estimated prices. In the absence of AP invoice transactions the latest receipt will be considered for the actual cost.

Last transaction cost adjustments will superseded any other transaction for the actual cost. For both methods, the adjustment unit cost is the actual cost.

Last Transaction (LSST) – OPM uses the last transaction in the costing period as the basis for the raw material cost (if there is no Accounts Payable invoiced cost for the period, the last receipt price is used to cost the raw material).

Last Invoice Transaction (LSTI) – OPM uses the last Accounts Payable invoice transaction in the costing period as the basis for the raw material cost, even if there are raw material receipt transactions that occur later in the period. If there are no Accounts Payable invoiced costs for the period, the last receipt price is then used to cost the raw material. Actual cost adjustments supersede any of the methods used to calculate actual cost – an adjusted cost is the actual cost.
/by
, ,

How to View/Access Other User Concurrent Request in Oracle Apps R12

When user OPERATIONS submit a request at System Administratorresponsibility, this user can see the log and output files of this request. But the other user (ex: SYSADMIN) cannot do that even has the same responsibility. If we use the View All Concurrent Requests (System Administrator Mode) form, we only can see the request but not the output file of this request.
So, if we want to access the request output of the same responsibility from another user’s requests, then we need to follow the below setup steps:
1. Login as SYSADMIN with Functional Developer responsibility and update the object Concurrent Requests
1.a. Search Concurrent Requests object and click the link to update it.
CR_1
1.b. Create new Instance Set
CR_2
1.c. Enter Name, Code, Description and Predicate for the new instance Set.
Predicate:
&TABLE_ALIAS.request_id in (select cr.request_id from fnd_concurrent_requests cr where cr.responsibility_id = fnd_global.resp_id and cr.responsibility_application_id = fnd_global.resp_appl_id)
.
CR_3
1.d. New Instance Set successful created.
CR_4
2. Login as SYSADMIN with User Management responsibility and using theRoles and Role Inheritance Tab
2.a. Create Role and then create a Grant for the Role, Data Security Object choose Concurrent Requests
RRI_1
RRI_2
RRI_3
2.b. Choose the Data Context Type Instance Set and choose the Instance Set created in above step (EY – Access Request Output of Same Responsibility)
RRI_4
2.c. Choose Permission Set Request Operations
RRI_5
2.d. Role and Grant created.
RRI_6
3. Assign the role to users as needed. The users with this role will be able to see the log and output files for the same as responsibility.
3.a. Query the user that you want to add this new role and click Update.
UR_1
3.b. Assign the new Role and Apply to activated
UR_2
UR_3
4. User OPERATIONS submit request Signon Audit Users with Request ID 5831028.User SYSADMIN will be able to find the Request ID 5831028 and the View Output and View Log buttons are Enable also.
OPR_CR
SYS_CR
But if otherwise, user OPERATIONS cannot find the Request that userSYSADMIN submitted, because the Role just grant to the user SYSADMIN.
Reference: Doc ID 804296.1
/by