Retail · Home appliances Avi Sofer

Every order from the site opens itself in both Priority and Fireberry

PrestaShop / Priority / Fireberry Retail chain and online About a year in production

Avi Sofer, an Israeli home appliance and electronics chain, also sells online, works with a wide range of suppliers and runs several warehouses. It stopped typing orders. Today every order closed on the site is written automatically into both operational systems, and with it everything that did not yet exist in them gets created: the customer, the product, the category, the brand, the importer and the supplier price list.

317

consecutive runs with zero failures, over a two-day measurement window

2.7

seconds, median end-to-end run time

How we tell these stories

We tell every case the same way: not just the challenge and the result, but how we designed the flow and solved it step by step. In automation, the "how" is what holds up in production. So it's the part worth reading.

The catalog is born on the site, the systems had never heard of it

In a chain that sells from a wide range of suppliers, new products come in every day. Priority and Fireberry did not know about them. An order closed on the site would stop because the product did not exist in either system, and before it could be created, the top level category, the sub category, the brand and the importer had to be created above it.

In practice, someone sat and typed. The same order was recorded twice, in two systems, by hand. A single typo would surface only at the warehouse or in billing, after the customer had already paid.

Not syncing. Building.

The process does not move data between systems, it builds what is missing in them before it writes. On every order it goes down to the level of the individual product, checks each system separately to see whether it exists, and if it does not, climbs up the hierarchy and creates every record required along the way. Only once the groundwork is in place are the order and its lines created.

Everything was split into one main scenario and four sub scenarios: one handles the products, one the order in Priority, one the order in Fireberry, and one the inventory. Each stands on its own, is tested on its own, and can be replaced without touching the others.

What actually happens on every order

Intake. PrestaShop reports a new order. The process acknowledges intake immediately and holds the order in temporary storage, so the site does not wait for processing to finish.
Products. Every product in the order is checked in both systems. If the product is missing, the top level category, the sub category, the brand and the importer are checked above it, each one created if it does not exist, and only then is the product created, together with the cost price list for that supplier. If the product exists, it gets updated.
Customer. The customer is checked in both systems and created or updated, including the billing address and the shipping address. A customer created automatically is born with a credit block, until someone approves otherwise.
Order. First the process checks whether the order already exists, so that the same order is never opened twice. Then it is created in Priority and in Fireberry, followed by the order lines. Shipping and discount go in as full lines, including creating a shipping item if one is not defined yet. The order number created in Priority is written back to Fireberry and to PrestaShop.
Inventory. Stock levels for every item in the order are pulled from Priority and written into Fireberry, separately for each warehouse.
Cleanup. At the end of the cycle the temporary record is deleted.

Why an off the shelf connector was not enough

Moving an order from one system to another is a simple connection. What happens here is not a move. Before every write, something has to decide what already exists, what is missing, and in what order to create it, because a product cannot be created before the brand above it, and an order line cannot be created before the product. An off the shelf connector does not hold a dependency order and does not hold state between one call and the next.

Custom development would have known how to do this. But then every new supplier, every new field and every change to the category hierarchy would go back into the development team queue and wait there.

What changed

The double typing is gone. An order closed on the site shows up in Priority and in Fireberry with all its lines and all its background records, without anyone touching it. A new product from a new supplier no longer stops an order, and it does not wait for someone to create it by hand.

In the most recent measurement window, across two days, the process ran 317 times in a row without a single failure. On the one full activity day inside that window, 183 orders were opened through it. The median time from the moment an order closes on the site until it exists in both systems is 2.7 seconds.

On the sales side: the stock level of every item, per warehouse, sits in Fireberry. Nobody has to go into Priority to tell a customer whether something is available.

Why Make Enterprise

Two of the systems in this process, Priority and Fireberry, run against apps we built for the Make platform, so the depth you can reach inside them is not the depth of a standard connection.

Beyond that, what kept this process alive over time is the ability to break it into five scenarios that call one another, to see every run and every error at the level of the individual step, and to change one part without touching the rest. This is work the operations people do themselves.

The process has been running in production for about a year. In that time the systems it works against went through changes and upgrades, and it kept running.

Have an internal process like this?

A process that eats people's time but has no clear owner to build for it. That's exactly what Make Enterprise solves.