Last updated on FEBRUARY 03, 2017
Applies to:Oracle Advanced Supply Chain Planning - Version 12.1.3 and later
Information in this document applies to any platform.
On : 12.1.3 version, Memory Based Planner in Test:
Users are on 12.1.3 apps and have applied VCP 184.108.40.206 Patch 13833266. They are using Sun 64 bit MBP executable MSONWS64.ppc 120.14.12010000.72 with no one offs at this time. This is an EDD Classic Constrained plan with 180 days/8 weeks/4 periods. Demand Priority rule = AFT Rule. Peg Supplies by Demand Priority is enabled. Append planned orders enabled.
Enforce Purchasing Lead-time Constraints is enabled and so are resource constraints. with demand prioritization. Prioritized forecast is published from Demantra to ASCP (not to EBS instance). Sales orders have external/source priorities as well. Forecast is given higher priority numbers (ie 300) in Demantra than any of the planning priorities given to sales orders (ie below 80). Therefore forecast should always have lower priority than any sales order demand when ASCP pegs available on-hand inventory to sales orders and forecast demands.
ASCP does not appear to be calculating the end demand priority vs the source priority of the forecast. Prior to publishing the source priorities, ASCP calculated internal priorities for the forecast, incrementing same for each succeeding month of forecast. Even with the published source priority of “300”, which is higher than any of our sales order (external/source) priority values, ASCP still calculates its internal priority for forecast in the current month to be higher (lower numeric value) than the calculated priorities for the sales order demand (higher numeric value).
Primary business problem with this behavior: ASCP will peg on-hand inventory in the source organization to current month source org forecast instead of pegging it to the currently due sales order demand from the destination org. Thus ASCP will plan orders to move future supply to the destination org to cover the sales order demand at a later date, when on-hand inventory could be transferred immediately to ship the sales order now. This scenario is very typical in our business and is the primary reason for including priority for forecast demand.
MSC: Demand Priority Flexfield Attribute = 10
MSO: Default Forecast Priority = 100000
MSO: Default Sales Order Priority = 10000
MSC: Forecast Priority Flexfield Attribute = 0
MSC: INTER PLANT DEM PRIORITY is NULL
Example item data:
Plan run was 25-OCT-2012
Item = JMake
Org = TST:M1
On hand qty = 15
Pegged qty = 8 to forecast due 24-OCT-2012 (past due forecast) End Demand Source Priority = 300, End Demand Calculated Priority = 42
Pegged Qty = 1 to forecast due 25-OCT-2012 End Demand Source Priority = 300, End Demand Calculated Priority = 42
Pegged Qty = 5 to Sales Order due 24-OCT-2012 (Sales Order 2000435) End Demand Source Priority = 60, End Demand Calculated Priority = 49
Pegged QTy = 1 to Sales Order due 24-OCT-2012 (Sales Order 2000435) End Demand Source Priority = 60, End Demand Calculated Priority = 49
The sales order is for qty = 15 and the balance is pegged to a planned order due 12-NOV-2012. It was expected that the on hand would be used to cover the sales order demand first.
Forecast Qty = -8 due 24-OCT-2012 transaction_id = 18297550
Forecast Qty = -1 due 24-OCT-2012 transaction_id = 18298382
Sales Order Qty = -15 due 24-OCT-2012 transsaction_id = 18296388
Planned orders for supply that satisfies the balance of sales order 2000435 qty = 5, qty = 1 and qty = 3 have the following transaction id's
Expect the calculated demand priority for forecast will have a higher numeric value than for sales orders based on their setup. This then would cause pegging to satisfy the sales order first before the forecast
The issue can be reproduced at will with the following steps:
1. Run EDD constrained plan with demand priorities of forecast with higher numeric values than demand priority of sales orders
2. Review ASCP workbench and forecast is being satisfied with supplies before pegging since the calculated demand priority for forecast is a lower numeric value than for sales orders
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms