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).
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:
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 updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
email@example.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
Thanks for the update on the enhancement.
I think stamping a specific node will end up causing inventory inaccuracy in the inventory lookup api's and in inventory publish to selling channels when inventory does show up at an alternate location post the backorder (oversell risk). The other alternative will be to consider the backorder order as a promised demand and deduct that from the ATP in whatever locations the system would consider based on the configured sourcing rules.
I wanted to highlight on other system behavior that is related to this issue and had an impact on inventory inaccuracy. For OMS Commerce On Cloud customers, currently, the product does not allow clients to run the schedule agent more frequent than 30 mins. As a result, it could take up to 30 mins (or longer if there are a lot of backorders in the system) to reallocated the backorder based on new inventory availability. So, the risk of exposure in ATP inaccuracy is high. If the product were to automatically prioritize rescheduling of backorders based on what demand/supply change has occurred (prioritize these orders than other backorders for which there is no supply/demand change), then, it will definitely help minimize the window of ATP inaccuracy.
We agree it would be difficult to assess which node to stamp on a backorder. There would be lot of use case on how to derive where the demand has to be backordered against. For instance based on priority, then have a threshold on the number of backorders that can be against particular nodes. Region wise node selection and so forth. Thus if we were to expose a way to stamp the node for the backorder status for a particular order, will that help meet your expectations?
I think the base product should have rules to determine how to account for backorder demands and factor that into the ATP calculations (for both real time inv lookups/reservation and also for any ATP updates published outbound from either OMS or IV).
Stamping any specific node will be pure guesswork as we will not know which node the order will get allocated to. One option is for the system to evaluate the sourcing rules to determine which locations are eligible to fulfill the order/line and reduce ATP for the backorder demands against the locations that are factored in these sourcing rules.
The team evaluating this request had a follow-up question. If the product were to give a way to stamp a node to back order against, or optionally leave it blank, would that meet your needs (e.g. giving a handle to stamp / not stamp node on 1300 status)? Thanks!
The state problem is to address the scenario in OMS where any short picks (whether it is from a store or warehouse) results in a backorder and the overall system processes (including Inventory publish and inventory lookup API's) don't have a good way to account for these back order demands in an accurate manner. This situations arises when we have a backorder and inventory becomes available in the system post backorder event (say 5 mins later). The OMS base scheduling process does not allow orders to be scheduled faster than 30 min interval (OMS limitation on CoC) and the system does have a in built process that can identify the change in supply and automatically process/schedule the backorder based on inventory activity. To me , this is something that should be provided in OMS as a core function without customers having to write custom solutions.
This idea will be reassigned to the IBM Store Engagement offering- Offering Manager firstname.lastname@example.org
Please let him know if the duplicate orderline pointing to the specific shipnode can remove the association?