This portal is to open public enhancement requests for IBM Sterling products and services. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updateson them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
ATP calculations due to back order demands resulting in undersell issue
When there are orders in back order status (say ship to home orders that result in back order either a shortage reported from a fulfillment center or back order during the sourcing attempt), the system considers these backorders in both shipping aggregate ATP (as calculated by RTAM process) and node level ATP.
For node level ATP, since the fulfilling location is not known till the order gets rescheduled, the system recalculates ATP (say whenever there is a supply change for the back ordered item at multiple ship nodes) assigns these back order demand to any random node in the system and publishes the RTAM ATP. Now, when the scheduling agent pickups the back order for processing, it assigns the back order to a node based on the configured sourcing rules. The node assigned during the scheduling process can be different than the random node picked up by the RTAM and as a result this can result in an ATP undersell issue.
Say, system has 1 unit on back order for SKU1. Now, as part of the intra day inventory delta feed into OMS, on hand inventory is incremented (say 1 unit at each store) at stores (Say Store 1 thru store 5) for SKU1. when inv update is made in OMS, RTAM recalculation is triggered and system can random assign the backorder demand to any of the 5 stores that have inventory for SKU1. Say, RTAM selects Store 5 and assigns the backorder demand against Store 5 when calculating node level RTAM ATP. As a result, Store 5 ATP is calculated as 0 (On hand supply as 1 , Node level ATP is 0 as backorder is assigned to Store 5). Stores 1 thru 4 have ATP as 1 (on hand supply is 1 at each store).
Now, when the system schedules the backorder, the order is assigned to store 1 (based on sourcing rules). After sourcing, node level ATP for store 1 is published as 0 as the order got assigned to store 1. At this point, the 1 back order demand was considered against 2 different stores (Store 1 and store 5) resulting in an undersell.
When recalculating node level ATP, the system should pick the node to assign the backorder demand (ship to home) based on sourcing rules. In addition, when backorders are sourced, system should recalculate node level ATP to ensure that there is no undersell issue as identified above.
What is your industry?
How will this idea be used?
To prevent inventory undersell and make inventory available to selling channels for consumption.
Do not place IBM confidential, company confidential, or personal information into any field.