Skip to Main Content
IBM Sterling


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 updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

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.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Future consideration
Created by Guest
Created on Jun 29, 2020

Short pick/reject from a store results in a inventory oversell

When a shortage is reported from a store (through out of the box IBM Store module) that results in the order being backordered, the backorder demand is not being considered in the overall shipping aggregate ATP in OMS. As a result, this will result in OMS publishing the incorrect ATP picture to the selling channels (RTAM ATP publish). This is because, IBM Store module invokes changeShipment to cancel the lines from the shipment and also to move the lines in the order to a backorder state. When the lines are backordered through the changeShipment API, the ship node on the order line (the node to which the order was allocated initially) is not removed. This results in the backorder demand not being considered in the RTAM ATP recalculations when inventory becomes available in any other of the other nodes. This results in an oversell issue and is rectified only when the backorder is reprocessed by the scheduling process and is assigned to a different fulfilling location.

The same oversell issue occurs there is a partial reject from the DC.

What is your industry? Retail
How will this idea be used?

To ensure that the OMS RTAM ATP calculations result in accurate ATP reflective of all backorder demands in the system.

  • Guest
    Mar 7, 2022

    Hi Ryan,

    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.

  • Guest
    Mar 4, 2022

    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?

  • Guest
    Feb 9, 2022

    Hi Ryan,


    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.


    Thanks

  • Guest
    Feb 3, 2022

    Hello Ananth.

    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!

  • Guest
    Dec 9, 2021

    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.

  • Guest
    Oct 19, 2020

    This idea will be reassigned to the IBM Store Engagement offering- Offering Manager kiran.rao@ibm.com

    Please let him know if the duplicate orderline pointing to the specific shipnode can remove the association?