KSIDol documentation > KSIDol modules > Store (KSIRetail)

Module guide: Store (KSIRetail)

A non-technical guide: what the module does, how to use it day to day, and how it fits together with Dolibarr.

Tabs added to native records13

Dedicated permissions17

Available languages5 (650 keys each)

Dolibarr compatibilityv18 to v24

1. Module overview

KSIRetail turns Dolibarr into a full-featured store point of sale, without ever stepping outside its native objects: products, stock, invoices, credit notes, and supplier orders stay the same ones you already know. At the counter, barcode-scanned sales, logged cash sessions, and secured closings meet the requirements of France's anti-fraud VAT rules. Behind the scenes, inventories, transfers, receiving, and replenishment work hand in hand with native warehouses and supplier orders. Loyalty, gift cards, promotions, and online sales connectors round things out, for a store run end to end from inside Dolibarr.

A scan-first point of sale, built for speed at the counter
Logged cash sessions and sealed closings, aligned with NF525 requirements
Multiple barcodes per item and label printing straight from the browser
Store-by-store inventories, transfers, and receiving, on native Dolibarr stock
Automatic replenishment calculations, with returns and credit notes tied to native invoices
Loyalty program, gift cards, and targeted promotions
Online sales connectors, with no copy of your data leaving Dolibarr
Available in 5 languages, compatible with Dolibarr v18 through v24

2. Built on Dolibarr, nothing duplicated

KSIRetail doesn't create a parallel system: it plugs straight into the objects you already use.

Products, stock, invoices, payments, credit notes, and supplier orders remain Dolibarr's native objects: nothing is duplicated in a separate database.
The module adds 13 tabs to existing records (thirdparties, invoices, products, suppliers, supplier orders, receptions, warehouses, users...) rather than creating isolated new screens.
17 separate permissions let you give each person exactly what they need, without an all-or-nothing switch.
The POS module (TakePOS) and the Receptions module aren't forced on you: each is turned on separately as needed.

3. Stores, registers, sellers, and scan-first checkout

Three ideas structure day-to-day use: the store, the register, and the seller running it — with the checkout screen built for speed.

Each store is linked to a Dolibarr warehouse: the store's stock is that warehouse's native stock, not a copy. This link is required before a register can even open.
Each register is tied to a TakePOS terminal number.
A seller can be assigned to one or several stores, with a role and a default store.
The register only opens if the logged-in seller is assigned to the matching store.
At the counter, the cursor sits straight in the barcode-scanner field, with product thumbnails tucked behind a Catalog button so scanning stays fast.
The setup is flexible: display density, numeric keypad, scan-first or keyboard-first mode — each store or workstation can be tuned to its own use.

4. Cash sessions and NF525-compliant closings

Every register day opens and closes within a logged framework, built to hold up under a tax audit.

At opening, the seller declares a starting cash float. Every cash movement during the day, in or out, must carry a reason and is timestamped.
These events are chained by a cryptographic fingerprint: each movement carries the trace of the one before it, which makes any silent rewriting of the history detectable.
At closing, the module compares, for each payment method (cash, card, check), the expected amount, the declared amount, and the gap between the two.
Closing produces a sealed, numbered archive, exportable as JSON.
If Dolibarr's native tamper-proof logging module (blockedlog) is active, a closing that's already been logged can no longer be deleted — only reopened.
This meets the security, tamper-proofing, and record-keeping requirements of France's anti-fraud VAT rules. It isn't a certification on its own: that depends on a properly configured — and where required, duly certified — Dolibarr installation, a separate process specific to your setup, not something the module provides by itself.

5. Barcodes, labels, and catalog import

Each item can carry several codes, and a CSV import saves re-keying a whole catalog by hand.

Internal code, EAN-8, EAN-13, UPC-A, ISBN-13, Code 128, QR code, supplier code: several codes can coexist on the same item.
The check digit is validated for standardized numeric codes (EAN, UPC, ISBN); other formats (internal, Code 128, QR, supplier) aren't checked this way.
A sheet of labels prints straight from the browser, from 1 to 100 copies of the same code at a time.
The import file must follow 11 documented columns with a header that matches exactly: one unrecognized column rejects the whole file, to avoid silent partial imports.
A preview is shown before anything is committed.
Import creates or updates products, prices, and native Dolibarr codes. It doesn't touch stock, categories, or photos — those stay managed separately.

6. Store-by-store inventories and blind double counts

Inventory relies on Dolibarr's native inventory object but runs store by store, with an optional blind double count for extra accuracy.

Counting is done by scan, either adding to or replacing the current quantity, whichever fits your workflow.
Lots and serial numbers are supported.
Nothing moves in stock until the inventory is finally posted: you can count and recount without risk.
For a sensitive count, two people can count the same area without seeing each other's figures.
Differences between the two counts must be reconciled by hand before being posted to the native Dolibarr inventory: no figure is validated automatically.

7. Transfers between stores and supplier receiving

Moving stock between stores and receiving from suppliers both go through a tracked, scan-based workflow.

A store-to-store transfer passes through a dedicated transit warehouse.
The receiving store checks the goods on arrival and records a reason for any discrepancy found.
Stock not yet received stays visible in the transit warehouse until its own movement closes it out — there's no automatic write-off, tracking stays in the team's hands.
A supplier order can be received by scan, straight from the shipped order, and can be split across several passes if goods arrive in batches or several people are involved.
Stock only moves once the native Dolibarr reception is validated, which keeps a record of the store and warehouse involved.

8. Store-by-store replenishment

A replenishment run works out, store by store, what needs reordering.

The calculation factors in current stock, stock in transit, orders already placed through the module (not every existing supplier order), the average daily sales seen at the register, plus the lead time and pack size pulled from native supplier price lists.
Every suggested line can be edited or dropped, as long as a reason is given.
Native supplier orders are created grouped by supplier, left as drafts for approval.

9. Customer returns and credit notes

A return always starts from an already-validated invoice, never from a free-form entry.

This feature assumes a Dolibarr setup where stock is decremented on invoice validation (the native STOCK_CALCULATE_ON_BILL setting), the same way register sales assume TakePOS: a stated requirement, not a hidden one.
The module checks the remaining returnable balance before accepting the return.
A native Dolibarr credit note is created and validated, linked to the return, without ever touching the original invoice.
The item either goes back on the shelf or into quarantine, based on a reason entered each time.

10. Loyalty program and gift cards

Loyalty and gift cards both build on records you already have in Dolibarr, rather than a separate customer database.

Loyalty accounts are tied to native thirdparty records, not a separate customer database.
Earning points is a manual action from the customer record, based on a scale you set yourself — it doesn't trigger automatically on every paid invoice.
Points convert into a native Dolibarr fixed discount, never into a parallel payment method.
Points carry an expiry date; expiring them is handled by a dedicated action, not an automatic scheduled task.
Each gift card has a balance and a reviewable movement log.
The card's code is shown only once, at creation; afterwards it's stored as a hash, never in plain text.

11. Targeted promotions and discounts

Promotions can be fine-tuned to target exactly what you want to highlight.

Discount percentage, validity dates, minimum quantity, priority between rules, and targeting by store, product, product category, or customer category.
When several rules qualify, only the best one applies.
A better manual discount entered at the register is always preserved — it's never overridden by an automatic promotion.
Every promotion applied is logged.

12. Online sales and connectors (omnichannel)

KSIRetail can talk to an online shop or another sales channel without your data ever leaving your Dolibarr installation.

Three services are available: receiving an order, reporting back its status, and publishing a store's available stock.
Orders coming from the web arrive as native Dolibarr draft orders, set for pickup or delivery as appropriate.
If a shop sends the same order twice, it's only processed once.
On a conflict, the order is quarantined and logged in a sync journal for manual handling.
Published stock is the native stock figure, minus a safety threshold and any quantities already reserved.
Each connector has its own internal account, so it's always clear who did what.
This feature requires Dolibarr's native REST API module to be active.

13. Dashboard

New in version 0.5.4, a dashboard gives an at-a-glance overview of activity.

Today's sales, registers currently open, month-to-date revenue, unpaid invoices, and a list of stores and loyalty accounts.
A 6-month activity chart cross-references revenue against cashed-in sales.
Current promotions and the day's open items (pending quotes, unpaid invoices) round out the view.

14. Compatibility and languages

KSIRetail is built to fit into your installation for the long run, whatever its version or working language.

Compatible with Dolibarr versions v18 through v24.
Available in 5 languages, with roughly 650 translation keys each: no text is hard-coded.
Aside from the three exchange services with an online shop, the module makes no outbound network calls of its own: your data stays inside your Dolibarr installation.

15. Links with Dolibarr

The module does not work in isolation: it integrates with the native building blocks of Dolibarr.

Thirdparties : Loyalty accounts and gift cards are tied to native thirdparty records, with no separate customer database.
Products and services : Items sold in store remain native Dolibarr products and services, with their own barcodes and prices.
Stock and warehouses : Each store is linked to a native warehouse: the store's stock is Dolibarr's own stock, not a copy.
Invoices : Cashed-in sales are recorded as native invoices; returns always start from an already-validated invoice.
Credit notes : An accepted return creates and validates a native Dolibarr credit note, linked to the return, without touching the original invoice.
Supplier orders : Replenishment creates native supplier orders, grouped by supplier and left as drafts.
Receptions : A scanned receiving validates a native Dolibarr reception, which keeps a record of the store and warehouse.
Users : Each seller remains a Dolibarr user, assigned to one or more stores with a role.