IBM Sterling Ideas

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:

Post your ideas

IBM is transforming its request for enhancement (RFE) process. The purpose of the transformation is to provide a more consistent experience for you to submit requests and to enable IBM product owners to respond to your requests more quickly. For more information click here.

Start by posting ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,
1. Post an idea
2. Upvote ideas that matter most to you
3. Get feedback from the IBM team to refine your idea

Help IBM prioritize your ideas and requests

The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The offering manager team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.

Receive notifications on the decision

Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.

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.

  • Guest
  • Jun 29 2020
  • Future consideration
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 commented
    7 Mar 04:34pm

    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 commented
    4 Mar 05:02pm

    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 commented
    9 Feb 02:56pm

    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.


  • Guest commented
    3 Feb 11:39pm

    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 commented
    9 Dec, 2021 07:42pm

    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 commented
    19 Oct, 2020 03:55pm

    This idea will be reassigned to the IBM Store Engagement offering- Offering Manager

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

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.