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.

Add a new idea Subscribe
Status Not under consideration
Workspace OMS - Order Management (OnPrem & OMoC)
Created by Guest
Created on Jun 29, 2020

RELATED IDEAS

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? Retail
How will this idea be used?

To prevent inventory undersell and make inventory available to selling channels for consumption.

  • Guest
    Reply
    |     Feb 4, 2022

    Hello Ananth.

    Unfortunately the team is not able to proceed forward with this request since this is a depreciated feature in RTAM enabled using yfs.yfs.balanceShortageAcrossNodes=Y and yfs.yfs.considerUnassignedDemands=Y. That being said, there is a suggested option (see below) in v9.5 and above. It is recommended to move to the new feature to balance unassigned demands across DG.


    Feature in 9.5 and above : Distribution of unassigned demand based on priority for DG's.


    The new behavior while reducing the availability across DG does not change availability at Nodes so the issue logged in does not happen with new balancing behavior.

    In that case availability at nodes is not impacted and issue will not be observed. Only DG having priority gets unassigned demand and not other DG gets it.

    New feature does not support reducing unassigned availability from multiple DG(S) or DG with common Node.

    Good thing is customer use case is achievable with a small customization which can make unassigned demand to be considered for all DG(s) configured based on their requirement.


    While storing the alert for DG with new feature, a column in YFS_INVENTORY_ALERTS i.e. "UNASSIGNED_ONHAND_QUANTITY" , "UNASSIGNED_FUTURE_QUANTITY" for DG alert configured in priority.

    The same values can be shown in each generated alert xml wherever applicable if REALTIME_ATP_MONITOR.REALTIME_AVAILABILITY_CHANGE_LIST.xml is extended to have attributes: UnassignedFutureQuantity="" UnassignedOnhandQuantity="" in element AvailabilityChange.

    so event XML will be something as below: ( If you want to see alerts xml, you will have to extend alert xml as well )

    <AvailabilityChange AgentCriteriaId="" AlertLevel="2" AlertQuantity="10.00"

    AlertRaisedOn="2020-07-31T03:02:59-04:00" AlertType="REALTIME_ONHAND" FirstFutureAvailableDate="2500-01-01" FutureAvailableDate="2500-01-01"

    FutureAvailableQuantity="0.00" IsDefaultDistributionGroup="N" MonitorOption="3" Node="" DistributionRuleId="RTAM_DG" OnhandAvailableDate="2020-07-31" OnhandAvailableQuantity="5.00"

    UnassignedFutureQuantity="0.00" UnassignedOnhandQuantity="10.00"/>


    This will start showing unassigned onhand and future quantity for DG(s) configured in priority. Only drawback is if activity is created only for a Node which is not common between DG in that RTAM run, alert may not be created for DG which is not set for priority.

    Customer while publishing event to external system ( or wherever required ) can actually reduce the unassigned quantity to DG(s) not set in unassigned priority based on unassigned quantity of DG set for unassigned demand.

    If DG(s) which is not set in priority only comes in current AVAILABILITY_CHANGE_LIST EVENT; then you can query alert table for item, DG and get quantity from there and reduce for this alert quantity.

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.