IBM Sterling Ideas
Submit new product ideas for IBM Sterling solutions. Before you submit, please review existing ideas; if an idea close to yours already exists, it's better to add comments or vote on the existing idea. We will review your ideas and use them to help prioritize our product development. Best of all, the portal will automatically update you when the status of your idea has been changed.
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.
Connect with IBM experts and your peers on the
Supply Chain Collaboration Community and the Order Management Interest Group
Current design of BUC reporting Declined by Node metrics has gap that will under-report and under represent the declines/reject/short-picks by node.
-Design as explained in Case #TS004179727 "Pick Decline is a status of BUC and we do not have a status with this name in OMS application. As per the current design, pick decline in BUC maps to the OMS status 1400 ("Backordered From Node")"
Reason for design review
When a node declines/rejects a line it moves to Status = 1400 but it will only be in that state temporarily, a few hours at the most. Most retailers will typically have the OMS take action on that line pretty quickly by assigning it to another node (if ATP), cancelling (it no ATP) or having Customer Service take action (put a CSR hold). The issue is that it won't be in 1400 status for long, and once it moves to another status the "Pick Decline" event won't be visible for the node, though they rejected it, so it under-reports declines by the node.
How will this idea be used?
Accurate reporting of rejections by nodes in the BUC
|What is your industry?||Retail|
|What is the idea priority?||Medium|