Who changed that price? Product change history in PrestaShop

Monday morning. A customer writes in because they have bought a product at a price that makes no sense: half the usual amount. You look at the product page and, sure enough, the price is wrong. Who changed it? When? What was it before? How many orders have come in at that price?

In a standard PrestaShop store, the honest answer is «we don't know». And the next conversation in the team is usually awkward, because everyone says they have not touched anything.

Why PrestaShop does not know

The PrestaShop database stores the current state of each product: its price, its stock, its description, whether it is active. When someone saves a change, the new value replaces the old one and the old one disappears.

What it does store:

• The date the product was last modified (date_upd), without saying what changed or who changed it.
• The system log (Advanced Parameters > Logs), which, depending on the version, records some employee actions, but without the before and after values.
• Stock movements, when advanced stock management is enabled or in the versions that record them, which tell you how much stock moved but nothing about the rest of the product.

To know what happened you need what is called an audit log: one line per change, with who, when, which field, the previous value and the new one.

Which changes are worth logging

Not all fields matter equally. In order of how much trouble they cause:

1. Selling price and cost price. A mistake here turns into money lost the same day.
2. Stock. Keeping manual adjustments separate from movements coming from orders and from ERP syncs.
3. Status. A product that is disabled disappears from the catalogue and from Google Shopping or marketplace feeds.
4. Default category and associations. They affect the URL, the breadcrumb and search rankings.
5. Name, description and friendly URL. A URL change without a redirect is a page lost in Google.
6. References and codes (reference, EAN): the warehouse, the ERP and marketplaces depend on them.
7. Weight and dimensions. They change what you charge for shipping.

What a good history must include

• The employee, by name, not just a number.
• The exact date and time.
• The source: back office, CSV import, webservice or a module. Many surprises are not caused by a person but by an integration.
• The before and after of each field, on the same line.
• Filters by product, employee, field and date.
• Export to cross-check it against orders or show it to whoever needs to see it.
• Configurable retention: keeping everything forever fills the database; a reasonable period and automatic clean-up.

Cases where it is used

The price nobody changed

A food store sees products with the price set to zero every few days. Nobody on the team has touched them. The history shows that the change comes through the webservice, always at the same time: the ERP connector sends an empty price when an item has no price list assigned. Without the source recorded, they would have kept suspecting the team.

Stock that does not add up

A B2B distributor does a stocktake and units are missing. The product timeline shows every manual adjustment, every order movement and every sync. The discrepancy turns out to be a manual adjustment someone made to the wrong combination.

The product page that lost rankings

A product that used to sell well drops in Google. The history shows that three weeks ago its name and friendly URL were changed, and no redirect was set up. The previous URL is restored or a redirect is created, and you know exactly what text was there before.

How many orders came in at the wrong price

With the exact time of the change and of its correction, you filter the orders in that window that contain that product. Now you know who you need to write to and how much it has cost you.

How to organise it in the team

• One employee account per person. If three people share the same back office account, any history will only say «it was the store account». Everyone with their own, and with the profile they need.
• Dedicated accounts for integrations. The ERP, the supplier connector and the marketplace, each with its own webservice key: that way their source can be told apart.
• Weekly review. A look at the week's summary: who has changed the most, which fields and which products. Anything odd stands out.
• Agreed retention. A few months is usually enough for day-to-day work; if you sell products with regulated or contract prices, you may need longer.

It also helps when updating

When you update PrestaShop or a module, or migrate to a new version, it is common for some process to start touching fields it did not touch before: a module that rewrites prices when reinstalled, an import that now reads decimals differently. Having the history enabled before the update lets you see, the next day, whether something has changed products without anyone asking for it.

Checklist

• Every team member with their own employee account.
• Every integration with its own webservice key.
• History enabled at least for price, cost, stock, status, category, name and URL.
• Retention period decided and automatic clean-up.
• Regular review of the summary.
• Before and after an update, a look at the changes.

How to solve it in PrestaShop

Full Product Log records every change to your products with the employee, the date and time, the address it was made from and the previous value alongside the new one, across up to 84 fields that you choose to monitor. Above the list you have the summary for the period, with who changes the most, which fields and which products, and each name is a shortcut that filters the list. Each product has its own timeline, stock movements coming through the webservice from the ERP are recorded, you export what you are viewing to CSV and you decide how long it is kept. It does not modify your products or add anything to the storefront, and it works in multistore, from PrestaShop 1.7.6 to 9.