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).
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:
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 an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
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.
email@example.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
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.
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.
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.
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.
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.
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.