Price discrepancies across 380 customers dropped to zero
A distributor of industrial parts served 380 active business customers. Each had their own discounts depending on the product group, purchase volume and history of cooperation. The company also used credit limits, deferred payments and orders submitted as CSV files.
The PrestaShop store had three B2B price list modules, bought at different times from different vendors. Each implemented part of the pricing rules but ignored what the others did. The price in the cart could differ from the amount on the invoice. Explaining a single discrepancy took a salesperson half a day.
Analysis before buying another module
The client wanted a quote for a fourth module that would combine the three existing ones. I proposed two weeks of diagnosis first. The description of the problem suggested that the whole way prices were calculated needed to be examined.
The analysis showed that the price depended on four variables: the customer, the product, previous purchases and the account balance. The modules applied these rules independently, working around the limitations of the store’s data model. Combining them did not produce a consistent result.
Comparing three solutions
I prepared three options with their cost, risk and expected payback period:
- A fourth module meant the smallest outlay, but I estimated its useful life at about a year.
- Rewriting the pricing rules inside PrestaShop required a bigger investment and maintaining a custom workaround of the architecture.
- A separate pricing service followed by a platform change was the most expensive, but it removed the source of the discrepancies.
We added the annual cost of salespeople’s time and held-up orders to the comparison. It exceeded the difference between the options. Once that amount was taken into account, the client decided to extract pricing and migrate later.
Prices first, then the whole store
In the first stage I moved price calculation into a service with an API. The existing store fetched the result over HTTP. This stage took eight weeks and solved the most urgent problem while keeping sales running.
Ultimately the store was moved to Sylius, where the pricing rules could be described directly in the domain model. The implementation took another five months. The switchover happened after six months of history showing the pricing service running without discrepancies.
Results after a year
- The number of differences between the cart price and the invoice fell from a dozen or so a month to zero.
- Adding a discount rule took one day instead of two or three weeks of waiting for the module vendor.
- File-based orders were handled directly by the store, without an external module.
- Tests covered 94% of the pricing logic, whose errors directly affected billing.
Why this scope was justified
The decision came down to the scale of the problem and the cost of dealing with it every day. With thirty customers I would have recommended staying on PrestaShop and cleaning up the modules. With 380, the cost comparison justified the change. A migration is worth considering once you have checked whether a cheaper solution would achieve the goal.