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.

Ability to support order amendments and exchanges without re-pricing in OMS UIs (Call Center, Store, etc)

Currently re-pricing (and integration) is required for amendments and exchanges but in certain situations such as the below examples there should be no need for this and simplifies implementation for these use cases.


Change product variant- Variant to be priced using original line price- Exchanges- Restricted to exchange for same product or product variant- Correlation between return and exchange item

  • Guest
  • Jun 1 2022
  • Functionality already exists
What is your industry? Retail
How will this idea be used?

This would simplify implementations in an MVP situation and also for customers who do not need re-pricing for simple refunds and exchanges

  • Guest commented
    17 Aug 09:52am

    Hi Aaron,


    The IBM Call Centre UI invokes getCompleteItemList when looking at adding new exchange lines to an order and retrieving prices to display prior to adding the lines to the exchange order itself. At this point in UI flow the YPMGetOrderPriceUE or YFSOrderRepricingUE is not being invoked I believe when calling API getCompleteItemList. The API internally calls getItemListForOrdering from which there is no UE's mentioned in javadocs for YPMGetOrderPriceUE or YFSOrderRepricingUE but correct me if I'm wrong here.


    Regards,

    Nam

  • Admin
    Aaron Cutter commented
    22 Jul 02:07pm

    Hi Nam,

    Which UE are you referring to? I'm assuming that you are not using external pricing (the YFSGetExternalPricesForItemListUE that is invoked from getItemListForOrdering). If external pricing is not used, then it should use internal pricing, and therefore a UE like YPMGetOrderPriceUE or YFSOrderRepricingUE would be invoked, which includes order information. In your scenario, I think you're talking about building an exchange order and wanting to refer to the original sales order for item price details, which should be possible from these UEs.

    If you can provide a specific sequence of events and where your problem is, that may help to illustrate whether there is an existing solution or if not, what type of product enhancement may suit your scenario.

  • Guest commented
    21 Jul 08:58pm

    Hi Aaron,

    I believe the issue we faced was that the API getCompleteItemList is invoked by OMS UIs when it tries to obtain prices for item variants which calls getItemListForOrdering from which there are UEs available for you to return your own prices potentially however there is no context of the original order in the request itself which makes it not possible to be able to use the original price on the order line to use for the variants. I think if the original order details can be provided in context then this could be an option to use.

  • Admin
    Aaron Cutter commented
    21 Jul 08:45pm

    Hi Nigel,

    The BypassPricing attribute prevents the pricing UEs from getting called. The Javadocs indicate that if this flag is set to Y then pricing will not be performed and "It is assumed that pricing information is provided in the input to the api." So it is assumed that if you are bypassing pricing then you already know the price that you want and pass that as the input to the changeOrder API call for an order amendment.

    The scenarios you describe for not needing to execute repricing logic may be accurate, but are difficult to implement generically. For example, in some instances it may be the case that the same item with a different size or color is the same price, and repricing is not needed. But there are other instances where this may not be the case - for example, some basic or standard colors may all be the same price, but same item in a new color could be more expensive. This sort of edge case is exactly what the UE structure is intended to solve. It is difficult for Sterling Order Management the product to create a generic solution that works for everyone's requirements - but with a UE, you can insert your project-specific requirements to get exactly the behavior you want.

  • Guest commented
    20 Jul 03:50pm

    Hi Jason,

    It is quite common in initial release to reduce overall scope of implementation effort to not support amendments or exchanges whereby we need to take additional payment from Customer since that requires effort for integrating with pricing and promotions engine, customer master, secure payment capture in OMS apps, etc.

    It's also quite common for fashion retailers to limit amendments to only like for like or same style/colour but different size from which price is kept the same. In these cases if I'm changing size or exchanging for a different size the price from origin line should be retained, and this should factor in discounts and promotions already applied on original line.

    In these cases also we shouldn't be allowing any more lines or additional quantities to be added although this should be a rule to prevent it being fashion retailer specific. The flag you mention may bypass pricing but would then result in giving a price of 0 for the new item being added.


  • Admin
    Jason Cheng commented
    20 Jul 02:59pm

    Hi Nigel,

    You can use the existing attribute Order/@BypassPricing in order to avoid a repricing call. Since this is not a common use case, it can be done via customization of the UIs where repricing is not required should set this flag.


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.