Imagine. A webshop, where Items are sold connected via ION. In the webshop only actual prices are known, no validity date.

Now we send out a BOD with the current price [€ A], the shop shows the item at the current price.

Then we change a pricebook line because tomorrow (starting 0:00 this night) we will have a new price [€ B]. So price [€ A] gets expiry date 23:59 today, new price [€ B] starts 0:00 tomorrow. Now this change triggers a BOD with current price [€ A].

Tomorrow begins and the price on the shop does not change. Not that whole day. Nor the days after, because no new BOD is sent.

What would your option be to solve this problem?
- Push each item once every night?
- Create a session that keeps track of all "aging" fields in the BOD that needs to refresh data by sending out BODs on aged fields?
- Use the available standard funcionality to publish BODs based on aged data?
- Change the shop's functionality so the expiry date is included and let the shop pull the BOD when expiry date passed?

Tomorrow begins and the price on the shop does not change. Not that whole day. Nor the days after, because no new BOD is sent.

What would your option be to solve this problem?
Since there is no option:
- Use the available standard funcionality to publish BODs based on aged data? in the standard, we opted for a nasty way to create a job containing a session to signal date changes compared with several critical date fields to trigger the related record BODs...
A bit like
- Create a session that keeps track of all "aging" fields in the BOD that needs to refresh data by sending out BODs on aged fields?
For
- Change the shop's functionality so the expiry date is included and let the shop pull the BOD when expiry date passed? was not an option, our 3-rd party software developers of that new webshop already are struggling to update our webshop for two years now... And they are renowned party... they claim.

But after 500+ reads and no reaction I guess you never ran into this kind of issue?

In my view: pricing data is very dynamic, time based but also because of the multiple search levels. So it is hard to publish the data via a single BOD. All data (multiple tables) need to be published and the webshop should implement the same searching logic...too hard. Other option is to use the pricing webservice, retrieve the price at the time you need to show/use it. The last one seems the better solution to me.

I agree on that.

On the other hand: "Maak haast als je tijd hebt, dan heb je tijd als je haast hebt". [!GT?lang=NL]

We have a B2C situation with several thousands of items sold via a webshop. Each item now gets one (max three) price calculation (of several seconds) when launched into the webshop (or altered on any of the relevant fields). This is a background calculation, so no delay for customers.

Should we recalculate the price webservice-based on every show-on-page and on every add-to-cart the customer will definitely feel the delay and loose interest in our webshop. With cached prices we do not have that delay.

Added on top of that, a cached price is calculated only once, and as our customer base is segmented, we can simulate one price applicable for the whole (section) of customers. Webservice based recalculations would occur multiple times without changes in between.

In case the number of expiry dates is limited, you could run on those moments a program to trigger the applicable BODs.
But none of these solutions is really ideal.
thanks for the Dutch saying.