Dolibarr POS: why the till has to be part of the ERP

A point of sale records what a shop or a restaurant just sold. When that record lives outside the ERP, you get two versions of the truth: one at the till, one in the accounts. A POS module for Dolibarr should close each sale as a native invoice, deduct stock and reconcile the payment in the same database, so nobody retypes figures at closing time.

What a POS is, and why the sale has to start inside Dolibarr

A POS is the screen your staff use to ring up a coffee, a pair of shoes or a table of four. Behind it sit four facts: what was sold, at what price, out of which stock, and how it was paid. Dolibarr already stores all four.

What matters is where the data is born. If the sale is created inside Dolibarr, the invoice, the stock movement and the payment are one event seen from three angles. Created elsewhere and pushed over later, they become three jobs that can each fail alone: the export crashes, or a product code is mapped wrong. Each failure surfaces days later as a number that does not match.

"The till has to be part of the ERP" is not about tidy architecture. It is about who owns the truth when two systems disagree at 21:30 on a Saturday.

What breaks when the till is a separate system

None look dramatic at first. They look like a difference someone fixes on Monday.

Stock that no longer matches the shelf

You sell the last jacket at the counter. The till knows; Dolibarr does not, because the sync runs tonight, or that product was never mapped. Next morning the online shop sells the same jacket and the count is wrong in two places. After a month of small items, the stock report is no longer worth acting on.

Invoices issued twice, or never

A separate till keeps its own numbering, and someone translates it into Dolibarr invoices. Export twice, you get duplicates. Skip it once, you get a gap. An invoice is not a line you can quietly edit. It carries a number other documents point at.

A cash drawer nobody can explain

If the session lives at the till and the payments live in the ERP, the daily count compares two systems instead of checking one. A few euros off could be a counter mistake, a payment recorded twice, or a rounding rule applied in one system only. You cannot tell, so you stop looking.

Returns that leave no trace

A customer returns a shirt. At the till it is a refund; in the ERP it should be a credit note and stock back into the warehouse. Disconnected, the money leaves the drawer, the stock never returns, and nobody notices until a physical count finds an extra unit.

What a POS module for Dolibarr has to do

Apply this list to any till you consider, ours included.

Close the sale as a native Dolibarr invoice. Not an export, not a CSV. The invoice exists in Dolibarr with its lines, taxes and numbering when the sale is confirmed.

Reconcile the payment, not only the total. Half cash, half card should produce two payments on the invoice, so reconciliation and the cash count read real data.

Deduct stock at the moment of sale, and put it back on a return. If stock moves only in a nightly job, availability is always a day old.

Open and close a cash session with a count. Opening float, movements during the shift, counted amount at the end, and the difference stated plainly. It points at a shift, not at a month.

Treat returns and vouchers as documents. A return reverses the sale and restocks. A voucher is a balance you can track, not a note in a drawer.

Cover tables, rooms and split bills if you serve food. Hospitality is not retail with chairs: a floor plan, tables that move between waiters, one bill split three ways without inventing fake sales.

Speak the language of the staff. A till is used under pressure by people who may not read the back office language.

TakumiPos is the POS from EasySoft Tech S.L. It exists as a desktop application for Windows, macOS and Linux, and as a module for Dolibarr. As a module, every sale closes as a native Dolibarr invoice, with payment reconciled and stock deducted. It covers counter and hospitality — tables, rooms, floor plan, split payments — plus cash sessions and counts, returns and vouchers. Eight languages, Dolibarr 14 to 24. The module page is in Spanish, and there is a Dolistore listing plus the module catalogue.

Where the core POS stops being enough

Dolibarr ships with TakePos. For a small shop with one counter it is a fair place to start: part of the core, it records sales, and trying it costs nothing extra. It gets thin when you need floor-plan tables, bills split across payers, a counted cash close, or a voucher balance you can follow. That is a scope question, not a criticism.

How to start without making a mess

Pilot on one till. Not the busiest, and not all of them. Run a single counter for a few weeks beside your current process and compare both at closing. Matching stock and cash is real evidence.

Clean the master data first. A till inherits whatever state your catalogue is in: duplicate references, products with no warehouse, tax rates typed by hand. All of it lands at the counter, in front of a customer.

Train the people who close the shop. Half an hour with them beats a manual nobody opens. Show the count, the return and a failed payment.

Check whether you need an ERP behind the shop. If you are still deciding, this shop-to-ERP checklist helps, and it is in Spanish too.

Decide how many companies and tills you will run before creating separate installations: read Dolibarr multi-company.

Read up on stock corrections before month one. The mechanics are in stock adjustments in Dolibarr.

FAQ

Can I use a POS with Dolibarr without changing my accounting? A module that creates native invoices writes into the data your accountant already reads. You add an entry point, not a second ledger.

Does it work for a restaurant, or only retail? It should do both. For restaurants the difference is tables, rooms and split bills; for retail, barcode speed and quick returns. Check that tables are handled properly.

What happens to my stock if the connection drops? Ask before you buy. A desktop till on a local Dolibarr rides out a connectivity problem; a browser-only till does not. Both can be fine, as long as you know which you get.

Do I have to migrate my old sales history? Usually not. Start the new till from a clean date and keep the old system readable while you need it. Moving years of tickets rarely pays off.