A POS and inventory system should connect a sale to the correct stock movement, represent returns clearly and let staff reconcile the session without changing totals blindly. Compare the transaction trail rather than choosing only by the till interface. A payment receipt, stock balance and credit note answer different questions and need to remain traceable to one another.
Odoo POS and ERPNext provide documented examples for evaluating this connection. Odoo describes stock movements, refunds and session closing. ERPNext’s Stock Ledger describes movement history linked to source vouchers. These are useful comparison points; they do not establish which system is best for every retailer or prove a particular installation is ready. Odoo POS, ERPNext Stock Ledger.
What should a POS and inventory comparison include?
Describe the shop’s actual transactions: a straightforward sale, a quantity change before payment, a partial return and a stock correction. Identify the locations and sales units involved. If a product is sold individually but received in packs, include that distinction in the demonstration rather than leaving it for migration day.
Also distinguish inventory from cash control. An accurate drawer count does not prove that stock is correct. A stock movement does not prove that payment settled. The test should follow each record through its own evidence route and then check the links between them.
Avoid universal claims about offline operation or automatic synchronisation. Odoo documents temporary offline browser use, but the cited page does not measure your network, payment terminal or reconnection behaviour. Ask the candidate to demonstrate the complete interruption and recovery case appropriate to the intended setup.
How do the documented approaches compare?
| Evaluation area | Odoo POS documentation | ERPNext documentation | Decision question |
|---|---|---|---|
| Stock effects | POS product moves are registered in stock | POS profile needs a warehouse; closing entry posts stock and accounting | Which warehouse changes, and at which stage? |
| Return evidence | Refund flow can reference the original order | Ledger can trace stock-affecting vouchers | Are quantity and money effects distinguishable? |
| Retail sales documents | POS workflow joins selling and payment steps | POS creates paid retail invoices with payment and stock effects | Does the invoice trace the same sale and payment? |
| Session close | Expected totals grouped by payment method | Select POS profile and closing period, then submit the closing entry | Are count differences and ledger postings explainable? |
The sales rows now use ERPNext’s actual POS workflow and Sales Invoice documentation alongside Odoo POS. ERPNext describes choosing a profile and customer, adding items, selecting a payment mode and creating the POS Invoice. Its closing workflow separately describes stock and accounting postings. Test the timing in the intended configuration rather than assuming both products post every effect at the same stage. ERPNext POS workflow, ERPNext sales invoices.
Separately, on the purchasing side, ERPNext’s buying guide warns against updating stock again where a purchase receipt has already recorded the goods. A stock-updating purchase invoice concerns incoming goods, whereas a POS sale concerns outgoing goods. Use the duplicate-receipt example as a separate receiving test; it cannot establish how ERPNext handles POS sales, refunds or session closing. ERPNext buying workflow.
How should a return be demonstrated?
In Odoo’s documented refund route, the operator opens a session, selects the relevant order, chooses returned quantities and completes the refund payment method. Its documentation says a validated return payment generates a credit note referencing the original receipt or invoice.
Ask the demonstrator to return only part of an order. Inspect the remaining sold quantity, returned quantity, payment record and original reference. Then ask where the returned goods went. Saleable stock, damaged stock and goods awaiting inspection should not be treated as the same business outcome merely because a refund was created.
The cited POS page does not establish your shop’s returns policy or a universal automatic disposition for damaged goods. State the intended policy separately and test its configuration. A customer receiving a refund is not proof that the item has been inspected or is suitable to sell again.
Why does session closing need a separate record?
Odoo’s closing control includes expected amounts grouped by payment method. That supports a useful distinction between the system’s expected totals and the operator’s counted evidence. A difference should prompt investigation rather than an unexplained adjustment to make the session close.
The POS documentation also describes cash-in and cash-out entries with a reason. Include these in the demonstration so staff can distinguish a sale from a drawer movement. Otherwise a legitimate withdrawal can appear to be missing sales revenue, or an unexplained difference can be hidden as a cash adjustment.
Where several users share a session, establish how actions remain attributable in the intended configuration. Odoo allows multiple users in a session; that fact does not prove the business has enabled the accountability controls it needs. Record the actual operator information available in the tested environment.
A sale-return-close worksheet
Use this original worksheet for a controlled test product:
Opening stock evidence: product, unit, location and starting quantity reference.
Sale evidence: order or receipt identifier, quantity sold, selected payment method and resulting stock movement.
Return evidence: original sale reference, returned quantity, financial reversal record and destination of goods.
Cash movement evidence: non-sale entries with reasons and authorisation.
Closing evidence: expected totals by method, counted totals and unresolved differences.
Stock reconciliation: opening quantity plus accepted receipts and returns, less outgoing quantities and approved removals, compared with the observed balance.
Investigation: source document behind each discrepancy, action owner and next check.
The quantity relationship is an editorial reconciliation aid. It is not a claim that all returns should increase saleable stock or that every platform uses identical document names. Adapt it to the shop’s agreed stock categories while preserving the evidence links.
What should you reject during selection?
Reject a demonstration that changes a stock total without explaining the originating document. Ask for an ordinary user to investigate a discrepancy rather than letting an administrator repair it invisibly. Also reject a return demonstration that ends at a receipt printer without showing the stock and financial results.
Do not award a product credit for controls that exist only in a proposed customisation. Record “documented”, “demonstrated”, “requires configuration” and “not yet evidenced” separately in the selection notes. This helps compare a ready workflow with a development promise without pretending they carry the same certainty.
Before migration, agree the opening stock evidence, outstanding returns and the session boundary. Keep unresolved differences visible so they do not become unexplained starting balances in the new system.
Discuss the shop workflow through Spout’s web development service or start an enquiry with the worksheet and candidate systems.
By Spout Team. Prepared with AI-assisted drafting using the linked primary documentation.