Price Histories or Product Logs

Submitted by Matt C on Wed, 07/10/2009 - 23:36

General User's Discussion

We have found from time to time that knowing what the price history for a product has been is handy.

It has also occurred to our ordering person that once we start using automatic updates integrated with wholesaler list prices, that without some sort of log we wont be able to determine what may have caused price changes.

Lastly with a afew people in our clinic able to change prices, having some ability to see previous prices would be handy.

So my question is what is the best way to achieve this?

Should we;
1. Add a new price entry under product and expire the previous price by adding an end date = to the new prices start date?
2. How should the auto price update executed from the suppliers section change its prices so as to be traceable?
3. Is is better to have an annotated log link to each product showing changes in names, prices, suppliers etc?

Cheers,
Matt C

Price Histories or Product

Submitted by tanderson on Thu, 08/10/2009 - 17:11.

Re: point 1, yes, adding a new price entry and expiring the previous one would be the best approach.

Re: point 2. At the moment, the auto price update triggers a recalculation of a product's unit prices based on the new cost of the product.

i.e it updates the existing prices rather than expiring the current and adding a new one. It will also change all unit prices including those that have expired.

Not sure if this is the desired behaviour or not. Tony?

Re: point 3. Not 100% sure what you mean. We could add a generated description stating that a price has been updated automatically.

-Tim

Price updating and history keeping

Submitted by Matt C on Fri, 09/10/2009 - 10:43.

Hey Tim,

Re Point 2:

I'm not sure if it was intended to have a price history retained through old price entries but it does seem to be a good idea. If so the current auto update behaviour seems at odds with that purpose.

Re Point 3:

Sorry, didn't explain that well. I was suggesting as an alternative to the above method of price history keeping was of a log of dated statements, outlining how the product may have been changed. For example;

21-10-2009 09:30 Price automatically updated

But I think the strategy of using new price entries and expiring old ones is much better. Yes adding a generated description saying that a price was created via Autoupdate would be handy.

A new Point 4:

In light of this discussion, in terms of encouraging "correct" use of price entries, should the unit price field be read only after it is created? In other words the only way to edit a price is to create a new one so as to ensure a log is kept of a price change event?

A last Point 5!

Should price entries have a "note" field for users to be able to add or annotate a price change. In our case we would include user initials here as we tend to use a general adminsitrator log in for these functions rather then assigning administrator privileges to our general log ins.

Matt C

Re: Price Histories or Product Logs

Submitted by David Mason (not verified) on Wed, 07/08/2019 - 18:56.

Hi All,

I'm keen to see if we can re-invigorate this discussion into a project. I think it would be great if the product price history automatic update didn't overwrite the current price.

So from the above discussion:

Pts 1/2 above: When an a supplier invoice is delivered in OpenVPMS and there is a difference in price that this does not overwrite the current unit price, but sets an end date as today and new start date the same with the updated unit price.
Pt 3: - A log somewhere would be fantastic. Possibly both a note field as suggested by Matt C but also a report that we can review the price change history that has occured as a result of the supplier delivery.

Let me know what you think and we might be able to push it along to development.

Many thanks

David

Re: Price Histories or Product Logs

Submitted by tanderson on Thu, 15/08/2019 - 10:08.

Creating a price history from deliveries has been scheduled for OpenVPMS 2.2: OVPMS-2190

At this stage the data model doesn't support linking a user to a price, but if it did, it wouldn't tell you that the price change was the result of an edit or a delivery.

The delivery identifier could be associated with the price. This would need to be cleared if a user subsequently changed the price manually.
This could then be used in reports to indicate which prices came from a delivery.

Re: Price Histories or Product Logs

Submitted by David Mason (not verified) on Mon, 19/08/2019 - 17:32.

Hi Tim

Thanks for the update. If we could identify which price changes were manual and which were an automatic update through a delivery this would be good.

Would this also capture a price change made manually to a suppliers price? Possibly for products whose prices are not automatically updated through deliveries.

For clarification; - on the project page (OVPMS-2190) it doesn't state if all other aspects of a products price structure (markup, max discount, etc) will remain the same. Can you confirm that this will be the case.

Also would this update 'lock' the prices tab from staff being able to edit a product price / product price information, so that they need to create an end date, and then add a new price rather just edit the item?

Many thanks

David

Re: Price Histories or Product Logs

Submitted by tanderson on Thu, 19/09/2019 - 12:27.

I've updated OVPMS-2190 to indicate that the markup and maximum discount will be copied from the previous price and added:

OVPMS-2203 Prevent editing of prices with a From Date < now
OVPMS-2204 Include author on product prices

OVPMS-2204 won't tell you if a price came from a delivery or manual entry, nor will it tell you if the price has subsequently been edited, but it will tell you who was responsible for its creation.