Connecting PrestaShop to GoManage and Aunabase: a real case

Eleven at night. An electrician opens the shop on his phone, adds three metres of trunking, a box of switches and a breaker, and pays. Next morning, in the warehouse, it turns out there was one box left: the other two went over the counter on Friday at half six.

The customer did nothing wrong, and neither did the shop. The problem is that the shop and the warehouse live in two different places — the website on one side, the ERP on the other — and in between there is a person copying prices and stock levels whenever they get a spare moment.

This is what we built for a distributor of electrical and plumbing supplies working with two tools that are well known in the trade: Go!Manage, the ERP by Telematel, and Aunabase, the product database of the Aúna Distribución group.

The starting point: two systems that already worked

The company did not have a software problem. Its ERP was up to date, with almost thirty thousand items on file, its price lists and its stock per warehouse. And it had access to Aunabase, where the group's manufacturers publish the good product data: the real commercial name, the technical description, the photos, the barcode, the brand, the units each item is sold in.

What it did not have was a shop. And the temptation, when you build one, is to fill it in by hand: export a spreadsheet, upload it, touch it up, and three months later own a third catalogue that matches neither of the other two.

The shop is not another place to store the catalogue. It is the shop window of what is already in the ERP.

With that in mind, the job stopped being "get the products into PrestaShop" and became something far easier to explain: deciding who is in charge of what.

Who is in charge of what

The whole project rests on this split, and it is the part worth settling before anything else is touched:

• The ERP is in charge of the business. Which references are sold, at what price, how many are left and which ones are on a promotional price list. None of that is edited from the shop.
• Aunabase is in charge of how the product is told. Name, description, images, brand, manufacturer, barcode, family and minimum sales unit.
• The shop is in charge of selling. The home page, the campaigns, its own copy, shipping and dealing with the customer.

Out of the ERP's almost thirty thousand items, the shop shows a selection of 16,700 references: the ones the distributor wants to sell online. The rest stay in the ERP and never show up. Widening or trimming that list is a commercial decision taken in the ERP, not a website maintenance chore.

What the customer sees

Day to day, with everything in place, the shop behaves like this:

• Product pages that make sense. Every item arrives with its commercial name, its technical description, its photos and its brand, rather than a "REF 4021 WHITE" and a stock image. That is what lets the page compete on Google, which is where half the visitors come from — we covered it in where to start when your shop does not show up.
• Prices and stock that are the warehouse's. Not those of the last export.
• No stock, no sale. The reference stays visible — you want Google to know it and the customer to know you carry it — but it cannot go into the basket until there are units again.
• Everything in its own unit. If an item ships in boxes of ten, the shop will not let anyone order seven. The minimum unit comes from the manufacturer's data, so orders arrive ready to pick.
• Discontinued items disappear on their own. When a reference is withdrawn, it stops being for sale without anyone having to remember.
• Offers place themselves. Whatever sits on a promotional price list in the ERP lands in the shop's offers category, and leaves it just as quietly when the price list changes.

None of this is maintained by a person. It is the same information already maintained in the ERP and in Aunabase, seen from the web.

And the order, back again

The interesting half of an integration is the one that runs the other way. When the customer pays, the order lands in Go!Manage with its lines, its quantities, the delivery address, the invoicing address and the payment method translated into the one the ERP understands. Nobody types it again.

And because this has to be verifiable, the order page in the back office shows whether it reached the ERP or not, with a button to send it again. That is the real change for the company: no more "I'll put it into the ERP when I get a minute". The warehouse sees the order where it sees all the others.

The three decisions that make it last

An integration is judged six months in, not on the day it is switched on. These are the three that avoid the classic problems:

1. Price and stock are edited in one place only. The ERP. A shop where they can also be changed by hand ends up arguing with itself, and the argument is always lost on the busiest day.
2. Hand-written work is never overwritten. When someone improves a product name, rewrites a description or uploads a better photo, the next update respects that work. Without this rule, nobody ever touches a product page again.
3. The update runs in batches and knows how to resume. A catalogue this size is not refreshed in one go: it is processed in blocks and, if it is interrupted, it carries on from where it was. The shop never has to close "for maintenance" or sit there with half a catalogue.

What we need from you

When someone asks us about this, what we need to know is not much:

• A connection user for your Go!Manage, which your ERP provider issues.
• Your Aunabase credentials, if you are a member of the group.
• The selection of references you want to sell online and how you want them grouped into families.
• And one commercial decision: whether you sell to trade customers at agreed prices, open up to the general public, or both at once. We wrote about that separately, in how to show the catalogue only to approved customers.

With that we can already run a first trial pass and look at the real catalogue inside the shop before deciding anything else.

If you work with Go!Manage or Aunabase

We know both from the inside and we know where they usually hurt: references the ERP holds twice, families that do not match how customers actually buy, items with no photo, special price lists. None of that is unusual and none of it stops you going live.

And if your ERP is a different one, the approach is the same: the ERP owns price and stock, the good catalogue owns the product pages, and orders find their own way back.

Is your ERP up to date and your shop still a to-do? Tell us what you use and we will tell you what can be connected, and in what order.

Tell us about your case