odoo 19 · Switzerland · sublicensing for odoo partners
Bestandsverfahren in Odoo.
Continuous inventory accounting wired to the Swiss Kontenrahmen KMU: goods receipt through a received-not-invoiced clearing account, cost recognised at goods issue, and no cost-of-sales line on the customer invoice.
$ odoo -i l10n_ch_stock_account_method_a ✓ ready
the problem
Odoo doesn't post inventory the way your clients' accountants expect.
To be clear about the legal position: OR Art. 958c requires only that positions be substantiated durch ein Inventar oder auf andere Art — continuous posting is not mandated. But most Swiss clients keep their stock accounts that way, and their Treuhänder expects to see it. Odoo out of the box does not.
01 / CLEARING
No clearing account
Goods receipt doesn't run through an account that clears back to zero when the vendor bill posts. The “delivered but not yet invoiced” reconciliation isn't there.
02 / COST
Cost recognised too late
By default the expense lands on the customer invoice instead of at goods issue, so stock and cost drift apart within the period.
03 / EFFORT × N
Rebuilt every time
So every partner builds it again — per client, per chart of accounts, and once more after each upgrade. That is the work this package removes.
the postings
Four steps, cleanly reconciled
Goods receipt debits the stock account against the clearing account. The vendor bill clears it back to zero. Cost is recognised at goods issue, not at invoicing.
Stocktake differences post to defined accounts, and at period end the clearing balance is reclassified as uninvoiced deliveries.
FIFO weighted average standard price
goods receipt .... Dr 1200 / Cr 1290
vendor bill ...... Dr 1290 / Cr payables → 0
goods issue ...... Dr 4200 / Cr 1200
customer invoice . no cost-of-sales line
stocktake diff ... defined accounts
✓ clearing account back to zero.
$
1200 Waren, 1210 Rohstoffe, 4200 Materialkosten Handel, and 1290 Wareneingang ohne Rechnung as the clearing account — created by the module, since the KMU chart ships none. A separate Warendrittel layer is available for the fixed-record-price case.
timing and cut-off
When cost is recognised — and how to keep the cut-off clean
Method A recognises cost at goods issue. Where local law does not prescribe a posting pattern, IAS 2 and its local transpositions recognise cost in the period in which the related revenue is recognised. For merchandise sold ex works or FOB shipping point the two coincide, the dates are the same, and the postings are identical.
Where they diverge — a despatch that crosses a period end, FOB destination terms, bill-and-hold, consignment — it becomes a cut-off question rather than a posting-pattern question, and one your client's accountant should settle rather than the software. We would rather say that plainly than pretend it never comes up.
If that cut-off matters to your clients, the period-end close can be extended with a delivered-not-billed reclassification, so both bases agree at every period end. That is not part of the package today — tell us it matters to you and we will scope it together.
what you get
One module you need, and layers you add only if the client does
The base localisation is the whole of method A on its own. Everything else is optional — install a layer only where a client actually needs it, and leave it out everywhere else. Nothing degrades if you never install them.
Runs on Odoo Community and Odoo Enterprise — the modules depend only on Community standard modules (stock_account, mrp_account, l10n_ch), so they work wherever your clients already are.
BASE — REQUIRED
Perpetual inventory
Goods and raw materials, clearing account, cost at issue, stocktake differences and the period-end reclassification. This is the module.
MRP — OPTIONAL
Own production
Only for clients that manufacture. Finished goods and work in progress with their own stock and income accounts.
WAREHOUSE — OPTIONAL
Per-warehouse valuation
Only for clients running several warehouses — and even then, cost and accounts are two separate opt-ins. See below.
optional · per-warehouse valuation
Two separate opt-ins: whose cost, and whose stock account?
Neither of these is switched on by default, and most clients never need either. Clients running several warehouses tend to hit two distinct problems, so they install as two independent layers — you can take one without the other.
Optional: cost per warehouse. Each warehouse runs its own cost pool alongside Odoo's company-level engine — weighted average and standard price at (product, warehouse) granularity, plus per-warehouse FIFO layers. An issue is valued at the source warehouse's own cost, and an inter-warehouse transfer carries that cost with the goods instead of re-averaging centrally. Any product category can opt back out and stay centrally costed.
Optional: stock account per warehouse. Separately, each warehouse can post to its own balance-sheet account instead of the category's single company account. The statutory account class is preserved — the warehouse only adds a sub-account dimension. Transfers then post debit destination / credit source, with two-step transfers flowing through transit. Idempotent on re-run, so adding a warehouse later is safe.
Splitting cost without splitting the balance sheet is a perfectly reasonable setup, and a common one. Because the postings genuinely change once stock is split this way, this layer ships its own interactive cheat sheet, separate from the main one. Both are linked below.
tested
Every module ships with its own test suite
234 test methods across 75 test files — and not one module in the family without tests. The engine carries 31 on its own, the per-warehouse cost layer 10, the account split 20, and each country localisation adds its own on top.
They assert the postings, not just that the code imports: that the clearing account nets back to zero, that cost lands at goods issue and not on the invoice, that a transfer moves value between the right two accounts. When you deploy this at a client and own the support afterwards, that is worth more than any feature list — you can run the suite after every upgrade and know within a minute whether anything shifted.
not only Switzerland
19 countries, one principle
The same engine, wired per country to the national chart. If you serve clients across borders, one package covers all of them — and in Poland, Portugal and Romania perpetual inventory carries an explicit statutory basis on top.
Germany Austria Switzerland Netherlands United Kingdom Ireland Denmark Sweden Norway Estonia Latvia Lithuania Poland Czechia Slovakia Hungary Slovenia Croatia Romania Bulgaria Portugal
demo
Try it yourself
A Switzerland sample company on Odoo 19 Enterprise with the national chart and a fully posted goods cycle: receipt, vendor bill, goods issue, stocktake difference. Inspect the journal entries directly in the general ledger.
The demo resets every two days — try anything you like.
Open the demoCheat sheet — postingsCheat sheet — per warehouse
Would you rather have your own sandbox?
The shared demo is fine for a look around, but if you want to load your own data, try an upgrade, or show a client something concrete, we will set up a private instance for you — not shared with anyone, and not reset every two days.
url ...... https://demo.datadance.eu
login .... demo-ch
password . methoda2026
company .. Sample company (Kontenrahmen KMU)
✓ Resets every 2 days, 03:00 CET.
for odoo partners
Buy once. Deploy across your client base.
We offer this package as a sublicense for Odoo partners: you acquire it once and deploy it at your clients — instead of rebuilding it per project or licensing it per client.
Scope, country selection, support and version maintenance are all open to discussion. Every partner works differently — one needs only one market, another twelve countries and a maintenance agreement. Tell us what would work for you, and we will see whether we can meet it.
who is behind it
Data Dance s.r.o.
Odoo consulting and development from Slovakia, doing Odoo and nothing else. We are the only Odoo Community Association member, contributor and supporter in Slovakia and Czechia — the code we give back is the same code our clients run on.
Inventory valuation is one piece of a much larger integration practice. What we build and maintain in production:
EDI & E-INVOICING
A shared EDI engine with concrete connectors — EDITEL EDIFACT over eXite SOAP, GRiT over the Orion OAuth2/REST API — for sales and purchase order flows with retail chains, dispatched asynchronously through queue jobs. Plus Peppol BIS Billing 3.0 send and receive via the eXite access point, and ISDOC for Czechia including advance invoices.
SHIPPING & LOGISTICS
Eleven carrier integrations — Packeta, DPD, PPL, GLS (MyGLS), Balikobot, Slovak Post, SPS, SDS, TopTrans, Wolt Drive — with cash on delivery, backend label printing via PrintNode, and pickup-point selection built into the eCommerce checkout.
PAYMENTS
Online gateways — GoPay, Comgate, Pays.cz and Nexi XPay — alongside Comgate payment terminals in the point of sale (including the CloudPOS 2.0 API), fast-terminal flows and tipping. Payment QR codes for Pay by square (SK) and QR platba (CZ), on invoices and at the till.
BANKING & FISCAL
Statement import (GPC, MultiCash), ISO 20022 / SEPA payment orders with local payment symbols, and fiscalisation for EET (CZ) and VRP2 (SK) including POS.
DOCUMENTS & DATA
ONLYOFFICE for editing documents, reports and templates directly in Odoo. ARES (CZ) and Finstat (SK) partner lookups, VIES validation, payment-reliability checks, POHODA export for clients whose accountant stays on POHODA, and SMS gateways.
PAYROLL & STATUTORY
Full CZ and SK payroll with the statutory filings that go with it — and the CZ/SK accounting localisation this inventory package grew out of.
We build these modules because we need them ourselves. They stay maintained because our own projects run on them.
edi_editel (eXite) ....... ok
edi_grit (Orion) ......... ok
peppol_bis3 .............. ok
account_edi_isdoc ........ ok
delivery × 11 carriers ... ok
gopay/comgate/pays/nexi .. ok
pay_by_square / qr_platba ok
eet2 / vrp2 (fiscal) ..... ok
onlyoffice ............... ok
stock_account_method_a ... ok
✓ 19 countries. ready to dance.
$
sublicense
Tell us what you need.
A few lines are enough. Say which countries matter to you and roughly what scope you have in mind, and we will take it from there. A private sandbox is yours for the asking — just mention it in the message.
$ dd sublicense --market ch