Connecting PrestaShop to GoManage and Aunabase: a real case
An electrical and plumbing supplies shop that takes price and stock from the Go!Manage ERP, product pages from…
“I'd like to return the boots, they're too small.” Someone on your team opens the order, replies by hand, notes the case in a spreadsheet and waits for a parcel. When it turns up, they have to remember whose it was and what was promised. Multiply that by twenty a month.
The customer always writes the same message, but behind it sit three processes the law treats separately, with deadlines and costs that have nothing in common:
How long that guarantee runs depends on where your customer is, and the differences are bigger than most shops assume. Two years is the EU floor, not the ceiling: Spain raised it to three years for anything bought since 2022, France presumes a fault was there from the start for a full twenty-four months and adds six months to the guarantee after every repair, and Germany puts the burden of proof on the seller for the first twelve months. If you ship across the EU, the safe answer is the most generous one for that customer's country, not the one written on your English returns page.
Selling into the UK adds a second layer that has nothing to do with the EU rules: fourteen days to cancel under the Consumer Contracts Regulations 2013, and separately a thirty-day short-term right to reject faulty goods for a full refund under the Consumer Rights Act 2015. Two different rights, two different clocks.
Mixing them up is expensive in both directions. Treating a cancellation as a commercial return —“the window was thirty days and it's closed”— puts you outside the law. Treating a guarantee claim as a cancellation means giving back money you never had to.
The customer always writes the same email. Behind it are three different processes, and only one of the three is yours to decide.
This one isn't in any manual and it's the one that turns up most: the customer forgot to enter their discount code. They don't want to return the goods — they haven't even got them yet — they want the whole order cancelled so they can place it again properly.
And they're entitled to, because the right to withdraw doesn't make anyone wait for the parcel: it can be exercised from the moment the contract is concluded. The fourteen days are the end of the window, not the start of it.
Operationally this is nothing like a return. If the order hasn't left the warehouse there's nothing to collect: it has to be stopped, cancelled and refunded. If it has already gone, you have a parcel in transit that will come back on its own. PrestaShop offers no route for the customer to do this themselves — it ends up as an email, or a phone call — and it's exactly what the electronic withdrawal function solves, mandatory since June 2026 and what we build with Right of Withdrawal.
What's left —the everyday return, with the goods already at the customer's house— is what the rest of this article is about.
This surprises a lot of people: you don't need to buy anything to get started. PrestaShop has included a merchandise returns system for years, but it arrives disabled, which is why hardly anyone knows it's there.
You turn it on under Customer Service → Merchandise Returns. There are two settings and that's it: enable it, and say how many days you accept — fourteen out of the box.
From then on the customer opens the order from their account, ticks which products they're returning and how many, writes why, and submits the request. It shows up in a list in your back office, with five states you move it through: waiting for confirmation, waiting for the parcel, parcel received, denied and completed. Every state change emails the customer, and you can print a PDF return slip for them to drop in the box.
For a shop with three or four returns a month, this is enough. Genuinely. Switch it on before you consider anything else.
The first surprise is when the button shows up. PrestaShop only offers to return an order that is paid and shipped, and it counts the days from the shipping date recorded on the order: the one filled in when you change the status, not when the customer opens the box. If your warehouse takes two days to mark orders as sent, the customer starts two days down without anyone telling them.
The second is that digital orders are left out entirely. If what you sell is downloaded, PrestaShop never shows the return option — which makes sense for a file, but leaves nothing for shops that mix physical and downloadable products in the same order.
The third is the reason. The customer types it into a free-text box, and that's where it ends: there's no list of reasons, so at the end of the quarter you can't answer the one question that matters —why am I getting these back?—. With fixed reasons you find out that 40 % of the returns on one reference are about sizing, and that the product needs a better size guide, not a different supplier.
The fourth is that a return doesn't move any money. Approving one generates no refund: that's another screen, on the order, that somebody has to remember to fill in. There's no collection either, no carrier label, no notice to the warehouse.
Put shortly: PrestaShop records the request. Everything that happens afterwards still lives in your inbox.
Once a shop goes past twenty or thirty returns a month, the same requests always appear, and they're almost never “I want an RMA module”:
The third point takes the most forms, and they're worth telling apart, because they aren't the same piece:
RMA-00001, precisely because customers understand “RMA” and don't understand “sales return order”. If your ERP already knows how to do this, the shop doesn't need to learn it: it needs to tell it.That last idea is the one that saves us the most work. We already apply it in the Go!Manage integration: the ERP runs the business, the shop is the window. Returns are no different — whoever decides to issue a credit note is whoever keeps the books, not the catalogue.
What does repeat in every case is the starting point: the native system switched on, so the request is recorded against the order instead of in an email, and whatever needs connecting goes on from there.
Turn on native returns and set the window to what you actually accept. Write the three routes out separately on your returns page, with their deadlines and with the country differences that apply to you, and stop arguing them case by case. Then spend a month noting the reason for every return by hand: at thirty lines you'll know whether you need to connect something or whether this is plenty.
If those thirty lines tell you it has to move somewhere else, tell us how you work and with which tools —the board, the ERP, the warehouse— and we'll tell you what's worth connecting and what isn't worth touching.
An electrical and plumbing supplies shop that takes price and stock from the Go!Manage ERP, product pages from…
Ready to boost your PrestaShop store? Let's discuss your project and create something amazing together.
Contact us now