# Radical Fanatics - full content export



> Odoo Gold Partner in Amsterdam. ERP implementation for mid-sized companies.

> Generated from the live content collections. See https://www.fanatics.nl/llms.txt for the index.



================================================================

KNOWLEDGE BASE

================================================================

# How does the TARGET method work in practice?
URL: https://www.fanatics.nl/help/how-the-target-method-works
Language: en

The **TARGET method** is how we run Odoo projects. Not dreamed up behind a desk, but refined across 80+ projects over 25 years. Six steps:

## T, Top management on board

Without commitment from the owner or directors, every Odoo project stalls. So step 1 is simple: we make sure top management is in the kick-off, knows what it delivers, and commits to the weekly check-ins.

## A, Analysis up front

A **[Quick Scan](/scan)**, 1 to 3 days in which we walk through your processes, map the gaps, and set concrete goals. No 87-page report, just a workable list of goals.

## R, Risk first

Which parts of the project carry risk? That is where we start. **Not** with the easiest bit first to claim a quick win. Risky pieces first, because if they only surface at the end, the project derails.

## G, Geared check-ins

Weekly stand-ups of **30 minutes max**. Fixed agenda: what is done, what is blocked, what is next week. No status reports, just actions.

## E, Expert sessions

When a team gets stuck on a specific point (HR law, manufacturing logic, an integration), we set up a short expert session with the right people. Not a broad meeting, a focused hour with the people who can hand you the answer.

More: [Make fast progress with expert meetings](/blog/expert-meetings-en).

## T, Tracking

Oversight is the backbone. We track progress in Odoo itself (the Project module) or in Trello, whichever your team prefers. What matters: it happens **consistently**, not only when there is a crisis.

More: [Keeping track, how to stay on course](/blog/keeping-projects-on-track).

## What it is not

- No Agile rituals, no Scrum Masters, no story points.
- No steering on hours, we steer on delivered phases.
- No jargon for the sake of jargon.

## What it is

A workable approach you can run alongside your day job, even without a PM certificate. We bring the discipline. You bring the knowledge of your business.

More detail at [/target](/target).


# What does Odoo cost per month?
URL: https://www.fanatics.nl/help/how-much-does-odoo-cost
Language: en

Odoo's pricing model is simple and transparent, one of the reasons we work with it.

## The licence price

**One App Free:** Free for unlimited users, but limited to a single app (e.g. CRM only or Inventory only). No implementation partner needed for simple setups.

**Standard plan:** From ~€20 per user per month. Includes **all 80+ modules**, no surcharge per extra app. Hosting is Odoo SaaS (cloud, managed by Odoo).

**Custom plan:** Realistically ~€35 per user per month for most Radical Fanatics clients. This plan covers:
- Running [custom code](/odoo-custom-development) on [Odoo.sh](https://www.odoo.sh/) or self-hosted
- Optional Odoo.sh hosting (included in the plan)
- Enrichment credits (address enrichment, email validation) and OCR credits (invoice scanning): low usage costs on top of the base price

Prices are indicative. Odoo sometimes offers volume discounts for companies with 50+ users. Always request a current quote from Odoo or your partner.

## The implementation cost

Depends on scope. Our ballpark:

- **Small implementation** (1–3 modules, 5–15 users): €15,000–€35,000
- **Standard implementation** (4–6 modules, 15–50 users): €35,000–€85,000
- **Large implementation** (7+ modules, 50+ users, custom work): €85,000+

This is our time, not the Odoo licence. We work in phases and you pay per delivered phase, no one-big-sum up front.

## Ongoing support & upgrades

Optional. Cancellable monthly, no fine print. Built from:

- **Base fee:** ~€250 per month (access, monitoring, patch management)
- **Per user:** €10–€20 per month, depending on the SLA and availability you want
- **Updoo modules or custom work:** an optional monthly fee to maintain custom modules or integrations we have built

Total support cost for an average 20-user company lands between €450 and €650 per month.

## What we don't charge

- No "intro fee" for the scan.
- No integration licences: we build integrations ourselves, so no middleware vendor in the mix.
- No subscription on our custom modules: they are yours once paid for.

Want a real estimate for your situation? Try the [ROI calculator](/pricing/calculator) or [book a scan](/scan).


# Kun je Odoo koppelen aan Exact of Twinfield?
URL: https://www.fanatics.nl/nl/help/koppelingen-exact-twinfield
Language: nl

Veel klanten draaien hun boekhouding in **[Exact Online](/odoo-exact-integration)** of **[Twinfield](/odoo-twinfield-integration)** en willen die niet (meteen) migreren. Geen probleem, we bouwen koppelingen die werken.

## Wat we koppelen

### Vanuit Odoo naar Exact/Twinfield
- **Verkoopfacturen**, automatisch geboekt zodra ze definitief zijn in Odoo.
- **Inkoopfacturen**, gescand of geüpload in Odoo, geboekt in Exact/Twinfield.
- **Klantgegevens**, nieuwe klanten in Odoo CRM landen ook in je boekhouding.
- **Producten en grootboeknummers**, eenmalige sync of doorlopend, afhankelijk van wens.

### Vanuit Exact/Twinfield naar Odoo
- **Betalingsstatus**, als een factuur is betaald, ziet Odoo dat ook.
- **Banktransacties**, voor reconciliatie tussen verkoop en betaling.

## Hoe het werkt

Onze koppelingen draaien op **Cloudflare Workers** (eigen infrastructuur) of als **Odoo-module** met directe API-call. We schrijven de code zelf, geen middleware-vendor erbij. Logs gaan naar een dashboard zodat je elke transactie kunt terugzien.

## Alternatief: migreren naar Odoo Accounting

Veel klanten kiezen er na een jaar voor om hun hele boekhouding naar Odoo te migreren. Voordelen:

- **Eén systeem**, geen koppeling om te onderhouden.
- **Lagere licentiekosten**, Exact/Twinfield-abonnement valt weg.
- **Diepere integratie**, projecten, voorraad, productie zien direct de financiële kant.

We helpen je deze keuze maken op basis van schaal, complexiteit en compliance-eisen.

## Andere koppelingen die we doen

- **[vPlan](/odoo-vplan-integration)** (capaciteitsplanning)
- **[Nmbrs](https://www.nmbrs.nl/) / [Loket](https://www.loket.nl/)** (salarisverwerking)
- **[Magento](https://business.adobe.com/products/magento/magento-commerce.html) / [Shopify](/odoo-vs-shopify)** (webshop ↔ Odoo)
- **TimeChimp / Hubstaff** (urenregistratie)
- **[Mollie](https://www.mollie.com/nl) / [Stripe](https://stripe.com/)** (betalingen)

Iets dat hier niet staat? Stuur een mail naar [team@fanatics.nl](mailto:team@fanatics.nl), als het een open API heeft, kunnen we het koppelen.


# Getting started with Odoo Accounting: opening balance and open items
URL: https://www.fanatics.nl/help/odoo-accounting-getting-started
Language: en

Below are the steps and points of attention for going live with Odoo Accounting.

**Download:** [Odoo Accounting go-live checklist (PDF)](/kb/accounting-getting-started/odoo-accounting-go-live-checklist.pdf)

We usually follow this short checklist:

1. Close as many receipts, deliveries and manufacturing orders as possible.
2. [Import the open customer and supplier items](/help/import-file-open-items).
3. Import stock as an inventory adjustment.
4. Import the trial/opening balance (or enter it manually).
5. Add and connect your banks. Check that the balance reconciles with the opening balance.
6. Import assets via the fixed-asset import model and check that the various accounts reconcile with the opening balance. See the article [Import fixed assets into Odoo](/help/import-fixed-assets).
7. Enter stock quantities (make sure every product has a cost price) and check that it reconciles with the opening balance.

The video below by Kevin Zaki is a handy guide.

| Level | Topic | Link |
|---|---|---|
| Advanced | Starting balance | [YouTube](https://www.youtube.com/watch?v=Rdjh3j9c1DY) |

Timestamps in the video:

- Preparation up to minute 10
- From 10:00: importing products
- From 11:00: importing general-ledger accounts (adjustments)
- From 17:00: importing stock
- From 18:05: importing sales invoices
- After that: importing purchase invoices

Note: in the example Kevin uses accounts 777777 and 888888 as the suspense account for importing the open items. These are not existing accounts in the standard Odoo chart of accounts. Pick a different P&L account for this.

We prefer to create two temporary balance-sheet accounts that sit close to the receivables and payables accounts. To do so, copy the receivables and payables ledger accounts to, for example: **110001 Receivables opening balance** and **130001 Payables opening balance**.

## Importing sales invoices

The procedure for purchase invoices is almost identical. Prepare the import file as shown in the video.

The standard Dutch chart of accounts in Odoo uses ledger number 110000. From the opening balance, however, we do not want to post here directly. We want to create a credit amount on a balance-sheet account equal to the debit amount you will post for the total of the open sales invoices when posting the opening balance.

To import the open items you use an extra 'receivables account' that serves as a temporary suspense account, for example account **110001**. The 'revenue' is posted here when the invoices are imported. On import you then get the entry:

```
110000 Receivable
    to 110001 Total outstanding / 'revenue' (do not post VAT)
```

Your chart of accounts then looks like this:

![Chart of accounts with temporary suspense account 110001 for the opening balance](/kb/accounting-getting-started/img-1.png)

When you enter the opening balance, account 110001 is reversed (debited) again. The open items are now outstanding and can be reconciled against the bank.

The import file in Excel might look like this:

| Number | Partner | Invoice_date | Due Date | Reference | Unit Price | Label | Account |
|---|---|---|---|---|---|---|---|
| INV/2022/00001 | Deco Addict | 2022-12-08 | 2022-01-07 | S00003 | 22137,5 | Opening balance | 110001 |
| INV/2022/00002 | Deco Addict | 2022-12-08 | 2022-01-07 | S00002 | 48012,5 | Opening balance | 110001 |
| INV/2022/00003 | Azure Interior | 2022-12-01 | 2022-01-31 | S00001 | 36512,5 | Opening balance | 110001 |
| INV/2022/00004 | Deco Addict | 2022-11-30 | 2022-12-30 | S00004 | 36512,5 | Opening balance | 110001 |

**Note:** an important extra column to add is **Invoice Lines / Taxes**. Leave this column empty. If you do not, VAT is added to the line based on the customer's fiscal position, which throws off the amount.

Then go to the Customer Invoices journal and start the import there.

**Note:** if the invoice numbers are not sequential, you will get an error after importing that the invoice numbers are not consecutive. In that case, create a new journal named **Customer Invoices (Opening balance)** and import the invoices there. Once done, you can archive that journal. For credit notes, add an extra **Journal_ID** column and enter Customer Invoices (Opening balance) there.

![Import screen for sales invoices in the Customer Invoices (Opening balance) journal](/kb/accounting-getting-started/img-2.png)

![Field mapping during the import of the open sales invoices](/kb/accounting-getting-started/img-3.png)

After importing, you still need to post the open items (Post Entries):

![Posting the imported invoices with Post Entries](/kb/accounting-getting-started/img-4.png)

If you now open one of the invoices and go to the Journal Items tab, you see the entry created for that item:

![Journal Items tab of an imported invoice with the contra entry](/kb/accounting-getting-started/img-5.png)

The total of all imported open items is now both debit on account 110000 Receivables on the balance sheet and credit on 110001 Receivables (opening-balance suspense), in our example for an amount of € 143,175.00.

![Balance of open items, debit on 110000 and credit on 110001](/kb/accounting-getting-started/img-6.png)

When you post the opening balance, 110001 is reversed again.

## Need a hand with your switch?

Stuck on the opening balance or the open-item import? [Book an Odoo scan](/scan) or [get in touch](/contact) - we will take a look with you.


# Odoo Accounting in gebruik nemen: beginbalans en openstaande posten
URL: https://www.fanatics.nl/nl/help/odoo-boekhouding-beginbalans
Language: nl

Hieronder vind je de stappen en aandachtspunten voor wanneer je Odoo Accounting in gebruik wilt nemen.

**Download:** [Odoo Accounting go-live checklist (PDF)](/kb/accounting-getting-started/odoo-accounting-go-live-checklist.pdf)

Wij hanteren meestal de onderstaande verkorte checklist:

1. Sluit zoveel mogelijk ontvangsten, leveringen en productieorders.
2. [Importeer de openstaande posten](/help/importbestand-openstaande-posten) debiteuren en crediteuren.
3. Importeer de voorraad als voorraadaanpassing.
4. Importeer de proefbalans/openingsbalans (of voer deze handmatig in).
5. Voeg banken toe en koppel ze. Controleer de aansluiting met het saldo op de beginbalans.
6. Importeer de activa via het importmodel voor vaste activa en controleer de aansluiting van de diverse rekeningen op de beginbalans. Zie hiervoor het artikel [Vaste activa importeren in Odoo](/help/vaste-activa-importeren).
7. Voer de voorraadaantallen in (zorg dat de kostprijs bij alle artikelen is ingevuld) en controleer de aansluiting op de beginbalans.

De onderstaande video van Kevin Zaki is een handige leidraad.

| Niveau | Onderwerp | Link |
|---|---|---|
| Advanced | Beginbalans / Starting balance | [YouTube](https://www.youtube.com/watch?v=Rdjh3j9c1DY) |

Tijdstempels in de video:

- Voorbereidingen tot minuut 10
- Vanaf 10:00: producten importeren
- Vanaf 11:00: grootboekrekeningen importeren (aanpassingen)
- Vanaf 17:00: voorraad importeren
- Vanaf 18:05: verkoopfacturen importeren
- Aansluitend: inkoopfacturen importeren

Let op: in het voorbeeld gebruikt Kevin de rekeningen 777777 en 888888 als tussenrekening voor het importeren van de openstaande posten. Dit zijn geen bestaande rekeningen in het standaard Odoo-rekeningschema. Kies hiervoor een andere V&W-rekening.

Wij maken hiervan liever twee tijdelijke balansrekeningen die dicht bij de debiteuren- en crediteurenrekeningen liggen. Kopieer daarvoor bijvoorbeeld de grootboekrekeningen debiteuren en crediteuren naar: **110001 Debiteuren beginbalans** en **130001 Crediteuren beginbalans**.

## Verkoopfacturen importeren

De procedure voor inkoopfacturen is vrijwel gelijk. Bereid het importbestand voor zoals beschreven in de video.

Het standaard rekeningschema in Odoo (voor Nederland) heeft grootboeknummer 110000. Vanaf de beginbalans willen we hier echter niet direct op boeken. We willen een creditbedrag op een balansrekening creëren dat even hoog is als het debetbedrag dat je bij het boeken van de beginbalans wilt boeken voor het totaal van de openstaande verkoopfacturen.

Om de openstaande posten te importeren werk je met een extra 'debiteurenrekening' die als tijdelijke tussenrekening dient, bijvoorbeeld rekening **110001**. Hier wordt de 'omzet' op geboekt bij de import van de facturen. Je krijgt dan bij import de boeking:

```
110000 Debiteur
    aan 110001 Totaal openstaand / 'omzet' (boek geen btw mee)
```

Je chart of accounts ziet er dan als volgt uit:

![Chart of accounts met tijdelijke tussenrekening 110001 voor de beginbalans](/kb/accounting-getting-started/img-1.png)

Bij het invoeren van de beginbalans wordt rekening 110001 weer tegengeboekt (gedebiteerd). De openstaande posten staan nu open en kunnen via de bank afgeletterd worden.

Het importbestand kan er in Excel bijvoorbeeld zo uitzien:

| Number | Partner | Invoice_date | Due Date | Reference | Unit Price | Label | Account |
|---|---|---|---|---|---|---|---|
| INV/2022/00001 | Deco Addict | 2022-12-08 | 2022-01-07 | S00003 | 22137,5 | Beginbalans | 110001 |
| INV/2022/00002 | Deco Addict | 2022-12-08 | 2022-01-07 | S00002 | 48012,5 | Beginbalans | 110001 |
| INV/2022/00003 | Azure Interior | 2022-12-01 | 2022-01-31 | S00001 | 36512,5 | Beginbalans | 110001 |
| INV/2022/00004 | Deco Addict | 2022-11-30 | 2022-12-30 | S00004 | 36512,5 | Beginbalans | 110001 |

**Let op:** een belangrijke extra kolom om toe te voegen is **Invoice Lines / Taxes**. Laat deze kolom leeg. Doe je dit niet, dan wordt op basis van de fiscal position van de klant btw aan de regel toegevoegd, waardoor het bedrag niet meer klopt.

Ga vervolgens naar het dagboek Verkoopfacturen (Invoices) en start daar de import.

**Let op:** als de factuurnummers niet opvolgend zijn, krijg je na het importeren een foutmelding dat de factuurnummers niet opeenvolgend zijn. Maak in dat geval een nieuw dagboek aan, genaamd **Customer Invoices (Beginbalans)**, en importeer de facturen daarin. Is dit gereed, dan kun je dit dagboek archiveren. Bij creditfacturen voeg je een extra kolom **Journal_ID** toe en vul je daar Customer Invoices (Beginbalans) in.

![Importscherm voor verkoopfacturen in het dagboek Customer Invoices (Beginbalans)](/kb/accounting-getting-started/img-2.png)

![Veldtoewijzing tijdens de import van de openstaande verkoopfacturen](/kb/accounting-getting-started/img-3.png)

Na het importeren moet je de openstaande posten nog verwerken (Post Entries):

![Geïmporteerde facturen verwerken met Post Entries](/kb/accounting-getting-started/img-4.png)

Open je nu een van de facturen en ga je naar het tabblad Journal Items, dan zie je de gemaakte boeking voor die post:

![Tabblad Journal Items van een geïmporteerde factuur met de tegenboeking](/kb/accounting-getting-started/img-5.png)

Het totaalbedrag van alle geïmporteerde openstaande posten staat nu zowel debet op rekening 110000 Debiteuren op de balans als credit op 110001 Debiteuren (BB-tussenrekening), in ons voorbeeld voor een bedrag van € 143.175,00.

![Saldo openstaande posten debet op 110000 en credit op 110001](/kb/accounting-getting-started/img-6.png)

Bij het inboeken van de beginbalans wordt 110001 weer tegengeboekt.

## Hulp nodig bij je overstap?

Loop je vast bij de beginbalans of de import van openstaande posten? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact) - dan kijken we met je mee.


# Odoo Accounting einrichten: Eröffnungsbilanz und offene Posten
URL: https://www.fanatics.nl/de/help/odoo-buchhaltung-eroeffnungsbilanz
Language: de

{/* TODO(de-review): first-pass DE translation, needs native-speaker review. */}

Nachfolgend finden Sie die Schritte und Hinweise für den Go-live von Odoo Accounting.

**Download:** [Odoo Accounting Go-live-Checkliste (PDF)](/kb/accounting-getting-started/odoo-accounting-go-live-checklist.pdf)

Wir verwenden meist die folgende Kurz-Checkliste:

1. Schließen Sie so viele Wareneingänge, Lieferungen und Fertigungsaufträge wie möglich ab.
2. [Importieren Sie die offenen Posten](/de/help/importdatei-offene-posten) der Debitoren und Kreditoren.
3. Importieren Sie den Bestand als Bestandskorrektur.
4. Importieren Sie die Saldenliste/Eröffnungsbilanz (oder erfassen Sie diese manuell).
5. Fügen Sie Banken hinzu und binden Sie sie an. Prüfen Sie den Abgleich mit dem Saldo der Eröffnungsbilanz.
6. Importieren Sie die Anlagen über das Importmodell für Anlagegüter und prüfen Sie den Abgleich der verschiedenen Konten mit der Eröffnungsbilanz. Siehe dazu den Artikel [Anlagegüter in Odoo importieren](/de/help/anlagegueter-importieren).
7. Erfassen Sie die Bestandsmengen (achten Sie darauf, dass bei allen Artikeln der Einstandspreis hinterlegt ist) und prüfen Sie den Abgleich mit der Eröffnungsbilanz.

Das folgende Video von Kevin Zaki ist ein praktischer Leitfaden.

| Niveau | Thema | Link |
|---|---|---|
| Advanced | Starting balance | [YouTube](https://www.youtube.com/watch?v=Rdjh3j9c1DY) |

Zeitstempel im Video:

- Vorbereitung bis Minute 10
- Ab 10:00: Produkte importieren
- Ab 11:00: Sachkonten importieren (Korrekturen)
- Ab 17:00: Bestand importieren
- Ab 18:05: Ausgangsrechnungen importieren
- Anschließend: Eingangsrechnungen importieren

Hinweis: Im Beispiel verwendet Kevin die Konten 777777 und 888888 als Zwischenkonto für den Import der offenen Posten. Diese Konten gibt es im Standard-Kontenrahmen von Odoo nicht. Wählen Sie hierfür ein anderes GuV-Konto.

Wir legen dafür lieber zwei temporäre Bilanzkonten an, die nah an den Debitoren- und Kreditorenkonten liegen. Kopieren Sie dazu z. B. die Sachkonten Debitoren und Kreditoren nach: **110001 Debitoren Eröffnungsbilanz** und **130001 Kreditoren Eröffnungsbilanz**.

## Ausgangsrechnungen importieren

Das Vorgehen für Eingangsrechnungen ist nahezu identisch. Bereiten Sie die Importdatei wie im Video gezeigt vor.

Der Standard-Kontenrahmen in Odoo (für die Niederlande) verwendet die Sachkontonummer 110000. Ab der Eröffnungsbilanz möchten wir hier jedoch nicht direkt buchen. Wir möchten auf einem Bilanzkonto einen Habenbetrag erzeugen, der genauso hoch ist wie der Sollbetrag, den Sie beim Buchen der Eröffnungsbilanz für die Summe der offenen Ausgangsrechnungen buchen möchten.

Um die offenen Posten zu importieren, verwenden Sie ein zusätzliches 'Debitorenkonto', das als temporäres Zwischenkonto dient, zum Beispiel Konto **110001**. Hier wird beim Import der Rechnungen der 'Umsatz' gebucht. Beim Import erhalten Sie dann die Buchung:

```
110000 Debitor
    an 110001 Summe offen / 'Umsatz' (keine USt. buchen)
```

Ihr Kontenplan sieht dann so aus:

![Kontenplan mit temporärem Zwischenkonto 110001 für die Eröffnungsbilanz](/kb/accounting-getting-started/img-1.png)

Beim Erfassen der Eröffnungsbilanz wird das Konto 110001 wieder gegengebucht (im Soll). Die offenen Posten stehen nun offen und können über die Bank ausgeglichen werden.

Die Importdatei in Excel könnte zum Beispiel so aussehen:

| Number | Partner | Invoice_date | Due Date | Reference | Unit Price | Label | Account |
|---|---|---|---|---|---|---|---|
| INV/2022/00001 | Deco Addict | 2022-12-08 | 2022-01-07 | S00003 | 22137,5 | Eröffnungsbilanz | 110001 |
| INV/2022/00002 | Deco Addict | 2022-12-08 | 2022-01-07 | S00002 | 48012,5 | Eröffnungsbilanz | 110001 |
| INV/2022/00003 | Azure Interior | 2022-12-01 | 2022-01-31 | S00001 | 36512,5 | Eröffnungsbilanz | 110001 |
| INV/2022/00004 | Deco Addict | 2022-11-30 | 2022-12-30 | S00004 | 36512,5 | Eröffnungsbilanz | 110001 |

**Hinweis:** Eine wichtige Zusatzspalte ist **Invoice Lines / Taxes**. Lassen Sie diese Spalte leer. Andernfalls wird auf Basis der Steuerposition des Kunden USt. zur Zeile hinzugefügt, wodurch der Betrag nicht mehr stimmt.

Gehen Sie anschließend zum Journal Ausgangsrechnungen (Invoices) und starten Sie dort den Import.

**Hinweis:** Sind die Rechnungsnummern nicht fortlaufend, erhalten Sie nach dem Import eine Fehlermeldung, dass die Rechnungsnummern nicht aufeinanderfolgend sind. Legen Sie in diesem Fall ein neues Journal mit dem Namen **Customer Invoices (Eröffnungsbilanz)** an und importieren Sie die Rechnungen dort. Danach können Sie dieses Journal archivieren. Bei Gutschriften fügen Sie eine zusätzliche Spalte **Journal_ID** hinzu und tragen dort Customer Invoices (Eröffnungsbilanz) ein.

![Importbildschirm für Ausgangsrechnungen im Journal Customer Invoices (Eröffnungsbilanz)](/kb/accounting-getting-started/img-2.png)

![Feldzuordnung während des Imports der offenen Ausgangsrechnungen](/kb/accounting-getting-started/img-3.png)

Nach dem Import müssen Sie die offenen Posten noch buchen (Post Entries):

![Importierte Rechnungen mit Post Entries buchen](/kb/accounting-getting-started/img-4.png)

Wenn Sie nun eine der Rechnungen öffnen und zum Tab Journal Items wechseln, sehen Sie die für diesen Posten erstellte Buchung:

![Tab Journal Items einer importierten Rechnung mit der Gegenbuchung](/kb/accounting-getting-started/img-5.png)

Die Summe aller importierten offenen Posten steht nun sowohl im Soll auf Konto 110000 Debitoren in der Bilanz als auch im Haben auf 110001 Debitoren (Zwischenkonto Eröffnungsbilanz), in unserem Beispiel über einen Betrag von € 143.175,00.

![Saldo der offenen Posten, Soll auf 110000 und Haben auf 110001](/kb/accounting-getting-started/img-6.png)

Beim Buchen der Eröffnungsbilanz wird 110001 wieder gegengebucht.

## Brauchen Sie Unterstützung beim Wechsel?

Kommen Sie bei der Eröffnungsbilanz oder beim Import der offenen Posten nicht weiter? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact) - wir schauen gemeinsam mit Ihnen.


# Lässt sich Odoo an Exact oder Twinfield anbinden?
URL: https://www.fanatics.nl/de/help/odoo-exact-twinfield-anbindung
Language: de

{/* TODO(de-review): first-pass DE translation. */}

Viele Kunden führen ihre Buchhaltung in **[Exact Online](/de/odoo-exact-integration)** oder **[Twinfield](/de/odoo-twinfield-integration)** und möchten sie nicht (sofort) migrieren. Kein Problem, wir bauen Anbindungen, die funktionieren.

## Was wir anbinden

### Von Odoo nach Exact/Twinfield
- **Ausgangsrechnungen**, automatisch gebucht, sobald sie in Odoo final sind.
- **Eingangsrechnungen**, in Odoo gescannt oder hochgeladen, in Exact/Twinfield gebucht.
- **Kundendaten**, neue Kunden im Odoo-CRM landen auch in Ihrer Buchhaltung.
- **Produkte und Sachkonten**, einmalige Synchronisierung oder fortlaufend, je nach Wunsch.

### Von Exact/Twinfield nach Odoo
- **Zahlungsstatus**, ist eine Rechnung bezahlt, sieht Odoo das ebenfalls.
- **Banktransaktionen**, für den Abgleich zwischen Verkauf und Zahlung.

## So funktioniert es

Unsere Anbindungen laufen auf **Cloudflare Workers** (eigene Infrastruktur) oder als **Odoo-Modul** mit direktem API-Call. Wir schreiben den Code selbst, ohne Middleware-Anbieter. Logs laufen in ein Dashboard, sodass Sie jede Transaktion nachvollziehen können.

## Alternative: Migration nach Odoo Accounting

Viele Kunden entscheiden sich nach einem Jahr, ihre gesamte Buchhaltung nach Odoo zu migrieren. Die Vorteile:

- **Ein System**, keine Anbindung, die gewartet werden muss.
- **Niedrigere Lizenzkosten**, das Exact/Twinfield-Abonnement entfällt.
- **Tiefere Integration**, Projekte, Bestand und Produktion sehen die finanzielle Seite direkt.

Wir helfen Ihnen bei dieser Entscheidung auf Basis von Größe, Komplexität und Compliance-Anforderungen.

## Weitere Anbindungen, die wir umsetzen

- **[vPlan](/de/odoo-vplan-integration)** (Kapazitätsplanung)
- **[Nmbrs](https://www.nmbrs.nl/) / [Loket](https://www.loket.nl/)** (Lohnabrechnung)
- **[Magento](https://business.adobe.com/products/magento/magento-commerce.html) / [Shopify](/de/odoo-vs-shopify)** (Webshop ↔ Odoo)
- **TimeChimp / Hubstaff** (Zeiterfassung)
- **[Mollie](https://www.mollie.com/nl) / [Stripe](https://stripe.com/)** (Zahlungen)

Etwas, das hier nicht aufgeführt ist? Schreiben Sie eine E-Mail an [team@fanatics.nl](mailto:team@fanatics.nl), wenn es eine offene API hat, können wir es anbinden.


# Can you connect Odoo to Exact or Twinfield?
URL: https://www.fanatics.nl/help/odoo-exact-twinfield-integration
Language: en

Many clients run their accounting in **[Exact Online](/odoo-exact-integration)** or **[Twinfield](/odoo-twinfield-integration)** and don't want to migrate it (right away). No problem, we build integrations that work.

## What we connect

### From Odoo to Exact/Twinfield
- **Sales invoices**, posted automatically the moment they're finalised in Odoo.
- **Purchase invoices**, scanned or uploaded in Odoo, posted in Exact/Twinfield.
- **Customer data**, new customers in Odoo CRM land in your accounting too.
- **Products and ledger accounts**, a one-off sync or ongoing, depending on your needs.

### From Exact/Twinfield to Odoo
- **Payment status**, once an invoice is paid, Odoo sees it too.
- **Bank transactions**, for reconciliation between sale and payment.

## How it works

Our integrations run on **Cloudflare Workers** (our own infrastructure) or as an **Odoo module** with a direct API call. We write the code ourselves, no middleware vendor in the mix. Logs feed a dashboard so you can trace every transaction.

## Alternative: migrate to Odoo Accounting

Many clients choose to migrate their whole accounting to Odoo after a year. The upsides:

- **One system**, no integration to maintain.
- **Lower licence costs**, the Exact/Twinfield subscription drops away.
- **Deeper integration**, projects, inventory and manufacturing see the financial side directly.

We help you make this call based on scale, complexity and compliance requirements.

## Other integrations we build

- **[vPlan](/odoo-vplan-integration)** (capacity planning)
- **[Nmbrs](https://www.nmbrs.nl/) / [Loket](https://www.loket.nl/)** (payroll)
- **[Magento](https://business.adobe.com/products/magento/magento-commerce.html) / [Shopify](/odoo-vs-shopify)** (webshop ↔ Odoo)
- **TimeChimp / Hubstaff** (time tracking)
- **[Mollie](https://www.mollie.com/nl) / [Stripe](https://stripe.com/)** (payments)

Something not listed here? Email [team@fanatics.nl](mailto:team@fanatics.nl), if it has an open API, we can connect it.


# Welke Odoo-versie en welke hosting?
URL: https://www.fanatics.nl/nl/help/odoo-versie-en-hosting
Language: nl

Twee keuzes die elke nieuwe Odoo-klant maakt: **welke versie** en **waar draait het**.

## Welke versie

Odoo brengt elk jaar een nieuwe versie uit. Onze standaard:

- **Voor nieuwe implementaties:** altijd de nieuwste versie (V18 op moment van schrijven). Daarmee zit je 3+ jaar zonder verplichte upgrade.
- **Voor migraties van een oude versie:** als je op V14 of ouder zit, gaan we direct naar de nieuwste, niet eerst naar de tussenliggende versie.

## Waar draait het

Drie opties:

### Odoo Online (SaaS)
Goed voor: kleine teams (tot ~20 users) die geen maatwerk willen en een vaste maandprijs zoeken. Geen IT-zorgen, maar ook minder flexibiliteit.

### [Odoo.sh](https://www.odoo.sh/)
**Onze standaardaanbeveling** voor mkb. Cloud-hosted door Odoo, maar je hebt volledige controle over modules, custom code en deployments. Staging-omgeving inbegrepen.

### Self-hosted
Voor bedrijven met specifieke compliance-eisen (zorg, financieel, defensie) of die expliciet on-prem willen. Wij doen dit ook, maar het is zeldzaam.

## Wat wij meestal doen

Voor 80% van onze klanten: **nieuwste versie, op Odoo.sh.** Geeft de beste balans tussen flexibiliteit, kosten en gemak.

Vragen? Vermeld het in je [scan-aanvraag](/scan) of mail [team@fanatics.nl](mailto:team@fanatics.nl).


# Hoe werkt de TARGET-methode in de praktijk?
URL: https://www.fanatics.nl/nl/help/target-methode
Language: nl

De **TARGET-methode** is hoe wij Odoo-projecten doen. Niet bedacht achter een bureau, ontwikkeld over 80+ projecten in 25 jaar. Zes stappen:

## T, Topmanagement betrekken

Zonder commitment van de eigenaar of directie loopt elk Odoo-project vast. Stap 1 is dus simpel: we zorgen dat het topmanagement bij de kick-off zit, weet wat het oplevert, en zich committeert aan de wekelijkse check-ins.

## A, Analyse vooraf

Een **[Quick Scan](/scan)**, 1 tot 3 dagen waarin we processen langslopen, gaps in kaart brengen en concrete doelen formuleren. Geen 87-pagina-rapport, wel een werkbare doelenlijst.

## R, Risico's prioriteren

Welke onderdelen van het project zijn risicovol? Daar beginnen we mee. **Niet** met het makkelijkste eerst om snelle winst te claimen. Risicovolle stukken eerst, want als ze pas op het einde komen, ontspoort het project.

## G, Geplande check-ins

Wekelijkse stand-ups van **maximaal 30 minuten**. Standaard agenda: wat is af, wat blokkeert, wat is volgende week. Geen statusrapporten, wel acties.

## E, Expertsessies

Als een team vastloopt op een specifiek punt (HR-wetgeving, productie-logica, integratie), zetten we een korte expert-sessie op met de juiste mensen. Geen brede vergadering, een gefocuste uur met de mensen die de oplossing kunnen geven.

Meer: [Snel vooruitgang boeken met expert meetings](/nl/blog/expert-meetings).

## T, Taakbewaking

Toezicht is de ruggengraat. We houden de voortgang bij in Odoo zelf (Project-module) of in Trello, afhankelijk van wat je team prettig vindt. Belangrijk: het gebeurt **consistent**, niet alleen als er een crisis is.

Meer: [Toezicht houden, zo blijf je op koers](/nl/blog/toezicht-houden-projecten).

## Wat het niet is

- Geen Agile-rituelen, geen Scrum Masters, geen Story Points.
- Geen sturen op uren, we sturen op opgeleverde fases.
- Geen jargon voor het jargon.

## Wat het wel is

Een werkbare aanpak die jij, ook zonder PM-certificering, naast je gewone werk kunt doen. We brengen de discipline. Jij brengt de kennis van je bedrijf.

Meer details op [/target](/target).


# Was ist der kostenlose Odoo-Scan?
URL: https://www.fanatics.nl/de/help/was-ist-der-kostenlose-odoo-scan
Language: de

{/* TODO(de-review): first-pass DE translation. */}

Der **Odoo-Scan** ist ein kostenloses 30-minütiges Kennenlernen, in dem wir drei Dinge tun:

1. **Zuhören**, womit Sie gerade zu tun haben: welches System Sie nutzen, welche Prozesse wehtun, was bereits gut läuft.
2. **Abgleichen** mit dem, was Odoo standardmäßig löst, und wo Maßarbeit oder ein anderes Paket besser passt.
3. **Einen konkreten nächsten Schritt** vorschlagen: einen Quick Scan, eine Testkonfiguration oder ein ehrliches "Odoo ist nicht das Richtige für Sie".

## Warum es kein Verkaufsgespräch ist

Wir pitchen nicht. Passt Odoo nicht, sagen wir das. Wenn wir meinen, dass ein anderes Paket ([AFAS](/de/odoo-vs-afas), [Exact](/de/odoo-vs-exact), [Microsoft Dynamics](/de/odoo-vs-dynamics)) besser zu Ihrer Situation passt, erklären wir, warum. Keine Verkaufssprüche, einfach Klartext.

## Was Sie für den Scan bereithalten können

Nichts. Wirklich nichts. Wenn Sie aber doch etwas vorbereiten möchten, sind dies die drei nützlichsten Dinge:

- **Eine Beschreibung Ihres aktuellen Stacks** in einer Zeile pro Tool. ("Buchhaltung in Exact, Lager in Excel, CRM in Pipedrive, Zeiterfassung über TimeSheets.")
- **Ihre zwei größten Zeitfresser.** Wo verlieren Sie oder Ihr Team Stunden an etwas, das schlauer laufen sollte?
- **Eine Schätzung Ihrer Teamgröße** pro Abteilung.

Haben Sie das nicht zur Hand? Kein Problem, wir gehen es im Gespräch durch.

## Was bekommen Sie danach?

Eine kurze E-Mail mit den drei wichtigsten Verbesserungspunkten, die wir sehen, und, wenn Sie offen dafür sind, einen Folgevorschlag. Kein Vertrag zum Unterschreiben, kein Rückruf-Druck, keine drei Berater, die sich ungefragt melden.

Bereit für einen Termin? [Scan starten](/de/scan).


# Was kostet Odoo pro Monat?
URL: https://www.fanatics.nl/de/help/was-kostet-odoo
Language: de

{/* TODO(de-review): first-pass DE translation. */}

Das Preismodell von Odoo ist einfach und transparent, einer der Gründe, warum wir damit arbeiten.

## Der Lizenzpreis

**One App Free:** Kostenlos für unbegrenzt viele Nutzer, aber auf eine einzige App beschränkt (z. B. nur CRM oder nur Inventory). Für einfache Setups ist kein Implementierungspartner nötig.

**Standard-Plan:** Ab ~20 € pro Nutzer und Monat. Enthält **alle 80+ Module**, ohne Aufpreis pro zusätzlicher App. Das Hosting läuft über Odoo SaaS (Cloud, betrieben von Odoo).

**Custom-Plan:** Realistisch ~35 € pro Nutzer und Monat für die meisten Radical-Fanatics-Kunden. Dieser Plan umfasst:
- Den Betrieb von [Maßcode](/de/odoo-custom-development) auf [Odoo.sh](https://www.odoo.sh/) oder self-hosted
- Optionales Odoo.sh-Hosting (im Plan enthalten)
- Enrichment-Credits (Adressanreicherung, E-Mail-Validierung) und OCR-Credits (Rechnungsscan): geringe Nutzungskosten zusätzlich zum Grundbetrag

Die Preise sind Richtwerte. Odoo bietet gelegentlich Mengenrabatte für Unternehmen mit 50+ Nutzern. Fordern Sie immer ein aktuelles Angebot bei Odoo oder Ihrem Partner an.

## Die Implementierungskosten

Hängt vom Umfang ab. Unsere Richtwerte:

- **Kleine Implementierung** (1–3 Module, 5–15 Nutzer): 15.000 €–35.000 €
- **Standard-Implementierung** (4–6 Module, 15–50 Nutzer): 35.000 €–85.000 €
- **Große Implementierung** (7+ Module, 50+ Nutzer, Maßarbeit): 85.000 €+

Das ist unsere Zeit, nicht die Odoo-Lizenz. Wir arbeiten in Phasen, und Sie zahlen pro gelieferter Phase, keine große Summe im Voraus.

## Laufender Support & Upgrades

Optional. Monatlich kündbar, kein Kleingedrucktes. Setzt sich zusammen aus:

- **Grundgebühr:** ~250 € pro Monat (Zugang, Monitoring, Patch-Management)
- **Pro Nutzer:** 10 €–20 € pro Monat, je nach gewünschtem SLA und Verfügbarkeit
- **Updoo-Module oder Maßarbeit:** gegebenenfalls eine monatliche Gebühr für die Wartung von Maßmodulen oder Anbindungen, die wir gebaut haben

Die gesamten Support-Kosten für ein durchschnittliches Unternehmen mit 20 Nutzern liegen damit zwischen 450 € und 650 € pro Monat.

## Was wir nicht berechnen

- Keine "Kennenlern-Gebühr" für den Scan.
- Keine Anbindungslizenzen: Wir bauen Anbindungen selbst, also kein zusätzlicher Middleware-Anbieter.
- Kein Abo auf unsere Maßmodule: Die gehören nach Bezahlung Ihnen.

Möchten Sie eine echte Schätzung für Ihre Situation? Probieren Sie den [ROI-Rechner](/de/pricing/calculator) oder [buchen Sie einen Scan](/de/scan).


# Wat is de gratis Odoo-scan?
URL: https://www.fanatics.nl/nl/help/wat-is-de-odoo-scan
Language: nl

De **Odoo-scan** is een gratis kennismaking van 30 minuten waarin we drie dingen doen:

1. **Luisteren** naar waar je nu mee zit: welk systeem je hebt, welke processen pijn doen, wat al goed werkt.
2. **Spiegelen** aan wat Odoo standaard kan oplossen, en waar maatwerk of een ander pakket past.
3. **Een concreet vervolg** voorstellen: een Quick Scan, een proefconfiguratie, of een eerlijke "Odoo is niet jullie ding".

## Wat het geen verkooppraatje is

We pitchen niet. Als Odoo niet past, zeggen we dat. Als we denken dat een ander pakket ([AFAS](/odoo-vs-afas), [Exact](/odoo-vs-exact), [Microsoft Dynamics](/odoo-vs-dynamics)) beter past bij jouw situatie, leggen we uit waarom. Geen verkooppraatjes, gewoon waar het op staat.

## Wat je voor de scan klaar mag hebben

Niks. Echt niks. Maar als je toch iets wilt voorbereiden, zijn dit de drie nuttigste dingen:

- **Een beschrijving van je huidige stack** in één regel per tool. ("Boekhouding in Exact, voorraad in Excel, CRM in Pipedrive, urenregistratie via TimeSheets.")
- **Je twee grootste tijdvreters.** Waar verliezen jij of je team uren aan iets dat slimmer zou moeten?
- **Een schatting van je teamgrootte** per afdeling.

Heb je dit niet bij de hand? Geen probleem, we doorlopen het tijdens het gesprek.

## Wat krijg je na afloop?

Een korte mail met de top-3 verbeterpunten die wij zien, en, als je daar voor open staat, een vervolgvoorstel. Geen contract om te tekenen, geen call-back-druk, geen drie consultants die ongevraagd contact opnemen.

Klaar om te plannen? [Start de scan](/scan).


# Wat kost Odoo per maand?
URL: https://www.fanatics.nl/nl/help/wat-kost-odoo
Language: nl

Odoo's prijsmodel is simpel en transparant, een van de redenen dat we ermee werken.

## De licentie-prijs

**One App Free:** Gratis voor onbeperkte gebruikers, maar beperkt tot één app (bijv. alleen CRM of alleen Voorraad). Geen implementatiepartner nodig voor eenvoudige setups.

**Standard-plan:** Vanaf ~€20 per gebruiker per maand. Inclusief **alle 80+ modules**, geen toeslag per extra app. Hosting is Odoo SaaS (cloud, beheerd door Odoo).

**Custom-plan:** Realistisch ~€35 per gebruiker per maand voor de meeste FANATICS-klanten. Dit plan omvat:
- Draaien van [maatwerk-code](/odoo-custom-development) op [Odoo.sh](https://www.odoo.sh/) of self-hosted
- Optionele Odoo.sh hosting (inbegrepen in het plan)
- Enrichment-credits (adresverrijking, e-mailvalidatie) en OCR-credits (factuur-scanning): lage gebruikskosten bovenop het basisbedrag

Prijzen zijn richtprijzen. Odoo biedt soms volume-kortingen voor bedrijven met 50+ gebruikers. Vraag altijd een actuele offerte op bij Odoo of jouw partner.

## De implementatiekosten

Hangt af van scope. Onze indicatie:

- **Kleine implementatie** (1–3 modules, 5–15 users): €15.000–€35.000
- **Standaard implementatie** (4–6 modules, 15–50 users): €35.000–€85.000
- **Grote implementatie** (7+ modules, 50+ users, maatwerk): €85.000+

Dit is onze tijd, niet de Odoo-licentie. We werken in fases en je betaalt per gerealiseerde fase, geen één-groot-bedrag-vooraf.

## Doorlopende support & upgrades

Optioneel. Opzegbaar per maand, geen kleine lettertjes. Opgebouwd uit:

- **Basisfee:** ~€250 per maand (toegang, monitoring, patchbeheer)
- **Per gebruiker:** €10–€20 per maand, afhankelijk van de gewenste SLA en beschikbaarheid
- **Updoo-modules of maatwerk:** eventueel een maandelijkse fee voor onderhoud van custom modules of koppelingen die wij hebben gebouwd

De totale support-kosten voor een gemiddeld bedrijf van 20 gebruikers liggen daarmee tussen de €450 en €650 per maand.

## Wat we niet rekenen

- Geen "kennismakingsfee" voor de scan.
- Geen koppelings-licenties: wij bouwen koppelingen zelf, dus geen middleware-vendor erbij.
- Geen abonnement op onze custom modules: die zijn van jou na betaling.

Wil je een echte schatting voor jouw situatie? Probeer de [ROI-calculator](/pricing/calculator) of [plan een scan](/scan).


# Welche Odoo-Version und welches Hosting?
URL: https://www.fanatics.nl/de/help/welche-odoo-version-und-hosting
Language: de

{/* TODO(de-review): first-pass DE translation. */}

Zwei Entscheidungen, die jeder neue Odoo-Kunde trifft: **welche Version** und **wo es läuft**.

## Welche Version

Odoo bringt jedes Jahr eine neue Version heraus. Unser Standard:

- **Für neue Implementierungen:** immer die neueste Version (V18 zum Zeitpunkt des Schreibens). Damit sind Sie 3+ Jahre ohne Pflicht-Upgrade.
- **Für Migrationen von einer alten Version:** Sind Sie auf V14 oder älter, gehen wir direkt auf die neueste Version, nicht zuerst auf eine Zwischenversion.

## Wo es läuft

Drei Optionen:

### Odoo Online (SaaS)
Gut für: kleine Teams (bis ~20 Nutzer), die keine Anpassungen wünschen und einen festen Monatspreis suchen. Keine IT-Sorgen, aber auch weniger Flexibilität.

### [Odoo.sh](https://www.odoo.sh/)
**Unsere Standardempfehlung** für den Mittelstand. Von Odoo cloud-gehostet, aber Sie behalten die volle Kontrolle über Module, Custom-Code und Deployments. Staging-Umgebung inbegriffen.

### Self-hosted
Für Unternehmen mit spezifischen Compliance-Anforderungen (Gesundheitswesen, Finanzen, Verteidigung) oder die ausdrücklich on-prem wünschen. Wir setzen das ebenfalls um, aber es ist selten.

## Was wir meist tun

Für 80% unserer Kunden: **neueste Version, auf Odoo.sh.** Das bietet die beste Balance aus Flexibilität, Kosten und Einfachheit.

Fragen? Erwähnen Sie sie in Ihrer [Scan-Anfrage](/de/scan) oder schreiben Sie an [team@fanatics.nl](mailto:team@fanatics.nl).


# What is the free Odoo scan?
URL: https://www.fanatics.nl/help/what-is-the-free-odoo-scan
Language: en

The **Odoo scan** is a free 30-minute intro in which we do three things:

1. **Listen** to where you are now: which system you run, which processes hurt, what already works well.
2. **Mirror** that against what Odoo solves out of the box, and where custom work or a different package fits better.
3. **Propose a concrete next step**: a Quick Scan, a trial configuration, or an honest "Odoo isn't your thing".

## Why it isn't a sales pitch

We don't pitch. If Odoo doesn't fit, we say so. If we think another package ([AFAS](/odoo-vs-afas), [Exact](/odoo-vs-exact), [Microsoft Dynamics](/odoo-vs-dynamics)) suits your situation better, we explain why. No sales talk, just straight answers.

## What you can have ready for the scan

Nothing. Truly nothing. But if you do want to prepare, these three things help most:

- **A description of your current stack** in one line per tool. ("Accounting in Exact, stock in Excel, CRM in Pipedrive, time tracking in TimeSheets.")
- **Your two biggest time sinks.** Where do you or your team lose hours to something that should be smarter?
- **An estimate of your team size** per department.

Don't have this handy? No problem, we cover it during the call.

## What you get afterwards

A short email with the top 3 improvements we see and, if you're open to it, a follow-up proposal. No contract to sign, no call-back pressure, no three consultants reaching out unprompted.

Ready to book? [Start the scan](/scan).


# Which Odoo version and which hosting?
URL: https://www.fanatics.nl/help/which-odoo-version-and-hosting
Language: en

Two choices every new Odoo client makes: **which version** and **where it runs**.

## Which version

Odoo ships a new version every year. Our standard:

- **For new implementations:** always the latest version (V18 at the time of writing). That keeps you 3+ years with no mandatory upgrade.
- **For migrations from an old version:** if you're on V14 or older, we go straight to the latest, not to an intermediate version first.

## Where it runs

Three options:

### Odoo Online (SaaS)
Good for: small teams (up to ~20 users) that want no custom work and a fixed monthly price. No IT worries, but less flexibility too.

### [Odoo.sh](https://www.odoo.sh/)
**Our standard recommendation** for SMEs. Cloud-hosted by Odoo, but you keep full control over modules, custom code and deployments. Staging environment included.

### Self-hosted
For companies with specific compliance requirements (healthcare, finance, defence) or that explicitly want on-prem. We do this too, but it's rare.

## What we usually do

For 80% of our clients: **latest version, on Odoo.sh.** It gives the best balance of flexibility, cost and ease.

Questions? Mention them in your [scan request](/scan) or email [team@fanatics.nl](mailto:team@fanatics.nl).


# Wie funktioniert die TARGET-Methode in der Praxis?
URL: https://www.fanatics.nl/de/help/wie-die-target-methode-funktioniert
Language: de

{/* TODO(de-review): first-pass DE translation. */}

Die **TARGET-Methode** ist unsere Art, Odoo-Projekte umzusetzen. Nicht am Schreibtisch erdacht, sondern über mehr als 80 Projekte in 25 Jahren entwickelt. Sechs Schritte:

## T, Top-Management einbinden

Ohne das Commitment der Inhaber oder der Geschäftsführung bleibt jedes Odoo-Projekt stecken. Schritt 1 ist deshalb einfach: Wir sorgen dafür, dass das Top-Management beim Kick-off dabei ist, weiß, was es bringt, und sich zu den wöchentlichen Check-ins verpflichtet.

## A, Analyse vorab

Ein **[Quick Scan](/de/scan)**, 1 bis 3 Tage, in denen wir Ihre Prozesse durchgehen, Lücken erfassen und konkrete Ziele formulieren. Kein 87-seitiger Bericht, sondern eine umsetzbare Zielliste.

## R, Risiken zuerst

Welche Teile des Projekts sind riskant? Damit fangen wir an. **Nicht** mit dem Einfachsten zuerst, um schnelle Erfolge zu reklamieren. Riskante Teile zuerst, denn wenn sie erst am Ende kommen, entgleist das Projekt.

## G, Geplante Check-ins

Wöchentliche Stand-ups von **maximal 30 Minuten**. Feste Agenda: Was ist fertig, was blockiert, was steht nächste Woche an. Keine Statusberichte, sondern Aktionen.

## E, Expertensitzungen

Wenn ein Team an einem bestimmten Punkt feststeckt (Arbeitsrecht, Fertigungslogik, eine Integration), setzen wir eine kurze Expertensitzung mit den richtigen Leuten an. Kein großes Meeting, sondern eine fokussierte Stunde mit den Menschen, die die Lösung liefern können.

Mehr: [Mit Expert Meetings schnell vorankommen](/de/blog/expert-meetings-de).

## T, Tracking

Die Überwachung ist das Rückgrat. Wir verfolgen den Fortschritt in Odoo selbst (Projekt-Modul) oder in Trello, je nachdem, womit Ihr Team gut zurechtkommt. Wichtig ist: Es geschieht **konsequent**, nicht nur in der Krise.

Mehr: [Den Überblick behalten, so bleiben Sie auf Kurs](/de/blog/projekte-im-griff-behalten).

## Was es nicht ist

- Keine Agile-Rituale, keine Scrum Master, keine Story Points.
- Kein Steuern über Stunden, wir steuern über gelieferte Phasen.
- Kein Jargon um des Jargons willen.

## Was es ist

Ein umsetzbarer Ansatz, den Sie auch ohne PM-Zertifizierung neben Ihrer eigentlichen Arbeit umsetzen können. Wir bringen die Disziplin. Sie bringen das Wissen über Ihr Unternehmen.

Mehr Details unter [/target](/de/target).


# Accounts alleen op uitnodiging aanmaken in Odoo Website
URL: https://www.fanatics.nl/nl/help/account-aanmaken-alleen-op-uitnodiging
Language: nl

In Odoo V16 voorkom je net iets anders dan in V15 dat websitebezoekers zelf een account aanmaken. Wil je dat accounts alleen op uitnodiging ontstaan, volg dan deze stap.

## Account alleen op uitnodiging instellen

Ga naar de **Website**-app -> **Configuratie** -> **Instellingen** -> **Shop - Checkout Process** en selecteer **Uitgeschakeld (kopen als gast)**.

![Odoo Website-instelling Checkout Process met de optie kopen als gast uitgeschakeld](/kb/account-by-invitation/img-1.png)

Vanaf nu kan een bezoeker tijdens het afrekenen geen eigen account meer aanmaken. Portaaltoegang geef je voortaan zelf, door een gebruiker een uitnodiging te sturen.

## Hulp nodig bij je Odoo-inrichting?

Wil je de website en portaaltoegang goed dichtzetten? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact) - dan kijken we met je mee.


# Create accounts only on invitation in Odoo Website
URL: https://www.fanatics.nl/help/account-creation-only-on-invitation
Language: en

In Odoo V16 you prevent website visitors from creating their own account a little differently than in V15. To make sure accounts are created on invitation only, follow this step.

## Set accounts to invitation only

Go to the **Website** app -> **Configuration** -> **Settings** -> **Shop - Checkout Process** and select **Disabled (buy as guest)**.

![Odoo Website setting Checkout Process with the buy-as-guest option disabled](/kb/account-by-invitation/img-1.png)

From now on a visitor can no longer create an account during checkout. You grant portal access yourself, by sending a user an invitation.

## Need a hand with your Odoo setup?

Want to lock down the website and portal access properly? [Book an Odoo scan](/scan) or [get in touch](/contact) - we will take a look with you.


# Show extra product fields on your Odoo eCommerce page
URL: https://www.fanatics.nl/help/add-extra-product-fields-ecommerce
Language: en

Sometimes you want a product page to show more than just the name and price - think of the internal reference, the barcode, or a custom HTML field with extra detail. In Odoo you bind these fields to the page without any custom development.

## Show an existing field

1. Open the product page in your shop and click **Edit** in the top right.
2. Drag a **Text** block to where the information should appear.
3. Select the text, open the inline editor and choose **Bind field** (Dynamic field).
4. Pick the field you want, for example the internal reference or the barcode.
5. Save. The block now shows the value of whichever product the visitor is viewing.

The value follows the product: open a different item and the displayed information updates by itself.

## Add a new field

If the field does not exist yet, create it first with Studio:

1. Open Studio on the product form and add a new field (text, number or HTML).
2. Fill the field on your products with the right value.
3. Bind the field to a block on the product page the same way as above.

An HTML field is useful when you want to show formatted content, such as a specification table or a block of certifications.

## Videos

The video below walks through binding a product field step by step:

- [Short walkthrough (Screencast)](https://app.screencast.com/vrgeODYRrlvF8)

Want to go further, for example with dynamic fields and custom blocks? Watch this video:

- [Deeper dive (YouTube)](https://www.youtube.com/watch?v=97W6YeYVwxU)

## Need a hand with your shop?

Want to set up your Odoo eCommerce pages more cleverly? [Book an Odoo scan](/scan) or [get in touch](/contact) - we will take a look with you.


# Importdatei Anlagegüter in Odoo (Beispiel mit Erläuterungen)
URL: https://www.fanatics.nl/de/help/anlagegueter-importieren
Language: de

{/* TODO(de-review): first-pass DE translation. */}

Möchten Sie Ihre Anlagegüter in Odoo übernehmen, zum Beispiel im Rahmen der Eröffnungsbilanz oder wenn Sie das Anlagenmodul später in Betrieb nehmen? Verwenden Sie unsere Excel-Vorlage. Damit importieren Sie alle Anlagen auf einmal, statt sie einzeln zu erfassen.

**Download:** [Importvorlage Anlagegüter (XLSX)](/kb/import-fixed-assets/importbestand-vaste-activa.xlsx)

## Die Vorlage herunterladen

Wir stellen eine ausgefüllte Beispieldatei mit Erläuterungen bereit. In der ersten Zeile des ersten Tabs finden Sie bei Bedarf gelbe Notizen, die erklären, was in jede Spalte gehört.

- **Importdatei Anlagegüter.xlsx** - die Standardvorlage für aktuelle Odoo-Versionen.
- **Importdatei Anlagegüter (Odoo 16 und früher).xlsx** - für ältere Versionen.

Fragen Sie die Vorlage bei uns an, falls Sie sie noch nicht haben; wir senden sie Ihnen zu.

## Wichtige Hinweise

- **Löschen Sie die gelbe Hinweiszeile.** Die erste Zeile im ersten Tab dient nur der Erläuterung. Entfernen Sie sie vor dem Import, sonst liest Odoo die Notizen als Daten.
- **Lassen Sie das Startdatum weg.** Wenn Sie die Abschreibungsdaten korrekt erfassen, leitet Odoo das richtige Startdatum beim Erzeugen der Abschreibungen selbst ab. Diese Spalte müssen Sie also nicht importieren.
- **Prüfen Sie den Abgleich mit der Eröffnungsbilanz.** Stimmen Sie Ihre Anlagenkonten und die kumulierten Abschreibungen mit den Beträgen in Ihrer Eröffnungsbilanz ab.

Dieser Artikel gehört zur Checkliste für den Go-live von Odoo Accounting, in der der Import der Anlagen Schritt 6 ist.

## Brauchen Sie Unterstützung beim Anlagenimport?

Kommen Sie beim Import oder beim Abgleich mit der Eröffnungsbilanz nicht weiter? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact) - wir schauen gemeinsam mit Ihnen.


# Auto-numbering the Internal Reference in Odoo
URL: https://www.fanatics.nl/help/auto-number-internal-reference
Language: en

Want every new product to get a consecutive number in the Internal Reference field (the product number)? By default Odoo leaves that field empty or relies on someone typing it in. With a number sequence and a small automated action, you let Odoo do the work.

You need three things for this:

1. Set the **Internal Reference** field to Read Only, so nobody overwrites it by hand.
2. Create a **number sequence** with its own code and prefix.
3. Create an **automated action** with a Python expression that fetches the next free number from the sequence on creation.

## Creating the sequence

Go to the sequence settings (Settings, Technical, Sequences & Identifiers, Sequences) and create a new sequence. Give it a clear name and its own **sequence code** - you will reference that code in the automated action. Set the prefix, the sequence size (number of digits) and the step.

![Odoo number sequence showing sequence code, prefix BM-, sequence size 4 and next number](/kb/internal-reference-numbering/img-1.png)

In this example the sequence code is `bm.product.numbers`, with prefix `BM-` and a sequence size of 4 digits. The next number is then, for example, `BM-0115`.

## Wiring up the automated action

Next, create an automated action on the **Product** model. Set the trigger to **On Creation** so the action fires the moment a new product is created. Choose **Update the Record** as the action and give the Internal Reference field a **Python expression** that pulls the next number from the sequence.

![Automated action on the Product model with an On Creation trigger and a Python expression for Internal Reference](/kb/internal-reference-numbering/img-2.png)

Use this expression and replace the sequence code with your own:

```python
record.env['ir.sequence'].next_by_code('tp.product.number')
```

From now on, every new product automatically gets the next free number in the Internal Reference field.

## Need a hand with your Odoo setup?

Want this set up cleanly, or stuck on your own numbering logic? [Book an Odoo scan](/scan) or [get in touch](/contact) - we will take a look with you.


# Bill of materials (stuklijsten) importeren in Odoo
URL: https://www.fanatics.nl/nl/help/bill-of-materials-importeren
Language: nl

Een bill of materials (stuklijst) importeren is handig als je veel verschillende
configuraties hebt en de Manufacturing-module gebruikt, bijvoorbeeld vanuit een
export uit een CAD-programma. Het is geen platte import: één stuklijst bestaat uit
een kopregel met daaronder meerdere componentregels. Daardoor is het iets lastiger
dan het importeren van producten of contactpersonen.

**Download:** [Importtemplate stuklijsten (XLSX)](/kb/import-bom/import-template-stuklijsten.xlsx)

## Video: Import BoM

Kevin Zaki nam een heldere uitleg op van het hele proces.

| Niveau | Onderwerp | Link |
|---|---|---|
| Expert | Import BoM | [YouTube](https://www.youtube.com/watch?v=oJG5pNg9F-M) (21:30) |

## Het importbestand

Importeer je stuklijsten via de Manufacturing-app, onder **Producten > Stuklijsten**.
Bouw het importbestand op met een kopregel per stuklijst en daaronder een regel per
component. De belangrijkste kolommen:

| Kolom | Inhoud |
|---|---|
| External ID | Externe ID van de stuklijst (bijv. `bom_001`) |
| Product / External ID | Externe ID van het eindproduct |
| Product Variant / External ID | Externe ID van de variant (optioneel) |
| Quantity | Aantal dat de stuklijst oplevert |
| Unit of Measure | Maateenheid (bijv. Units) |
| BoM Type | Bijvoorbeeld "Manufacture this product" |
| BoM Line / External ID | Externe ID per componentregel |
| BoM Line / Component / External ID | Externe ID van het component |
| BoM Line / Quantity | Aantal per component |

De kopregel vul je één keer in; de bijbehorende componentregels laat je eronder
volgen met alleen de BoM Line-kolommen gevuld.

## Werk met externe ID's

Staan de producten al in Odoo, dan moet je werken met de **externe ID's** van zowel
de producten als de componenten. Zo koppelt Odoo elke regel aan het juiste product
in plaats van een nieuw product aan te maken. Het bestand ziet er dan zo uit:

![Excel-importbestand voor stuklijsten met externe ID's voor producten en componenten](/kb/import-bom/img-1.png)

## Hulp nodig bij je import?

Loop je vast bij het importeren van stuklijsten? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact) - dan kijken we met je mee.


# Calculating shipping costs in Odoo
URL: https://www.fanatics.nl/help/calculate-shipping-costs-odoo
Language: en

Odoo calculates shipping costs with *shipping rules*. You can build these in two ways:

- **Fixed amount** - a flat fee per shipment, optionally free for orders above a certain value.
- **Based on a formula** - where the cost scales with the shipment itself.

## What can the formula be based on?

A formula rule works out the shipping cost from a condition. Odoo offers five options:

| Condition | Calculated on |
|---|---|
| Weight | Weight |
| Volume | Volume |
| Weight * Volume | Volumetric weight |
| Price | Price |
| Quantity | Quantity |

For each rule you set the condition and the matching delivery cost:

![The Create Pricing Rules window in Odoo with the Condition dropdown open: Weight, Volume, Weight * Volume, Price and Quantity](/kb/shipping-costs/img-1.png)

## Turning the option on

To work with these pricing rules, first enable the option under **Settings > Shipping Methods**. After that you can configure the rules per shipping method.

## Going further

This short video explains how the shipping methods work in practice: [Delivery costs in Odoo](https://youtu.be/0KG9QCyVe0s).

## Need a hand with your setup?

Want to get your shipping methods right the first time? [Book an Odoo scan](/scan) or [get in touch](/contact) - we will take a look with you.


# Contacten importeren in Odoo
URL: https://www.fanatics.nl/nl/help/contacten-importeren
Language: nl

Voor het importeren van contacten in Odoo werk je met twee Excel-templates: een voor bedrijven en een voor de contactpersonen die bij die bedrijven horen.

**Download:** [Importtemplate contacten (XLSX)](/kb/import-contacts/import-template-contacten.xlsx)

## Bedrijven importeren

Importeer eerst de bedrijven zelf. Gebruik hiervoor het template **Partner Import file - Companies.xlsx** (op te vragen bij Radical Fanatics).

## Contactpersonen importeren

Importeer daarna de contactpersonen met het template **Partner Import file - companies contacts.xlsx** (op te vragen bij Radical Fanatics).

Werk in dit bestand met de bedrijfs-ID, zodat elke contactpersoon aan het juiste bedrijf wordt gekoppeld. Hetzelfde bestand kun je ook gebruiken om losse personen te importeren, zonder bedrijf.

## Hulp nodig?

[Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact)


# Address contacts by first name in Odoo email templates (QWeb)
URL: https://www.fanatics.nl/help/first-name-salutation-email-templates
Language: en

Odoo stores a contact's first and last name in a single field. Sometimes you want to greet someone by first name only in an email template. A short expression in your QWeb reports handles it.

## The expression

Split the name field on spaces and take the first part:

```
Variable: ${object.partner_id.name.split()[0]}
QWeb email template: <t t-out="object.partner_id.name.split()[0]"></t>
```

`split()` breaks the full name into separate words; `[0]` takes the first word, which is the first name.

## Example: salutation in a quotation email

The QWeb block below puts "Hi [first name]," above the body of a sales order email:

```html
<div style="margin: 0px; padding: 0px;">
    <p style="box-sizing:border-box;margin: 0px; padding: 0px; font-size: 13px;">
        <t t-set="doc_name" t-value="'quotation' if object.state in ('draft', 'sent') else 'order'"></t>
        Hi <t t-out="object.partner_id.name.split()[0]"></t>,
        <br><br>
        As agreed, here is the link to our quotation.
        <br>You can view it online through the link in this email. The PDF version you can download there sets out the assumptions, the project scope and the conditions in more detail.
        <br><br>If everything looks good, you can confirm the quotation online.
        <br><br>
        Let me know if you have any questions.
        <t t-if="not is_html_empty(object.user_id.signature)" data-oe-t-group-active="true">
            <br><br>
            <t t-out="object.user_id.signature or ''" data-oe-t-inline="true">--<br>Team Radical Fanatics</t>
        </t>
        <br><br>
    </p>
</div>
```

## Watch out

- If a first name has multiple words (for example "Jan Willem"), you only get the first word. For most salutations that is fine.
- If a contact has no name, the expression can throw an error. In critical templates, guard against it with a fallback.

Ref: [Odoo forum: dynamic placeholder for only first name](https://www.odoo.com/nl_NL/forum/help-1/dynamic-placeholder-for-only-first-name-in-odoo-mass-mailing-111395)

## Need a hand with your Odoo setup?

Stuck on email templates or other configuration? [Book an Odoo scan](/scan) or [get in touch](/contact)


# Extra productvelden tonen op je Odoo eCommerce-pagina
URL: https://www.fanatics.nl/nl/help/extra-productvelden-ecommerce
Language: nl

Soms wil je op de productpagina van je webshop meer laten zien dan alleen de naam en de prijs. Denk aan het artikelnummer, de barcode of een eigen HTML-veld met extra uitleg. In Odoo koppel je zulke velden zonder maatwerk aan de pagina.

## Een bestaand veld tonen

1. Open de productpagina in je webshop en klik rechtsboven op **Bewerken**.
2. Sleep een **Tekst**-blok naar de plek waar de informatie moet komen.
3. Selecteer de tekst, open de inline-editor en kies **Veld koppelen** (Dynamic field).
4. Kies het gewenste veld, bijvoorbeeld het artikelnummer (Internal Reference) of de barcode.
5. Sla op. Het veld toont nu automatisch de waarde van het product dat de bezoeker bekijkt.

De waarde volgt het product: open je een ander artikel, dan past de getoonde informatie zich vanzelf aan.

## Een nieuw veld toevoegen

Bestaat het veld nog niet, maak het dan eerst aan met Studio:

1. Open Studio op het productformulier en voeg een nieuw veld toe (tekst, getal of HTML).
2. Vul het veld bij je producten met de juiste waarde.
3. Koppel het veld vervolgens op dezelfde manier aan een blok op de productpagina.

Een HTML-veld is handig wanneer je opgemaakte content wilt tonen, zoals een specificatietabel of een blok met certificeringen.

## Video's

In de onderstaande video laten we stap voor stap zien hoe je een productveld koppelt:

- [Korte uitleg (Screencast)](https://app.screencast.com/vrgeODYRrlvF8)

Wil je een stap verder gaan, bijvoorbeeld met dynamische velden en eigen blokken? Bekijk dan deze video:

- [Verdieping (YouTube)](https://www.youtube.com/watch?v=97W6YeYVwxU)

## Hulp nodig bij je webshop?

Wil je je Odoo eCommerce-pagina's slimmer inrichten? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact) - dan kijken we met je mee.


# How fast can we go live with Odoo?
URL: https://www.fanatics.nl/help/how-fast-can-we-go-live-with-odoo
Language: en

**Short answer:** for an SME scope with 3-6 modules, 5 to 50 users and average complexity: **3 to 9 months** from first conversation to go-live.

## The three factors that set the pace

### 1. How many modules in scope
- 1-2 modules (e.g. just CRM + Sales): **2-4 months**
- 3-4 modules: **4-6 months**
- 5+ modules with integrations: **6-9 months**

### 2. How much custom work
Pure standard Odoo: fast. One or two [custom modules](/odoo-custom-development): moderate. Many custom flows, integrations with legacy systems, data migration from a complex ERP: slower.

### 3. Your team's availability
This is **the biggest factor** and the one most often underestimated. An Odoo implementation takes 4-8 hours a week from your key users (the people who will use the system most). If they aren't there, the project stalls, not because we get stuck, but because we can't get decisions made.

## The fastest implementations we've done

- **6 weeks**, small [services firm](/industries/services), CRM + Sales only, no migration, key user available.
- **3 months**, [manufacturing company](/industries/manufacturing), Sales + Inventory + Manufacturing, moving from an Excel-only setup.

## The slowest

- **14 months**, mid-sized company switching from SAP, with 8 modules, 4 integrations and 20 years of legacy data. Entirely within scope, but simply a big job.

## What we don't do

**Big-bang implementations.** We always work in phases. First two modules go live, then two more, then the rest. That keeps an implementation from sitting in a test environment for months while your team loses patience.

Want an honest estimate for your situation? [Book a scan](/scan), 30 minutes is enough for us to sketch a timeline.


# Hoe snel kunnen we live met Odoo?
URL: https://www.fanatics.nl/nl/help/hoe-snel-live
Language: nl

**Korte antwoord:** voor een mkb-scope met 3–6 modules, 5 tot 50 users en gemiddelde complexiteit: **3 tot 9 maanden** van eerste gesprek tot go-live.

## De drie factoren die het tempo bepalen

### 1. Hoeveel modules in scope
- 1–2 modules (bijv. alleen CRM + Sales): **2–4 maanden**
- 3–4 modules: **4–6 maanden**
- 5+ modules met integraties: **6–9 maanden**

### 2. Hoeveel maatwerk
Pure standaard-Odoo: snel. Eén of twee [custom modules](/odoo-custom-development): matig. Veel custom flows, integraties met legacy-systemen, datamigratie van een complexe ERP: trager.

### 3. Beschikbaarheid van jouw team
Dit is **de grootste factor** en wordt het vaakst onderschat. Een Odoo-implementatie vraagt 4–8 uur per week van je key-users (de mensen die het systeem het meest gaan gebruiken). Zijn ze er niet, dan stagneert het project, niet omdat wij vastlopen, maar omdat we beslissingen niet kunnen krijgen.

## De snelste implementaties die we deden

- **6 weken**, klein [dienstverleningsbedrijf](/industries/services), alleen CRM + Sales, geen migratie, key-user beschikbaar.
- **3 maanden**, [productiebedrijf](/industries/manufacturing), Sales + Inventory + Manufacturing, vanuit Excel-only setup.

## De langzaamste

- **14 maanden**, middelgroot bedrijf dat overstapte van SAP, met 8 modules, 4 koppelingen en 20 jaar legacy-data. Volledig binnen scope, maar nu eenmaal groot werk.

## Wat we niet doen

**Big-bang-implementaties.** We werken altijd in fases. Eerst gaan twee modules live, dan twee meer, dan de rest. Daarmee voorkom je dat een implementatie maandenlang in een testomgeving blijft hangen en je team het beu wordt.

Wil je een eerlijke schatting voor jouw situatie? [Plan een scan](/scan), na 30 minuten weten we genoeg om een tijdlijn te schetsen.


# Importing bills of materials (BoMs) in Odoo
URL: https://www.fanatics.nl/help/import-bill-of-materials
Language: en

Importing a bill of materials (BoM) is handy when you have many different
configurations and use the Manufacturing module, for example from a CAD-program
export. It is not a flat import: a single BoM consists of a header row with several
component rows underneath. That makes it a little trickier than importing products
or contacts.

**Download:** [Bill of materials import template (XLSX)](/kb/import-bom/import-template-stuklijsten.xlsx)

## Video: Import BoM

Kevin Zaki recorded a clear walkthrough of the whole process.

| Level | Topic | Link |
|---|---|---|
| Expert | Import BoM | [YouTube](https://www.youtube.com/watch?v=oJG5pNg9F-M) (21:30) |

## The import file

Import BoMs from the Manufacturing app, under **Products > Bills of Materials**.
Build the import file with one header row per BoM and a row per component beneath it.
The key columns:

| Column | Contents |
|---|---|
| External ID | External ID of the BoM (e.g. `bom_001`) |
| Product / External ID | External ID of the finished product |
| Product Variant / External ID | External ID of the variant (optional) |
| Quantity | Quantity the BoM yields |
| Unit of Measure | Unit of measure (e.g. Units) |
| BoM Type | For example "Manufacture this product" |
| BoM Line / External ID | External ID per component row |
| BoM Line / Component / External ID | External ID of the component |
| BoM Line / Quantity | Quantity per component |

Fill in the header row once; let the matching component rows follow underneath with
only the BoM Line columns populated.

## Use external IDs

If the products already exist in Odoo, you must use the **external IDs** of both the
products and the components. That way Odoo links each row to the right product
instead of creating a new one. The file then looks like this:

![Excel import file for bills of materials with external IDs for products and components](/kb/import-bom/img-1.png)

## Need a hand with your import?

Stuck importing bills of materials? [Book an Odoo scan](/scan) or [get in touch](/contact) - we will take a look with you.


# Importing contacts into Odoo
URL: https://www.fanatics.nl/help/import-contacts
Language: en

To import contacts into Odoo you use two Excel templates: one for companies and one for the contact people who belong to those companies.

**Download:** [Contacts import template (XLSX)](/kb/import-contacts/import-template-contacten.xlsx)

## Importing companies

Import the companies first. Use the template **Partner Import file - Companies.xlsx** (available from Radical Fanatics).

## Importing contact people

Next, import the contact people with the template **Partner Import file - companies contacts.xlsx** (available from Radical Fanatics).

In this file, work with the company ID so that each contact links to the right company. You can also use the same file to import individual people with no company.

## Need a hand?

[Book an Odoo scan](/scan) or [get in touch](/contact)


# Import file for open items
URL: https://www.fanatics.nl/help/import-file-open-items
Language: en

Importing open items is part of [going live with Odoo Accounting](/help/odoo-accounting-getting-started). Below is the description and the posting logic for importing open sales and purchase invoices. The import files for sales and purchase are almost identical. First create the suspense accounts **110001** and **130001**, plus the journals **purchase invoices opening balance** and **sales invoices opening balance**.

**Download:** [Open items import template (XLSX)](/kb/import-open-items/import-template-openstaande-posten.xlsx)

There is also a [video walking through the full procedure](https://www.loom.com/share/de7cb86b440040d7a253d23cec539cd6). The steps are written out below.

## Procedure for sales and purchase invoices

The standard Dutch chart of accounts in Odoo uses ledger number **110000**. From the opening balance, we do not want to post here directly. We want to create a credit amount on a balance-sheet account equal to the debit amount you post for the total of the open sales invoices when entering the opening balance.

So use an extra 'receivables account' that serves as a temporary suspense account, for example account **110001**. The 'revenue' is posted here when the invoices are imported. On import you get the entry:

```
110000 Receivable
    to 110001 Total outstanding / 'revenue' (do not post VAT)
```

Your chart of accounts then looks like this:

![Chart of accounts with temporary suspense account 110001](/kb/import-open-items/img-1.png)

When you enter the opening balance, account 110001 is reversed (debited) again. The open items are now outstanding and can be reconciled against the bank.

## The import file

The import file in Excel might look like this:

| Number | Partner | Invoice_date | Due Date | Reference | Unit Price | Label | Account |
|---|---|---|---|---|---|---|---|
| INV/2022/00001 | Deco Addict | 2022-12-08 | 2022-01-07 | S00003 | 22137,5 | Opening balance | 110001 |
| INV/2022/00002 | Deco Addict | 2022-12-08 | 2022-01-07 | S00002 | 48012,5 | Opening balance | 110001 |
| INV/2022/00003 | Azure Interior | 2022-12-01 | 2022-01-31 | S00001 | 36512,5 | Opening balance | 110001 |
| INV/2022/00004 | Deco Addict | 2022-11-30 | 2022-12-30 | S00004 | 36512,5 | Opening balance | 110001 |

The price column and the two next to it map in Odoo to **Invoice Lines / Unit Price**, **Invoice Lines / Label** and **Invoice Lines / Account**.

**Note:** an important extra column to add is **Invoice Lines / Taxes**. Leave it empty. If you do not, Odoo adds VAT to the line based on the customer's fiscal position, which throws off the amount. For purchase invoices this is not needed, so test it mainly for the sales invoices.

## Importing and posting

Go to the Customer Invoices journal and start the import there.

**Note:** if the invoice numbers are not sequential, you get an error after importing that the numbers are not consecutive. In that case, create a new journal, **Customer Invoices (Opening balance)**, and import the invoices there. You can archive that journal afterwards. For credit notes, add an extra **Journal_ID** column and enter Customer Invoices (Opening balance) there.

![Import screen for the open invoices](/kb/import-open-items/img-2.png)

![Field mapping during the import](/kb/import-open-items/img-3.png)

After importing, post the open items with **Post Entries**:

![Posting the imported invoices with Post Entries](/kb/import-open-items/img-4.png)

Open one of the invoices and go to the Journal Items tab, and you see the entry created for that item:

![Journal Items tab with the contra entry](/kb/import-open-items/img-5.png)

The total of all imported open items is now both debit on **110000 Receivables** on the balance sheet and credit on **110001 Receivables** (opening-balance suspense), in our example € 143,175.00:

![Balance of open items, debit on 110000 and credit on 110001](/kb/import-open-items/img-6.png)

When you post the opening balance, 110001 is reversed again.

## Need a hand with your import?

Stuck on the import file or the entries? [Book an Odoo scan](/scan) or [get in touch](/contact) - we will take a look with you.


# Fixed-asset import file in Odoo (example with notes)
URL: https://www.fanatics.nl/help/import-fixed-assets
Language: en

Need to load your fixed assets into Odoo, for example as part of the opening balance or when you start using the asset module later on? Use our Excel template. It lets you import every asset in one go instead of entering them one by one.

**Download:** [Fixed-asset import template (XLSX)](/kb/import-fixed-assets/importbestand-vaste-activa.xlsx)

## Downloading the template

We provide a filled-in example file with notes. The first row of the first tab carries yellow notes that explain what belongs in each column.

- **Fixed-asset import file.xlsx** - the standard template for recent Odoo versions.
- **Fixed-asset import file (Odoo 16 and earlier).xlsx** - for older versions.

Ask us for the template if you don't have it yet; we'll send it over.

## Key points

- **Delete the yellow note row.** The first row on the first tab is explanation only. Remove it before importing, otherwise Odoo reads the notes as data.
- **Leave out the start date.** If you fill in the depreciation details correctly, Odoo derives the right start date itself when it generates the depreciation. You don't need to import that column.
- **Check the reconciliation with the opening balance.** Reconcile your fixed-asset accounts and the accumulated depreciation with the amounts in your opening balance.

This article is part of the checklist for going live with Odoo Accounting, where importing assets is step 6.

## Need a hand with your asset import?

Stuck on the import or the reconciliation with the opening balance? [Book an Odoo scan](/scan) or [get in touch](/contact) - we will take a look with you.


# Importing product images into Odoo
URL: https://www.fanatics.nl/help/import-product-images
Language: en

To import images into Odoo, they need to be reachable through a URL. That can be online or, when Odoo runs on your own machine, through a local path. Here are three approaches.

## Online with postimg.cc

[postimg.cc](https://postimg.cc/) is the most reliable option. You upload all images and copy the direct link for each one. We have tested this method with up to 1000 images per import.

1. Create an account.
2. Upload the files in the order of your import file.
3. After uploading, click **Direct link** (see the image below).
4. Copy and paste the values into the right rows of your import file.

![Copying the Direct link of an image on postimg.cc](/kb/import-product-images/img-1.png)

## Online with Google Drive

Put all images you want to import into a single Google Drive folder. The downside: Google times out after roughly 40 to 50 images, so it is less suited to large uploads, where you have to split the import into batches.

After uploading, find an add-on that turns the images into a URL, for example 'Photo gallery by awesome table'. In the final URL, replace the `file/d` part with `uc?id=`. The images are then ready to import.

## Locally on your own server

If you run Odoo locally, you can read the images straight from a local path. This only works when you can restore an Odoo backup, for example in Odoo.sh. On your own server this is the recommended method.

## Need a hand with your import?

Stuck importing your product images? [Book an Odoo scan](/scan) or [get in touch](/contact) - we will take a look with you.


# Importing products with variants in Odoo
URL: https://www.fanatics.nl/help/import-products-with-variants
Language: en

Follow the guide below to import products with variants into Odoo. The video was recorded on an older Odoo version, but the approach still holds (as of Q2 2023).

**Download:** [Product variants import template (XLSX)](/kb/import-product-variants/import-template-producten-met-varianten.xlsx)

## Video walkthrough

The full import of products, variants and values is shown step by step in a video: *Products and Product Variants - IMPORT TUTORIAL*. Ask your consultant for the video if you need it.

## Excel template

Use the Excel template *TEMPLATE - PRODUCT & PRODUCT VARIANTS* as your starting point. Fill in the fields you need for products, variants and their values. The template follows the same column layout as the video, so you can get your import file ready quickly.

## Import without variants

Do not need attributes or variants? A simpler import will do. There is a separate article with a product import template without variants.

## Need a hand with your import?

Stuck importing products or variants? [Book an Odoo scan](/scan) or [get in touch](/contact) - we will take a look with you.


# Importing products in Odoo: import template without variants
URL: https://www.fanatics.nl/help/import-products-without-variants
Language: en

For a simple product import without variants, use the standard import template to prepare your import file. This covers an import without variants, without eCommerce and without other extras. If you need something more specific, we can build a tailored import template.

**Download:** [Product import template, no variants (XLSX)](/kb/import-products/import-template-products-no-variants-en.xlsx)

## Available templates

- **Product import template (no variants)** - the base template for a simple import.
- **Product (product.template) including eCommerce** - the same import, with the eCommerce fields added.
- **Odoo product import template ENG (No Variants)** - the same template with English notes, including eCommerce.

The template headers contain notes with further explanation. If you need to add extra product properties (such as length, width, m2), simply add extra columns.

## Import in two steps

1. The import of the products themselves via the Inventory module.
2. (Where applicable) The import of the related vendors, prices and vendor product codes via the Purchase module (Vendor Pricelists).

## Warehouse locations

A question that comes up regularly: how do you handle warehouse locations? You do not link them to a product. That works through putaway rules, which set the suggested location on receipt. For extra flexibility, you can store a product across multiple warehouse locations, for example when the default location is full.

So you do not specify warehouse locations at import. You enter them when you post the stock quantities.

## Product variants and product images

An import with product variants is a bit more involved. There is a separate guide for that: [Importing products with variants](/help/import-products-with-variants).

To import product images, follow the guide [Importing product images](/help/import-product-images).

## Need a hand with your import?

Stuck preparing your import file, or want a tailored template? [Book an Odoo scan](/scan) or [get in touch](/contact) - we will take a look with you.


# Importing reordering rules in Odoo: minimum and maximum stock
URL: https://www.fanatics.nl/help/import-reordering-rules
Language: en

Reordering rules keep your stock topped up automatically. You set a minimum and maximum quantity per product. When stock drops below the minimum, Odoo raises a purchase suggestion to replenish back up to the maximum.

**Download:** [Reordering rules import template (XLSX)](/kb/import-reordering-rules/import-template-minimale-voorraadregels.xlsx)

To set this up for many products at once, use the Excel template. It imports into the `stock.warehouse.orderpoint` model.

## Importing the template

Import the file under **Inventory -> Configuration -> Reordering Rules**. The headers in the Excel template carry a note for each column explaining what to enter.

## Key columns

| Column | Field | What it does |
|---|---|---|
| Product | `product_id` | The product the rule applies to (required). |
| Warehouse | `warehouse_id` | The warehouse the rule applies to. |
| Location | `location_id` | The stock location being monitored. |
| Min quantity | `product_min_qty` | Below this level a reordering rule triggers. |
| Max quantity | `product_max_qty` | Odoo replenishes up to this level. |
| Trigger | `trigger` | Automatic or manual replenishment. |
| Vendor | `supplier_id` | Optional: the vendor pricelist for the purchase suggestion. |

## Getting started

1. Fill in the template with a minimum and maximum quantity for each product.
2. Import the file under Inventory -> Configuration -> Reordering Rules.
3. Check the rules that were created and run a first replenishment to confirm the purchase suggestions are right.

A well-chosen minimum accounts for your lead time: the longer a vendor takes to deliver, the higher your minimum should sit to avoid running out.

## Need a hand with your import?

Stuck setting up your reordering rules, or want a tailored template? [Book an Odoo scan](/scan) or [get in touch](/contact) - we will take a look with you.


# Importing sales orders in Odoo
URL: https://www.fanatics.nl/help/import-sales-orders
Language: en

You can import sales orders and their order lines in one go through an Excel file. That saves a lot of manual entry when you take over a batch of open orders from another system.

**Download:** [Sales order import template (XLSX)](/kb/import-sales-orders/import-template-sales-orders.xlsx)

## Importing through the Sales module

Open the **Sales** module and switch to the list view of your orders. Click **Favorites -> Import records** and upload your Excel file.

The key trick: you can add several order lines to the same order at once. In your file, put all lines of one order under the same order reference. Odoo then links each line to the correct order automatically.

## Building the import file

Use one row per order line. The order details (customer, date) sit on the first row of each order; the follow-up rows repeat only the order reference plus their own product and quantity.

| Order Reference | Customer | Order Lines / Product | Order Lines / Quantity | Order Lines / Unit Price |
|---|---|---|---|---|
| SO0001 | Deco Addict | Desk | 2 | 145.00 |
| SO0001 |  | Desk chair | 4 | 89.00 |
| SO0002 | Azure Interior | Conference table | 1 | 950.00 |

In this example order **SO0001** gets two order lines and **SO0002** a single line.

**Note:** make sure the product names match the products in Odoo exactly, otherwise the import cannot link the line. If you prefer working with internal references, use the external ID or internal reference instead of the product name.

## Need a hand?

Stuck importing your orders? [Book an Odoo scan](/scan) or [get in touch](/contact) - we will take a look with you.


# Importing supplier pricelists in Odoo
URL: https://www.fanatics.nl/help/import-supplier-pricelists
Language: en

A supplier pricelist records which supplier you can order a product from and the price that supplier charges. You import it in the Purchase module.

**Download:** [Supplier pricelist import template (XLSX)](/kb/import-supplier-pricelists/import-template-leveranciersprijslijst.xlsx)

Go to **Purchase -> Configuration -> Vendor Pricelists** and start the import there.

## Template

Use our example template **Prijslijst leverancier (product.supplierinfo).xlsx** as the basis for your import file. Each column header carries extra guidance.

Ask us for the latest template if you do not have it - we will send it straight over.

## Preparation

Two things must be in place before you import:

- The **products** are entered.
- The **suppliers** are entered, with names that match your import file exactly.

If a name does not match precisely, Odoo will not link the row to the right supplier or product.

## Working with external IDs and product template IDs

The template uses the external ID. That makes this import a little more involved than most, because a supplier pricelist works with **product template IDs**, not product IDs.

Those product template IDs appear once you enable variants. To export the right list, temporarily switch variants on under **Inventory -> Configuration -> Settings -> Variants**.

Then export the product list. Odoo automatically includes the product template IDs, which you use in the import file. After that, you can switch variants back off - it has no further effect as long as you do not use it.

## Alternative: by product name

You can also work with product names via the **Product Template / Name** column. Only do this if you are 100% certain the names match exactly. The smallest difference breaks the link, so the product template ID route is safer.

## Need a hand with your import?

Stuck on the supplier pricelist or the product template IDs? [Book an Odoo scan](/scan) or [get in touch](/contact) - we will take a look with you.


# Importbestand openstaande posten
URL: https://www.fanatics.nl/nl/help/importbestand-openstaande-posten
Language: nl

Het importeren van openstaande posten hoort bij het [in gebruik nemen van Odoo Accounting](/help/odoo-boekhouding-beginbalans). Hieronder vind je de beschrijving en de boekingslogica voor het importeren van openstaande in- en verkoopfacturen. De importbestanden voor in- en verkoop zijn vrijwel gelijk. Maak vooraf de tussenrekeningen **110001** en **130001** aan, plus de dagboeken **inkoopfacturen beginbalans** en **verkoopfacturen beginbalans**.

**Download:** [Importtemplate openstaande posten (XLSX)](/kb/import-open-items/import-template-openstaande-posten.xlsx)

Er is ook een [video met de volledige procedure](https://www.loom.com/share/de7cb86b440040d7a253d23cec539cd6). De stappen staan hieronder uitgeschreven.

## Procedure voor in- en verkoopfacturen

Het standaard rekeningschema in Odoo (voor Nederland) gebruikt grootboeknummer **110000**. Vanaf de beginbalans willen we hier niet direct op boeken. We willen een creditbedrag op een balansrekening creëren dat even hoog is als het debetbedrag dat je bij de beginbalans boekt voor het totaal van de openstaande verkoopfacturen.

Werk daarom met een extra 'debiteurenrekening' die als tijdelijke tussenrekening dient, bijvoorbeeld rekening **110001**. Hier wordt de 'omzet' op geboekt bij de import van de facturen. Bij import krijg je de boeking:

```
110000 Debiteur
    aan 110001 Totaal openstaand / 'omzet' (boek geen btw mee)
```

Je chart of accounts ziet er dan zo uit:

![Chart of accounts met tijdelijke tussenrekening 110001](/kb/import-open-items/img-1.png)

Bij het invoeren van de beginbalans wordt rekening 110001 weer tegengeboekt (gedebiteerd). De openstaande posten staan nu open en kunnen via de bank afgeletterd worden.

## Het importbestand

Het importbestand kan er in Excel bijvoorbeeld zo uitzien:

| Number | Partner | Invoice_date | Due Date | Reference | Unit Price | Label | Account |
|---|---|---|---|---|---|---|---|
| INV/2022/00001 | Deco Addict | 2022-12-08 | 2022-01-07 | S00003 | 22137,5 | Beginbalans | 110001 |
| INV/2022/00002 | Deco Addict | 2022-12-08 | 2022-01-07 | S00002 | 48012,5 | Beginbalans | 110001 |
| INV/2022/00003 | Azure Interior | 2022-12-01 | 2022-01-31 | S00001 | 36512,5 | Beginbalans | 110001 |
| INV/2022/00004 | Deco Addict | 2022-11-30 | 2022-12-30 | S00004 | 36512,5 | Beginbalans | 110001 |

De prijskolom en de twee kolommen ernaast zijn in Odoo te vinden als **Invoice Lines / Unit Price**, **Invoice Lines / Label** en **Invoice Lines / Account**.

**Let op:** een belangrijke extra kolom om toe te voegen is **Invoice Lines / Taxes**. Laat deze leeg. Doe je dit niet, dan voegt Odoo op basis van de fiscal position van de klant btw aan de regel toe, waardoor het bedrag niet meer klopt. Bij inkoopfacturen is dit niet nodig, dus test het vooral voor de verkoopfacturen.

## Importeren en verwerken

Ga naar het dagboek Verkoopfacturen (Invoices) en start daar de import.

**Let op:** zijn de factuurnummers niet opvolgend, dan volgt na het importeren een foutmelding dat de nummers niet opeenvolgend zijn. Maak in dat geval een nieuw dagboek aan, **Customer Invoices (Beginbalans)**, en importeer de facturen daarin. Daarna kun je dit dagboek archiveren. Voeg bij creditfacturen een extra kolom **Journal_ID** toe en vul daar Customer Invoices (Beginbalans) in.

![Importscherm voor de openstaande facturen](/kb/import-open-items/img-2.png)

![Veldtoewijzing tijdens de import](/kb/import-open-items/img-3.png)

Na het importeren verwerk je de openstaande posten nog met **Post Entries**:

![Geïmporteerde facturen verwerken met Post Entries](/kb/import-open-items/img-4.png)

Open je nu een factuur en ga je naar het tabblad Journal Items, dan zie je de gemaakte boeking voor die post:

![Tabblad Journal Items met de tegenboeking](/kb/import-open-items/img-5.png)

Het totaalbedrag van alle geïmporteerde openstaande posten staat nu zowel debet op **110000 Debiteuren** op de balans als credit op **110001 Debiteuren** (BB-tussenrekening), in ons voorbeeld voor € 143.175,00:

![Saldo openstaande posten debet op 110000 en credit op 110001](/kb/import-open-items/img-6.png)

Bij het inboeken van de beginbalans wordt 110001 weer tegengeboekt.

## Hulp nodig bij je import?

Loop je vast bij het importbestand of de boekingen? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact) - dan kijken we met je mee.


# Importdatei für offene Posten
URL: https://www.fanatics.nl/de/help/importdatei-offene-posten
Language: de

{/* TODO(de-review): first-pass DE translation. */}

Der Import offener Posten ist Teil der [Inbetriebnahme von Odoo Accounting](/de/help/odoo-buchhaltung-eroeffnungsbilanz). Nachfolgend finden Sie die Beschreibung und die Buchungslogik für den Import offener Ein- und Ausgangsrechnungen. Die Importdateien für Ein- und Verkauf sind nahezu identisch. Legen Sie vorab die Zwischenkonten **110001** und **130001** an, dazu die Journale **Eingangsrechnungen Eröffnungsbilanz** und **Ausgangsrechnungen Eröffnungsbilanz**.

**Download:** [Open items import template (XLSX)](/kb/import-open-items/import-template-openstaande-posten.xlsx)

Es gibt auch ein [Video mit der vollständigen Prozedur](https://www.loom.com/share/de7cb86b440040d7a253d23cec539cd6). Die Schritte sind unten ausgeschrieben.

## Vorgehen für Ein- und Ausgangsrechnungen

Der Standard-Kontenrahmen in Odoo (für die Niederlande) verwendet die Sachkontonummer **110000**. Ab der Eröffnungsbilanz möchten wir hier nicht direkt buchen. Wir möchten auf einem Bilanzkonto einen Habenbetrag erzeugen, der genauso hoch ist wie der Sollbetrag, den Sie beim Erfassen der Eröffnungsbilanz für die Summe der offenen Ausgangsrechnungen buchen.

Verwenden Sie deshalb ein zusätzliches 'Debitorenkonto', das als temporäres Zwischenkonto dient, zum Beispiel Konto **110001**. Hier wird beim Import der Rechnungen der 'Umsatz' gebucht. Beim Import erhalten Sie die Buchung:

```
110000 Debitor
    an 110001 Summe offen / 'Umsatz' (keine USt. buchen)
```

Ihr Kontenplan sieht dann so aus:

![Kontenplan mit temporärem Zwischenkonto 110001](/kb/import-open-items/img-1.png)

Beim Erfassen der Eröffnungsbilanz wird Konto 110001 wieder gegengebucht (im Soll). Die offenen Posten stehen nun offen und können über die Bank ausgeglichen werden.

## Die Importdatei

Die Importdatei in Excel könnte zum Beispiel so aussehen:

| Number | Partner | Invoice_date | Due Date | Reference | Unit Price | Label | Account |
|---|---|---|---|---|---|---|---|
| INV/2022/00001 | Deco Addict | 2022-12-08 | 2022-01-07 | S00003 | 22137,5 | Eröffnungsbilanz | 110001 |
| INV/2022/00002 | Deco Addict | 2022-12-08 | 2022-01-07 | S00002 | 48012,5 | Eröffnungsbilanz | 110001 |
| INV/2022/00003 | Azure Interior | 2022-12-01 | 2022-01-31 | S00001 | 36512,5 | Eröffnungsbilanz | 110001 |
| INV/2022/00004 | Deco Addict | 2022-11-30 | 2022-12-30 | S00004 | 36512,5 | Eröffnungsbilanz | 110001 |

Die Preisspalte und die beiden Spalten daneben heißen in Odoo **Invoice Lines / Unit Price**, **Invoice Lines / Label** und **Invoice Lines / Account**.

**Hinweis:** Eine wichtige Zusatzspalte ist **Invoice Lines / Taxes**. Lassen Sie diese leer. Andernfalls fügt Odoo auf Basis der Steuerposition des Kunden USt. zur Zeile hinzu, wodurch der Betrag nicht mehr stimmt. Bei Eingangsrechnungen ist das nicht nötig, testen Sie es also vor allem für die Ausgangsrechnungen.

## Importieren und buchen

Gehen Sie zum Journal Ausgangsrechnungen (Invoices) und starten Sie dort den Import.

**Hinweis:** Sind die Rechnungsnummern nicht fortlaufend, erhalten Sie nach dem Import eine Fehlermeldung, dass die Nummern nicht aufeinanderfolgend sind. Legen Sie in diesem Fall ein neues Journal an, **Customer Invoices (Eröffnungsbilanz)**, und importieren Sie die Rechnungen dort. Danach können Sie dieses Journal archivieren. Fügen Sie bei Gutschriften eine zusätzliche Spalte **Journal_ID** hinzu und tragen Sie dort Customer Invoices (Eröffnungsbilanz) ein.

![Importbildschirm für die offenen Rechnungen](/kb/import-open-items/img-2.png)

![Feldzuordnung während des Imports](/kb/import-open-items/img-3.png)

Nach dem Import buchen Sie die offenen Posten noch mit **Post Entries**:

![Importierte Rechnungen mit Post Entries buchen](/kb/import-open-items/img-4.png)

Wenn Sie nun eine Rechnung öffnen und zum Tab Journal Items wechseln, sehen Sie die für diesen Posten erstellte Buchung:

![Tab Journal Items mit der Gegenbuchung](/kb/import-open-items/img-5.png)

Die Summe aller importierten offenen Posten steht nun sowohl im Soll auf **110000 Debitoren** in der Bilanz als auch im Haben auf **110001 Debitoren** (Zwischenkonto Eröffnungsbilanz), in unserem Beispiel über € 143.175,00:

![Saldo der offenen Posten, Soll auf 110000 und Haben auf 110001](/kb/import-open-items/img-6.png)

Beim Buchen der Eröffnungsbilanz wird 110001 wieder gegengebucht.

## Brauchen Sie Unterstützung beim Import?

Kommen Sie bei der Importdatei oder den Buchungen nicht weiter? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact) - wir schauen gemeinsam mit Ihnen.


# Interne Referentie automatisch nummeren in Odoo
URL: https://www.fanatics.nl/nl/help/interne-referentie-automatisch-nummeren
Language: nl

Wil je dat elk nieuw product automatisch een opvolgend nummer krijgt in het veld Internal Reference (het productnummer)? Standaard laat Odoo dat veld leeg of vult een medewerker het handmatig in. Met een nummerreeks en een kleine automated action laat je Odoo het werk doen.

Je hebt hiervoor drie dingen nodig:

1. Zet het veld **Internal Reference** op Read Only, zodat niemand het handmatig overschrijft.
2. Maak een **nummerreeks** (sequence) aan met een eigen code en prefix.
3. Maak een **automated action** met een Python-expressie die bij het aanmaken het eerstvolgende vrije nummer uit de reeks ophaalt.

## De nummerreeks aanmaken

Ga naar de instellingen voor nummerreeksen (Settings, Technical, Sequences & Identifiers, Sequences) en maak een nieuwe reeks aan. Geef de reeks een duidelijke naam en een eigen **reekscode** - die code gebruik je straks in de automated action. Stel de prefix, de reeksgrootte (aantal cijfers) en de stap in.

![Odoo-nummerreeks met reekscode, prefix BM-, reeksgrootte 4 en volgend nummer](/kb/internal-reference-numbering/img-1.png)

In dit voorbeeld is de reekscode `bm.product.numbers`, met prefix `BM-` en een reeksgrootte van 4 cijfers. Het volgende nummer wordt dan bijvoorbeeld `BM-0115`.

## De automated action koppelen

Maak vervolgens een automated action aan op het model **Product**. Zet de trigger op **On Creation**, zodat de actie afgaat zodra een nieuw product wordt aangemaakt. Kies als actie **Update the Record** en vul bij het veld Internal Reference een **Python expression** in die het volgende nummer uit de reeks ophaalt.

![Automated action op het Product-model met trigger On Creation en een Python-expressie voor Internal Reference](/kb/internal-reference-numbering/img-2.png)

Gebruik deze expressie en vervang de reekscode door die van jouw eigen reeks:

```python
record.env['ir.sequence'].next_by_code('tp.product.number')
```

Vanaf nu krijgt elk nieuw product automatisch het eerstvolgende vrije nummer in het veld Internal Reference.

## Hulp nodig bij je Odoo-inrichting?

Wil je dit netjes ingericht hebben of loop je vast op een eigen nummerlogica? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact) - dan kijken we met je mee.


# Interne Referenz in Odoo automatisch nummerieren
URL: https://www.fanatics.nl/de/help/interne-referenz-automatisch-nummerieren
Language: de

{/* TODO(de-review): first-pass DE translation, needs native-speaker review. */}

Möchten Sie, dass jedes neue Produkt automatisch eine fortlaufende Nummer im Feld Interne Referenz (die Produktnummer) erhält? Standardmäßig lässt Odoo dieses Feld leer oder verlässt sich darauf, dass jemand es manuell ausfüllt. Mit einer Nummernfolge und einer kleinen automatisierten Aktion übernimmt Odoo diese Arbeit für Sie.

Dafür benötigen Sie drei Dinge:

1. Setzen Sie das Feld **Interne Referenz** auf Schreibgeschützt, damit niemand es manuell überschreibt.
2. Legen Sie eine **Nummernfolge** mit eigenem Code und Präfix an.
3. Legen Sie eine **automatisierte Aktion** mit einem Python-Ausdruck an, der bei der Erstellung die nächste freie Nummer aus der Folge holt.

## Die Nummernfolge anlegen

Gehen Sie zu den Einstellungen für Nummernfolgen (Settings, Technical, Sequences & Identifiers, Sequences) und legen Sie eine neue Folge an. Geben Sie ihr einen klaren Namen und einen eigenen **Folgencode** - diesen Code verwenden Sie später in der automatisierten Aktion. Stellen Sie das Präfix, die Folgengröße (Anzahl der Stellen) und den Schritt ein.

![Odoo-Nummernfolge mit Folgencode, Präfix BM-, Folgengröße 4 und nächster Nummer](/kb/internal-reference-numbering/img-1.png)

In diesem Beispiel lautet der Folgencode `bm.product.numbers`, mit dem Präfix `BM-` und einer Folgengröße von 4 Stellen. Die nächste Nummer ist dann zum Beispiel `BM-0115`.

## Die automatisierte Aktion verknüpfen

Legen Sie anschließend eine automatisierte Aktion am Modell **Product** an. Setzen Sie den Auslöser auf **On Creation**, damit die Aktion ausgelöst wird, sobald ein neues Produkt erstellt wird. Wählen Sie als Aktion **Update the Record** und hinterlegen Sie für das Feld Interne Referenz einen **Python-Ausdruck**, der die nächste Nummer aus der Folge holt.

![Automatisierte Aktion am Modell Product mit dem Auslöser On Creation und einem Python-Ausdruck für die Interne Referenz](/kb/internal-reference-numbering/img-2.png)

Verwenden Sie diesen Ausdruck und ersetzen Sie den Folgencode durch Ihren eigenen:

```python
record.env['ir.sequence'].next_by_code('tp.product.number')
```

Ab jetzt erhält jedes neue Produkt automatisch die nächste freie Nummer im Feld Interne Referenz.

## Brauchen Sie Unterstützung bei Ihrer Odoo-Einrichtung?

Möchten Sie das sauber eingerichtet haben oder kommen Sie bei einer eigenen Nummernlogik nicht weiter? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact) - wir schauen gemeinsam mit Ihnen.


# Kontakte in Odoo importieren
URL: https://www.fanatics.nl/de/help/kontakte-importieren
Language: de

{/* TODO(de-review): first-pass DE translation. */}

Für den Import von Kontakten in Odoo verwenden Sie zwei Excel-Vorlagen: eine für Unternehmen und eine für die Ansprechpartner, die zu diesen Unternehmen gehören.

**Download:** [Importvorlage Kontakte (XLSX)](/kb/import-contacts/import-template-contacten.xlsx)

## Unternehmen importieren

Importieren Sie zuerst die Unternehmen selbst. Verwenden Sie dafür die Vorlage **Partner Import file - Companies.xlsx** (erhältlich bei Radical Fanatics).

## Ansprechpartner importieren

Importieren Sie anschließend die Ansprechpartner mit der Vorlage **Partner Import file - companies contacts.xlsx** (erhältlich bei Radical Fanatics).

Arbeiten Sie in dieser Datei mit der Unternehmens-ID, damit jeder Ansprechpartner dem richtigen Unternehmen zugeordnet wird. Mit derselben Datei können Sie auch einzelne Personen ohne Unternehmen importieren.

## Brauchen Sie Unterstützung?

[Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact)


# Konten nur auf Einladung in Odoo Website erstellen
URL: https://www.fanatics.nl/de/help/konto-nur-auf-einladung-erstellen
Language: de

{/* TODO(de-review): first-pass DE translation. */}

In Odoo V16 verhindern Sie etwas anders als in V15, dass Website-Besucher ein eigenes Konto anlegen. Damit Konten nur auf Einladung entstehen, folgen Sie diesem Schritt.

## Konten nur auf Einladung einstellen

Gehen Sie in die **Website**-App -> **Konfiguration** -> **Einstellungen** -> **Shop - Checkout Process** und waehlen Sie **Deaktiviert (als Gast kaufen)**.

![Odoo Website-Einstellung Checkout Process mit deaktivierter Option Als Gast kaufen](/kb/account-by-invitation/img-1.png)

Ab sofort kann ein Besucher waehrend des Bestellvorgangs kein Konto mehr anlegen. Den Portalzugang vergeben Sie selbst, indem Sie einer Nutzerin oder einem Nutzer eine Einladung senden.

## Brauchen Sie Unterstuetzung bei der Odoo-Einrichtung?

Moechten Sie Website und Portalzugang sauber absichern? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact) - wir schauen gemeinsam mit Ihnen.


# Leveranciersprijslijsten importeren in Odoo
URL: https://www.fanatics.nl/nl/help/leveranciersprijslijsten-importeren
Language: nl

Een leveranciersprijslijst legt vast welk product je bij welke leverancier kunt bestellen en welke prijs die leverancier rekent. Je importeert deze in de inkoopmodule.

**Download:** [Importtemplate leveranciersprijslijst (XLSX)](/kb/import-supplier-pricelists/import-template-leveranciersprijslijst.xlsx)

Ga naar **Inkoop -> Configuratie -> Leveranciersprijslijsten** en start daar de import.

## Template

Gebruik onze voorbeeldtemplate **Prijslijst leverancier (product.supplierinfo).xlsx** als basis voor je importbestand. In de kop van elke kolom staat extra uitleg.

Vraag de actuele template bij ons op als je die niet hebt - we sturen hem direct toe.

## Voorbereiding

Twee dingen moeten op orde zijn voordat je importeert:

- De **producten** zijn ingevoerd.
- De **leveranciers** zijn ingevoerd, met exact dezelfde namen als in je importbestand.

Klopt een naam niet precies, dan koppelt Odoo de regel niet aan de juiste leverancier of het juiste product.

## Werken met externe ID's en product template ID's

In de template werken we met de externe ID. Dat maakt deze import iets bewerkelijker dan de meeste, want een leveranciersprijslijst werkt met **product template ID's**, niet met product ID's.

Die product template ID's ontstaan zodra je varianten activeert. Om de juiste lijst te exporteren, zet je daarom varianten tijdelijk aan onder **Inventory -> Configuration -> Settings -> Variants**.

Exporteer vervolgens de productenlijst. Odoo neemt dan automatisch de product template ID's mee, die je in het importbestand gebruikt. Daarna kun je de optie varianten weer uitzetten - dat heeft geen verder effect zolang je er niets mee doet.

## Alternatief: op productnaam

Je kunt ook werken met productnamen via de kolom **Product Template / Name**. Doe dit alleen als je 100% zeker weet dat de namen exact overeenkomen. Bij de kleinste afwijking mislukt de koppeling, dus de route via product template ID's is veiliger.

## Hulp nodig bij je import?

Loop je vast op de leveranciersprijslijst of de product template ID's? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact) - dan kijken we met je mee.


# Lieferantenpreislisten in Odoo importieren
URL: https://www.fanatics.nl/de/help/lieferantenpreislisten-importieren
Language: de

{/* TODO(de-review): first-pass DE translation. */}

Eine Lieferantenpreisliste hält fest, bei welchem Lieferanten Sie ein Produkt bestellen können und welchen Preis dieser Lieferant berechnet. Sie importieren sie im Einkaufsmodul.

**Download:** [Importvorlage Lieferantenpreisliste (XLSX)](/kb/import-supplier-pricelists/import-template-leveranciersprijslijst.xlsx)

Gehen Sie zu **Einkauf -> Konfiguration -> Lieferantenpreislisten** und starten Sie dort den Import.

## Vorlage

Verwenden Sie unsere Beispielvorlage **Prijslijst leverancier (product.supplierinfo).xlsx** als Grundlage für Ihre Importdatei. In der Kopfzeile jeder Spalte stehen weitere Hinweise.

Fragen Sie die aktuelle Vorlage bei uns an, falls Sie sie nicht haben - wir senden sie Ihnen direkt zu.

## Vorbereitung

Zwei Dinge müssen stimmen, bevor Sie importieren:

- Die **Produkte** sind erfasst.
- Die **Lieferanten** sind erfasst, mit Namen, die exakt mit Ihrer Importdatei übereinstimmen.

Stimmt ein Name nicht genau, verknüpft Odoo die Zeile nicht mit dem richtigen Lieferanten oder Produkt.

## Arbeiten mit externen IDs und Produktvorlagen-IDs

Die Vorlage nutzt die externe ID. Das macht diesen Import etwas aufwändiger als die meisten, denn eine Lieferantenpreisliste arbeitet mit **Produktvorlagen-IDs**, nicht mit Produkt-IDs.

Diese Produktvorlagen-IDs entstehen, sobald Sie Varianten aktivieren. Um die richtige Liste zu exportieren, schalten Sie Varianten daher vorübergehend unter **Inventory -> Configuration -> Settings -> Variants** ein.

Exportieren Sie anschließend die Produktliste. Odoo übernimmt automatisch die Produktvorlagen-IDs, die Sie in der Importdatei verwenden. Danach können Sie Varianten wieder ausschalten - das hat keine weitere Wirkung, solange Sie nichts damit tun.

## Alternative: über den Produktnamen

Sie können auch mit Produktnamen über die Spalte **Product Template / Name** arbeiten. Tun Sie das nur, wenn Sie zu 100% sicher sind, dass die Namen exakt übereinstimmen. Die kleinste Abweichung unterbricht die Verknüpfung, daher ist der Weg über die Produktvorlagen-IDs sicherer.

## Brauchen Sie Unterstützung beim Import?

Kommen Sie bei der Lieferantenpreisliste oder den Produktvorlagen-IDs nicht weiter? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact) - wir schauen gemeinsam mit Ihnen.


# Unit of Measure, Packaging en Packages in Odoo uitgelegd
URL: https://www.fanatics.nl/nl/help/maateenheid-verpakkingen-packages-odoo
Language: nl

Wat is het verschil tussen Unit of Measure (maateenheid), Packaging (productverpakkingen) en Packages (verpakkingen) in Odoo? De drie begrippen lijken op elkaar, maar elk speelt een eigen rol in verkoop, voorraad en levering.

## De drie begrippen kort

1. **Unit of Measure (UoM)**: de eenheid waarin een product verkocht, opgeslagen of ingekocht wordt. Denk aan stuks, kilo's of liters.
2. **Packaging (productverpakkingen)**: een verpakking met meerdere, identieke producten. Je gebruikt dit om meerdere eenheden van hetzelfde product in een keer te verkopen, bijvoorbeeld een doos van twaalf.
3. **Packages (verpakkingen)**: een doos waarin een of meer producten van hetzelfde of verschillend type worden verzonden. Dit gebruik je alleen bij het leveren van goederen.

## Video met uitleg

In de onderstaande video lopen we de drie begrippen na in Odoo:

- UoM komt aan bod vanaf het begin van de video.
- Packaging volgt vanaf minuut 10.
- Packages zie je vanaf minuut 17:15.

[Bekijk de uitleg op YouTube](https://youtu.be/I3YtiWgK84U)

De video is opgenomen in Odoo versie 14, maar de werkwijze geldt ook voor latere versies.

Tip: lees ook het artikel over verzendkosten berekenen in Odoo, waarin Packages verder terugkomt.

## Hulp nodig bij je inrichting?

Twijfel je hoe je UoM, Packaging en Packages het beste inricht voor jouw producten? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact) - dan kijken we met je mee.


# Unit of Measure, Packaging und Packages in Odoo erklärt
URL: https://www.fanatics.nl/de/help/masseinheit-verpackungen-packages-odoo
Language: de

{/* TODO(de-review): first-pass DE translation. */}

Was ist der Unterschied zwischen Unit of Measure (Maßeinheit), Packaging (Produktverpackungen) und Packages (Verpackungen) in Odoo? Die drei Begriffe ähneln sich, doch jeder spielt eine eigene Rolle in Verkauf, Bestand und Lieferung.

## Die drei Begriffe kurz erklärt

1. **Unit of Measure (UoM)**: die Einheit, in der ein Produkt verkauft, gelagert oder eingekauft wird. Etwa Stück, Kilogramm oder Liter.
2. **Packaging (Produktverpackungen)**: eine Verpackung mit mehreren identischen Produkten. Sie nutzen sie, um mehrere Einheiten desselben Produkts auf einmal zu verkaufen, zum Beispiel einen Karton mit zwölf Stück.
3. **Packages (Verpackungen)**: ein Karton, in dem ein oder mehrere Produkte desselben oder unterschiedlichen Typs versandt werden. Diesen nutzen Sie nur bei der Lieferung von Waren.

## Video mit Erklärung

Im folgenden Video gehen wir die drei Begriffe in Odoo durch:

- UoM wird ab dem Anfang des Videos behandelt.
- Packaging folgt ab Minute 10.
- Packages sehen Sie ab Minute 17:15.

[Erklärung auf YouTube ansehen](https://youtu.be/I3YtiWgK84U)

Das Video wurde in Odoo Version 14 aufgenommen, das Vorgehen gilt jedoch auch für spätere Versionen.

Tipp: Lesen Sie auch den Artikel über die Berechnung von Versandkosten in Odoo, in dem Packages erneut vorkommt.

## Brauchen Sie Unterstützung bei der Einrichtung?

Sind Sie unsicher, wie Sie UoM, Packaging und Packages für Ihre Produkte am besten einrichten? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact) - wir schauen gemeinsam mit Ihnen.


# Beschaffungsregeln in Odoo importieren: Mindest- und Höchstbestand
URL: https://www.fanatics.nl/de/help/mindestbestandsregeln-importieren
Language: de

{/* TODO(de-review): first-pass DE translation. */}

Mit Beschaffungsregeln hält Odoo Ihren Bestand automatisch auf dem gewünschten Niveau. Sie legen pro Produkt einen Mindest- und Höchstbestand fest. Fällt der Bestand unter das Minimum, löst Odoo automatisch einen Einkaufsvorschlag aus, um wieder bis zum Maximum aufzufüllen.

**Download:** [Importvorlage Mindestbestandsregeln (XLSX)](/kb/import-reordering-rules/import-template-minimale-voorraadregels.xlsx)

Um dies für viele Artikel auf einmal einzurichten, verwenden Sie die Excel-Vorlage. Sie importiert in das Modell `stock.warehouse.orderpoint`.

## Die Vorlage importieren

Importieren Sie die Datei unter **Lager -> Konfiguration -> Beschaffungsregeln**. Die Kopfzeilen der Excel-Vorlage enthalten zu jeder Spalte einen Hinweis, was Sie eintragen.

## Wichtigste Spalten

| Spalte | Feld | Bedeutung |
|---|---|---|
| Produkt | `product_id` | Der Artikel, für den die Regel gilt (Pflichtfeld). |
| Lagerhaus | `warehouse_id` | Das Lagerhaus, für das die Regel gilt. |
| Lagerort | `location_id` | Der überwachte Lagerort. |
| Mindestmenge | `product_min_qty` | Unterhalb dieses Niveaus wird eine Beschaffungsregel ausgelöst. |
| Höchstmenge | `product_max_qty` | Bis zu diesem Niveau füllt Odoo auf. |
| Auslöser | `trigger` | Automatische oder manuelle Auffüllung. |
| Lieferant | `supplier_id` | Optional: die Lieferantenpreisliste für den Einkaufsvorschlag. |

## Erste Schritte

1. Füllen Sie die Vorlage pro Produkt mit einem Mindest- und Höchstbestand aus.
2. Importieren Sie die Datei unter Lager -> Konfiguration -> Beschaffungsregeln.
3. Prüfen Sie die angelegten Regeln und führen Sie einen ersten Auffülllauf durch, um zu sehen, ob die Einkaufsvorschläge stimmen.

Ein gut gewähltes Minimum berücksichtigt Ihre Lieferzeit: Je länger ein Lieferant für die Lieferung braucht, desto höher sollte Ihr Minimum liegen, damit Sie nicht ohne Bestand dastehen.

## Brauchen Sie Unterstützung beim Import?

Kommen Sie beim Einrichten Ihrer Beschaffungsregeln nicht weiter oder wünschen Sie eine maßgeschneiderte Vorlage? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact) - wir schauen gemeinsam mit Ihnen.


# Minimale voorraadregels / aanvulopdrachten importeren in Odoo
URL: https://www.fanatics.nl/nl/help/minimale-voorraadregels-importeren
Language: nl

Met aanvulopdrachten (reordering rules) houdt Odoo je voorraad automatisch op peil. Je legt per product een minimum- en maximumvoorraad vast. Zakt de voorraad onder het minimum, dan doet Odoo automatisch een inkoopvoorstel om weer aan te vullen tot het maximum.

**Download:** [Importtemplate minimale voorraadregels (XLSX)](/kb/import-reordering-rules/import-template-minimale-voorraadregels.xlsx)

Om dit voor veel artikelen in één keer in te richten, gebruik je het Excel-template. Het importeert naar het model `stock.warehouse.orderpoint`.

## Het template importeren

Importeer het bestand onder **Voorraad -> Configuratie -> Aanvulopdrachten**. In de kopregels van het Excel-template staat per kolom extra uitleg over wat je invult.

## Belangrijkste kolommen

| Kolom | Veld | Toelichting |
|---|---|---|
| Product | `product_id` | Het artikel waarvoor de regel geldt (verplicht). |
| Magazijn | `warehouse_id` | Het magazijn waarop de regel van toepassing is. |
| Locatie | `location_id` | De voorraadlocatie die wordt gemonitord. |
| Min. hoeveelheid | `product_min_qty` | Onder dit niveau ontstaat een aanvulopdracht. |
| Max. hoeveelheid | `product_max_qty` | Tot dit niveau vult Odoo aan. |
| Trigger | `trigger` | Automatisch of handmatig aanvullen. |
| Leverancier | `supplier_id` | Optioneel: de leveranciersprijslijst voor het inkoopvoorstel. |

## Aan de slag

1. Vul het template per product in met een minimum- en maximumvoorraad.
2. Importeer het bestand onder Voorraad -> Configuratie -> Aanvulopdrachten.
3. Controleer de aangemaakte regels en draai een eerste aanvulronde om te zien of de inkoopvoorstellen kloppen.

Een goed gekozen minimum houdt rekening met je levertijd: hoe langer de leverancier erover doet, hoe hoger je minimum moet liggen om niet zonder voorraad te komen.

## Hulp nodig bij je import?

Loop je vast bij het inrichten van je aanvulopdrachten, of wil je een template op maat? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact) - dan kijken we met je mee.


# Customising label printing reports (ZPL, Zebra)
URL: https://www.fanatics.nl/help/odoo-customise-zpl-label-reports
Language: en

*Warning: always make a solid backup before you run any of the steps below.*

Odoo ships several standard options for printing Zebra labels. You cannot change them in Studio, but you can adjust (a copy of) the standard report. That takes a basic grasp of the ZPL code behind Zebra labels - which, happily, is not complicated.

![Printer dialog in Odoo for printing product labels, with the option to print a Zebra (ZPL) label](/kb/zpl-label-printing/img-1.png)

## Adjusting the default settings

You adjust the default settings of this label through the Qweb tab of the underlying report.

Turn on Developer mode first. Then, from the home screen, type `/reports` to jump to all reports.

![Searching for /reports from the home screen in Odoo](/kb/zpl-label-printing/img-2.png)

Choose **Settings > Technical > Actions > Reports** and select the report you want to edit, in this case **Product Label (ZPL)**.

![List of reports in Odoo with Product Label (ZPL) selected](/kb/zpl-label-printing/img-3.png)

Top right you will find the link to the Qweb part of this report. This Qweb code controls the label layout.

![Link to the Qweb view of the ZPL report, top right of the report screen](/kb/zpl-label-printing/img-4.png)

## The ZPL label code

Open that view and the **Architecture** tab shows the code tied to your current installation and module options. You can edit the code right here.

**Note:** changes to the standard layout will almost certainly be overwritten on the next update. So create an inherited view instead. That is beyond the scope of this article, but for testing it is handy to tweak the report quickly this way.

Good to know: you can comment out a line with a semicolon (`;`). Everything after a semicolon on a line counts as a comment and is ignored by the ZPL interpreter.

Make a backup of the current code too, so you can always return to the default.

The code you see might look like this:

![Architecture tab showing the standard ZPL code of the Product Label (ZPL) report](/kb/zpl-label-printing/img-5.png)

```xml
<t t-name="stock.label_product_product_view">
    <t t-foreach="quantity.items()" t-as="barcode_and_qty_by_product">
        <t t-set="product" t-value="barcode_and_qty_by_product[0]"/>
        <t t-foreach="barcode_and_qty_by_product[1]" t-as="barcode_and_qty">
            <t t-set="barcode" t-value="barcode_and_qty[0]"/>
            <t t-foreach="range(barcode_and_qty[1])" t-as="qty">
                <t t-translation="off">
^XA
^FT100,80^A0N,40,30^FD<t t-esc="product.display_name"/>^FS
<t t-if="product.default_code and len(product.default_code) > 15">
^FT100,115^A0N,30,24^FD<t t-esc="product.default_code[:15]"/>^FS
^FT100,150^A0N,30,24^FD<t t-esc="product.default_code[15:30]"/>^FS
</t>
<t t-else="">
^FT100,150^A0N,30,24^FD<t t-esc="product.default_code"/>^FS
</t>
<t t-if="price_included">
^FO600,100,1
^CI28
<t t-if="product.currency_id.position == 'after'">
^A0N,66,48^FH^FD<t t-esc="product.list_price" t-options="{&quot;widget&quot;: &quot;float&quot;, &quot;precision&quot;: 2}"/><t t-esc="product.currency_id.symbol"/>^FS
</t>
<t t-if="product.currency_id.position == 'before'">
^A0N,66,48^FH^FD<t t-esc="product.currency_id.symbol"/><t t-esc="product.list_price" t-options="{&quot;widget&quot;: &quot;float&quot;, &quot;precision&quot;: 2}"/>^FS
</t>
</t>
<t t-if="barcode">
^FO100,160^BY3
^BCN,100,Y,N,N
^FD<t t-esc="barcode"/>^FS
</t>
^XZ
                </t>
            </t>
        </t>
    </t>
</t>
```

### What the code does

This code prints labels for products with their barcodes and quantities. Line by line:

1. `<t t-name="stock.label_product_product_view">`: the name of the template for printing product labels.
2. `<t t-foreach="quantity.items()" t-as="barcode_and_qty_by_product">`: loops through each item in `quantity` and assigns it to `barcode_and_qty_by_product`, so the barcode and quantity per product can be printed.
3. `<t t-set="product" t-value="barcode_and_qty_by_product[0]"/>`: sets `product` to the first element, which represents the product.
4. `<t t-foreach="barcode_and_qty_by_product[1]" t-as="barcode_and_qty">`: loops through the list `barcode_and_qty_by_product[1]`, allowing several barcodes and quantities for the same product.
5. `<t t-set="barcode" t-value="barcode_and_qty[0]"/>`: sets `barcode` to the first element, which represents the barcode.
6. `<t t-foreach="range(barcode_and_qty[1])" t-as="qty">`: loops through a range of numbers, with the count set by the second element, so the same barcode and quantity print multiple times.
7. `<t t-translation="off">`: turns off translation for the label content, keeping the text unchanged.
8. `^XA`: starts the ZPL commands.
9. `^FT100,80^A0N,40,30^FD<t t-esc="product.display_name"/>^FS`: sets the position and font of the first line and prints the product display name.
10. `<t t-if="product.default_code and len(product.default_code) > 15">`: checks whether the product has an internal reference longer than 15 characters.
11. `^FT100,115^A0N,30,24^FD<t t-esc="product.default_code[:15]"/>^FS`: prints the first 15 characters of the internal reference.
12. `^FT100,150^A0N,30,24^FD<t t-esc="product.default_code[15:30]"/>^FS`: prints the next characters of the internal reference.
13. `<t t-else="">`: the alternative when the condition is false.
14. `^FT100,150^A0N,30,24^FD<t t-esc="product.default_code"/>^FS`: prints the full internal reference.
15. `<t t-if="price_included">`: checks whether the price is included.
16. `^FO600,100,1`: sets the position of the price on the label.
17. `^CI28`: sets the character encoding to UTF-8.
18. `<t t-if="product.currency_id.position == 'after'">`: checks whether the currency symbol sits after the price.
19. `^A0N,66,48^FH^FD...^FS`: prints the price and the currency symbol.
20. `<t t-if="product.currency_id.position == 'before'">`: checks whether the currency symbol sits before the price.
21. `^A0N,66,48^FH^FD...^FS`: prints the currency symbol and the price.
22. `<t t-if="barcode">`: checks whether a barcode exists.
23. `^FO100,160^BY3`: sets the position and barcode parameters.
24. `^BCN,100,Y,N,N`: sets the barcode type and size.
25. `^FD<t t-esc="barcode"/>^FS`: prints the barcode.
26. `^XZ`: ends the ZPL commands.

The result is a label with the product name, internal reference, price, and barcode for each product.

## Tip: let an AI assistant help

An AI assistant is great for tweaking a single part. Ask "How do I shrink the font and the barcode in the code below by 50%?" and you get the following.

The font size is set with `^A0N` followed by the size parameters; halve those values to make the text smaller. The barcode size is set with `^BY3`; lower it to, say, `2.5`, `2`, or `1.5` to shrink the barcode.

The adjusted code, with font and barcode both 50% smaller:

```xml
<t t-name="stock.label_product_product_view">
    <t t-foreach="quantity.items()" t-as="barcode_and_qty_by_product">
        <t t-set="product" t-value="barcode_and_qty_by_product[0]"/>
        <t t-foreach="barcode_and_qty_by_product[1]" t-as="barcode_and_qty">
            <t t-set="barcode" t-value="barcode_and_qty[0]"/>
            <t t-foreach="range(barcode_and_qty[1])" t-as="qty">
                <t t-translation="off">
^XA
^FT100,80^A0N,20,15^FD<t t-esc="product.display_name"/>^FS
<t t-if="product.default_code and len(product.default_code) > 15">
^FT100,115^A0N,15,12^FD<t t-esc="product.default_code[:15]"/>^FS
^FT100,150^A0N,15,12^FD<t t-esc="product.default_code[15:30]"/>^FS
</t>
<t t-else="">
^FT100,150^A0N,15,12^FD<t t-esc="product.default_code"/>^FS
</t>
<t t-if="price_included">
^FO600,100,1
^CI28
<t t-if="product.currency_id.position == 'after'">
^A0N,33,24^FH^FD<t t-esc="product.list_price" t-options="{&quot;widget&quot;: &quot;float&quot;, &quot;precision&quot;: 2}"/><t t-esc="product.currency_id.symbol"/>^FS
</t>
<t t-if="product.currency_id.position == 'before'">
^A0N,33,24^FH^FD<t t-esc="product.currency_id.symbol"/><t t-esc="product.list_price" t-options="{&quot;widget&quot;: &quot;float&quot;, &quot;precision&quot;: 2}"/>^FS
</t>
</t>
<t t-if="barcode">
^FO100,160^BY2
^BCN,50,Y,N,N
^FD<t t-esc="barcode"/>^FS
</t>
^XZ
                </t>
            </t>
        </t>
    </t>
</t>
```

The font parameters are lowered (for example 20, 15, 15, 12) and the barcode parameters set to a smaller barcode (`^BY2`, `^BCN,50`).

## Need a hand with your Odoo labels?

Stuck customising a ZPL report? [Book an Odoo scan](/scan) or [get in touch](/contact) - we will take a look with you.


# Welke Odoo-modules moet ik kiezen om mee te starten?
URL: https://www.fanatics.nl/nl/help/odoo-modules-waar-beginnen
Language: nl

Odoo heeft 80+ modules. Maar **begin nooit met alles tegelijk**. Onze regel: kies drie modules die je grootste pijn oplossen, ga daar mee live, breid daarna uit.

## De drie meest gekozen start-modules

### 1. Sales + CRM
Bijna alle klanten beginnen hier. Pipeline-management, offertes, orderbevestiging, automatische opvolging. Direct waarde, sales-cycli worden korter en niemand hoeft meer in een spreadsheet te kijken.

### 2. Inventory (Voorraad)
Voor productie- en handelsbedrijven onmisbaar. Multi-warehouse, barcodes, automatische bijbestelling, realtime voorraadwaarde. Vaak gekoppeld aan Sales.

### 3. Accounting
**Optioneel** in fase 1, sommige klanten houden hun bestaande boekhouding ([Exact](/odoo-exact-integration), [Twinfield](/odoo-twinfield-integration)) en koppelen die aan Odoo. Andere stappen over naar Odoo Accounting voor maximale integratie. Zie ook: [Kun je Odoo koppelen aan Exact of Twinfield?](/help/koppelingen-exact-twinfield)

## Wat in een Phase 2 hoort

- **Manufacturing (MRP)**, als productie complexer wordt, of als je BOMs en work orders nodig hebt.
- **Project**, voor projectgestuurde organisaties (bouw, dienstverlening, IT).
- **HR + Timesheets**, koppel pas aan na de basis goed loopt.
- **eCommerce**, Odoo's webshop is functioneel, maar als je shop al draait op [Shopify](/odoo-vs-shopify) of Magento, laat dat zo.

## Wat een Phase 3 kan zijn

- **Marketing Automation**, automatische e-mailcampagnes, lead-scoring.
- **Helpdesk**, als je een support-team hebt dat tickets bijhoudt.
- **Subscription**, voor SaaS- en abonnementsmodellen.

## De fout die we vaak zien

Klanten die proberen **alles in één keer** te implementeren. Dat duurt te lang, het team raakt overbelast, en de go-live wordt uitgesteld tot iedereen het beu is. Doe het stapsgewijs.

Onzeker waar te beginnen? [Plan een scan](/scan), we mappen je grootste pijnen en zeggen welke modules ze oplossen.


# Etikettendruck-Berichte anpassen (ZPL, Zebra)
URL: https://www.fanatics.nl/de/help/odoo-zpl-etiketten-berichte-anpassen
Language: de

{/* TODO(de-review): first-pass DE translation, needs native-speaker review. */}

*Warnung: Erstellen Sie immer zuerst ein gutes Backup, bevor Sie einen der folgenden Schritte ausfuehren.*

Odoo bietet mehrere Standardoptionen zum Drucken von Zebra-Etiketten. In Studio koennen Sie daran nichts aendern, Sie koennen jedoch (eine Kopie des) Standardberichts anpassen. Dafuer brauchen Sie Grundkenntnisse des ZPL-Codes von Zebra-Etiketten - der ist gluecklicherweise nicht kompliziert.

![Druckerdialog in Odoo zum Drucken von Produktetiketten, mit der Option, ein Zebra-Etikett (ZPL) zu drucken](/kb/zpl-label-printing/img-1.png)

## Standardeinstellungen anpassen

Die Standardeinstellungen dieses Etiketts passen Sie ueber den Qweb-Tab des zugrunde liegenden Berichts an.

Aktivieren Sie zuerst den Developer-Modus. Geben Sie dann vom Startbildschirm aus `/reports` ein, um zu allen Berichten zu gelangen.

![Suche nach /reports vom Startbildschirm in Odoo](/kb/zpl-label-printing/img-2.png)

Waehlen Sie **Settings > Technical > Actions > Reports** und selektieren Sie den Bericht, den Sie bearbeiten moechten, in diesem Fall **Product Label (ZPL)**.

![Liste der Berichte in Odoo mit ausgewaehltem Product Label (ZPL)](/kb/zpl-label-printing/img-3.png)

Oben rechts finden Sie den Link zum Qweb-Teil dieses Berichts. Dieser Qweb-Code steuert das Layout des Etiketts.

![Link zur Qweb-View des ZPL-Berichts, oben rechts im Berichtsbildschirm](/kb/zpl-label-printing/img-4.png)

## Der ZPL-Etikettencode

Oeffnen Sie diese View, zeigt der Tab **Architecture** den Code, der zu Ihrer aktuellen Installation und den Modul-Optionen gehoert. Diesen Code koennen Sie hier bearbeiten.

**Hinweis:** Aenderungen am Standardlayout werden beim naechsten Update mit hoher Wahrscheinlichkeit ueberschrieben. Legen Sie daher eine inherited View an. Das liegt ausserhalb des Umfangs dieses Artikels, fuer Tests ist es aber praktisch, den Bericht auf diese Weise schnell anzupassen.

Gut zu wissen: Sie koennen eine Zeile mit einem Semikolon (`;`) auskommentieren. Alles nach einem Semikolon in einer Zeile gilt als Kommentar und wird vom ZPL-Interpreter ignoriert.

Erstellen Sie auch ein Backup des aktuellen Codes, damit Sie jederzeit zum Standard zurueckkehren koennen.

Der Code, den Sie sehen, kann zum Beispiel so aussehen:

![Tab Architecture mit dem Standard-ZPL-Code des Berichts Product Label (ZPL)](/kb/zpl-label-printing/img-5.png)

```xml
<t t-name="stock.label_product_product_view">
    <t t-foreach="quantity.items()" t-as="barcode_and_qty_by_product">
        <t t-set="product" t-value="barcode_and_qty_by_product[0]"/>
        <t t-foreach="barcode_and_qty_by_product[1]" t-as="barcode_and_qty">
            <t t-set="barcode" t-value="barcode_and_qty[0]"/>
            <t t-foreach="range(barcode_and_qty[1])" t-as="qty">
                <t t-translation="off">
^XA
^FT100,80^A0N,40,30^FD<t t-esc="product.display_name"/>^FS
<t t-if="product.default_code and len(product.default_code) > 15">
^FT100,115^A0N,30,24^FD<t t-esc="product.default_code[:15]"/>^FS
^FT100,150^A0N,30,24^FD<t t-esc="product.default_code[15:30]"/>^FS
</t>
<t t-else="">
^FT100,150^A0N,30,24^FD<t t-esc="product.default_code"/>^FS
</t>
<t t-if="price_included">
^FO600,100,1
^CI28
<t t-if="product.currency_id.position == 'after'">
^A0N,66,48^FH^FD<t t-esc="product.list_price" t-options="{&quot;widget&quot;: &quot;float&quot;, &quot;precision&quot;: 2}"/><t t-esc="product.currency_id.symbol"/>^FS
</t>
<t t-if="product.currency_id.position == 'before'">
^A0N,66,48^FH^FD<t t-esc="product.currency_id.symbol"/><t t-esc="product.list_price" t-options="{&quot;widget&quot;: &quot;float&quot;, &quot;precision&quot;: 2}"/>^FS
</t>
</t>
<t t-if="barcode">
^FO100,160^BY3
^BCN,100,Y,N,N
^FD<t t-esc="barcode"/>^FS
</t>
^XZ
                </t>
            </t>
        </t>
    </t>
</t>
```

### Erklaerung des Codes

Dieser Code druckt Etiketten fuer Produkte mit den zugehoerigen Barcodes und Mengen. Zeile fuer Zeile:

1. `<t t-name="stock.label_product_product_view">`: der Name des Templates fuer den Druck von Produktetiketten.
2. `<t t-foreach="quantity.items()" t-as="barcode_and_qty_by_product">`: durchlaeuft jedes Element in `quantity` und weist es `barcode_and_qty_by_product` zu, sodass Barcode und Menge je Produkt gedruckt werden.
3. `<t t-set="product" t-value="barcode_and_qty_by_product[0]"/>`: setzt `product` auf das erste Element, das das Produkt darstellt.
4. `<t t-foreach="barcode_and_qty_by_product[1]" t-as="barcode_and_qty">`: durchlaeuft die Liste `barcode_and_qty_by_product[1]`, sodass mehrere Barcodes und Mengen fuer dasselbe Produkt moeglich sind.
5. `<t t-set="barcode" t-value="barcode_and_qty[0]"/>`: setzt `barcode` auf das erste Element, das den Barcode darstellt.
6. `<t t-foreach="range(barcode_and_qty[1])" t-as="qty">`: durchlaeuft eine Zahlenfolge, deren Anzahl durch das zweite Element bestimmt wird, sodass derselbe Barcode und dieselbe Menge mehrfach gedruckt werden.
7. `<t t-translation="off">`: schaltet die Uebersetzung fuer den Etiketteninhalt aus, sodass die Texte unveraendert bleiben.
8. `^XA`: startet die ZPL-Befehle.
9. `^FT100,80^A0N,40,30^FD<t t-esc="product.display_name"/>^FS`: legt Position und Schrift der ersten Zeile fest und druckt den Anzeigenamen des Produkts.
10. `<t t-if="product.default_code and len(product.default_code) > 15">`: prueft, ob das Produkt eine interne Referenz mit mehr als 15 Zeichen hat.
11. `^FT100,115^A0N,30,24^FD<t t-esc="product.default_code[:15]"/>^FS`: druckt die ersten 15 Zeichen der internen Referenz.
12. `^FT100,150^A0N,30,24^FD<t t-esc="product.default_code[15:30]"/>^FS`: druckt die naechsten Zeichen der internen Referenz.
13. `<t t-else="">`: die Alternative, wenn die Bedingung nicht zutrifft.
14. `^FT100,150^A0N,30,24^FD<t t-esc="product.default_code"/>^FS`: druckt die vollstaendige interne Referenz.
15. `<t t-if="price_included">`: prueft, ob der Preis enthalten ist.
16. `^FO600,100,1`: legt die Position des Preises auf dem Etikett fest.
17. `^CI28`: stellt die Zeichenkodierung auf UTF-8.
18. `<t t-if="product.currency_id.position == 'after'">`: prueft, ob das Waehrungssymbol hinter dem Preis steht.
19. `^A0N,66,48^FH^FD...^FS`: druckt den Preis und das Waehrungssymbol.
20. `<t t-if="product.currency_id.position == 'before'">`: prueft, ob das Waehrungssymbol vor dem Preis steht.
21. `^A0N,66,48^FH^FD...^FS`: druckt das Waehrungssymbol und den Preis.
22. `<t t-if="barcode">`: prueft, ob ein Barcode vorhanden ist.
23. `^FO100,160^BY3`: legt die Position und die Barcode-Parameter fest.
24. `^BCN,100,Y,N,N`: legt Typ und Groesse des Barcodes fest.
25. `^FD<t t-esc="barcode"/>^FS`: druckt den Barcode.
26. `^XZ`: beendet die ZPL-Befehle.

Das Ergebnis ist ein Etikett mit Produktname, interner Referenz, Preis und Barcode fuer jedes Produkt.

## Tipp: Lassen Sie einen KI-Assistenten mitdenken

Ein KI-Assistent eignet sich gut, um einen einzelnen Teil anzupassen. Auf die Frage "Wie verkleinere ich im folgenden Code die Schriftgroesse und den Barcode um 50%?" erhalten Sie Folgendes.

Die Schriftgroesse wird mit `^A0N` festgelegt, gefolgt von den Groessenparametern; halbieren Sie diese Werte, um den Text kleiner zu machen. Die Barcode-Groesse wird mit `^BY3` festgelegt; senken Sie sie zum Beispiel auf `2,5`, `2` oder `1,5`, um den Barcode zu verkleinern.

Der angepasste Code, mit Schrift und Barcode jeweils 50% kleiner:

```xml
<t t-name="stock.label_product_product_view">
    <t t-foreach="quantity.items()" t-as="barcode_and_qty_by_product">
        <t t-set="product" t-value="barcode_and_qty_by_product[0]"/>
        <t t-foreach="barcode_and_qty_by_product[1]" t-as="barcode_and_qty">
            <t t-set="barcode" t-value="barcode_and_qty[0]"/>
            <t t-foreach="range(barcode_and_qty[1])" t-as="qty">
                <t t-translation="off">
^XA
^FT100,80^A0N,20,15^FD<t t-esc="product.display_name"/>^FS
<t t-if="product.default_code and len(product.default_code) > 15">
^FT100,115^A0N,15,12^FD<t t-esc="product.default_code[:15]"/>^FS
^FT100,150^A0N,15,12^FD<t t-esc="product.default_code[15:30]"/>^FS
</t>
<t t-else="">
^FT100,150^A0N,15,12^FD<t t-esc="product.default_code"/>^FS
</t>
<t t-if="price_included">
^FO600,100,1
^CI28
<t t-if="product.currency_id.position == 'after'">
^A0N,33,24^FH^FD<t t-esc="product.list_price" t-options="{&quot;widget&quot;: &quot;float&quot;, &quot;precision&quot;: 2}"/><t t-esc="product.currency_id.symbol"/>^FS
</t>
<t t-if="product.currency_id.position == 'before'">
^A0N,33,24^FH^FD<t t-esc="product.currency_id.symbol"/><t t-esc="product.list_price" t-options="{&quot;widget&quot;: &quot;float&quot;, &quot;precision&quot;: 2}"/>^FS
</t>
</t>
<t t-if="barcode">
^FO100,160^BY2
^BCN,50,Y,N,N
^FD<t t-esc="barcode"/>^FS
</t>
^XZ
                </t>
            </t>
        </t>
    </t>
</t>
```

Die Schriftparameter sind verringert (zum Beispiel 20, 15, 15, 12) und die Barcode-Parameter auf einen kleineren Barcode gesetzt (`^BY2`, `^BCN,50`).

## Brauchen Sie Unterstuetzung bei Ihren Odoo-Etiketten?

Kommen Sie beim Anpassen eines ZPL-Berichts nicht weiter? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact) - wir schauen gemeinsam mit Ihnen.


# Planning resources in Odoo: people and machines via the Project module
URL: https://www.fanatics.nl/help/plan-resources-projects-odoo
Language: en

In Odoo you schedule more than just people: machines and other equipment are resources too. Two questions come up again and again:

- How do you plan resources, both people and machines, through the Project module?
- How do you make sure only people who can operate a given machine can be scheduled on it?

## People and machines as resources

In the Planning module you create two kinds of resource:

- **Human resources** - your staff, usually linked to their user or employee record.
- **Material resources** - machines, vehicles or tools. They have no personal calendar, but they do have their own capacity and availability.

Treating both as resources lets you schedule a task or project against the person and the machine doing the work. Capacity and load show up in the same planning view.

## Restricting machines to qualified staff

To stop anyone from being scheduled on a machine, work with roles or skills:

1. Give each machine a **role** required to operate it (for example "saw operator").
2. Assign that role to the staff allowed to run the machine.
3. When scheduling, Odoo then only suggests staff with the matching role.

This keeps the plan realistic: a shift on the saw can only go to someone actually qualified to run it.

## Video: resource planning in Odoo

The video below walks through the setup step by step.

| Topic | Link |
|---|---|
| Resource planning in Odoo | [YouTube](https://www.youtube.com/watch?v=0-8fhuePsco&t=500s) |

## Need a hand with your setup?

Want resource planning done right for your production or projects? [Book an Odoo scan](/scan) or [get in touch](/contact) - we will take a look with you.


# "Powered by Odoo" verwijderen uit je database
URL: https://www.fanatics.nl/nl/help/powered-by-odoo-verwijderen
Language: nl

Standaard toont Odoo onderaan bepaalde pagina's een kleine "Powered by Odoo"-vermelding. Wil je die weghalen, dan pas je de bijbehorende view aan. Dat regel je in een paar stappen.

## Stappenplan

1. Log in als beheerder en zet de **ontwikkelaarsmodus** aan via **Settings** (Algemene instellingen, onderaan).
2. Ga naar **Settings > Technical > User Interface > Views**.
3. Open de view **Brand Promotion Message**.

![Het menu Settings > Technical > User Interface > Views in Odoo](/kb/remove-powered-by-odoo/img-1.svg)

![De view Brand Promotion Message in de lijst met views](/kb/remove-powered-by-odoo/img-2.svg)

4. Deactiveer deze view, of becommentarieer of verwijder de inhoud ervan.

![De inhoud van de view Brand Promotion Message bewerken of uitschakelen](/kb/remove-powered-by-odoo/img-3.svg)

Na het opslaan verdwijnt de "Powered by Odoo"-tekst uit je database.

## Let op

- Wijzigingen aan technische views horen thuis in een gecontroleerde omgeving. Test ze eerst op een testdatabase voordat je ze in productie doorvoert.
- Een view uitschakelen of leegmaken is omkeerbaar: zet de view weer actief of herstel de inhoud om de vermelding terug te brengen.

## Hulp nodig bij je Odoo-inrichting?

Liever niet zelf in de technische views? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact) - dan regelen we het samen.


# Productafbeeldingen importeren in Odoo
URL: https://www.fanatics.nl/nl/help/productafbeeldingen-importeren
Language: nl

Om afbeeldingen in Odoo te importeren, moeten ze bereikbaar zijn via een URL. Dat kan online of, als Odoo op de eigen machine draait, via een lokaal pad. Hieronder vind je drie werkwijzen.

## Online via postimg.cc

[postimg.cc](https://postimg.cc/) is de meest betrouwbare optie. Je uploadt alle afbeeldingen en kopieert per afbeelding de directe link. Deze methode is getest met aantallen tot 1000 afbeeldingen per import.

1. Maak een account aan.
2. Upload de bestanden in de volgorde van je importbestand.
3. Klik na het uploaden op **Direct link** (zie de afbeelding hieronder).
4. Kopieer en plak de waarden op de juiste regels in je importbestand.

![Het kopiëren van de Direct link van een afbeelding op postimg.cc](/kb/import-product-images/img-1.png)

## Online via Google Drive

Zet alle te importeren afbeeldingen in één map in Google Drive. Het nadeel: Google geeft na zo'n 40 a 50 afbeeldingen een timeout. Voor grote uploads is dit dus minder geschikt, omdat je de import in delen moet knippen.

Zoek na het uploaden een add-on die van de afbeeldingen een URL maakt, bijvoorbeeld 'Photo gallery by awesome table'. Vervang in de uiteindelijke URL het deel `file/d` door `uc?id=`. Daarna kun je de afbeeldingen importeren.

## Lokaal via een eigen server

Draai je Odoo lokaal, dan lees je de afbeeldingen rechtstreeks vanaf een lokaal pad in. Dit werkt alleen als je een back-up van Odoo kunt terugzetten, bijvoorbeeld in Odoo.sh. Op een eigen server is dit de aanbevolen methode.

## Hulp nodig bij je import?

Loop je vast bij het importeren van je productafbeeldingen? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact) - dan kijken we met je mee.


# Producten importeren in Odoo: importtemplate zonder varianten
URL: https://www.fanatics.nl/nl/help/producten-importeren-zonder-varianten
Language: nl

Voor een simpele productimport zonder varianten gebruik je de standaard importtemplate om het importbestand voor te bereiden. Het gaat om een import zonder varianten, zonder eCommerce en zonder overige extra's. Heb je iets specifiekers nodig, dan maken we een importtemplate op maat.

**Download:** [Importtemplate producten zonder varianten (XLSX)](/kb/import-products/import-template-producten-zonder-varianten.xlsx)

## Beschikbare templates

- **Product import template (zonder varianten)** - de basistemplate voor een simpele import.
- **Product (product.template) inclusief eCommerce** - dezelfde import, met de eCommerce-velden erbij.
- **Odoo product import template ENG (No Variants)** - dezelfde template met Engelse toelichting, inclusief eCommerce.

In de headers van de template staan notities met verdere uitleg. Moet je extra producteigenschappen toevoegen (zoals lengte, breedte, m2), dan kan dat eenvoudig door extra kolommen toe te voegen.

## Import in twee stappen

1. De import van de producten zelf via de voorraadmodule.
2. (Indien van toepassing) De import van de gerelateerde leveranciers, prijzen en leverancier-productcodes via de inkoopmodule (Vendor Pricelists).

## Magazijnlocaties

Een vraag die vaak terugkomt: hoe ga je om met magazijnlocaties? Die koppel je niet aan een product. Dat werkt via putawayrules, die bij de ontvangst de advieslocatie aangeven. Voor extra flexibiliteit kun je een product op meerdere magazijnlocaties wegleggen, bijvoorbeeld als de standaardlocatie vol is.

Magazijnlocaties geef je dus niet op bij de import. Je voert ze in bij het opboeken van de voorraadaantallen.

## Productvarianten en productafbeeldingen

Een import met productvarianten is wat complexer. Daarvoor is er een aparte handleiding: [Producten importeren met varianten](/help/producten-met-varianten-importeren).

Voor het importeren van productafbeeldingen volg je de handleiding [Productafbeeldingen importeren](/help/productafbeeldingen-importeren).

## Hulp nodig bij je import?

Loop je vast bij de voorbereiding van je importbestand of wil je een template op maat? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact) - dan kijken we met je mee.


# "Powered by Odoo" aus Ihrer Datenbank entfernen
URL: https://www.fanatics.nl/de/help/powered-by-odoo-entfernen
Language: de

{/* TODO(de-review): first-pass DE translation. */}

Standardmäßig zeigt Odoo am unteren Rand bestimmter Seiten einen kleinen Hinweis "Powered by Odoo". Wenn Sie diesen entfernen möchten, passen Sie die zugehörige View an. Das erledigen Sie in wenigen Schritten.

## Schritt für Schritt

1. Melden Sie sich als Administrator an und aktivieren Sie den **Entwicklermodus** über **Settings** (Allgemeine Einstellungen, ganz unten).
2. Gehen Sie zu **Settings > Technical > User Interface > Views**.
3. Öffnen Sie die View **Brand Promotion Message**.

![Das Menü Settings > Technical > User Interface > Views in Odoo](/kb/remove-powered-by-odoo/img-1.svg)

![Die View Brand Promotion Message in der Liste der Views](/kb/remove-powered-by-odoo/img-2.svg)

4. Deaktivieren Sie diese View oder kommentieren Sie deren Inhalt aus bzw. entfernen Sie ihn.

![Den Inhalt der View Brand Promotion Message bearbeiten oder deaktivieren](/kb/remove-powered-by-odoo/img-3.svg)

Nach dem Speichern verschwindet der Text "Powered by Odoo" aus Ihrer Datenbank.

## Gut zu wissen

- Änderungen an technischen Views gehören in eine kontrollierte Umgebung. Testen Sie sie zuerst auf einer Staging-Datenbank, bevor Sie sie in der Produktion übernehmen.
- Eine View zu deaktivieren oder zu leeren ist umkehrbar: Aktivieren Sie die View wieder oder stellen Sie deren Inhalt wieder her, um den Hinweis zurückzuholen.

## Brauchen Sie Unterstützung bei Ihrer Odoo-Einrichtung?

Lieber nicht selbst in die technischen Views eingreifen? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact) - dann erledigen wir das gemeinsam.


# Producten met varianten importeren in Odoo
URL: https://www.fanatics.nl/nl/help/producten-met-varianten-importeren
Language: nl

Volg de handleiding hieronder om producten met varianten in Odoo te importeren. De video is opgenomen op een oudere Odoo-versie, maar de werkwijze klopt nog steeds (stand Q2 2023).

**Download:** [Importtemplate producten met varianten (XLSX)](/kb/import-product-variants/import-template-producten-met-varianten.xlsx)

## Videohandleiding

De volledige import van producten, varianten en waarden wordt stap voor stap in een video getoond: *Products and Product Variants - IMPORT TUTORIAL*. Vraag deze op bij je consultant als je de video nodig hebt.

## Excel-template

Gebruik het Excel-template *TEMPLATE - PRODUCT & PRODUCT VARIANTS* als basis. Daarin vul je de velden in die je nodig hebt voor producten, varianten en bijbehorende waarden. Het template volgt dezelfde kolomopzet als de video, zodat je het importbestand snel klaar hebt.

## Import zonder varianten

Heb je geen attributen of varianten nodig? Dan volstaat een eenvoudigere import. Daarvoor bestaat een apart artikel met een productimport-template zonder varianten.

## Hulp nodig bij je import?

Loop je vast bij het importeren van producten of varianten? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact) - dan kijken we met je mee.


# Produktbilder in Odoo importieren
URL: https://www.fanatics.nl/de/help/produktbilder-importieren
Language: de

{/* TODO(de-review): first-pass DE translation, needs native-speaker review. */}

Um Bilder in Odoo zu importieren, müssen sie über eine URL erreichbar sein. Das geht online oder, wenn Odoo auf der eigenen Maschine läuft, über einen lokalen Pfad. Nachfolgend finden Sie drei Wege.

## Online über postimg.cc

[postimg.cc](https://postimg.cc/) ist die zuverlässigste Option. Sie laden alle Bilder hoch und kopieren pro Bild den direkten Link. Wir haben diese Methode mit bis zu 1000 Bildern pro Import getestet.

1. Legen Sie ein Konto an.
2. Laden Sie die Dateien in der Reihenfolge Ihrer Importdatei hoch.
3. Klicken Sie nach dem Hochladen auf **Direct link** (siehe Abbildung unten).
4. Kopieren Sie die Werte und fügen Sie sie in die richtigen Zeilen Ihrer Importdatei ein.

![Kopieren des Direct link eines Bildes auf postimg.cc](/kb/import-product-images/img-1.png)

## Online über Google Drive

Legen Sie alle zu importierenden Bilder in einen Ordner in Google Drive. Der Nachteil: Google läuft nach etwa 40 bis 50 Bildern in einen Timeout und eignet sich daher weniger für große Uploads, bei denen Sie den Import in Teile aufteilen müssen.

Suchen Sie nach dem Hochladen ein Add-on, das aus den Bildern eine URL erzeugt, zum Beispiel 'Photo gallery by awesome table'. Ersetzen Sie in der endgültigen URL den Teil `file/d` durch `uc?id=`. Danach können Sie die Bilder importieren.

## Lokal auf einem eigenen Server

Wenn Sie Odoo lokal betreiben, lesen Sie die Bilder direkt über einen lokalen Pfad ein. Das funktioniert nur, wenn Sie ein Odoo-Backup wiederherstellen können, zum Beispiel in Odoo.sh. Auf einem eigenen Server ist dies die empfohlene Methode.

## Brauchen Sie Unterstützung beim Import?

Kommen Sie beim Import Ihrer Produktbilder nicht weiter? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact) - wir schauen gemeinsam mit Ihnen.


# Produkte in Odoo importieren: Importvorlage ohne Varianten
URL: https://www.fanatics.nl/de/help/produkte-importieren-ohne-varianten
Language: de

{/* TODO(de-review): first-pass DE translation. */}

Verwenden Sie für einen einfachen Produktimport ohne Varianten die Standard-Importvorlage, um Ihre Importdatei vorzubereiten. Es handelt sich um einen Import ohne Varianten, ohne eCommerce und ohne weitere Extras. Wenn Sie etwas Spezifischeres benötigen, erstellen wir eine maßgeschneiderte Importvorlage.

**Download:** [Importvorlage Produkte ohne Varianten (XLSX)](/kb/import-products/import-template-products-no-variants-en.xlsx)

## Verfügbare Vorlagen

- **Product import template (ohne Varianten)** - die Basisvorlage für einen einfachen Import.
- **Product (product.template) inklusive eCommerce** - derselbe Import, mit den eCommerce-Feldern.
- **Odoo product import template ENG (No Variants)** - dieselbe Vorlage mit englischen Hinweisen, inklusive eCommerce.

In den Kopfzeilen der Vorlage finden Sie Notizen mit weiteren Erläuterungen. Müssen Sie zusätzliche Produkteigenschaften hinzufügen (wie Länge, Breite, m2), geht das einfach, indem Sie weitere Spalten ergänzen.

## Import in zwei Schritten

1. Der Import der Produkte selbst über das Lager-Modul.
2. (Sofern zutreffend) Der Import der zugehörigen Lieferanten, Preise und Lieferanten-Produktcodes über das Einkaufs-Modul (Vendor Pricelists).

## Lagerorte

Eine Frage, die regelmäßig aufkommt: Wie gehen Sie mit Lagerorten um? Diese verknüpfen Sie nicht mit einem Produkt. Das funktioniert über Putaway-Regeln, die beim Wareneingang den empfohlenen Lagerort angeben. Für mehr Flexibilität können Sie ein Produkt auf mehreren Lagerorten ablegen, zum Beispiel wenn der Standardlagerort voll ist.

Lagerorte geben Sie also beim Import nicht an. Sie erfassen sie beim Buchen der Bestandsmengen.

## Produktvarianten und Produktbilder

Ein Import mit Produktvarianten ist etwas aufwendiger. Dafür gibt es eine eigene Anleitung: [Produkte mit Varianten importieren](/de/help/produkte-mit-varianten-importieren).

Für den Import von Produktbildern folgen Sie der Anleitung [Produktbilder importieren](/de/help/produktbilder-importieren).

## Brauchen Sie Unterstützung beim Import?

Kommen Sie bei der Vorbereitung Ihrer Importdatei nicht weiter oder wünschen Sie eine maßgeschneiderte Vorlage? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact) - wir schauen gemeinsam mit Ihnen.


# Produkte mit Varianten in Odoo importieren
URL: https://www.fanatics.nl/de/help/produkte-mit-varianten-importieren
Language: de

{/* TODO(de-review): first-pass DE translation. */}

Folgen Sie der Anleitung unten, um Produkte mit Varianten in Odoo zu importieren. Das Video wurde mit einer älteren Odoo-Version aufgenommen, das Vorgehen gilt jedoch weiterhin (Stand Q2 2023).

**Download:** [Importvorlage Produkte mit Varianten (XLSX)](/kb/import-product-variants/import-template-producten-met-varianten.xlsx)

## Videoanleitung

Der vollständige Import von Produkten, Varianten und Werten wird Schritt für Schritt in einem Video gezeigt: *Products and Product Variants - IMPORT TUTORIAL*. Fragen Sie bei Bedarf Ihren Berater nach dem Video.

## Excel-Vorlage

Verwenden Sie die Excel-Vorlage *TEMPLATE - PRODUCT & PRODUCT VARIANTS* als Ausgangspunkt. Darin füllen Sie die Felder aus, die Sie für Produkte, Varianten und deren Werte benötigen. Die Vorlage folgt demselben Spaltenaufbau wie das Video, sodass Sie Ihre Importdatei schnell fertigstellen.

## Import ohne Varianten

Sie benötigen keine Attribute oder Varianten? Dann genügt ein einfacherer Import. Dafür gibt es einen separaten Artikel mit einer Produktimport-Vorlage ohne Varianten.

## Brauchen Sie Unterstützung beim Import?

Kommen Sie beim Import von Produkten oder Varianten nicht weiter? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact) - wir schauen gemeinsam mit Ihnen.


# Remove "Powered by Odoo" from your database
URL: https://www.fanatics.nl/help/remove-powered-by-odoo
Language: en

By default Odoo shows a small "Powered by Odoo" credit at the bottom of certain pages. To remove it, you edit the view that renders it. It takes a few steps.

## Steps

1. Log in as administrator and turn on **developer mode** from **Settings** (at the bottom of the General Settings page).
2. Go to **Settings > Technical > User Interface > Views**.
3. Open the **Brand Promotion Message** view.

![The Settings > Technical > User Interface > Views menu in Odoo](/kb/remove-powered-by-odoo/img-1.svg)

![The Brand Promotion Message view in the views list](/kb/remove-powered-by-odoo/img-2.svg)

4. Deactivate this view, or comment out or remove its content.

![Editing or disabling the content of the Brand Promotion Message view](/kb/remove-powered-by-odoo/img-3.svg)

Once you save, the "Powered by Odoo" text disappears from your database.

## Good to know

- Changes to technical views belong in a controlled environment. Test them on a staging database before applying them in production.
- Disabling or emptying a view is reversible: reactivate the view or restore its content to bring the credit back.

## Need a hand with your Odoo setup?

Rather not dig into the technical views yourself? [Book an Odoo scan](/scan) or [get in touch](/contact) - and we will sort it out together.


# Resources plannen in Odoo: mensen en machines via de projectenmodule
URL: https://www.fanatics.nl/nl/help/resources-plannen-projecten-odoo
Language: nl

In Odoo plan je niet alleen mensen in, maar ook machines en ander materieel. Twee vragen komen daarbij vaak terug:

- Hoe plan je via de projectenmodule resources, zowel mensen als machines?
- Hoe zorg je dat alleen mensen die een bepaalde machine kunnen bedienen daarvoor ingepland kunnen worden?

## Mensen en machines als resource

In de module Planning maak je twee soorten resources aan:

- **Menselijke resources** - je medewerkers, doorgaans gekoppeld aan hun gebruiker of werknemerskaart.
- **Materiële resources** - machines, voertuigen of gereedschap. Deze hebben geen agenda van een persoon, maar wel een eigen capaciteit en beschikbaarheid.

Door beide als resource te behandelen, plan je een taak of project in tegen zowel de persoon als de machine die het werk uitvoert. Je ziet capaciteit en bezetting in dezelfde planningsweergave.

## Alleen bevoegde medewerkers op een machine

Wil je voorkomen dat zomaar iedereen op een machine wordt ingepland, dan werk je met rollen of vaardigheden:

1. Geef elke machine een **rol** die nodig is om hem te bedienen (bijvoorbeeld "operator zaagmachine").
2. Ken die rol toe aan de medewerkers die de machine mogen bedienen.
3. Bij het inplannen stelt Odoo dan alleen medewerkers met de juiste rol voor.

Zo blijft de planning realistisch: een shift op de zaagmachine kun je alleen toewijzen aan iemand die daadwerkelijk bevoegd is.

## Video: resource planning in Odoo

In de onderstaande video wordt stap voor stap uitgelegd hoe je dit inricht.

| Onderwerp | Link |
|---|---|
| Resource planning in Odoo | [YouTube](https://www.youtube.com/watch?v=0-8fhuePsco&t=500s) |

## Hulp nodig bij je inrichting?

Wil je resourceplanning goed neerzetten voor jouw productie of projecten? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact) - dan kijken we met je mee.


# Ressourcen planen in Odoo: Mitarbeiter und Maschinen über das Projektmodul
URL: https://www.fanatics.nl/de/help/ressourcen-planen-projekte-odoo
Language: de

{/* TODO(de-review): first-pass DE translation. */}

In Odoo planen Sie nicht nur Mitarbeiter ein, sondern auch Maschinen und andere Betriebsmittel. Zwei Fragen tauchen dabei immer wieder auf:

- Wie planen Sie Ressourcen, sowohl Mitarbeiter als auch Maschinen, über das Projektmodul?
- Wie stellen Sie sicher, dass nur Personen, die eine bestimmte Maschine bedienen können, dafür eingeplant werden?

## Mitarbeiter und Maschinen als Ressource

Im Modul Planung legen Sie zwei Arten von Ressourcen an:

- **Personelle Ressourcen** - Ihre Mitarbeiter, in der Regel mit ihrem Benutzer- oder Mitarbeiterdatensatz verknüpft.
- **Materielle Ressourcen** - Maschinen, Fahrzeuge oder Werkzeuge. Sie haben keinen persönlichen Kalender, aber eine eigene Kapazität und Verfügbarkeit.

Wenn Sie beides als Ressource behandeln, planen Sie eine Aufgabe oder ein Projekt gegen die Person und die Maschine, die die Arbeit ausführt. Kapazität und Auslastung erscheinen in derselben Planungsansicht.

## Maschinen nur für qualifiziertes Personal

Damit nicht jeder beliebig an einer Maschine eingeplant wird, arbeiten Sie mit Rollen oder Fähigkeiten:

1. Geben Sie jeder Maschine eine **Rolle**, die zur Bedienung erforderlich ist (zum Beispiel "Bediener Sägemaschine").
2. Weisen Sie diese Rolle den Mitarbeitern zu, die die Maschine bedienen dürfen.
3. Beim Einplanen schlägt Odoo dann nur Mitarbeiter mit der passenden Rolle vor.

So bleibt die Planung realistisch: Eine Schicht an der Säge können Sie nur jemandem zuweisen, der tatsächlich dafür qualifiziert ist.

## Video: Resource Planning in Odoo

Das folgende Video erklärt die Einrichtung Schritt für Schritt.

| Thema | Link |
|---|---|
| Resource planning in Odoo | [YouTube](https://www.youtube.com/watch?v=0-8fhuePsco&t=500s) |

## Brauchen Sie Unterstützung bei der Einrichtung?

Möchten Sie die Ressourcenplanung für Ihre Produktion oder Projekte sauber aufsetzen? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact) - wir schauen gemeinsam mit Ihnen.


# Sales orders importeren in Odoo
URL: https://www.fanatics.nl/nl/help/sales-orders-importeren
Language: nl

Verkooporders met hun orderregels kun je in Odoo in een keer importeren via een Excel-bestand. Dat scheelt veel handmatig invoeren wanneer je bijvoorbeeld een batch openstaande orders overneemt vanuit een ander systeem.

**Download:** [Importtemplate sales orders (XLSX)](/kb/import-sales-orders/import-template-sales-orders.xlsx)

## Importeren via de Sales-module

Ga naar de **Verkoop**-module en open de lijstweergave van de orders. Klik op **Favorieten -> Import records** en upload je Excel-bestand.

Het sterke punt: je kunt per order meerdere orderregels tegelijk toevoegen. Zet daarvoor in je bestand alle regels van dezelfde order onder hetzelfde ordernummer. Odoo koppelt de regels dan automatisch aan de juiste order.

## Het importbestand opbouwen

Bouw het bestand op met een rij per orderregel. De ordergegevens (klant, datum) staan op de eerste regel van elke order; de vervolgregels herhalen alleen het ordernummer en hun eigen product en aantal.

| Order Reference | Customer | Order Lines / Product | Order Lines / Quantity | Order Lines / Unit Price |
|---|---|---|---|---|
| SO0001 | Deco Addict | Bureau | 2 | 145,00 |
| SO0001 |  | Bureaustoel | 4 | 89,00 |
| SO0002 | Azure Interior | Conferentietafel | 1 | 950,00 |

In dit voorbeeld krijgt order **SO0001** twee orderregels en **SO0002** een enkele regel.

**Let op:** zorg dat de productnamen exact overeenkomen met de producten in Odoo, anders kan de import de regel niet koppelen. Werk je liever met interne referenties, gebruik dan de externe ID of de interne referentie in plaats van de productnaam.

## Hulp nodig?

Loop je vast bij het importeren van je orders? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact) - dan kijken we met je mee.


# Stücklisten (BoM) in Odoo importieren
URL: https://www.fanatics.nl/de/help/stuecklisten-importieren
Language: de

{/* TODO(de-review): first-pass DE translation. */}

Eine Stückliste (BoM) zu importieren ist praktisch, wenn Sie viele unterschiedliche
Konfigurationen haben und das Manufacturing-Modul nutzen, zum Beispiel aus einem
Export eines CAD-Programms. Es ist kein flacher Import: Eine Stückliste besteht aus
einer Kopfzeile mit mehreren Komponentenzeilen darunter. Das macht sie etwas
kniffliger als den Import von Produkten oder Kontakten.

**Download:** [Importvorlage Stücklisten (XLSX)](/kb/import-bom/import-template-stuklijsten.xlsx)

## Video: Import BoM

Kevin Zaki hat eine verständliche Anleitung zum gesamten Ablauf aufgenommen.

| Niveau | Thema | Link |
|---|---|---|
| Expert | Import BoM | [YouTube](https://www.youtube.com/watch?v=oJG5pNg9F-M) (21:30) |

## Die Importdatei

Importieren Sie Stücklisten in der Manufacturing-App unter **Produkte > Stücklisten**.
Bauen Sie die Importdatei mit einer Kopfzeile je Stückliste und darunter einer Zeile
je Komponente auf. Die wichtigsten Spalten:

| Spalte | Inhalt |
|---|---|
| External ID | Externe ID der Stückliste (z. B. `bom_001`) |
| Product / External ID | Externe ID des Fertigprodukts |
| Product Variant / External ID | Externe ID der Variante (optional) |
| Quantity | Menge, die die Stückliste ergibt |
| Unit of Measure | Maßeinheit (z. B. Units) |
| BoM Type | Zum Beispiel "Manufacture this product" |
| BoM Line / External ID | Externe ID je Komponentenzeile |
| BoM Line / Component / External ID | Externe ID der Komponente |
| BoM Line / Quantity | Menge je Komponente |

Die Kopfzeile füllen Sie einmal aus; die zugehörigen Komponentenzeilen folgen
darunter, wobei nur die BoM-Line-Spalten befüllt werden.

## Mit externen IDs arbeiten

Sind die Produkte bereits in Odoo vorhanden, müssen Sie mit den **externen IDs**
sowohl der Produkte als auch der Komponenten arbeiten. So verknüpft Odoo jede Zeile
mit dem richtigen Produkt, statt ein neues anzulegen. Die Datei sieht dann so aus:

![Excel-Importdatei für Stücklisten mit externen IDs für Produkte und Komponenten](/kb/import-bom/img-1.png)

## Brauchen Sie Unterstützung beim Import?

Kommen Sie beim Import von Stücklisten nicht weiter? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact) - wir schauen gemeinsam mit Ihnen.


# Unit of Measure, Packaging and Packages in Odoo explained
URL: https://www.fanatics.nl/help/unit-of-measure-packaging-packages-odoo
Language: en

What is the difference between Unit of Measure, Packaging and Packages in Odoo? The three terms look alike, but each plays its own role in sales, stock and delivery.

## The three terms in short

1. **Unit of Measure (UoM)**: the unit a product is sold, stored or purchased in. Think pieces, kilos or litres.
2. **Packaging**: a pack holding several identical products. You use it to sell multiple units of the same product at once, for example a box of twelve.
3. **Packages**: a box in which one or more products of the same or different type are shipped. You use this only when delivering goods.

## Video walkthrough

In the video below we work through the three terms in Odoo:

- UoM is covered from the start of the video.
- Packaging follows from minute 10.
- Packages appear from minute 17:15.

[Watch the explanation on YouTube](https://youtu.be/I3YtiWgK84U)

The video was recorded in Odoo version 14, but the approach still applies to later versions.

Tip: also read the article on calculating shipping costs in Odoo, where Packages comes up again.

## Need a hand with your setup?

Unsure how to set up UoM, Packaging and Packages for your products? [Book an Odoo scan](/scan) or [get in touch](/contact) - we will take a look with you.


# Importbestand vaste activa in Odoo (voorbeeld met toelichting)
URL: https://www.fanatics.nl/nl/help/vaste-activa-importeren
Language: nl

Wil je je vaste activa in Odoo zetten, bijvoorbeeld bij de beginbalans of als je later de activamodule in gebruik neemt? Gebruik dan ons Excel-template. Daarmee importeer je alle activa in een keer in plaats van ze stuk voor stuk in te voeren.

**Download:** [Importtemplate vaste activa (XLSX)](/kb/import-fixed-assets/importbestand-vaste-activa.xlsx)

## Het template downloaden

We leveren een ingevuld voorbeeldbestand met toelichting. Op de eerste regel van het eerste tabblad staan waar nodig gele notities die uitleggen wat in elke kolom hoort.

- **Importbestand vaste activa.xlsx** - het standaardtemplate voor recente Odoo-versies.
- **Importbestand vaste activa (Odoo 16 en eerder).xlsx** - voor oudere versies.

Vraag het template bij ons op als je het nog niet hebt; we sturen het je toe.

## Belangrijke aandachtspunten

- **Verwijder de gele toelichtingsregel.** De eerste regel op het eerste tabblad bevat alleen uitleg. Haal die weg voordat je importeert, anders leest Odoo de notities als data.
- **De startdatum laat je weg.** Vul je de afschrijvingsgegevens correct in, dan leidt Odoo bij het genereren van de afschrijvingen zelf de juiste startdatum af. Die kolom hoef je dus niet te importeren.
- **Controleer de aansluiting op de beginbalans.** Sluit de rekeningen van je vaste activa en de cumulatieve afschrijvingen aan op de bedragen in je beginbalans.

Dit artikel hoort bij het stappenplan voor het in gebruik nemen van Odoo Accounting, waarin de import van activa stap 6 is.

## Hulp nodig bij je activa-import?

Loop je vast op de import of de aansluiting op de beginbalans? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact) - dan kijken we met je mee.


# Verkaufsauftraege in Odoo importieren
URL: https://www.fanatics.nl/de/help/verkaufsauftraege-importieren
Language: de

{/* TODO(de-review): first-pass DE translation. */}

Sie koennen Verkaufsauftraege samt ihren Auftragspositionen in einem Schritt ueber eine Excel-Datei importieren. Das erspart viel manuelle Erfassung, wenn Sie zum Beispiel einen Stapel offener Auftraege aus einem anderen System uebernehmen.

**Download:** [Importvorlage Verkaufsaufträge (XLSX)](/kb/import-sales-orders/import-template-sales-orders.xlsx)

## Import ueber das Verkaufsmodul

Oeffnen Sie das Modul **Verkauf** und wechseln Sie in die Listenansicht der Auftraege. Klicken Sie auf **Favoriten -> Datensaetze importieren** und laden Sie Ihre Excel-Datei hoch.

Der entscheidende Vorteil: Sie koennen demselben Auftrag mehrere Positionen auf einmal hinzufuegen. Setzen Sie dazu alle Positionen eines Auftrags unter dieselbe Auftragsreferenz. Odoo ordnet dann jede Position automatisch dem richtigen Auftrag zu.

## Die Importdatei aufbauen

Verwenden Sie eine Zeile pro Auftragsposition. Die Auftragsdaten (Kunde, Datum) stehen in der ersten Zeile jedes Auftrags; die Folgezeilen wiederholen nur die Auftragsreferenz sowie ihr eigenes Produkt und ihre Menge.

| Order Reference | Customer | Order Lines / Product | Order Lines / Quantity | Order Lines / Unit Price |
|---|---|---|---|---|
| SO0001 | Deco Addict | Schreibtisch | 2 | 145,00 |
| SO0001 |  | Buerostuhl | 4 | 89,00 |
| SO0002 | Azure Interior | Konferenztisch | 1 | 950,00 |

In diesem Beispiel erhaelt Auftrag **SO0001** zwei Positionen und **SO0002** eine einzelne Position.

**Hinweis:** Achten Sie darauf, dass die Produktnamen exakt mit den Produkten in Odoo uebereinstimmen, sonst kann der Import die Position nicht zuordnen. Wenn Sie lieber mit internen Referenzen arbeiten, verwenden Sie die externe ID oder die interne Referenz statt des Produktnamens.

## Brauchen Sie Unterstuetzung?

Kommen Sie beim Import Ihrer Auftraege nicht weiter? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact) - wir schauen gemeinsam mit Ihnen.


# Versandkosten in Odoo berechnen
URL: https://www.fanatics.nl/de/help/versandkosten-berechnen-odoo
Language: de

{/* TODO(de-review): first-pass DE translation, needs native-speaker review. */}

In Odoo berechnen Sie Versandkosten mit *Versandregeln*. Diese können Sie auf zwei Arten aufbauen:

- **Pauschalbetrag** - eine feste Gebühr pro Sendung, optional kostenlos für Bestellungen ab einem bestimmten Wert.
- **Auf Basis einer Formel** - bei der sich die Kosten an der Sendung selbst orientieren.

## Worauf können Sie die Formel stützen?

Eine Formelregel ermittelt die Versandkosten anhand einer Bedingung. Odoo bietet fünf Optionen:

| Bedingung | Berechnung auf Basis von |
|---|---|
| Weight | Gewicht |
| Volume | Volumen |
| Weight * Volume | Volumengewicht |
| Price | Preis |
| Quantity | Menge |

Pro Regel legen Sie die Bedingung und die zugehörigen Versandkosten fest:

![Das Fenster Create Pricing Rules in Odoo mit geöffnetem Condition-Dropdown: Weight, Volume, Weight * Volume, Price und Quantity](/kb/shipping-costs/img-1.png)

## Die Option aktivieren

Um mit diesen Pricing Rules zu arbeiten, aktivieren Sie die Option zuerst unter **Settings > Shipping Methods**. Anschließend können Sie die Regeln je Versandart konfigurieren.

## Mehr erfahren

In diesem kurzen Video wird erklärt, wie die Versandarten in der Praxis funktionieren: [Delivery costs in Odoo](https://youtu.be/0KG9QCyVe0s).

## Brauchen Sie Unterstützung bei der Einrichtung?

Möchten Sie Ihre Versandarten gleich richtig einrichten? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact) - wir schauen gemeinsam mit Ihnen.


# Verzendkosten berekenen in Odoo
URL: https://www.fanatics.nl/nl/help/verzendkosten-berekenen-odoo
Language: nl

In Odoo bereken je verzendkosten met *shipping rules*. Die kun je op twee manieren opbouwen:

- **Vast bedrag** - een vaste fee per zending, eventueel gratis voor bestellingen boven een bepaalde waarde.
- **Op basis van een formule** - waarbij de kosten meebewegen met de zending zelf.

## Waarop kun je de formule baseren?

Een formule-regel rekent de verzendkosten uit op basis van een conditie. Odoo kent vijf opties:

| Conditie | Berekening op basis van |
|---|---|
| Weight | Gewicht |
| Volume | Volume |
| Weight * Volume | Volumegewicht |
| Price | Prijs |
| Quantity | Aantal |

Per regel stel je de conditie en de bijbehorende verzendkosten in:

![Het venster Create Pricing Rules in Odoo met het Condition-dropdownmenu open: Weight, Volume, Weight * Volume, Price en Quantity](/kb/shipping-costs/img-1.png)

## De optie aanzetten

Wil je met deze pricing rules werken, zet de optie dan eerst aan via **Settings > Shipping Methods**. Daarna kun je per verzendmethode de regels configureren.

## Verder kijken

In deze korte video wordt uitgelegd hoe de verzendmethodes in de praktijk werken: [Delivery costs in Odoo](https://youtu.be/0KG9QCyVe0s).

## Hulp nodig bij je inrichting?

Wil je je verzendmethodes in een keer goed inrichten? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact) - dan kijken we met je mee.


# Aanspreken met de voornaam in Odoo e-mailtemplates (QWeb)
URL: https://www.fanatics.nl/nl/help/voornaam-aanhef-email-templates
Language: nl

Odoo bewaart de voor- en achternaam van een contactpersoon standaard in één veld. Soms wil je iemand in een mailtemplate juist alleen bij de voornaam aanspreken. Met een korte expressie in je QWeb-rapporten regel je dat.

## De expressie

Splits het naam-veld op spaties en pak het eerste deel:

```
Variabele: ${object.partner_id.name.split()[0]}
QWeb-mailtemplate: <t t-out="object.partner_id.name.split()[0]"></t>
```

`split()` knipt de volledige naam op in losse woorden; `[0]` pakt het eerste woord, dus de voornaam.

## Voorbeeld: aanhef in een offerte-mail

Onderstaand QWeb-blok zet "Beste [voornaam]," boven de tekst van een verkoopordermail:

```html
<div style="margin: 0px; padding: 0px;">
    <p style="box-sizing:border-box;margin: 0px; padding: 0px; font-size: 13px;">
        <t t-set="doc_name" t-value="'offerte' if object.state in ('draft', 'sent') else 'order'"></t>
        Beste <t t-out="object.partner_id.name.split()[0]"></t>,
        <br><br>
        Hierbij stuur ik je, zoals afgesproken, de link naar onze offerte toe.
        <br>Deze kun je eenvoudig online inzien via de link in deze mail. In de PDF-versie van de offerte die je daar kunt downloaden zijn de uitgangspunten, de projectscope en de randvoorwaarden verder uitgewerkt.
        <br><br>Is alles akkoord, dan bevestig je de offerte online.
        <br><br>
        Laat het me gerust weten als je nog vragen hebt.
        <t t-if="not is_html_empty(object.user_id.signature)" data-oe-t-group-active="true">
            <br><br>
            <t t-out="object.user_id.signature or ''" data-oe-t-inline="true">--<br>Team Radical Fanatics</t>
        </t>
        <br><br>
    </p>
</div>
```

## Let op

- Werkt de voornaam uit meerdere woorden bestaat (bijvoorbeeld "Jan Willem"), dan krijg je alleen het eerste woord. Voor de meeste aanhefregels is dat prima.
- Heeft een contact geen naam, dan kan de expressie een fout geven. Vang dat in kritieke templates af met een fallback.

Ref: [Odoo-forum: dynamic placeholder for only first name](https://www.odoo.com/nl_NL/forum/help-1/dynamic-placeholder-for-only-first-name-in-odoo-mass-mailing-111395)

## Hulp nodig bij je Odoo-inrichting?

Loop je vast op mailtemplates of andere maatwerk-instellingen? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact)


# Kontakte in Odoo E-Mail-Vorlagen mit dem Vornamen ansprechen (QWeb)
URL: https://www.fanatics.nl/de/help/vornamen-anrede-e-mail-vorlagen
Language: de

{/* TODO(de-review): first-pass DE translation. */}

Odoo speichert Vor- und Nachnamen eines Kontakts standardmäßig in einem einzigen Feld. Manchmal möchten Sie jemanden in einer E-Mail-Vorlage nur mit dem Vornamen ansprechen. Ein kurzer Ausdruck in Ihren QWeb-Berichten erledigt das.

## Der Ausdruck

Teilen Sie das Namensfeld an Leerzeichen und nehmen Sie den ersten Teil:

```
Variable: ${object.partner_id.name.split()[0]}
QWeb-E-Mail-Vorlage: <t t-out="object.partner_id.name.split()[0]"></t>
```

`split()` zerlegt den vollständigen Namen in einzelne Wörter; `[0]` nimmt das erste Wort, also den Vornamen.

## Beispiel: Anrede in einer Angebots-E-Mail

Der folgende QWeb-Block setzt "Hallo [Vorname]," über den Text einer Verkaufsauftrags-E-Mail:

```html
<div style="margin: 0px; padding: 0px;">
    <p style="box-sizing:border-box;margin: 0px; padding: 0px; font-size: 13px;">
        <t t-set="doc_name" t-value="'Angebot' if object.state in ('draft', 'sent') else 'Auftrag'"></t>
        Hallo <t t-out="object.partner_id.name.split()[0]"></t>,
        <br><br>
        wie besprochen sende ich Ihnen hier den Link zu unserem Angebot.
        <br>Sie können es über den Link in dieser E-Mail online einsehen. In der dort herunterladbaren PDF-Version sind die Annahmen, der Projektumfang und die Rahmenbedingungen näher ausgeführt.
        <br><br>Wenn alles passt, können Sie das Angebot online bestätigen.
        <br><br>
        Melden Sie sich gern, falls Sie noch Fragen haben.
        <t t-if="not is_html_empty(object.user_id.signature)" data-oe-t-group-active="true">
            <br><br>
            <t t-out="object.user_id.signature or ''" data-oe-t-inline="true">--<br>Team Radical Fanatics</t>
        </t>
        <br><br>
    </p>
</div>
```

## Hinweis

- Besteht ein Vorname aus mehreren Wörtern (zum Beispiel "Jan Willem"), erhalten Sie nur das erste Wort. Für die meisten Anreden ist das ausreichend.
- Hat ein Kontakt keinen Namen, kann der Ausdruck einen Fehler auslösen. Sichern Sie das in kritischen Vorlagen mit einem Fallback ab.

Ref: [Odoo-Forum: dynamic placeholder for only first name](https://www.odoo.com/nl_NL/forum/help-1/dynamic-placeholder-for-only-first-name-in-odoo-mass-mailing-111395)

## Brauchen Sie Unterstützung bei Ihrer Odoo-Einrichtung?

Kommen Sie bei E-Mail-Vorlagen oder anderen Einstellungen nicht weiter? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact)


# Wat doet FANATICS precies?
URL: https://www.fanatics.nl/nl/help/wat-doet-fanatics
Language: nl

FANATICS is een **[Odoo Gold Partner](/odoo-partner-nederland)** in Amsterdam. We doen drie dingen:

## 1. Odoo implementeren

We brengen Odoo ERP naar mkb-bedrijven. Van scan tot go-live tot blijvende support. Onze sweet-spot is bedrijven van 10–250 medewerkers.

- **Sectoren** waar we veel werken: dienstverlening, productie, handel, civiele techniek, retail.
- **Modules** die we het vaakst implementeren: CRM, Sales, Inventory, Manufacturing, Accounting, Project, HR, Timesheets.
- **Tijd** van kennismaking tot go-live: meestal [3–9 maanden](/help/hoe-snel-live).

## 2. Custom modules (Updoo)

Als Odoo standaard iets niet doet wat jij nodig hebt, bouwen we het bij. Zie [/updoo](/updoo) voor voorbeelden, timesheets-vereenvoudiging, configurators, shopfloor-screens, lead-capture-flows.

Onze bekendste is **[CPQ Builder](/nl/odoo-productconfigurator)**, een eigen Odoo-productconfigurator voor Configure-to-Order: de klant klikt een product op maat samen en het rolt via de standaard Odoo-API automatisch als verkooporder, stuklijst (BOM) en productieorder Odoo in - zonder maatwerkmodule in Odoo. Het draait als los product op [cpqbuilder.com](https://cpqbuilder.com).

De code blijft van jou, open-source, geen vendor-lock-in.

## 3. Doorlopende support

Na go-live blijft iemand van ons je vaste contactpersoon. Geen tickethel, geen wachtrij. Korte lijnen, snelle antwoorden.

## Wat we niet doen

- **Werken met junior consultants.** Iedereen die met jou werkt heeft minimaal een paar jaar Odoo-ervaring.
- **Offshore-teams.** Eigen mensen, geen subcontractors.
- **Pakketten van 87 pagina's.** We werken met de [TARGET-methode](/target), strak, kort, resultaatgericht.

Meer weten? [Plan een scan](/scan) of [stuur ons een mail](mailto:team@fanatics.nl).


# Mit welchen Odoo-Modulen sollte ich starten?
URL: https://www.fanatics.nl/de/help/welche-odoo-module-zuerst
Language: de

{/* TODO(de-review): first-pass DE translation. */}

Odoo hat 80+ Module. Aber **starten Sie nie mit allem gleichzeitig**. Unsere Regel: Wählen Sie drei Module, die Ihren größten Schmerz lösen, gehen Sie damit live, erweitern Sie danach.

## Die drei am häufigsten gewählten Start-Module

### 1. Sales + CRM
Fast alle Kunden beginnen hier. Pipeline-Management, Angebote, Auftragsbestätigung, automatische Nachverfolgung. Sofortiger Mehrwert, die Vertriebszyklen werden kürzer und niemand muss mehr in eine Tabelle schauen.

### 2. Inventory (Bestand)
Für Produktions- und Handelsbetriebe unverzichtbar. Multi-Warehouse, Barcodes, automatische Nachbestellung, Echtzeit-Bestandswert. Oft an Sales angebunden.

### 3. Accounting
**Optional** in Phase 1. Manche Kunden behalten ihre bestehende Buchhaltung ([Exact](/de/odoo-exact-integration), [Twinfield](/de/odoo-twinfield-integration)) und binden sie an Odoo an. Andere wechseln zu Odoo Accounting für maximale Integration. Siehe auch: [Lässt sich Odoo an Exact oder Twinfield anbinden?](/de/help/odoo-exact-twinfield-anbindung)

## Was in eine Phase 2 gehört

- **Manufacturing (MRP)**, wenn die Produktion komplexer wird oder wenn Sie Stücklisten und Arbeitsaufträge benötigen.
- **Project**, für projektgesteuerte Organisationen (Bau, Dienstleistung, IT).
- **HR + Timesheets**, binden Sie diese erst an, wenn die Basis sauber läuft.
- **eCommerce**, der Webshop von Odoo ist leistungsfähig, aber wenn Ihr Shop bereits auf [Shopify](/de/odoo-vs-shopify) oder Magento läuft, lassen Sie ihn dort.

## Was eine Phase 3 sein kann

- **Marketing Automation**, automatische E-Mail-Kampagnen, Lead-Scoring.
- **Helpdesk**, wenn Sie ein Support-Team haben, das Tickets verwaltet.
- **Subscription**, für SaaS- und Abonnementmodelle.

## Der Fehler, den wir oft sehen

Kunden, die versuchen, **alles auf einmal** zu implementieren. Das dauert zu lange, das Team wird überlastet, und der Go-live wird verschoben, bis alle die Geduld verlieren. Gehen Sie schrittweise vor.

Unsicher, wo Sie beginnen sollen? [Buchen Sie einen Scan](/de/scan), wir kartieren Ihre größten Schmerzpunkte und sagen Ihnen, welche Module sie lösen.


# What does Radical Fanatics do?
URL: https://www.fanatics.nl/help/what-does-radical-fanatics-do
Language: en

Radical Fanatics is an **[Odoo Gold Partner](/odoo-partner-nederland)** in Amsterdam. We do three things:

## 1. Implement Odoo

We bring Odoo ERP to SMEs. From scan to go-live to lasting support. Our sweet spot is companies of 10–250 staff.

- **Sectors** we work in a lot: professional services, manufacturing, trade, civil engineering, retail.
- **Modules** we implement most often: CRM, Sales, Inventory, Manufacturing, Accounting, Project, HR, Timesheets.
- **Time** from first meeting to go-live: usually [3–9 months](/help/hoe-snel-live).

## 2. Custom modules (Updoo)

When standard Odoo does not do something you need, we build it. See [/updoo](/updoo) for examples: timesheet simplification, configurators, shopfloor screens, lead-capture flows.

Our best known is **[CPQ Builder](/odoo-product-configurator)**, our own Odoo product configurator for Configure-to-Order: the customer clicks together a made-to-order product and it flows through the standard Odoo API into a sale order, a bill of materials (BOM) and a manufacturing order - with no custom module in Odoo. It runs as a standalone product at [cpqbuilder.com](https://cpqbuilder.com).

The code stays yours, open-source, no vendor lock-in.

## 3. Ongoing support

After go-live, someone from our team stays your fixed point of contact. No ticket hell, no queue. Short lines, fast answers.

## What we don't do

- **Work with junior consultants.** Everyone who works with you has at least a few years of Odoo experience.
- **Offshore teams.** Our own people, no subcontractors.
- **87-page packages.** We work with the [TARGET method](/target): tight, short, results-driven.

Want to know more? [Book a scan](/scan) or [send us an email](mailto:team@fanatics.nl).


# Was macht Radical Fanatics?
URL: https://www.fanatics.nl/de/help/was-macht-radical-fanatics
Language: de

{/* TODO(de-review): first-pass DE translation. */}

Radical Fanatics ist ein **[Odoo Gold Partner](/de/odoo-partner-nederland)** in Amsterdam. Wir machen drei Dinge:

## 1. Odoo implementieren

Wir bringen Odoo ERP in mittelständische Unternehmen. Vom Scan über den Go-live bis zum dauerhaften Support. Unsere Stärke liegt bei Unternehmen mit 10–250 Mitarbeitenden.

- **Branchen**, in denen wir oft arbeiten: Dienstleistung, Fertigung, Handel, Bauwesen, Einzelhandel.
- **Module**, die wir am häufigsten implementieren: CRM, Sales, Inventory, Manufacturing, Accounting, Project, HR, Timesheets.
- **Zeit** vom Kennenlernen bis zum Go-live: meist [3–9 Monate](/de/help/hoe-snel-live).

## 2. Maßmodule (Updoo)

Wenn Odoo standardmäßig etwas nicht kann, das Sie brauchen, bauen wir es nach. Beispiele finden Sie unter [/updoo](/de/updoo): vereinfachte Zeiterfassung, Konfiguratoren, Shopfloor-Screens, Lead-Capture-Flows.

Am bekanntesten ist **[CPQ Builder](/de/odoo-produktkonfigurator)**, unser eigener Odoo-Produktkonfigurator für Configure-to-Order: Der Kunde klickt ein Maßprodukt zusammen, und es fließt über die Standard-Odoo-API automatisch als Verkaufsauftrag, Stückliste (BOM) und Fertigungsauftrag nach Odoo - ohne Custom-Modul in Odoo. Er läuft als eigenständiges Produkt auf [cpqbuilder.com](https://cpqbuilder.com).

Der Code bleibt Ihrer, Open Source, kein Vendor-Lock-in.

## 3. Laufender Support

Nach dem Go-live bleibt jemand aus unserem Team Ihr fester Ansprechpartner. Keine Ticket-Hölle, keine Warteschlange. Kurze Wege, schnelle Antworten.

## Was wir nicht tun

- **Mit Junior-Beratern arbeiten.** Jeder, der mit Ihnen arbeitet, hat mindestens einige Jahre Odoo-Erfahrung.
- **Offshore-Teams.** Eigene Leute, keine Subunternehmer.
- **87-seitige Pakete.** Wir arbeiten mit der [TARGET-Methode](/de/target): straff, kurz, ergebnisorientiert.

Mehr erfahren? [Scan buchen](/de/scan) oder [schreiben Sie uns eine E-Mail](mailto:team@fanatics.nl).


# Which Odoo modules should I start with?
URL: https://www.fanatics.nl/help/which-odoo-modules-to-start-with
Language: en

Odoo has 80+ modules. But **never start with everything at once**. Our rule: pick three modules that solve your biggest pain, go live with those, then expand.

## The three most common starter modules

### 1. Sales + CRM
Almost every client starts here. Pipeline management, quotes, order confirmation, automatic follow-up. Immediate value, sales cycles get shorter and no one has to dig through a spreadsheet anymore.

### 2. Inventory
Essential for manufacturing and trading companies. Multi-warehouse, barcodes, automatic reordering, real-time stock value. Often connected to Sales.

### 3. Accounting
**Optional** in phase 1. Some clients keep their existing accounting ([Exact](/odoo-exact-integration), [Twinfield](/odoo-twinfield-integration)) and connect it to Odoo. Others move to Odoo Accounting for maximum integration. See also: [Can you connect Odoo to Exact or Twinfield?](/help/odoo-exact-twinfield-integration)

## What belongs in a Phase 2

- **Manufacturing (MRP)**, once production gets more complex, or when you need BOMs and work orders.
- **Project**, for project-driven organisations (construction, services, IT).
- **HR + Timesheets**, connect only once the basics run well.
- **eCommerce**, Odoo's webshop is capable, but if your shop already runs on [Shopify](/odoo-vs-shopify) or Magento, leave it there.

## What a Phase 3 might be

- **Marketing Automation**, automatic email campaigns, lead scoring.
- **Helpdesk**, if you have a support team tracking tickets.
- **Subscription**, for SaaS and subscription models.

## The mistake we see often

Clients trying to implement **everything at once**. It takes too long, the team gets overloaded, and the go-live keeps slipping until everyone has had enough. Do it step by step.

Not sure where to begin? [Book a scan](/scan), we'll map your biggest pains and tell you which modules solve them.


# Wie schnell können wir mit Odoo live gehen?
URL: https://www.fanatics.nl/de/help/wie-schnell-mit-odoo-live
Language: de

{/* TODO(de-review): first-pass DE translation. */}

**Kurze Antwort:** für einen KMU-Scope mit 3-6 Modulen, 5 bis 50 Nutzern und durchschnittlicher Komplexität: **3 bis 9 Monate** vom ersten Gespräch bis zum Go-live.

## Die drei Faktoren, die das Tempo bestimmen

### 1. Wie viele Module im Scope
- 1-2 Module (z. B. nur CRM + Sales): **2-4 Monate**
- 3-4 Module: **4-6 Monate**
- 5+ Module mit Integrationen: **6-9 Monate**

### 2. Wie viel Anpassung
Reines Standard-Odoo: schnell. Ein oder zwei [Custom-Module](/de/odoo-custom-development): mittel. Viele individuelle Abläufe, Integrationen mit Altsystemen, Datenmigration aus einem komplexen ERP: langsamer.

### 3. Verfügbarkeit Ihres Teams
Das ist **der größte Faktor** und wird am häufigsten unterschätzt. Eine Odoo-Implementierung erfordert 4-8 Stunden pro Woche von Ihren Key-Usern (den Personen, die das System am meisten nutzen werden). Sind sie nicht verfügbar, stockt das Projekt, nicht weil wir feststecken, sondern weil wir keine Entscheidungen bekommen.

## Die schnellsten Implementierungen, die wir umgesetzt haben

- **6 Wochen**, kleines [Dienstleistungsunternehmen](/de/industries/services), nur CRM + Sales, keine Migration, Key-User verfügbar.
- **3 Monate**, [Produktionsbetrieb](/de/industries/manufacturing), Sales + Inventory + Manufacturing, ausgehend von einem reinen Excel-Setup.

## Die langsamsten

- **14 Monate**, mittelgroßes Unternehmen beim Wechsel von SAP, mit 8 Modulen, 4 Anbindungen und 20 Jahren Altdaten. Vollständig im Scope, aber schlicht ein großes Vorhaben.

## Was wir nicht tun

**Big-Bang-Implementierungen.** Wir arbeiten immer in Phasen. Zuerst gehen zwei Module live, dann zwei weitere, dann der Rest. So vermeiden Sie, dass eine Implementierung monatelang in einer Testumgebung hängenbleibt und Ihr Team die Geduld verliert.

Möchten Sie eine ehrliche Einschätzung für Ihre Situation? [Buchen Sie einen Scan](/de/scan), nach 30 Minuten wissen wir genug, um eine Zeitleiste zu skizzieren.


# Label-rapporten in Odoo aanpassen (ZPL, Zebra)
URL: https://www.fanatics.nl/nl/help/zebra-labels-aanpassen-odoo
Language: nl

*Waarschuwing: maak altijd een goede backup voordat je een van de onderstaande stappen uitvoert.*

Odoo kent verschillende standaardopties om Zebra-labels te printen. Je past ze niet aan via Studio, maar je kunt wel een kopie van het standaardrapport bewerken. Daarvoor heb je basiskennis van ZPL-code nodig - die valt gelukkig mee.

![Printerdialoog in Odoo met labelformaten, waaronder ZPL Labels, voor het printen van productlabels](/kb/zpl-label-printing/img-1.png)

## Standaardinstellingen aanpassen

De standaardinstellingen van dit label pas je aan via het Qweb-tabblad van het achterliggende rapport.

Zet eerst Developer mode aan. Typ vanaf het startscherm `/reports` om alle rapporten te openen.

![Odoo-zoekbalk met /reports om naar het rapportenoverzicht te navigeren](/kb/zpl-label-printing/img-2.png)

Kies **Settings / Technical / Actions / Reports** en open het rapport dat je wilt bewerken - in dit geval **Product Label (ZPL)**.

![Lijst met Odoo-rapporten met Product Label (ZPL) gemarkeerd](/kb/zpl-label-printing/img-3.png)

Na het openen vind je rechtsboven de knop naar het Qweb-deel van het rapport. Die Qweb-code regelt de opmaak van het label.

![Rapportformulier in Odoo met rechtsboven de knop QWeb Views naar de opmaakcode](/kb/zpl-label-printing/img-4.png)

## ZPL-code van het label

Open je die view, dan zie je op het tabblad **Architecture** de code die hoort bij de huidige installatie en module-opties. Die code pas je hier aan.

Let op: wijzigingen aan de standaardlayout worden bij een volgende update hoogstwaarschijnlijk overschreven. Werk daarom bij voorkeur met een inherited view. Dat valt buiten de scope van dit artikel, maar voor testen is rechtstreeks aanpassen wel handig. Handig om te weten: je commentarieert een regel uit met een puntkomma (`;`). Alles na de puntkomma negeert de ZPL-interpreter.

Maak ook hier eerst een backup van de huidige code, zodat je altijd terug kunt naar de standaard.

### Voorbeeld van de standaardcode

![Qweb-view in Odoo met de ZPL-code van het Product Label-rapport op het tabblad Architecture](/kb/zpl-label-printing/img-5.png)

```
<t t-name="stock.label_product_product_view">
    <t t-foreach="quantity.items()" t-as="barcode_and_qty_by_product">
        <t t-set="product" t-value="barcode_and_qty_by_product[0]"/>
        <t t-foreach="barcode_and_qty_by_product[1]" t-as="barcode_and_qty">
            <t t-set="barcode" t-value="barcode_and_qty[0]"/>
            <t t-foreach="range(barcode_and_qty[1])" t-as="qty">
                <t t-translation="off">
^XA
^FT100,80^A0N,40,30^FD<t t-esc="product.display_name"/>^FS
<t t-if="product.default_code and len(product.default_code) > 15">
^FT100,115^A0N,30,24^FD<t t-esc="product.default_code[:15]"/>^FS
^FT100,150^A0N,30,24^FD<t t-esc="product.default_code[15:30]"/>^FS
</t>
<t t-else="">
^FT100,150^A0N,30,24^FD<t t-esc="product.default_code"/>^FS
</t>
<t t-if="price_included">
^FO600,100,1
^CI28
<t t-if="product.currency_id.position == 'after'">
^A0N,66,48^FH^FD<t t-esc="product.list_price" t-options="{&quot;widget&quot;: &quot;float&quot;, &quot;precision&quot;: 2}"/><t t-esc="product.currency_id.symbol"/>^FS
</t>
<t t-if="product.currency_id.position == 'before'">
^A0N,66,48^FH^FD<t t-esc="product.currency_id.symbol"/><t t-esc="product.list_price" t-options="{&quot;widget&quot;: &quot;float&quot;, &quot;precision&quot;: 2}"/>^FS
</t>
</t>
<t t-if="barcode">
^FO100,160^BY3
^BCN,100,Y,N,N
^FD<t t-esc="barcode"/>^FS
</t>
^XZ
                </t>
            </t>
        </t>
    </t>
</t>
```

### De code uitgelegd

Deze code drukt labels af voor producten met bijbehorende barcodes en hoeveelheden. Regel voor regel:

1. `<t t-name="stock.label_product_product_view">`: de naam van het sjabloon voor productlabels.
2. `<t t-foreach="quantity.items()" t-as="barcode_and_qty_by_product">`: een lus die door elk item in `quantity` itereert, zodat je barcode en hoeveelheid per product kunt afdrukken.
3. `<t t-set="product" t-value="barcode_and_qty_by_product[0]"/>`: zet de variabele `product` op het eerste element, dat het product vertegenwoordigt.
4. `<t t-foreach="barcode_and_qty_by_product[1]" t-as="barcode_and_qty">`: een lus over de lijst met barcodes en hoeveelheden, zodat je meerdere barcodes per product kunt afdrukken.
5. `<t t-set="barcode" t-value="barcode_and_qty[0]"/>`: zet de variabele `barcode` op de barcode.
6. `<t t-foreach="range(barcode_and_qty[1])" t-as="qty">`: een lus die de barcode net zo vaak afdrukt als de opgegeven hoeveelheid.
7. `<t t-translation="off">`: schakelt vertaling uit, zodat de teksten ongewijzigd blijven.
8. `^XA`: start de ZPL-commando's.
9. `^FT100,80^A0N,40,30^FD<t t-esc="product.display_name"/>^FS`: positie en lettertype van de eerste tekstregel; drukt de weergavenaam van het product af.
10. `<t t-if="product.default_code and len(product.default_code) > 15">`: controleert of de standaardcode bestaat en langer is dan 15 tekens.
11. `^FT100,115^A0N,30,24^FD<t t-esc="product.default_code[:15]"/>^FS`: drukt de eerste 15 tekens van de standaardcode af.
12. `^FT100,150^A0N,30,24^FD<t t-esc="product.default_code[15:30]"/>^FS`: drukt het volgende deel van de standaardcode af.
13. `<t t-else="">`: het alternatief als de standaardcode niet langer dan 15 tekens is.
14. `^FT100,150^A0N,30,24^FD<t t-esc="product.default_code"/>^FS`: drukt de volledige standaardcode af.
15. `<t t-if="price_included">`: controleert of de prijs is inbegrepen.
16. `^FO600,100,1`: plaatst de prijs op het label.
17. `^CI28`: stelt de tekencodering in op UTF-8.
18. `<t t-if="product.currency_id.position == 'after'">`: controleert of het valutasymbool achter de prijs staat.
19. `^A0N,66,48^FH^FD...`: drukt prijs en valutasymbool af.
20. `<t t-if="product.currency_id.position == 'before'">`: controleert of het valutasymbool voor de prijs staat.
21. `^A0N,66,48^FH^FD...`: drukt valutasymbool en prijs af.
22. `<t t-if="barcode">`: controleert of er een barcode is.
23. `^FO100,160^BY3`: plaatst de barcode en stelt de barcodeparameters in.
24. `^BCN,100,Y,N,N`: stelt het type en de grootte van de barcode in.
25. `^FD<t t-esc="barcode"/>^FS`: drukt de barcode af.
26. `^XZ`: beëindigt de ZPL-commando's.

Het resultaat is een label met productnaam, standaardcode, prijs en barcode voor elk product met bijbehorende hoeveelheden en barcodes.

## Tip: laat een AI-assistent meedenken

Een AI-assistent helpt prima om een onderdeel aan te passen. Op de vraag "hoe verklein ik in onderstaande code de lettergrootte en de barcode met 50%?" volgt dit antwoord:

> De lettertypen worden gedefinieerd met `^A0N`, gevolgd door de parameters voor de lettergrootte. Halveer die waarden om de tekst te verkleinen. De barcodegrootte stel je in met `^BY3`; verlaag die naar bijvoorbeeld 2,5, 2 of 1,5 om de barcode te verkleinen.

De aangepaste code, met letter- en barcodegrootte met 50% verkleind:

```
<t t-name="stock.label_product_product_view">
    <t t-foreach="quantity.items()" t-as="barcode_and_qty_by_product">
        <t t-set="product" t-value="barcode_and_qty_by_product[0]"/>
        <t t-foreach="barcode_and_qty_by_product[1]" t-as="barcode_and_qty">
            <t t-set="barcode" t-value="barcode_and_qty[0]"/>
            <t t-foreach="range(barcode_and_qty[1])" t-as="qty">
                <t t-translation="off">
^XA
^FT100,80^A0N,20,15^FD<t t-esc="product.display_name"/>^FS
<t t-if="product.default_code and len(product.default_code) > 15">
^FT100,115^A0N,15,12^FD<t t-esc="product.default_code[:15]"/>^FS
^FT100,150^A0N,15,12^FD<t t-esc="product.default_code[15:30]"/>^FS
</t>
<t t-else="">
^FT100,150^A0N,15,12^FD<t t-esc="product.default_code"/>^FS
</t>
<t t-if="price_included">
^FO600,100,1
^CI28
<t t-if="product.currency_id.position == 'after'">
^A0N,33,24^FH^FD<t t-esc="product.list_price" t-options="{&quot;widget&quot;: &quot;float&quot;, &quot;precision&quot;: 2}"/><t t-esc="product.currency_id.symbol"/>^FS
</t>
<t t-if="product.currency_id.position == 'before'">
^A0N,33,24^FH^FD<t t-esc="product.currency_id.symbol"/><t t-esc="product.list_price" t-options="{&quot;widget&quot;: &quot;float&quot;, &quot;precision&quot;: 2}"/>^FS
</t>
</t>
<t t-if="barcode">
^FO100,160^BY2
^BCN,50,Y,N,N
^FD<t t-esc="barcode"/>^FS
</t>
^XZ
                </t>
            </t>
        </t>
    </t>
</t>
```

De lettergrootteparameters zijn verlaagd (bijv. 20, 15, 15, 12) en de barcodeparameters naar een kleinere barcode (`^BY2`, `^BCN,50`).

## Hulp nodig bij je Zebra-labels?

Loop je vast bij het aanpassen van je ZPL-rapport of een inherited view? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact) - dan kijken we met je mee.


# Zusätzliche Produktfelder auf Ihrer Odoo eCommerce-Seite anzeigen
URL: https://www.fanatics.nl/de/help/zusaetzliche-produktfelder-ecommerce
Language: de

{/* TODO(de-review): first-pass DE translation, needs native-speaker review. */}

Manchmal möchten Sie auf der Produktseite Ihres Shops mehr zeigen als nur Name und Preis - etwa die Artikelnummer, den Barcode oder ein eigenes HTML-Feld mit zusätzlichen Informationen. In Odoo verknüpfen Sie solche Felder ohne Eigenentwicklung mit der Seite.

## Ein vorhandenes Feld anzeigen

1. Öffnen Sie die Produktseite in Ihrem Shop und klicken Sie oben rechts auf **Bearbeiten**.
2. Ziehen Sie einen **Text**-Block an die Stelle, an der die Information erscheinen soll.
3. Markieren Sie den Text, öffnen Sie den Inline-Editor und wählen Sie **Feld verknüpfen** (Dynamic field).
4. Wählen Sie das gewünschte Feld, zum Beispiel die Artikelnummer (Internal Reference) oder den Barcode.
5. Speichern Sie. Der Block zeigt nun den Wert des Produkts an, das die Besucherin oder der Besucher gerade ansieht.

Der Wert folgt dem Produkt: Öffnen Sie einen anderen Artikel, passt sich die angezeigte Information von selbst an.

## Ein neues Feld hinzufügen

Gibt es das Feld noch nicht, legen Sie es zunächst mit Studio an:

1. Öffnen Sie Studio im Produktformular und fügen Sie ein neues Feld hinzu (Text, Zahl oder HTML).
2. Befüllen Sie das Feld bei Ihren Produkten mit dem passenden Wert.
3. Verknüpfen Sie das Feld anschließend auf dieselbe Weise mit einem Block auf der Produktseite.

Ein HTML-Feld eignet sich, wenn Sie formatierte Inhalte zeigen möchten, etwa eine Spezifikationstabelle oder einen Block mit Zertifizierungen.

## Videos

Das folgende Video zeigt Schritt für Schritt, wie Sie ein Produktfeld verknüpfen:

- [Kurze Anleitung (Screencast)](https://app.screencast.com/vrgeODYRrlvF8)

Möchten Sie einen Schritt weitergehen, zum Beispiel mit dynamischen Feldern und eigenen Blöcken? Sehen Sie sich dieses Video an:

- [Vertiefung (YouTube)](https://www.youtube.com/watch?v=97W6YeYVwxU)

## Brauchen Sie Unterstützung bei Ihrem Shop?

Möchten Sie Ihre Odoo eCommerce-Seiten cleverer einrichten? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact) - wir schauen gemeinsam mit Ihnen.


# Journaalposten importeren in Odoo
URL: https://www.fanatics.nl/nl/help/boekingen-importeren
Language: nl

Met een importbestand lees je journaalposten in Odoo in. Handig bijvoorbeeld om een complexe terugkerende loonjournaalpost in één keer in te lezen in plaats van regel voor regel te boeken.

**Download:** [Importtemplate journaalposten (XLSX)](/kb/import-journal-entries/import-template-journaalposten.xlsx)

## De opzet van het bestand

Zorg dat de kolommen A tot en met C op één rij zijn gevuld. Alleen zo herkent Odoo dat de regels bij één journaalpost horen. Je importeert records per dagboek.

![Voorbeeld van een journaalpost-import in Odoo, met kolommen A-C op een rij ingevuld](/kb/import-journal-entries/img-1.png)

Een voorbeeld-importbestand (`Import journaalpost.xlsx`) hoort bij dit artikel en laat de juiste kolomopzet zien.

Loop je vast bij het importeren? [Plan een Odoo-scan](/nl/scan) of [neem contact op](/nl/contact).


# Buchungen in Odoo importieren
URL: https://www.fanatics.nl/de/help/buchungen-importieren
Language: de

{/* TODO(de-review): first-pass DE translation, needs native-speaker review. */}

Mit einer Importdatei lesen Sie Journalbuchungen in Odoo ein. Praktisch ist das zum Beispiel, um eine komplexe wiederkehrende Lohnbuchung in einem Schritt einzulesen, statt Zeile für Zeile zu buchen.

**Download:** [Importvorlage Buchungen (XLSX)](/kb/import-journal-entries/import-template-journaalposten.xlsx)

## Aufbau der Datei

Achten Sie darauf, dass die Spalten A bis C in einer Zeile gefüllt sind. Nur so erkennt Odoo, dass die Zeilen zu einer Buchung gehören. Sie importieren die Datensätze pro Journal.

![Beispiel eines Buchungsimports in Odoo, mit den Spalten A-C in einer Zeile ausgefüllt](/kb/import-journal-entries/img-1.png)

Eine Beispiel-Importdatei (`Import journaalpost.xlsx`) gehört zu diesem Artikel und zeigt den richtigen Spaltenaufbau.

Kommen Sie beim Import nicht weiter? [Buchen Sie einen Odoo-Scan](/de/scan) oder [nehmen Sie Kontakt auf](/de/contact).


# Import journal entries into Odoo
URL: https://www.fanatics.nl/help/import-journal-entries
Language: en

An import file lets you load journal entries into Odoo. Handy, for example, to load a complex recurring payroll journal entry in one go instead of posting it line by line.

**Download:** [Journal entries import template (XLSX)](/kb/import-journal-entries/import-template-journaalposten.xlsx)

## How to structure the file

Make sure columns A through C are filled on a single row. That is the only way Odoo recognises that the lines belong to one journal entry. You import records per journal.

![Example of a journal entry import in Odoo, with columns A-C filled on one row](/kb/import-journal-entries/img-1.png)

An example import file (`Import journaalpost.xlsx`) accompanies this article and shows the correct column layout.

Stuck on the import? [Book an Odoo scan](/scan) or [get in touch](/contact).


================================================================

BLOG

================================================================

# The best software for installation companies (2026): an honest comparison
URL: https://www.fanatics.nl/blog/best-software-installation-companies
Language: en

**Short answer:** there is no best software for *every* installation company - there is a best choice per profile. A small team that mainly wants rid of paper work orders is fine with a light app. An installation company deep into service and maintenance often picks an industry package. And whoever wants to connect the whole company - from quote to engineer to invoice to webshop - ends up at a broad platform. Below, seven packages commonly chosen in the Dutch market, honestly side by side, including the one we sell ourselves (bias disclosed where it applies).

## At a glance

| Package | Type | Strongest point | Watch out |
|---|---|---|---|
| **Syntess Atrium** | Industry ERP for installers | Depth in installation, service and maintenance | Vertical and closed; recently "Powered by Aceve" |
| **OpusFlow** | All-in-one for (sustainable) installers | Popular with solar and heat-pump installers | Younger product; verify depth per process |
| **AFAS** | Broad Dutch ERP | Finance, HR and payroll in one | Field service and work orders are not the core |
| **Exact Construction & Installation** | Accounting + industry layer | Strong Dutch accounting core | Thinner in engineer planning and service |
| **4PS Construct** | Construction ERP on Microsoft | Project-based construction, Microsoft stack | Enterprise weight; heavier project |
| **Simple-Simon** | Work-order app | Live fast, low threshold, cheap | Only the work order; everything else stays put |
| **Odoo + RogerDone** | Open platform + dispatch board | Everything connected, CRM through accounting, plus smart engineer planning | Standard planning is basic - hence RogerDone |

## The seven packages, discussed honestly

**Syntess Atrium** has been the reference in the installation industry for decades: work orders, maintenance contracts, project control and quoting in the installer's own language. That depth is real. The flip side: it is a vertical, closed package - the moment you want a webshop, customer portal, CRM as a growth engine or broad reporting, you end up in integrations. And since the company presents itself as "Syntess - Powered by Aceve", there is an extra reason to pay attention: a new owner means questions about roadmap, pricing and support. The full trade-off sits in our [Syntess alternative overview](/syntess-alternative) and the [1-on-1 comparison Odoo vs Syntess](/odoo-vs-syntess).

**OpusFlow** positions itself as an all-in-one platform for installers, with strong traction among sustainable-installation companies (solar, heat pumps, charging stations). Strong marketing and pace. It is a younger product than the established names: verify per process (quoting, inventory, accounting) whether the depth is there for your company, and ask for references in your sub-sector.

**AFAS** is a broad Dutch ERP with finance, HR and payroll at its heart. A logical candidate when the administrative side is your biggest pain - but field-service planning and work orders are not the core, so a second package often lands next to it anyway.

**Exact Construction & Installation** builds on the strongest Dutch accounting core in the SMB market, with an industry layer for construction and installation. Same pattern as AFAS: strong where it comes from (finance), thinner in engineer planning and service execution.

**4PS Construct** is a serious construction and installation ERP on the Microsoft platform (Business Central). A logical candidate for larger, project-driven installation companies deep in the Microsoft stack - budget for an implementation with enterprise weight.

**Simple-Simon** is the lightest of the list: a work-order app that goes live fast and costs little. Fine for a small team getting off paper. But the app only solves the work order - the order, stock, invoice and job costing still live elsewhere, and that is where the retyping starts. Why that is the real problem: [digital work orders: the app is not the problem](/blog/digital-work-orders), and the direct comparison in [Odoo vs Simple-Simon](/odoo-vs-simple-simon).

**Odoo + RogerDone** - and here we are a party, so read with that in mind. Odoo connects what usually lies scattered at installation companies: CRM, quotes, purchasing, inventory, work orders (Field Service), maintenance contracts, invoicing and accounting on one open platform. Honesty requires saying: the standard engineer planning is functional but basic. That is exactly why we built [RogerDone](/updoo/rogerdone), a smart dispatch board on top of Odoo that plans on skills, travel time and availability. The complete guide for this route: [software for field-service installers](/software-for-field-service-installers).

## Which one fits you?

- **1-5 engineers, paper is the problem** → Simple-Simon or another light work-order app; keep it simple.
- **Purely installation/service, deliberately in a vertical package** → Syntess Atrium or OpusFlow; choose on references in your sub-sector.
- **Administration and HR are the biggest pain** → AFAS or Exact; accept that field service needs a second solution.
- **Large, project-driven, Microsoft house** → 4PS.
- **Connecting service with sales, inventory, portal and finance** → Odoo + RogerDone; book a [free scan](/scan) and we will say so honestly if a vertical package fits you better.

## Frequently asked questions

**What is the best software for an installation company?**
There is no best for everyone: light team → work-order app; deep into service/maintenance → industry package (Syntess, OpusFlow); connecting everything → Odoo + RogerDone. Choose on your centre of gravity, not the longest feature list.

**What is a good alternative to Syntess Atrium?**
Staying in a vertical package: OpusFlow. Connecting wider: Odoo with RogerDone. Since the Aceve acquisition this is the moment many customers compare - see the [full Syntess alternative overview](/syntess-alternative).

**What does software for an installation company cost?**
Light apps from roughly €10-20 per user per month; industry packages and ERP tens of euros per user plus implementation. Compare three-year totals.

**Does an installation company need an ERP, or is a work-order app enough?**
Up to about five engineers with simple administration: an app suffices. Above that, retyping between systems costs more than integration.

**Can Odoo run an installation company end to end?**
Yes, from quote to accounting; for smart engineer planning we complement the basic standard with RogerDone.

**What does the Aceve acquisition of Syntess mean?**
Little in the short term; watch roadmap, pricing and support - and use the moment to re-test your choice.

---

**Torn between two of these packages?** [Book a free Odoo scan](/scan) - we put your processes next to the candidates and are honest about where Odoo wins and where the vertical package wins.

---

**Read more:** [Software for field-service installers: the complete guide](/software-for-field-service-installers) · [Syntess alternative](/syntess-alternative) · [Odoo vs Syntess](/odoo-vs-syntess) · [Odoo vs Simple-Simon](/odoo-vs-simple-simon) · [RogerDone](/updoo/rogerdone)


# Contract management software: which of the three problems do you actually have?
URL: https://www.fanatics.nl/blog/contract-management-software-erp
Language: en

*You are looking for contract management software. What you find is a market where three completely different products are sold under the same name, at prices a factor of twenty apart. Before you start comparing, it is worth establishing which of the three you are actually after.*

**Short answer:** there are three categories. A **contract register** answers which contracts you hold, when they expire and who signed. **Recurring billing** turns contracts into periodic invoices and handles renewals. **Contract lifecycle management** supports the drafting and negotiation itself, with clause libraries and approval flows. Most mid-sized companies mean the first, sometimes buy the second, and almost never need the third.

## The three categories

**Category 1: the contract register.** This is what most businesses are actually looking for. The question behind it is nearly always the same: which contracts are running, when do we have to cancel or renew, and where is the signed copy. The problem is usually not that no system exists, but that the contracts are scattered across mailboxes, a network drive and the memory of someone who will not work here in three years.

**Category 2: recurring billing.** Here it is not about the agreement but about the money that comes out of it. Which invoice goes out when, what happens at renewal, how do you track recurring revenue. That is a materially different question from category 1, even though it hangs off it.

**Category 3: contract lifecycle management.** The drafting and negotiating itself: clause libraries, comparing versions, approval rounds past legal and the board. A real category with real value, but for organisations where drafting contracts is the work rather than an incidental.

## How to work out which one you have

A simple test. Answer this: **what went wrong last time?**

Did you miss a notice period, or did your lease quietly roll over for another year? That is category 1. Was an invoice wrong, or did a renewal go out at the old rate? That is category 2. Did a contract take three weeks to sign because it went round four people? That is category 3.

Most companies that come to us saying "we want something for contract management" have category 1 and sometimes 2. We rarely meet category 3 in the mid-market, and when we do we refer it on.

## Where Odoo fits and where it does not

We are explicit here, because a sales pitch would be easy.

**Strong: recurring billing.** [Odoo](/odoo-erp) Subscriptions does this well. Recurring products and services, automated invoicing, renewals manual or automatic, upsells carried into the renewal, and batch views showing which customers are due. There are configurable alerts that fire as soon as a subscription meets conditions you set yourself, triggering an email, an activity or an update. And customers see their own contracts and options in the portal. We take that further in [subscription management software](/blog/subscription-management-software).

**Workable but not out of the box: the contract register.** Odoo has Documents for the files and activities with reminders for the dates. With those you can build a register that functions perfectly well, including notice periods that land on someone's screen in time. But be honest about what that is: configuration, not a module you switch on. If a contract register is your only question and you do nothing else in Odoo, a light standalone package is faster to get live.

**Do not: CLM.** Clause libraries, redlining, approval flows across several parties. Odoo is not built for that and neither are we. Find a specialist.

What Odoo does add is the place the contract came from: the quote, the order and the customer already sit in the same system. A contract that lives apart from the sales order it came out of is a second administration you will be maintaining.

## The question underneath the question

In nearly every contract management conversation we have, the real problem turns out not to be the software but the owner. Contracts go wrong not because there is no system, but because nobody is responsible for them. Buying a package without answering that first produces an empty system in which, two years from now, the same contracts are missing as today.

So our honest order is: first decide who owns this and which contracts exist, then look at where they should live. That is less fun than comparing software and it saves more money.

---

**Not sure which of the three you need?** [Book a free Quickscan](/scan) and we will walk through your contracts, renewals and billing flows before anything gets purchased.

---

**Read more:** [Subscription management software](/blog/subscription-management-software) · [Odoo for leasing and rental companies](/blog/odoo-for-leasing-and-rental-companies) · [Odoo ERP](/odoo-erp)


# Inventory management software for a small business: spreadsheet, standalone, WMS or your ERP?
URL: https://www.fanatics.nl/blog/inventory-management-software-small-business
Language: en

*Your stock no longer adds up. There is something in the system that is not on the shelf, or you sell something you do not have. So you start shopping for software. The difficult part is that the market sells you four different things under roughly the same banner, and the prices are a factor of twenty apart.*

**Short answer:** there are four levels. A **spreadsheet** is fine until more than one person needs to be in it, you sell through several channels, or you no longer trust your own numbers. A **standalone stock package** suits anyone who only needs to sort out inventory and has nothing else to connect. A **WMS** is for a warehouse problem rather than a stock problem: it is about where something sits and how you pick it efficiently. And the **inventory module in your ERP** is usually the right answer as soon as stock is connected to sales, purchasing and accounting. Most companies are shopping one level higher than they need.

## The four levels, and where you outgrow each

**Level 1: the spreadsheet.** Do not underestimate it. For a business with a few hundred items, one location and one person keeping stock, a spreadsheet is fast, free and understood by everyone. You outgrow it at three moments: when a second person needs to be in it at the same time, when you sell through more than one channel, or when you start counting more often than you reorder. That last one is the sharpest signal, because counting is what you do when you no longer believe your own records.

**Level 2: a standalone stock package.** Barcode scanning, reorder points, multiple locations, an app on the floor. A perfectly good category, and for a business without other systems often exactly enough. The problem only appears when something else arrives beside it: a webshop, an accounting package, a sales system. Every integration then becomes a place where the truth can drift apart.

**Level 3: a WMS.** This is where most of the confusion sits, and therefore most of the wasted money. A warehouse management system does not solve a stock problem but a warehouse problem: where do I put this down, in what order does the picker walk, how do I stop two people heading for the same rack. If your warehouse is a room, you do not need this. If your warehouse is a hall where picking routes genuinely matter, you do. We work that distinction out separately in [warehouse management software](/blog/odoo-as-wms).

**Level 4: your ERP inventory module.** As soon as stock is connected to sales, purchasing, manufacturing and accounting, a separate inventory solution is usually the more expensive route. Not because of the licence, but because of the integration you buy with it and keep maintaining.

## The distinction that decides most choices

If you take one thing from this page: **inventory management answers how many, a WMS answers where and how.**

Do you have too much or too little of things, reorder too late, or find your valuation is off? That is inventory. Are your people walking too far, does it take too long for an order to leave, do people put things down in arbitrary places? That is a warehouse problem.

The two feel identical, because both surface as "our stock does not add up". But the solutions are a factor of ten apart in cost, so it pays to establish which of the two you actually have before you go shopping.

## The spreadsheet moment

Plenty of businesses search for stock control in Excel because they want to rescue their spreadsheet rather than replace it. That is a reasonable reflex, and sometimes the right answer.

What does work: formulas for reorder points, a second tab for movements, and a fixed counting day. What does not work, and what people attempt anyway: several people at once, a real-time link to a webshop, and serial number or best-before registration. Those are precisely the three things a spreadsheet was structurally never built for, and where the time you invest does not come back.

The broader step from spreadsheet to system is covered in [from Excel to Odoo](/blog/from-excel-to-odoo).

## When your ERP is already enough

If you already run an ERP, the honest question is not which stock package to buy but whether you are using the module you already have. [Odoo](/odoo-erp) includes inventory as standard: multiple warehouses and locations, reorder points per product per location, barcode scanning, putaway and removal strategies such as FIFO and FEFO, and lot and best-before tracing. For most trading and manufacturing businesses that is more than enough.

The real advantage is not the feature list but the data model: a sales order lowers your available stock immediately, a purchase order raises it, and your accounting follows without anything being retyped. A standalone package can have the same features and still work out worse, simply because there is an integration in between.

For wholesale and distribution we take this further on the [wholesale page](/industries/wholesale).

## When a standalone package beats us

This belongs here, because otherwise this piece is a sales pitch.

If you only have a stock question and no other systems that need to hang around it, a light, inexpensive inventory package is live faster and cheaper than an ERP project. If your warehouse logic genuinely sits at the top end, with wave picking, zone control or complex cross-docking, a specialised WMS alongside your ERP is the better answer and we will say so. And if you are still at the very beginning with a handful of items, the honest message is that your spreadsheet is fine and your money is better spent elsewhere.

---

**Unsure whether you have a stock problem or a warehouse problem?** [Book a free Quickscan](/scan) and we will walk through your items, locations and order flow before anything gets purchased.

---

**Read more:** [Warehouse management software: can Odoo handle your warehouse?](/blog/odoo-as-wms) · [From Excel to Odoo](/blog/from-excel-to-odoo) · [Odoo for wholesale and distribution](/industries/wholesale) · [Odoo as a PIM](/blog/odoo-as-a-pim)


# Adding a Dutch entity to your ERP: what changes, by country of origin
URL: https://www.fanatics.nl/blog/dutch-entity-in-your-erp
Language: en

*Most of our work starts with one company in one country. Then a group decides to open something in the Netherlands, and a different set of questions arrives: not "which modules do we need" but "what does this country demand that ours does not, and what does that do to the system we already run". The incorporation itself is your lawyer's and tax adviser's job. What lands on the ERP team's plate is everything after it, and that part is rarely written down anywhere.*

**Short answer:** a Dutch entity registers for Dutch VAT and files its own return, quarterly by default, plus an **ICP declaration** listing its B2B supplies to VAT-registered customers elsewhere in the EU. If it imports from outside the EU it will want the **article 23 deferment**, which moves import VAT from the border to the return, and which a foreign company cannot apply for by itself. The chart of accounts is rebuilt rather than translated, annual accounts of a BV are public, and Dutch payroll runs on its own rules. In your ERP that means a second company with its own chart of accounts, tax regime and filing calendar next to the parent, not a second system.

## Why an Odoo partner is writing this

To be clear about what this is and is not: we are not your notary, your tax adviser or a company formation agent, and nothing here replaces them. What we can tell you is what each of these choices does to your system, because that is the part we get handed once the entity exists and nobody planned for the filings, the chart of accounts or the second VAT calendar.

We deliver Odoo internationally, including in countries where Odoo shipped no fiscal localisation and we [built one ourselves](/international-odoo-partner). This page is the reverse direction: not a Dutch group expanding outward, but a foreign group landing here. If you are the one expanding outward, the companion piece is [international accounting with Odoo](/blog/international-accounting-with-odoo), which works through which country ledger belongs in your system and which is better kept local and connected.

## What every foreign entity meets here

Six things apply regardless of where your parent sits.

- **BV or branch.** A BV is a separate legal entity with its own annual accounts deposited at the Chamber of Commerce. A branch is a registered presence of the foreign company and is not a separate legal entity. Your adviser decides which; your ERP has to reflect it.
- **Chamber of Commerce registration.** Every entity registers with the KVK, and that registration is public, including the deposited annual accounts of a BV.
- **Dutch VAT and its filing rhythm.** The Dutch entity registers for VAT and files its own returns, quarterly by default. The parent's VAT number does not cover it.
- **The ICP declaration.** A separate filing listing your B2B supplies to VAT-registered customers in other EU countries, submitted next to the VAT return. This is the single most-missed obligation on this list.
- **The chart of accounts.** The Netherlands has a widely used reference chart, the RGS, but it is a reference rather than a strict statutory template. Dutch practice allows more freedom here than several neighbouring countries do, which is liberating or unnerving depending on where you come from.
- **Payroll and the expat facility.** Dutch payroll tax runs on its own rules, and the facility for incoming employees, long known as the 30 percent ruling and now the expat scheme, is being trimmed: it stays at 30 percent through 2026 and drops to 27 percent from 2027, with the salary threshold rising to 50.436 euro.

## The Dutch VAT return, and the two things sitting next to it

Worth its own section, because this is the part that generates work every quarter for as long as the entity exists.

The **Dutch VAT return** is filed with the Belastingdienst, quarterly by default, monthly if your volume or history calls for it. It nets what you charged against what you paid, so unlike a US sales tax filing it is not purely a remittance. Miss the rhythm and the penalties are administrative rather than dramatic, but the filing calendar is a real operational commitment that someone has to own from month one.

Two things sit alongside it.

**The ICP declaration.** Short for intracommunautaire prestaties, this lists your B2B supplies to VAT-registered customers in other EU countries and is submitted next to the VAT return. Every EU country has an equivalent, generally called the EC Sales List. If your parent is German, Belgian or French this will look familiar. If it is British, American or Chinese, there is no analogue at home, and this is the obligation teams most reliably forget until the first reminder arrives.

**The article 23 import deferment.** If the Dutch entity imports goods from outside the EU, this is the single most valuable thing on the page. Without it, import VAT is paid at the border and reclaimed later, so the money is out of the business in the meantime. With an article 23 permit, the import VAT is declared and deducted on the same VAT return, which nets to zero and keeps the cash. For a business importing containers, that cash-flow difference is a large part of why groups pick the Netherlands for their EU entity in the first place.

The catch, and it surprises almost everyone: **a foreign company cannot apply for an article 23 permit itself.** You need to be established here, and to have imported from outside the EU more than once. A foreign entrepreneur works through a fiscal representative, who either applies on your behalf or lets you operate under theirs, and who reports and deducts the import VAT on the return. You also have to keep an administration that shows the import VAT owed separately, which is a system requirement rather than a paperwork one.

In practice that last point is where the ERP earns its place: the return, the ICP declaration and the separate import VAT trail should all fall out of transactions already recorded, not out of a quarterly spreadsheet reconstruction.

## What surprises teams, by country of origin

| Coming from | What tends to catch teams out | What it changes in your ERP |
| --- | --- | --- |
| **United Kingdom** | There is no ICP equivalent at home, and post-Brexit your Dutch entity now sits inside the EU while the parent does not | A second VAT regime plus an EU-specific filing the UK system was never built to produce |
| **Germany** | The chart of accounts does not map: SKR03 and SKR04 have no Dutch counterpart, and the Steuerberater-owned ledger is less the norm here | Chart of accounts and tax codes rebuilt rather than translated; bookkeeping more often in-house |
| **Belgium** | Your parent is likely ahead, not behind: domestic B2B e-invoicing via Peppol has been mandatory in Belgium since January 2026, and is not yet mandatory here | The Dutch entity may need less than you assume today, and more once the Dutch B2B mandate lands |
| **France** | The Plan Comptable Général is prescriptive; Dutch practice is not, which reads as missing structure rather than freedom | Fewer imposed account codes, so your group needs its own mapping discipline |
| **United States** | VAT is not sales tax with a different name; it is a different mechanism, reclaimable and filed periodically. Fiscal years here are usually calendar years | A tax engine and filing calendar with no US analogue, and a possible reporting-period mismatch with the parent |
| **China** | Money movement is not frictionless, and there is no fapiao here: in the Netherlands the invoice you issue is the document, with no government-issued equivalent | Intercompany settlement needs planning, and the Dutch entity has no fapiao workflow to replicate |

## A note on the two that are furthest apart

**Coming from the US, the VAT gap is conceptual, not administrative.** Sales tax is charged at the end of the chain and is a cost to the buyer. VAT is charged at every step and reclaimed by businesses along the way, so your Dutch entity both collects and recovers it, and the return nets the two. Teams that treat it as "European sales tax" configure it as a tax rate and then cannot explain the balance sheet. It needs to be modelled as what it is.

**Coming from China, the fapiao habit is the thing to unlearn.** In China the fapiao is issued through the tax system and is what makes a transaction real. There is nothing equivalent here. A Dutch invoice is a document you produce yourself, and its validity rests on containing the required details, not on government issuance. Groups that run a Chinese ledger alongside a European one hit this from both sides, which we work through in [Chinese accounting in Odoo](/blog/chinese-accounting-odoo-localisation).

## What this means in the system

None of the above requires a separate Dutch system. It requires the one you have to hold two sets of rules at once.

- **Multiple companies in one database**, each with its own chart of accounts, tax regime, currency and reporting. The Dutch entity follows Dutch VAT while the parent follows its own.
- **The Dutch fiscal localisation**, which brings the chart of accounts and tax codes, so the VAT return and the ICP declaration come out of the transactions already in the system rather than a spreadsheet at quarter end.
- **Intercompany entries and consolidation**, so group reporting eliminates internal flows instead of double counting them.
- **Multiple currencies** where the parent does not report in euro.
- **Payroll connected, not forced.** Dutch payroll is limited in standard Odoo, so we connect a specialist and post the journals back. That is the honest arrangement rather than a claim we would have to walk back.

The decision that actually costs money if you get it wrong is not any of these settings. It is whether the Dutch ledger lives in the group system at all, or stays local with an accountant and gets connected. That choice deserves its own analysis, and it is the subject of [international accounting with Odoo](/blog/international-accounting-with-odoo).

## What we would tell you before you ask

Two things, in the spirit of [how we work](/what-we-do-differently).

If your Dutch entity is a small sales office with a handful of invoices a month, putting it in the group ERP may be more machinery than the problem deserves. A local bookkeeper and a periodic journal entry is sometimes the right answer, and we will say so.

And if the real problem is incorporation, residency, or which structure is most tax-efficient, we are the wrong party. Talk to a Dutch tax adviser first. Come back when the entity exists and the question becomes what your system has to do about it.

---

**Opening a Dutch entity and unsure what it does to your systems?** [Book a free Quickscan](/scan) and we will map your entities, filings and the connection strategy before anything gets configured.

---

**Read more:** [International accounting with Odoo](/blog/international-accounting-with-odoo) · [Chinese accounting in Odoo: l10n_cn, fapiao and Golden Tax](/blog/chinese-accounting-odoo-localisation) · [Odoo for international rollouts](/international-odoo-partner) · [Odoo hosting and data residency international](/blog/odoo-hosting-and-data-residency-international) · [What we do differently](/what-we-do-differently)


# Odoo Website or an alternative? Choose on findability, not on convenience
URL: https://www.fanatics.nl/blog/odoo-website-or-alternative
Language: en

**Short answer:** the Odoo Website app is a fine choice when your site mainly needs to be a neat extension of your backend: pages, a blog, forms that land straight in your CRM. But when **findability** is your growth channel - SEO, AEO (answer engines) and GEO (being cited by AI) - we currently advise a different route: a lightweight, lightning-fast site (we build on Astro) that unlocks parts of Odoo headless, with AI as the build accelerator. Not because Odoo falls short as a platform, but because the requirements for a findable site have fundamentally changed in two years. The site you are reading this on is the proof.

## Two kinds of websites, one wrong comparison

The question "Odoo Website or something else?" often goes wrong because two different things get mixed up:

1. **The site as a business card next to your operation.** A well-kept company site, directly connected to CRM, e-commerce and portal, maintained by the same people who work in Odoo. This is what the Odoo Website app was made for, and it is good at it: one environment, no integrations, drag-and-drop, and your [webshop](/blog/is-odoo-ecommerce-good-enough) comes with it.
2. **The site as a growth channel.** A site that has to beat competitors in search engines and AI answers, with dozens to hundreds of substantive pages, interactive tools, lead magnets and a technical foundation that crawlers and language models process effortlessly.

For the first kind, the question is basically already answered. This piece is about the second - because that is the question we get more and more.

## What findability demands today

Being found today no longer means optimising for ten blue links only. There are three layers:

- **SEO** - classic search results. Rewards speed (Core Web Vitals), clean structure and authority.
- **AEO** - answer engines: featured snippets, AI Overviews. Rewards pages that answer the question right at the top, with visible FAQs and FAQ schema.
- **GEO** - generative engines: being cited by ChatGPT, Gemini, Perplexity. Rewards clean, static HTML, complete structured data and content that genuinely answers one question per page.

All three reward the same technical profile: **lightweight, statically generated pages with full control over markup, metadata and structured data, in every language.** And that is exactly where every page builder strains - not just Odoo's, also WordPress with a plugin-heavy theme or a drag-and-drop SaaS. You gain convenience, but hand in control and speed.

## Our route: lightweight site, Odoo headless behind it

What we currently advise (and practise) for companies that want to win on findability:

- **A static, lightweight front-end** - we build on Astro: pages are generated as ready-made HTML at publish time, without heavy scripts. Load times in tenths of a second, perfect Core Web Vitals, and every page exactly as crawlers and language models prefer it.
- **Odoo unlocked headless where it adds value** - forms and chatbots create leads in your CRM via the API, calculators and configurators talk to your product data, customer portals show Odoo data. The operation stays in Odoo; the site is the fast front.
- **AI as the build accelerator** - this is what fundamentally changed the trade-off. A well-structured multilingual site with dozens of substantive pages, interactive tools and lead magnets was a months-long project two years ago. With AI support you build it in a fraction of that - and more importantly: you roll out new pages, tools and lead magnets **before your competitors have them**. Publishing speed has become a competitive advantage.
- **Claiming authority** - whoever publishes the best answer to their market's questions first becomes the answer AI cites. That position can be claimed now; in two years it will be taken.

This is not theory: the site you are reading is built this way. Over a thousand statically generated pages in three languages, FAQ and video schema on every relevant page, interactive tools as lead magnets, and forms that land straight in our own Odoo. How that approach became affordable is in [our piece on custom software in the AI era](/blog/custom-software-affordable-mid-market).

## When the Odoo Website app is simply the right choice

Fair is fair: for many companies the second route is overkill. Choose the Odoo Website app with confidence if:

- your site mainly exists to be there: who we are, what we do, contact;
- you have no content strategy (and no plan to start one);
- the biggest win for you is marketing and operations in one system;
- your webshop is the heart of the site and you [stay within the standard](/blog/is-odoo-ecommerce-good-enough).

The rule of thumb: **if your website is an extension of your operation, choose Odoo Website. If your website is your growth channel, build it as a growth channel.** And the two do not exclude each other: you can keep your operational portal and webshop in Odoo and put your findability site in front - they share the same backend.

## Frequently asked questions

**Is the Odoo Website app good enough for my company site?**
For a well-kept company site with forms straight into your CRM: yes. The limits appear once findability becomes your growth channel and speed, structured data and publishing pace become decisive.

**What is a headless website on Odoo?**
A separate, fast front-end (for example Astro) that talks to Odoo via APIs: forms become leads, product data comes from Odoo, portals show Odoo data.

**Why is site speed so important for SEO and AEO?**
Speed is a ranking factor, and light, static pages get crawled more often and more deeply - including by the AI crawlers that need to cite your content.

**What is the difference between SEO, AEO and GEO?**
SEO: being found in search results. AEO: being the direct answer in snippets and AI overviews. GEO: being cited by language models. All three reward fast pages with the answer up top and complete structured data.

**Do I lose the Odoo connection without the Odoo Website app?**
No: via the API, forms, chatbots and calculators create leads and orders directly in Odoo.

**Is a separate site not much more expensive?**
It used to be. AI has drastically lowered the build cost of a lightweight site - today the real cost is not being found.

---

**Curious what this approach would do for your findability?** [Book a free Odoo scan](/scan) - we look at your current site, your market and whether the Odoo Website app or the headless route fits your ambition. And we will say so plainly if the standard app is enough for you.

---

**Read more:** [WordPress alternative: the measurements](/wordpress-alternative) · [Is Odoo e-commerce good enough?](/blog/is-odoo-ecommerce-good-enough) · [Custom software became affordable](/blog/custom-software-affordable-mid-market) · [How many apps does Odoo have?](/blog/how-many-apps-does-odoo-have) · [The TARGET method](/target)


# Smart manufacturing and Industry 4.0: what it means, what it costs, and where to start
URL: https://www.fanatics.nl/blog/smart-manufacturing
Language: en

import OeeCalculator from '@fanatics-web/ui/OeeCalculator.astro';

**Short answer:** smart manufacturing is production that **measures itself, feeds that back, and adjusts**. That is the whole idea, and it is genuinely valuable. What makes the topic exhausting is that it arrives wrapped in a vocabulary built for conference keynotes: Industry 4.0, smart factory, IIoT, digital twin, dark factory, predictive everything. Underneath those words sits a ladder, and **almost everyone benefits from the bottom two rungs while almost nobody is ready for the top one**. This page sorts the terms, gives the ladder, and says plainly where the money is.

## The vocabulary, sorted

They are not synonyms, though they get used as if they were.

- **Industry 4.0.** German industrial-policy framing: the fourth industrial revolution, after steam, electricity and computing. Broad, political, and useful mostly as an umbrella.
- **Smart manufacturing.** The more operational term for the same shift. Production that senses, records, analyses and adapts.
- **Smart factory.** One connected site where those capabilities are actually in place. A place, not a philosophy.
- **IIoT (Industrial Internet of Things).** The plumbing: sensors, gateways and connectivity that get machine data out of the machine.
- **Digital twin.** A live virtual model of a machine, line or product, fed by real data, used to simulate before you commit in the real world.
- **Predictive maintenance.** Using machine data to intervene before something breaks, rather than on a schedule or after a failure.
- **Dark factory.** Production that runs unmanned. Real in a handful of industries, a thought experiment in most.

Notice that only the last three are technologies. The first four are framings, and framings do not have a price or a payback.

## The maturity ladder

The order matters more than the technology, because each rung is only worth what the rung below it supports.

1. **One system for the backbone.** Sales, purchasing, inventory, production and finance on one database. Unglamorous, and the precondition for everything else: without it you are analysing fragments.
2. **Digital reporting on the floor.** Operators record operations, quantities, scrap and quality as it happens instead of on paper. This is the [MES layer](/blog/what-is-a-mes), and it is where most mid-sized manufacturers get their largest single jump in insight.
3. **Measurement.** Now that reporting is reliable, real metrics become possible: OEE, downtime reasons, actual versus planned times feeding back into [job costing](/blog/job-costing-in-odoo) and planning.
4. **Machine connectivity.** Sensors and machine data where it pays: high-value machines, high-frequency processes, or measurements people cannot capture reliably by hand.
5. **Prediction and self-adjustment.** Predictive maintenance, digital twins, automated parameter adjustment. Genuine, and genuinely demanding in data and expertise.

**Most mid-sized manufacturers we meet are somewhere between rung one and two.** That is not a criticism; it is where the value is. The gap between "we find out next week" and "we know now" is worth more than the gap between "we know now" and "we predicted it".

## Measurement comes before intelligence: the OEE check

Rung three is the pivot, and OEE is the metric everyone reaches for. It is **availability x performance x quality**, and its real value is not the percentage but **which of the three is dragging you down**.

<OeeCalculator locale="en" />

Two things worth noticing. First, **the three factors multiply**, so 90% on each gives 73%, not 90%. That is why OEE feels harsh the first time you calculate it, and why the widely cited 85% is genuinely world class rather than a target you should expect to hit next quarter.

Second, if you set an ideal cycle time that is slower than the machine can actually run, performance climbs over 100% and your OEE flatters you. That is the single most common way these numbers get quietly wrong, which is a good preview of the honest part.

## Our opinion: most Industry 4.0 spend is a measurement problem wearing a technology costume

Our position, stated plainly, and consistent with what we say about [MES](/blog/mes-software) and [scheduling](/blog/production-planning-scheduling-software): the pattern repeats because the underlying mistake repeats.

Sensors are easy to buy and dashboards demo beautifully. Neither fixes the thing that actually limits most factories, which is that **nobody reliably records what happened**. Put a real-time dashboard on top of a floor where downtime gets logged when someone remembers, and you have built an expensive instrument for displaying guesses. Precisely, in colour, on a big screen.

Four positions we will defend:

- **A dashboard nobody acts on is a screensaver.** Before buying visibility, decide who will look at the number, how often, and what they are authorised to change. If there is no answer, the project is decoration.
- **Predictive maintenance is oversold to companies that have not tried preventive maintenance.** Prediction needs machine data over long periods and enough failures to learn from. Planned preventive maintenance with honest logging captures most of the benefit at a fraction of the cost. Start there; let the data tell you whether prediction is worth adding.
- **Digital twins are real, and rarely your next step.** They pay off in high-volume or high-risk process industries where simulating beats experimenting. For a jobbing shop with 200 different products a year, the modelling effort exceeds the benefit.
- **The most valuable Industry 4.0 project is usually boring.** Getting operators to report every operation the moment it happens, in two taps, is worth more than any sensor. It is also harder, because it is a people problem rather than a purchase.

And the one that costs us work: **if someone shows you an Industry 4.0 roadmap before asking how you currently record downtime, they are selling a category, not a solution.** We would rather implement rung one and two well and have you come back for rung four in two years than sell you all five now.

## What actually pays off, in order

If you want a practical shortlist for a mid-sized manufacturer:

- **Highest return:** digital reporting per operation, downtime reasons captured with a reason code, actual times flowing back into costing and planning.
- **Good return once the above works:** OEE per bottleneck machine (not per machine, just the constraint), quality checks recorded in-process rather than at the end.
- **Situational:** machine connectivity on high-value or high-frequency equipment, energy monitoring where energy is a real cost line, [automated storage integration](/blog/odoo-as-wms) where picking volume justifies it.
- **Later, if ever:** predictive maintenance, digital twins, autonomous scheduling.

That list is deliberately unexciting. It is also the sequence we have watched work.

## Where Odoo fits, and where it does not

In [Odoo](/odoo-erp), rungs one to three are covered directly: one database for the backbone, [Shop Floor](/blog/what-is-a-mes) for digital reporting, Quality for in-process checks, Maintenance for preventive maintenance, and the IoT box for connecting scanners, scales, printers and simple machine signals.

Where it stops, said plainly: **Odoo is not an Industry 4.0 platform.** OEE dashboards, high-frequency machine data historians, predictive models and digital twins are not standard functionality, and anyone telling you otherwise is describing a roadmap as if it were a feature. Those live in specialist tools that you connect to Odoo, with Odoo as the system of record.

We think that is the right division. Rungs one to three are where the returns are, and they are exactly the rungs that benefit from sitting on one database with your orders, stock and costs. Rungs four and five are specialist work, and pretending otherwise is how implementations disappoint. The categories and where each fits are mapped in [manufacturing software](/blog/manufacturing-software).

## Frequently asked questions

**What is smart manufacturing?**
Production that measures itself, feeds the data back and adjusts. A spectrum from reliable shop-floor capture through machine connectivity to prediction, not a single state.

**What is the difference between Industry 4.0 and smart manufacturing?**
Largely the same shift: Industry 4.0 is the German policy framing, smart manufacturing the operational term. Smart factory is a connected site, IIoT the sensor layer, digital twin a live virtual model.

**Where should a mid-sized manufacturer start?**
With reliable digital reporting on the floor, not with sensors. Backbone, then reporting, then measurement, then connectivity, then prediction.

**Is predictive maintenance worth it for a smaller manufacturer?**
Usually not first, sometimes not at all. Preventive maintenance with honest logging captures most of the benefit far more cheaply.

**What is OEE and why does it matter?**
Availability times performance times quality. It is usually the first genuinely useful factory metric, and it exposes which factor costs you most, provided the underlying data is honest.

---

**Want to know which rung you are actually on?** [Book a free Odoo scan](/scan) - we look at how you record production today and tell you honestly which step pays off next, and which ones you can safely ignore for now.

---

**Read more:** [Manufacturing software: the categories](/blog/manufacturing-software) · [What is a MES?](/blog/what-is-a-mes) · [MES software: how to choose](/blog/mes-software) · [Production planning and scheduling](/blog/production-planning-scheduling-software) · [MRP system explained](/blog/mrp-system) · [Odoo for manufacturers](/industries/manufacturing)


# How many apps does Odoo have, and which are they? (2026)
URL: https://www.fanatics.nl/blog/how-many-apps-does-odoo-have
Language: en

**Short answer:** it depends on what you count. **Odoo itself ships 78 official apps**, counted in the Apps menu of a current Odoo database (checked July 2026), spread over 13 categories. The **Odoo App Store** (apps.odoo.com) contains far more: **over 80,000 apps and modules** in total, combining Odoo's own apps, paid partner apps and free community modules across all versions. As of July 2026 the store reports roughly **80,800**. If you have read that Odoo has "40,000 community modules", that figure is simply out of date, the ecosystem has roughly doubled.

## The three numbers people mix up

Most confusion about "how many apps does Odoo have" comes from conflating three different things.

1. **Official Odoo apps (78).** These are the apps Odoo builds and maintains itself, the tiles in the Apps menu. This is the number that matters for "what can Odoo do out of the box".
2. **The Odoo App Store total (80,000+).** Everything published on apps.odoo.com: official apps, paid apps from Odoo partners, and free community modules, across every supported version. As of July 2026: ~80,800. This is the number that shows how large the ecosystem is.
3. **What you actually install (a handful).** The apps that map to your real processes. For a mid-sized company that is usually somewhere between five and fifteen.

Quoting the wrong one of these leads to nonsense, either "Odoo only has a few dozen apps" (true only for the official core) or "you get 80,000 apps" (true only for the store total, most of which you will never touch).

## Which apps does Odoo have? The list by category

This is what most people are actually after, and here it comes from the only source that settles it: **an Odoo database itself.** We opened Odoo's public demo (Odoo Online, checked 29 July 2026), filtered the Apps menu on apps, and counted. The result is **78 official apps** across **13 categories**:

| Category | Apps | Examples |
| --- | --- | --- |
| **Human Resources** | 15 | Employees, Recruitment, Time Off, Appraisals, Referral, Fleet, Payroll, Attendances, Frontdesk, Lunch |
| **Sales** | 11 | CRM, Sales, Point of Sale, Restaurant, Subscriptions, Rental, Invoicing |
| **Shipping Connectors** | 10 | DHL Express, UPS, FedEx, Envia, Starshipit, Lazada Connector |
| **Productivity** | 9 | Discuss, Documents, Knowledge, Sign, Approvals, WhatsApp Messaging, Meeting Rooms, Data Recycle, AI |
| **Supply Chain** | 8 | Inventory, Purchase, Manufacturing, Maintenance, Quality, PLM, Barcode, Repairs |
| **Marketing** | 7 | Email Marketing, Marketing Automation, SMS Marketing, Social Marketing, Events, Survey, Marketing Card |
| **Website** | 5 | Website, eCommerce, Blog, Forum, eLearning |
| **Services** | 5 | Project, Timesheets, Field Service, Helpdesk, Planning |
| **Accounting** | 3 | Accounting, Expenses, Equity |
| **Administration** | 2 | Databases, Obox (Odoo IoT management) |
| **ESG** | 1 | ESG |
| **Customizations** | 1 | Studio |
| **Technical** | 1 | (technical modules) |

That is the real answer, and it explains why so many published lists look incomplete. Two categories in particular rarely make anyone's overview: **Shipping Connectors** (ten carrier integrations, a full eighth of the total) and the long tail of **HR apps** (fifteen, more than any other category).

### Why sources disagree on the number

You will find "40 apps", "60 apps" and "80 apps" all presented as fact, sometimes by the same AI assistant on different days. Here is what each figure is actually counting:

- **~40** is **out of date**. It was roughly right several versions ago and gets repeated by sources that never rechecked. If a tool tells you this today, treat the rest of its answer with the same suspicion.
- **~60** is the **marketing grid**: the headline apps on Odoo's public all-apps page, grouped into nine categories. It leaves out the shipping connectors and much of the HR tail.
- **78** is **what the software actually shows**: the Apps menu in a current Odoo database, in the thirteen categories above. This is the number we would defend.

So the honest answer to "how many apps does Odoo have" is **78 as of July 2026**, with two caveats worth stating: the count moves with each release, and availability differs between Community and Enterprise, so your own Apps menu may be shorter.

## App or module: what is the difference?

The terms overlap, which is why the counts get used interchangeably.

- A **module** is a package of code that adds functionality to Odoo.
- An **app** is usually a larger, headline module that shows up as a tile in the Apps menu (Sales, Inventory, Accounting). Smaller technical modules extend or connect those apps behind the scenes.

The App Store lists both under a single "Apps found" counter, so when a source says "80,000 apps" and another says "80,000 modules", they are pointing at the same store total.

## Free or paid?

The store total is **not** a count of free software. It is a mix:

- **Community modules** are open-source and free to download.
- **Official Odoo apps** are included in your Odoo subscription (Standard or Custom).
- **Partner apps** in the store are often **paid** one-off purchases, built by third parties.

So "80,000+ apps" says nothing about price. It says the ecosystem is deep, in both free and commercial directions.

## Community versus Enterprise

One more distinction shapes what is available to you. Odoo comes in two editions:

- **Community**, the free, open-source edition.
- **Enterprise / Standard / Custom**, the paid editions with the full set of official apps, mobile, studio, and support.

Community modules from the store work on the Community edition; many official apps and partner apps target the paid editions. The right edition is a fit question, not a "more is better" one, which brings us to the number that actually matters.

## The number that actually matters

Here is the honest part. **You do not implement 80 apps, let alone 80,000.** A large ecosystem is a sign of health, not a to-do list. The work of a good implementation is the opposite of maximising app count: it is **curation**, choosing the few apps that match the processes you actually run, and configuring them so they work as one system.

We see it on every project. A company does not need "an app for everything"; it needs the right handful, set up well, on one database, so that a quote flows into an order, into production, into an invoice, into the [cost price](/blog/cost-price-calculation) and back. Ten apps that fit beat forty that half-fit.

So when someone asks "how many apps does Odoo have", the useful follow-up is: *which ones do you actually need?* That is a much shorter list, and it is the list worth spending time on.

## Frequently asked questions

**How many apps does Odoo have?**
78, counted in the Apps menu of a current Odoo database in July 2026, across 13 categories. The App Store separately lists over 80,000 apps and modules (Odoo, partners and community combined), roughly 80,800.

**What is the difference between an Odoo app and a module?**
A module is any code package that adds functionality; an app is a larger, headline module shown as a tile in the Apps menu. The store counts both together.

**How many modules are in the Odoo App Store?**
More than 80,000. Older "40,000" figures are out of date; the ecosystem has roughly doubled.

**Are Odoo apps free?**
A mix. Community modules are free; official apps come with a subscription; many partner apps are paid.

**How many Odoo apps do you actually need?**
Usually a handful to a dozen, the ones that fit your real processes. Curation, not quantity, is the point.

---

**Not sure which Odoo apps fit your business?** [Book a free Odoo scan](/scan) - we go through your processes and tell you honestly which handful of apps you need, and which you can skip.

---

**Read more:** [What is Odoo?](/what-is-odoo) · [What is a MES?](/blog/what-is-a-mes) · [Odoo as a WMS](/blog/odoo-as-wms) · [Odoo ERP overview](/odoo-erp) · [Compare Odoo](/compare) · [Pricing & implementation calculator](/pricing/calculator)


# Manufacturing software: the categories explained, and which ones you actually need
URL: https://www.fanatics.nl/blog/manufacturing-software
Language: en

**Short answer:** "manufacturing software" is not a product, it is **eight overlapping categories** that vendors happily describe using each other's vocabulary. The backbone is **ERP**; around it sit **MRP** (materials), **APS** (capacity and sequence), **MES** (shop-floor execution), **WMS** (warehouse), **QMS** (quality), **PLM** (product data and revisions) and **CAD/CAM** (design and machine programming). Most bad software decisions in manufacturing come from buying one category while the problem lives in another. This page maps them, then answers the question underneath: **which do you actually need?**

## The eight categories, mapped

| Category | Answers | Does not do | You need it when |
| --- | --- | --- | --- |
| **ERP** | How is the business doing? Orders, purchasing, stock, finance | Real-time shop-floor control, machine data | Almost always: it is the backbone |
| **MRP** | What do we make and order, how much, by when? | Say whether the hours exist | You make to order or stock with bills of materials |
| **APS / scheduling** | When does this job run, on which machine, in what order? | Manage materials or money | A work centre is a genuine bottleneck |
| **MES** | What is happening on the floor right now? | Plan ahead, run your books | The floor is a black box after the fact |
| **WMS** | Where is stock and how do we pick it fastest? | Produce anything | Warehousing itself is complex or automated |
| **QMS** | Is it good, and can we prove it? | Run production | Regulated industries, audits, recalls |
| **PLM** | Which version of the product is current, and who approved it? | Execute production | Frequent revisions, engineered products |
| **CAD/CAM** | What does it look like and how does the machine cut it? | Anything commercial | You design and machine your own parts |

Read that table once and most vendor conversations become easier to parse. When someone pitches a "complete manufacturing solution", the useful question is: *which of these eight are you, and which do you assume I already have?*

## Where the categories genuinely overlap

The boundaries are not clean, and pretending otherwise helps nobody.

- **ERP and MRP.** In modern software MRP is a module of the ERP, not a separate system. A standalone MRP tool means maintaining master data twice. Detail on the [MRP system page](/blog/mrp-system).
- **MRP and APS.** MRP plans materials, APS plans capacity. MRP II already includes a capacity layer, which is why many companies never need separate APS. See [production planning and scheduling](/blog/production-planning-scheduling-software).
- **ERP and MES.** Modern ERPs ship a shop-floor app that covers the MES role for people-driven production. See [what is a MES](/blog/what-is-a-mes) and, if you are choosing, [MES software](/blog/mes-software).
- **ERP and WMS.** ERP inventory modules have absorbed most WMS functionality: putaway, removal strategies, barcode, lots. See [Odoo as a WMS](/blog/odoo-as-wms).
- **QMS inside ERP.** Quality control points during operations are standard in most manufacturing ERPs; standalone QMS is about documentation and compliance depth.

The pattern is consistent: **ERP has absorbed the mainstream of most categories.** What remains genuinely specialist is the deep end of each: machine-level MES, sequence-optimising APS, automated-warehouse WMS, revision-controlled PLM.

## Which do you actually need?

An honest sequence, from most to least commonly justified.

1. **ERP with manufacturing.** Nearly everyone. This is the backbone and everything else assumes it.
2. **Shop-floor reporting** (the MES role, usually an ERP module). Almost everyone benefits, because without it your costing and planning run on estimates.
3. **Quality**, where your industry or customers demand proof.
4. **Capacity scheduling**, once a work centre is a real bottleneck rather than an occasional one.
5. **PLM**, when product revisions are frequent and getting the wrong version to the floor is a real risk.
6. **Separate MES**, with deep machine or PLC integration, or validated production.
7. **Separate WMS**, with high-throughput automated warehousing.
8. **Separate APS**, with sequence-dependent setups across many constrained resources.

Most mid-sized manufacturers land on the first three or four. If you find yourself shortlisting items 6, 7 and 8 simultaneously, that is worth a second look: it usually means the backbone is not doing its job, and adding specialists around a weak core rarely ends well.

## Our opinion: the integration bill is always larger than the quote

Where we stand, stated plainly. We implement Odoo, so we have an interest here; the argument should stand on its own anyway.

Best-of-breed is genuinely appealing. Each tool is better at its job than the equivalent ERP module, and the demos prove it. What the demos never show is the **space between the systems**: the nightly synchronisation, the master data maintained twice, the item that exists in three places with three slightly different descriptions, and the meeting where planning and the floor argue about which system is right instead of about the delivery date.

Three positions:

- **Integration is not a phase, it is a permanent cost.** Every connection needs maintenance, breaks on upgrades, and needs someone who understands both sides. Count it as a recurring line, not a project.
- **For mid-sized manufacturers, shared data beats functional depth.** The last 15% of MES or WMS functionality is worth less than every department working from the same numbers. Above a certain scale that flips, and you should be honest about which side you are on.
- **Best-of-breed is a legitimate choice for exactly one thing.** Pick the process that genuinely is your core complexity, buy the specialist for that, and run everything else on the backbone. Companies that pick specialists for three categories at once are usually buying tools to avoid a decision.

The uncomfortable version: **most "we need better manufacturing software" problems are master-data problems**. Wrong bills of materials, routing times nobody measured, lead times entered once at go-live. New software makes those visible faster, which feels like progress, but the fix is the data. Any vendor who does not ask about your master data before quoting is selling licences, not outcomes.

## Manufacturing software in Odoo

For completeness, since it is the stack we know best: [Odoo](/odoo-erp) covers ERP, MRP, capacity scheduling, shop-floor execution, warehouse, quality and maintenance as apps on one database, with PLM and CAD/CAM as the honest gaps at the deep end. What that means practically, per category, is spread across the pages linked above, and we describe how we run these projects in the [TARGET method](/target).

What we would not claim: that it is the strongest tool in every category. It is not, and this page would be worthless if it pretended otherwise. What it is: one database where a quote becomes an order, a manufacturing order, a picked shipment, an invoice and a [cost price](/blog/cost-price-calculation) without a single integration in between. For most mid-sized manufacturers, that is the trade worth making.

If you want the industry view rather than the software view, start at [Odoo for manufacturers](/industries/manufacturing).

## Frequently asked questions

**What is manufacturing software?**
An umbrella term for eight overlapping categories: ERP, MRP, APS, MES, WMS, QMS, PLM and CAD/CAM. Not a single product.

**What is the difference between ERP and manufacturing software?**
ERP is one category within it, usually the backbone. All manufacturing ERP is manufacturing software; not all manufacturing software is ERP.

**Which manufacturing software does a mid-sized manufacturer need?**
Usually an integrated ERP with manufacturing, inventory and shop-floor reporting, plus quality where required. Specialist systems need a specific trigger.

**Is one integrated system better than best-of-breed?**
Neither universally. One system wins on shared data and no integration projects; best-of-breed wins where one process is genuinely your core complexity.

**How much does manufacturing software cost?**
The licence is rarely decisive. Count implementation, data migration, integration, shop-floor hardware, training and annual maintenance. Best-of-breed stacks cost more than the sum of their licences.

---

**Want to know which categories you actually need?** [Book a free Odoo scan](/scan) - we map your processes against these categories and tell you honestly which ones you need now, which can wait, and which you do not need at all.

---

**Read more:** [Smart manufacturing and Industry 4.0](/blog/smart-manufacturing) · [MRP system explained](/blog/mrp-system) · [Production planning and scheduling](/blog/production-planning-scheduling-software) · [What is a MES?](/blog/what-is-a-mes) · [MES software: how to choose](/blog/mes-software) · [MES vs MRP vs ERP](/blog/mes-vs-mrp-vs-erp) · [Odoo as a WMS](/blog/odoo-as-wms) · [Odoo for manufacturers](/industries/manufacturing)


# Subscription management software: dedicated tool or inside your ERP?
URL: https://www.fanatics.nl/blog/subscription-management-software
Language: en

**Short answer:** if you invoice on a recurring basis - rentals, service contracts, subscriptions, advertising screens, coffee on contract - you do not need a separate subscription tool next to your accounting. Odoo Subscriptions turns a sales order into a running contract that invoices itself, collects itself and keeps its own steering metrics (MRR, churn), in the same environment as your CRM, your inventory and your general ledger. Below: how that works, and honestly, when a specialised tool is the better choice.

## The problem with recurring revenue in separate tools

Recurring revenue sounds administratively simple - the same amount, every month - but in practice it is exactly where separate tools get in each other's way. The contract lives in a CRM or a spreadsheet, invoices come from an invoicing package or a subscription tool, payment runs through a payment provider, and the books receive the result via an export. Every link is a place where a cancellation does not come through, a price indexation gets missed, or a customer keeps paying for something that was already stopped - or the reverse.

We regularly see the pattern with companies that come to us: a healthy business with hundreds of running contracts, and nobody who can say with certainty which contracts are active, what will be invoiced next month and what the true monthly revenue is. Not out of sloppiness, but because that truth is spread across four systems.

## How it works in Odoo: the contract is the administration

Odoo Subscriptions turns it around. A subscription is not a loose record in a separate tool but a sales order with a repeat rhythm:

- **Contract = sales order.** Term, notice period, periodic amount, one-off setup fees and usage-based lines (per screen, per location, per user) sit in one document.
- **Invoicing runs by itself.** Per month, quarter or year the invoice is created and sent, with direct debit or card payment via your payment provider. Failed payments get automatic reminders (dunning).
- **The books are not a copy but the source.** The invoice sits directly in your general ledger; VAT and revenue are correct without synchronisation. Your accountant looks at the same numbers as your sales team.
- **Changes settle themselves.** Upgrade halfway through the month? Settled pro rata. Indexation per 1 January? A pricelist change, not manual work per contract.
- **Steering metrics from the same data.** MRR, ARR, churn and revenue per plan come from the invoicing itself - the dashboard cannot deviate from the books, because it *is* the books.

And because it sits in Odoo, it does not stop at the invoice. A company that places screens, machines or equipment on contract attaches to that same contract the delivered hardware (serial numbers, inventory), the installation appointment (Field Service) and the incident tickets (Helpdesk). Per customer you see the complete picture: what is installed, what is going on, what it costs and what it earns.

## Who this makes the difference for

Recurring revenue stopped being a software-only model long ago. We see it at more and more companies:

- **Equipment on site**: advertising screens, coffee machines, charging stations, climate systems - hardware plus service plus periodic invoicing
- **Service contracts**: maintenance, SLAs, inspections on a fixed rhythm
- **Consumption subscriptions**: coffee, consumables, stock replenishment on contract
- **Digital services**: SaaS, portals, licences

The common thread: the subscription is never just an invoice. There is a delivery attached, service, hardware, a customer relationship. That is exactly why a standalone subscription tool grates: it only knows the invoice side.

## Honestly: when a specialised tool wins

Odoo Subscriptions is not the best choice for everyone. If you run high-volume consumer SaaS with tens of thousands of self-onboarding users, per-country price experiments, paywall A/B tests and optimised dunning flows, specialised platforms like Chargebee, Recurly or Stripe Billing are more mature there. That segment needs the depth and accepts the accounting integration as the price.

For most companies - tens to thousands of business contracts, often with hardware or service attached - it is the other way round: the win is not in price experiments but in one administration, and then the integrated route is almost always stronger. Unsure which profile you are: that is exactly a question for a [fit-gap up front](/target).

## Frequently asked questions

**What is subscription management software?**
Software that manages recurring contracts: term, periodic invoicing, price changes, cancellations and metrics such as MRR and churn. As a standalone tool, or as a module inside your ERP such as Odoo Subscriptions.

**Can Odoo send recurring invoices automatically?**
Yes, per month, quarter or year, including direct debit or card payment and reminders on failed payments. The invoice sits directly in your own accounting.

**Can I combine different subscription models?**
Yes: fixed amounts, tiers, usage-based invoicing, setup fees and mid-term changes with pro rata settlement.

**Does Odoo track MRR and churn?**
Yes, from the same data as the invoicing - so the dashboard cannot contradict the books.

**When is a dedicated subscription tool better?**
For high-volume consumer SaaS with complex price experiments. For business contracts, certainly with hardware or service attached, the integrated route almost always wins.

**Can I combine service and hardware with a subscription?**
Yes: the same contract can cover hardware (serial numbers), installation (Field Service) and service tickets (Helpdesk).

---

**Hundreds of running contracts and no sharp view of your monthly revenue?** [Book a free Odoo scan](/scan) - we look at your contract types, your invoicing rhythm and what it takes to get everything into one environment.

---

**Read more:** [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost) · [Odoo directly or via a partner?](/blog/odoo-direct-or-via-a-partner) · [The TARGET method](/target) · [Odoo for field services](/industries/field-services)


# Production scheduling software: capacity, sequence, and the hours you do not have
URL: https://www.fanatics.nl/blog/production-planning-scheduling-software
Language: en

import CapacityPlanningCalculator from '@fanatics-web/ui/CapacityPlanningCalculator.astro';

**Short answer:** planning and scheduling are two different jobs that get sold as one. **Planning** decides *what* to make and order, and roughly when, working in weeks and days. **Scheduling** decides *when a specific job runs, on which machine, in what order*, working in hours and minutes. Planning is mostly the [MRP calculation](/blog/mrp-system) on materials; scheduling is about **capacity and sequence**. Confusing them is why companies buy planning software and still miss delivery dates: they solved the material question and left the hours question untouched.

## Planning and scheduling: the division of labour

| | **Planning** | **Scheduling** |
| --- | --- | --- |
| **Answers** | What do we make and order, roughly when? | When does this job run, on which machine, in what order? |
| **Unit of time** | Weeks and days | Hours and minutes |
| **Constraint** | Materials and lead times | Capacity, setups, sequence |
| **Output** | Purchase and manufacturing orders | A sequence per work centre |
| **Breaks when** | Bills of materials or lead times are wrong | Routing and setup times are wrong |

You need them in that order. Scheduling a plan with no materials behind it produces a beautiful sequence for jobs that cannot start. But planning without scheduling gives you order dates and no idea whether the shop can actually deliver them, which is exactly where the trouble usually is.

## Finite versus infinite capacity

The single most useful distinction in this market, and the one vendors are vaguest about.

- **Infinite capacity scheduling** assumes a work centre absorbs whatever you throw at it. Jobs get placed on the date they are needed, regardless of whether the hours exist. Simple, fast, and honest enough when you have slack.
- **Finite capacity scheduling** respects the real hours per work centre. When capacity runs out, work moves forward or backward and the promise date changes. Harder, slower, and the only version that tells you the truth once something is a bottleneck.

Most ERP systems schedule finitely against work centre capacity. Most spreadsheets schedule infinitely, which is why the spreadsheet always says the date is fine.

## The check most planning articles skip

Before comparing tools, check whether the hours exist at all. Enter one work centre and see.

<CapacityPlanningCalculator locale="en" />

Notice the band boundaries, and note that they are not arbitrary. Somewhere around **85% utilisation, queues start growing sharply**, and past roughly 95% they explode. This is queueing behaviour, not pessimism: as a resource approaches full load, every disturbance (a breakdown, a rush order, an operator off sick) has nowhere to go, so it turns straight into delay.

Which leads to the most useful sentence on this page: **planning a bottleneck at 100% utilisation is planning to be late.** Software cannot fix that. Only capacity, outsourcing, or a different promise date can.

## Our opinion: most scheduling problems are measurement problems

We will be direct, because this is where the money is wasted.

When a manufacturer tells us their scheduling is a mess, we ask one question first: **when did you last measure a routing time?** The answer is usually a variation of "those came over from the old system" or "someone estimated them at go-live". Everything downstream then inherits that guess. The schedule looks precise to the minute and is wrong by hours, and no tool can out-calculate wrong input.

Three positions we will defend:

- **Setup times are the most underestimated number in manufacturing.** They rarely appear in routings at full length, and in small-batch production they can outweigh run time entirely. If your schedule ignores changeovers, it is fiction with a Gantt chart on top.
- **A perfect schedule that nobody follows is worth less than a rough one everybody follows.** Shop-floor adoption beats algorithmic quality almost every time. If the plan lives on a screen the operators do not look at, you do not have a schedule, you have an opinion.
- **If you are firefighting daily, more scheduling detail will not help.** Finer planning on an overloaded shop produces a more precise account of why you are late. Fix the load first.

And the one that costs us: **a large share of "we need scheduling software" conversations should end in "measure your routings and setups for a quarter first"**. That is unglamorous, it does not need a purchase order, and it fixes more delivery reliability than most implementations do.

## Choosing production scheduling software

You will see this sold under several names: production scheduling software, manufacturing scheduling software, finite capacity scheduling, or APS. The labels overlap almost entirely and the differences are largely marketing, so do not let a vendor talk you into a category. What actually separates the tools is the list below.

Once you genuinely need a tool, these are what matter:

- **Finite capacity, honestly implemented.** Ask specifically how the tool behaves when capacity runs out. Does it move the date, or quietly overload the work centre?
- **Setup and sequence handling.** Can it model sequence-dependent setups (colour changes, material changes) where the order of jobs changes total setup time? This is the main reason to look beyond an ERP scheduler.
- **Rescheduling behaviour.** Real shops change hourly. How fast and how disruptively does the plan respond, and can planners lock or protect jobs?
- **Shop-floor visibility.** The schedule has to be visible where the work happens, or it is not real. This is where scheduling meets [MES](/blog/what-is-a-mes).
- **Integration with your ERP.** Scheduling needs routings, orders and stock. Separate tools need those synchronised, which is a project of its own.
- **Planner trust.** Can a planner see why the tool put a job there, and override it without breaking everything? An optimiser nobody trusts gets bypassed within weeks.

### When your ERP already covers it

Be honest here, because it saves real money. If your ERP schedules manufacturing orders against work centre capacity, shows load per work centre, handles routing and setup times, and reschedules when things move, you have what most mid-sized manufacturers need.

Separate **APS** (Advanced Planning and Scheduling) software earns its place with sequence-dependent setups, many shared and constrained resources, or genuine optimisation across scenarios. That is a real category with real value, and it is a smaller group of companies than the marketing suggests.

## Planning and scheduling in Odoo

In [Odoo](/odoo-erp), both layers sit in Manufacturing on the same database as sales, purchasing and inventory:

- **Material planning** through the MRP run and reordering rules, covered in depth on the [MRP system page](/blog/mrp-system).
- **Work centres with capacity**, including operating hours, efficiency and time before and after production.
- **Routings with operation and setup times**, so a manufacturing order occupies real hours rather than an assumption.
- **Scheduling against capacity** with a planning view and work centre load, so overload becomes visible instead of arriving as a surprise.
- **Rescheduling** when orders move, with the consequences flowing through to delivery dates.
- **Execution feedback** via [Shop Floor](/blog/what-is-a-mes), so the actual times land back in the system and your next schedule uses measured numbers instead of estimates.

That last point matters more than any scheduling feature: a closed loop between plan and reality is what makes routings accurate over time. That is also why we keep returning to the same advice, in [job costing](/blog/job-costing-in-odoo) as much as here: measure, then plan.

## Frequently asked questions

**What is the difference between production planning and scheduling?**
Planning decides what to make and order and roughly when (weeks and days); scheduling decides when a job runs, on which machine and in what order (hours and minutes).

**What is finite versus infinite capacity scheduling?**
Infinite ignores available hours and places jobs on the needed date; finite respects real capacity and moves work when hours run out. Finite is what you need once something is a bottleneck.

**Do I need separate production scheduling software?**
Often not. A modern ERP scheduling against work centre capacity covers most mid-sized manufacturers. APS earns its place with sequence-dependent setups and many constrained resources.

**Why do delivery dates slip even with planning software?**
Mostly utilisation and measurement: queues grow sharply above about 85% load, and routing and setup times are often estimates rather than measurements.

**Can Odoo do production planning and scheduling?**
Yes, via MRP for materials and work centre capacity scheduling with routings, setup times and a planning view. For sequence-dependent optimisation, an APS tool alongside Odoo remains stronger.

---

**Not sure whether your problem is scheduling, capacity, or measurement?** [Book a free Odoo scan](/scan) - we look at your routings, setup times and work centre load, and tell you honestly which of the three you are dealing with.

---

**Read more:** [MRP system explained](/blog/mrp-system) · [What is a MES?](/blog/what-is-a-mes) · [MES vs MRP vs ERP](/blog/mes-vs-mrp-vs-erp) · [Manufacturing software: the categories](/blog/manufacturing-software) · [Odoo for manufacturers](/industries/manufacturing) · [The TARGET method](/target)


# Warehouse management software: can Odoo handle your warehouse?
URL: https://www.fanatics.nl/blog/odoo-as-wms
Language: en

**Short answer:** yes, largely. Odoo has a real WMS core, not an inventory list that gets called a "warehouse". Barcode scanning, putaway rules, storage categories, removal strategies such as FIFO and FEFO, reordering rules, multi-step routes and lot and shelf-life tracing are standard in the Inventory and Barcode apps. For by far the most SME warehouses that is enough. Where it stops: extremely high throughput with physical automation (automated cranes, sorting lanes, voice picking). That is where a dedicated WMS still wins. Below is an honest breakdown, per component, of what [Odoo](/odoo-erp) does as a warehouse system, with examples from two very different warehouses.

## What Odoo's warehouse does out of the box

A warehouse system stands or falls on a handful of functions. This is what Odoo offers as standard.

- **Barcode scanning.** The Barcode app runs on a phone, tablet or handheld scanner and covers receipts, internal transfers, picking, packing and counting. You scan location and product, and Odoo books the movement immediately.
- **Putaway rules (inbound).** Automatically determine where an incoming product is stored: based on product, product category or packaging, to a fixed zone or location.
- **Storage categories.** Group locations by property (refrigeration, hazardous materials, size) and steer putaway accordingly. That way every product lands in a suitable spot without the warehouse operator having to know it by heart.
- **Removal strategies (outbound).** Per location or category you choose FIFO, LIFO, FEFO (by shelf life) or closest location. When picking, Odoo automatically proposes the right batch.
- **Reordering rules.** Min and max levels with automatic purchase or manufacturing orders, and the reordering rules per location.
- **Multi-step routes.** Receipts and deliveries in one, two or three steps (for example receipt -> quality control -> storage), plus push and pull rules for cross-docking and dropshipping.
- **Batch and wave picking.** Pick multiple orders together in an efficient walking route.
- **Lot, serial number and shelf-life tracing.** Full traceability through the chain, with best-before dates and recall reports.

That is not a light version. It is a WMS that is more than enough for most companies, with the big advantage that it sits on the same database as your purchasing, sales, manufacturing and accounting, so that a [cost price](/blog/cost-price-calculation) or [job costing](/blog/job-costing-in-odoo) is correct right away.

## Two warehouses, two emphases

What "a good warehouse" means differs strongly per company. Two real-world examples show which Odoo functions are then decisive.

**A finishing and coating company.** Here it is all about precise **storage categories and packaging types**: products have to land in the right zone, and every operation is closed off with a printed **label** from a Zebra printer. The setup lives in putaway rules, a tight category structure and label printing at the right workstations, plus production processes across multiple machines. Odoo's putaway plus barcode plus ZPL label printing covers that without an external WMS.

**A fresh-produce grower (sprouts).** Here the clock is boss: a cultivation process of five to ten days, last-minute orders from wholesalers and supermarkets, and products with a short shelf life. Decisive are **FEFO** (the batch that expires first goes out first), **lot and best-before registration** and fast, error-free picking under time pressure. Odoo's removal strategies and shelf-life tracing are made for this.

Two totally different warehouses, both within standard Odoo, because the building blocks (putaway, categories, removal strategies, barcode, tracing) are broad enough.

## And when there are machines in the warehouse: the lift integration at Rhea Vendors

The section above says Odoo is strong for warehouses that run on people with scanners. That is true, but it is not the whole story, and leaving it there would be unfair.

At [Rhea Vendors](/cases/rhea-vendors-groep-en), a manufacturer of professional coffee and drinks machines, we built an integration for the German site (Servomat) with **two [Apfel](https://apfel-gmbh.de/) storage lift systems** (the LTL and LTK series): automated vertical units holding components and subassemblies. It works like this: a warehouse operator picks in the **Odoo Barcode app**, and the system automatically brings the right shelf forward. The operator does not walk to the stock, the stock comes to the operator.

That is classic **goods-to-person**, the principle modern warehouse automation is built on, and here it runs on Odoo with a custom integration. The same implementation covers 40 users, full manufacturing, quality management and label printing.

What this means for the question "can Odoo handle automation": **the boundary sits in a different place than most people assume**. Integrating an automated storage system with Odoo is very achievable, and that is exactly the type of automation SME warehouses invest in first. What stays hard is something else: a warehouse where the *control itself* sits with the machines, with sorting installations, crane control and PLC logic making decisions at sub-second resolution. Steering a lift from a pick instruction is a different discipline from that.

Read how that three-country rollout went in the [Rhea Vendors case](/cases/rhea-vendors-groep-en).

## Odoo WMS versus a dedicated WMS

Where is the boundary? This table is honest, not promotional.

| Aspect | Odoo Inventory/Barcode | Dedicated WMS |
| --- | --- | --- |
| Barcode scanning, putaway, removal strategies | Yes, standard | Yes |
| Lot/serial, FEFO, shelf life, traceability | Yes, standard | Yes |
| Reordering rules, multi-step routes, batch/wave picking | Yes, standard | Yes, often more fine-grained |
| Integration with purchasing, sales, production, accounting | Yes, one database | Integration needed |
| Very high throughput (thousands of lines/hour) | Up to a point | Stronger |
| Integration with storage lifts and goods-to-person | Yes, via custom integration (see Rhea Vendors) | Yes, more often standard |
| Heavy physical automation (cranes, sorting lanes, pick-to-light, voice) | Limited | Core strength |
| Dynamic slotting, real-time wave optimisation | Basic | Advanced |

The rule of thumb: **if your warehouse runs on people with scanners, Odoo is almost always enough, even when machines assist them. If your warehouse runs on machines that drive, sort and decide by themselves, you want a specialised WMS**, preferably coupled to Odoo for the administration. Most wholesalers, manufacturers and fulfilment operations in the SME segment fall into the first category, and as the lift integration below shows, that category does not exclude automation at all.

## What to watch out for when choosing

- **Calculate your throughput honestly.** Not the number of orders per day, but the peak per hour. Below a few hundred order lines per hour, Odoo is rarely the bottleneck.
- **Look at your automation ambition.** Do you want automated cranes or voice picking within three years? Factor that in now.
- **Weigh the integration gain.** A separate WMS is almost always functionally richer at the warehouse level, but you pay with an integration and duplicate master data. A database that covers your entire chain is often worth more for an SME than the last 10% of WMS refinement.

## Frequently asked questions

**Is Odoo a full WMS?**
Yes, for most SME warehouses: barcode, putaway, storage categories, FIFO/FEFO, reordering rules, multi-step routes, batch/wave picking and lot and best-before tracing are standard in the Inventory and Barcode apps. For extreme throughput with physical automation, a dedicated WMS remains stronger.

**Does Odoo have barcode scanning?**
Yes, the Barcode app on a phone, tablet or handheld scanner covers receipts, transfers, picking, packing and counting. You print labels from Odoo, including to Zebra via ZPL.

**Does Odoo support FIFO and FEFO for shelf life?**
Yes, via removal strategies per location or category, combined with lot and best-before registration for fresh produce.

**When do you need a separate WMS alongside Odoo?**
With very high throughput and physical automation (cranes, sorting lanes, voice picking) or WMS-specific optimisations such as dynamic slotting. Then you couple a dedicated WMS to Odoo.

**Can Odoo track lot and serial numbers for traceability?**
Yes, through the entire chain from receipt to delivery, with best-before dates and recall reports.

---

**Not sure whether Odoo can handle your warehouse?** [Book a free Odoo scan](/scan) - then we walk through your warehouse processes, throughput and traceability requirements and are honest about where Odoo is enough and where it is not.

---

**Read more:** [What is a MES?](/blog/what-is-a-mes) · [MES vs MRP vs ERP](/blog/mes-vs-mrp-vs-erp) · [Odoo for wholesale](/industries/wholesale) · [Odoo for manufacturers](/industries/manufacturing) · [Cost price calculation](/blog/cost-price-calculation) · [Job costing](/blog/job-costing-in-odoo) · [What does an Odoo implementation cost?](/pricing/calculator) · [The TARGET method](/target)


# MES software: how to choose one (and when you do not need one)
URL: https://www.fanatics.nl/blog/mes-software
Language: en

**Short answer:** choosing MES software is less about feature lists than about two questions most vendors skip. First: **is the shop floor really your bottleneck**, or is the pain a layer below in planning or master data? Second: **does your ERP already cover this**, which for people-driven production it often does. Get those two right and the rest of the selection becomes straightforward. Get them wrong and you will buy a precise instrument for measuring the wrong thing.

This page is written from the buyer's side. If you are still working out what a MES *is*, read [what is a MES](/blog/what-is-a-mes) first; if you are weighing which layer to invest in, [MES vs MRP vs ERP](/blog/mes-vs-mrp-vs-erp) has a five-question diagnostic. This page assumes you have decided you need one and are choosing.

## Four categories of MES vendor

The market looks fragmented until you notice it clusters into four types, each with a predictable strength and a predictable weakness.

| Category | Strong at | Weak at | Fits when |
| --- | --- | --- | --- |
| **Industrial automation MES** (from automation and control vendors) | Machine and PLC integration, process control, high-frequency data | Cost, business-side integration, agility | The floor is machine-driven and heavily automated |
| **Specialist independent MES** | Shop-floor depth, analytics, OEE, scheduling detail | Needs integration with your ERP; duplicate master data | Manufacturing is your core complexity and you can carry the integration |
| **ERP-native shop floor** (a module of your ERP) | One database with planning, stock and finance; no integration project | Deep machine connectivity, second-level capture | Production is people-driven and you want one system |
| **Industry-specific systems** (print, food, metal) | Fits your trade out of the box, familiar vocabulary | Locks you into one sector; weaker outside its niche | Your industry's specifics outweigh breadth |

There is no winner in that table, only a fit. What we do see: companies who put "the floor is machine-driven" and "we are people-driven" in the wrong box pay for it for years.

## The eight criteria that actually decide it

Ignore feature matrices for a moment. In the projects we have seen succeed or struggle, these decided the outcome.

1. **Operator usability at the workstation.** Can someone wearing gloves, in a noisy hall, report a step in two taps without reading anything? This is the single highest-weighted criterion and it is almost always underweighted in selections, because the people doing the selecting are not the people doing the tapping.
2. **Integration with ERP and planning.** Where do orders come from and where do results go? Every integration you avoid is a project you do not run and a synchronisation you never debug.
3. **Machine connectivity.** Do you genuinely need PLC and sensor data, or do people report? Be honest here: this criterion alone often decides your category.
4. **Quality and traceability depth.** Control points during operations, measurements, blocking on failure, lot and serial genealogy, recall reporting.
5. **Configurability without code.** Can your own team add a check or change a screen, or is every change a vendor ticket with a rate card?
6. **Deployment and hardware.** Tablets, mounts, scanners, network coverage in a hall with metal everywhere. This is a real budget line that gets discovered late.
7. **Total cost over five years,** not licence price. See below.
8. **Track record in your industry,** with references you can actually call. Not logos on a slide: names and phone numbers.

## What MES software really costs

Licence cost is usually the smaller half of the bill. A realistic five-year view includes:

- **Licences or subscription**, per user or per workstation.
- **Implementation and configuration**, typically the largest line for specialist systems.
- **Hardware**: tablets, industrial mounts, scanners, label printers, plus network coverage on the floor.
- **Integration** with ERP, planning and machines. This is where specialist MES projects grow, because the integration is a project in itself.
- **Training**, including the reality that shop-floor staff turn over and training is never one-off.
- **Annual maintenance and support**, often a percentage of licence value.

The pattern worth knowing: a specialist MES commonly reaches six figures once integration and hardware are counted, while an **ERP-native shop-floor module can be a fraction of that, mostly because the integration work does not exist**. That is not a claim that one is better. It is the reason the categories are priced so differently, and why the "do I need a separate MES" question is worth real thought before you shortlist.

## Our opinion: most MES selections weigh the wrong things

We are an ERP partner, so read this knowing what we sell. It also means we have watched a lot of these decisions from close by.

**The demo lies, politely.** Every MES demos beautifully, because demos run on clean data with a presenter who knows the shortcuts. The floor does not run on clean data with a presenter. Insist on a pilot at one real work centre, with your bills of materials, your operators, and a week of actual production. What survives that is what you are buying. Vendors who resist a pilot are telling you something.

**Weight operator usability above everything else.** A MES that operators avoid does not produce partial data, it produces **wrong** data, filled in from memory at the end of the shift, and that is worse than no data because you will trust it. Every other feature is downstream of whether people actually use the thing.

**Be suspicious of the OEE promise.** OEE is the most-demoed and least-earned metric in this market. It is genuinely valuable, but only once your reporting is complete and honest. Buying a MES *for* OEE puts the dashboard before the data. Get accurate reporting first; the percentage will still be there next quarter.

**And the one that costs us work:** if your planning is unreliable or your master data is a mess, **do not buy a MES this year**. You will get a very precise measurement of chaos. Fix the layer below first. We have told prospects this and lost the project to someone who told them what they wanted to hear. We would still say it.

## The honest test: does your ERP already cover this?

Before you shortlist anything, run this check. If your ERP has a shop-floor app, does it do:

- Digital work instructions at the workstation
- Start, pause and stop timing per operation
- Quantity and scrap reporting at the moment it happens
- Quality checks as a step, with blocking on failure
- Barcode scanning for components, lots and serials
- Direct flow-through to stock, planning and cost price

If yes, you have the MES role covered for **people-driven production**, without an integration project. That is the situation for most mid-sized manufacturers, and it is why we so often end up recommending the boring answer: switch on what you already own, run it for a quarter, and revisit.

You need a separate MES when the answer is genuinely: deep machine and PLC integration, capture at the second across many machines, or validated production under regulatory requirements. Then buy the specialist, connect it to your ERP for planning and finance, and do not pretend either one can be the other.

For reference, in [Odoo](/odoo-erp) that shop-floor role is covered by the Shop Floor app on top of Manufacturing, with Quality and IoT alongside. We describe what it does and where it stops in [what is a MES](/blog/what-is-a-mes), including the parts Odoo does not do well.

## Frequently asked questions

**How do you choose MES software?**
Decide which layer you need first, then weigh operator usability highest, followed by ERP integration, machine connectivity, quality depth, configurability, hardware, five-year cost and industry references.

**What types of MES software are there?**
Industrial-automation MES, specialist independent MES, ERP-native shop-floor modules, and industry-specific systems. Each has a predictable strength and weakness.

**How much does MES software cost?**
Licences are the smaller half. Count implementation, hardware, integration, training and annual maintenance. Specialist projects often reach six figures; ERP-native modules cost a fraction because the integration does not exist.

**Do I need MES software if I already have an ERP?**
Often not, for people-driven production. A separate MES earns its place with deep machine integration, second-level capture, or validated production.

**Why do MES implementations fail?**
Undefined processes, an operator interface designed for managers, and buying a MES while planning or master data is still unreliable.

---

**Want a second opinion before you shortlist?** [Book a free Odoo scan](/scan) - we go through your floor, your planning and your data, and tell you honestly whether you need MES software at all, and what we would not sell you.

---

**Read more:** [Smart manufacturing and Industry 4.0](/blog/smart-manufacturing) · [Manufacturing software: the categories](/blog/manufacturing-software) · [Production planning and scheduling](/blog/production-planning-scheduling-software) · [What is a MES?](/blog/what-is-a-mes) · [MES vs MRP vs ERP](/blog/mes-vs-mrp-vs-erp) · [MRP system explained](/blog/mrp-system) · [Odoo for manufacturers](/industries/manufacturing) · [Can Odoo run your production floor?](/blog/can-odoo-run-your-production-floor) · [The TARGET method](/target)


# MES vs MRP vs ERP: the three layers of manufacturing software (and how Odoo unites them)
URL: https://www.fanatics.nl/blog/mes-vs-mrp-vs-erp
Language: en

import MesLayerDiagnostic from '@fanatics-web/ui/MesLayerDiagnostic.astro';

**Short answer:** they are not alternatives but **three layers stacked on top of each other**. **MRP** plans (what are we making, when, is the material there?), **MES** executes and records (what is happening on the shop floor right now?), and **ERP** processes the consequences into inventory, cost price and invoicing. The sharpest distinction is the clock: ERP thinks in days to months, MRP in weeks to days, an MES in minutes to seconds. So the real-world question is rarely "MES or MRP", but: **which layer is my bottleneck?**

## The three layers side by side

| | **ERP** | **MRP** | **MES** |
| --- | --- | --- | --- |
| **Answers** | How is the business doing? | What are we making, when, with which material? | What is happening on the shop floor right now? |
| **Time horizon** | Days to months | Weeks to days | Minutes to seconds |
| **Core objects** | Orders, invoices, inventory, general ledger | Bills of materials, manufacturing orders, material requirements | Work orders, operations, scrap, quality |
| **Users** | Management, administration, purchasing, sales | Planners, work preparation | Operators, production management |
| **Typical question** | Are we making money on this customer? | Will we hit the delivery date? | Why is line 2 down? |
| **In Odoo** | Sales, Purchase, Inventory, Accounting | Manufacturing (MRP) | Shop Floor |

Read the table from right to left and you see the chain: the MES delivers reality, MRP compares it with the plan, ERP translates it into money.

## Where it goes wrong in practice

Three patterns we keep seeing at manufacturing companies.

**1. Buying an MES while the foundation is missing.** If sales, purchasing and inventory still sit in disconnected systems and spreadsheets, an MES mostly amplifies the chaos: you measure the shop floor very precisely, but the numbers do not tie back to anything. First a system, then measuring.

**2. Thinking MRP will solve the shop floor problem.** MRP produces a beautiful plan, but if nobody reports what actually happened, the plan stays fiction. Overruns, scrap and downtime only become visible once you record them.

**3. Buying an MES for what is really a process problem.** If operations are not defined or bills of materials are wrong, no system is going to repair that. Software makes a good process faster and a bad process visibly more expensive.

The order that works in practice: **ERP foundation → MRP planning → MES execution**. Every step makes the next one more valuable.

## Which layer do you need?

Instead of a generic recommendation: five questions about your situation, with an honest verdict. Including the outcome "Odoo is not the right tool here".

<MesLayerDiagnostic locale="en" />

## Why one database makes the difference

Classically, ERP, MRP and MES are three packages from three vendors, with integrations between them. That works, but you pay for it with:

- **Delay.** Data travels via nightly or periodic synchronisation; the shop floor is real time, your numbers are not.
- **Duplicate master data.** Products, bills of materials and work centers exist in two systems and drift apart.
- **Arguments about the truth.** When planning and the shop floor show different numbers, the meeting is about which system is right instead of about the problem.

In [Odoo](/odoo-erp) they are layers on the same database: [Manufacturing](/industries/manufacturing) for the MRP role, [Shop Floor](/blog/what-is-a-mes) for the MES role. An operator who reports an operation as done immediately reduces inventory, books hours, updates the planning and influences the [cost price](/blog/cost-price-calculation) and the [job costing](/blog/job-costing-in-odoo). No integration, no waiting time, no second truth.

That is not "Odoo has the richest MES features", because it does not. It is: **the layer you are missing, you do not have to build alongside it**.

## Our opinion: almost everyone buys one layer too high

Our position, stated explicitly, because you are entitled to know where we stand.

When a manufacturing company comes to us with "we want an MES", in the vast majority of conversations the pain turns out to sit one layer lower. Not because those people do not get it, but because **MES is the word going around at conferences and in LinkedIn posts**, and "our bills of materials are wrong" simply does not make for an inspiring project proposal.

So we will say it out loud: **the most underrated layer is MRP, and the most overrated is MES.** A correct bill of materials, a realistic operation time and a planning that holds up usually deliver more than real-time insight into a process you do not yet control. Seeing in real time that things are going wrong is not the same as preventing them from going wrong.

Two propositions that follow from this:

- **Measuring only tells you something if there is something to know.** An MES on top of shaky planning gives you a very precise measurement of chaos. Impressive, and rarely usable.
- **The layer order is not dogma, but it is almost always true.** ERP foundation, then MRP, then MES. We have helped companies that reversed this order. It was possible, but it cost more and it took longer.

Where we argue against ourselves: there is an exception, and it is real. If your pain demonstrably sits in **downtime and scrap** and you have planning that largely works, then the shop floor layer really is your first step. Then you are measuring something you can actually influence. That is exactly what the diagnostic above filters for.

And one more unpopular point: **the vendor who immediately offers you an MES without asking about your planning is selling their product, not your solution.** We sell Odoo, so read this page with that in mind; but that is precisely why the section below sets out when you should not come to us.

## Honestly: when you do want a separate MES

There are situations where a specialised MES alongside Odoo is the wiser choice:

- You need to **read out and control machines** (PLC, process control) instead of having people report.
- You capture data at **second-level resolution across many machines at once**.
- You are in **heavily regulated production** where a validated MES with its own audit trails is required.

Then the clean architecture is: Odoo as the ERP and planning backbone, the MES as a specialised shop floor layer next to it, with a clear integration. That is more honest than forcing a platform into something it was not built for.

## Frequently asked questions

**What is the difference between MES and MRP?**
MRP plans (what are we making, when, which material), an MES executes and records in real time on the shop floor. MRP thinks in weeks and days, an MES in minutes and seconds.

**What is the difference between MRP and ERP?**
ERP is the broad platform for the whole company; MRP is the production planning part within it. In modern packages MRP is a module of the ERP, not a separate system.

**Do I need ERP, MRP or MES?**
That depends on your biggest pain: disconnected systems (ERP), material and planning (MRP), or no view of the shop floor (MES). The diagnostic above gives a concrete answer.

**Can an ERP system replace an MES?**
For people-driven production, often yes, via a shop floor app. Not with deep machine integration, second-level data or validated production.

**How do MES and MRP work together in Odoo?**
Odoo Manufacturing fills the MRP role, Odoo Shop Floor the MES role, on the same database. A reported operation flows straight through into planning, inventory and cost price.

---

**Want to know which layer delivers the most for you?** [Book a free Odoo scan](/scan) - we will walk through your planning, your shop floor and your recording, and tell you honestly which layer you need now and which one can wait.

---

**Further reading:** [Manufacturing software: the categories](/blog/manufacturing-software) · [MRP system explained](/blog/mrp-system) · [MES software: how to choose](/blog/mes-software) · [What is an MES?](/blog/what-is-a-mes) · [Can Odoo run your production floor?](/blog/can-odoo-run-your-production-floor) · [Odoo for manufacturing companies](/industries/manufacturing) · [Odoo as WMS](/blog/odoo-as-wms) · [Manufacturing accounting in Odoo](/blog/manufacturing-accounting-in-odoo) · [The TARGET method](/target)


# MRP software explained: the calculation, the limits, and how to choose one
URL: https://www.fanatics.nl/blog/mrp-system
Language: en

import MrpRequirementsCalculator from '@fanatics-web/ui/MrpRequirementsCalculator.astro';

**Short answer:** an **MRP system** (Material Requirements Planning) answers three questions: *what do we need to make or buy, how much, and by when?* It takes your demand, explodes it through the bill of materials, subtracts what you already have or have on order, and proposes purchase and manufacturing orders with dates that respect lead times. That is the whole idea: turning "we sold 500" into "order 380 of this component today".

Most explanations stop at that sentence. The calculation underneath is where MRP actually becomes understandable, so let us do it properly.

## The MRP calculation, step by step

MRP is arithmetic, repeated relentlessly. Per item, per period:

1. **Gross requirement** - what demand asks for (sales orders, forecast, or the parent item's planned order).
2. **Available** = on hand − safety stock + scheduled receipts (what is already ordered and inbound).
3. **Net requirement** = gross requirement − available, floored at zero. If stock covers it, you order nothing.
4. **Planned order** = the net requirement rounded up to your **lot size**, and at least the **minimum order quantity** your supplier enforces.
5. **Order date** = date needed − **lead time**. This is called back-scheduling, and it is where "we are already too late" becomes visible.

Then MRP does the part that makes it worth automating: it takes each planned order, looks up that item's bill of materials, and repeats the whole calculation one level down. A finished product with four subassemblies and forty components produces a cascade no one wants to maintain by hand.

## Try it: the netting calculation

Change the numbers and watch the order proposal move. This is exactly what one line of an MRP run does.

<MrpRequirementsCalculator locale="en" />

Two things become obvious once you play with it. **Safety stock is not free**: raising it lowers your available quantity and pulls orders forward. And **lot size and minimum order quantity routinely make you buy more than you need**, which is a supplier negotiation disguised as a system setting.

## MRP, MRP II, ERP and MES: where the boundaries are

These terms get used loosely, so briefly:

- **MRP** plans **materials**: what to order and make, and when.
- **MRP II** extends the same logic to **capacity**: machines, work centres and labour, so the plan also reflects whether you can physically make it in time. Almost everything sold today as "MRP" is really MRP II.
- **ERP** is the **broad platform**: sales, purchasing, inventory, accounting, HR. MRP is a module inside it.
- **MES** is the **execution layer** on the shop floor, working in minutes rather than weeks.

If you want that comparison in depth, including which layer to invest in first, we wrote a separate piece: [MES vs MRP vs ERP](/blog/mes-vs-mrp-vs-erp). And if the term MES is the unfamiliar one, start at [what is a MES](/blog/what-is-a-mes).

## Our opinion: MRP fails on data, not on features

Here is where we will be blunt, because it is the single most common reason MRP disappoints.

Nearly every failed MRP project we have seen failed for the same reason: **the calculation was fine, the data was not**. MRP is arithmetic on your master data, so it inherits every flaw in it. A bill of materials missing a component, a lead time that says 5 days when the supplier reliably takes 20, a stock figure that is off because returns were never booked: MRP will faithfully compute a wrong answer and present it with total confidence.

That leads to three opinions we hold firmly:

- **Lead times are the most-neglected field in manufacturing software.** They are usually entered once, at implementation, by someone guessing. They then quietly drive every order date for years. Reviewing them is the cheapest planning improvement available to most companies.
- **Safety stock is often used to paper over unreliable data.** Raising it hides the symptom of a planning problem and ties up cash. Sometimes it is genuinely the right call; often it is an expensive apology for a wrong lead time.
- **If your planners override the MRP proposals every week, the system is not the problem.** The overrides are information: something in the data does not match reality. Chasing that is more valuable than any new feature.

The unpopular consequence: an MRP implementation is mostly a **data project** wearing a software project's clothes. Anyone who sells it to you purely as a software installation has not done this before.

## Choosing MRP software: what actually matters

The market is full of comparison tables with checkmarks. In practice, only a handful of things decide whether it works for you.

- **Does MRP sit on the same data as purchasing and inventory?** If your MRP tool is separate from where stock and orders live, you will maintain master data twice, and the calculation will drift from reality. This is the strongest argument for MRP as an ERP module rather than a standalone tool.
- **Can it handle your bill-of-materials depth and variants?** Multi-level bills, phantom assemblies, and configurable products are where simple tools quietly fall over.
- **Are lot sizing, minimum order quantities and lead times modelled per supplier?** One global setting is not enough once you have real suppliers.
- **Can planners see *why* a proposal exists?** Traceability from a proposed order back to the demand that caused it is what makes planners trust the system, and trust is the whole ballgame.
- **Does it extend to capacity when you need it?** Materials first is fine, but you do not want a dead end when machine capacity becomes the constraint.

### And honestly: when a spreadsheet is still enough

Few software companies will say this, so we will. A spreadsheet holds up when you have **few components, stable demand and shallow bills of materials**. If you make ten products from twenty parts and demand is predictable, MRP software will not transform your business.

The point where it breaks is not company size, it is **change frequency and depth**. When the same component appears at three levels, when lead times differ per supplier, when demand shifts weekly, every change means recalculating everything by hand, and that is when people quietly stop recalculating. That moment, not a revenue threshold, is when you need MRP software.

## MRP in Odoo

In [Odoo](/odoo-erp), MRP is not a separate product but the Manufacturing app on the same database as sales, purchasing, inventory and accounting. Practically that means:

- **Bills of materials** including multi-level and variants, with operations and work centres.
- **Reordering rules** with minimum and maximum levels, lead times and lot sizes per product and per supplier.
- **The MRP run** proposing purchase and manufacturing orders, with traceability back to the demand that triggered them.
- **Capacity** via work centres, so the plan reflects machines rather than materials alone.
- **Direct flow-through** to [cost price](/blog/cost-price-calculation) and [job costing](/blog/job-costing-in-odoo), because the same database holds the financial side.

The advantage is not that Odoo's planning algorithm is more sophisticated than a specialised planning tool's. It is that the data it calculates on is the same data your buyers, warehouse and finance team already maintain. Given that MRP fails on data, that is worth more than an extra algorithm.

## Frequently asked questions

**What is an MRP system?**
Software that calculates what to make or buy, how much, and by when, by exploding demand through the bill of materials and netting it against stock and orders on the way.

**How does the MRP calculation work?**
Available = on hand − safety stock + scheduled receipts. Net requirement = gross requirement − available, floored at zero. That net is rounded up to lot size and minimum order quantity, and the order date is the need date minus the lead time.

**What is the difference between MRP and ERP?**
ERP is the broad platform for the whole company; MRP is the production planning module inside it. Standalone MRP means maintaining master data twice.

**What is the difference between MRP and MRP II?**
MRP plans materials; MRP II adds capacity (machines, work centres, labour). Nearly everything sold as MRP today is MRP II.

**Do I need MRP software or is a spreadsheet enough?**
A spreadsheet works with few components, stable demand and shallow bills of materials. Depth and change frequency, not company size, are what push you to real MRP software.

---

**Not sure whether your planning problem is a data problem or a software problem?** [Book a free Odoo scan](/scan) - we go through your bills of materials, lead times and planning process, and tell you honestly which of the two you are dealing with.

---

**Read more:** [Manufacturing software: the categories](/blog/manufacturing-software) · [Production planning and scheduling](/blog/production-planning-scheduling-software) · [MES vs MRP vs ERP](/blog/mes-vs-mrp-vs-erp) · [What is a MES?](/blog/what-is-a-mes) · [MES software: how to choose](/blog/mes-software) · [Odoo for manufacturers](/industries/manufacturing) · [Cost price calculation](/blog/cost-price-calculation) · [The TARGET method](/target)


# What is a MES system (Manufacturing Execution System)? And how does it work in Odoo?
URL: https://www.fanatics.nl/blog/what-is-a-mes
Language: en

import MesLayerDiagnostic from '@fanatics-web/ui/MesLayerDiagnostic.astro';

**Short answer:** a **MES (Manufacturing Execution System)** is the software layer that drives and records your production **at the moment it happens**. Planning determines *what* needs to be made and when; a MES records *what actually happens*: which operation is running, who is working on it, how long it takes, how much scrap there is and whether the quality check passed. So the difference with a planning system is mostly **time**: planning thinks in days and weeks, a MES in minutes and seconds. In [Odoo](/odoo-erp) the **Shop Floor** app fills that role, on top of Odoo Manufacturing.

## What a MES does

The functions differ per vendor, but the core is the same everywhere: **support and capture execution**.

- **Digital work instructions.** At the work centre the operator sees step by step what needs to happen, with drawings, photos or video instead of a printed folder.
- **Time tracking per operation.** Start and stop at the work centre, so you know how long an operation actually took instead of how long it was estimated to take.
- **Quantities and scrap.** Produced quantities, rejects and scrap are booked at the moment itself, not at the end of the day.
- **Quality checks.** Control points during the operation, with measurements, photos and pass or fail, including a block if something does not meet the standard.
- **Barcode and scanning.** Scan components, lots and serial numbers on the line, so traceability appears without extra admin.
- **Real-time feedback.** What happens on the floor flows straight through into inventory, planning and cost price.
- **Machine connection (IoT/PLC).** Many MES systems read counters, scales or controllers directly. This is exactly the part where the differences between systems are biggest.

In short: a MES turns the floor from a **black hole** into a **live picture**.

## MES, MRP and ERP: three layers, three time horizons

Most of the confusion disappears once you see it as layers, each with its own question and its own clock.

| Layer | Answers | Time horizon | Users |
| --- | --- | --- | --- |
| **ERP** | How is the company doing? | Days to months | Management, admin, purchasing, sales |
| **MRP** | What do we need to make, when, and do I have material? | Weeks to days | Planners, work preparation |
| **MES** | What is happening on the floor right now? | Minutes to seconds | Operators, production management |

They are not competitors but a chain: MRP makes the plan, the MES executes and reports back, and ERP processes the consequences in inventory, cost price and invoicing. In the world of disconnected systems these are three packages with interfaces between them. In an integrated platform they are layers on **the same database**, which is the difference between "the numbers will be right tomorrow" and "the numbers are right now".

Want that comparison in more depth, including where the limits are: [MES vs MRP vs ERP](/blog/mes-vs-mrp-vs-erp).

## Which layer do you need?

This is the question where most MES explanations go quiet. Not everyone searching for "MES" actually needs a MES: sometimes the gain sits one layer lower. Five questions, an honest answer straight away.

<MesLayerDiagnostic locale="en" />

## Does Odoo have a MES? Yes, but there is no app by that name

This causes a lot of confusion, including in articles that talk about "the Odoo MES module". **That module does not exist.** You will not find an app named MES in Odoo. The MES role is filled by a combination of four standard apps:

- **Manufacturing** - manufacturing orders, bills of materials, operations and work centres (the MRP side).
- **Shop Floor** - the tablet interface where operators start, stop and report operations. This is the actual MES heart.
- **Quality** - control points, measurements and blocks during the operation.
- **IoT** - connecting peripherals such as scanners, scales, printers and foot pedals through the IoT box.

So anyone searching for "how to switch on the MES module" gets stuck. You switch on **Manufacturing and Shop Floor**, and extend with Quality and IoT where needed.

Two things you come across in marketing texts about Odoo MES that we want to put in honest perspective: **OEE reporting and predictive maintenance are not standard Odoo functions**. Odoo does record the building blocks (run times, downtime, scrap, maintenance requests through the Maintenance app), but a full OEE calculation or predictive maintenance is something you build on top or take from a specialised system. Anyone who promises otherwise is selling a dashboard that does not exist yet.

## MES in Odoo: the Shop Floor app

Odoo covers the MES layer with **Shop Floor**, a tablet interface on top of Odoo Manufacturing. What it offers out of the box:

- **Work centre driven operation.** Every work centre has its own screen with the operations queued there.
- **Start, pause and stop timers** per work order, with automatic hour registration.
- **Digital work instructions** with documents, photos and videos alongside the operation.
- **Quantities, scrap and consumption** reported directly from the screen.
- **Quality checks** as a step in the operation, with a measurement or a pass and fail.
- **Barcode scanning** for components, lots and serial numbers.
- **Immediate flow-through**: a reported operation lowers inventory, books hours and works through into the [cost price](/blog/cost-price-calculation) and the [job costing](/blog/job-costing-in-odoo).

The big advantage is not that Odoo's MES functions are the richest on the market, but that they sit **on the same database as planning, inventory, purchasing and accounting**. No interface, no nightly synchronisation, no two versions of the truth.

## Honestly: where Odoo's MES layer stops

As with every comparison on this site, we are clear about this. Odoo Shop Floor is strong for **people-driven production**: operators who carry out, report and check operations at work centres. Where a specialised MES remains stronger:

- **Deep machine integration**: reading and writing back PLCs, process control and machine data in real time.
- **Very high frequency**: second-level data capture across many machines at once.
- **Heavily regulated production** with validation requirements (pharma, medical devices) where a validated MES with its own audit trails is demanded.

If that is where you are, the clean solution is not "forcing Odoo", but a specialised MES **alongside** Odoo, with Odoo as the ERP and planning backbone. For most small and mid-sized manufacturers the opposite applies: Shop Floor is more than enough, and the gain sits in the fact that everything is in one system.

## Our opinion: most MES projects start at the wrong end

A word about our own position, because you are entitled to hold us to it.

The MES market loves selling **dashboards**. A big screen in the canteen with OEE percentages, a chart that moves in real time, a demo where everything turns green. It looks impressive and it convinces management. But in practice we rarely see a company that has too few charts. We see companies where the operator still fills in a slip of paper that gets typed over a day later.

Our conviction: **a MES pays for itself at the work centre, not in the boardroom.** The value appears the moment an operator with a dirty glove can report what happened in two taps, and does not have to think about which box goes where. If that does not work, every dashboard above it is fiction: pretty charts on data nobody filled in seriously.

Three opinions follow from that, and not everybody likes them:

- **Start with the input, not with the reporting.** If reporting takes more than a few seconds, it gets filled in from memory at the end of the day. Then you are measuring recollections, not production.
- **OEE is rarely your first problem.** It is a beautiful KPI for companies that have their basics in order. For most small and mid-sized manufacturers, "do we even know how long this operation took" is a more useful question than a percentage to two decimal places.
- **Distrust every MES promise without a limit.** A vendor who cannot name what their system does *not* do has not looked into your situation. We name that limit explicitly below, including where Odoo falls short.

And the uncomfortable truth that goes with it: if your process is not defined, software is not going to save it. A MES makes a good process faster and mainly makes a bad process **visibly more expensive**. That is still a gain, but it is a different gain from the one you saw on the quote.

## And what about "smart manufacturing"?

Smart manufacturing (or Industry 4.0) is the broader ambition: production that measures, adjusts and predicts itself, with sensors, data and analysis. A MES is the **practical first step** towards it, because without reliable execution data there is nothing to be smart with. So do not start with the buzzword but with the basics: record what happens, and only then does predicting mean something.

## Frequently asked questions

**What is a MES?**
The software layer that drives execution on the shop floor and records it in real time: which operation is running, how long, with what scrap and what quality.

**What exactly does a MES do?**
Digital work instructions, time tracking per operation, booking quantities and scrap, quality checks, barcode scanning and real-time feedback into planning and inventory. Often also a machine connection through IoT or PLC.

**What is the difference between MES and ERP?**
ERP is the administrative heart of the entire company (days to months); a MES focuses on the floor at the moment of execution (minutes to seconds). In Odoo both sit on the same database.

**Does Odoo have a MES?**
Yes, the Shop Floor app on top of Manufacturing: tablet operation, timers, work instructions, quality checks and barcode. For heavy PLC integration a specialised MES remains stronger.

**When do you need a MES?**
As soon as your planning is in place but the floor stays a black hole. If the pain is still in material and planning, MRP matters more; if it sits in disconnected systems, start with the ERP foundation.

---

**Curious whether Odoo's MES layer is enough for your floor?** [Book a free Odoo scan](/scan) - we will walk through your operations, work centres and measurement needs and be honest about where Shop Floor is enough and where it is not.

---

**Read more:** [Smart manufacturing and Industry 4.0](/blog/smart-manufacturing) · [Manufacturing software: the categories](/blog/manufacturing-software) · [MRP system explained](/blog/mrp-system) · [MES software: how to choose](/blog/mes-software) · [MES vs MRP vs ERP](/blog/mes-vs-mrp-vs-erp) · [Can Odoo run your production floor?](/blog/can-odoo-run-your-production-floor) · [Odoo for manufacturers](/industries/manufacturing) · [Manufacturing accounting in Odoo](/blog/manufacturing-accounting-in-odoo) · [Job costing](/blog/job-costing-in-odoo) · [The TARGET method](/target)


# Cost price calculation: direct and indirect costs, and how to spread them (with calculator)
URL: https://www.fanatics.nl/blog/cost-price-calculation
Language: en

import KostprijsCalculator from '@fanatics-web/ui/KostprijsCalculator.astro';

**Short answer:** a cost price is **direct costs plus an allocated share of the indirect costs**. The direct costs (material, direct hours) are the easy part: you assign those straight away. The art is in the indirect costs, the overhead that belongs to the whole company and not to a specific product: those you have to **spread** using an allocation base. How you do that determines whether your cost price is right. Below are the three methods for spreading, the difference between absorption and variable costing, a calculator that builds up your cost price per unit, and how to capture it in [Odoo](/odoo-erp).

## Direct and indirect costs

Everything starts with this distinction.

- **Direct costs** can be assigned straight to a product or order. The steel in a frame, the fitter's hours on a job, the machine hours on a production run. You can point and say: that cost belongs to this product.
- **Indirect costs** (overhead) belong to the company as a whole: the rent of the hall, the bookkeeper, the manager, the software. They are needed in order to produce, but you cannot pin them to a single product.

The direct costs are therefore no problem. The entire theory of cost price calculation is about that second category: how do you allocate a fair share of the indirect costs to each product?

## Spreading indirect costs: three methods

There are three classic ways to spread overhead, from coarse to fine.

### 1. The markup method

You apply a **markup percentage** to a base. For example: all indirect costs together are 60% of the direct costs, so you add a 60% markup to every product. The base can be the total direct costs, direct labour only, or an amount per direct hour.

- *Advantage:* simple, fast, fine for a company with one type of work.
- *Disadvantage:* coarse. A product with a lot of material but few overhead-causing operations gets too much allocated (the "primitive markup method"). The refined markup method therefore uses several markups on different bases.

### 2. The cost-centre method

You first distribute the overhead across **cost centres** (departments, machines) using an allocation base, and calculate a **rate** per cost centre (for example a machine-hour rate). A product then absorbs overhead towards the cost centres it actually uses.

- *Advantage:* much fairer. A product that sits on an expensive machine for a long time also carries more of that machine.
- *Disadvantage:* more laborious; you have to maintain the cost centres and allocation bases. This is the method you see back in a real [manufacturing accounting](/blog/manufacturing-accounting-in-odoo), with absorption accounts per cost centre.

### 3. Activity-based costing (ABC)

You allocate overhead per **activity** (processing a purchase order, a changeover, an inspection), each with its own cost driver. The sharpest, but also the heaviest to maintain. Worthwhile if your overhead is large and unevenly distributed.

> **The common thread:** the more finely you spread, the more accurate the cost price, but the more administration it costs. The right method is the coarsest one that still gives a fair picture for your mix. For most SME production, a good cost-centre method is the sweet spot.

## Calculate your cost price

Choose your allocation base and see how the indirect costs land per unit, how the absorption cost price builds up and which selling price goes with it given your margin.

<KostprijsCalculator locale="en" />

The stacked bar makes immediately visible what surprises many companies: for service and make-to-order work the **indirect** slice is often bigger than expected. Whoever underestimates their overhead calculates structurally too keenly and only discovers it at the [job costing](/blog/job-costing-in-odoo).

## Absorption versus variable costing

Another choice you have to make: do you allocate *all* costs, or only the variable ones?

- **Absorption costing:** all costs, including the fixed indirect costs, are allocated. This is the usual basis for your inventory valuation and your selling price, and what the calculator above shows.
- **Variable costing (direct costing):** only the variable costs are allocated; the fixed costs you take separately as period costs. Strong for short-term decisions: for an extra order where your fixed costs are already covered anyway, only whether the revenue exceeds the variable costs counts (the contribution margin).

Both are correct, for different questions. For "what may this product structurally cost" you use absorption; for "do I accept this extra job at a lower price" you look at the contribution margin.

## From cost price to selling price

The cost price is your floor, not your price. On top comes your profit markup. Watch the difference between a markup *on* the cost price (margin as a percentage of the cost price) and a margin *in* the selling price (percentage of the selling price): a 25% markup on a cost price of 100 gives 125, but that is a margin of 20% of the selling price. The calculator uses the markup on the cost price.

## Calculating the cost price in Odoo

A cost price that lives in a spreadsheet is out of date a month later. In [Odoo](/odoo-erp) the cost price lives in your system:

- **Cost price per product**, as standard price, FIFO or moving average.
- **Cost price from the bill of materials**: for a manufactured product Odoo calculates the cost price from the components and the operations (with work-centre rates for your machine hours, the cost-centre idea).
- **Landed costs**: freight, import duties and insurance you allocate to the inventory value, so that your cost price reflects the real purchasing chain.
- **Overhead** you allocate via work-centre rates or a markup, exactly as in the tool.

The beauty: that calculated cost price is immediately your **estimate**. If you then register the actual hours and material on the order, the [job costing](/blog/job-costing-in-odoo) rolls out by itself, and you see whether your markups were right. That closes the circle: calculate the cost price, quote with it, and check it afterwards.

## Frequently asked questions

**How do you calculate the cost price of a product?**
Direct costs (material + direct hours) plus an allocated share of the indirect costs (overhead) = the absorption cost price per unit. On top comes your profit margin.

**What is the difference between direct and indirect costs?**
Direct costs you assign straight to a product (material, hours); indirect costs (premises, management, systems) belong to the whole company and you spread them using an allocation base.

**How do you allocate indirect costs to a product?**
Via the markup method (percentage on a base), the cost-centre method (rate per department or machine) or ABC (per activity). Spreading more finely gives a more accurate but more laborious cost price.

**What is the difference between absorption and variable costing?**
Absorption allocates all costs (basis for inventory and selling price); variable allocates only variable costs (strong for short-term decisions via the contribution margin).

**Can you calculate the cost price in Odoo?**
Yes, via cost price per product, cost price from the bill of materials, landed costs and overhead via work-centre rates. The calculated cost price is immediately your estimate.

---

**Want a cost price that is right and keeps itself up to date?** [Book a free Odoo scan](/scan) - then we go through your cost structure, allocation bases and calculation with you and show how cost price, quote and job costing come together in one system.

---

**Read more:** [Job costing: from estimate to actual cost price](/blog/job-costing-in-odoo) · [Manufacturing accounting in Odoo](/blog/manufacturing-accounting-in-odoo) · [Odoo for manufacturing companies](/industries/manufacturing) · [Software for construction companies](/software-for-construction-companies) · [What does an Odoo implementation cost?](/pricing/calculator) · [The TARGET method](/target)


# Job costing: from estimate to actual cost (with calculator)
URL: https://www.fanatics.nl/blog/job-costing-in-odoo
Language: en

import NacalculatieCalculator from '@fanatics-web/ui/NacalculatieCalculator.astro';

**Short answer:** job costing is establishing after the fact what an order, project or production run *actually* cost, compared to the estimate you made in advance. The value is not in the total amount, but in the *difference* and its cause: did you work more hours than budgeted (volume variance), were those hours more expensive than your rate (budget variance), or did the material get out of hand? Whoever knows that per order calculates more sharply next time. Below we explain the principle, with a calculator that splits the variance for you straight away, and we show how you automate it in [Odoo](/odoo-erp).

## Estimate and job costing: two sides of the same order

Every order starts with an **estimate**: you assess the hours, the material and the other costs, add your [overhead markup](/blog/cost-price-calculation) on top and arrive at a price. That estimate is your plan, and often your standard cost as well.

**Job costing** is the reckoning with reality. You collect the actual hours logged, the actual material consumption and the actual rates, and put those next to the estimate. The difference is your learning moment:

- If the order structurally overruns on hours, you are calculating too tightly, or your process is stuttering.
- If the rates are higher than planned, your hourly rate is outdated or you are running below your normal capacity.
- If the material does not add up, there is waste in it, or your purchase price has gone up.

Without job costing you do know at the end of the year whether your business made a profit, but not *on which orders* and *why*. That is the difference between a result that happens to you and a result that you steer.

## Work it out yourself

Fill in your estimate and actual cost. The tool calculates the result on the order and splits the difference into the three causes that together add up exactly to the total.

<NacalculatieCalculator locale="en" />

What you see happening above is the core of cost analysis: the total difference between estimate and actual cost falls apart exactly into three explainable pieces. That "exactly" is no coincidence but an arithmetic identity, and that is precisely why it is usable: every euro of variance has an address.

## The difference broken down: volume, budget and material

The three variances from the tool are the standard language of cost accounting.

- **Volume variance (hours).** `(actual hours − calculated hours) × standard cost`. This isolates the *quantity* of work: did you need more or fewer hours than planned? Valued at the standard cost, so that a rate change does not cloud the picture.
- **Budget or rate variance.** `actual hours × (actual rate − standard cost)`. This isolates the *price* of an hour: did each hour worked turn out more expensive or cheaper than your standard cost? A higher actual rate often points to undercapacity, overtime or an outdated rate.
- **Material variance.** `actual material − calculated material`. Waste, price increase or an overly optimistic material calculation.

This split comes straight from the cost accounting textbooks (whoever has worked through *Boekhouden Geboekstaafd* part 3 will recognise the volume and budget variance). It works for a production run just as well as for a construction project, an installation job or a consulting assignment: everywhere you calculate in advance and register hours and material afterwards.

## Job costing per sector

The principle is universal, the implementation differs per sector:

- **Production.** Job costing per production order, with material, machine hours and surcharges. If you want to have that balance out on your balance sheet (work in progress, standard cost, variance account), you end up at real [manufacturing accounting](/blog/manufacturing-accounting-in-odoo).
- **Construction and installation.** Job costing per project or per specification: budgeted versus spent man-hours and material, with additional and reduced work. See also [software for construction companies](/software-for-construction-companies) and [software for field service installers](/software-for-field-service-installers).
- **Project organisations and service providers.** Job costing based on logged hours against a rate, often the determining factor for your margin.

## Automating job costing in Odoo

The pitfall of job costing is that it becomes a loose exercise: afterwards putting hours from one system and costs from another side by side in a spreadsheet. Then the job costing is always too late and never complete.

Better is job costing that rolls *out of your administration itself*. In [Odoo](/odoo-erp) that works like this:

1. **Estimate as standard cost.** You record the calculated cost price as the standard cost on the product or the project budget.
2. **Registration where the work happens.** Hours on the work order or the project, material via stock movements, machine costs via work centers. Record once, at the place where it arises.
3. **The difference posts itself.** On completion, the difference between actual costs and standard cost lands on a variance account, directly analysable per order and per customer via the cost analysis.

For production companies that want to carry this through to the operation step and onto the balance sheet, we have worked out the full posting flow in a separate demo: [manufacturing accounting in Odoo](/blog/manufacturing-accounting-in-odoo). There you see how work in progress, coverage accounts and the variance posting land neatly on the trial balance.

## Frequently asked questions

**What is job costing?**
Establishing after the fact what an order, project or production run actually cost: all the hours, materials and costs spent, set against the estimate.

**What is the difference between an estimate and job costing?**
An estimate is the cost price budgeted in advance (that you quote with); job costing is the actual cost price after the fact. The difference you split into volume, budget and material variance.

**How do you calculate job costing?**
Actual hours times actual rate, plus actual material, minus the estimate. Split the difference by cause (hours, rate, material), as the calculator above does.

**What is a volume variance and a budget variance?**
The volume variance comes from more or fewer hours than budgeted (at standard cost); the budget variance from a deviating hourly rate. Together with the material variance they explain the whole difference.

**Can you automate job costing in Odoo?**
Yes, by working with a standard cost and registering hours and material on the order; the difference then posts itself automatically on a variance account, analysable per order and customer.

---

**Want job costing to roll out of your system instead of out of a spreadsheet?** [Book a free Odoo scan](/scan) - then we walk through your calculation, hours and material registration and show where job costing can happen automatically.

---

**Read more:** [Calculating cost price: direct and indirect costs](/blog/cost-price-calculation) · [Manufacturing accounting in Odoo](/blog/manufacturing-accounting-in-odoo) · [Odoo for manufacturing companies](/industries/manufacturing) · [Software for construction companies](/software-for-construction-companies) · [Software for field service installers](/software-for-field-service-installers) · [What does an Odoo implementation cost?](/pricing/calculator) · [The TARGET method](/target)


# Manufacturing accounting in Odoo: work in progress, job costing and product cost that reconcile on your balance sheet
URL: https://www.fanatics.nl/blog/manufacturing-accounting-in-odoo
Language: en

import VideoEmbed from '@fanatics-web/ui/VideoEmbed.astro';

**Short answer:** standard Odoo posts inventory movements and product cost neatly, but genuine manufacturing accounting - where material, machine hours and surcharges are posted to work in progress (WIP) per production step and settled cleanly against a standard cost when completed - calls for a well-designed posting flow on top of the standard. In the video below (10 minutes) we show how we approach that: from cost elements and journals, via the postings per work order, to a trial balance that runs clean and a variance posting that makes the job costing per order visible. Factory accounting, production accounting and cost accounting are other names for the same principle.

<VideoEmbed
  provider="loom"
  videoId="67cac3c9e3574c34b48b24305c0d9857"
  poster="https://cdn.loom.com/sessions/thumbnails/67cac3c9e3574c34b48b24305c0d9857-c4e12dd0a98c13c8-full-play.jpg"
  title="Manufacturing accounting in Odoo - demo of the posting flow"
  description="Demo: work in progress postings per production step in Odoo, with cost elements, surcharges, standard cost and a reconciling trial balance."
  uploadDate="2026-07-28T12:00:00+02:00"
  duration="PT10M43S"
  caption
/>

## Why post work in progress?

Anyone who produces has money "in transit" at every moment: paper that has already come off the roll but is not yet a brochure, material consumed in step one while step two has yet to begin. If you do not post that, your balance sheet only reconciles at moments when nothing happens to be in production - and your result arises at random moments instead of at completion.

Manufacturing accounting solves that with a fixed principle: **consumption is debited to a work in progress account during production, and credited to the corresponding settlement account when the order is completed.** Between those two accounts the balance should be zero - unless something is genuinely in production. That outstanding balance *is* your work in progress. It is the same control idea as a suspense account: a balance that does not clear points to work still running (or to an error). This is also called the matching principle: costs and revenues land in the period they belong to, not at the moment the invoice happens to come in.

## The terminology: cost type, cost centre, cost object

Anyone who has ever struggled through a cost-accounting textbook recognises the thread of manufacturing accounting: costs flow through the administration in three steps.

- **Cost type** - *what* kind of costs they are: paper, material, machine hours, subcontracted work, labour. In the general ledger these are your cost accounts.
- **Cost centre** - *where* the costs arise: the printing press, the enveloping machine, a department. Each machine or work centre gets its own machine-hour rate, built up from depreciation, maintenance, space and utilisation.
- **Cost object** - *for what* the costs are incurred: the manufacturing order, and thereby ultimately the product or the customer. The cost object is where the estimate and job costing come together.

The bridge between cost centre and cost object is the **applied-overhead account**. At each operation a predetermined rate (the machine-hour rate or a surcharge percentage) is *credited* to the applied-overhead account and *debited* to work in progress: that way the order is already allocated its share of the indirect costs. At the end of the period the actual costs are set against it. If a balance remains on the applied-overhead account, that is the **absorption variance**, and you split it into two parts:

- the **budget variance** - were the actual costs higher or lower than budgeted?
- the **volume variance** - did you run more or fewer hours than the normal capacity the rate is calculated on? If you run below your normal capacity, part of your fixed costs remains "uncovered".

That is exactly the information a production company steers on: not just *whether* an order made a loss, but *why* - purchased too expensively (budget) or ran too little (volume).

> **Continental vs. Anglo-Saxon.** The posting flow in the video follows the continental (European) tradition: first all costs by cost type in the general ledger, then allocated on via cost centres to the cost object. Standard Odoo leans by default more towards the Anglo-Saxon method (costs directly to the product cost), supplemented with analytic postings. For genuine manufacturing accounting on a standard cost you set up the continental flow explicitly - that is what this approach adds.

## The building blocks: cost elements, journals and links

In the setup we show in the video, everything revolves around **cost elements**: per cost type (paper, machine hours, surcharges) you record which accounts are debited and credited, in which journal. You then link those cost elements to the operation in two places:

- **Product categories** (Inventory): all paper types fall into the category "paper", for example, and that category refers to the posting flow for work in progress paper.
- **Work centres** (Manufacturing): the printing press and the enveloping machine each have their own cost element (their own cost centre), so that machine costs per operation land on the right account.

The surcharge cost element is special: there you define a markup percentage on a base - in the demo 10% on paper consumption, as coverage for indirect costs. That surcharge is calculated automatically and posted to the applied-overhead account the moment the relevant step is completed. No manual journal entries, no forgotten markups.

One detail determines when a posting happens: in the bill of materials you record per component **in which operation it is consumed** (the "consumed in operation" column). The paper is consumed in the printing step - so that is where the work in progress posting arises, not only at the end.

## The posting flow, step by step

In the video we follow a manufacturing order of 1,000 units through two operations (printing and enveloping) - a print-shop example, but the principle is the same for any [production floor](/blog/can-odoo-run-your-production-floor):

1. **Work order "printing" completed** - three postings arise immediately: work in progress paper to paper (the material value), the automatic 10% surcharge to the applied-overhead account, and work in progress production to applied-overhead production (the machine costs at the machine-hour rate). Everything is immediately visible in the trial balance.
2. **Work order "enveloping" completed** - same principle for the second step: material, semi-finished product and production costs posted alongside.
3. **Complete the manufacturing order ("produce all")** - the finished product is posted to inventory at the **standard cost** (the estimate), and the difference with the actual production costs goes to a variance account. In the demo a negative difference: production was more expensive than the calculation - the **job costing** in a single posting, per order.
4. **Deliver and invoice** - the delivery is validated, the invoice confirmed, and the revenue appears in the balance sheet.

The proof is in the trial balance at the end: each work in progress account cancels out against its settlement account (debit 50, credit 50), and what remains is the result - built up from revenue, cost at standard cost and the efficiency variance. If an order is still running, you see exactly for what amount. That is how the **general ledger becomes a mirror of the factory**: what happens on the floor is in the figures at that same moment.

## Analysing: from trial balance to job costing per customer

The same figures can also be viewed from a production perspective: **Manufacturing → Reporting → Cost analysis** shows what is in the accounting, but with drill-down to the underlying manufacturing orders. With that a [job costing](/blog/job-costing-in-odoo) per manufacturing order can be built, and even per customer - handy if you want to know which orders or customers you actually earn on. The estimate is already in the standard cost; the difference is your job costing, without a separate time administration alongside your accounting.

## Honest about the status and about standard Odoo

Two honesties belong here.

**About standard Odoo.** Odoo works by default with a central WIP account per manufacturing order and posts the product cost when the order is completed. That is fine for many companies. If you want fine-grained work in progress *per operation step*, with separate applied-overhead accounts per cost type and an explicit variance analysis on a standard cost, that is not a standard button. Splitting cost by cost type and cost centre is in standard Odoo mainly a reporting and analytical question, not a general-ledger question - the approach in the video deliberately shifts part of that into the general ledger, because some companies (and accountants) simply want to see it in the posting itself.

**About this demo.** What the video shows is a first version of this setup, built as a demonstration of the principle. Labour costs and subcontracted work are not yet in the demo (both can be set up with standard Odoo means - for subcontracting see also subcontracting while retaining traceability), and edge cases such as cancelling or interrupting a manufacturing order still need finishing. The definitive setup - which cost elements, which surcharges, which chart of accounts - we determine per company during the implementation, [fit-gap first](/target). That is how customisation on the accounting should arise too: first prove the principle, then build for production.

## Frequently asked questions

**What is manufacturing accounting?**
The administrative side of producing: material consumption, machine hours and surcharges are posted to work in progress during production and settled to finished-goods inventory when completed. Your balance sheet shows at any moment what is in production. Factory accounting, production accounting and cost accounting are other names for the same thing.

**What is the difference between an estimate and job costing?**
An estimate is the cost calculated in advance (which you quote with and use as the standard cost); job costing is what the order actually cost. The difference between the two - the budget and volume variance - lands automatically on a variance account in this posting flow, per order.

**What is an applied-overhead account and a volume variance?**
The applied-overhead account absorbs the pre-allocated indirect costs (via surcharge or machine-hour rate). The balance that remains is the absorption variance, to be split into a budget variance (actual costs vs. budgeted) and a volume variance (hours run vs. normal capacity).

**Does Odoo post work in progress per production step by default?**
By default Odoo posts inventory movements and product cost when the order is completed, with a central WIP account per order. Fine-grained work in progress per operation step with surcharges and applied-overhead accounts is set up with an additional module, as in the video.

**How does a standard cost work in Odoo production?**
Finished product is posted to inventory at the standard cost; the difference with the actual production costs goes to a variance account. That way you see per period and per order whether your calculation holds.

**Can I have surcharges posted automatically?**
Yes - per cost element you define a percentage on a base (for example 10% on material consumption as coverage). The posting happens automatically when the step is completed.

**Can I analyse the production result per order or per customer?**
Yes, via manufacturing cost analysis, with drill-down to the underlying manufacturing orders - the basis for a job costing per order and per customer.

**Why do the work in progress accounts cancel out against each other?**
Every debit during production is credited to the settlement account when completed. Zero balance means: nothing left in production. An outstanding balance *is* your work in progress - the built-in control of this posting flow.

---

**Want to know what manufacturing accounting would look like for your production?** [Book a free Odoo scan](/scan) - then we walk through your production steps, cost centres and calculation and are honest about what works out of the box and where setup or customisation is needed.

---

**Read more:** [Job costing: from estimate to actual product cost](/blog/job-costing-in-odoo) · [Odoo for production companies](/industries/manufacturing) · [Can Odoo run your production floor?](/blog/can-odoo-run-your-production-floor) · Subcontracting while retaining traceability · [Software for construction companies](/software-for-construction-companies) · [Software for field service installers](/software-for-field-service-installers) · [What does an Odoo implementation cost?](/pricing/calculator) · [The TARGET method](/target)


# The Odoo Success Pack: when it works, and when to call a partner instead
URL: https://www.fanatics.nl/blog/odoo-success-pack
Language: en

**Short answer:** the Odoo Success Pack is a bundle of consultancy hours bought directly from Odoo, and for a small company with one or two users and standard needs it is a perfectly good, affordable start. But once local accounting, integrations, customisation or multiple departments enter the picture, a 50-hour pack does not buy you an implementation - it buys you the beginning of one, without telling you how long the rest will take. This page explains honestly how the model works, who it fits, and where we see it strain in practice.

Honesty first: we are a Dutch Odoo partner, so we have a stake here. Read this with that in mind. But we are also fans of Odoo as a product - we would not do this work otherwise - and for the right companies the pack genuinely is the better choice. We write this because we speak to too many companies that only discovered what they had bought after the pack ran out.

## How it typically goes: demo, then a pack

The pattern we keep seeing: a company requests a demo at odoo.com, gets a call from a sales rep, the demo is good - Odoo demos remarkably well - and a proposal follows quickly: licences plus a Success Pack, often around 50 hours.

There is nothing dishonest about that. It is Odoo's sales model: the company steers on licences and on hours, and the pack is the standardised way to sell those hours. But it helps to see the offer for what it *is*: a commercial proposal based on a demo, not an estimate based on your processes. At the moment the pack lands on the table, nobody has usually seen your accounting, your stock flows or your integrations.

## What you buy (and what you do not)

A Success Pack is a prepaid credit of consultancy hours. An Odoo consultant configures the system with you remotely, in video sessions. That works, and the hourly rate is sharp.

What you do *not* buy - and what many buyers only notice later:

- **A total estimate.** Odoo rarely gives a substantiated up-front estimate of the total hours your implementation will take. When the pack runs out and you are not done, you buy more. Ask insistently and you may be advised a bigger pack up front, but the initiative sits with you.
- **Someone on site.** The pack is remote. No on-site workshops, nobody who sees your warehouse or sits next to your finance team.
- **A consultant of your choosing.** Odoo has grown very fast for years, which inevitably means many new consultants. You cannot choose or vet who you get; experience varies widely per person.
- **Local depth.** VAT logic, statutory filings, audit files, bank integrations, e-invoicing, what your accountant expects: this is local terrain, and it is exactly where internationally operating consultants most often fall short. In our Dutch practice, gaps around Dutch accounting rules are the single most common reason pack customers end up calling us.

And there is a softer factor we often hear first from customers who came to us from a pack: working style. Speaking (roughly) the same language as your assigned consultant does not mean sharing the same mentality. Dutch SMEs tend to want direct, pragmatic, sometimes bluntly honest sparring - and that is not always what the pack format delivers.

## Who the pack genuinely fits

This needs saying, because the pack gets more flak online than it deserves. The Success Pack is a sound choice if:

- you start with **one or two users**;
- your needs stay **close to standard Odoo**: CRM, quotes, invoicing, a simple webshop;
- you need **no integrations or custom development**;
- your accounting is simple, or stays outside Odoo for now;
- you have the time and appetite to learn and configure yourself.

For that profile the pack is affordable, low-threshold and fast - and a full partner project is honestly overkill. Odoo is, moreover, simply an excellent product; the easy on-ramp is one of the reasons it grows as fast as it does, and deservedly so.

## Where it strains: a beginning without an end

The problem is not that the pack is bad. The problem is that it gets sold to companies it was never meant for: companies with inventory, accounting, multiple departments, a data migration or integrations. For those companies, 50 hours is not an implementation but a down payment - with no total figure underneath it.

For scale: a [serious Odoo implementation](/blog/what-does-an-odoo-implementation-cost) quickly runs to several hundred hours, and [the timeline](/blog/how-long-does-an-odoo-implementation-take) is driven by scope and internal availability, not by the size of the hour bundle. Start such a project on a 50-hour pack and you will inevitably reach the point where the hours are gone and the work is not. Two options remain: buy more hours (again without a total picture), or find a partner after all - with a half-configured system as the starting point.

We see that second route regularly. Recently a family-owned services company of around 35 people came to us, with a planning-heavy field team. They had started via the direct route and gradually discovered that their real needs - smart scheduling, a customer portal, invoicing that matches Dutch practice - required a fit-gap analysis, a scoping table and deliberate customisation choices that loose remote hours cannot deliver. Not because the consultant lacked goodwill, but because the model is not built for it. We started where every predictable project starts: [fit-gap first, build second](/target).

## Pack or partner: the honest decision aid

**Go ahead with the Success Pack if:**

- you start small (1-2 users) with standard processes;
- there are no integrations, customisation or data migration involved;
- your accounting is simple and you want to learn the system yourself;
- you want to explore Odoo before investing more seriously.

**Call a (local) partner if:**

- accounting, VAT and reporting must be exactly right for your local practice;
- integrations or custom development are on the table;
- Odoo touches multiple departments and data has to be migrated;
- you want a total estimate and a fixed scope up front instead of an hour bundle;
- you want someone who visits, sees your processes and dares to say no when that is better for your organisation.

If you are torn, put the same question to every provider - Odoo itself and any partner: *"what will my implementation cost in total, and what is that estimate based on?"* A provider who wants to see your processes before naming a number is taking you seriously. A number that arrives within an hour of the demo is a sales price, not an estimate.

The broader trade-off between going direct and working with a partner - including when you genuinely do not need one - is covered in [Odoo directly or via a partner?](/blog/odoo-direct-or-via-a-partner)

## Frequently asked questions

**What is an Odoo Success Pack?**
A prepaid bundle of consultancy hours (typically 25, 50, 100 or more) bought directly from Odoo alongside your licences. An Odoo consultant helps you configure the system remotely. It is a bundle of hours, not a project with a fixed scope or end date.

**How much does an Odoo Success Pack cost?**
Pricing varies by region and pack size, but the hourly rate is competitive. The catch is not the rate but the total: the pack is sold without a substantiated estimate of the total hours you will need.

**Are 50 hours enough for an Odoo implementation?**
For one or two users with standard processes: often yes. For a company with accounting, inventory, multiple departments, data migration or integrations: almost never. Ask for a total estimate up front.

**Why am I offered a Success Pack right after my demo?**
Because that is Odoo's sales model: licences plus hours. Legitimate, and not expensive - but the offer usually arrives before anyone has reviewed your processes.

**Does an Odoo consultant know local accounting rules?**
Not necessarily. Odoo grows fast and operates internationally; you cannot choose who you get. Local VAT logic, filings and bank integrations are exactly where a local partner makes the difference.

**Can I switch from a Success Pack to a partner?**
Yes, this happens regularly and your licences remain in place. The earlier the better: early choices about data structure and chart of accounts are hard to unwind later.

---

**Already have a Success Pack quote on the table, or halfway through a pack and in doubt?** [Book a free Odoo scan](/scan) - we will give an honest second opinion on the proposed hours and configuration. And if the conclusion is that the pack is fine for you, that is exactly what we will say.

---

**Read more:** [Odoo directly or via a partner?](/blog/odoo-direct-or-via-a-partner) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost) · [How long does an Odoo implementation take?](/blog/how-long-does-an-odoo-implementation-take) · [The TARGET method](/target) · [Odoo implementation checklist](/blog/odoo-implementation-checklist)


# Odoo implementation checklist: 26 checkpoints from preparation to go-live
URL: https://www.fanatics.nl/blog/odoo-implementation-checklist
Language: en

*Search for an Odoo implementation checklist and you will mostly find lists of thirty loose tips. The problem of an implementation is rarely a missing tip - it is a missing **order**. So below is not a tips list but the runbook: **seven phases, 26 checkpoints**, from appointing your project lead to closing the project after the buffer period. Free to use, whichever partner you work with - and [downloadable as a checkable PDF](https://www.fanatics.nl/downloads/odoo-implementation-checklist-en.pdf), no form in front of it.*

## Download the checklist as a PDF

**[Download the Odoo implementation checklist (PDF)](https://www.fanatics.nl/downloads/odoo-implementation-checklist-en.pdf)** - checkable, in colour, with links to the matching tools. Print it and pin it to the project board. Also available in [Dutch](https://www.fanatics.nl/downloads/odoo-implementatie-checklist-nl.pdf) and [German](https://www.fanatics.nl/downloads/odoo-implementierung-checkliste-de.pdf).

## Phase 0 - Preparation

The phase most often skipped, and the phase where the project is already won or lost. Before anyone configures anything:

- **Appoint one internal project lead (SPOC)** and make their availability explicit - [it sets the pace more than any technical choice](/blog/how-long-does-an-odoo-implementation-take).
- **Assign a key user per process** who decides, tests and later supports colleagues - [what a key user actually does](/blog/what-is-a-key-user).
- **Pick your go-live date and count back**, including two months of buffer for testing and overrun - the [go-live planner](/odoo-go-live-planner) does it in a minute.
- **Set a budget frame based on scope**, not the other way round - [what an implementation costs](/blog/what-does-an-odoo-implementation-cost).

## Phase 1 - Fit-gap & scope

This is where the project gets made predictable - or not. It is the phase we spend the most time on, for a reason:

- **Map per process what actually happens**, not what the manual says.
- **Record per line: standard, configuration or custom.** This becomes the scoping table that turns the project into a predictable one - the core of [our TARGET method](/target).
- **Name every integration separately and request the specifications now.** Third parties set their own pace; whoever requests specs during the build, waits during the build.
- **Assess data quality honestly.** Migrating clean data is a task; cleaning it first is a sub-project.
- **Agree a definition of done per process** before anything gets built.
- **Decide what goes live in phase one and what deliberately comes later.** Scope is a dial, not a given.

## Phase 2 - Configuration

- **Set up the chart of accounts and reporting structure first** - everything books back to it, and redistributing afterwards is manual labour.
- **Configure roles and permissions** before the first user enters the system.
- **Build the main flow working end to end**: quote, order, delivery, invoice.
- **Start integrations as early as possible** and test them with real data.

## Phase 3 - Data

- **Clean the source data in the old system**, not during the migration.
- **Run a trial migration** and have key users validate the outcome - they recognise what is missing.
- **Agree a date after which the old system is frozen.** Two living systems is not a transition but a second administration.

## Phase 4 - Testing & training

- **Have key users test with real scenarios** from their own practice, not demo data.
- **Collect findings on one list and triage**: blocking, before go-live, or after.
- **Train end users on their own work**, not on the whole system.

## Phase 5 - Go-live

- **Fix go/no-go criteria up front** and agree who decides.
- **Write a cutover runbook**: what moves when, and what the fallback is.
- **Plan hypercare**: short lines and daily check-ins in the first weeks.

## Phase 6 - After go-live

The phase missing from most checklists, and the difference between a system that lands and a system that gets tolerated:

- **Keep one wish list** and schedule further development in a fixed rhythm.
- **Evaluate with the key users after a month**: what works, what grates.
- **Close the project only once** the buffer-period findings are resolved.

## The honest footnote to every checklist

A checklist feels like grip, but the paper is not the work. The two checkpoints projects genuinely strand on are not the technical ones: they are the project lead who is not given the time, and the scoping table that gets skipped because "we know what we want". Take those two seriously and you can work through the rest of this list with confidence - skip them, and no checklist will save you.

Want the complete approach behind this checklist, with the why per step: it is in our book **"How we do Odoo"** - [free to download](/book), and also without a form full of mandatory fields.

---

**Rather walk the checklist along your own situation together?** [Book a free Odoo scan](/scan) - we go through the phases with your processes as the starting point, and we are honest about where the risks sit.

---

**Read more:** [Odoo implementation: are you ready?](/odoo-implementation) · [How long does an Odoo implementation take?](/blog/how-long-does-an-odoo-implementation-take) · [Go-live planner](/odoo-go-live-planner) · [What is a key user?](/blog/what-is-a-key-user) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost) · [The TARGET method](/target)


# Digital work orders: what belongs on one, what an app costs and when to look further
URL: https://www.fanatics.nl/blog/digital-work-orders
Language: en

*Let us be honest: the paper docket book is all but extinct. Nearly every field-service company now works with a digital work order, usually in a standalone app. **And yet that digital order still produces manual work: it sits in the app, while the invoice, the hours and the stock sit somewhere else.** This is what belongs on a good work order, when a standalone app simply suffices, and the moment the work order should really be the start of your invoice.*

## From docket book to app: half the problem solved

Anyone still peeling a carbon copy off the dashboard has become a rarity. The standalone work-order app has largely solved the old paper problems - illegible, lost, slow to arrive - and that is real progress: the technician fills in the order on site, the customer signs on screen, and the order is at the office instantly.

But watch what happens at the office once that order comes in. The hours have to reach time registration, the materials have to come off stock, and the order has to become an invoice - and those systems do not know the app. So retyping happens anyway, just from a screen instead of a carbon copy. The order got digitised; the process behind it did not. That is the half of the problem that remains, and what the rest of this piece is about.

## What belongs on a work order

Anyone searching for a work-order example is really searching for this list. The fixed parts:

- **Customer and site address** - who, and where the work was done
- **Date and time** - including arrival and departure if you invoice by the hour
- **Description of the work** - what was done, in language both the customer and the invoice understand
- **Hours per technician** - time worked, split by rate if needed
- **Materials with quantities** - what was used, because this becomes the invoice line and the stock deduction
- **Extra work and remarks** - precisely the work that was not agreed up front, because that is where the discussion otherwise starts
- **Photos** - the situation before and after, the best evidence there is
- **The customer's signature** - the closing piece that makes the invoice indisputable

Those last two are what paper never did well, and where digital makes the difference: evidence and agreement, captured on the spot.

## The standalone app - and the question to ask first

There are perfectly good standalone work-order apps; in the Netherlands, [Simple-Simon](/odoo-vs-simple-simon) is the best known. For a small team that only wants to replace the docket book, such an app is a real option: quick to set up, low-threshold, and it genuinely solves the paper problem.

But ask one question first: **is the work order your end point, or your starting point?** If the order is finished once it is filled in, a standalone app will do. But at most installation and service companies, that is where it starts: the hours have to reach time processing, the materials have to come off stock, and the whole order has to become an invoice. With a standalone app that means an integration to your administration - or, more often in practice, someone at the office retyping everything. And with that, the old problem is back, just more legibly.

## The work order as the start of your invoice

That is why the most interesting question is not which work-order app looks nicest, but where the order lives. In Odoo, the work order (Field Service) is part of the same system as your planning, your stock and your invoicing. That changes what an order is: the hours on it are instantly registered hours, the materials are instantly deducted from stock, and the "invoice" button turns the signed order into an invoice - the same afternoon, without anyone retyping anything.

For an installation or service company, that is the real difference: not a tidier docket, but invoicing that is days to weeks faster and zero vanished work. What that looks like in full is on our page for [installation companies](/software-for-field-service-installers) and the industry page [field services & installation](/industries/field-services).

## Honestly: when a standalone app simply suffices

If you are two or three people, invoice fixed amounts per job and your bookkeeper handles the administration: then a standalone work-order app or even a good template is fine for now. The gain of integration sits in volume - many orders, many materials, hours that have to become invoices. If you are not there yet, do not buy a platform for a docket problem. If you are, the standalone app is the patch you will be replacing again in a year.

## In short

The docket book is all but gone and the standalone app solved the paper problems - the retyping at the office it did not. A good order carries customer, time, work description, hours, materials, extra work, photos and a signature. A standalone app suffices as long as the order is the end point; once the order is the start of your invoice, time processing and stock deduction, an order that lives in the same system as the rest wins. And for a small team without that volume: start simple with confidence, and know where the tipping point sits.

---

**Curious what the work-order-to-invoice route looks like for your field service?** [Book a free Odoo scan](/scan) - we take your current docket flow as the starting point.

---

**Read more:** [The best software for installation companies (2026)](/blog/best-software-installation-companies) · [Software for field service & installers](/software-for-field-service-installers) · [Odoo vs Simple-Simon](/odoo-vs-simple-simon) · [Field services & installation](/industries/field-services) · [What is an ERP system?](/blog/what-is-an-erp-system)


# What is CRM? Meaning, what a CRM system does and when you need one
URL: https://www.fanatics.nl/blog/what-is-crm
Language: en

*CRM is an abbreviation just like ERP: everyone uses it, almost nobody explains it. So here is the explanation: **CRM stands for Customer Relationship Management - one place where your customers, touchpoints and sales opportunities come together.** This is what a CRM system concretely does, the difference with ERP, the well-known examples side by side - and the honest tipping point where a standalone CRM starts to hurt.*

## The meaning, without the jargon

Customer Relationship Management sounds like a management book, but the idea fits on a beer mat: **everything about a customer in one place, and nothing slipping through the cracks.**

In a company without CRM, customer knowledge lives scattered. The history sits in the account manager's mailbox, the agreements in their head, the quote in a folder, and why that one deal fell through is known only to the colleague who has since left. While the team is small, that works. Until it does not.

A CRM system turns that around. Every customer is one record with everything attached: contacts, conversations, emails, quotes, open opportunities. Whoever opens the record sees the whole relationship at a glance - even when the colleague who owns it is on holiday.

## What a CRM system concretely does

Three things, and all three are simpler than vendors make them sound.

**The customer picture.** All knowledge about a relationship in one place, instead of in mailboxes and heads. That is the foundation the rest sits on.

**The pipeline.** Your sales process in stages: lead, qualified, quote, negotiation, won. Every opportunity hangs in a stage, and the board shows in one glance what is coming, what is stalling and where it sticks. That makes sales steerable instead of hopeful.

**The follow-up.** Tasks, reminders and automatic actions. "I was going to call them back" is the most expensive sentence in sales - not because calling is hard, but because it evaporates. A CRM does not let it evaporate.

## The difference with ERP - and where it grates

The shortest summary: **CRM manages the promise, ERP manages the delivery.** CRM runs from first contact to won deal; [ERP](/blog/what-is-an-erp-system) picks it up from there - order, stock, delivery, invoice, accounting.

That handover is exactly where separate systems go wrong. The deal sits in the CRM, but the order has to enter the administration - so somebody retypes it. The prices in the CRM drift from the price list in the ERP. And the account manager who wants to know whether their customer has paid has to ask a different system. Each of those seams is small; together they are the reason "just a CRM on the side" ends up costing more than it looked.

That is why platforms like Odoo contain both sides on one data model: the won quote becomes the order, without a handover. That is not a CRM feature; it is the removal of the seam.

## The well-known examples, honestly characterised

**[Salesforce](/odoo-vs-salesforce)** is the market leader and the benchmark for large sales organisations: extremely rich, extremely configurable, with a price tag and a consultancy ecosystem to match.

**[HubSpot](/odoo-vs-hubspot)** is strong on the marketing side: inbound, email flows, content. Entry is free and smooth; the bill grows with every module you add.

**[Zoho](/odoo-vs-zoho)** and Pipedrive are the accessible middle class: set up quickly, decent pipeline, less depth once the processes behind sales arrive.

**[Microsoft Dynamics](/odoo-vs-dynamics)** leans on the Office world: strong when your organisation already sits deep in Microsoft, delivered through partners.

**Odoo CRM** - we build Odoo, so factor in our colour - is deliberately not a standalone CRM but part of a broader platform: the same customer, the same products and the same numbers from lead to payment. The strength is not more CRM features, but the absence of the handover.

## When are you ready for one?

The signals are more recognisable than the vendor checklists:

**Follow-up evaporates.** Leads sit untouched because nobody guards them. You do not lose deals on price, but on silence.

**The customer picture lives in heads.** When the account manager leaves, the relationship leaves with them. That is not a staffing risk but a systems risk.

**The Excel list is the pipeline.** Works until two salespeople edit the same list at once, or until management asks what is really in the funnel.

And the honest counterweight: with a handful of customers and one salesperson, a CRM system is overkill. A tidy list and discipline beat any tool that is not kept up. The tipping point comes with the team - and with the moment the deal has to go somewhere after it is won.

## In short

CRM stands for Customer Relationship Management: one place for your customer picture, your pipeline and your follow-up. The difference with ERP sits in the handover - CRM manages the promise, ERP the delivery - and that handover is exactly where separate systems cost time and errors. Salesforce, HubSpot, Zoho and Dynamics are the well-known standalone players; in Odoo, CRM is part of the whole, so the seam disappears. And if you are small and disciplined: a tidy list is fine for now, and we will happily say so.

---

**Curious what CRM looks like when it is attached to your quotes, orders and invoices?** [Book a free Odoo scan](/scan) - we will show it with your processes as the starting point.

---

**Read more:** [What is an ERP system?](/blog/what-is-an-erp-system) · [Odoo vs Salesforce](/odoo-vs-salesforce) · [Odoo vs HubSpot](/odoo-vs-hubspot) · [Compare ERP systems](/blog/compare-erp-systems) · [Odoo alternatives](/blog/odoo-alternatives)


# Odoo alternatives: by process, by sector and open source - honestly compared
URL: https://www.fanatics.nl/blog/odoo-alternatives
Language: en

*Anyone typing "Odoo alternatives" is one of three people: you are comparing Odoo against point solutions per process, you are wondering whether an industry specialist fits better, or you have a quote on the table and doubts in your head. All three deserve an honest answer - and that is what this page gives, including the two lists you rarely find at an Odoo partner: **the sector specialists that sometimes genuinely win, and the open-source alternatives** most partners prefer not to mention. And yes: we build Odoo, so factor in our bias. That is exactly why the list below includes alternatives we do not sell.*

## First, the inverted list: what are you actually replacing?

Most searches for an Odoo alternative start with one process: you need a CRM, a webshop, a POS. The honest answer per process is below - and notice what happens as you read. Each of these categories is, with the alternative, a separate package with its own login, its own invoice and an integration that you get to maintain. In Odoo it is one module on the same data model.

| Process | In Odoo | Point-solution alternatives |
|---|---|---|
| CRM & sales | Odoo CRM | [Salesforce](/odoo-vs-salesforce), [HubSpot](/odoo-vs-hubspot), [Zoho](/odoo-vs-zoho) |
| Accounting | Odoo Accounting | [Exact](/odoo-vs-exact), [Twinfield](/odoo-vs-twinfield), [Moneybird](/odoo-vs-moneybird), [SnelStart](/odoo-vs-snelstart) |
| Webshop | Odoo eCommerce | [Shopify](/odoo-vs-shopify), [WooCommerce](/odoo-vs-woocommerce), [Lightspeed](/odoo-vs-lightspeed) |
| Point of sale | Odoo POS | [Lightspeed](/odoo-vs-lightspeed) |
| Stock & orders | Odoo Inventory | [Brincr](/odoo-vs-brincr), [Logic4](/odoo-vs-logic4) |
| Manufacturing | Odoo Manufacturing | [MRPeasy](/odoo-vs-mrpeasy), [Ridder iQ](/odoo-vs-ridder-iq), [MKG](/odoo-vs-mkg) |
| Projects & time | Odoo Project | [Gripp](/odoo-vs-gripp), [Teamleader](/odoo-vs-teamleader), [Monday](/odoo-vs-monday) |
| Work orders & field service | Odoo Field Service | [Simple-Simon](/odoo-vs-simple-simon) |
| Building processes | Odoo Studio | [Airtable](/odoo-vs-airtable) |
| HR & payroll | Odoo HR | [AFAS](/odoo-vs-afas), [Visma](/odoo-vs-visma) |

This is the point the table makes without us having to shout it: **the "alternative to Odoo" is usually not a package but a stack of packages.** Five tools, five logins, five invoices and four integrations - that is the real comparison. Sometimes that stack is still the right choice (more below), but then make the comparison complete, glue included.

If you are looking for a full platform as the alternative, [Dynamics 365 Business Central](/odoo-vs-dynamics), [NetSuite](/odoo-vs-netsuite), [AFAS](/odoo-vs-afas) and [SAP Business One](/odoo-vs-sap) are the usual candidates - internationally, Sage joins that list. Each has its own honest comparison behind the link.

## The sector specialists: sometimes they genuinely win

You will not often find this list at an Odoo partner, which is exactly why it belongs here. For some industries a vertical package covers the industry process so deeply that it wins the broader trade-off. We would rather say that up front than have you discover it during an implementation.

| Sector | Specialist | When the specialist wins |
|---|---|---|
| Car leasing | [LeaseWise](/odoo-vs-leasewise) | When your challenge sits in the lease core: calculation, contracts and the Dutch chain integrations |
| Print & sign | [MultiPress](/odoo-vs-multipress), [Prindustry](/odoo-vs-prindustry) | When graphic calculation and print workflow drive your entire process |
| Metal & machine building | [MKG](/odoo-vs-mkg), [Ridder iQ](/odoo-vs-ridder-iq), [Isah](/odoo-vs-isah), [Bemet](/odoo-vs-bemet) | For heavy make-to-order manufacturing with deep calculation - [our comparison for metal companies](/blog/best-erp-for-metal-companies) |
| ETO machine building | [Trimergo](/odoo-vs-trimergo) | For project-driven engineer-to-order with complex project planning |
| Installation trade | [Syntess](/odoo-vs-syntess) | When installation calculation and work orders are the core and the forced cloud migration does not bother you |
| Healthcare & charities | [Pluriform](/odoo-vs-pluriform) | When a proven Dutch vertical (care records, fund administration) drives your entire process |

The common thread in all these trade-offs: **the specialist knows the industry, Odoo connects the company.** If the industry process is your whole story, the specialist can be the better choice. If the industry is one part of a broader company - with its own import, e-commerce, multiple entities - it tips towards one platform. And there is a middle road: specialist for the core, Odoo around it, provided it is clear up front which system leads.

## The open-source alternatives nobody names

Odoo is itself open source - the Community edition is free and the code is public. But Odoo is not the only open-source ERP, and anyone selecting on openness deserves the full list. So here it is, with the honest trade-off per system.

**ERPNext** is the most serious open-source alternative to Odoo: a full ERP on the Frappe framework, MIT licence, an active international community and modern architecture. The trade-off: the app ecosystem is a fraction of Odoo's, localisation (bank feeds, tax filings) is more limited, and implementation partners are far scarcer.

**Dolibarr** is the lightweight: a PHP-based open-source ERP/CRM that is especially popular in France. For a small organisation with simple processes it can be fine; it runs out sooner as stock, manufacturing or multi-company get serious.

**Tryton** shares its roots with the early Odoo lineage (both descend from TinyERP) and chose architectural purity over ecosystem. Technically tidy, but the community and partner network are small - you need to bring a lot yourself.

**Axelor** is the low-code alternative: a French open-source platform that combines ERP with a BPM engine, so you build processes visually. Interesting for heavy custom workflow; the local ecosystem outside France is thin.

The pattern across all four: **open source is not the differentiator - Odoo is open source too.** The differentiator is the ecosystem around it: apps, localisations, partners you can swap. That is not an argument against these systems; it is the due-diligence question you must ask each of them. Whoever wants maximum openness with a mature ecosystem ends up back at Odoo in practice - and that is not a sales pitch but a countable property: compare the number of apps, localisations and local partners.

## Doubting a quote? That is a different conversation

A good share of the people searching "Odoo alternatives" already have an Odoo quote and feel doubt. That deserves a more precise answer than a list of alternatives, because the doubt is rarely about the platform. It is about the scope ("does all of this have to happen?"), the price ("is a thousand hours normal?") or the partner ("do they actually get us?").

For that there are two routes that cost nothing. **A second opinion on your quote**: we walk through it line by line - what is standard, what is configuration, what is genuinely custom, and does the ratio make sense. Including when the conclusion is that the quote is simply good; then that is what we say. And if you are already on Odoo but the collaboration grates: [switching Odoo partners](/blog/switching-odoo-partner) is easier than most companies think, precisely because the code and the data are yours.

## In short

The best Odoo alternative depends on what you are really looking for. Per process there are strong point solutions - but count the glue, because five packages with four integrations is the real comparison. Per sector there are specialists that sometimes genuinely win, and we say honestly when. Open source is not a differentiator but a starting point: ERPNext, Dolibarr, Tryton and Axelor are the real open-source alternatives, each with a smaller ecosystem as the price. And if you are doubting a quote that is already on the table: that is usually not a platform question but a scope question - and a second opinion helps faster than a switch.

---

**Still want a conversation about Odoo? Or a second opinion on your current Odoo quote?** [Book a free scan](/scan) or [get in touch](/contact) - we take an honest look, including when the answer is "the specialist" or "your current quote is fine".

---

**Read more:** [What is an ERP system?](/blog/what-is-an-erp-system) · [Compare ERP systems](/blog/compare-erp-systems) · [Switching Odoo partners](/blog/switching-odoo-partner) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost) · [All comparisons](/compare)


# What is a key user? The role that makes or breaks your ERP implementation
URL: https://www.fanatics.nl/blog/what-is-a-key-user
Language: en

*Every ERP implementation has a few of them, and yet almost everyone who gets the role first looks up what it actually is: the **key user**. The short answer: the employee who represents their department during the implementation - they know the process, co-decide on the configuration, test the system and later train their colleagues. The long answer is more interesting, because this role makes or breaks your project. This is what a key user does, how much time it takes, how the role differs from project lead and application management, and how to pick the right people.*

## The definition, and why the role exists

A key user is an ordinary employee with a temporary extra role: during an ERP or software implementation, they are the voice of their department or process. Sales, purchasing, warehouse, accounting - each core process ideally has one.

Why does the role exist? Because an implementation partner can configure your system, but does not know your company. The consultant knows what Odoo can do; the key user knows how things really work at your company - including the exceptions that appear in no process description. Without that knowledge, a system gets configured for how the work should run, and that is rarely how it runs. The key user is the bridge: they translate daily practice into configuration choices, and later the new system back to their colleagues.

## The four tasks, and the fifth that comes with them

In practice the role comes down to four things, in the order of the project.

**Explaining the process.** At the start - in our case in the fit-gap analysis - the key user explains how their process works. Not the paper version, but the real one: where the exceptions sit, which steps quietly happen in Excel, what goes wrong when someone is ill. The more honest this story, the better the scoping table that follows from it.

**Co-deciding on the configuration.** Which fields are mandatory, which statuses does an order have, is that one exception worth configuring or do we abolish it? These are not IT questions but process questions, and the key user is the one who can answer them.

**Testing with real cases.** Not clicking through the happy flow, but rebuilding last month's difficult order. The best key users test with a list of real practical cases - every mistake they catch does not go live.

**Training colleagues.** Around go-live, the key user trains their own team, in the language of their own work. That works better than a generic external training: the explanation is about your orders, your customers, your exceptions. In our TARGET method this is a step of its own - training end users on their own work, not on the system in general.

And then the fifth, which often goes unagreed: **after go-live, the key user is the first point of contact.** Small questions they resolve themselves; real problems they escalate. Agreeing this up front prevents the partner's helpdesk from filling up in the first weeks with questions that could have been answered internally in thirty seconds.

## How much time does it really take?

More than most companies budget. In the busy phases, count on **half a day to a full day per week per key user**, with peaks around testing and go-live. And here is the point we bring back in every [timeline estimate](/blog/how-long-does-an-odoo-implementation-take): that time is not a cost item but the biggest accelerator of the project. Decisions that sit for days because nobody has time are the quietest delayer of every implementation.

The pitfall is predictable: the company appoints its best people as key users - logical, they know the process best - but frees up no hours. Then the key user does it "on the side", on Friday afternoons, and every test round slips a week. Whoever takes the role seriously plans it in: formally, in the agenda, with work that temporarily lands elsewhere.

## Key user, project lead, application management: who does what

Three roles that get mixed up, with a simple dividing line.

The **project lead** (in our projects the SPOC) oversees the whole: planning, scope, budget, decisions that cross departments, and the daily contact with the implementation partner. One person, with mandate. In our [go-live planner](/odoo-go-live-planner), the availability of this role weighs heavily in the timeline - not for nothing.

The **key users** each cover one process. They do not decide on the planning, but they do decide how their process lands in the system. Rule of thumb: the project lead decides *what* and *when*; the key users determine *how*.

**Application management** is not a project role but a structural one: maintaining the system after go-live - users, permissions, settings, small changes. In SMBs the most involved key user often grows into this, and that is a fine route, as long as it is a conscious choice with the time to match rather than something that silently gets added.

Together these roles form your project team: one project lead, a key user per core process, and a plan for management after go-live. There really are no more flavours - and no more are needed.

## How do you pick the right key users?

Not by hierarchy. The department manager is by no means always the best choice; the person who does the work daily usually is. Three criteria that matter in practice:

**Process knowledge including the exceptions.** The best key user is the person colleagues already turn to when something gets stuck. That person knows not just the rule, but the ten exceptions to it.

**Daring to have an opinion.** The role demands choices: this we configure, that we abolish. Someone who finds everything "fine either way" delivers a system that stands for nothing. Being allowed to be critical - including towards their own manager and towards us - is a job requirement.

**Standing in the team.** The key user will become trainer and point of contact. Someone the team trusts brings colleagues along; someone seen as a controller does not.

And one anti-criterion: do not pick only the biggest enthusiast. A healthy sceptic who did not trust the system at first and does after testing is worth more at go-live than ten cheering early adopters.

## In short

A key user is the process representative during an ERP implementation: they explain the real work, co-decide on the configuration, test with real cases, train their colleagues and remain the first point of contact after go-live. The role takes half a day to a full day per week and is, together with an available project lead, the biggest accelerator of any project. Pick on process knowledge, backbone and standing - not on job title - and formally free up time for it. Get that right, and the most important part of your project team is in place.

---

**Building your project team for an Odoo implementation?** [Book a free Odoo scan](/scan) and we will discuss which roles your project needs - or first run your [timeline and go-live date](/odoo-go-live-planner).

---

**Read more:** [How long does an Odoo implementation take?](/blog/how-long-does-an-odoo-implementation-take) · [The go-live planner](/odoo-go-live-planner) · [The TARGET method](/target) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost)


# What is an ERP system? Meaning, examples and when you need one
URL: https://www.fanatics.nl/blog/what-is-an-erp-system
Language: en

*ERP is one of those abbreviations everyone uses and almost nobody explains. So here is the explanation: **ERP stands for Enterprise Resource Planning - one system in which your core processes work together on one data model.** Sales, purchasing, stock, manufacturing and accounting look at the same customers, the same products and the same numbers. This is what that means in practice, seven well-known examples side by side, the signals that your company is ready - and the honest story about when you do not need one yet.*

## The meaning, without the jargon

Enterprise Resource Planning is an eighties name that sells the idea badly, so forget the words for a moment and hold on to the picture: **one system, one data model.**

In a company without ERP, every department lives in its own world. Sales works in a quoting tool, the warehouse in a stock list, the accountant in an accounting package, and between those worlds data travels by email, export and retyping. Every handover is a chance for errors, and nobody looks at the same number.

In an ERP system those worlds do not exist. A customer is one record, whether sales calls them or accounting sends a reminder. A product is one record, with one stock figure that the webshop, the warehouse and the buyer all three see. And the chain hangs together: the quote becomes the order, the order the delivery, the delivery the invoice - and the accounting follows automatically. That is the whole trick. No magic, but discipline: everything on one data model.

## ERP versus accounting software versus CRM

The three terms blur together in conversations, so let us be precise.

**Accounting software** records what has happened financially. It is the terminus of your processes, not their engine. Excellent as long as the processes themselves are manageable.

A **CRM** manages the front end: leads, opportunities, follow-up. It usually stops the moment the deal is won - exactly where the real work starts. What a CRM does precisely is covered in [what is CRM](/blog/what-is-crm).

An **ERP** connects both with the execution in between: orders, stock, purchasing, projects, invoicing. Modern platforms simply include CRM and accounting as components, so there are no handovers left.

The practical route we see with nearly every [ERP switcher](/blog/erp-switchers-analysed): a company starts with accounting software, glues tools around it in the growth years - a webshop, a stock list, a planning system - and one day discovers that the glue between those tools costs more than the tools themselves. That is the moment ERP changes from jargon into a solution. What that looks like, we described in [from Excel to Odoo](/blog/from-excel-to-odoo).

## Seven well-known ERP systems, one paragraph each

Examples say more than definitions. The names you meet most often, with the honest characterisation:

**[SAP](/odoo-vs-sap)** is the benchmark for the enterprise: extremely complete, extremely heavy. For SMBs it is rarely the right size, and the S/4HANA migration deadline is currently driving many companies to reconsider.

**[Microsoft Dynamics 365 Business Central](/odoo-vs-dynamics)** is Microsoft's SMB ERP: strong in the Office world, delivered through partners, with licences and custom work that add up faster than the demo suggests.

**[Oracle NetSuite](/odoo-vs-netsuite)** is the cloud suite for international scale-ups: strong in multi-entity finance, with a price tag and a contract model in the American style.

**[Exact](/odoo-vs-exact)** is the Dutch accounting standard that grew into ERP: your accountant knows it, and that is a genuine strength. Outside finance it gets narrower.

**[AFAS](/odoo-vs-afas)** is the Dutch all-in-one suite, strong on finance, HR and payroll. Complete but rigid: the package decides how you work, not the other way round.

**[Visma](/odoo-vs-visma)** is the financial-logistics cloud ERP behind brands like Visma.net and AccountView: strong in finance and project accounting, with everything around it as the question.

**[Odoo](/odoo-erp)** - the platform we build, so factor in our bias yourself - is the open platform: every module from CRM to manufacturing on one data model, open source, at a licence price that is a fraction of the rest. The investment sits in the implementation, not the licence.

Want to see them genuinely side by side, with scores per criterion: that is what our [ERP comparator](/blog/compare-erp-systems) is for. And if you are looking around from Odoo instead - per process, per sector or open source - the honest map is in [Odoo alternatives](/blog/odoo-alternatives).

## The signals that you are ready

Not a vendor's checklist, but what we actually hear in intake conversations:

**Excel has quietly become your ERP.** The stock list, the project planning, the after-calculation - it all lives in worksheets that one person understands. Works, until that person is on holiday.

**Nobody knows the real number.** What was the margin on that order? How much stock do we have right now? The answer exists, but it costs a morning of searching and comparing three systems.

**Everything gets typed twice.** The webshop order goes into the administration by hand; the delivery note gets retyped into the invoice. Every double entry is an error risk and a salary.

**Growth makes it worse, not better.** More orders means more glue work. The team grows faster than revenue, because the systems do not scale along.

Recognise two or more, and the question is no longer whether, but what and when - and for that, [what does it cost](/blog/what-does-an-odoo-implementation-cost) and [how long does it take](/blog/how-long-does-an-odoo-implementation-take) are the logical next questions.

## And the honest story: sometimes not yet

An ERP system is not a status symbol. With five people, one process and an accountant who has the overview, an ERP implementation is a solution to a problem you do not have - and every euro and hour that goes into it comes out of your real work. Good accounting software plus a few separate tools is simply the right answer then, and whoever tells you otherwise is selling you something.

The tipping point is not your size but your fragmentation: the moment the separate tools no longer know each other and you are the glue. From there, one data model becomes worth more every month.

## In short

ERP stands for Enterprise Resource Planning: one system in which sales, purchasing, stock, manufacturing and accounting work together on one data model, so data exists once and the chain flows automatically. Well-known examples are SAP, Dynamics 365, NetSuite, Exact, AFAS, Visma and Odoo - different in audience, philosophy and price. You are ready once separate tools and Excel cost more glue work than one system; you are not yet as long as one accounting package can carry the overview. And when you choose, choose for where you want to be in five years, not for today's feature list.

---

**Curious whether your company is ready?** [Book a free Odoo scan](/scan) and we will take an honest look - including when the conclusion is that your current setup still does fine.

---

**Read more:** [Compare ERP systems](/blog/compare-erp-systems) · [Why companies really switch ERP](/blog/erp-switchers-analysed) · [From Excel to Odoo](/blog/from-excel-to-odoo) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost) · [How long does an Odoo implementation take?](/blog/how-long-does-an-odoo-implementation-take)


# How long does an Odoo implementation take? Three months standard, then everything adds up
URL: https://www.fanatics.nl/blog/how-long-does-an-odoo-implementation-take
Language: en

*"How long is this going to take?" is the second question in every system decision, right after "what does it cost". The honest answer for Odoo: **a standard implementation stands in about three months** - and after that, everything adds up. More users, heavier modules, custom work, integrations, data migration: each of those choices makes the project longer, and one factor makes everything shorter. This is what really drives the timeline, why we deliberately do not run it as an agile project, and how to count back from a hard date like 1 January. Want to run your own numbers straight away: the [go-live planner](/odoo-go-live-planner) does it in a minute.*

## The short answer: three months, if you stay standard

An implementation of the core processes - CRM, sales, purchasing, accounting - for a normally sized team stands in roughly three months. That is not a marketing number but a conditional one: it holds as long as the scope stays standard, the data migration is limited, and someone on your side genuinely frees up time.

Why can it go that fast? Because for those core processes, Odoo is simply finished. You configure, you set up, you migrate a manageable set of master data - but you build nothing. Every week in such a project goes into making choices, not into writing software.

It also means the reverse: every step outside the standard has a price in time. That is not an objection - sometimes your process is worth the custom work - but it belongs on the table before the planning gets promised.

## What adds up

The timeline of an Odoo project is no mystery. It is additive, and the line items are almost always the same.

**Users.** More people means more processes touched, more training, more opinions and more testing. An implementation for two hundred people is fundamentally different work than one for fifteen.

**Heavier modules.** eCommerce and Manufacturing are the two classics. A webshop touches product data, stock, payments and shipping at once; manufacturing touches bills of materials, routings and planning. Both work excellently in Odoo - but both are a project inside the project.

**Custom work.** From a small screen tweak to your own calculation engine: custom work has to be designed, built and tested. The range is wide, and precisely why its size should come out of a [fit-gap analysis](/target) rather than a gut feeling.

**Integrations.** Every connection to an external system - a webshop, a logistics provider, EDI with a buyer - brings a second party with its own pace. Integrations are rarely big work per piece, but they stack, and you are not the only one setting the tempo.

**Data.** The most invisible line item. If your customers, products and open items are clean, migration is a task. If they first need deduplicating and cleaning, it is a sub-project. Anyone who grew up [in Excel](/blog/from-excel-to-odoo) usually already knows which side they are on.

**Multiple entities.** Multi-company is not a checkbox: every additional entity brings its own configuration, its own flows and intercompany traffic, and multiplies the coordination.

Add it up and you understand the range you see everywhere: three months standard, six to nine with serious scope, towards twelve for large multi-company projects.

## The biggest accelerator is not technology but a person

If we could pass on one thing from all our projects, it is this: **the availability of your internal project lead sets the pace more than any technical choice.**

Every implementation lives on decisions. Which fields are mandatory? Who can see what? Is this exception worth configuring or do we abolish it? A project lead who genuinely gets time for this - and mandate - answers those questions in days. A project lead who fits it in on Friday afternoons answers them in weeks. Multiply that by the hundred decisions every project asks, and you see where plannings die.

That is why we ask about it explicitly up front, and why it weighs heavily in our [planner](/odoo-go-live-planner): from at least four hours a week on a small project to "as much as needed" on a large one. It sounds like a detail. It is the lever. And the project lead does not stand alone: who belongs next to them per process is covered in [what is a key user](/blog/what-is-a-key-user).

## Why we do not run it as an agile project

Many implementation partners work agile: sprints, a backlog, discovering along the way what is needed. We deliberately do the opposite. **The fit-gap analysis at the start produces a scoping table that turns the project into a predictable waterfall project.**

Per process it is fixed what works standard, what is configuration and what genuinely has to be built - including the definition of done, before anything gets built. Deviating is allowed, but then we know what we are deviating from. The consequence for the timeline is exactly what you want: a plan that is right up front instead of one that emerges along the way, and a fixed price per phase instead of an open end. "Discovering along the way" sounds flexible, but it is the most expensive way to find out your scope was bigger than you thought.

## Counting back from 1 January

Most deadlines are wishes; the book-year boundary is a real one. Live per 1 January means starting clean: no half a book year in the old system and half in the new, no double administration for your accountant.

If you want to be live on 1 January, you count back. First subtract **two months of buffer** - for test findings, new wishes that surface once people see the system, and plain overrun. That buffer is not pessimism; every go-live without one trades quality under pressure, exactly in the weeks that decide whether users embrace the system. What remains is the room for your actual scope. Start after the summer and a standard project fits comfortably. If your full scope does not fit, there is one dial left - and it is the most important one in this whole story.

## Scope is a dial: phasing

"Not feasible" barely exists. What does exist: *not everything at once*. The answer is phasing - live with the core processes first, the heavier parts right after. Accounting in the new system per 1 January and the webshop integration in February is not a failed plan; it is a good one.

Phasing also takes risk out of the project: a smaller first go-live is a manageable go-live, and your team gets to know the system while phase two is being built. Nearly every "unfeasible" date becomes feasible once the question changes from "when can everything" to "what genuinely has to stand by that date".

## In short

A standard Odoo implementation stands in about three months; users, heavier modules, custom work, integrations, data and additional entities add on top, up to six to nine months for serious and towards twelve for large projects. The biggest accelerator is an available internal project lead. With a fit-gap and a scoping table we deliberately turn it into a predictable waterfall project. And for a hard date like 1 January: count back, keep two months of buffer, and use scope as a dial. The [go-live planner](/odoo-go-live-planner) runs your situation in a minute.

---

**Want to know whether your date is feasible?** Fill in the [go-live planner](/odoo-go-live-planner) for a first estimate, or [book a free Odoo scan](/scan) - and we will map scope, phasing and planning together.

---

**Read more:** [Odoo implementation: are you ready?](/odoo-implementation) · [The implementation checklist (26 checkpoints, free PDF)](/blog/odoo-implementation-checklist) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost) · [The TARGET method](/target) · [What is a key user?](/blog/what-is-a-key-user) · [From Excel to Odoo](/blog/from-excel-to-odoo) · [Odoo directly or via a partner](/blog/odoo-direct-or-via-a-partner)


# EDI integration with a large retailer: no EDI, no customer
URL: https://www.fanatics.nl/blog/edi-connection-large-retailer
Language: en

*You have a product, a first buyer and a delivery date. And then it turns out the biggest unknown in your whole system project is not your accounting, not your stock and not your webshop, but three letters: EDI. Anyone who wants to supply a large supermarket chain soon discovers that electronic message exchange is not a wish but an entry requirement. **No EDI, no customer.** This is how it works, why there is no generic EDI connection, and why you start here.*

## It is not a feature, it is an entry requirement

With most system questions you get to choose. Want a webshop? Want project administration? Fine, we will switch it on. EDI works differently. A large retailer exchanges its orders, despatch advices and invoices electronically following the GS1 standard, and expects you to connect to it. If you do not, you are not a supplier. It is that simple.

That changes the order of your project. EDI is not something you add once the rest stands, it is the thing you start with, because it is the only part where somebody else sets the pace.

## Three messages, and where they come from

The core of the GS1 standard is more manageable than the jargon suggests. Three messages genuinely matter:

- **ORDERS** - the order. The retailer sends it to you.
- **DESADV** - the despatch advice. You send it to the retailer, before the goods arrive.
- **INVOIC** - the invoice. It goes from you to the retailer.

Alongside those there is usually an acknowledgement (APERAK), so both sides know a message landed. And there are timing requirements: EDI providers connecting to Ahold Delhaize document, for instance, that the DESADV must be in at least an hour before the goods reach the delivery location. That is not a detail. It means your despatch advice has an operational deadline that moves with your logistics.

## The surprise: it is not two parties, but three

This is where most estimates go wrong. You picture EDI as a line between you and the retailer. But as soon as you have outsourced your storage and shipping - and for a young brand that is the rule rather than the exception - the chain runs through three parties.

The **order** arrives with you and must flow automatically to your logistics provider, because they pick and ship. The **despatch advice** does not originate with you but with that logistics provider, at the moment a pallet is actually ready, and must go from there to the retailer. The **invoice** does go back from your system to the retailer.

Look at that for a second. The message with the strictest timing, the DESADV, is precisely the message you do not create yourself. You depend on data from a party that does not work for you. That is why the question "what can your fulfilment partner do, and over which interface" shapes your scope as hard as the retailer does. How you set that up is covered in [selling without your own warehouse](/blog/outsourced-fulfilment-odoo).

## Odoo does not do EDI itself, and that is fine

A common question: can Odoo do this natively? Towards a specific retailer: no. Odoo handles the content excellently - an incoming order becomes a sales order, a shipment becomes an outgoing delivery, an invoice is an invoice - but the translation into the GS1 message format and the transport to the retailer runs through an **EDI provider** or VAN. That party is the interpreter between your system and the retailer.

That sounds like a detour but is a blessing. You do not want your ERP to know every buyer's EDI specifications; you want one specialised party to know that, and your system to talk to that one party. Odoo connects to the provider, the provider talks to the retailer. If a second retailer arrives tomorrow, that is an extension at your provider rather than a rebuild of your ERP.

## There is no standard EDI connection

This is the sentence we get the most pushback on, and the sentence that saves the most money: **there is a standard, but no standard connection.** GS1 is the language. But every retailer has its own specifications, its own mandatory fields, its own timing, its own test track. "An EDI connection" does not exist in general, only per buyer.

What follows is practical: you cannot estimate an EDI track without that retailer's specifications and that provider's capabilities. Anyone who quotes you a number anyway is guessing. We would rather say we do not know yet and that finding out is step one, because this part is usually the biggest unknown in the entire scope - often the combination of EDI provider and fulfilment partner determines the bulk of what the project becomes.

## And then the retailer tests your connection

The last part people underestimate: you are not done when it works on your side. Large retailers test and certify the connection themselves, at their own pace and in their own queue. That is lead time you cannot recover by working harder or adding people.

If you have a hard date - a shelf moment, a launch, a season - that is the reason to put EDI at the front and run the rest of your configuration in parallel. Accounting, product data and stock you can do at your own speed. For the retailer, you wait.

## In short

With a large retailer, EDI is not a feature but an entry requirement. Three messages carry it: ORDERS in, DESADV out before the goods arrive, INVOIC afterwards. As soon as your logistics is outsourced there are three parties rather than two, and the message with the tightest deadline comes from somebody else. Odoo does the content, an EDI provider does the translation. And because there is a standard but no standard connection, every honest track starts with that one retailer's specifications, and it starts early, because the retailer tests it itself.

---

**About to supply a large retailer and not yet sure what your system needs to do?** [Schedule a no-obligation Quickscan](/scan) and we will map your EDI track, your fulfilment partner and your administration - including what is standard and what becomes an integration.

---

**Read more:** [PIM, EDI and customer portal for wholesale](/blog/pim-edi-customer-portal-wholesale-odoo) · [Selling without your own warehouse](/blog/outsourced-fulfilment-odoo) · [Promo discounts and annual agreements in your P&L](/blog/promo-discounts-annual-agreements-margin) · [Odoo for procurement, sourcing and import companies](/blog/odoo-for-sourcing-and-import-companies) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost)


# Selling without your own warehouse: outsourced fulfilment and how to connect it to Odoo
URL: https://www.fanatics.nl/blog/outsourced-fulfilment-odoo
Language: en

*No production of your own, no warehouse of your own. You buy from your supplier, a logistics provider stores and ships, and you sell. That is a fine model, and for a young brand often the only sensible one. But there is a misconception inside it that only hurts once it is too late: **no warehouse of your own does not mean no stock administration.** This is what stays in Odoo, what you integrate, and why an integration is rarely your first step.*

## The warehouse is outsourced, the administration is not

The pallets sit with someone else, the forklift is not yours, and the people picking are not on your payroll. That stock is still yours. It sits on your balance sheet, you bought and paid for it, you will invoice it, and you are responsible for its valuation at year end. When your accountant asks what was in that warehouse on 31 December and what it was worth, "my logistics provider knows" is not an answer.

So you simply run that stock in Odoo, as a location of your own that happens to sit elsewhere. Purchases arrive at that location, sales leave from it, and you see in your own system what you have. That you never touch the goods yourself changes nothing about that.

That sounds obvious, but in practice many young brands only see their stock in their provider's portal. That works right up until you want to know your margin, or your accountant calls.

## The question that shapes your scope

If you are going to integrate, exactly one question needs answering first: **what can that partner do, and over which interface?** In practice you meet three flavours.

A **modern API** is the nicest: real time, two-way, well documented. You push orders and pull statuses and stock levels the moment they change.

**EDI** also appears, especially at partners who work heavily with retail themselves. That is fine, and it has the advantage that the message structure is already fixed.

And then there is the **flat file**: a CSV dropped on an SFTP a few times a day. Old-fashioned, but it works, and more partners do this than you would expect. The difference sits in how current your data is and in what you have to build to make it reliable.

All three can work. But they differ substantially in build time, in maintenance and in what you have to agree about. That is why this is the question you ask before anyone estimates hours. Anyone estimating a fulfilment integration without knowing which of the three it will be is guessing - and together with your EDI track this often determines the bulk of your scope.

## Start with the portal, integrate when it hurts

Here we argue against what you expect to hear from a systems partner. Nearly every fulfilment partner has a portal: you pass orders, you see stock levels, you download a report. At low volume that is fine. An integration is then mostly an invoice.

You integrate at the moment the manual work starts to hurt. You will recognise that moment: daily order counts rise until retyping becomes a day job, errors creep in, or a retailer sets lead-time requirements you simply cannot meet by hand. That is when an integration pays for itself, and not a day earlier.

That is also just good project management. If you have a hard go-live date, the question is not "what do we eventually want" but "what has to stand to be able to ship". A portal-first approach takes a risky integration off your critical path and moves it to the moment your business pays for it.

## The despatch advice does not come from you

There is one place where all of this converges, and it deserves separate attention. Supply a large retailer and they expect an electronic despatch advice - the DESADV - often within a tight window before the truck reaches the delivery location.

That message does not originate with you. It originates with your logistics provider, because they know when a pallet is actually ready and what is on it. You are in the middle: it has to reach the retailer in the right format and on time.

So the message with the tightest deadline in the whole chain is the message a third party creates. That is not a disaster, but it is why the agreements with your fulfilment partner are part of your EDI track rather than something you arrange afterwards. How that triangle works is covered in [EDI with a large retailer](/blog/edi-connection-large-retailer).

## What it costs, and why you want to see it

Fulfilment is almost always priced variably: a rate per order, per order line, per pallet, per storage slot per week. Precisely because it is variable, those costs belong attributed to where they come from.

With analytic accounting in Odoo you attach fulfilment costs to the customer and product group causing them. Then you see that the retailer with the big pallets costs you little per euro of revenue, and that the channel with many small loose orders eats your margin. Without that attribution it stays one logistics lump in your income statement and you only know it was expensive, not what drove it. That is the same reasoning as with [promo discounts and annual agreements](/blog/promo-discounts-annual-agreements-margin): costs that belong to your revenue should be visible against that revenue.

## In short

Outsourcing fulfilment is sensible, but it outsources your warehouse, not your administration. Run your stock in Odoo as a location of your own that sits elsewhere. Before any estimate, ask what your provider can do - API, EDI or flat file - because that shapes your scope. Start on their portal and integrate when volume demands it, not earlier. Bear in mind that the despatch advice with the tightest deadline originates elsewhere. And attribute your fulfilment costs analytically, so you can see which channel eats your margin.

---

**Selling without your own warehouse and wondering what to integrate?** [Schedule a no-obligation Quickscan](/scan) and we will look at your fulfilment partner, your stock administration and what does and does not belong on your critical path.

---

**Read more:** [EDI with a large retailer](/blog/edi-connection-large-retailer) · [Promo discounts and annual agreements in your P&L](/blog/promo-discounts-annual-agreements-margin) · [PIM, EDI and customer portal for wholesale](/blog/pim-edi-customer-portal-wholesale-odoo) · [Connect Shopify to Odoo](/blog/connect-shopify-to-odoo) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost)


# Promo discounts and annual agreements: why your retail margin belongs at the top of the P&L
URL: https://www.fanatics.nl/blog/promo-discounts-annual-agreements-margin
Language: en

*You sell your product to a supermarket chain for 2 euros, your cost price is 1.20, so your margin is 40 percent. Except it is not. A leaflet week ran over it, an invoice arrived afterwards for the promo difference, and at year end there is a contribution of a few percent of your revenue on the bill. **Supplying large retailers hands you two margin eaters - promo discounts and annual agreements - and most companies book them away under marketing costs.** That is exactly where you never see them again. This is why they belong at the top of your P&L.*

## The two things that eat your margin

The moment you do business with a large retailer, you get two items you do not have with an ordinary customer.

The first are **promo discounts**. Your product goes on promotion - a two-for-one, a leaflet week, a shelf position - and that costs money. In practice you see two forms. Sometimes it runs up front, through a temporary price list: for the duration of the promotion the retailer simply pays a lower purchase price. Tidy, because the discount then sits correctly in your sales order from the start. But often it runs afterwards: the retailer sends you an invoice for the difference, after the promotion has run and your revenue was booked long ago. That is the variant that surprises.

The second are **annual agreements**. Contributions you pay yearly, usually as a percentage of your revenue with that retailer, sometimes as a fixed amount. They sit in your trading terms and they are not optional.

Both have the same effect: of every euro you turn over with that customer, you keep less than your selling price suggests. And both get booked to the wrong place by default.

## Why "under marketing" is an expensive habit

Follow how it goes. The retailer's invoice for that promotion looks like a purchase invoice. It arrives at accounts payable, somebody has to pick a ledger account, and "promotion costs" or "marketing" is the most obvious bucket. Done. The same reflex applies to the annual contribution.

Administratively understandable. Commercially fatal. Because what you have just done is this: you moved the cost of selling to that retailer into a cost line nobody looks at when judging margin. Your gross margin looks beautiful - you did sell for 2 euros after all - and somewhere at the bottom, between your ad budget and your trade-show stand, sits the money that actually ate your margin.

The consequence is a steering error, not a bookkeeping error. You start steering on a margin that does not exist. You compare products on a percentage that is right for one and wrong for another, because one went on promotion and the other did not. You negotiate purchase prices to win half a percent while three percent disappears into a line you never open. And at the retailer where you grow fastest - and therefore run the most promotions and pay the highest contribution percentage - the gap between the paper margin and the real one is widest.

## Where it does belong

The honest place is at the top, deducted from your revenue. Because that is what it is: **you sold the same product for less money.** A promo discount is not a spend, it is forgone proceeds. An annual contribution running as a percentage of your revenue is not a marketing campaign, it is the price of the shelf.

Put those two against revenue and something useful happens: your P&L starts with gross revenue, deducts promo discounts and annual agreements, and lands on a net revenue that is genuinely what the customer earned you. Only below that comes your cost price, and only then a margin you can steer on. You see per retailer what it really yields, and per product whether that item is profitable at all without a promotion.

That insight is not academic. It is the difference between knowing you are growing and knowing whether your growth makes money.

## How to set this up in Odoo

The technology is not the hard part, the choice up front is. Concretely it is three things.

**Separate ledger accounts.** Promo discounts and annual agreements get their own revenue accounts, in the revenue section, not the cost section. An invoice from the retailer for a promo difference is booked not to promotion costs but to the promo discounts account, where it reduces your revenue.

**Report structure.** Your P&L layout in Odoo determines how those accounts roll up. Set it so gross revenue, discounts and net revenue appear as distinct lines at the top, and your income statement reads like the story above instead of a heap of ledger accounts.

**Analytic accounting.** This attaches every entry to a customer and a product group. That is what lets you answer "what do I earn on this retailer" and "what do I earn on this product" separately, including the discounts weighing on them.

None of the three is custom work. It is configuration. But it is configuration you do at the start, because this is the classic example of something that gets expensive afterwards: **if you want insight later, you have to book to the right accounts today.** Redistributing past entries across accounts you did not have then is manual labour nobody enjoys.

## The honest nuance

This is a choice, not a law. There are accountants who prefer promo discounts as costs, and there are situations where a contribution genuinely is a marketing service you buy - an advert in the leaflet you could also have bought separately, for instance. That one does belong under marketing.

The point is not that there is one right answer. The point is that most companies never make this choice consciously. The item lands wherever accounts payable can file it fastest, and after that the whole company steers for years on a margin that is a few percent too high. Make the choice consciously, record why, and make sure your reporting shows what you want to know.

## In short

Selling to large retailers costs you promo discounts and annual agreements. Book them under marketing costs and they vanish from view, leaving you steering on a gross margin that does not exist - hardest at the customer where you grow fastest. They belong at the top, deducted from revenue, because you sold the same product for less money. In Odoo you handle that with separate revenue accounts, a deliberate P&L structure and analytic accounting per customer and product. No custom work, but a choice you make at the start.

---

**Supplying retail and unsure whether your margin adds up?** [Schedule a no-obligation Quickscan](/scan) and we will look together at your P&L structure, your discount flows and what Odoo can show you.

---

**Read more:** [EDI with a large retailer](/blog/edi-connection-large-retailer) · [Selling without your own warehouse](/blog/outsourced-fulfilment-odoo) · [PIM, EDI and customer portal for wholesale](/blog/pim-edi-customer-portal-wholesale-odoo) · [From Excel to Odoo](/blog/from-excel-to-odoo) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost)


# Chinese accounting in Odoo: the fiscal localisation (l10n_cn), fapiao and Golden Tax
URL: https://www.fanatics.nl/blog/chinese-accounting-odoo-localisation
Language: en

*If you work with an entity in China, a fair question is: can the Chinese accounting actually live in Odoo? The answer is more nuanced than yes or no. Odoo has a Chinese fiscal localisation - l10n_cn provides the chart of accounts and taxes - but fapiao and the Golden Tax system are a story of their own. This is what the localisation does cover, where OCA modules step in, and when you book in Odoo versus keep it local and couple. A deep-dive on the broader choice around [international accounting in Odoo](/blog/international-accounting-with-odoo).*

## Yes, Odoo has a Chinese localisation

Let us start by removing the misconception that Odoo "can do nothing with China". That is not true. Odoo ships the fiscal localisation **l10n_cn**: a Chinese chart of accounts and the associated taxes. With it you can book in Odoo according to the Chinese account structure, just as there are localisations for the Netherlands, Germany or the US.

For many companies with a Chinese entity this is the foundation they are looking for: one ERP for the group, with a locally correct ledger for the Chinese site.

## Where it gets more complex: fapiao and Golden Tax

The nuance sits in the statutory invoicing. In China official invoicing runs through **fapiao** - invoices regulated by the tax authority - and the **Golden Tax system** (Jinshui), the government platform through which companies issue fapiao and remit VAT.

That issuance is not fully in the standard Odoo localisation. There are three practical routes:

1. **OCA modules.** The community repository **l10n-china** (from the Odoo Community Association) contains additional modules that go beyond l10n_cn, including around fapiao. Handy if you want to stay within Odoo.
2. **Third-party connector.** A link between Odoo and the Golden Tax system, provided by a local party.
3. **Issue locally, process in Odoo.** You keep issuing fapiao in the Golden Tax software and process the administration in Odoo, with or without a connector.

Which route fits depends on your fapiao volume and your existing local setup. For a handful of invoices a month, manual processing is fine; at high volume a module or connector pays off.

## The core question: book in Odoo or keep local?

This is where most companies actually sit. Two models, and the choice is situation-dependent:

**Booking in Odoo** fits if you have **in-house accountants** and want one system for the whole group. You book the Chinese entity in Odoo with l10n_cn, arrange fapiao via a module or connector, and get direct consolidation and current insight without waiting for figures delivered from outside. If you have the people in house who understand it, this is often the best route - and exactly the point we make in the [international accounting article](/blog/international-accounting-with-odoo): a Chinese localisation exists, so why not use it?

**Keeping local and coupling** fits if an **external Chinese firm** does the books and is already in its own software, or if specific statutory requirements around Golden Tax are hard to press into Odoo. Then you let the Chinese accounting run locally and couple at figure level to Odoo for consolidation.

There is no universally right answer. The decider: do you have the accounting knowledge in house, and how heavily do the local statutory requirements weigh?

## l10n_cn versus OCA: what is what

Briefly, because the names confuse:

- **l10n_cn** is **Odoo''s own official fiscal localisation**: chart of accounts and taxes. This is the base.
- The **OCA l10n-china modules** are **additional, community-maintained extensions** that go further where the base stops, for example around fapiao and Golden Tax.

So the base always comes from l10n_cn; for specific Chinese requirements you check whether an OCA module or a local connector closes the gap.

## In short

Odoo can certainly handle Chinese accounting: l10n_cn provides the chart of accounts and taxes as a foundation. The nuance sits in fapiao and the Golden Tax system, which is not fully in the standard - there OCA modules, a connector or a local setup step in. If you have in-house accountants, booking in Odoo is often the best route; if you work with an external Chinese firm or the statutory requirements weigh heavily, you keep local and couple. A choice per situation, not one right answer.

---

**Do you have a Chinese entity and are unsure whether the accounting should live in Odoo or locally?** [Schedule a no-obligation Quickscan](/scan) and together we determine the model that fits your entity structure and your team.

---

**Read more:** [International accounting with Odoo](/blog/international-accounting-with-odoo) · [Odoo from China: hosting and self-hosting](/blog/odoo-from-china-self-hosting) · [Odoo hosting and data residency international](/blog/odoo-hosting-and-data-residency-international) · [Odoo for procurement, sourcing and import companies](/blog/odoo-for-sourcing-and-import-companies)


# From Excel to Odoo: why even companies with tens of millions in revenue still run on spreadsheets
URL: https://www.fanatics.nl/blog/from-excel-to-odoo
Language: en

*We recently spoke with a company from the established order: tens of millions in revenue, a site in China and one in the Netherlands, supplying large retailers. And still, almost everything ran on Excel, Google Sheets and loose tools. No exception, it turns out in practice. The key lesson up front: **an unfinished ERP is not a matter of company size, but of a moment that has not yet arrived.** This is when spreadsheets start to slow you down, what they silently cost, and what the move to Odoo looks like.*

## It is not a size problem

There is a stubborn image that "still running on Excel" is something for startups and small business owners. Reality is different. We regularly see mature, profitable companies with tens of millions in revenue, multiple sites and international customers, where the core of the operation still sits in spreadsheets: the stock, the orders, the purchasing, the price calculation, the communication with suppliers and customers.

That is not a sign of amateurism. It is almost always the result of success. The company grew with what worked, and Excel worked. Why would you change something that brought revenue to tens of millions? That exact reasoning is why the switch is postponed for so long - until a moment forces it.

## Why Excel lasts so long

Excel is not dominant by accident. It is the most flexible piece of software most people know: it works from the first second, costs nothing extra, requires no implementation, and adapts to any process you can think of. You start with a tab. Then a second file is added. Then a shared folder, a naming convention, a macro someone once built.

That is how a company grows into it unnoticed; every step is small and logical; nobody ever consciously decides "we run our business on spreadsheets". It just happens. And because it scales along - slower than the business, but it scales - the tipping point only comes into view late.

## The Excel paradox

Here is the crux. The very property that makes Excel so attractive is exactly where it eventually slows you down: **the boundless flexibility.** Because anything is possible, nothing is fixed. There is no enforced process, no single source of truth, no built-in control. Two people edit two versions; a formula gets overwritten by accident; a file lives in the head of whoever built it.

At small scale that is manageable. At scale it becomes a risk. The flexibility that moved you forward is then the reason nobody can say with certainty how much stock there is or what an order really earns.

## The signals that Excel has become the brake

The tipping point announces itself. The recurring signals, and why they occur:

- **Stock never quite matches.** You buy or sell in multiple places, and each list keeps its own count. Without a central source it inevitably drifts apart.
- **Someone retypes data by hand.** Between purchasing and sales, between order and accounting. Every manual step is slow, error-prone, and does not scale with your volume.
- **The overview sits in one head.** There is a colleague who "knows the sheets". If they leave, the insight leaves. That is key-person risk, not a system.
- **Reporting takes days.** A simple question - what margin did we make per customer last quarter - requires manually combining multiple files.
- **Onboarding new people fails.** There is no system to learn, only unwritten knowledge and files with their own logic.

## What Excel silently costs at scale

The licence is free; the cost of ownership is not. The real costs are invisible and therefore treacherous:

- **Errors from double entry** that only surface when a customer or supplier complains.
- **Stock that does not match**, causing missed sales, overselling or over-buying.
- **Margin you only see afterwards**, because costs and sales sit in separate files.
- **Hours of manual work** that grow linearly with your order volume instead of being automated.
- **No audit trail**, which becomes awkward once compliance, an audit or a large customer asks for proof.

A spreadsheet that demands tens of hours of correction and reconciliation every month is more expensive than a system that simply works. That is the same calculation we make in [what an Odoo implementation costs](/blog/what-does-an-odoo-implementation-cost): the visible price is rarely the whole story.

## The tipping point is almost never "it could be better"

This is perhaps the most important insight, and it recurs in our [analysis of 300+ ERP switchers](/blog/erp-switchers-analysed): companies rarely switch because it could be better. "It could be better" is a nagging feeling that can linger for years. Only a **concrete moment** gets people moving:

- A large customer demanding **EDI or a customer portal**, which a spreadsheet simply cannot deliver.
- A **second site, currency or language** being added.
- A **team that grows** and in which the knowledge no longer fits in a few heads.
- **Local custom software** that was once built and no longer keeps up with the growth.

Recognise such a moment, and the question is no longer "could it be better", but "can we still do this with Excel". That is the point at which postponing costs more than switching.

## The pressure from large customers

A separate, underrated trigger: **your customers force your hand.** Large retailers do not work with loose order lists by email. They expect EDI connections, order statuses, a supplier portal, clean article data. Whoever tries to meet that with Excel gets stuck - not because the people cannot do it, but because a spreadsheet is never a system that talks to another system automatically.

At that moment the choice is no longer internal. You have to keep up with what your customers expect, and that requires a business platform with a real source of truth behind your sales.

## International makes it sharper

As soon as a company combines multiple countries - for example a purchasing organisation in China and a sales side in the Netherlands - complexity stacks up: multiple currencies, multiple languages, a foreign bookkeeping that is arranged locally but still has to connect, and logistics across borders. Excel can keep up for a while, but it becomes a house of cards. That is precisely where a platform like Odoo delivers a big advantage: multiple entities, currencies and languages in a coherent whole, with the local accounting connected instead of loose. We wrote earlier about [Odoo for international rollouts](/international-odoo-partner).

## What "off Excel" really means

Switching is not the same as digitising your spreadsheets. It is about a fundamental shift: **from loose lists to a source of truth.** In a system like Odoo, purchasing, sales, stock, order workflow, article management, EDI, customer portal and accounting come together on one data model. A sale automatically lowers the stock; a purchase replenishes it; the accounting follows along; and everyone looks at the same figures.

That is the gain Excel by definition cannot offer, however clever your sheets are: coherence. No longer five files you try to keep aligned by hand, but a whole that adds up because it cannot do otherwise.

## When Excel is fine (the honest nuance)

To stay honest: Excel is not the problem, and not every company has to move off it. For a single location with clear processes, few movements and a small team, a well-built spreadsheet is often fine - and an ERP project would be overkill then. The point is not "Excel is bad". The point is **recognising the moment** when your operations have grown bigger than a spreadsheet can carry.

## How to approach the switch

The order that makes the difference between a smooth transition and a painful one:

1. **Fit-gap first.** Map your processes, channels, stock flows and accounting requirements before you configure anything. Where is the real pain, and what can run standard?
2. **Decide which data becomes leading.** Stock, articles, customers: one source, not five.
3. **Phase the rollout.** Start with the core (purchasing, sales, stock) and expand, instead of switching everything on at once.
4. **Migrate cleanly.** Move articles, open items and balances over correctly, with a dry run before go-live.
5. **Keep Excel for what it is good at.** Ad-hoc analysis and quick calculations stay fine in Excel; the operation moves.

That is exactly the kind of choice where an honest analysis up front makes the difference between a system that lasts for years and a half-finished project.

## In short

Still running on Excel is not a sign of a small or immature company - it is often precisely the result of success and postponed necessity. Excel lasts a long time because it scales deceptively well, but the same flexibility is where you eventually get stuck. The tipping point is almost never "it could be better", but a concrete moment: a large customer, a second site, a growing team. Recognise that moment, and move your operations to a source of truth - then Excel goes back to being the tool it should be.

---

**Recognise this, and unsure whether your moment has arrived?** [Schedule a no-obligation Quickscan](/scan) and we will map your processes, your scope and your biggest risks in 20 minutes - including an honest answer on whether Excel is still enough for now.

---

**Read more:** [Why companies really switch ERP: 300+ switchers](/blog/erp-switchers-analysed) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost) · [Odoo for international rollouts](/international-odoo-partner) · [PIM, EDI and customer portal for wholesale](/blog/pim-edi-customer-portal-wholesale-odoo) · [Odoo reviews: 2,500+ reviews](/blog/odoo-experiences) · [All ERP comparisons](/compare)


# International accounting with Odoo: one group, multiple countries (and sometimes a Chinese ledger alongside)
URL: https://www.fanatics.nl/blog/international-accounting-with-odoo
Language: en

*As soon as a growing company gets an entity abroad - a purchasing office in China, a sales point in Germany, an entity in the US - the same question comes up: does that country's accounting also run in Odoo, or do you keep it local and connect it to the group? The answer is not "everything in one system" and not "a separate package everywhere", but a deliberate choice per country. This is the honest trade-off, with the Chinese ledger as a sharp example.*

## The question behind the question

"Can Odoo handle international accounting?" is quickly answered technically: yes. Odoo runs multiple entities as multi-company, in multiple currencies and languages, with consolidated reporting, and has fiscal localisation packages for dozens of countries. But that is not where the real decision sits.

The real question is: **which country ledger do you put in Odoo, and which do you keep local and connect?** That is not a technical but a strategic choice, and the answer differs per country, depending on regulation, the local accountant, the language and practice.

## Two models

There are roughly two ways to organise international accounting with Odoo.

**Model 1: everything in Odoo, with fiscal localisation per country.** You run each entity in Odoo and install the fiscal localisation package per country: the chart of accounts, the taxes and the fiscal positions. This is the cleanest setup: one system, one data model, direct consolidation. It fits countries with a localisation Odoo covers well and where there is no heavy local requirement to book in other software or with a local party.

**Model 2: local accounting local, connected to the group.** For some countries it is wiser to keep the accounting local - with an external firm or in local software - because the law, the language or practice call for it. Odoo then remains the **group system** for the operation (purchasing, sales, inventory, projects) and for consolidation, and the local ledger is connected: via periodic journal entries, a subset of data, or a daily import.

The art is not to choose one dogmatically, but to determine the right one per entity.

## China: where the choice is sharpest

China is often portrayed as "cannot be done in Odoo". That is not true. Odoo has a **Chinese fiscal localisation** (chart of accounts and taxes), and the community (OCA) offers additional modules, including for **fapiao** (Chinese invoicing). China is therefore not an exception where Odoo stops - it is precisely the sharpest example of the choice between the two models.

The trade-off comes down to two questions:

- **Do you have your own accounting capacity in China?** If so - an own accountant or finance team on the ground - keeping the Chinese ledger in Odoo is often the best choice: one system, direct consolidation, no separate package alongside. The localisation plus any OCA or partner modules cover the chart of accounts and the invoicing.
- **Do you work with an external local firm, or do you have very specific statutory requirements?** Think of certain parts around the Golden Tax System or filings you would rather leave to a local specialist. Then it can be wiser to keep the accounting local and connect it to the group.

So there is no default answer "China = connect". The operation (orders, purchasing, margins, stock flows) belongs in Odoo regardless; for the accounting you test whether the localisation covers your specific requirements and whether you have the capacity on the ground - and then deliberately choose between booking in Odoo or keeping it local and connecting. We saw exactly this kind of scenario recently at a [sourcing and import company](/blog/odoo-for-sourcing-and-import-companies) with entities in China and Hong Kong.

## Bank connections: be honest across the border

A concrete point that often comes up too late: **bank connections do not work the same everywhere.** For European banks an automatic connection in Odoo is standard. For banks outside the EU - for example in China or Hong Kong - that is not a given. The honest approach: test it per bank before you promise anything. If it cannot be automatic, a daily or periodic bank import is the real alternative. That is not a shortcoming, but a choice you make deliberately instead of being surprised by it.

## Where the data runs matters

Connecting accounting across countries also touches the question of where your system runs and who can reach it. If a large part of your team sits in a country with limited access to certain cloud services, the hosting location (for example Singapore versus Europe) becomes a real trade-off. We work that choice out in the [hosting guide](/blog/odoo-hosting-online-sh-or-self-hosting), and the broader international approach in [Odoo for international rollouts](/international-odoo-partner).

## What you need in Odoo

For full international accounting you lean on the heavier side of Odoo:

- **Full accounting** (bank reconciliation, assets, tax reporting) - that is the Enterprise functionality, see [Odoo Community vs Enterprise](/blog/odoo-community-or-enterprise).
- **Multi-company** with intercompany transactions and consolidated reporting.
- **Fiscal localisation packages** per country where you book in Odoo.
- **Multiple currencies and languages** in a coherent whole.
- **Interfaces** for the entities that stay local: journal entries, subset sync or import.

## The honest nuance

Not every foreign ledger belongs in Odoo, and not every one belongs outside it. For a German or Belgian entity with a good localisation, model 1 (everything in Odoo) is often fine. For a Chinese entity it can go either way: with own accountants and a covering localisation, booking in Odoo is excellent; if you lean on an external local firm or specific statutory requirements, keeping it local and connecting is wiser. The mistake is not one model or the other, but not choosing deliberately - and then discovering afterwards that you forced a local tax requirement into a system not meant for it, or that you are missing a group view.

## How to approach it

1. **Map the entities.** Per country: which tax requirements, which accountant, which language, which bank.
2. **Determine the model per entity.** Book in Odoo (with localisation) or keep local and connect.
3. **Test the bank connections** per bank, with import as a fallback.
4. **Design the consolidation** at group level, with intercompany and elimination.
5. **Weigh the hosting location** if part of your team has limited cloud access.

## In short

International accounting with Odoo is not a technical but an architecture question: which country ledger do you put in Odoo, and which do you keep local and connect to the group? Odoo delivers the multi-company, the localisations and the consolidation; the art is to choose the right setup per entity. China is not a wall but the sharpest example of that choice: with own accountants and a covering localisation, booking in Odoo is excellent; otherwise a group system with a connected local ledger is the honest answer - one view, without forcing the local requirements.

---

**Do you have a foreign entity and are unsure about the setup?** [Schedule a no-obligation Quickscan](/scan) and we will map your entities, your tax requirements and the best connection strategy.

---

**Read more:** [Chinese accounting in Odoo: l10n_cn, fapiao and Golden Tax](/blog/chinese-accounting-odoo-localisation) · [Odoo for international rollouts](/international-odoo-partner) · [Odoo for procurement, sourcing and import companies](/blog/odoo-for-sourcing-and-import-companies) · [Odoo hosting and data residency international](/blog/odoo-hosting-and-data-residency-international) · [Odoo Community vs Enterprise](/blog/odoo-community-or-enterprise) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost)


# PIM software and Odoo: when product data belongs in a shell around it
URL: https://www.fanatics.nl/blog/odoo-as-a-pim
Language: en

*When Odoo''s standard product model no longer suffices - thousands of items, each with a complete dossier of specifications, compliance and artwork - the reflex is to keep extending the product screen. That is the wrong turn. At that scale you do not build PIM inside Odoo, but as a **shell around it**, with only the transactional subset in Odoo itself. And with one hard rule: the sync runs one way only. This is the architecture, why syncing back and forth rebuilds the chaos, and where the line is.*

## When the standard product model strains

For most companies Odoo''s product model is more than enough. Specifications, variants, prices, images: it is all in there, and you need no extra system. The question "can Odoo serve as a PIM?" is for them simply: yes.

It only strains with a specific profile. Thousands of items, and per item not a handful of fields but a complete dossier: technical specifications, compliance documents and certificates, packaging data, artwork, multiple languages, and dozens to hundreds of attributes that each buyer or channel asks for slightly differently. We saw this at a [sourcing and import company](/blog/odoo-for-sourcing-and-import-companies) where a single item row was good for 173 columns. At that point the product screen in Odoo becomes a catch-all, and each extension makes it slower and more fragile.

## The shell architecture: what belongs where

The solution is not "cram everything into Odoo", but to split the data to where it belongs:

- The **PIM** manages the full product data: all specifications, compliance, packaging, artwork, translations and variants. This is the source of truth for the product.
- **Odoo** holds the **transactional subset**: exactly the fields you need to sell, purchase, hold stock and invoice. This is the source of truth for the transaction.

The rule of thumb for what belongs where: **does a field belong to the transaction, then it may live in Odoo; does it belong to the complete product dossier, then it stays in the PIM** and only what Odoo actually uses comes along. A certificate a buyer requests belongs in the PIM; the sales price and the stock unit belong in Odoo. That way the product screen in Odoo stays clean and fast, while the richness of the data is fully preserved in the layer built for it.

## Why the sync runs one way only

Here is the principle that holds the whole setup up: **the sync runs one way only, from the PIM to Odoo.** Change a specification, a price or a certificate and you do that in the PIM, and it flows to Odoo. Never the other way.

The temptation is to let it run both ways "for convenience" - a price you happen to adjust in Odoo flowing back to the PIM. Do not. As soon as both systems think they own the same fields, you get conflicts: which value wins, and when? You rebuild exactly the situation you set out to solve - versions drifting apart, nobody knowing what is right - but now split across two systems instead of ten Excel tabs. **Syncing back and forth rebuilds the Excel chaos, only more expensively.** One direction keeps the question "where does the truth live?" always answerable.

## Two sources of truth, each for its domain

One direction does not mean one system. There are two sources of truth, and that is fine as long as the line is sharp:

- The **PIM** is the source for **product data**. Everything that describes the product originates and changes there.
- **Odoo** is the source for the **transaction**. Orders, stock, deliveries and invoices originate there.

The line runs along the question "does this describe the product, or record an event?". A product attribute describes; an order records. As long as you do not mix those two, every field knows where it belongs and the sync stays simple and predictable.

## Where the line is: not everyone needs this

This is emphatically not an argument to put a separate PIM next to Odoo by default. For the vast majority of companies that is overkill - you add a system, a connection and maintenance where the standard product model would have done fine. The shell architecture only pays for itself with the profile above: many items, a rich dossier per item, and multiple buyers or channels that each want their own subset.

Unsure which side you are on? Look at your item row. Does it have a handful of fields, then Odoo is your PIM and you are done. Is it heading toward dozens or hundreds of fields most of which have nothing to do with the sales transaction, then the shell is worth considering. That trade-off is part of the broader B2B setup we described in [PIM, EDI and customer portal for wholesale](/blog/pim-edi-customer-portal-wholesale-odoo).

## In short

With thousands of items each carrying a complete dossier, your product data does not belong inside Odoo, but in a PIM as a shell around it - with only the transactional subset in Odoo itself. The sync runs one way only, from PIM to Odoo, because syncing both ways rebuilds the chaos. Two sources of truth, each for its domain, with a sharp line: the PIM describes the product, Odoo records the transaction. And for most companies not at that scale: Odoo is your PIM, and that is exactly enough.

---

**Is your item data running into the limits of the standard product model?** [Schedule a no-obligation Quickscan](/scan) and together we determine whether Odoo suffices as a PIM or a shell architecture pays for itself.

---

**Read more:** [PIM, EDI and customer portal for wholesale](/blog/pim-edi-customer-portal-wholesale-odoo) · [Odoo for procurement, sourcing and import companies](/blog/odoo-for-sourcing-and-import-companies) · [From Excel to Odoo](/blog/from-excel-to-odoo) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost)


# Odoo for leasing and rental companies: contracts, assets and a portal where customers manage their own fleet
URL: https://www.fanatics.nl/blog/odoo-for-leasing-and-rental-companies
Language: en

*Leasing and rental are not ordinary sales. They are not about a transaction but about a relationship across years: a contract, an asset with a residual value, maintenance, damage, financing and invoicing that runs on month after month. Most leasing companies handle that with a stack of loose packages and Excel, where each piece covers a part and nothing covers the whole. This is how Odoo brings leasing and rental companies onto one platform, and how we build a customer portal on top of it with Updoo where customers manage their own fleet.*

## Why leasing is a different question

With an ordinary sale, your system delivers an order, an invoice and done. With leasing and rental, that is where it begins. The object stays yours, or your financier's, and you manage it over the entire term. That makes leasing a combination of five things that are rarely in one package:

- **Contract management** - term, conditions, renewals, mid-term changes.
- **Asset management** - the object, the depreciation, the financing and the residual value.
- **Recurring invoicing** - monthly instalments, additional costs, settlement at end of contract.
- **Repair and maintenance** - planned and unplanned, tracked per object.
- **Damage handling** - reports, settlement, costs and insurance.

Whoever does this with loose tools misses the overview that matters precisely in leasing: what is a contract worth on the bottom line, how is the fleet doing, and where does the margin leak. That is the same pitfall as in [from Excel to Odoo](/blog/from-excel-to-odoo), but with assets that last for years.

## The architecture: the whole lifecycle on one platform

In Odoo the links of the leasing and rental process come together on one data model:

- **Sales and quote** - including the lease price, built from components.
- **Contracts and subscriptions** - recurring instalments, renewals, cancellations.
- **Asset management and accounting** - depreciation schedules, financing and residual value per object.
- **Maintenance and service** - work orders, planning, history per asset.
- **Inventory and objects** - the fleet as managed objects with status and location.
- **Invoicing** - automatic, per contract, with the right components.
- **Reporting** - return per contract, per object and across the fleet.

A contract automatically drives the invoicing; a maintenance visit hangs on the right object; the depreciation runs along in the accounting. Everything adds up because it is not separate.

## The lease-price calculator

A lease price is not a single number, but a sum: depreciation, interest and financing, expected residual value, maintenance, insurance and margin. In many leasing companies that calculation lives in an Excel file that one person knows. That is exactly the kind of calculation logic we capture in Odoo, so every quote comes together consistently, traceably and up to date - and does not depend on that one file.

## The distinctive part: an Updoo customer portal for the fleet

Here we make it distinctive. On top of the standard Odoo portal function we build, with [Updoo](/updoo), a **customer portal where lessees and renters manage their own fleet.** Concretely, a customer can there:

- **View their contracts and objects** - which vehicles or assets are running, until when, on what terms.
- **Follow the maintenance status** - what is planned, what is done, when something needs to happen.
- **Report damage or a service request** - with photos, straight as a record in Odoo.
- **Retrieve invoices and documents** - without calling your back office.
- **Request extensions or changes** - an extra vehicle, an early trade-in.

That does two things at once: it lowers the load on your back office, and it raises service and loyalty with your customer. It connects to our broader approach to [B2B customer portals in Odoo](/blog/odoo-b2b-customer-portal), focused on fleet management. Standard where it can, a smart extension where your process is unique.

## For rental too

The building blocks are not reserved for car leasing. Equipment rental, machine rental and other assets you lend out over time for a fee work the same way: contracts, recurring invoicing, asset management, maintenance and a customer portal. Odoo has, among others, a Rental app that connects to the same data model, so rental and leasing can run side by side on one platform.

## Growth is the tipping point

Leasing companies rarely switch because "it could be better", but at a concrete moment: a growth plan (from a handful to dozens of staff), an adjacent activity being added (for example import or an own garage), or the realisation that the loose packages no longer carry the operation. We see that pattern broadly in our [analysis of 300+ ERP switchers](/blog/erp-switchers-analysed): not "it could be better", but a moment that forces your hand.

## How to approach it

1. **Fit-gap first.** Map the lifecycle - contract, asset, maintenance, damage, invoicing - and decide where standard suffices and where an extension (lease-price calculator, portal) is needed.
2. **Decide the source of truth.** Contracts, objects, customers: one source.
3. **Phase it.** Start with contracts, invoicing and assets; add the calculator, the portal and the service flow after.
4. **Cost it honestly.** Leasing often demands more custom work; weigh that up front - see [what an Odoo implementation costs](/blog/what-does-an-odoo-implementation-cost).

## In short

Leasing and rental are about contracts and assets across years, not loose transactions. Odoo brings contract management, asset management, maintenance, damage and invoicing onto one platform, with a lease-price calculator where the calculation logic belongs, and an Updoo customer portal where your customers manage their own fleet. That way a leasing company runs the entire lifecycle on one system, with better service as a bonus.

---

**Is your leasing or rental process getting stuck on loose packages?** [Schedule a no-obligation Quickscan](/scan) and we will map your lifecycle, your scope and your biggest risks in 20 minutes.

---

**Read more:** [From Excel to Odoo](/blog/from-excel-to-odoo) · [Odoo for procurement, sourcing and import companies](/blog/odoo-for-sourcing-and-import-companies) · [B2B customer portal in Odoo](/blog/odoo-b2b-customer-portal) · [Why companies really switch ERP: 300+ switchers](/blog/erp-switchers-analysed) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost) · [Updoo: extensions on Odoo](/updoo)


# Odoo for procurement, sourcing and import companies: from 173 Excel columns to one product model
URL: https://www.fanatics.nl/blog/odoo-for-sourcing-and-import-companies
Language: en

*Sourcing and import companies live between two worlds: factories in Asia, and demanding retailers in Europe. In between sits a chain of RFQs, samples, inspections, compliance, article data and invoicing. We recently made a solution assessment for such a company, and one number stuck: **a single article row held 173 columns, in 13 field groups, each with a supplying party and a responsible role.** That is not a product list - it is a complete PIM model that happens to live in Excel. This is how Odoo brings that chain onto one platform, why PIM is the heart, and how we build it with Updoo.*

## The sourcing model has its own demands

A sourcing or procurement-facilitation company is not a standard wholesaler. It helps retailers and online players buy directly from the factory in Asia - OEM and private label - and earns on facilitation, quality and margin. The business model determines what the system must do. In practice we see two variants, often side by side:

- **Facilitating for a fee**: you bring the customer to the right factory, arrange quality, compliance and logistics, and earn a fee or margin. You hold no stock yourself.
- **Buying and reselling**: you buy to order, get paid up front, and arrange the import. Here too, goods go directly from the factory to the customer.

Both demand a system that can handle **the chain** - from the RFQ at the factory to delivery at the retailer - without you managing a warehouse. That is a different question from "inventory management for a wholesaler", and precisely where generic tools get stuck.

## Every product introduction in a new Excel file

At this kind of company the process is often excellent on paper. What is missing is one system. Everything runs via Excel, Teams, email and an ERP with limitations. Every product introduction goes through the same series of milestones - in the assessment more than 25, from shopping list to product evaluation - but each time in a new Excel file. That costs time, causes errors, and makes steering on status impossible. You cannot see at a glance which products sit where in the process, which inspection is scheduled, or which certificate is about to expire.

This is the same dynamic we described in [from Excel to Odoo](/blog/from-excel-to-odoo): not small or immature, but stuck on loose files. The homework is done well; it lacks a home.

## The architecture: from RFQ to retailer on one data model

What it comes down to is coherence. In Odoo the links of the sourcing chain come together on one data model. From the assessment, with an honest split of what runs standard and what is built:

| Domain | Approach | In short |
|---|---|---|
| CRM & contacts | Standard | Customers, suppliers, leads, visit reports |
| Sales & purchasing | Configuration | SO/PO with down payments, Incoterms, commission |
| Project management (NPI) | Configuration | The 25+ milestones as a project template with phases, deadlines and RACI |
| Accounting | Configuration | Multi-company across entities, with bank connections as a point of attention |
| PIM / article creation | Custom (Updoo shell) | The heart of the system - see below |
| Retailer EDI | Custom | Automatic order intake instead of manual downloading |
| Supplier portal | Custom (Updoo) | Suppliers upload certificates, photos, packaging data themselves |
| Inspections & quality | Configuration | PSI reports, sample approval, formal sign-offs |
| Compliance monitoring | Custom | Flag expiring certificates, proactively |
| Inventory / POS | Later | No own stock; deliberately out of scope |

That honest split is half the work: no hollow "Odoo does everything", but clear what you switch on, what you configure, what you build, and what you deliberately move to a later phase.

## PIM: the heart of the system

Back to those 173 columns. They fall into 13 field groups - from general product info and price history (FOB, landed cost, sales price per country, margin) to logistics, packaging convenant (grams per material for PPWR), artwork requirements with dozens of compliance markings, certification (BOM, TCF, REACH, RoHS, DPP), test reports per sample phase, and ten product-photo positions. Each field has an owner: the supplier, the compliance department or the merchandiser.

That is not a product list. It is a complete PIM model, including who supplies what. And that is exactly where standard Odoo falls short, for three reasons:

- **Price history with dates.** FOB price 1, 2 and 3 with date, plus landed costs and sales prices per country. Odoo keeps the current price, not a structured history with margin calculation.
- **Ownership per field group.** The supplier fills in logistics and packaging, compliance the certifications, the merchandiser the basics. That requires write rights per field group - standard Odoo has rights per model, not per field group.
- **Compliance as a living dossier.** Certificates and markings expire and determine whether a product may go into inspection. The system must be proactive: flag before something expires, not after.

## Our proposal: PIM as an Updoo shell around Odoo

Here we make a deliberate architecture choice. No external PIM package - those are built for retail catalogues (many SKUs, little process), while this model is the reverse: each article carries a complete dossier with ownership per field group and an approval flow. And no heavy custom module inside Odoo either - that fights the framework and ties down your hosting.

Instead: an **[Updoo](/updoo) product as a shell around Odoo.** The shell is the source for the full 173-field model; Odoo only gets the transactional subset that orders, invoices and margins need - article number, EAN, description, cost, HS code, colli, some 15 to 20 fields. And the sync is **one direction: from the shell to Odoo.** That last part is a principle, not a detail: syncing back and forth rebuilds the Excel chaos, but more expensively. One source of truth means truly one. That principle - and where the line is - we work out separately in [PIM as a shell around Odoo](/blog/odoo-as-a-pim).

We use the same pattern for the **supplier portal**: an own portal layer on top of Odoo where suppliers upload certificates, photos and packaging data themselves, with Odoo as the data layer. Faster, more flexible and more manageable than prising open the standard Odoo portal. That way portal and PIM become one environment for the supplier, instead of two loose systems.

## What the data does after creation

Article creation is one moment; only then does it start. That is precisely why this is a living system and not an archive. The data does four things:

- **It feeds transactions.** The subset in Odoo returns on every PO and SO line, invoice and margin calculation. On a repeat order the system automatically checks whether the data still holds: certificates valid, latest artwork and manual linked.
- **It mutates.** New FOB prices, changed packaging, new manual versions, articles from New to Active to EOL - each change with date and owner. The history Excel does not keep.
- **It expires.** Certificates have an expiry date. The shell monitors it and triggers renewal at the supplier via the portal, with the mail signals you need.
- **It reports.** Packaging data becomes PPWR reporting, DPP is coming, vendor scorecards and margin dashboards draw from the same source. And a customer catalogue or website in a later phase becomes easy: the data already exists.

## Multiple entities, China and Europe

Sourcing companies almost always combine multiple countries and entities: sales in the Netherlands (and sometimes Poland), back office in China, a separate entity in Hong Kong. That stacks complexity, and there are three things to be honest about up front:

- **Bank connections.** For European banks an automatic connection is standard; for Chinese and Hong Kong banks you test this per bank. If it cannot be automatic, daily bank import is the honest alternative.
- **Hosting and performance from China.** Access to a cloud environment from China is a known point of attention. The question "Singapore versus Europe" becomes urgent when most of your users sit in China. We work that choice out in the [hosting guide](/blog/odoo-hosting-online-sh-or-self-hosting).
- **Communication.** WeChat with factories is daily reality in China, but not a standard Odoo integration. Expect email and portal in the system, WeChat alongside.

Odoo runs the entities as multi-company with consolidated reporting; the local accounting (for example the Chinese one) you often keep local and connect to the group - the trade-off is in [international accounting with Odoo](/blog/international-accounting-with-odoo). More on multilingual, international deployment in [Odoo for international rollouts](/international-odoo-partner).

## The pressure from large retailers: EDI and portals

A separate trigger that forces your hand: large retailers do not work with order lists by email. They expect **EDI connections, order statuses, a supplier portal and clean article data.** In the assessment the orders still arrived in a mailbox and were downloaded by hand - workable up to a certain volume, a bottleneck after that. You automate that order intake into sales orders in Odoo, provided you have the retailer's EDI specifications. If you also sell online yourself, this connects to our [guide on connecting Shopify to Odoo](/blog/connect-shopify-to-odoo).

## The most important architecture question

One question determines the whole setup, and you ask it in the fit-gap: **is the product model yours, or yours-for-a-specific-retailer?** If many field groups now carry a large customer's requirements, and a second retailer comes along, the model has to handle customer-specific layers - own article numbers, own compliance requirements, own artwork. That determines whether you build a dataset per customer or one generic model with customer profiles. It is the most important architecture choice of the whole project, and you make it best up front.

## How to approach it

1. **Fit-gap on the heaviest parts.** The PIM architecture (the customer question above), the EDI specifications and the user landscape across entities.
2. **Decide the source of truth.** The product model is one, not five. Sync one direction.
3. **Phase honestly.** Phase 1 = PIM, project management, orders and finance. Dashboards grow along. Website, email marketing and events come after.
4. **Test the assumptions.** Number of real users versus portal users, bank connections, hosting location - that affects both the licences and the cost. We do the honest maths in [what an Odoo implementation costs](/blog/what-does-an-odoo-implementation-cost).

## In short

A sourcing or import company does not have a stock problem but a chain problem: from the factory in Asia to the retailer in Europe everything has to add up, across multiple languages, currencies and entities. The gain is not in more software, but in **one product model that carries the whole process.** Odoo brings purchasing, sales, project management, EDI, inspections and accounting together; and with Updoo we build the PIM shell and portals where your process is unique. Standard where it can, a smart shell where it has to.

---

**Recognise this in your trading or import company?** [Schedule a no-obligation Quickscan](/scan) and we will map your chain, your scope and your biggest risks - including an honest split of what runs standard and what becomes custom.

---

**Read more:** [From Excel to Odoo](/blog/from-excel-to-odoo) · [Odoo for leasing and rental companies](/blog/odoo-for-leasing-and-rental-companies) · [Odoo for international rollouts](/international-odoo-partner) · [PIM, EDI and customer portal for wholesale](/blog/pim-edi-customer-portal-wholesale-odoo) · [Odoo hosting and data residency international](/blog/odoo-hosting-and-data-residency-international) · [Connect Shopify to Odoo](/blog/connect-shopify-to-odoo) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost) · [Updoo: extensions on Odoo](/updoo)


# Odoo from China: hosting, speed and self-hosting behind the Great Firewall
URL: https://www.fanatics.nl/blog/odoo-from-china-self-hosting
Language: en

*If a large part of your team sits in China, a question that never comes up in the Netherlands is suddenly a daily one: does Odoo stay fast and reliably reachable? There is no Odoo.sh data centre in China, Singapore and Mumbai are the nearest, and the Great Firewall stays a factor. This is what does work, when self-hosting inside China is the only route, and how to choose - as a practical elaboration of the broader [hosting and data-residency trade-off](/blog/odoo-hosting-and-data-residency-international).*

## The problem: latency plus the Great Firewall

Access to cloud environments outside China can be slow or unreliable. That comes from two things coinciding: the sheer distance to a server in Europe or the US, and the Great Firewall that filters and slows international traffic. For an occasional user that is annoying; for an operational team processing orders, stock and purchasing in Odoo all day, it is a brake on the work.

This is exactly the profile where the default choice is no longer a given. A company with a site in China and one in Europe - such as a [sourcing and import company](/blog/odoo-for-sourcing-and-import-companies) - cannot simply pick the European node and expect the Chinese office to work smoothly with it.

## What Odoo.sh does offer: Singapore and Mumbai

Odoo.sh runs on Google Cloud and offers 7 fixed hosting locations: Belgium, Iowa (US), Toronto, Dammam (Saudi Arabia), Mumbai (India), Singapore and Sydney. **None of them is in China.** The nearest are **Singapore** and **Mumbai**.

A node in Singapore or Mumbai lowers latency from China noticeably compared to Europe or the US. For many companies that is enough: your users in China work acceptably fast, and you keep the management ease of Odoo.sh. But it does not remove the Great Firewall - international traffic stays international traffic, and reliability is not equal to a server inside the country.

## Self-hosting inside China: when it is the only route

Two situations force towards self-hosting inside China:

1. **Strict data residency.** If (certain) data must physically stay in China, no Odoo.sh location covers that. There is no node in China, so local storage is only possible through your own environment inside the country.
2. **Insufficient speed despite a regional node.** If Singapore or Mumbai is still too slow or too erratic for your operational team, a server inside China is the only way to achieve truly low latency.

Self-hosting then means: running Odoo on a server or cloud provider inside China, for example a local region of Alibaba Cloud or Tencent Cloud. That gives low latency and true local storage - at the cost of the management you carry yourself (or via a partner): updates, backups, security. For a publicly reachable website an ICP registration may also be required; for an internal business application that usually does not apply.

## The trade-off: management ease versus local control

There is no universally right answer; there is the right one for your situation.

| Question | Towards Singapore/Mumbai (Odoo.sh) | Towards self-hosting in China |
|---|---|---|
| Must data physically stay in China? | No | Yes |
| How critical is speed for the China team? | Acceptable with regional node | Maximal, local server needed |
| How much management do you want to carry? | Little (managed) | More (self or via partner) |
| Publicly reachable site? | No ICP question | Possible ICP registration |

Most companies with a China team but no hard local-storage requirement do fine with a node in Singapore or Mumbai. As soon as data residency or operational speed is decisive, it tips towards self-hosting inside China.

## In short

Running Odoo from China is possible, but requires a deliberate choice. There is no Odoo.sh node in China; Singapore and Mumbai are the nearest and lower latency, but do not remove the Great Firewall. If data must physically stay in China, or speed is insufficient despite a regional node, self-hosting inside China is the only route - with more management as the price. Test the data-residency requirement up front and weigh speed and management against each other explicitly.

---

**Do you have a team or site in China and are unsure about the best hosting setup?** [Schedule a no-obligation Quickscan](/scan) and together we determine whether Singapore/Mumbai suffices or self-hosting inside China is needed.

---

**Read more:** [Odoo hosting and data residency international](/blog/odoo-hosting-and-data-residency-international) · [Chinese accounting with Odoo](/blog/chinese-accounting-odoo-localisation) · [International accounting with Odoo](/blog/international-accounting-with-odoo) · [Odoo for procurement, sourcing and import companies](/blog/odoo-for-sourcing-and-import-companies)


# Odoo hosting and data residency for international companies: where does your data live (Singapore, Europe or China)?
URL: https://www.fanatics.nl/blog/odoo-hosting-and-data-residency-international
Language: en

*With hosting most companies think of "which form": Odoo Online, Odoo.sh or self-hosting. For an international company there is a question on top of that, which often weighs heavier: **where does your data live, and who can reach it quickly and legally?** As soon as a large part of your team sits in China, for example, the choice between a Singapore node, Europe or a self-hosted environment suddenly becomes urgent. This is the trade-off, as a deep-dive on our [hosting guide](/blog/odoo-hosting-online-sh-or-self-hosting).*

## Three questions that coincide

Data location looks like a technical detail, but it touches three things at once that you cannot see separately:

- **Performance and access** - how fast and reliably can your users reach it, from where they sit?
- **Data residency and compliance** - must (certain) data physically stay in a country or region?
- **The hosting form** - Odoo Online, a chosen Odoo.sh region, or self-hosting?

For a company on one location in the Netherlands those three are rarely a problem. As soon as you go international, they start to grate - and then the default choice is no longer a given.

## Where your data can live

Briefly the options, because that is where it starts:

- **Odoo Online** runs your database in a data centre in a region that matches you. Simple, but you have little steering on the exact location.
- **Odoo.sh** runs on Google Cloud and lets you **choose the hosting region** when setting up your project, from 7 fixed locations: Belgium (Europe), Iowa (US), Toronto (Canada), Dammam (Saudi Arabia), Mumbai (India), Singapore and Sydney. This is the route if the data location must be a deliberate choice - provided your destination is on that list.
- **Self-hosting** (on-premise or with your own hosting provider) gives full control over where the data lives - at the cost of the management you carry yourself.

The choice between these forms we work out more broadly in the [hosting guide](/blog/odoo-hosting-online-sh-or-self-hosting); here it is about the location behind it.

## Performance from China: the sharpest example

If a large part of your team sits in mainland China, this is the point you cannot ignore. Access to cloud environments outside China can be slow or unreliable - a known phenomenon. Odoo.sh has no data centre in China itself; the nearest fixed locations are **Singapore** and **Mumbai**. Such a node in the region lowers latency noticeably, but does not fully remove the underlying limitations.

The trade-off then becomes concrete: a regional node (Singapore or Mumbai) for daily speed, or - for strict local-storage requirements - self-hosting within China, because an Odoo.sh node in China does not exist. We saw this at a [sourcing and import company](/blog/odoo-for-sourcing-and-import-companies) where most users sat in China: precisely there, "Singapore versus Europe" becomes not a theoretical but a daily question.

## Data residency and compliance

The second question is legal, not technical. **Data residency** is the requirement that certain data physically stays in a country or region. In the EU the GDPR applies; some countries have their own data localisation laws. That co-determines your choice:

- If your data falls under European rules, an EU node is the logical choice.
- If local legislation requires data to stay in the country, self-hosting or a local environment may be needed.
- If you work with multiple entities in multiple countries, the setup can differ per entity - which relates to how you [connect the international accounting](/blog/international-accounting-with-odoo).

The rule: test this up front. Discovering data residency requirements afterwards is an expensive surprise.

## The trade-off in practice

There is no universally right location; there is the right one for your situation. The questions that decide the choice:

1. **Where do your daily users sit?** The majority determines the logical region; the rest deliberately accepts a bit more latency.
2. **Which data requirements apply?** GDPR, local data localisation, customer or sector requirements.
3. **How critical is speed from difficult regions?** For an operational team working in the system all day, latency weighs heavier than for occasional users.
4. **How much management do you want to carry?** Self-hosting gives control over the location, but puts the maintenance on you - see the trade-off in the [hosting guide](/blog/odoo-hosting-online-sh-or-self-hosting).

## In short

For an international company hosting is not only a question of form, but of location: where does your data live, and who can reach it quickly and legally? Odoo.sh lets you choose from 7 fixed regions, self-hosting gives full control, and Odoo Online is the simplest but the least steerable. If your team is spread across regions - certainly with part in China - you make that choice deliberately, based on where your users sit and which data requirements apply. Test performance and residency up front, not afterwards.

---

**Do you have users or sites in multiple countries and are unsure about the data location?** [Schedule a no-obligation Quickscan](/scan) and together we will determine the right hosting form and region for your situation.

---

**Read more:** [Odoo from China: hosting and self-hosting](/blog/odoo-from-china-self-hosting) · [Odoo hosting: Online, Odoo.sh or self-hosting?](/blog/odoo-hosting-online-sh-or-self-hosting) · [Odoo for international rollouts](/international-odoo-partner) · [International accounting with Odoo](/blog/international-accounting-with-odoo) · [Odoo for procurement, sourcing and import companies](/blog/odoo-for-sourcing-and-import-companies) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost)


# PIM, EDI and customer portal in Odoo: the three building blocks of B2B wholesale and import
URL: https://www.fanatics.nl/blog/pim-edi-customer-portal-wholesale-odoo
Language: en

*B2B wholesale and import run on three things that must be right: clean product data, a smooth order flow with large buyers, and self-service for your customers. In practice those are three building blocks - PIM, EDI and a customer portal. Separately they work halfway; together on one data model they form the backbone of a B2B operation. This is what each does, how they come together in Odoo, and where it goes wrong.*

## Why these three together are the backbone

A wholesaler or import company does not sell to consumers who type in an order themselves on a nice webshop. It sells to other businesses: retailers, chains, buyers with their own systems and requirements. That asks for something other than a sales channel alone. It asks that your **product data is right**, that you can **exchange orders electronically**, and that your customers **can arrange their own affairs**. Those three are not separate projects - they interlock, with the product data as source.

## PIM: the product data as foundation

PIM (Product Information Management) is the management of your full item data from one source: specifications, variants, prices, images, compliance and documents. It is the foundation because everything flows from it: the catalogue that goes to retailers, the webshop, the quotes, the portal. If the product data is wrong, the rest is wrong too - then you sell wrong specifications, miss a certificate, or the portal shows a price that no longer applies.

For companies with thousands of items and a complete dossier per item (compliance, packaging, artwork) the standard product model does not always suffice. Then we build the PIM as a shell around Odoo, with only the transactional subset in Odoo itself. We worked that approach out in [Odoo for procurement, sourcing and import companies](/blog/odoo-for-sourcing-and-import-companies) - there a single item row was good for 173 columns.

## EDI: the order flow with large buyers

EDI (Electronic Data Interchange) is the electronic exchange of orders, order confirmations, delivery notes and invoices with large buyers. Where a small customer emails an order list, a large retailer expects it to go automated - and increasingly it is a hard requirement to be allowed to be a supplier at all.

Without EDI you download orders by hand from a mailbox and retype them. That works up to a certain volume and after that becomes a bottleneck and a source of errors. An EDI connection processes incoming orders automatically into sales orders in Odoo, with the right item data (from the PIM) and the statuses back to the buyer. You do need the EDI specifications of the retailer in question; that is always the first step.

## Customer portal: self-service for your customers

A B2B customer portal gives your business customers access to their own environment: order history, quickly placing repeat orders, retrieving quotes and documents, viewing invoices, managing their account. That does two things at once: it lowers the load on your inside sales team (fewer emails and calls) and it raises service and loyalty.

In Odoo you build this on the standard portal function, with an extension where your process is unique. We wrote separately about it in [B2B customer portal in Odoo](/blog/odoo-b2b-customer-portal). The portal shows the same product data as the EDI catalogue and the webshop - because it comes from the same source.

## How they come together on one data model

Here is where the real gain sits. In Odoo, PIM, EDI and the portal do not stand separately next to each other, but on one data model:

- The **product data (PIM)** feeds the webshop, the EDI catalogue and the customer portal - one source, not five.
- Orders from **EDI and the portal** become sales orders in Odoo, with the same items and prices.
- The **stock and availability** the channels show come from the same system.
- The **accounting** runs along automatically.

If you also sell online to smaller buyers, a webshop channel is the fourth building block; how you connect that is in [Connect Shopify to Odoo](/blog/connect-shopify-to-odoo). Everything on the same data model means a change in one place is right everywhere.

## Where it goes wrong

The pitfalls are always the same:

- **PIM as an afterthought.** If the product data is a loose end, the problem leaks through to every channel. Start with the data.
- **Underestimating EDI.** Every retailer has its own specifications; "an EDI connection" does not exist in general, only per buyer. How that plays out concretely at a large supermarket chain is covered in [EDI with a large retailer](/blog/edi-connection-large-retailer).
- **A portal that is only a login.** Without real self-service (repeat orders, documents, status) a portal is an empty shell that does not relieve the inside sales team.
- **Separate systems.** A separate PIM package, a separate EDI tool and a separate portal that you keep in sync by hand rebuilds the Excel chaos - more expensively. The power is in one data model.

## In short

B2B wholesale and import run on PIM, EDI and a customer portal. Product data is the foundation, EDI is the order flow with large buyers, the portal is the self-service for your customers - and the gain is that in Odoo they come together on one data model, with the product data as source. Standard where it can, a targeted extension where your process is unique.

---

**Are you building a B2B wholesale or import operation on Odoo?** [Schedule a no-obligation Quickscan](/scan) and we will map your product data, your order flows and your portal wishes - including what can be standard and what becomes custom work.

---

**Read more:** [EDI with a large retailer](/blog/edi-connection-large-retailer) · [Selling without your own warehouse](/blog/outsourced-fulfilment-odoo) · [Odoo for procurement, sourcing and import companies](/blog/odoo-for-sourcing-and-import-companies) · [PIM as a shell around Odoo](/blog/odoo-as-a-pim) · [B2B customer portal in Odoo](/blog/odoo-b2b-customer-portal) · [Connect Shopify to Odoo](/blog/connect-shopify-to-odoo) · [From Excel to Odoo](/blog/from-excel-to-odoo) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost)


# Choosing the best Odoo-Shopify connector: what the comparisons leave out
URL: https://www.fanatics.nl/blog/choosing-the-best-odoo-shopify-connector
Language: en

*"Which Odoo-Shopify connector is the best?" is the wrong question. There is no universal best, Odoo does not build one itself, and the connector is not even the most important decision. This is an honest, in-depth decision guide: the real apps with their prices and reviews, and above all the architecture questions most comparisons skip. For anyone choosing an integration seriously, and as a reference for our own consultants. This is the connector deep-dive for our [complete guide to connecting Shopify to Odoo](/blog/connect-shopify-to-odoo).*

## First, a persistent myth: Odoo has no connector of its own

Many guides open with "Odoo's native connector versus the rest". That is misleading. **Odoo S.A. does not build or maintain a Shopify connector as a core product.** Odoo own e-commerce is the Website app; anyone wanting to keep Shopify as the store and Odoo as the back office chooses a separate module. Most "Shopify connectors" on the Odoo App Store are from external vendors.

When someone says "the native connector", they almost always mean the most-used app-store module (in practice, Emipro's). That changes your choice fundamentally: you are not choosing between "Odoo itself" and "third-party", but between **three routes** we set out below.

### The exception that sets the nuance: the Odoo India connector

While combing through the Odoo App Store we came across a module that gets closer to "from Odoo" than the rest: the [Shopify Connector for Odoo](https://apps.odoo.com/apps/modules/19.0/ecommerce_shopify) by **Odoo IN Pvt Ltd**, that is, Odoo India. Why this is relevant: with almost every other connector the vendor is an external party with no tie to Odoo; here an Odoo entity itself is at the controls. That makes it a case apart, but it carries the Odoo name with caveats you should know:

- It is a project of the Indian Odoo entity, and it is explicitly marked **"Third Party"** on the App Store.
- **Support falls outside standard Odoo support.** You arrange help through the vendor, not through your usual Odoo support channel. So treat it as a separate module, with its own maintenance and support line.
- Functionally it covers the familiar ground (products, orders, stock with multi-location, customers, payments/invoicing, shipping, returns), with scheduled sync and automatic retry. Price indicatively around 174 euro.

In short: it is not a core part of Odoo backed by standard support, but it is a module worth watching, precisely because the involvement of an Odoo entity could make it more interesting over time than a random third-party. Treat it today for what it is: a separate add-on with its own support arrangement.

## The field: the players, honestly listed

This is the market as it looks now. Prices and review counts come from the Odoo App Store and the Shopify App Store and do change; treat them as a snapshot, not gospel.

| Connector | Vendor | Price (indicative) | Reputation | In short |
|---|---|---|---|---|
| Shopify Odoo Connector (`shopify_ept`) | Emipro / Teqstars | ~ €403 one-off | ~282 reviews, widely used | Odoo 8-19, webhooks + cron, BoM stock, multi-store, returns |
| Shopify Connector (`ecommerce_shopify`) | Odoo IN Pvt Ltd (Odoo India) | ~ €174 one-off | no visible rating | Carries the Odoo name but "Third Party"; support outside standard Odoo support |
| Odoo Shopify Connector PRO | VentorTech | ~ €499 one-off | ~20 reviews | Aimed at more complex multi-store/custom setups |
| Odoo Shopify Connector | TeqStars | ~ €286 one-off | ~84 reviews | Built on the GraphQL Admin API |
| Shopify Odoo Connector | Webkul | ~ €174 one-off or $35/mo | 3.5 stars / 18 reviews (Shopify) | Stock via cron (every 8h), variant prices via paid add-on |
| OdooSyncO | Techspawn | $15-30/mo | 4.6 stars / 8 reviews | Real-time, Odoo 16+ |
| Odoo Integration | TechMarbles | $35-65/mo | high score, small count (see caveat) | SaaS, no module install |
| Shopify Odoo Connector | Cybrosys | ~ €99 one-off | no visible rating | Entry level, webhooks |
| various "free" modules | Metclouds et al. | free | mixed | Limited coverage |

A few things you rarely read stated plainly:

- **CedCommerce has no Odoo-Shopify connector.** Their catalogue is marketplace integrations (Amazon, eBay, Walmart). Anyone searching that name ends up at a different product.
- **Syncoria and similar parties** sell the integration as a service (implementation), not as a priced product. That is a different purchase than an app.
- **Name confusion is real.** Syncoria, Synconics and Techspawn are three different parties; search engines lump them together. Know who you are talking to.

## It is not a software choice, but an architecture choice

The sharpest framing we found online (from a vendor, but fair): connector selection is not a software purchase, it is an architecture decision. There are roughly four routes, each with its own cost profile over three years:

| Route | Sync | Cost (3 years, indicative) | Strong for |
|---|---|---|---|
| App-store connector | Mostly cron (5-60 min), sometimes webhooks | €200-500 | Single store, < ~50 orders/day, standard process |
| iPaaS middleware (Celigo, Alumio, Patchworks) | Webhook, near real-time | €10,000-50,000 | Multiple systems, monitoring, error recovery |
| Custom integration (API) | Real-time, fully to spec | €25,000-100,000+ | Unique flows, high volume, non-standard logistics |
| Managed connector | Real-time, managed | €10,000-20,000 | Reliability without building it yourself |

The underlying question at every route is the same: **who owns the sync logic, and who fixes it at 2am?** With an app-store module that sits with the vendor (and their pace). With custom, with you or your partner. With middleware, with the iPaaS vendor. That distribution of responsibility matters more than which feature ticks the comparison shows.

## The question almost no one asks: REST or GraphQL?

This is the most underrated due-diligence question, and it separates future-proof from expiring integrations. **Shopify deprecated its old REST Admin API as of 1 October 2024** and is moving everything to the GraphQL Admin API, with endpoints disappearing in phases. A connector still leaning largely on REST may work fine today, but it is living on borrowed time.

Some vendors make an explicit selling point of this (TeqStars advertises GraphQL-native); others claim GraphQL but leave open whether that holds for all Odoo versions. The lesson is not "pick brand X", but: **just ask.** Which Shopify API does the integration run on, and what is the plan when Shopify removes the next endpoints? A vendor without a clear answer tells you more than any feature list ever could.

## Buy or build?

The eternal question, and the honest answer is nuanced. For a single store with standard processes, a good paid connector is almost always cheaper and wiser than building. Building yourself only pays off for genuinely unique flows, high volume, strict multi-store or non-standard logistics.

But whoever builds must complete the bill. From practice (and from several independent sources): a custom build demands **ongoing maintenance, roughly 5 to 15 hours a month**, more during major API or version changes. It quickly becomes a *single point of failure*, and "if the developer who built it leaves and documentation is thin, maintenance becomes extremely expensive". Every Shopify API update or Odoo version upgrade can demand paid development time.

The neutral voice from the Odoo forum sums it up well: if your requirements are simple, one of the best-selling connectors will probably work fine; test it first, and then keep an eye on your error log. That last part is not a throwaway: an integration is a living component, not a one-off project.

## What reviews do and do not tell you

Reviews are valuable, but you have to read them like a consultant, not like a buyer. The patterns that really matter:

- **Support is bimodal.** With almost every connector you see "great support, always available" next to "tickets stay open for two weeks". That is not a contradiction; it means support quality varies per case and per period. Ask about the SLA, not the stars.
- **Cron is not real-time.** Several connectors sync stock via a cron (for example every eight hours). "Even when it syncs, it is often not truly real-time." During a flash sale a sync delay of a quarter of an hour can lead to serious overselling. If scarce stock and peaks are your reality, cron is a risk.
- **Duplicates on retry.** A recurring complaint: "duplicate orders occur when a sync retry creates a second order in Odoo", and connectors that create "huge amounts of duplicate products". Ask how the integration handles retries and idempotency.
- **Returns have silent conditions.** With some connectors a return only syncs if the refund is completed in Shopify, the restock option is ticked, and an invoice exists in Odoo. Three conditions that can each fail silently.
- **Hidden add-ons.** "To sync variant prices you have to install another module." The entry price is not the end price.
- **Upgrade breakage.** Connectors that target a fixed Odoo version sometimes break at the next version upgrade. Ask about the upgrade policy.

And an honest warning about the reviews themselves: **not every high score is trustworthy.** On the app stores (the Shopify App Store and the Odoo App Store) we saw, during our inventory, a listing with almost exclusively five stars, in which the same support employee was praised by name in nearly identical wording, and where the lower reviews were hidden. That is the classic pattern of review farming. It proves nothing about a specific vendor, but it is a reason to read such scores with healthy suspicion, and to lean more on reviews that name concrete store names, countries and failing scenarios.

## The four axes that separate good from bad

Let go of the feature list. In practice these four axes decide whether a choice works out:

1. **Who owns the sync logic?** You, the app vendor, the iPaaS vendor or your partner. That determines who fixes it when it goes wrong, and how fast.
2. **Upgrade-safety on both sides.** Shopify (REST to GraphQL) and Odoo (version upgrades). An integration that breaks at every upgrade is a recurring cost.
3. **The support model.** Is there an SLA, or a forum? And crucially: what happens after the free support window? A recurring complaint is exactly that webhooks stopped after the support period ended.
4. **Edge-case behaviour.** Partial returns, bundles that deduct at component level, multi-warehouse routing, strict B2B/B2C separation and the right fiscal positions. This is where the cheap integrations fail, not on the homepage features.

## Due diligence: the questions to ask every vendor

Send this list before you sign. The answers separate the professionals from the rest:

1. Which Shopify API does the integration run on: REST or GraphQL? And what is the plan as REST is further phased out?
2. Is stock sync real-time (webhooks) or scheduled (cron)? If cron, at what frequency?
3. Is multi-store native, or via multiple instances of the module?
4. Do bundles/kits deduct at component level (bill of materials), or as a single item?
5. How are partial returns and refunds handled, and under what conditions?
6. Does the integration support multi-warehouse with routing rules?
7. Does it work on Odoo Online, or is Odoo.sh/on-premise required (for example for webhooks or customisation)?
8. How does the integration prevent duplicate orders on a sync retry (idempotency)?
9. What is the upgrade policy for new Odoo versions, and is that included in the price?
10. What happens after the free support window: is there an SLA, and what does it cost?

## Our advice: when which route

- **Single store, standard process, low volume:** a good paid app-store connector is enough. Pick one with webhooks (not just cron) and a demonstrable upgrade policy, and test it on a staging environment with your real scenarios before you go live.
- **Multiple stores or channels, serious volume, monitoring needed:** consider iPaaS middleware or a heavier connector; the higher monthly cost buys reliability and error recovery.
- **Unique flows, non-standard logistics, strategic importance:** a custom build can be the right choice, provided you deliberately assign the maintenance and upgrade responsibility.

In every case: only choose the connector once your data strategy is set (which data is leading, which way the sync goes). The connector is the final piece, not the starting point. We work that out fully in the [complete guide to connecting Shopify to Odoo](/blog/connect-shopify-to-odoo).

---

**Want help with the choice, or a second pair of eyes on a quote?** [Schedule a no-obligation Quickscan](/scan) and we weigh your scenario, your scope and the risks honestly, even if a cheaper route is the better one.

---

**Read more:** [Connect Shopify to Odoo: the complete guide](/blog/connect-shopify-to-odoo) · [Odoo hosting: Online, Odoo.sh or self-hosting?](/blog/odoo-hosting-online-sh-or-self-hosting) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost) · [Odoo reviews: 2,500+ reviews](/blog/odoo-experiences) · [All Odoo comparisons](/compare)


# Connect Shopify to Odoo: the complete guide
URL: https://www.fanatics.nl/blog/connect-shopify-to-odoo
Language: en

*Shopify is excellent at what it does: selling. But it is not an ERP. As soon as stock, purchasing, production, returns and accounting have to add up, and certainly if you have multiple channels, the question is not "how do I connect Shopify to Odoo", but "where should the truth live". This is the deep guide: the trade-offs, the choices and the why. For anyone who wants to set up an integration properly, and at the same time a reference for our own consultants.*

import ShopifyOdooScrolly from '~/components/blog/ShopifyOdooScrolly.astro'

<ShopifyOdooScrolly lang="en" />

## When is Shopify alone no longer enough?

Shopify runs your webshop fine. It pinches the moment your business grows bigger than the sales channel. The signals, and why they occur:

- **Stock never quite matches.** You sell in multiple places (webshop, B2B, marketplaces, POS) and each channel keeps its own count. Without a central source it inevitably drifts apart.
- **Manual copying into accounting or a stock system.** Every manual step is a source of errors and delay, and it does not scale with your order volume.
- **Purchasing, production or assembly that Shopify does not know.** Shopify does not know what a purchase order, a bill of materials or a production order is. As soon as stock arises from purchasing or production, you need a system that knows those processes.
- **Margin not visible.** Cost price, purchasing and sales sit in separate systems, so you do not know per order or product what you really earn.
- **Consumer and business mixed up.** Different prices, VAT treatment and stock per audience are hard to keep strictly apart in Shopify alone.

These are not webshop problems. They are signals that you need a business platform behind your webshop. That is exactly where Odoo sits.

## The core decision: where should the truth live?

The most important choice you make before installing any connector: **which system is leading for your stock?**

If Shopify is leading, you continuously keep two systems aligned by hand, and you lose the moment you sell on more than one channel: the webshop does not know what your B2B sale or your POS just deducted. If **Odoo** is leading, there is a source of truth. Odoo knows your real stock (purchasing, receipts, production, returns, multiple warehouses) and pushes available quantities to every channel.

For almost every business that does more than a single webshop, the answer is: **Odoo is the single source of truth, Shopify is a sales channel.** The rest of this guide assumes you make that choice, and shows how to make it real.

## The data architecture: what syncs, which way, and why

A good integration is not "everything with everything", but a deliberate choice per data type. Every row below is an explicit decision, with a reason:

| Data | Direction | Why this direction |
|---|---|---|
| Products (title, price, description, media) | One side leading (usually Odoo) | Editing both sides causes conflicts; pick the source |
| Stock / availability | Odoo to Shopify | Odoo knows the real stock, prevents overselling |
| Orders | Shopify to Odoo | Sales arise on the channel, are processed in Odoo |
| Customers | Shopify to Odoo | Created or matched as the order comes in |
| Shipping / tracking | Odoo to Shopify | Fulfilment happens in Odoo, status back to the customer |
| Returns / credit notes | Shopify to Odoo | Reverse plus restore stock at the correct location |
| Payment / reconciliation | Shopify to Odoo | Booked automatically and matched against the bank |

**Direction matters more than the connector.** Editing products in both systems creates conflicts; keeping stock in Shopify alongside Odoo produces drift. Two rules for conflicts: (1) define exactly one leading system per field, and (2) let the non-leading system only display that field, not edit it.

## Stock strategy: the heart of the integration

This is where it all stands or falls. Most failed integrations are, at their core, stock problems.

**Available is not the same as physical.** What you push to Shopify is not your physical stock, but your **available** stock: physical minus reserved minus an optional buffer. Push physical stock and you sell things that are already reserved.

**Reservations and a safety buffer.** Decide per channel whether you hold a buffer (for example not showing the last few units online) to dampen overselling on simultaneous sales. This is a deliberate margin against race conditions, not a technical detail.

**Real-time versus scheduled syncing.** Real-time feels ideal, but Shopify has API limits and at high volume a continuous push can run you into rate limits. The trade-off: real-time for fast movers and scarce stock, scheduled (every X minutes) or event-driven for the rest. Choose deliberately per product group instead of wanting everything real-time.

**Multiple warehouses and locations.** If you sell from multiple warehouses or partly dropship, Odoo decides which location fulfils an order and which sum of locations you push as available to Shopify. Lay down those rules before you integrate.

**Separating B2B and B2C.** This is where it most often goes wrong. Two patterns:
- **Separated stock**: separate warehouses or locations for B2B and B2C. Strict, predictable, but you have to actively allocate stock.
- **Shared pool with reservation**: one stock, where B2B orders reserve early so they are not bought away by the B2C webshop. More flexible, but demands discipline in the reservation process.
Without one of these two, your B2C webshop sells the stock you meant for a B2B customer. The choice depends on how strict the separation must be and how much manual work you accept.

## Products and mapping: the SKU is your key

Everything hangs on a reliable link key, and that is the **SKU**. Without consistent SKUs between Shopify and Odoo you get no reliable mapping of stock and orders.

- **Variants**: a Shopify product with variants maps to product variants in Odoo. Make sure the variant SKUs match on both sides, otherwise a sold variant deducts the wrong stock.
- **Direction of product management**: choose whether you maintain products in Odoo or in Shopify. Odoo-leading gives a clean source for price, cost and stock; Shopify-leading suits teams that work content-first. Not both.
- **Metafields and content**: SEO copy and rich content often prefer to live in Shopify. Agree which fields are Shopify-only, so a sync does not overwrite them.

## Bundles and kits: where it quietly goes wrong

Shopify bundles and Odoo kits look the same but work differently, and this difference quietly breaks your stock.

A bundle that sells as one product on Shopify must, in Odoo, deduct the stock of the **components**, not of a fictitious bundle product. If the integration deducts the bundle as a single item, your component stock is wrong after every bundle sale, and you only see it once the counts diverge. Odoo solves this with bills of materials or kit products that deduct at component level. Agree up front how bundles, kits and variants are mapped, and test explicitly that a bundle sale reduces the correct components.

## The order flow: from checkout to booking

An order goes through more than "it comes in":

1. **Order** comes from Shopify into Odoo, with customer, lines, discounts and shipping method.
2. **Payment** is linked: Shopify Payments, iDEAL, credit card. For accounting you want the receipt reconciled against the order.
3. **Fulfilment** happens in Odoo: picking, packing, shipping from the correct location.
4. **Tracking** goes back to Shopify, so the customer sees their status.
5. **Return or credit note** comes back into Odoo: reverse and, crucially, restore stock at the correct location, including handling partial returns.

Every step is a decision: automatic or with control, immediate or batched. For accounting, reconciling payments against orders is the point where many integrations stall halfway.

## Tax and accounting: where a local partner wins

This is where a generic international connector often falls short and where Dutch knowledge makes the difference:

- **VAT and fiscal positions**: B2C with VAT, B2B with reverse charge or intra-community, that requires the right fiscal positions in Odoo.
- **EU sales and OSS**: sell across the border to consumers and the One Stop Shop scheme and per-country VAT come into play.
- **Peppol and e-invoicing**: increasingly relevant for business invoicing in the Netherlands and the EU.
- **Reconciliation and daily closing**: the bridge between your sales channel and books that add up.

This is exactly why "installing a connector" is not the same as "your e-commerce accounting adds up".

## Multiple stores and channels: the allocation rules

Multiple stores (per country, brand or B2B/B2C) can hang off one Odoo environment, each with its own warehouse, price list and channel. The pitfall is stock allocation: without rules one store sells the others empty. Decide up front how stock is allocated and reserved, whether you use a separate location per store, and how you handle shared stock. This is the same question as the B2B/B2C separation, one level broader.

## Choosing the connector: a decision matrix

There are roughly three routes. None is universally best; choose on scenario:

| Route | Strong when | Watch out |
|---|---|---|
| App-store connector (e.g. Webkul, Emipro) | Standard scenario, live fast, limited budget | Less control over edge cases; customisation often hard; quality varies per vendor |
| Odoo own Shopify connector | You want to stay within the Odoo ecosystem | Scenario coverage can be narrower than a specialised app |
| Custom integration (via the API) | Complex or unique flows, full control | Requires Odoo.sh or on-premise and maintenance; every customisation is upgrade risk |

The selection criteria: number of stores and countries, direction and frequency of the sync, product mapping, bundles/kits and variants, order statuses, control over stock updates, and your hosting form (customisation requires [Odoo.sh or on-premise](/blog/odoo-hosting-online-sh-or-self-hosting)). Weigh maintenance too: an integration is not a one-off project but a living component that has to keep working through every Shopify and Odoo upgrade. Buyers often search by connector name, but the connector is the final piece, not the starting point. We compare the real apps, their prices and reviews, and the architecture questions most comparisons skip, in [choosing the best Odoo-Shopify connector](/blog/choosing-the-best-odoo-shopify-connector).

## Implementation approach: how to set it up properly

The order that makes the difference between an integration that lasts for years and one you keep repairing:

1. **Fit-gap first.** Map your e-commerce processes, channels, stock flows and accounting requirements before you choose a connector.
2. **Lay down the data strategy.** Per data type: which system is leading, which way it syncs, real-time or scheduled.
3. **Design the stock model.** Warehouses, locations, buffers, B2B/B2C separation, allocation rules.
4. **Build on staging and dry-run.** Test with real scenarios: a bundle sale, a partial return, simultaneous sales on two channels, an order across multiple warehouses.
5. **Go live with a stock baseline.** Start with matching stock on both sides, and actively monitor for drift in the first weeks.

## Failure modes and diagnosis (for consultants)

When it goes wrong, the cause is almost always one of these. Recognise the pattern:

- **Stock drifts apart.** Cause: stock kept in two places, or physical instead of available pushed, or a channel (POS, B2B) deducts outside Odoo. Fix: one source, push available, all channels through Odoo.
- **Overselling.** Cause: sync frequency too low for fast movers, no buffer, or no B2B/B2C separation. Fix: real-time for scarce stock, buffer, separation.
- **Stock wrong after a bundle sale.** Cause: bundle deducted as a single item instead of components. Fix: kit or bill of materials at component level.
- **Duplicate customers.** Cause: no matching on email at creation. Fix: matching rule on a unique field.
- **Orders get stuck.** Cause: unknown SKU, missing fiscal position, or a payment method without mapping. Fix: complete the mapping and set up error handling.
- **Accounting does not reconcile.** Cause: payments not reconciled against orders, or wrong VAT treatment. Fix: automate reconciliation, fiscal positions per audience.

## In short

Shopify sells, Odoo runs your business. Make Odoo the single source of truth, decide per data type which way the sync goes, push available instead of physical stock, separate B2B and B2C stock deliberately, map bundles at component level, arrange tax and reconciliation, and only choose the connector once the data strategy is set. Then the integration becomes a foundation instead of a risk - and 42 is finally the answer in both systems.

---

**Want to know whether your stock or channel problem is an integration or a platform choice?** [Schedule a no-obligation Quickscan](/scan) and we will map your e-commerce processes, your scope and your biggest risks in 20 minutes.

---

**Read more:** [Odoo hosting: Online, Odoo.sh or self-hosting?](/blog/odoo-hosting-online-sh-or-self-hosting) · [Odoo Community vs Enterprise](/blog/odoo-community-or-enterprise) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost) · [Odoo reviews: 2,500+ reviews](/blog/odoo-experiences) · [All Odoo comparisons](/compare)


# The most-asked Odoo questions (with honest answers)
URL: https://www.fanatics.nl/blog/most-asked-odoo-questions
Language: en

import OdooReviewsScrolly from '~/components/blog/OdooReviewsScrolly.astro'

*Which questions do people really ask about Odoo? We gathered the topics that come up most on the Odoo forum, Stack Overflow, GitHub and in our own implementations - and paired them with honest, practical answers. No marketing, just the nuance you need before you start.*

Odoo is broad and flexible, and precisely for that reason the same questions keep surfacing: about cost, about the choice between Community and Enterprise, about why an implementation runs over or customisation breaks on upgrade. We ordered them into the clusters that come up most. If you would rather know what users themselves say about Odoo, read our analysis of [2,500+ public reviews](/blog/odoo-experiences).

## Cost and licensing

### What is the difference between Odoo Community and Enterprise?
Both run on exactly the same core and database. Enterprise adds Studio (no-code customisation), a set of exclusive apps, official support and smoother upgrades. With Community you carry the maintenance and upgrade risk yourself. Company-wide use almost always leans on Enterprise in practice; Community fits those with developers in-house. We work through the full trade-off in [Odoo Community vs Enterprise: which to choose?](/blog/odoo-community-or-enterprise).

### What does Odoo really cost?
The licence is transparent, but that is rarely the problem. The real costs are in implementation, data migration, customisation, training and hosting. That is not an Odoo quirk - it applies to any ERP - but it is often underestimated. We do the honest maths in [what does an Odoo implementation cost](/blog/what-does-an-odoo-implementation-cost).

### Why does "every change" suddenly become paid customisation?
This is the heart of what we call the flexibility tax: the same modularity that sells is where people get stuck. Without scope discipline, configuration quietly slides into customisation, and every customisation becomes an upgrade risk. The remedy is not less Odoo, but more discipline: processes first, phase the modules, and deliberately record where you will not customise.

## Implementation and approach

### Why do Odoo implementations run over or fail?
The cause is almost never the software. The pattern: no process definition up front, too many modules switched on at once, and no training or change management. You see this back in nearly every hard review discussion - the biggest disappointment is attributed by the community itself to scope, expectations and approach, not to Odoo.

### Is it better to buy Odoo directly from Odoo or via a partner?
For a simple setup, going direct can be enough. As soon as multiple processes, departments, countries or integrations come into play, partner quality becomes decisive. A recurring pattern in public discussions: a lot of frustration arises from buying hours or support directly from Odoo. We weigh it honestly in [Odoo directly or via a partner](/blog/odoo-direct-or-via-a-partner).

### Which modules do I need, and in what order?
Start from the process, not the app list. Pick the modules that touch your core process (sales, inventory, accounting) and get those right before you expand. Switching everything on at once is the fastest route to a stalled project.

## Accounting and localisation

### How do I set up the chart of accounts and VAT correctly?
Install the fiscal localisation package for your country: it brings the chart of accounts, the taxes and the fiscal positions. For EU VAT, set the fiscal positions per country so the correct VAT is applied automatically. Regional tax detail is exactly where it goes wrong if you try to do it by hand.

### My inventory valuation is off - why?
Usually a combination of negative stock and a wrongly set costing method or counter-accounts. Deliberately choose your valuation method (FIFO or standard cost) and check the inbound and outbound stock accounts.

## Customisation, upgrades and technical

### Why does my customisation break on an upgrade?
On a version upgrade, XML IDs are renamed or removed and the API changes. Customisation that leans on them must be ported, with migration scripts, and tested on a clean database. Building upgrade-safe (with inherit and a precise xpath instead of replacing whole blocks) greatly limits the damage.

### Why is Odoo slow with a lot of data?
The ORM gets heavier at scale. Archiving, indexing, batch processing and tuning workers resolve most bottlenecks. Importantly: slow performance points to the quality of customisation more often than to Odoo core.

### A menu or field is invisible to a user - why?
Access in Odoo works on two levels: access rights govern which actions are allowed on a model, record rules govern which rows are visible. A menu stays hidden until both are set correctly. This is one of the most-asked admin questions.

### How do I integrate Odoo with another system?
Odoo has an external API (XML-RPC/JSON-RPC): you authenticate with an API key and call models. For most companies the question is not "can it integrate" but "which integration stays maintainable through future upgrades" - and there, a considered design matters more than the technology itself.

## Hosting

### Odoo.sh, self-hosting or Odoo Online?
Odoo.sh is Odoo own managed hosting (Enterprise, per worker, with staging and Git) - best suited to teams running customisation who want to test before production. Self-hosting is cheaper on licence, but you carry backups, updates and upgrades (a major upgrade quickly runs to tens of hours). Odoo Online is the simplest, but the least flexible for customisation. We lay out the three forms, with diagram and table, in [Odoo hosting: Online, Odoo.sh or self-hosting?](/blog/odoo-hosting-online-sh-or-self-hosting).

<OdooReviewsScrolly lang="en" />

## The common thread

Lay these questions side by side and a pattern jumps out: almost none of them are really about the software. They are about costs that were not guarded, scope that was not defined, customisation without discipline, and expectations that were not aligned. That is good news, because it means a good approach de-risks exactly the things people get stuck on.

We saw the same in our own [analysis of 300+ ERP switchers](/blog/erp-switchers-analysed): companies rarely switch because "it could be better", but because of a forced moment - and whoever then fails to guard scope and approach ends up in exactly the pitfalls above.

---

**Is your question not here, or do you want it tailored to your situation?** [Schedule a no-obligation Quickscan](/scan) and we will map your process, your scope and your biggest risks in 20 minutes.

---

**Read more:** [Odoo Community vs Enterprise: which to choose?](/blog/odoo-community-or-enterprise) · [Odoo hosting: Online, Odoo.sh or self-hosting?](/blog/odoo-hosting-online-sh-or-self-hosting) · [Odoo reviews: what do 2,500+ users say?](/blog/odoo-experiences) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost) · [Odoo directly or via a partner](/blog/odoo-direct-or-via-a-partner) · [300+ ERP switchers analysed](/blog/erp-switchers-analysed) · [All Odoo comparisons](/compare)


# Odoo Community vs Enterprise: when does free cost more than paid?
URL: https://www.fanatics.nl/blog/odoo-community-or-enterprise
Language: en

*One of the first choices with Odoo is also one of the most misunderstood: Community or Enterprise? One is free and open source, the other paid - but choosing on that basis looks at the wrong axis. The real question is not "free or paid", but: do I make myself dependent on licences, or on technology? This is an honest decision guide based on user discussions, Odoo documentation and our analysis of [2,500+ Odoo reviews](/blog/odoo-experiences).*

> ## Short conclusion
>
> **Community is not a "lesser Odoo".** It is a different distribution of responsibility. Community saves licence costs, but shifts hosting, maintenance, upgrades, support and module choices to you. Enterprise costs per user, but buys standardisation, official upgrades, support and less technical management.
>
> **The decision rule:** choose Odoo Community when technical control matters more to you than standardisation. Choose Odoo Enterprise when continuity, accounting, upgrades, support and less technical management matter more than avoiding licence costs.

## Community vs Enterprise in one sentence

- **Community** = control and lower licence costs, in exchange for technical ownership.
- **Enterprise** = extra apps, support and official upgrade paths, in exchange for a per-user subscription.

## What is exactly the same?

This is often forgotten: the engine is identical. Community and Enterprise share the same source core, the same data model and the same base apps for sales, purchasing, inventory, CRM and projects. So you are not building on a stripped-down second-rate version with Community - the foundation is the same. What Enterprise adds is not different software, but a package of features, service and risk transfer.

## Which features are in Community, which only in Enterprise?

Handy as a reference - for prospects and for internal staff. These are the features that most often make the difference:

| Component | Community | Enterprise |
|---|---|---|
| Core apps (sales, purchasing, inventory, CRM, project) | Yes | Yes |
| Invoicing | Yes | Yes |
| Full accounting (bank reconciliation, follow-ups, assets, budgets, tax reporting) | No | Yes |
| Studio (no-code customisation) | No | Yes |
| Exclusive apps: Subscriptions, Helpdesk, Field Service, Documents, Sign, Planning, Quality, PLM | No | Yes |
| Marketing Automation, MRP extensions, Quality/Maintenance | No | Yes |
| Mobile app (iOS/Android) | No | Yes |
| VoIP / IoT integrations | No | Yes |
| Official Odoo support | No (community/partner) | Yes |
| Automated version upgrade | No (self/OCA/partner) | Yes |
| Hosting on Odoo.sh | No | Yes |
| OCA modules (free, community) | Yes | Yes |
| Source code customisable (open source) | Yes | Yes (with licence terms) |
| Licence cost | Free | Per user (roughly 20-30 euro per month) |

The two that most often tip the decision in practice are **Studio** (customising without code) and **full accounting**. Anyone wanting to use Odoo as a financial system quickly falls short with Community's invoicing - unless you fill that gap with OCA modules.

## The real axis: ownership, not features

Most "Community vs Enterprise" articles put down a feature table and are done. But the question behind the search is not "which features are included". It is: **who do you want to hold responsible for your ERP - your own technical team, a partner, the community or Odoo itself?**

So the most useful table is not "which features do I get", but **which responsibility do you buy off?**

| Topic | Community | Enterprise |
|---|---|---|
| Licence | No licence costs | Per user |
| Support | Community / partner / own team | Official support + partner |
| Upgrades | Yourself / OCA / OpenUpgrade / partner | Official upgrade flow available |
| Accounting | Via invoicing + OCA or customisation | Full by default |
| Hosting | Arrange yourself | Odoo Online / Odoo.sh / on-premise |
| Flexibility | Very high | High, within the Enterprise context |
| Risk | Technical ownership sits with you | Cost and vendor dependence higher |

See also our overview of the hosting forms in [Odoo hosting: Online, Odoo.sh or self-hosting?](/blog/odoo-hosting-online-sh-or-self-hosting) - because the edition and hosting choices interlock.

## What do users say online?

In public discussions (Reddit, the Odoo forum) and in our own [analysis of 2,500+ reviews](/blog/odoo-experiences), a strikingly consistent pattern emerges. Community is found attractive for its low or absent licence costs, full control and self-hosting. But the same users name recurring breaking points: **accounting, support, upgrades, hosting management and the technical knowledge required.**

The biggest trigger to look towards Enterprise is almost always **accounting**. A recurring story: someone uses Community fine for CRM, project and recruitment, but cannot fully switch without proper accounting and tax reporting. Sharper still: companies that run on Community for years and only discover, once serious administration, compliance and data quality kick in, that their accounting configuration is off. **The Community choice is often only truly tested once the administration gets serious.**

## Why do companies move from Community to Enterprise?

- **Accounting becomes a core process** - auditability, localisation, tax reporting, analytic accounting, closing processes.
- **Less technical management** to carry as the organisation grows.
- **Official support** instead of depending on forums or a single internal specialist.
- **Automated upgrades** instead of porting every version yourself.
- **Consolidation** of scattered tools into one maintained platform.
- **Compliance and governance** at a larger, more regulated organisation.

## Why do companies stay on Community?

- **No licence costs** - relevant with many users or tight budgets.
- **Self-hosting and full control** over data and infrastructure.
- **Technical knowledge in-house** (Odoo, Python, Linux) to carry the management.
- **The OCA ecosystem** with thousands of free, quality modules.
- **Less dependence** on a vendor and on recurring licences.

## The forgotten third route: Community + OCA + partner

Many articles pretend there are only two flavours. In practice there is a serious third: **Odoo Community, supplemented with OCA modules and a good partner.** The <a href="https://odoo-community.org/" target="_blank" rel="noopener">Odoo Community Association</a> is a non-profit that maintains thousands of community-maintained modules and open upgrade tools, aimed at cheaper and more successful Odoo implementations.

This route approaches much Enterprise functionality, including accounting, without licence costs. The flip side: you choose, maintain and upgrade those modules yourself (or via your partner). So it is not "free Enterprise", but a fully-fledged ecosystem for those who know what they are doing. Not "Community is less" - rather "Community demands discipline".

## Can you go back? Enterprise to Community

Community to Enterprise is a supported path: same database, you activate the subscription code and the extra apps become available (Odoo <a href="https://www.odoo.com/documentation/19.0/administration/on_premise/community_to_enterprise.html" target="_blank" rel="noopener">documents this switch</a> itself). The reverse is a completely different story. You have to remove Enterprise modules, find alternatives for Enterprise apps, and records created by those modules can be archived or lost on removal. In public discussions this is described as tricky or unsupported, often with the advice to start over and move data via export and import.

> **The migration law:** Community to Enterprise is usually expanding. Enterprise to Community is usually dismantling.

So do not build around a choice you should simply make. Customisation you stack on Community to mimic an Enterprise feature later becomes redundant or even an upgrade blocker.

## What does it really cost? The hidden-cost formula

"Free" is about the licence, not the cost of ownership. Do the honest maths on both editions:

> **Total cost of Community** = hosting + management + support + upgrades + module quality (OCA) + customisation + internal technical ownership.
>
> **Total cost of Enterprise** = licences + implementation + hosting choice + support/partner + any customisation.

A major version upgrade of a customised Community install quickly runs to tens of hours. That is not an argument against Community - it is an argument to complete the bill. We work through the broader cost breakdown in [what does an Odoo implementation cost](/blog/what-does-an-odoo-implementation-cost).

## The ownership matrix

Still unsure? Run through these questions. More answers on the left means Community fits; more on the right means Enterprise.

| Question | Leans Community | Leans Enterprise |
|---|---|---|
| Do you have in-house Odoo/Python/Linux knowledge? | Yes | No |
| Is accounting a core process? | Only with strong OCA/partner knowledge | Yes |
| Do you want official support? | Less important | Important |
| Do you want self-hosting and maximum control? | Yes | Sometimes, via on-premise/Odoo.sh |
| Do you want as little technical management as possible? | No | Yes |
| Do you want easy, predictable upgrades? | Only with a strong technical approach | Yes |
| Is the organisation growing towards more compliance? | Less urgent | Yes |

## The honest conclusion

The Community-versus-Enterprise choice is not a pricing question but a responsibility question. **Community and Enterprise are not two price packages, but two ways to organise ERP responsibility.** Community moves the work and the risk to you (or your partner); Enterprise largely buys it off.

For a technical team with a need for control, Community - especially with OCA - can be excellent. For most organisations that want Odoo as the beating heart of their business, with full accounting and as little technical management as possible, Enterprise is the honest choice. Not because it is "better", but because you need the service and certainty that come with it.

The wrong question is "which version is cheaper?". The right question is: **which responsibility do you want to carry yourself?**

---

**Want this tailored to your situation?** [Schedule a no-obligation Quickscan](/scan) and together we will determine which edition, which hosting and which approach fit you - including an honest fit-gap on accounting and customisation - in 20 minutes.

---

**Read more:** [Odoo hosting: Online, Odoo.sh or self-hosting?](/blog/odoo-hosting-online-sh-or-self-hosting) · [Odoo reviews: what do 2,500+ users say?](/blog/odoo-experiences) · [The most-asked Odoo questions](/blog/most-asked-odoo-questions) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost) · [Odoo directly or via a partner](/blog/odoo-direct-or-via-a-partner) · [All Odoo comparisons](/compare)


# Odoo reviews: what do users really say?
URL: https://www.fanatics.nl/blog/odoo-experiences
Language: en

import OdooReviewsScrolly from '~/components/blog/OdooReviewsScrolly.astro'

*Odoo promises a lot: one platform for almost your entire business. But what do users say once they have really started with it? We analysed over 2,500 verified reviews on G2 and Capterra, plus hundreds of forum questions and discussions on Reddit, the Odoo forum and independent sources. This is what we found.*

There is a lot of noise about Odoo online, from "best decision ever" to "stay away". We wanted to look past the isolated opinions: which patterns keep coming back when you lay thousands of experiences side by side? Not to glorify or trash Odoo - we are an Odoo partner, so we are not neutral - but to honestly understand when Odoo works, and when it goes wrong. To offset our own bias, we deliberately lean on public, verifiable reviews that anyone can check.

<OdooReviewsScrolly lang="en" />

> ## Short conclusion
>
> Odoo is broadly appreciated for its wide functionality, modularity and price-quality ratio. On the major review platforms it scores mid-high: **G2 4.3/5** (over 1,200 reviews), **Capterra 4.2/5** (over 1,300). At the same time, those same reviews show consistent criticism of **support, hidden costs and sales pressure, the learning curve, upgrades that break customisations, and variable partner quality**.
>
> The common thread almost no one says out loud: **the biggest disappointments are rarely about the software - they are about scope, expectations and the implementation approach.** Odoo is not an app you just "switch on". It is a business platform. And precisely for that reason, the approach determines whether it stays cheap and powerful, or becomes expensive and frustrating.

## How we researched this

We combined two layers. **Public and independent:** hundreds of reviews and discussions on <a href="https://www.g2.com/products/odoo-odoo-erp/reviews" target="_blank" rel="noopener">G2</a>, <a href="https://www.capterra.com/p/135618/Odoo/reviews/" target="_blank" rel="noopener">Capterra</a>, Trustpilot, TrustRadius, <a href="https://www.reddit.com/r/Odoo/" target="_blank" rel="noopener">Reddit r/Odoo</a> and the <a href="https://www.odoo.com/forum/help-1" target="_blank" rel="noopener">Odoo forum</a>. **Unique and our own:** our own analysis of [over 300 Dutch companies looking for a new ERP](/blog/erp-switchers-analysed).

We did not copy reviews, but clustered them by theme - price, support, implementation, customisation, accounting, inventory, performance, ease of use, partner - with the sources attached. Where we cite a number, it is publicly verifiable; where that was not possible, we leave it out. We care about the pattern, not isolated anecdotes.

**The research in numbers** (as of July 2026):

- **2,551 verified reviews** on the two largest platforms: G2 (4.3/5, 1,237 reviews) and Capterra (4.2/5, 1,314 reviews, including the public star distribution), supplemented by TrustRadius, Trustpilot and Software Advice.
- **23 Reddit discussions** (r/Odoo, 2020-2026), coded into 41 data points with sentiment and theme.
- **28 recurring question topics** from the Odoo forum, Stack Overflow and GitHub - the basis for the most-asked-questions analysis.
- **26 additional sources** from independent review sites and advisory bureaus, including Dutch ones (e.g. ICT Portal), distinguishing independent from partner/vendor sources.
- **300+ Dutch companies** from our own switcher analysis as a second, first-party layer.
- Method: one theme taxonomy (17 themes), sentiment per item, all source URLs logged, summarised at theme level in our own words. Our own and partner content excluded from the independent tallies.

## What users value about Odoo

The market is remarkably unanimous about the strong points:

- **All-in-one, modular.** Pick the apps you need; they work together on one data model. "Pick and choose what apps you need", as one user summed it up.
- **Integration that removes double entry.** CRM, sales, inventory and accounting in one place - the classic escape from disconnected tools.
- **Price-quality ratio.** Recurring compliment: cost-effective compared to a stack of separate SaaS or a heavy enterprise ERP. One long-time user: "Odoo is literally my lowest expense."
- **Strong in manufacturing and inventory.** The manufacturing app in particular gets a lot of praise on Reddit ("the manufacturing application is amazing").
- **Scales along and is open.** Lots of standard functionality, a large ecosystem, and your data stays yours.

## Where it hurts

Exactly that strength - breadth and flexibility - is also where it goes wrong. The recurring criticism:

- **Support after go-live is inconsistent.** "Once you pay, customer support disappears", is a recurring Trustpilot sentiment. Standard support is not always set up for business-specific questions.
- **Price: hidden costs and sales pressure.** Reviews complain about costs that only surface after signing, price increases when changing plans, and heavy selling of "Success Packs". Capterra's own summary flags billing as a notable negative theme.
- **Learning curve and implementation heavier than expected.** "Odoo has a steep learning curve" - and without sharp choices, configuration quickly turns into customisation.
- **Upgrades can break customisations.** Those who customise a lot run into migration work with every version upgrade. This is a structural theme, not an incident.
- **Partner quality varies widely.** The independent Dutch ICT Portal even warns that many partners are "small operations with 1-2 clients" - so vet your partner well.
- **Performance at scale.** With lots of data or users it can get heavy; multi-company feels clunky.

We also keep the honest caveat in: part of the criticism genuinely touches the product or the company (outdated documentation, unpredictable prices, sales behaviour), separate from the approach. That is part of the picture.

## The common thread: the software is rarely the problem

This is the finding that stayed with us most, and that you see back in almost every hard discussion: **the biggest disappointment is attributed by the community itself to scope, expectations, buying support directly from Odoo, or missing a good partner - not to the software.**

A few recurring reframes from public Reddit discussions:

- On a thread about a failed implementation, the highest-voted reply is: it has *"less to do with Odoo itself and more to do with the BA you have sourced"* (the internal business analyst).
- On *"worst platform in 15 years"* the two highest-voted replies are: get a partner - and someone who, after three years, considers it the best system on the market.
- Several experienced users: do not buy large hour packages directly from Odoo, *"not to buy huge hours from Odoo directly"*, but take a local partner who knows your process.

There is even a price paradox in it: Odoo is so cheap that people also expect free support - and are then disappointed. The software is broadly respected; the pain clusters around the *approach*.

That connects seamlessly with what we saw in our [own analysis of 300+ switchers](/blog/erp-switchers-analysed): companies almost never switch because "it could be better", but because of a forced moment - and whoever then fails to guard scope and approach ends up in exactly the negative reviews above.

## When does Odoo fit well - and when less so?

**Good if:** you want to get rid of disconnected systems; you have processes around sales, inventory, purchasing, manufacturing, service or e-commerce; you want to grow without constantly bolting on new software; and you accept that standardising is often smarter than rebuilding everything.

**Less good if:** you are looking for a plug-and-play accounting tool; you want to rebuild every existing process exactly; you have no time for involved key users; or you see ERP purely as an IT project.

## Directly from Odoo, or via a partner?

Not every company immediately needs a heavy partner - it would be dishonest to claim that. But the data points one way: as soon as Odoo touches multiple processes, departments, countries, warehouses or integrations, partner quality becomes decisive. A good partner helps above all with *choices*: what do we do standard, what not, what in phase 1, where is customisation justified, and how do we keep upgrades safe.

Want to sharpen that trade-off? Read our honest comparison [Odoo directly or via a partner](/blog/odoo-direct-or-via-a-partner).

## Checklist: how to avoid a bad Odoo experience

- Have we done a real fit-gap before installing anything?
- Do we know which processes can run standard - and have we explicitly decided where there will be no customisation?
- Has the data migration been realistically estimated?
- Is local accounting and tax knowledge secured?
- Is there one point of contact with a mandate, and are key users involved?
- Is training part of the project, and is support after go-live arranged?
- Are we choosing a phased approach, or trying to do everything at once?

---

**Odoo is not the right choice for every company. But if your organisation is ready for one integrated platform, Odoo is often surprisingly powerful and affordable. The real question is not "is Odoo good?" - it is "will Odoo be set up well for your business?".** That is where the difference lies between an enthusiastic review and a frustrating experience.

**Have your Odoo approach challenged before you begin.** [Schedule a no-obligation Quickscan](/scan) and we will map your process, your scope and your biggest risks in 20 minutes.

---

**Read more:** [The most-asked Odoo questions, honestly answered](/blog/most-asked-odoo-questions) · [Odoo Community vs Enterprise](/blog/odoo-community-or-enterprise) · [Odoo hosting: Online, Odoo.sh or self-hosting?](/blog/odoo-hosting-online-sh-or-self-hosting) · [Why companies really switch ERP: 300+ switchers](/blog/erp-switchers-analysed) · [Odoo directly or via a partner](/blog/odoo-direct-or-via-a-partner) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost) · [All Odoo comparisons](/compare)


# Odoo hosting: Online, Odoo.sh or self-hosting?
URL: https://www.fanatics.nl/blog/odoo-hosting-online-sh-or-self-hosting
Language: en

import OdooHostingDiagram from '~/components/blog/OdooHostingDiagram.astro'

*You have chosen between Community and Enterprise - but you are not done yet. The next question is just as decisive: where does Odoo run? Odoo Online, Odoo.sh or your own server? That choice decides whether you can run customisation, who does the upgrades, and what support you get. Here is the honest overview.*

What many companies overlook: "which Odoo" is really two questions. One about the edition (Community or Enterprise), and one about the hosting form. They are connected, but not the same. The edition decides which features you get; the hosting form decides where it runs, who manages it and how much you can customise. This article is about that second question.

<OdooHostingDiagram lang="en" />

## The three hosting forms

### Odoo Online
The simplest option: fully Odoo-managed cloud. You log in and it works - backups, updates and upgrades happen automatically. The price is that you cannot run custom code or third-party apps. You can configure and customise with Studio. Odoo Online has a free "One App" variant and an "All Apps" subscription. For companies with standard processes that want to start quickly, this is often enough.

### Odoo.sh
Odoo developer cloud, exclusive to Enterprise. Odoo.sh gives you a production, staging and development environment with Git integration and automatic backups - and, crucially, the room to run customisation and third-party apps. You choose between a shared and dedicated environment, priced per worker. This is the sweet spot for companies that want the conveniences of the cloud but still need customisation.

### Self-hosting (on-premise)
You run Odoo on your own server or with your own hosting provider. Maximum control and customisation possible, but you carry the backups, security updates, maintenance and version upgrades yourself. Official Odoo support and our support are more limited here, simply because we do not manage the environment. For most companies the management work does not outweigh the control - unless there is a specific reason (compliance, data location, existing infrastructure).

## In a table

| | Odoo Online | Odoo.sh | Self-hosting |
|---|---|---|---|
| Edition | Enterprise | Enterprise | Community or Enterprise |
| Custom code | No | Yes | Yes |
| Third-party apps | No | Yes | Yes |
| Backups & updates | By Odoo | By Odoo | Yourself |
| Version upgrades | Automatic | Assisted | Yourself (heavy work) |
| Staging environment | No | Yes | Set up yourself |
| Support (Odoo + Fanatics) | Full | Full | Limited |
| Best for | Fast start, standard | Customisation with cloud ease | Maximum control |

## Two things that often go wrong

**Customisation and Odoo Online do not mix.** The most common surprise: a company picks Odoo Online to start quickly, then gets stuck later because customisation or an external integration turns out to be needed. Know up front whether you will run customisation - then you start straight on Odoo.sh instead of having to migrate later.

**Switching is usually only possible on a major version.** Migrating between hosting forms (for example from Online to Odoo.sh) is a supported path, but not a switch you flip on a whim. Plan such a move around a version upgrade (xx.0) and test it up front.

## How does this relate to Community vs Enterprise?

The two choices interlock. Odoo Online and Odoo.sh are Enterprise-only; self-hosting works with both editions. So if you want the cloud conveniences of Odoo.sh, you are automatically on Enterprise. The full trade-off between the editions is in [Odoo Community vs Enterprise: which to choose?](/blog/odoo-community-or-enterprise).

## The honest conclusion

The hosting choice comes down to the same question as the edition choice: how much work and risk do you want to carry yourself, and how much do you want to buy off? Odoo Online buys off the most (but trades away flexibility), self-hosting gives the most control (but puts the work on you), and Odoo.sh sits deliberately in between. For most companies with some customisation need, Odoo.sh is the golden mean.

---

**Unsure which hosting form fits you?** [Schedule a no-obligation Quickscan](/scan) and together we will determine the right combination of edition, hosting and approach - in 20 minutes.

---

**Read more:** [Odoo Community vs Enterprise](/blog/odoo-community-or-enterprise) · [The most-asked Odoo questions](/blog/most-asked-odoo-questions) · [What does an Odoo implementation cost?](/blog/what-does-an-odoo-implementation-cost) · [Odoo reviews: 2,500+ reviews](/blog/odoo-experiences) · [All Odoo comparisons](/compare)


# All 749 Odoo partners of Europe analysed: 96% work only in their home country
URL: https://www.fanatics.nl/blog/european-odoo-partners-analysed
Language: en

import EuroPartnerScrolly from '~/components/blog/EuroPartnerScrolly.astro'

*After analysing [300+ ERP switchers](/blog/erp-switchers-analysed) and [the Dutch partner landscape](/odoo-partners-netherlands), we went a size up: we mapped every Odoo partner in Europe. 749 firms, 21 countries, over 23,000 references. One question drove it: who actually works across the border?*

If you have entities in several countries and one ERP to roll out, you go looking for a partner who can handle that. But how big is that choice really? We pulled the complete partner directory from odoo.com (snapshot 5 July 2026), de-duplicated firms listed in several countries, and counted.

<EuroPartnerScrolly lang="en" />

## How we researched this

We collected every listing in the official odoo.com partner directory for 21 European countries: 789 listings in total. Odoo lists a partner in a country when it has an office there, so firms with offices in several countries appear multiple times. After name matching (stripping legal suffixes and country qualifiers, plus manual checks on variants like "braintec Schweiz" and "braintec Deutschland"), **749 unique firms** remained.

One limitation up front: this measures *office presence*, not *delivery*. A partner can implement across a border without an office there - we do exactly that ourselves. But presence is the only publicly verifiable measure, and it tells a clear story.

## The numbers

| | |
|---|---|
| Unique partner firms | **749** (789 listings) |
| Countries | 21 |
| Gold / Silver / Ready | 94 / 183 / 512 |
| Present in ≥2 countries | **28 (3.7%)** |
| Present in ≥3 countries | **8 (1.1%)** |
| Total published references | ± 23,400 |

Per country, large to small: France 133, Belgium 130, Spain 90, Germany 81, Italy 66, Switzerland 58, Netherlands 51, UK 34, Austria 31, Luxembourg 20 - then eleven countries with fewer than 20 partners.

## Finding 1: Gold is scarce

Only **12.5%** of European partners hold Gold status. More than two thirds (512 of 749) sit at Ready, the entry level - a good share of them with fewer than ten references. Anyone "looking for an Odoo partner" is in practice choosing from a much smaller pool of proven implementation firms than the gross counts suggest. For the Netherlands we worked this out in detail in [the Dutch partner landscape](/odoo-partners-netherlands).

## Finding 2: the border is nearly sacred

**96.3% of European Odoo partners are present in exactly one country.** Of the 28 border-crossers, nearly all follow the language: Belgian partners step into France, Irish into the UK, Scandinavians among each other. The eight firms present in three or more countries form the complete European top:

| Partner | Countries | References (total) |
|---|---:|---:|
| Dynapps | 5 | 895 |
| OBS Solutions | 5 | 372 |
| Nalios | 3 | 443 |
| braintec | 3 | 184 |
| Camptocamp | 3 | 177 |
| Flyt | 3 | 89 |
| Metrum | 3 | 60 |
| Sodexis | 3 | 45 |

Hats off to these eight - serving several countries with local offices is a serious achievement. But notice what is *not* there: none of them combine Europe with, say, the US, the Middle East, Asia and Oceania.

## What this means if you have entities across borders

The practical conclusion for a company with entities in several countries: the default choice is either a local partner per country (with the same design discussions three times over and nobody owning the whole), or one of the eight office-builders above.

There is a third route, and it has nothing to do with offices: **the architecture of Odoo itself**. Multi-company runs all your entities in one database, with local fiscal rules per entity. Whoever masters that design delivers across any border - from one team. In fairness: that is exactly how we do it, so read this paragraph with that in mind. We have one office (Amsterdam) and have delivered Odoo in [13 countries](/international-odoo-partner), from Germany and Italy to the US, China, Dubai and Australia - including self-built fiscal localisations for the Central African Republic and Ghana, where Odoo shipped none.

References tell you who is *big*, not who is *good*. In follow-up research we scored these partners on seven quality measures - see which [European Odoo partners are truly leading](/blog/most-forward-thinking-odoo-partners-europe).

*Source: odoo.com partner directory, 21 European countries, snapshot 5 July 2026. Counts move throughout the year; we refresh this research periodically. We are part of this dataset ourselves (Netherlands, Silver, 69 references).*


# The most forward-thinking Odoo partners in Europe: 52 scored on 7 measures
URL: https://www.fanatics.nl/blog/most-forward-thinking-odoo-partners-europe
Language: en

import PartnerScoreScrolly from '~/components/blog/PartnerScoreScrolly.astro'
import PartnerScoreTable from '~/components/blog/PartnerScoreTable.astro'

*In earlier research we counted [300+ ERP switchers](/blog/erp-switchers-analysed) and [all 749 Odoo partners of Europe](/blog/european-odoo-partners-analysed). References tell you who is big. This time we asked a different question: who is forward-thinking? What can we learn from the partners leading the way?*

A ranking by customer count mostly rewards age and size. But a buyer wants something else: who builds their own products, who shares real knowledge, who is open about price, who uses AI concretely? We scored 52 European Odoo partners on seven such measures - and the striking thing is: **no single partner is best at everything**. Scroll along; the leader changes on every measure.

<PartnerScoreScrolly lang="en" />

## What stands out

The key lesson is in the movement above: **forward-thinking is not one thing**. 360ERP and OBS Solutions build impressive own AI agents. braintec won Best Partner Europe four times. Prelium is crystal clear on price with a public calculator. Somko, Eezee-it and manaTec publish ranges of their own apps. Every partner has a corner it excels in - which is exactly why "the best partner" does not exist, only the best match.

We (Radical Fanatics) are in fact one of the smaller partners: by number of references we are near the bottom (50th of 52) and we are the second-youngest partner on the list. On awards we do better: our single award puts us among the ten firms that hold any at all, against 42 that hold none. Yet we finish first on the sum of the seven quality measures - because we are the only one strong everywhere and the only one with a published book and original research. Not the biggest, then, but the most well-rounded. Read that knowing we designed this rubric ourselves.

<PartnerScoreTable lang="en" />

## What to do with this

Use these seven measures as your own checklist in a partner conversation. Ask about own products and the method they use. Ask whether they are open about price. Ask what they concretely do with AI, not whether they "do something with AI". And weigh awards, but not more heavily than the match with your company. Want to see how we work on these points? Explore [the Dutch partner landscape](/odoo-partners-netherlands) or [our international approach](/international-odoo-partner).

*Source: manual review of 52 European Odoo partner websites, snapshot 5 July 2026. Scores are interpretation; the rubric is public. Counts and offerings move; we refresh this research periodically.*


# Why companies really switch ERP: we analysed 300+ switchers
URL: https://www.fanatics.nl/blog/erp-switchers-analysed
Language: en

import ErpSwitchersScrolly from '~/components/blog/ErpSwitchersScrolly.astro'

*We speak to business owners looking for a new ERP every week. To understand what really drives them, we analysed over 300 Dutch companies actively shopping around. Here is what we found.*

Everyone has a gut feeling about why companies switch ERP systems. "The old system is too expensive." "They want to move to the cloud." "A competitor got something new." But what are the real reasons, when you line up a few hundred switchers side by side?

We looked into it. Below are the five most common reasons to switch ERP, with real (anonymised) quotes, plus the one thread almost nobody names out loud.

<ErpSwitchersScrolly lang="en" />

> ## Key findings
>
> Based on 300+ analysed Dutch ERP switchers:
>
> - **Missing functionality (~45%)** - the system lacks inventory, planning, work orders, projects or a B2B portal.
> - **Outgrew a bookkeeping package (~35%)** - Excel or a package like SnelStart/Moneybird/Twinfield has been outgrown by the operation.
> - **Outdated or end-of-life (~30%)** - forced migration by end of support or a mandatory cloud move.
> - **Fragmentation (~28%)** - loose tools, double entry, connectors that do not add up.
> - **Unhappy vendor (~12%), too expensive (~10%), custom build stuck (~8%).**
>
> **The common thread:** almost nobody switches because "something better exists". The switch is nearly always triggered by a forced moment. Companies usually name several reasons at once, so the percentages add up to more than 100%.

## How we researched this

We analysed over 300 Dutch companies that were actively looking for a new ERP - from sole traders to organisations with hundreds of employees, spread across manufacturing, wholesale, installation, professional services, food, e-commerce and more. For each company we looked at two things: which system they run now, and why they want to switch. All examples and quotes in this article are anonymised; we care about the pattern, not the individual companies.

## The 5 most common reasons to switch ERP

### 1. The system lacks what you need (~45%)

By far the most-named reason. Not that the system is broken - it is just missing a piece. Inventory management, capacity planning, digital work orders, project administration with post-calculation, a B2B ordering portal. A machine shop said: *"little grip on the projects and the system has no inventory module."* A wholesaler: *"they know how much stock they have, but not where it is."*

The underlying cause is almost always the same: the current system was designed for one thing (usually the bookkeeping or one industry), and the business has grown processes that ended up hanging around it.

### 2. You have outgrown your bookkeeping package (~35%)

A huge group does not yet run a real ERP, but a bookkeeping package plus Excel. While it stays small that works fine. But growth pinches: *"works mostly from Excel now and that is starting to hit its limits."* And: *"everything by hand, dockets handed in too late and the invoice to the customer already gone."* And this is not reserved for small companies: we spoke with [a trading company with tens of millions in revenue still running entirely on Excel](/blog/from-excel-to-odoo).

This is a distinct category because the answer is different. Whoever outgrows [SnelStart](/snelstart-alternative), [Moneybird](/moneybird-alternative) or [Twinfield](/twinfield-alternative) is not looking for a better bookkeeping package but for a business platform where accounting is part of the whole.

### 3. The system is outdated or shutting down (~30%)

The most powerful decision trigger: you are forced. End of support, a mandatory cloud migration, or a vendor that stops developing. *"Exact Globe is no longer supported after this year."* *"Multivers is no longer being developed."* *"This ERP now has to move to S/4HANA and they are not going to do it."* And a classic: *"an old AS/400 from the late nineties. It is now hitting its limits."*

This is exactly the moment not to blindly take a sidestep. If you have to migrate anyway, use that one migration well - see [Exact Globe is end-of-life: what now?](/blog/exact-globe-end-of-life) and [Odoo vs Multivers](/odoo-vs-multivers).

### 4. Everything is held together with tape (~28%)

Fragmentation: a bookkeeping package, a separate CRM, Excel for planning, a standalone webshop, and connectors that not quite run smoothly. *"Exact Online in combination with all kinds of loose tools."* *"loose systems, which leads to manual work and inefficiency."* The books add up, but the operation leaks: double entry, errors, and nobody with the full picture.

### 5. Unhappy, too expensive, or custom build stuck (~30% combined)

The tail is three smaller but recognisable reasons. **Unhappy with the vendor or partner** (~12%): *"they want to part ways with their current partner."* **Too expensive** (~10%), often with heavy enterprise systems: *"this is seen as too heavy and too expensive."* And **custom builds that get stuck** (~8%): the self-built system maintained by one person - *"a custom system that no longer gets updates and is maintained by one person"* - a risk that grows with the years.

## Where do companies switch away from?

Besides the why, we looked at the from. Roughly five starting points:

| Starting point | What we saw | Dominant pain |
|---|---|---|
| Excel / no system | Large share, often growers | Outgrown, functionality |
| Bookkeeping package (SnelStart, Moneybird, Twinfield) | Big group | Outgrown, fragmentation |
| Accounting-ERP (Exact family, AFAS) | Very often named | Outdated, functionality |
| Industry-ERP (Syntess, Isah, Gilde, Multivers) | Substantial | Unhappy, outdated, too expensive |
| Big ERP (SAP, NAV/Navision, NetSuite) | Smaller, but clear | Outdated (forced upgrade), too expensive |

The most-named individual packages: **[Exact](/odoo-vs-exact)** (Online and Globe) number one by a distance, followed by **[SnelStart](/odoo-vs-snelstart)**, **[AFAS](/odoo-vs-afas)**, **[Multivers](/odoo-vs-multivers)**, **[Twinfield](/odoo-vs-twinfield)**, **[Syntess](/odoo-vs-syntess)** and **[Microsoft Dynamics/Navision](/odoo-vs-dynamics)**.

## The common thread: almost nobody switches because "something better exists"

This is the finding that stuck with us most. You would expect companies to switch because they want something better. But in practice the trigger is nearly always a concrete event: the system runs end-of-life, a forced cloud migration arrives, the business outgrows its package, or the maintainer of the custom system leaves. "It could be better" is a dormant feeling; only a forced moment gets people moving.

That has a practical consequence. If you are forced to migrate anyway, that is exactly the moment not to take the smallest step (a sidestep to the same type of system), but to choose well once. Migrating twice - first the sidestep, then the real switch after all - is the most expensive scenario we see.

One striking aside: a single prospect named digital sovereignty as an explicit criterion - *"it may not be an American system, it has to be a European system."* Not a dominant theme yet, but a growing voice.

## What does this mean for you?

Do you recognise yourself in one of the five reasons? It helps to know which category your pain falls into:

- **Missing functionality, or everything held together with tape?** Then you want a broad platform where inventory, sales, projects and accounting sit on one system. Compare on our [comparison pages](/compare) or browse the [alternatives guide](/alternatives).
- **Have you purely outgrown your bookkeeping package?** Check whether you really need an ERP or whether a lighter step suffices - we are honest about that.
- **Forced by end-of-life?** Use that moment. Do not take a sidestep; choose well once.

We are an Odoo Gold Partner and therefore not neutral - but we will just as readily tell you when a lighter package, or simply staying put, is the better choice. Want to know where your pain falls and what a switch delivers? [Book a free Quickscan](/scan) and we will map it in 20 minutes.

---

**Read more:** [Odoo reviews: what do 2,500+ users say?](/blog/odoo-experiences) · [Is your ERP ready for retirement?](/blog/time-to-retire-your-erp) · [Exact Globe is end-of-life: what now?](/blog/exact-globe-end-of-life) · [All ERP comparisons](/compare) · [The best ERP alternatives, honestly compared](/alternatives)


# Implementing Odoo directly or through a partner? An honest assessment
URL: https://www.fanatics.nl/blog/odoo-direct-or-via-a-partner
Language: en

import StatRow from '~/components/blog/StatRow.astro'

**Short answer:** if you start directly with Odoo, you buy the software plus a limited number of guidance hours (a Success Pack). For a simple start - CRM, invoicing, a handful of users - that can be perfectly fine. As soon as Odoo touches multiple departments - accounting, inventory, purchasing, manufacturing, e-commerce, migration, reporting - it turns from an installation into an implementation project. Then a good partner almost always pays for itself. Not because the software falls short, but because successful adoption demands context, sharp process choices and implementation discipline you cannot buy in loose advisory hours.

Below is the honest assessment, including when you do not need a partner.

## The numbers behind this piece

This piece started with an analysis of Odoo's own published FY2025 figures by [Frederick Tubiermont](https://www.linkedin.com/posts/fredericktubiermont_i-pulled-odoos-public-numbers-audited-fy2025-share-7476968099003432960-yAbE/), vendor-neutral, based on public accounts and Odoo's own partner dashboard. The top line is strong: 28% revenue growth to 545 million euro, 48 million euro operating cash flow, 6.5 million leads at roughly 33 to 46 euro each, and almost a doubling of paying customers. An impressive acquisition machine.

<StatRow eyebrow="Odoo FY2025, from public figures" stats={[
  { num: '€545m', label: 'revenue, +28% YoY' },
  { num: '6.5m', label: 'leads in 12 months' },
  { num: '~€33-46', label: 'cost per lead' },
  { num: '197,747', label: 'paying customers (was 115,762)' },
  { num: '88%', label: 'leads are micro-business <5 staff' },
  { num: '0', label: 'public figures on retention' },
]} />

But the nuance sits in what a "customer" is. The dashboard shows 758,160 "customers", roughly 9 times the audited net add of 81,985 paying customers. That gap is funnel volume: sign-ups, trials, free tier. Not paying customers. And 88% of the lead base is companies with fewer than five employees, a segment that typically churns fast. Whether the underlying maths (LTV against CAC) works depends entirely on how long those customers stay: roughly five to seven years, meaning annual churn below 15%. That one figure, cohort retention, is on no public surface.

For you, as a company weighing Odoo against a partner, that is not an abstract debate. It is the question: how do you make sure you are in the group that stays, rather than the one that drops off? That is what the rest of this piece is about.

## Activating software is not the same as using Odoo successfully

Odoo is remarkably good at something most ERP vendors never managed: making ERP attractive. Quick to start, lots of apps, a sharp licence price, a modern interface, a low-threshold online entry. That approach works, and it is exactly why Odoo is growing so fast.

But a trial is not an implementation. A database is not a business foundation. An activated app is not an adopted process. A company that *tries* Odoo is not yet the same as a company that uses Odoo successfully for sales, purchasing, inventory, manufacturing, accounting, service, projects and management information.

For you as a customer that is the whole point. The question is not "can I start with Odoo?", you almost always can. The question is: "will I get Odoo genuinely embedded in my daily operation?" That is the difference between a system that is technically live and a system that adds value.

## Why many companies start directly with Odoo (and when that is fine)

Many companies begin directly with Odoo. Sometimes via the website, sometimes because they want to explore what is possible first, sometimes because it looks low-threshold and affordable. Nothing wrong with that, in fact it is one of Odoo's greatest strengths.

Often a [Success Pack](/blog/odoo-success-pack) comes alongside: a number of guidance hours from Odoo itself to get you going. On paper logical, and for a simple start it works.

In practice such a pack often turns out too tight. Fifty hours sounds manageable, but for a serious implementation with accounting, inventory, sales, purchasing, migration, permissions, reporting and local requirements it is frequently simply too little. And the model works differently than customers expect up front: the consultant configures, but is not necessarily close to your daily operation. Local tax practice, sector-specific processes, on-site workshops, change management and bringing your users along often fall outside what you thought you bought.

That is not a reproach, it is simply a different model. Odoo's direct approach is scalable, product-focused and efficient. ERP success just often calls for something else: proximity, process knowledge and implementation discipline. And that is exactly when companies end up at a partner after all.

## What does a good Odoo partner actually do?

Partners are often seen as "implementation capacity", a way to buy hours. But the real value is not in the number of available consultants. It is in experience, context and honesty. A good partner does not simply execute what you ask, it helps determine what is wise.

### 1. Real experience with similar companies

Odoo is broadly applicable. That is a strength and a risk: because almost anything seems possible, the idea quickly arises that every wish is easy to configure. A partner who has done similar implementations sees sooner where the project really gets hard. Not from theory, but from experience.

A trading company with stock and barcode scanning runs into different questions than a manufacturer with bills of materials, quality checks and planning. A webshop has different risks than a service firm with project invoicing. That experience prevents you from repeating known mistakes, and helps determine when a process is better left standard, when customisation is justified and when a wish mainly adds complexity without real business value.

### 2. Knowledge of the local market

ERP is never fully universal, certainly not once accounting, tax, reporting, e-invoicing, payment files, VAT rules or local working methods come into play. An international consultant can know a lot about Odoo and still lack a feel for the local practice.

Think of VAT logic and reporting, audit files, bank connections, Peppol and e-invoicing, statutory accounts processes, accountant expectations and the way SMEs organise their administration. That looks like detail work, but those are precisely the details that determine whether you gain trust in the system. If finance is not right, the whole project is under pressure. A local partner also understands how your people work, which terms they use and which reports they are used to.

### 3. Honest advice on what does and does not belong in Odoo

Odoo can do a lot. But not everything belongs in Odoo. Perhaps the most important role of a partner is protecting you from the idea that one system must by definition do everything.

Some processes fit excellently in Odoo. Others are better left in a specialised application, certainly if it is business-critical, contains a lot of industry functionality or already works well. A good partner therefore dares to say not only "yes, that is possible", but also:

- "That is possible, but I would not do it."
- "That is possible, but it gets needlessly complex."
- "That does not belong in phase one."
- "An integration is wiser there."
- "This is standard Odoo, better adapt your process to it."
- "This is strategic enough to justify customisation after all."

That honesty is essential. Most ERP projects fail not because the software can do too little, but because too few sharp choices are made.

### 4. Honest advice on Odoo Studio

With Odoo Studio you quickly make fields, screens, automations and small adjustments without classic development. For small extensions that is useful. But Studio becomes risky as soon as it becomes a replacement for good design, clear scope and robust development. Too many Studio adjustments lead to clutter, technical debt, difficult upgrades and functionality that is just not good enough for business-critical use.

Our rule of thumb: use Studio as little as possible, and only where it really fits. Not because Studio is bad, but because an ERP system has to last for years. What feels like a quick fix today can become a problem later with growth, upgrades or integrations. A good partner thinks about maintainability tomorrow, not just the fastest configuration today. More on this: [Odoo Studio is rarely the solution](/blog/odoo-studio-rarely-the-solution).

### 5. Services beyond the standard Odoo scope

An ERP implementation almost always touches more than Odoo alone: connections with webshops, marketplaces, payment providers, carriers, BI tools, CPQ, portals, PIM systems or custom work. And also things that do not traditionally fall under ERP but do determine success: data quality, reporting, management information, accounting setup, security, hosting, performance, support processes and user adoption.

In the end you do not buy software modules, you want a working business process. Sometimes that is standard [Odoo](/odoo-erp). Sometimes Odoo with a good integration. Sometimes customisation outside Odoo. And sometimes deliberately *not* building something. That broader view makes the difference.

## When do you not need a partner?

Honesty matters: not every customer needs a partner. For small companies, simple processes or organisations with enough in-house knowledge, starting directly can work fine. If you mainly use CRM, simple invoicing or basic project management, a full implementation project is overkill.

If you want to do part of it yourself, it helps to be realistic about the hours, get your data in order up front, and assign someone internally who owns the project. Bringing in a partner can also be phased: start yourself, and add a partner the moment it gets more complex.

## The tipping point: when Odoo becomes infrastructure

As soon as Odoo touches multiple departments, financial processes, inventory, manufacturing, logistics, integrations, management reporting, the nature of the project changes. Then Odoo is no longer a tool, but infrastructure. And you do not implement infrastructure with a few loose advisory hours.

Then you need a plan. A scope. Ownership. Process choices. Data migration. Test scenarios. Training. Aftercare. And someone who dares to say "this should not happen yet" or "this is better left standard". That is exactly where a partner adds value, with a [proven implementation method](/target).

## How to choose? A short decision framework

**Starting directly with Odoo makes sense if:**

- you have a small team and simple processes (CRM, invoicing, basic projects);
- you have the in-house knowledge and time to configure it yourself;
- you want to explore Odoo before you invest;
- finance and inventory do not (yet) play a big role.

**A partner almost certainly pays for itself if:**

- Odoo touches multiple departments or business-critical processes;
- a data migration or integrations are involved;
- accounting, VAT, e-invoicing or reporting have to be exactly right;
- you run manufacturing, inventory or complex logistics;
- you have no internal project owner or implementation experience;
- you want to do it right once rather than repair it later.

In doubt? Then do not start with the feature list, but with the question: where is my biggest risk, in the software or in the rollout? With ERP the answer is almost always the latter. To make that concrete, look at a few [customer cases](/cases) or take a no-obligation [Quickscan](/quickscan). Already on Odoo but it grinds with your current partner? Read [switching Odoo partner](/blog/switching-odoo-partner).

## Frequently asked questions

**Do I need an Odoo partner?**
Not always. For a simple start with CRM or invoicing and enough in-house knowledge, you can begin directly with Odoo. As soon as Odoo touches multiple departments - accounting, inventory, manufacturing, integrations or migration - a good partner almost always pays for itself, because success then sits in the rollout, not the software.

**Is an Odoo Success Pack enough for a full implementation?**
For a simple start or orientation a Success Pack can be enough. For a serious implementation with accounting, inventory, sales, purchasing, migration and reporting, a pack of 25 to 50 hours is often too tight. Be realistic about the hours required up front.

**What does an Odoo partner do that Odoo itself does not?**
A good partner brings experience with similar companies, knowledge of the local market and tax practice, honest advice on what does and does not belong in Odoo (including restraint with Studio and customisation), and services beyond the standard Odoo scope such as integrations, data quality and user adoption.

**Can I start with Odoo myself and bring in a partner later?**
Yes. Many companies start themselves and bring in a partner once it gets more complex. Bear in mind that early choices about data structure, permissions and customisation are harder to undo later, ideally have a partner look along before the irreversible decisions.

**How do I choose the right Odoo partner?**
Look for demonstrable experience with companies like yours, knowledge of the local market, and the willingness to say no or not yet rather than confirming every wish. A partner who protects you from unnecessary complexity is worth more in the long run than one who promises everything. More on our approach as an [Odoo partner in the Netherlands](/odoo-partner-nederland).

## In closing: choose on adoption, not activation

Odoo's growth is impressive, and the entry is rightly attractive. But whether Odoo works for *you* rarely depends on the software and almost always on the rollout. A lead is not a customer, a database is not a foundation, and an activated app is not an adopted process.

Odoo can open the door. A good partner makes sure you still walk through it happily three years from now. So choose not on who is live fastest, but on what makes your business successful and keeps it that way. That is, in the end, the only metric that counts.


# Odoo Studio: rarely the solution, often the start of the problem
URL: https://www.fanatics.nl/blog/odoo-studio-rarely-the-solution
Language: en

**Short answer:** Odoo Studio is Odoo's low-code layer for changing fields, screens and automations without programming. Tempting, but we are deliberately cautious with it. On version upgrades, Studio changes regularly break - fields disappear from views, inherited views get reset - and combined with custom code it almost inevitably leads to faults that are hard to localize. For anything that genuinely matters, we prefer customisation you can isolate and switch off.

## What Odoo Studio promises

Studio is appealing, and we get it. You do not have to wait for a developer, you quickly add a field yourself, adjust a screen or build a small automation. For small, isolated things that is fine. We are not against Studio; we are against Studio as the default answer to every wish.

Because the story does not stop at "it works today". An ERP system has to last for years, and that is exactly where it pinches.

## Where it goes wrong: the upgrade

Odoo ships a new version every year. Changes you make in the interface on top of the standard views do not always survive such an upgrade. In practice we see it as fields that have suddenly disappeared from a view, or inherited views that were reset to standard on the upgrade.

The result: after the upgrade your freshly configured screen looks different, and you have to rebuild it by hand. Right at the moment you are already busy with the upgrade itself, and without a clean record of what was there. That is not an incident, it is a recurring pattern.

## Even riskier: Studio plus custom code

It gets genuinely dangerous when Studio and custom code live side by side. Studio changes the view in the database, custom code changes things in code, and the two layers do not know about each other.

On a fault you then cannot tell whether it is Studio, the custom code, or the clash between the two. Those are exactly the faults that cost hours to find, because there is no single place to look. The more Studio changes sit on top of a custom implementation, the more opaque the whole thing becomes.

## Why we prefer custom development: you can switch it off

The biggest advantage of a clean custom module is simple: you can isolate it. If something breaks, you switch the module off. Does it work again? Then you know where the fault sits. Still broken? Then it is somewhere else.

That off/on test is invaluable for localizing faults, and it is exactly what you cannot do cleanly with Studio changes woven into the database. On top of that, custom code lives in version control, can be tested against a new Odoo version before the upgrade, and shows you exactly what changes. That is not a luxury; it is the difference between a manageable system and a system nobody dares to upgrade anymore.

| | Odoo Studio | Custom development (module) |
|---|---|---|
| Change something small fast | Strong | Slower |
| Behaviour on upgrades | Breaks regularly (fields gone, views reset) | Tested, in version control |
| Isolatable on faults | No, woven into the database | Yes: switch off, fault localized |
| Combining with custom code | Risky, hard to debug | One consistent codebase |
| Long-term maintenance | Unpredictable | Manageable |

## When Studio is fine

Honestly: Studio is not the devil. An extra field on a non-critical model, a quick prototype to show an idea, a small standalone automation. For that kind of small, isolated thing Studio can work fine, as long as you accept you may have to check it after an upgrade.

The line sits at two things: business-critical, and the presence of custom code. As soon as one of those comes into play, Studio's speed no longer outweighs the risk.

## Our rule of thumb

Use Studio as little as possible, and never for anything business-critical or in combination with custom code. As soon as it matters, or as soon as custom code is already nearby, choose customisation you can isolate, test and switch off.

That is not dogma against low-code; it is hard-learned from upgrades and faults. Odoo Studio is rarely the solution. Often it is the start of the problem.

## Frequently asked questions

**Is Odoo Studio bad?**
No, not bad, but we are deliberately cautious with it. For small, isolated changes Studio can work fine. The risk is in the pattern: on upgrades Studio changes regularly break, and combined with custom code it leads to faults that are hard to localize.

**Do Studio changes break on an Odoo upgrade?**
Yes, regularly. We see fields disappear from a view and inherited views reset to standard on the upgrade. Your freshly configured screen then looks different and has to be rebuilt by hand, right during the upgrade.

**Odoo Studio or custom development?**
Small and isolated, on a non-critical model: Studio can do it. Business-critical, or alongside existing custom code: choose custom development. A custom module can be isolated, tested against a new Odoo version and lives in version control, so you know exactly what changes.

**Can you combine Odoo Studio and custom code?**
Technically yes, but it is risky. Studio changes the view in the database, custom code changes it in code, and the two layers do not know about each other. On a fault you then cannot tell whether it is Studio, the custom code, or the clash between them. Those are the faults that cost hours.

**What do you do when something breaks?**
With custom development we simply switch the relevant module off to see if the problem disappears. If it does, you know where the fault sits. That off/on test is invaluable for localizing, and you cannot do it cleanly with Studio changes woven into the database.

## Want a system that is still upgradable in three years?

That is exactly what we steer for: changes you can isolate, test and roll back, instead of invisible edits that produce surprises on every upgrade. More on that trade-off in [Implementing Odoo directly or through a partner](/blog/odoo-direct-or-via-a-partner) and our [implementation method](/target). Want to talk it through for your situation? [Book a free intro call](/contact).


# Switching Odoo partner? How to move safely to a new Odoo partner
URL: https://www.fanatics.nl/blog/switching-odoo-partner
Language: en

import Checklist from '~/components/blog/Checklist.astro'

You already run Odoo, but the partnership with your current partner is not going as hoped. Tickets pile up. Advice feels reactive. Customisation is poorly documented. Or you notice your business is growing faster than your current Odoo partner can handle.

Then the question naturally comes up: can we move to another Odoo partner without losing our licences, database, progress or knowledge?

The short answer: yes, in most cases you can. But it is important to organise the switch carefully. Below you will read when switching is wise, what stays yours, and a step-by-step plan for a safe move.

## Can you just switch Odoo partner?

**Yes, in most cases you can move to another Odoo partner. Your Odoo database, licences and business data are and stay yours. You do need to check how your hosting, Odoo.sh project, customisation, documentation and current agreements are set up.**

The practical steps can differ per situation: Odoo Online, Odoo.sh, self-hosted or external hosting each have their own points of attention. And you are not locked to a partner just because you use Odoo; the partner relationship is separate from your ownership of licences and data. Always check your current contract for notice periods and agreements.

## When is it wise to switch Odoo partner?

Not sure whether it is you or the partner? These are signals that often point to a mismatch:

- You mainly get tickets resolved, but little strategic advice.
- Your partner does not know your industry or processes well enough.
- A lot of customisation was built, but nobody knows exactly why.
- Your project stalls or keeps slipping.
- You miss local knowledge of accounting, tax, e-commerce or logistics.
- You started directly with Odoo on a Success Pack, but miss local guidance or on-site involvement.
- Your current partner no longer fits your stage: you have grown, gone more international or become more complex.

That last one is common: many companies start directly with Odoo on a Success Pack and later find they need more proximity, industry knowledge or development than that model offers. More on that in [Implementing Odoo directly or through a partner](/blog/odoo-direct-or-via-a-partner).

## What stays yours when you switch?

Reassuring: most of it stays yours. Pay attention mainly to who has access and ownership where.

| Component | Does it stay? | What to watch |
|---|---|---|
| Odoo database | Yes | Check who is owner and admin |
| Odoo licences | Yes | The partner link must be changed |
| Data | Yes | Make a back-up up front |
| Customisation | Usually yes | Check repository, documentation and ownership |
| Odoo.sh | Yes, but the handover needs care | Check GitHub, repository and access |
| Support agreements | No, those change | Cancel or let the current contract expire |
| Knowledge of your setup | Not automatically | Have an audit or fit-gap done |

Important: your database, licences and data are yours, not your partner's. Some partners suggest otherwise, but that is not correct. What you do need to arrange is who is currently owner and admin, so access is handed over cleanly.

## Step-by-step: how to switch Odoo partner

Moving to a new Odoo partner usually works in seven steps.

### Step 1: Decide why you want to switch

Not just "we are unhappy", but concretely: speed, quality, industry knowledge, project approach, communication, customisation, support, cost or strategic advice. The sharper your reason, the more targeted your choice of a new partner.

### Step 2: Make a short handover analysis

Map your current setup: which apps you use, which custom modules are active, where Odoo runs, who has admin rights, whether documentation exists, and which tickets or projects are still open. This prevents surprises during the handover.

### Step 3: Choose a partner that fits your stage

Do not choose on size alone, but on experience with companies like yours and the stage you are in. Compare your options and see what you may expect from a good [Odoo partner in the Netherlands](/odoo-partner-nederland).

### Step 4: Invite several partners

Not to run a price contest, but to see a difference in vision. Let partners respond to your current setup, the risks they see and the first improvement points. That tells you more than a polished pitch.

### Step 5: Have an Odoo audit or fit-gap done

A good new partner does not start blind with support. First you want to know what is there, what is fragile and which choices are wise. This step prevents you from quietly carrying old problems along.

### Step 6: Arrange the formal handover

Coordinate the handover with your current partner and, where needed, your Odoo account manager. Practically it covers licences and partner link, database management, Odoo.sh, GitHub repository, hosting, admin rights, domains, email and external integrations. Put agreements in writing where you can.

### Step 7: Plan a soft landing

The first 30 days are about stability: checking access, walking through critical processes, building documentation, prioritising open issues and delivering a few quick wins. That makes the switch feel like progress right away.

## The biggest risks in a partner switch

The biggest risks usually sit not in the licences, but in access, documentation, customisation, hosting and knowledge transfer. Especially with Odoo.sh, external hosting, custom modules and integrations it is important to check up front who owns which parts. An audit beforehand surfaces these points before they become a problem.

## Not every partner lets you go easily

Honestly: partners deal with switchers differently. Some cooperate maturely, as they should. Others try to make a switch harder, for example by tightening terms, dragging out the handover, or not readily handing over access and customisation. We have seen both in practice, and it often says a lot about how a partner views the relationship.

We do not think it is fair to bash partners in public. But we have guided quite a few switchers by now, so we know the patterns. Want to know whether your current partner is on our (informal) blacklist, and what the smartest switch strategy is in your case? [Get in touch, no strings attached](/contact), and we will talk it through privately.

**Where we stand.** Radical Fanatics does not believe in holding clients back from switching in any way. We believe the best quality and service should be the glue, not a contract that locks you in. That is why we work with short-term contracts, every client can get the master password of their own Odoo.sh database, and customisation built specifically for a client can be taken to another environment. As it should be: your data, your system, your choice.

<Checklist title="Ask a new partner this, up front" items={[
  'Do I always have access to my own data?',
  'Do I always get admin access to the system, wherever it is hosted?',
  'Can I take customisation you build for me to another partner?',
  'Do you work with short contracts, or am I locked in for long?',
  'Do I get (on Odoo.sh) the master password of my own database?',
]} />

### Customisation: ask whether you can take it with you

If you have customisation built, always ask up front whether you can take it to another partner. Not every partner is open to that. With us, customisation developed specifically for a client is transferable to another environment. Put this in writing before development starts, not only when you already want to switch.

## Frequently asked questions

**Can I just switch Odoo partner?**
In most cases yes. Your Odoo database, licences and business data usually stay yours. Check up front how your licences, hosting, Odoo.sh project, customisation and current agreements are set up, and review your contract.

**Do my Odoo licences stay if I switch?**
Usually yes. Licences sit with your company; on a switch it is mainly the partner link that changes. Depending on contract and hosting the execution can differ.

**Does my Odoo database stay?**
Yes, your database and data are yours. Make a back-up up front and check who is owner and admin.

**What happens to custom modules?**
Customisation usually stays, but check where the source code lives, whether it is documented and who owns it. On Odoo.sh this often ties to a GitHub repository.

**Does my current partner have to cooperate?**
For some steps (access, repository ownership, hosting) cooperation is helpful or needed. Much can also be arranged yourself or via Odoo. Put agreements in writing.

**How do you hand over an Odoo.sh project?**
An Odoo.sh project ties to a GitHub repository and access rights. Check who owns the repository and project, and transfer ownership and rights carefully.

**How long does switching take?**
Often a few weeks, depending on complexity, integrations and customisation. A new partner usually starts with an audit or fit-gap.

**What does it cost to switch?**
The biggest cost sits in the handover and an optional audit, not in the licences. A modest upfront investment pays off because you do not start blind.

## Not sure your current Odoo partner still fits?

You do not have to stay stuck in a partnership that slows your project. But you should not switch impulsively and buy the same problem again. The best switch starts with insight: what is there now, what is fragile, and which partner actually fits your business?

That is why we recommend an independent review, an **Odoo switch scan**. In a short scan we map what is in good shape, where the risks sit and which steps are needed to switch safely. [Start with an Odoo scan](/scan) or [book a free intro call](/contact).

And if, in the same breath, you are wondering whether the system itself still fits: take an honest look at the [Odoo alternatives](/blog/odoo-alternatives) first - usually the doubt turns out to sit with the partner, not the platform.


# Compare ERP systems: put them side by side yourself
URL: https://www.fanatics.nl/blog/compare-erp-systems
Language: en

import Checklist from '~/components/blog/Checklist.astro'
import ResearchTeaser from '~/components/blog/ResearchTeaser.astro'
import ErpComparatorEmbed from '~/components/blog/ErpComparatorEmbed.astro'

Which ERP is best? The honest answer: it depends on your company. The right choice differs by company size, sector and process, and a vendor who tells you its package always wins is selling, not advising. So we built an interactive comparator that puts any two packages side by side, and this guide shows what actually matters.

<Checklist title="What actually matters" items={[
  'Which system handles your core process natively',
  'The real cost over five years',
  'One platform or a chain of connectors',
  'Who owns your customizations afterwards',
]} />

## Why "the best ERP" doesn't exist

The major players on the Dutch market each grew strong somewhere. AFAS leads in HR and the payroll run, Exact in Dutch accounting, Dynamics 365 when you already live deep in the Microsoft stack, SAP Business One and NetSuite for international scale, and Odoo as a broad platform running sales, inventory, manufacturing, webshop and finance on one model.

None of those six is best for everyone. A manufacturer weighs very different things than a services firm with a lot of staff. That is why "the best ERP" is the wrong question. The right one is: which system fits your heaviest process, at a cost you can still defend in five years?

## Compare it yourself, in a few clicks

Instead of a rigged table that conveniently always favours us, we built a comparator where you do it yourself. Pick two packages below and you see them head to head on the criteria that decide the choice - type, best fit, entry price, Dutch accounting, e-commerce, customization and open source.

<ErpComparatorEmbed lang="en" />

Put Odoo next to your current system, or two candidates you are weighing yourself. The [full pillar page](/best-erp-software-netherlands) also has the complete scored matrix and per-package analysis - including where Odoo loses.

<ResearchTeaser lang="en" />

## What actually matters

Four things weigh most, and none of them is on a feature list:

1. **Your heaviest process.** Does your business run on manufacturing, the webshop, the payroll run or projects? The system that handles that natively wins. The rest is detail.
2. **The real cost.** Licence per user is the start. Add implementation, connectors, customization and maintenance over five years - that is where the big differences sit, not in the monthly price.
3. **One platform or a chain of connectors.** The more separate packages you stitch together, the more maintenance and room for error. A broad platform that does most things natively saves hassle later.
4. **Ownership of your customizations.** On a closed system your customizations are tied to the vendor. On an open platform you own them yourself and can switch partners without rebuilding.

Want a deeper look at one matchup? We put Odoo next to the Dutch classics in [Odoo vs AFAS](/odoo-vs-afas) and [Odoo vs Exact](/odoo-vs-exact).

## From comparing to choosing

Not ready to compare because the basic question comes first? Then read [what an ERP system actually is](/blog/what-is-an-erp-system). And if you are comparing from Odoo outwards: the honest map is in [Odoo alternatives](/blog/odoo-alternatives). A comparator gets you to a shortlist, not to a signature. For that last step your own situation decides: your processes, your data, your connectors. In a [free scan](/scan) we work it out for your company - honestly, even if the answer is not Odoo. Better half an hour up front than the wrong system for the next ten years.


# From SAP to Odoo: what a migration actually looks like
URL: https://www.fanatics.nl/blog/sap-to-odoo-migration
Language: en

*An honest account from our own practice - not about which alternative to pick, but about how the move itself plays out.*

We help SMB and mid-market companies move off SAP. The question I want to answer here is not "which system is better" - we have set that out honestly elsewhere - but the question that comes next: **what does the switch actually look like?** What comes across, what does not, how long does it take, and what does it cost compared to staying?

If you first want to know which alternative fits you, or how Odoo stacks up against SAP head to head, start with our overview of the [best SAP alternatives](/sap-alternative) or the full [Odoo vs SAP comparison](/odoo-vs-sap). This article is about the migration itself.

## Why companies come to us

Most conversations share the same trigger. SAP is winding down mainstream support for ECC and pushing customers toward S/4HANA via RISE with SAP. That is not an update but a re-implementation: new data models, reconfigure, retrain, pay again. At that point a sensible owner asks: if I have to re-implement anyway, do I want another heavy SAP - or a platform that fits my scale?

The second trigger is wear. The system works, but every change costs a consultant, every report costs a day, and the package was built for multinationals with hundreds of users while you have fifty. The forced migration is the nudge, not the cause.

## What the move is and is not

The most important thing I set straight up front: a SAP-to-Odoo migration is **not a lift-and-shift.** You do not copy SAP configuration into Odoo. You redesign your processes in a lighter system and deliberately leave behind the complexity that crept into SAP over the years.

That feels like more work, but it is the relief. Most SAP frustration we encounter is not about what SAP can do, but about what it costs to make it do anything. By choosing what you actually need during the switch, the system - and running it - gets lighter immediately.

## The phases of a migration

Not a generic demo, but a fixed route. Here is how we approach it:

1. **Process analysis and fit-gap** - we walk your process from lead to invoice and decide what fits standard Odoo, what needs configuration, and what genuinely needs customisation or an integration. This is where most risks surface.
2. **Data migration plan** - which master data, open items and live orders come across, and which history you archive. Here it becomes clear early how clean your SAP data really is.
3. **Configuration** - we build the core processes in Odoo: sales, purchasing, stock, production, projects and finance on one platform.
4. **Parallel running and testing** - on real scenarios: quote, order, purchasing, production order, delivery, invoice, post-calculation. Not on paper, but with your own data.
5. **Go-live, phased** - core first, then the rest. We would rather not do a big bang when phasing is safer.
6. **Optimisation** - after the switch, sharpening up on what turns out to chafe in practice.

Realistic hours, cost and lead time per phase are in our [implementation benchmark](/odoo-implementation-benchmark).

## What migrates, what does not

A common misconception is that everything has to move. It does not, and usually it should not.

- **Across:** customers, suppliers, items, bills of materials, open receivables and payables, live sales and purchase orders, current stock levels.
- **Not, or only as an archive:** years of transaction history, closed financial years, dead items and customers. You keep those in a read-only export or archive. You lose nothing, but you also do not drag pollution into your new system.

The switch is an ideal moment to clean up your data. Almost every SAP export we open contains duplicate customers, dead items and fields nobody uses anymore.

## The sum: staying versus switching

The honest question is not only "what does switching cost", but "what does switching cost compared to the S/4HANA migration that is otherwise coming for you anyway". Below we put both side by side, as an indication, for an SMB or mid-market company of roughly 30 to 50 users, over five years.

| Cost item (5 years, indicative) | S/4HANA via RISE | Odoo switch |
| --- | --- | --- |
| Licences / subscription | high | low to medium |
| Implementation / reconfiguration | very high | medium |
| Hosting & infrastructure | included, but pricey | low |
| Maintenance, changes & customisation | high (consultant per change) | low to medium |
| Training & adoption | high | medium |
| **Total TCO over 5 years** | **reference (100%)** | **roughly 30 to 50%** |

In our practice the total five-year cost of an Odoo switch for an SMB comes out far lower than an S/4HANA project - often by a factor of 2 to 3. The biggest saving is not in the licence, but in implementation and in the fact that you can make changes yourself instead of hiring a consultant for every adjustment.

Note: these are ranges, not a quote. Actual cost depends on scope, modules, customisation, integrations and how clean your data is. For your situation we make a focused estimate rather than a table.

Want a first indication for your own organisation? The [SAP cost-leak scan](/sap-kostenlek) works out in 60 seconds what SAP costs you unnoticed - on licensing, maintenance and the friction between systems.

## What goes wrong - and how we prevent it

After dozens of projects you see the patterns. Three things go wrong most often:

- **Cleaning data too late.** Discover the data quality only during the migration and you lose time. We deliberately start early.
- **No internal process owner.** An ERP switch is not an IT project you outsource entirely. Without someone internal to make calls, every project stalls.
- **A big bang where phasing was possible.** Converting everything in one weekend feels decisive, but it stacks risk. Going live in phases is almost always safer.

None of these three is a surprise once you have done it often. So most of our work sits before go-live, not after.

## When you are better off staying on SAP

We sell Odoo, but we are honest about the line. If you are genuinely enterprise - dozens of legal entities, multinational consolidation, heavy industry and compliance requirements, with the budget and team to run SAP well - then S/4HANA offers depth a lighter platform does not have out of the box. Then switching is not relief but risk. We say so plainly.

For most of the SMB and mid-market companies we speak to, that is not the situation. There, the forced S/4HANA migration is exactly the moment to choose deliberately rather than be carried along.

## Frequently asked questions

### How long does a migration from SAP to Odoo take?

In our experience an SMB or mid-market switch runs from a few months to about a year, depending on scope, data quality and how much customisation you actually need. That is far shorter than a typical S/4HANA re-implementation, mainly because you go live in phases instead of one big bang.

### What migrates from SAP to Odoo, and what does not?

Master data, open items and live orders come across. Deep transaction history we usually keep in an archive or read-only export instead of moving everything - it saves time, money and risk, and you do not lose the information.

### Is a SAP-to-Odoo migration a lift-and-shift?

No. It is a redesign, not a copy. You rebuild processes in Odoo rather than replicating SAP configuration one to one. Precisely because you leave the SAP complexity behind, it gets lighter.

### What does switching cost compared to staying on SAP?

In our practice the total five-year cost of an Odoo switch for an SMB is far lower than an S/4HANA migration - often by a factor of 2 to 3, depending on scope. The TCO table above puts both side by side as an indication.

### What goes wrong most often in an ERP switch?

Dirty data cleaned up too late, no internal process owner, and a big-bang go-live where a phased approach was safer. All three are avoidable, and that is where most of our work sits up front.

### When are you better off staying on SAP?

When you are genuinely enterprise: dozens of legal entities, multinational consolidation and heavy compliance, with the budget and team to run SAP well. Then S/4HANA offers depth a lighter platform does not have out of the box.

## Thinking about a switch?

We will think along, with no strings attached, about whether and how a move from SAP to Odoo pays off in your situation - even if that means you are better off staying put. [Talk through your situation with us](/contact) and we will hold your process honestly against both sides.

---

**Read more:** [The best SAP alternatives, honestly scored](/sap-alternative) · [Odoo vs SAP: the full comparison](/odoo-vs-sap) · [Why switching to S/4HANA isn't always the right call](/blog/sap-s4hana-alternatives)


# Best ERP for metal companies: Odoo, Ridder iQ, MKG, ISAH and Business Central compared
URL: https://www.fanatics.nl/blog/best-erp-for-metal-companies
Language: en

import MetalErpScrolly from '~/components/blog/MetalErpScrolly.astro'

There is no single best ERP system for metal companies. **Ridder iQ, MKG, ISAH and Bemet** are strong choices for businesses that mainly want an industry-specific solution for production, quoting and shop-floor processes. **Odoo** is often more interesting for metal companies that want to combine production with CRM, sales, purchasing, stock, eCommerce, service, accounting, documents, approvals and reporting on one flexible platform. **Business Central** mainly suits larger organisations that lean heavily on the Microsoft ecosystem. The best choice depends on your complexity, your growth plans, your need for custom work, your integrations, and whether you mainly want a production system or a broad business platform.

That is the short answer. Below we make it concrete: a choice table per type of business, an honest comparison of the systems, when Odoo is and is not the smart pick, and how to decide without getting fixated on a demo.

<MetalErpScrolly lang="en" />

## Who is this comparison for?

For metalworkers, sheet-metal workers, machine builders, assembly businesses and technical wholesalers with light production - businesses with stock, purchasing, sales, production and service, currently working with Exact, MKG, Ridder, ISAH, Bemet, Excel or a pile of separate tools.

And straight away, honestly: if extremely deep nesting, direct machine control or CAM-driven production planning is your core process, a specialised MES or industry system may remain necessary. Odoo can do a lot, but you should not misuse it as a replacement for every specialist production system.

## The key conclusion, per type of business

| Situation | Likely best direction |
| --- | --- |
| You want an industry system purely for metal production | Ridder iQ, MKG, ISAH or Bemet |
| You want one flexible platform for sales, purchasing, stock, production, service and finance | Odoo |
| You are deep in Microsoft with international financial complexity | Business Central |
| You use many separate tools and Excel | Odoo or Business Central |
| You have many CAM/MES dependencies | Industry system + integration, or Odoo + MES |
| You want to start fast and expand later | Odoo |
| You want to depend as little as possible on a single vendor | Odoo |

## The systems briefly compared

Odoo does not automatically belong at number one. An honest overview helps more than a ranking:

| ERP system | Strong in | Less strong in | Best fit |
| --- | --- | --- | --- |
| **Odoo** | Broad platform, flexibility, integrations, CRM, stock, production, accounting, eCommerce | Not deeply metal-specific out of the box | Growing manufacturers that want one platform |
| **Ridder iQ** | Metal industry, quoting, production processes | Narrower as a general business platform | Metal companies that put industry functionality first |
| **MKG** | Dutch metal industry, quoting and production | Less flexible beyond industry logic | SMB metal companies |
| **ISAH** | Manufacturing, machine building, project production | Implementation complexity | Larger manufacturers |
| **Bemet / ECI** | Production ERP, planning, quoting | Thinner in CRM, eCommerce and service | Order-driven manufacturers |
| **Business Central** | Microsoft ecosystem, finance, international scale | Production often via add-ons | Microsoft-oriented organisations |
| **Exact** | Finance, accounting, Benelux | Limited production | Smaller or finance-first businesses |

Odoo is not a pure metalworking package, but a broad ERP platform that works well for metal companies that value flexibility, integrations and scalability over deeply built-in industry functionality.

## When is Odoo suitable for metalworking?

**Odoo is suitable when:**

- you want sales, purchasing, stock, production, service and finance in one system;
- you currently work with a lot of Excel, separate tools or double entry;
- your business is growing and processes need to professionalise;
- your production process can be reasonably standardised;
- you need integrations with accounting, a webshop, portals, scanners, BI or client systems;
- you do not want to be locked into a single industry-specific setup;
- you want to implement step by step.

**Odoo is less suitable when:**

- you expect full CAM control from the ERP;
- you want extremely complex nesting or machine planning straight out of the ERP;
- you have no internal process owner or point of contact;
- you think an ERP solves all production problems by itself;
- you need 80% customisation to fit your process.

For metal companies the choice is usually not "Odoo or an industry system", but: which processes belong in the ERP, and which belong in specialist software such as CAM, MES or shop-floor tooling?

## Odoo versus the industry systems

### Odoo versus Ridder iQ

Ridder iQ is stronger if you primarily want an industry-specific metal solution. Odoo is stronger if you want one broad business platform that combines production with CRM, sales, stock, purchasing, service, accounting, eCommerce and automation. Read the full [Odoo vs Ridder iQ comparison](/odoo-vs-ridder-iq) or the broader overview of [Ridder iQ alternatives](/ridder-iq-alternative).

### Odoo versus MKG

MKG suits businesses that want a familiar Dutch metal solution. Odoo suits businesses that also value flexibility, integrations and scalability beyond production. See the [Odoo vs MKG comparison](/odoo-vs-mkg) or the broader overview of [MKG alternatives](/mkg-alternative).

### Odoo versus ISAH

ISAH is strong in more complex manufacturing and project production. Odoo is often more attractive if you want to start modular and implement less heavily. Read the [Odoo vs ISAH comparison](/odoo-vs-isah).

### Odoo versus Bemet

Bemet is strong in production planning and quoting for order-driven manufacturers. Odoo wins once you want to connect production to the rest of the business. See the [Odoo vs Bemet comparison](/odoo-vs-bemet) or the broader overview of [Bemet alternatives](/bemet-alternative).

### Odoo versus Business Central

Business Central is logical for organisations deep in Microsoft. Odoo is often more attractive for businesses that want an integrated, modular platform with many standard apps in one environment. Read the [Odoo vs Business Central comparison](/odoo-vs-dynamics). If your need is mostly accounting, [Odoo vs Exact](/odoo-vs-exact) is also relevant.

## What must ERP for metal companies do at a minimum?

A good ERP for metalworking supports at least sales, purchasing, stock, bills of materials, routings, work orders, planning, quality control, traceability and invoicing.

**Must-have functionality:** CRM and quoting, sales and purchase orders, stock management, bills of materials, routings, work orders, planning, serial and lot numbers, quality controls, time tracking, post-calculation, invoicing, accounting, reporting, rights and approvals, document management and integrations.

**Specific to metal companies:** material reservation, remnant or sheet/tube management, operations such as cutting, bending, welding, coating and assembly, subcontracting, quality documentation, traceability, and integrations with CAM, MES, scanners or machines.

Odoo covers much of this out of the box or with configuration. Some parts need industry knowledge, [targeted customisation](/odoo-custom-development) or an integration - and that distinction is exactly what you make sharp up front.

## The biggest mistake in ERP selection at metal companies

The biggest mistake is not that businesses pick the wrong ERP. The biggest mistake is that they pick an ERP before properly analysing their processes.

ERP selection without implementation reality is theory. The question is not only which package looks good in a demo, but what you can actually implement successfully - and that depends on the fit-gap between your real business process and what the system supports out of the box.

## How we approach an ERP choice for metal companies

Not a generic demo, but a method:

1. **Process analysis** - what happens from lead to invoice?
2. **Fit-gap** - what fits standard Odoo, and what needs configuration, customisation or integration?
3. **Risk analysis** - where can the project go wrong?
4. **A demo on real scenarios** - create a quote, confirm an order, trigger purchasing, create a production order, reserve material, run a work order, book a delivery, invoice, review post-calculation.
5. **Phased implementation** - core processes first, then optimisation. Realistic hours, cost and lead time are in our [implementation benchmark](/odoo-implementation-benchmark).

More about Odoo for your sector is on [Odoo for manufacturing](/industries/manufacturing) and [Odoo ERP](/odoo-erp).

## Frequently asked questions

### What is the best ERP system for metalworking?

There is no single best ERP for every metal company. Ridder iQ, MKG, ISAH and Bemet are strong in industry-specific metal processes such as quoting, work preparation and the shop floor. Odoo is strong for businesses that want to combine production with CRM, stock, purchasing, sales, service, accounting and automation on one flexible platform.

### Is Odoo suitable for metal companies?

Yes, for many metal companies, especially when processes can be reasonably standardised and the business wants one broad platform. For highly specialised machine control, CAM integration or complex nesting you combine Odoo with specialist software.

### When do you pick Odoo over Ridder iQ?

When you want to manage not just production but also sales, CRM, purchasing, stock, accounting, service, eCommerce and integrations on one platform. Ridder iQ is more obvious when industry functionality for metal production is the deciding factor.

### When is an industry system better than Odoo?

When your production process is highly specific to metalworking and you mainly want deep functionality for quoting, the shop floor, CAM links or machine planning. Odoo is stronger when flexibility, broad business processes and integrations matter more.

### Can Odoo integrate with CAM or MES?

Yes, via APIs or custom integrations with CAM, MES, scanner and BI systems. The question is not only whether an integration is technically possible, but which system should lead for which process.

### What does an Odoo implementation cost for a metal company?

It depends on users, modules, integrations, customisation and data migration. A scoped start can be relatively small, a full project is larger. Realistic ranges are in our [implementation benchmark](/odoo-implementation-benchmark).

### Which is better: Odoo or Business Central?

Business Central is often logical for businesses deep in Microsoft with complex financial or international requirements. Odoo is often stronger for businesses that want a broad, modular and flexible platform with many standard apps in one environment.

## An honest Odoo check for your metal company

We sell Odoo, but we are professional enough to say when Odoo is not the best choice. Want to know whether it fits your production process - suitable, doubtful or better not? [Request an honest Odoo check](/contact). We put your processes against both Odoo and the industry systems, and we are clear about where standard is enough and where customisation or a specialist is needed.


# Exact Globe Next is end-of-life: what now?
URL: https://www.fanatics.nl/blog/exact-globe-end-of-life
Language: en

The last full service pack for **Exact Globe Next** shipped in **March 2026**; one extra pack follows in the summer for the Dutch salary update. After that, it is done: no updates, no bugfixes, no security patches. The software keeps running, but stands still - while everything around it (Windows, SQL Server, integrations, legislation) keeps moving.

That means one thing: **you are migrating either way.** The only question is where to.

## What exactly was announced

- **March 2026:** the last full service pack for Globe Next; one extra pack in summer 2026 for the Dutch salary update.
- **After that:** no new functionality, bugfixes or security updates. New legal requirements - such as extended Peppol e-invoicing - land only in the successor.
- **The successor:** Exact Globe+, on a modern 64-bit platform. Note: moving from Globe Next to Globe+ is a real migration, not an update button.

## What running without support actually means

A package without maintenance does not stop working - it stops moving along. Every new Windows or SQL update is untested territory from now on. Every discovered vulnerability stays open. Every integration that changes on the other side (bank, webshop, scanning) can break with nobody left to fix the Globe end. For an administration that also carries your inventory valuation and invoicing, that is not a comfortable place to sit for years.

## Your three routes

1. **Stay within Exact:** migrate to Globe+ (or Exact Online for lighter administrations). Familiar, same vendor - but a full migration project, and you keep the same package thinking: accounting at the centre, the rest connected around it.
2. **A comparable package elsewhere:** [AccountView](/odoo-vs-accountview) or [Visma Net](/odoo-vs-visma). A sideways step; sensible if you mainly want the EOL risk gone. Do check the destination's foundation: AccountView itself runs on a Visual FoxPro core Microsoft stopped supporting in 2015.
3. **Choose once, properly:** use the migration you have to do anyway to move to one platform. That is where Odoo comes in.

## Why Globe users in particular look at a platform

Globe Next has always been strong with **trade and manufacturing businesses** - companies where the administration is not standalone but tied to orders, inventory, purchasing and production. That is exactly where the package-plus-connectors model pinches hardest: the webshop reads a different stock figure than the sales desk, Excel decides purchasing, and the books only reconcile with the warehouse after manual work.

In Odoo those processes run on one data model: order, inventory, production, shipping, invoicing and accounting share the same truth, with webshop and CRM native when you need them. How that compares to Exact is in our [honest Odoo vs Exact comparison](/odoo-vs-exact).

## The migration, practically

We start every Globe migration with a **fit-gap**: what Globe (and the tools around it) does for you today, and what belongs where tomorrow. Then the data migration - master data, open items, history - with a dry run before go-live, phased so the operation keeps running. A focused trade implementation typically goes live in weeks to a few months.

For cost, count on roughly €1,000 to €3,000 per user as a one-off; the full breakdown is in [what does an Odoo implementation cost](/blog/what-does-an-odoo-implementation-cost).

## Start while it is still calm

The closer to the end of support, the fuller the migration calendars - at Exact partners and beyond. Start now and you choose in peace; wait and you migrate under pressure. Begin with a [free Odoo scan](/scan): we map what Globe does for you today and what one platform looks like for your operation. Or book a [Quickscan](/quickscan) directly.


# What does an Odoo implementation cost in 2026?
URL: https://www.fanatics.nl/blog/what-does-an-odoo-implementation-cost
Language: en

import DriverTable from '~/components/blog/DriverTable.astro'

An Odoo implementation costs roughly **€1,000 to €3,000 per user** as a one-off. A manufacturer with 15 users and full scope - sales, CRM, purchasing, shipping, inventory, manufacturing and internal processes - usually lands between **€25,000 and €30,000**. That is the direct answer. The more useful one explains where that number comes from, why we price per user, and why the per-user price falls as you grow.

<DriverTable title="What it costs, roughly" rows={[
  { label: 'Implementation', value: '€1,000 - €3,000 / user' },
  { label: 'Project (15 users, full scope)', value: '€25,000 - €30,000' },
  { label: 'Licence (Enterprise)', value: 'from ~€35 / user / mo' },
  { label: 'Custom module', value: '€4,000 - €15,000' },
]} />

Want the real spread? Our [Odoo implementation benchmark](/odoo-implementation-benchmark) lays out the figures from more than 80 projects: the median, the ranges and the scope tiers. Per user is a handy rule of thumb; the benchmark shows that scope and complexity weigh heavier than the number of users.

## Why we price per user

Most implementation cost scales with the number of people using the system: more users usually means more roles, more permissions, more screens to configure and more people to train. Per user is therefore a fairer starting point than a flat project figure that lands differently for everyone.

| Situation | One-off cost per user |
|---|---|
| Small, standard setup, close to the standard, few integrations | towards €1,000 |
| Average: several departments, a few integrations, some customisation | €1,500 - €2,500 |
| Broad: manufacturing, multiple entities or webshops, heavier integrations | towards €3,000, sometimes higher |

These are starting points, not quotes. The same organisation can fall at either end, depending on the factors below.

## What actually determines the price

Five things decide where you land in that range:

- **Your requirements.** The closer you stay to standard Odoo, the cheaper. The cost lives in the deviations from the standard, not in the standard itself.
- **The guidance you want.** Do you want us to do most of it, or will your team take on a large part? Doing more yourself lowers the bill directly.
- **The number of users.** More users means more configuration and training - but on average cheaper per user (see below).
- **Customisation and integrations.** Configuring the standard is predictable work. Integrations with external systems and custom modules sit on top of that.
- **The availability of internal people.** An engaged internal lead who makes decisions and picks up testing speeds the project up and pushes the cost down. No internal capacity means we absorb that, and that costs.

## Why the per-user price falls as you grow

Configuring a process costs about the same whether you do it for 5 or 25 people. The purchasing flow, the inventory logic, the invoicing: you set that up once. Spread that one-off cost across more users and the per-user figure drops. That is why a small company sits nearer the top per user and a larger one nearer the bottom.

The exception is **added complexity that does not scale with users**. Multiple legal entities, multiple webshops, international VAT, heavy integrations or a messy data migration: those costs are largely independent of the user count and can push the per-user average back up.

## Example: a manufacturer with 15 users

Take a manufacturer with 15 users putting the whole operation on Odoo: sales and CRM, purchasing, shipping, inventory, manufacturing and the internal processes around them. One platform, one source of truth, from quote to production to invoice.

A full implementation like that usually lands between **€25,000 and €30,000** as a one-off. That works out at roughly €1,700 to €2,000 per user - the middle band - because the scope is broad (manufacturing adds weight) but there is no exotic complexity like multiple entities or webshops. Add that, and it rises.

## Implementation, licence and customisation: three budgets

It pays to separate them so nothing surprises you:

- **Implementation** is the one-off cost to configure standard Odoo for your business - the figures above.
- **Licence** is a recurring cost: Odoo Enterprise from around €35 per user per month. We always deliver on Enterprise, never the bare Community edition.
- **Customisation** is a separate budget for the 20% the standard does not cover, usually €4,000 to €15,000 per module. How that works is in [what does Odoo customisation cost](/blog/what-does-odoo-customisation-cost).

The pragmatic route: go live on the standard configuration on Enterprise first, then add customisation only where the standard genuinely falls short.

## How to keep the cost down

- **Start standard.** Run standard Odoo first; some of your "must-have" customisation turns out to be already covered, or no longer needed once the process is clean.
- **Free up internal people.** An engaged internal lead on your side is the cheapest accelerator there is.
- **Phase it.** Build the core first, use it, then decide what is genuinely worth adding.
- **Fix the process first.** Automating a messy process only makes the mess faster.

## Get a real number for your situation

Ranges only get you so far. Our [implementation calculator](/pricing/calculator) walks through the processes you want to cover and gives a cost breakdown and a go-live timeline. To weigh it against staying put, the [ROI calculator](/pricing/roi) compares five-year Odoo costs against AFAS, Exact and SAP Business One. Or start with a [free Odoo scan](/scan) and we will map it out together. If the timeline matters as much as the cost, read [how long an Odoo implementation takes](/blog/how-long-does-an-odoo-implementation-take) or run your go-live date through the [go-live planner](/odoo-go-live-planner).

---

**Read more:** [Odoo implementation: are you ready?](/odoo-implementation) · [How long does an Odoo implementation take?](/blog/how-long-does-an-odoo-implementation-take) · [The implementation checklist](/blog/odoo-implementation-checklist)


# In three months, AI changed our company
URL: https://www.fanatics.nl/blog/how-ai-is-changing-our-company
Language: en

Last night, at my entrepreneurs' club. Entrepreneurs Organization. Coffee, a quick catch-up, and within ten minutes the talk was about AI. As it almost always is these days.

Next to me a manufacturer. "Tim," he said, "my nineteen-year-old intern built something in four days that we got a thirty-grand quote for last year." He laughed a little uneasily.

Further along, a woman who supplies services to government. She was the one grinning. With AI she suddenly saw openings: information that governments do hold but never make accessible, she now pulls out automatically.

Someone else was afraid instead. That he can no longer keep pace with his own customers.

And there is always one who says it will not move that fast. That a human will always be needed to keep checking the AI. One who does not trust it.

But the rest feel exactly the same. A wave is coming. And just as many opportunities.

At our company that wave is no longer a forecast. It is here. And it went fast: in three months.

## What shifted

We had three developers with their hands full. Today it looks different. A lot of development is moving to our consultants. Sounds odd. It is not.

Because they sit at the table with the client. They understand the problem best. And with AI they now turn that problem into software themselves. The detour via a separate developer gets shorter. Sometimes it is gone.

Bugfixing shifts too. To the first line of our support. That works, because our first line is also our second and sometimes third line. We do not work with juniors. Whoever picks up the phone here knows what they are talking about.

Three months. That is all it took.

## How we do it

We let Claude write code and review itself. On security too. Then a developer looks it over. And honestly? So far little bad comes out.

The craft shifts. Less typing yourself. More thinking clearly about what it has to do. And then checking it is right. That is not a lesser job. It is a different one.

The best part is the people. Our developers want to move with it. Not out of fear, but because they can see the fun in it. And our consultants are unanimously enthusiastic - they are all doing AI engineering. That is not a given. I am proud of it.

## Do we pass this on to the client?

Then the real question lands on the table. Do we keep the gains for ourselves? Or pass them on?

For me it is not a long discussion. It cannot be otherwise. If we do not, someone else soon will. Cheaper, faster, just as good. And then you end up at the back. Not because your product is worse. But because you held on to your old business model too long.

Not passing it on feels safe. It is the opposite.

## Do I have no worries, then?

I do. I would love to see good European alternatives emerge. For Claude Code. For Office. For our infrastructure. I already see promising initiatives, and that gives me hope.

Until they are here, we keep it tidy: GDPR-compliant Enterprise contracts at Claude and Amazon Bedrock. Well arranged. But I keep watching, because dependence is a risk too.

What is not an option is standing still. The wave is coming either way. You let it work for you, or you wait until it rolls over you.

We have chosen.

Want to know what that shift means for your business? Read [why custom is affordable for mid-market now](/blog/custom-software-affordable-mid-market), or how it plays out on the floor in [AI in manufacturing](/blog/ai-in-manufacturing).


# AI in manufacturing: from hours of work to minutes
URL: https://www.fanatics.nl/blog/ai-in-manufacturing
Language: en

import Checklist from '~/components/blog/Checklist.astro'

A workday at [Agrowteam](https://www.agrowteam.nl), a Dutch builder of polytunnels and greenhouses. New greenhouse, a bill of materials from Autodesk Inventor with thousands of components, and someone spending hours figuring out what gets bought, what gets produced, and how it ends up in an Odoo BOM. Until recently, that was just the job.

Now AI does it in minutes. Same BOM, same outcome, a day less work per greenhouse. That is what AI in manufacturing can do, without needing to be revolutionary. One step that took hours, now goes in minutes.

This piece is about where else AI works in a manufacturing business, how we do that, and when to wait a bit.

<Checklist title="What AI does in a manufacturing business" items={[
  'Turn a CAD bill of materials into an Odoo BOM',
  'Flag the machine likely to fail',
  'Read supplier confirmations and delivery notes',
  'Give the planner suggestions',
]} />

## What AI does on the floor and in your costing

| What AI does | How it works | What you get |
|---|---|---|
| **BOM skill** | Reads a bill of materials from Inventor or another CAD package and turns it into an Odoo BOM, with the right make-or-buy choice per part. | At Agrowteam: from hours of work per greenhouse to minutes. |
| **Predictive maintenance** | Watches the maintenance log and flags the machine likely to fail. | Less unplanned downtime. |
| **Document intake** | Reads incoming supplier confirmations, delivery notes and invoices and sets up the booking. | Less re-typing, fewer errors. |
| **Help the planner** | Suggests moves when demand or a delivery date shifts. | Faster response, better utilisation. |

For none of the four do you have to produce new data. BOMs, work orders, stock moves and maintenance already live in Odoo.

## How we approach this: one step at a time

At Agrowteam it was not an "AI strategy". It was a concrete problem that kept coming back: a BOM from Inventor with thousands of components, turned over by hand. We built an AI skill that reads the BOM and prepares the Odoo BOM. The foreman reviews, corrects where needed, and pushes it into production.

What you see there is what we do more often: one job that comes back weekly or daily, automated cleverly enough that the person stays in charge. Not replacement, but relief.

In [Updoo Shopfloor](/updoo/shopfloor) we showed this another way. In a 40-person manufacturing team paper work orders disappeared completely, and on-time completion went up 11%. AI sits naturally on top: suggest the next step, catch an anomaly. The data is already flowing through it.

At a large Dutch national printer the planning runs at a different scale entirely. More than sixty thousand orders a year, split across fifty workstations. Until recently that was largely manual, in Excel - with all the puzzle moments and errors that come with it. We are putting AI in there for an optimal daily plan on the orders already in Odoo, and Updoo makes sure that every employee at their workstation sees on a simple screen what they need to work on. AI plans, Updoo presents, people work.

Another example we are currently working on: a powder coater with three production lines who optimises his orders by hand every day. Colours need to be grouped and run in a fixed sequence, light to dark - otherwise the cleaning between batches eats more time than the coating itself. Going through orders one by one, day in day out, and a rush order halfway through throws the whole plan. AI can produce the optimal schedule for that day in one pass, reading the orders already in Odoo. Something slips in? AI takes the planner's manual adjustment as a hint and runs a second pass, instead of someone losing another hour to it.

Even for service after the factory gate, the same idea works. In RogerDone we built AI scheduling for technicians from tasks generated in Odoo. What you sold, you know. Who can do what and where they are now, you know. AI puts a planning on top of that.

## Manufacturing checklist: when does AI pay off?

| Start with AI when... | Wait a bit when... |
|---|---|
| ...the process runs steadily and the data in Odoo is clean. | ...your key data still sits loose in Excel or on paper. |
| ...the task is narrow and high-frequency (one step, one type of document). | ...it only happens once a quarter. |
| ...you can measure the result in time, stock or errors. | ...you cannot say what a good result is. |
| ...you understand the job well yourself first. | ...you cannot explain it well yet. |

AI on a messy process mainly speeds up the mistakes. Get the basics right first.

## Why manufacturing custom work fits the budget now

The BOM skill for Agrowteam would have cost tens of thousands ten years ago, if anyone had built it at all. Too narrow, too specific, too little reuse. Today a prototype is a few days of work.

The work you pay for shifts. Less typing code, more thinking through what the thing has to do, and then testing it carefully. People call it vibe coding: AI does the typing, we do the craft. So small, focused solutions suddenly fit a mid-market budget. Not "a big AI platform", but "that one step that always trips us up".

For the wider story behind this: [custom software is affordable for mid-market now](/blog/custom-software-affordable-mid-market).

## Get your production data straight first, then AI

Walk your own factory floor for a day. Write down where the same look-up happens twice a week. That is your first AI job. Nothing more.

A few places to read on:
- [Odoo for manufacturers](/industries/manufacturing) - how Odoo lays the base that AI stands on.
- [Can Odoo really run your production floor?](/blog/can-odoo-run-your-production-floor) - where Odoo stops and Updoo Shopfloor begins.
- [Custom software is affordable for mid-market now](/blog/custom-software-affordable-mid-market) - the full story behind the why.
- Run a wholesale operation alongside? Read [AI in wholesale](/blog/ai-in-wholesale) too - many patterns overlap.


# Custom software just got affordable for mid-sized companies
URL: https://www.fanatics.nl/blog/custom-software-affordable-mid-market
Language: en

For years, mid-sized companies kept two lists. One was everything their software should do. The other was what they could actually afford to build. The gap between them is where good ideas went to die. AI just closed most of it.

A client recently asked us for something small but awkward: customer-specific price lists they could download as Excel or PDF, and a way to turn any price list straight into a filled cart. The old way would have been a few days of work and two developers with different specialisms. We built it in four hours. Faster and better. This client never had the budget for the old version, so in the old world it simply wouldn't have been built.

That's the real shift. Not that custom software got a little cheaper, but that an entire category of "nice, but too expensive" is now firmly in the "worth building" pile.

A bigger example. We recently built a product-configuration platform for [Odoo](/odoo-erp) eCommerce: the kind of tool that lets a customer click together a made-to-order product and see the right price on the spot. Half a year earlier, another company had bought a comparable system from a third party: around €2,000 a month, plus a setup bill in the tens of thousands. We deliver the same thing for less than a tenth of that price. It runs at cpqbuilder.com.

Same pattern, bigger number. Software that used to be the preserve of companies with deep pockets is now within reach of a forty-person business.

## The same thing happened with the cloud

We've been here before.

One morning in October 2007, the neighbours above our Amsterdam office all decided to shower at once during a renovation. The ceiling came down. Water everywhere. While we scrambled for an expensive backup location, I made a decision that reshaped my career: I left traditional IT behind and went all in on something most of my peers still distrusted, the cloud.

A few years later I wrote a book about it, *Cloudsource je ICT!*. The message was simple. Stop owning servers, rent computing as a service, spend the savings on your actual business. The technology was ready. The objections were not.

And they were loud. Security, mostly. At the time, 47% of IT managers saw the cloud as a security risk, and fewer than a third thought the benefits outweighed the dangers. A lot of people just couldn't get comfortable with the idea of their data living "somewhere else." I used to point out that a server in your own basement gives you the feeling of safety, not actual safety - the same feeling people had about internet banking right before they all started doing it.

The part worth remembering: most of that fear didn't come from the businesses themselves. It came from the IT people whose income depended on the old model. The more servers a company owned, the more work there was for them.

## The objections to AI sound exactly like the objections to cloud

I'm hearing the same objections again now, in 2026:

- "The cloud isn't secure" has become "AI-written code isn't safe."
- "I don't want my data where I can't see it" has become "I don't understand the code, so who's in control?"
- And the objection no one says out loud: the people keenest to tell you AI-built software is dangerous are often the ones who bill by the hour to write code by hand.

The worries aren't imaginary. But we've run this experiment before, and we know how it ends: the technology wins, most of the early fear turns out to be fear of the unknown, and the few real risks get handled by people who take them seriously.

## When custom software isn't the right answer

Nobody who sells you something will say this, so let me: AI-built custom software isn't always the answer.

If standard Odoo already does the job, don't customise it. Every line you add is a line someone has to maintain. If your process is a mess, software won't fix it - fix the process first. And when a requirement is genuinely core to your business, that's where you want experienced people reviewing every decision, not just a quick AI prompt.

The shift isn't "build everything now." It's that the bar for "worth building" dropped. A lot of things that sat just below it now sit comfortably above.

## Who makes sure it works, and stays secure?

Fair question. If AI writes the code, who makes sure it actually works, and who keeps your data secure? That deserves a real answer, not a reassuring wave of the hand. It's also the question I get asked most. The short version: AI is the engine, but we're still the ones who build it, test it, and stand behind it. More on exactly how we keep AI-built code clean and secure soon.

If you run a mid-sized company and you have a shelved wishlist - the integration you gave up on, the portal you couldn't justify, the report that still lives in someone's spreadsheet - it's worth taking that list back out. The maths has changed. A [free Odoo scan](/scan) is a good place to find out what is suddenly within reach.


# Odoo for NGOs: why grant management is the key
URL: https://www.fanatics.nl/blog/odoo-for-ngos-grant-management
Language: en

NGOs, foundations and charities work with an unusual mix of idealism and control. On one side it's all about impact: projects, people, partners, donors, change in the world. On the other, every euro has to be accounted for - not just internally, but to grant providers, funds, auditors, regulators, and sometimes several international donors at once.

And that's exactly where it tends to break.

## The problem: disconnected tools that don't talk to each other

In practice, grant management at many organisations still leans on a pile of separate tools. A CRM for donors. Excel for budgets. SharePoint or Google Drive for documents. An accounting package for the books. Email for the agreements. And a few spreadsheets only that one colleague understands - the one who built them.

It works. Until it doesn't.

The moment you grow, manage several grants at once, or have to report differently per donor, the administration turns fragile. Not because people do their jobs badly, but because the information is scattered. The project manager looks at activities. Finance looks at cost centres. The fundraiser looks at donor commitments. Management wants an overview. And the donor wants to know one thing: what happened to our money?

[Odoo](/odoo-erp) would be a logical answer here. It bundles CRM, projects, accounting, documents, planning, reporting, purchasing, HR and communication into one platform. Not an eleventh standalone app, but a single place where the organisation comes together.

And yet we still see Odoo surprisingly rarely at NGOs and registered charities. Not because it's unsuitable - quite the opposite. It's because the default Odoo setup doesn't yet think the way an NGO thinks.

## An NGO doesn't think like a sales organisation

A commercial organisation thinks in customers, sales orders, margins and invoices.

An NGO thinks in programmes, grants, donors, budget lines, activities, deliverables, countries, partners, reporting periods and impact.

That's a fundamentally different model. So the question isn't "can Odoo do this?". The better question is: **how do you set Odoo up so an NGO recognises itself in it?**

That answer rarely lies in standard out of the box, and almost always in [a deliberate extension of the standard platform](/odoo-custom-development) - not to rebuild Odoo, but to let it speak the language of the non-profit.

## What Odoo needs: a grant management layer

For organisations that have to manage and account for grants, this means a clear grant management layer on top of Odoo. Think:

- a grant as a central record;
- linked to donor, programme, project and budget;
- clear budget lines and spend categories;
- scheduled reporting moments;
- supporting documents per activity or expense;
- progress against deliverables;
- financial actuals versus budget;
- management reports per donor, country, programme or project.

Then Odoo isn't a generic ERP that a foundation happens to use too. It becomes a workable platform for professional NGOs.

## From fragmented administration to a single record

The real benefit is in the connections. Grant management no longer stands apart from the rest of the organisation. A project expense attaches directly to finance. An activity attaches to the project. A donor commitment lives in CRM. A reporting deadline becomes a task. Documents sit with the right record. And management sees not only *what* was spent, but why, on what, and to what result.

That's what most NGOs are looking for: more grip, without more bureaucracy. Because no foundation wants software for the sake of software. An NGO wants to spend less time searching, checking, copying and reporting - so there's more time for what actually matters: making impact.

## Proof: togrant.com

This isn't theory. We built this model for an international NGO managing institutional grants from the EU, USAID and FCDO, across more than fifteen countries. The result is <a href="/updoo/togrant">togrant.com</a>: a platform that runs the full grant lifecycle - from application through award, country-level budget allocation and Odoo sync to the final report to the donor.

The best part: togrant.com talks to Odoo through the standard API, without touching a single line of standard Odoo. The accounting stays on its regular upgrade path; togrant owns the grant domain. Exactly the separation a growing NGO needs.

For more examples of how organisations translated Odoo to their own way of working, see our [client cases](/cases) and the [Odoo for culture & non-profit](/industries/culture) sector page.

## Start small, with the right model

My advice to any NGO weighing this up: don't fall for the "Odoo can do everything" pitch. Everyone sees through it. The honest message is stronger - **Odoo is an excellent foundation, but an NGO needs its own information model.** Get that model right and you translate it into Odoo. Skip it and you ship a generic ERP the organisation never recognises itself in.

You don't have to do it all at once. Start with the grant, the budget and the reporting as the core, and build out from there - phased, following our [TARGET method](/target). For many NGOs that's the difference between administration that runs behind the facts and an organisation that knows, at any moment: what resources do we have, where are they deployed, what's left to report, and what impact are we delivering?

## Frequently asked questions

**Is Odoo a good fit for NGOs and foundations?**
Yes. Odoo combines CRM, projects, accounting, documents and reporting in one platform - exactly the domains an NGO works in. The out-of-the-box setup only thinks in customers and sales orders. A grant management layer on top makes it a workable platform for professional non-profits.

**What is grant management in Odoo?**
A grant management layer turns a grant into a central record: linked to donor, programme, project and budget, with budget lines, reporting deadlines, supporting documents and progress against deliverables. Accountability sits attached to finance, projects and CRM instead of in loose spreadsheets.

**Can Odoo report per donor separately?**
Yes. Through analytic accounts you tie every expense to the right funding source and filter reports by donor, country, programme or project. <a href="/updoo/togrant">togrant.com</a> extends this with donor-structured budgets and ready-made exports such as the EU PRAG report.

**What does Odoo cost for a non-profit?**
Odoo Enterprise starts around €20 per user per month. Most non-profits we work with run 5–15 users - €100 to €300 per month. Implementation is a one-off investment; run your numbers with our [ROI calculator](/pricing/roi).

---

Wondering whether this fits your organisation? [Start a free Quickscan](/scan) - in 30 minutes we map where your grant management gets stuck today and what Odoo could change about it. No sales pitch.

*Background: Odoo describes its own approach for non-profits on the <a href="https://www.odoo.com/industries/nonprofit-organization" target="_blank" rel="noopener noreferrer">Odoo nonprofit page</a>. If you hold ANBI status or a CBF mark, also check the accountability requirements from <a href="https://www.cbf.nl" target="_blank" rel="noopener noreferrer">the CBF (Dutch charity authority)</a>.*


# AI for cultural organisations: less reporting, more doing
URL: https://www.fanatics.nl/blog/ai-for-cultural-organisations
Language: en

A grant application of forty pages. Half of what is in it - the organisational setup, the proof, the existing results - you also wrote last year, and the year before that. What is different is the angle for this fund and this round. For [NIMD](https://www.nimd.org) (Netherlands Institute for Multiparty Democracy) we are setting up a system where AI surfaces that older material and prepares the first version. Someone sharpens it, with knowledge of what this fund is sensitive to. Not from scratch.

And when the application is awarded, we will pull the same pattern through to the accountability reporting. A report in the format the funder wants, with figures from Odoo, in a form they accept immediately. That is a lot of work that today still happens by hand - and that is much better spent on your actual mission.

## What AI delivers for cultural organisations

| What AI does | How it works | What you get |
|---|---|---|
| **Prepare applications** | Pulls relevant parts from earlier applications and drafts a first version. | No more blank document, less repetition. |
| **Compile reports** | Builds accountability reports in the funder's format. | Less time on reporting, more on your mission. |
| **Sort incoming mail** | Reads incoming mail and files applications, questions and donations in the right place. | Faster handling, less searching. |
| **Flag lapses early** | Reads engagement patterns and signals lapse risk. | Reach out in time, fewer cancellations. |

For none of the four do you have to track anything new, provided your Odoo is set up to think in donors, programmes and budgets.

## Togrant: the base AI stands on

[Togrant.com](/updoo/togrant) is the piece we built to teach Odoo to think in grants. An application becomes a central record, linked to donor, programme, project and budget. Donor-structured budgets. Ready-made exports, including the EU PRAG report.

That is not AI. That is structure. But it is the structure AI needs to do anything useful. You cannot build a report out of loose spreadsheets and mail threads. You can build one from a well-organised dossier.

[Hart Haarlem](/cases), one of North Holland's largest cultural venues, runs events, ticketing, room rental and a webshop on one Odoo. One source of truth for who your audience is, what they did, what they gave. That is exactly the kind of foundation an AI layer can sit on sensibly - personal recommendations, churn warnings, smarter email. Not because you have to, but because the data allows it.

## Patterns we see elsewhere too

For a larger membership organisation we are in conversation with, we are working on a set of AI patterns that are equally useful for many cultural organisations and non-profits:

- **A chatbot on the member portal** answering questions about membership, cancellation and your policy area from your own knowledge. Not a generic model that hallucinates, but one that knows your content.
- **Suggested answers in the helpdesk** for staff, from earlier tickets and the publication archive. Faster response, consistent tone, knowledge retained.
- **Personal content feed**: relevant publications and events based on region, membership and earlier behaviour. Higher engagement, fewer lapses.
- **Lapse early warning**: model engagement signals (portal visits, newsletter clicks, event signups) to get members at lapse risk in front of the membership team in time.

None of these has to be a big project. Each is a small, focused module running on your existing data.

## Culture checklist: start now or wait?

| Start with AI when... | Wait a bit when... |
|---|---|
| ...your Odoo already thinks in donors, programmes and budgets. | ...everything still sits scattered across separate tools and folders. |
| ...something happens often (reporting, applications, mail). | ...it only happens now and then. |
| ...you can measure the result in time, donors or turnout. | ...you cannot say what a good result is. |
| ...members, donations and accounting sit in one system. | ...your core numbers still sit loose in spreadsheets. |

AI on a messy dossier mostly speeds up the mess.

## Why this is achievable on tight budgets too

A tool that prepares grant applications, or a reporting generator built for a specific funder - these used to be expensive projects for large organisations. Today we build them in weeks, because AI speeds up the base work and we set things up modularly. One job at a time, measure first, then more.

For the full story behind this: [custom software is affordable for mid-market now](/blog/custom-software-affordable-mid-market).

## First, your member and donor data in one place

Pick one report that currently takes the most time. That is almost always your first AI job - because the data is right (otherwise you would not have got the grant) and the effect is immediate to measure. After that you can look at preparing applications or sorting the inbox.

Read on:
- [Odoo for culture and non-profits](/industries/culture) - the base everything else sits on.
- [Why grant management is the key](/blog/odoo-for-ngos-grant-management) - why structure beats tool.
- [AI in professional services](/blog/ai-in-professional-services) - many patterns around projects and reporting overlap.
- [Custom software is affordable for mid-market now](/blog/custom-software-affordable-mid-market) - the pillar.


# When your checkout needs more than standard Odoo POS
URL: https://www.fanatics.nl/blog/odoo-pos-beyond-standard
Language: en

Standard Odoo POS is good enough for most shops. It scans barcodes, prints receipts, takes payments, and updates stock with every transaction because it sits on the same inventory as the rest of Odoo. You only need more when your trade has rules a generic till doesn't handle, and that's where targeted custom code comes in. This guide helps you tell which you are.

## What standard Odoo POS already does

The basics are all there, and for many retailers they're the whole win:

- Barcode scanning, receipt printing and payment handling.
- A direct link to inventory, so stock is accurate after every sale.
- One stock number across the counter and the webshop, because POS, shop and accounting share a database.
- Offline resilience: the till keeps working through a short Wi-Fi outage and syncs back when the connection returns.

Because everything sits in one system, a sale at the counter and an order online draw down the same stock. For a lot of shops, that integrated standard setup is the win, no custom code required.

## When you need more: a wine shop's checkout

[Wijnwinkel Barneveld](/cases/wijnwinkel-barneveld-en) is a good example of standard-plus-custom. This specialist wine retailer moved off Lightspeed and Exact onto one Odoo platform for shop, webshop and administration, then added exactly what a wine business needs:

- An 18+ age check built into the webshop checkout, a legal requirement for selling alcohol online.
- Packaging logic that offers to build a case at six bottles and suggests a packaging unit at twelve or more.
- Bottle deposits (emballage) registered at every transaction, keeping the stock of empty crates and the financial settlement correct.
- An Exact Online integration that syncs purchase and sales invoices, debtors, creditors and cost centres, so there's no double bookkeeping entry.
- Receipt and label printing through Printnode, straight from Odoo with no download steps.
- A loyalty programme, rolling out, that tracks reward points customers can redeem both in store and online.

Each of those is a focused addition on top of standard Odoo, not a rebuild. The payoff is one platform for shop, webshop and books instead of three systems that don't talk to each other.

## The omnichannel point

The reason a retailer chooses Odoo over a standalone till is usually stock. When the counter, the webshop and purchasing all read and write the same inventory, you stop reconciling three numbers that are never quite the same. A bottle sold in the shop isn't available online a second later by luck, but by design. That single source of truth is hard to bolt onto a dedicated POS after the fact.

## Moving off Lightspeed

Switching tills sounds daunting, but the migration is well-trodden: products, customers and stock come across, the new POS runs alongside the old one briefly, and the back office moves to Odoo once the shop floor is comfortable. Wijnwinkel Barneveld came from exactly that combination, Lightspeed plus Exact, onto one system.

## When a dedicated POS is the simpler choice

If you only need a till, a dedicated POS is simpler, and that's a fair choice, be honest with yourself about it. Odoo wins when the checkout is one face of a larger operation: stock across channels, a webshop, accounting, loyalty that follows the customer everywhere. The more of your business lives behind the till, the more the single platform is worth.

Weighing it against your current setup? Read [Odoo vs Lightspeed](/odoo-vs-lightspeed), or why this kind of targeted build became affordable in [our pillar piece](/blog/custom-software-affordable-mid-market). Or start a [free Odoo scan](/scan).


# AI in hospitality: time back for your guests
URL: https://www.fanatics.nl/blog/ai-in-hospitality
Language: en

You have an email in your inbox. Is it a reservation for Saturday? A supplier receipt? A guest asking for a doggy bag after last night's visit? Or a review that wants an answer? Until recently you sort that yourself, between cleaning the place up. AI does that for you now - and you have ten minutes back per day for the floor.

That is where AI in hospitality stands today. Not big, not revolutionary. Just concrete: the dull sorting, predicting and booking work goes a layer deeper, you have time back for the room.

## What AI already delivers in hospitality

| What AI does | How it works | What you get |
|---|---|---|
| **Sort the inbox** | Reads incoming mail and files reservations, questions, receipts and reviews in the right bucket. | Ten minutes a day back for the floor. |
| **Forecast how busy** | Predicts the day from your own sales, weather and date. | Better buying and rota, less waste. |
| **Read receipts** | Reads supplier receipts and invoices and sets up the booking. | Less re-typing, fewer errors. |
| **Watch margin** | Spots dishes leaking margin or sitting still. | Sharper menu, better gross profit. |

For none of the four do you have to track anything new. It is already in Odoo - provided till and stock match up there.

## The quiet standard, not always custom

For [Ons Broodje Bonaire](/cases), a Caribbean sandwich shop on a Dutch ERP base, we put Odoo POS, QR self-order, online ordering, time tracking and eCommerce into one live system. Pragmatically set up in about twenty hours. The base needed no AI to run well. One piece we did build with AI: because there is no good bank connection for the ABC islands, an AI app we wrote imports the bank statements into Odoo automatically. Exactly the kind of narrow, annoying problem where AI pays for itself fast.

Many hospitality questions we solve by setting up the standard well and honestly saying when custom is not needed. AI joins where it pays off. Often first in purchasing and the inbox.

## Patterns we see elsewhere too

Sorting incoming mail is not a hospitality invention. We see the same pattern at member organisations: AI recognises whether an incoming mail is a new signup, a membership question, or something for accounting. For a hospitality business it works identically: AI splits reservations from supplier contact from guest questions, and gets the right people or systems moving.

Another pattern we have running elsewhere: a chatbot that answers questions from your own knowledge. For a member organisation that is about membership and cancellation. For a hospitality business it can be about opening hours, dietary requirements or the wine list - with answers drawn from your own menu and house rules, not from a generic model.

## Hospitality checklist: start now or wait?

| Start with AI when... | Wait a bit when... |
|---|---|
| ...till, stock and accounting sit in one Odoo. | ...your receipts still disappear in a drawer or in a separate accounting app. |
| ...something happens often (inbox, buying, booking). | ...it only happens now and then. |
| ...you can measure the result in waste, margin or time. | ...you cannot say what a good result is. |
| ...your staff hours also sit in the same system. | ...your rota and till sit apart. |

AI on a messy process mostly speeds up the mistakes. That does not need to be more than setting things up properly - not months of work.

## Why this is achievable even for a single venue

A demand forecast of your own, a chatbot on your menu, a targeted inbox sort - these used to be projects for chains with budget. Today we build them for a single venue too, because AI speeds up the base code work and we set things up modularly. One job at a time, measure first, then more.

For the full story behind this: [custom software is affordable for mid-market now](/blog/custom-software-affordable-mid-market).

## First, your orders and stock in one place

Is your inbox full of mixed-up mail? Start there. Have no idea how busy Saturday will be? Start there. Both jobs are small, quick to prove, easy to measure.

Read on:
- [Odoo for hospitality](/industries/hospitality) - how Odoo brings till, stock and accounting together.
- [AI in retail](/blog/ai-in-retail) - many patterns overlap.
- [Custom software is affordable for mid-market now](/blog/custom-software-affordable-mid-market) - the pillar.


# A self-service portal for your B2B customers, on Odoo?
URL: https://www.fanatics.nl/blog/odoo-b2b-customer-portal
Language: en

Yes, you can give your B2B customers a self-service portal on Odoo, and most of what you need is already in the standard product. The interesting question is where the built-in portal stops and a little custom work starts to pay off. This guide maps both.

## What you get out of the box

Odoo's B2B portal is part of the standard product, not a premium add-on. Each business customer gets their own login with:

- Per-customer pricing, the prices you negotiated, not list prices.
- Agreed payment terms and credit conditions.
- Ordering against existing quotes, so a salesperson's offer becomes a self-service order.
- Products hidden from customers who aren't meant to see them.
- Their own order history, invoices and quotes, ready to download.

For comparison, that level of B2B on Shopify lives in the Plus tier at around $2,300 a month. In Odoo it's part of the standard product.

## Why it works so cleanly

The portal reads directly from Odoo. A customer sees their own negotiated prices, their open and past orders, their invoices and quotes, all live, with no second system to keep in sync. It's their own slice of your data, nothing copied or exported, and nothing that drifts out of date the moment something changes in the back office.

## What your customers actually ask for

The portal earns its place by removing the calls and emails that land on your sales desk every day:

- "Can you resend that invoice?" - they download it themselves.
- "What's the status of my order?" - they can see it.
- "Can I reorder what I had last time?" - reorder straight from history.
- "What's my price on this?" - their price, shown to them.

Each of those is standard, and each one is time your team gets back.

## Where a little custom work pays off

The standard portal covers ordering, pricing and documents. Custom work extends it to the specific things your customers ask for.

A good example from our own work: a client wanted customer-specific price lists their buyers could download as Excel or PDF, and a way to turn any price list straight into a filled cart. The old way would have been a few days and two developers, more than this client could justify. We built it in four hours, so a feature that would never have been worth it suddenly was. That shift, from "too expensive to bother" to "done in an afternoon", is the whole point of [our piece on affordable custom software](/blog/custom-software-affordable-mid-market).

## The honest line

For most wholesalers and B2B sellers, the standard portal covers the essentials with no custom build at all. Extend it only where a workflow your customers rely on isn't covered. Start from standard, add where it matters.

A portal is usually one face of a larger Odoo setup, the same database also runs your webshop, stock and invoicing. If the webshop side is where your question really sits, see [is Odoo's webshop good enough](/blog/is-odoo-ecommerce-good-enough), or start a [free Odoo scan](/scan).


# AI in retail: only useful when your stock adds up
URL: https://www.fanatics.nl/blog/ai-in-retail
Language: en

import Checklist from '~/components/blog/Checklist.astro'

Saturday night half past eight. The shop closes. Three numbers do not match. The till says 47 bottles in stock. The webshop says 51. The warehouse counts 44. Someone has to spend half an hour working out which is right. Nobody wants that.

That is not an AI problem. That is an "one-stock-figure" problem. AI on three matching wrong numbers makes it wrong faster. But once till, webshop and warehouse run on one stock figure - which is what a well-set-up Odoo does for you - AI opens a few doors.

<Checklist title="What AI does in a shop with a webshop" items={[
  'Forecast stock across all channels',
  'Read supplier invoices and receipts',
  'Personalise offers',
  'Guide visitors to the right product',
]} />

## What AI delivers in a shop with a webshop

| What AI does | How it works | What you get |
|---|---|---|
| **Forecast stock** | Predicts how much of each item you need, across all channels. | Fewer missed sales, less marking down. |
| **Read invoices** | Reads supplier invoices and receipts and sets up the booking. | Less re-typing, fewer errors. |
| **Personalise offers** | Suggests promotions based on per-customer buying behaviour. | Higher basket, more repeat visits. |
| **Help visitors pick** | A chatbot or guided sale that lands on the right product in two questions. | More conversion online, less doubt in store. |

For none of the four do you have to track anything new, provided till, webshop and stock sit in one Odoo.

## Honest: not every pattern works yet

For [Wijnwinkel Barneveld](/cases) we built a platform where till, webshop and accounting run on one Odoo, with a loyalty programme across both channels, deposit handling and an age check at checkout. No AI on it yet, but the base is exactly the kind AI sits sensibly on top of.

Because here is the difference. A loyalty programme across shop and webshop on one database gives you a wealth of data: which customer buys what, how often, when. You can put AI on that - predict which customer is responsive to a targeted offer, or which product is about to run out in two weeks. Without that shared base you get a generic forecast that delivers nothing in your situation.

## An idea we see elsewhere too

At larger member organisations we see the same pattern: a personal content feed or offer, based on what someone looked at and bought before. A visitor who keeps coming back for white wines does not see a promo for red rioja. That sounds obvious, but for it to actually work, the data has to be right and your system has to be able to show something different per customer.

Another pattern showing up more often in retail: a chatbot that guides new visitors through your assortment. For a wine shop: "What are you eating tonight, and how much do you want to spend?" Three suggestions, one click, cart filled. That is no longer far-off future.

## Retail checklist: start now or wait?

| Start with AI when... | Wait a bit when... |
|---|---|
| ...till, webshop and stock run on one system. | ...your stock still sits loose in three places. |
| ...you have a loyalty programme or customer admin AI can learn from. | ...you have no shared customer data. |
| ...something happens often (reordering, booking, questions). | ...it only happens now and then. |
| ...you can measure the result in margin, stock or time. | ...you cannot say what a good result is. |

A clean Odoo is the foundation. AI is the layer on top, not its replacement.

## Why retail custom work now fits the budget

An age check, packaging logic that suggests a case at six bottles, deposit handling that picks up at the right moment - each a focused addition on standard Odoo. These used to be separate projects you weighed up one by one. Today we build them as part of a normal engagement, because AI speeds up the bare code work and we focus on the design.

For the wider story: [custom software is affordable for mid-market now](/blog/custom-software-affordable-mid-market).

## One stock first, then AI

Start with the basics: is everything in one Odoo? Then you can take on a first AI job. Otherwise, that is your first job. Honestly, that is also where we make the difference - we build the foundation and only then take on the smarter layers.

Read on:
- [Odoo for retail](/industries/retail) - how Odoo brings your till, webshop and accounting together.
- [When your checkout needs more than standard Odoo POS](/blog/odoo-pos-beyond-standard) - where custom is actually needed.
- [AI for your webshop](/blog/ai-in-ecommerce) - many patterns overlap.
- [Custom software is affordable for mid-market now](/blog/custom-software-affordable-mid-market) - the pillar.


# Custom prices and configurable products in Odoo: how far can you go?
URL: https://www.fanatics.nl/blog/odoo-product-configurator-cpq
Language: en

Yes, Odoo can handle custom prices and configurable products, and it can go a lot further than most people expect. The question is where standard variants stop being enough and a real configurator starts earning its keep. This guide draws that line.

## Where standard Odoo is enough

Odoo handles product variants and price lists in the standard product. If your catalogue has a manageable set of options, sizes, colours, a few add-ons, and pricing follows clear rules, you don't need anything custom. Set up the variants and the price lists and you're done. Per-customer and quantity-based pricing are standard too, so a lot of "we have complicated pricing" turns out to be configuration, not custom code.

## The signs you need a real configurator

You've outgrown standard variants when:

- Options interact, picking A rules out B, or makes C mandatory.
- The number of valid combinations is too large to list as variants.
- Pricing depends on the configuration, not a fixed list.
- Quotes need engineering input, so they take days and tie up scarce people.
- The price book lives in spreadsheets and one expert's memory.

If two or more of those are true, you're paying for slow, error-prone quoting whether you see it on an invoice or not.

## What a CPQ configurator actually does

CPQ stands for Configure, Price, Quote. Step by step:

1. **Configure** - the user picks options through a decision tree; invalid combinations are blocked at the point of selection, so a quote can't be wrong by construction.
2. **Price** - pricing updates inline as options are chosen, with discount tiers and margin floors per product family, and an approval step for anything below margin.
3. **Quote** - a PDF offer is generated with a visual summary, and the same choices output a bill of materials and engineering notes for production.

We built exactly this as the [Updoo Configurator](/updoo/configurator) for a manufacturer of custom industrial equipment that had 40+ option dimensions and a price book spread across three spreadsheets and one engineer's head. Quotes used to take a week, often arriving after the prospect had moved on.

The outcome: 85% less time per quote, an 18% higher quote-to-order rate, and zero pricing errors in six months. Under the hood it's Odoo Studio plus a custom Python rules engine, an OWL component for the configurator interface, and QWeb templates for the PDF.

## The same idea, facing the customer

A configurator doesn't have to be an internal sales tool. The same logic can sit on your webshop so the customer clicks together a made-to-order product and sees the right price on the spot. We built that for Odoo eCommerce, and it runs at cpqbuilder.com for less than a tenth of what a comparable third-party platform had cost a client the year before. That drop in cost is the whole story of [why custom software became affordable](/blog/custom-software-affordable-mid-market). More on how it works and how it compares to other options: the [Odoo product configurator](/odoo-product-configurator) and [Odoo CPQ options compared](/odoo-cpq-alternatives).

## The honest line

Don't build a rules engine you don't need. Standard variants for simple catalogues; a configurator when the combinations and pricing rules have outgrown what anyone can track by hand. The test is whether your quotes are slow and occasionally wrong, that's the pain a configurator removes, not the existence of options as such.

Want a sense of the investment? See [what Odoo customisation costs](/blog/what-does-odoo-customisation-cost), or start a [free Odoo scan](/scan).


# Can Odoo really run your production floor?
URL: https://www.fanatics.nl/blog/can-odoo-run-your-production-floor
Language: en

Yes, Odoo can run your production floor, but the honest answer has two halves. Odoo plans production well in the standard product. The floor itself, the people doing the work, needs a screen built for that environment, not the office desk the standard screen assumes. Knowing which half is your problem tells you whether you need anything custom at all.

## What standard Odoo Manufacturing already does

The planning side is strong out of the box, and for most manufacturers it's enough:

- Bills of materials and multi-level products.
- Routings and work-order steps per work center.
- Scheduling against work-center capacity.
- Material requirements planning (MRP): what to make or buy, and when.
- Barcode scanning and quality-control checkpoints.

This is rarely where Odoo falls short. If your question is "can Odoo plan and track our production", the standard answer is yes.

## Where it struggles: the floor itself

The weak point is the standard manufacturing order screen. It's built for an office desk: dense, full of fields, slow to navigate between steps. On a tablet, between two work steps, with gloves on, it doesn't get used. The information exists in the system but never reaches the line in a form people can act on. That's how a team ends up back on paper work orders, even with a good ERP behind them.

That's the exact problem [Updoo Shopfloor](/updoo/shopfloor) solves. A 40-person production team had the data in Odoo but worked from paper because the standard screen was too dense for a tablet. We built a full-screen tablet layout with large touch targets, designed for gloved hands:

- One work order, one step at a time, no scrolling.
- Plain-language instructions and photos pulled straight from the Odoo product record.
- Completion in a single tap, pushed back to Odoo in real time.
- A way to flag an issue to the operations dashboard the moment it happens.

The result: zero paper work orders, on-time completion up 11%, and real-time production status. It runs as a custom module with a PWA front-end, offline-capable for short Wi-Fi outages, pulling directly from Odoo Manufacturing so nothing is duplicated. The tablets are standard Android devices.

## Advanced planning, when standard scheduling isn't enough

Some operations need more than the standard scheduler: finite capacity planning, constraint-based sequencing, or rules specific to how your lines actually run, tooling changeovers, shared machines, priority jobs that have to jump the queue. That doesn't mean a separate planning system. It sits on top of Odoo as a focused module, reading from the same data, so the plan the office makes and the work the floor sees are always the same thing. The alternative, a standalone planning tool, is exactly how planning and reality drift apart.

## Connecting machines, scanners and quality

The floor isn't only screens. Barcode scanning is standard; quality checkpoints can sit inside a work order so a step can't be closed until a check passes. Machine and sensor data can feed in through Odoo's API, so completion reflects what actually happened on the line, not just what someone tapped. Each of these is a focused addition, not a rebuild.

## Why operators actually use it

A shop-floor layer earns its keep only if the people on the line adopt it, and they adopt it because they never touch Odoo's complexity. They see one order, one step, one photo, one button. Planning and office users keep the full Odoo. That split, simple on the floor, full in the office, is the whole design.

## When to leave it standard

If your volume is low and paper genuinely works, don't digitise for its own sake. And don't put a tablet layer on a process that's still a mess on paper, fix the process first. The shop-floor layer pays off when the data is already in Odoo but isn't reaching the line in usable form.

Want the accounting side of your production airtight too - work in progress, surcharges and variances against standard cost? See [manufacturing accounting in Odoo](/blog/manufacturing-accounting-in-odoo), video demo included.

Curious what a focused module like this costs? See [what Odoo customisation costs](/blog/what-does-odoo-customisation-cost), or why this kind of build became affordable at all in [our pillar piece](/blog/custom-software-affordable-mid-market). Or start a [free Odoo scan](/scan).


# AI in professional services: one sentence to your planning
URL: https://www.fanatics.nl/blog/ai-in-professional-services
Language: en

"Dominique is leaving. Move all his ecommerce tasks to Mitchel." That is not an email to a colleague. That is a command to [Hypergantt](https://hypergantt.com), our Gantt-management platform on top of Odoo. AI moves the whole puzzle on that one sentence - instead of half an hour of clicking through ten projects.

Or: "Push all tasks after May 1 by a week." Three seconds. Done.

That is where AI in services stands today. Not as a magical answer to everything. But as the way a planner or project manager gets to the right result far faster. We build this kind of tooling for clients, and for ourselves.

## Four AI uses for service firms

| What AI does | How it works | What you get |
|---|---|---|
| **Pre-fill hours** | Suggests timesheet lines from calendar and email. | More billable, less hassle. |
| **Draft quotes** | Builds a proposal from comparable past projects. | Faster quoting, better estimates. |
| **Smarter helpdesk** | Suggests answers from past tickets and your own knowledge base. | Faster response, knowledge retained. |
| **Revise planning** | Moves plannings on natural-language commands. | No more half-hour clicks for one shift. |

For none of the four do you have to track anything new. Projects, hours and customers already sit in Odoo.

## A few real examples

[Jobse groep](https://www.jobsegroep.nl) has a network of photographers and real estate agents. Agents want photos of a house at time X, with a photographer who has the right specialism, in the right region, with a logical route through their day. We built the platform where AI does that puzzle. The same data you would have in Odoo - tasks, skills, availability - just with an AI layer on top that produces a good planning at one click.

RogerDone is the same idea for service technicians. Tasks come from Odoo, AI builds the optimal planning, technicians see on their phone where to go. Far less phone work from the office.

In legal and advisory firms we increasingly get a variant on this question: "Can you build an internal search engine that digs through our past pitches and thought leadership, so we draft a strong proposal faster?" Plus, sometimes added: "...and that pulls in public material from our competitors too?" That is exactly what we are working on for a prospect in spatial planning. The tech is mature enough; it works on your own documents and on publicly available material.

And for timesheets - the place where services firms structurally lose money - we built [Updoo Timesheets](/updoo/timesheets). A stripped-down entry fast enough that people actually do it. AI can pre-fill hours on top from your calendar. [HR Subsidie Specialist](/cases) already binds CRM, project hours and invoicing on one base, so billable hours and live applications do not drift apart - exactly the kind of foundation such an AI layer rests on.

## The question from an entrepreneurs' meeting

A training institute asked us recently whether we could build a dynamic comparison platform where AI matches prospects to the right trainer. The kind of question that five years ago would have needed an innovation budget. Today it is a matter of weeks, with a first working version in two to four weeks.

We are building the same pattern ourselves with fit-gap.com, a comparison platform for CRM and ERP software that keeps itself up to date with AI. Prospects find the right consultancy through a handful of questions.

## Services checklist: when does AI pay off?

| Start with AI when... | Wait a bit when... |
|---|---|
| ...people actually log their hours in Odoo. | ...hours still sit on loose notes or in email. |
| ...something happens often (hours, quotes, tickets). | ...it only happens once a quarter. |
| ...you can measure the result in time, margin or billing. | ...you cannot say what a good result is. |
| ...projects, hours and invoices are in one system. | ...you still pull numbers from three separate tools. |

AI on a shaky process mostly speeds up the mistakes. Get the basics right first.

## Why services custom work fits the budget now

Your own planning tool, a matching platform, an internal knowledge base searchable with AI - these used to be projects for firms with deep pockets. Today we build them in weeks, not years, because AI speeds up the bare code work. We design and test, AI types along.

For the wider story: [custom software is affordable for mid-market now](/blog/custom-software-affordable-mid-market).

## First, hours, quotes and invoices in one place

Pick the job that hurts most right now. For most services firms that is timesheets, for others it is drafting quotes or running the helpdesk. Prove it there first.

Read on:
- [Odoo for services](/industries/services) - how Odoo lays the base.
- [Keeping projects on track](/blog/keeping-projects-on-track) - where planning tools and AI meet.
- [AI for cultural organisations](/blog/ai-for-cultural-organisations) - grant applications and reporting with AI.
- [Custom software is affordable for mid-market now](/blog/custom-software-affordable-mid-market) - the pillar.


# What does Odoo customisation cost in 2026?
URL: https://www.fanatics.nl/blog/what-does-odoo-customisation-cost
Language: en

import DriverTable from '~/components/blog/DriverTable.astro'

A focused custom Odoo module typically costs between €4,000 and €15,000 and goes live in one to three weeks. That's the direct answer. The more useful one takes a few minutes: what you're actually paying for, what pushes the number up, and why that number has been falling.

<DriverTable title="What Odoo customisation costs, roughly" rows={[
  { label: 'Small tweak or automation', value: 'under €4,000' },
  { label: 'Focused module', value: '€4,000 - €15,000' },
  { label: 'Multi-department or multi-system build', value: '€15,000 and up' },
]} />

## The price ranges, by type of work

Standard Odoo covers about 80% of what most companies do. The cost lives in the 20% that makes your business unique. Roughly, custom work falls into three bands, all built by senior developers with no offshore handoffs:

| Type of work | Indicative cost | Typical lead time |
|---|---|---|
| A small tweak or single automation | under €4,000 | days |
| A focused module: a few screens, automations, a clean integration | €4,000 - €15,000 | 1 - 3 weeks |
| A multi-department or multi-system build, with migration | €15,000 and up | several weeks, phased |

These are starting points, not quotes. The same feature description can sit at either end of a band depending on the detail below.

## What actually drives the price

The screens are rarely the expensive part. The cost sits in:

- **Integration depth.** A module that only touches Odoo is cheaper than one that has to stay in sync with an external system. The work is in the connections, not the buttons.
- **Data migration.** Moving and cleaning data from an old system is often the quiet majority of a project. Messy source data costs more than the feature itself.
- **Edge cases and business rules.** "Most orders work like this, except when..." Every exception is logic to build and test. The exceptions, not the happy path, set the price.
- **Compliance and approvals.** Age checks, audit trails, margin approvals: regulated or controlled steps add work because they have to be right every time.

## Customisation and implementation are two budgets

It's worth separating them so you're not surprised. The **implementation** is configuring standard Odoo to your business, plus the per-user licence. **Custom development** sits on top, for the 20% the standard doesn't cover. The pragmatic path is to get the standard set-up live first, then add custom modules only where the standard genuinely falls short, rather than designing everything bespoke from day one. For what the implementation itself costs, see [what does an Odoo implementation cost](/blog/what-does-an-odoo-implementation-cost).

## Don't forget the cost of ownership

The price of a module isn't only what you pay to build it. Every custom line has to be kept compatible across Odoo's annual versions and adjusted as your process changes. A small, well-built module is cheap to keep; the maintenance bill grows with how much custom logic you carry. That's the real reason the cheapest module is the one you don't build.

## Why the bar has dropped

The bigger shift is that AI-assisted development cut the hours a feature takes. A client recently asked for customer-specific price lists they could download as Excel or PDF, plus a way to fill a cart straight from a price list. The old way was a few days and two developers with different specialisms. We built it in four hours, so it finally fit a budget that never stretched to the old version.

The same holds at larger scale. We built a product-configuration platform for Odoo eCommerce that runs at less than a tenth of what a comparable third-party system cost a client the year before. The point isn't that maatwerk got a little cheaper, it's that things you'd never have quoted are now worth quoting. We unpack that shift in [our piece on affordable custom software](/blog/custom-software-affordable-mid-market).

## How to keep the cost down

- **Start standard.** Run standard Odoo first; you'll find some of your "must-have" custom wishes are already covered, or stop mattering once the process is clean.
- **Scope sharply.** A precise description of one workflow is cheaper to build than a vague "make it like our old system".
- **Phase it.** Build the core first, use it, then decide what's actually worth adding. Working software early beats a big bang months later.
- **Fix the process first.** Automating a messy process just makes the mess faster. Software amplifies whatever you point it at.

## When not to pay for customisation at all

If standard Odoo already does the job, leave it alone. If a process is broken, fix the process before you pay to automate it. And if a requirement is genuinely core to the business, that's exactly where experienced people should review every decision, not where you want the cheapest possible shortcut.

## Get a real number for your situation

Ranges only get you so far. Our [implementation calculator](/pricing/calculator) walks through the processes you want to cover and returns a cost breakdown and a go-live timeline. To weigh it against staying put, the [ROI calculator](/pricing/roi) compares five-year Odoo cost against AFAS, Exact and SAP Business One. Or start with a [free Odoo scan](/scan) and we'll map it with you.


# Is Odoo's webshop good enough, or do you need something custom?
URL: https://www.fanatics.nl/blog/is-odoo-ecommerce-good-enough
Language: en

For most mid-sized webshops, standard Odoo eCommerce is good enough. That isn't a compromise, it's the whole advantage: your shop, stock, invoicing and back office sit in one system, with nothing to sync between them. You need something custom only when the storefront itself is what sets you apart. This guide helps you tell which situation you're in.

## What standard Odoo eCommerce already gives you

Before deciding you need custom work, it's worth knowing what comes out of the box, because it's more than people expect:

- A full webshop tied directly to stock, so an order flows straight through to picking, invoicing and reporting.
- Multi-language, multi-currency and multiple storefronts from one back office.
- A native B2B portal: per-customer pricing, payment terms, ordering against quotes, products hidden from customers who shouldn't see them.
- Discounts, coupons, abandoned-cart flows and standard payment providers.
- The same stock number everywhere, because the webshop and the warehouse share one database.

For comparison, that level of B2B on Shopify lives in the Plus tier at around $2,300 a month. In Odoo it's part of the standard product.

## Signs you've outgrown the standard theme

The honest test isn't "could a custom shop be nicer". It's whether one of these is true for you:

- **The storefront is your main differentiator.** Your brand experience is the reason people buy, and a standard theme can't carry it.
- **You need a checkout or buying flow the theme won't do.** A configurator, a quote-to-cart step, an unusual journey.
- **Content and commerce are tightly woven.** Editorial, tools or rich product storytelling sit alongside the buy button.
- **You're hitting a performance or SEO ceiling** the standard theme can't lift past.

If none of these is true, custom work on the storefront is usually money you don't need to spend.

## The three routes, and when each fits

| Route | Best when | Trade-off |
|---|---|---|
| Standard Odoo webshop | The shop is one face of a larger operation; brand isn't the differentiator | Least to build and maintain; bound by the theme |
| Standard webshop + targeted custom code | You need a few specific things the standard misses | Keeps the integration, adds only what you need |
| Fully headless front-end on Odoo | The storefront is the business and needs a bespoke experience | Most freedom; a separate front-end to build and run |

Most companies belong in the middle row. Few genuinely need the third.

## You can keep your current storefront

Choosing Odoo for the back office doesn't force you to rebuild your shop on day one. We often run Odoo behind an existing storefront, syncing orders, customers and stock in near real time. A common path is to run both in parallel for two to four weeks, then move the back office to Odoo while the shop your customers know stays exactly where it is.

## Headless, in plain terms

Headless means Odoo keeps the shop logic, products, stock, pricing, orders, invoicing, while a separate, custom-built front-end handles the experience. This site is an example: a custom front-end served from Cloudflare's edge, with Odoo behind it. You get full design freedom on the storefront and keep a single, integrated back office. The cost is that the front-end is its own application to build and maintain, which is exactly why it's only worth it when the storefront is the business.

## The middle path in practice

[Wijnwinkel Barneveld](/cases/wijnwinkel-barneveld-en) kept Odoo's webshop and added exactly what a wine retailer needs: an 18+ age check at checkout, a legal requirement for selling alcohol online, and packaging logic that suggests building a case once a customer reaches six bottles. Standard where it can be, custom where it has to be, and no full rebuild.

## When to stay standard

If standard Odoo covers your shop, use it. The link to your back office is worth more than a custom theme, and every custom line is something to maintain. Reach for custom work only when one of the signals above is genuinely true.

Want to see how Odoo stacks up against the dedicated platforms? Read [Odoo vs Shopify](/odoo-vs-shopify), [Odoo vs WooCommerce](/odoo-vs-woocommerce) and [Odoo vs Lightspeed](/odoo-vs-lightspeed). Already selling on Shopify and want Odoo as the back office behind it? Read the complete guide [Connect Shopify to Odoo](/blog/connect-shopify-to-odoo). Wondering what a custom front-end or feature would cost? See [what Odoo customisation costs](/blog/what-does-odoo-customisation-cost). Or start a [free Odoo scan](/scan) to map your own situation.


# AI in wholesale: where it really earns its keep
URL: https://www.fanatics.nl/blog/ai-in-wholesale
Language: en

import Checklist from '~/components/blog/Checklist.astro'

A customer emails an order. Sometimes as a clean PDF, sometimes loose in the text, sometimes so unclear that you only get it after the third read. Twice a week a line ends up wrong in Odoo. Someone in the office re-types it, mutters under their breath, and moves on. That is wholesale today - and exactly where AI makes the difference.

Not by replacing your staff. By taking the dullest work off their plate, so your people can do what they are good at: managing customer relationships, sharp buying, watching margins.

<Checklist title="What AI does in a wholesale business" items={[
  'Read orders from email or PDF',
  'Set up customer-specific price lists',
  'Forecast demand per item and customer',
  'Watch margin',
]} />

## AI in wholesale: four uses that work

| What AI does | How it works | What you get |
|---|---|---|
| **Read orders** | Reads incoming orders from email or PDF and sets up the booking. | Less re-typing, fewer Saturday-afternoon errors. |
| **Set up prices** | Drafts customer-specific price lists and quotes, with tiers and discounts. | Faster quoting, fair pricing. |
| **Forecast demand** | Predicts how much of each item you need, per item and customer. | Sharper buying, fewer missed sales. |
| **Watch margin** | Spots items sitting still or leaking margin. | Adjust earlier, better gross profit. |

For none of the four do you have to track anything new. It is already in Odoo.

## The question we hear most often

"Can you get our email orders into Odoo by themselves?" The defining example of where AI starts in wholesale. Customers email, and not everyone the same way. AI reads the message, recognises the customer, recognises the items, and sets up a draft booking. Someone reviews, accepts, done.

Another example from our own work. A customer asked for downloadable customer-specific price lists that fill a cart in one click. That used to be a few days of work and two specialists. We built it in four hours. Not because we type faster, but because AI does the base code work while we focus on the design.

[Decilux](/cases), an AV distributor, runs CRM, sales, stock, buying and accounting on one Odoo. [Keizer International](/cases) migrated off SAP Business One to Odoo for a worldwide trade in bottles and caps. With both, the base is there: one system, clean data. That is exactly the foundation an AI layer can sit on sensibly - reorder suggestions, automatic order intake, alerts on shifting margins. Base first, smart layer second.

The same principle applies to making a B2B portal smarter. On top of what your customer already sees ([order history, own prices](/blog/odoo-b2b-customer-portal)), AI can suggest reorders based on what they bought before and when they usually do that.

## Wholesale checklist: when does AI pay off?

| Start with AI when... | Wait a bit when... |
|---|---|
| ...your stock and prices are right in Odoo. | ...your key customer prices still sit loose in Excel. |
| ...something happens often (orders, quotes, reordering). | ...it only happens now and then. |
| ...you can measure the result in time, stock or margin. | ...you cannot say what a good result is. |
| ...buying, stock and sales are in one system. | ...you still pull numbers from three separate packages. |

AI on a shaky process mostly speeds up the mistakes. Get the basics right first.

## Why wholesale custom work now fits the budget

Four hours of building for a feature that used to take a few days - that is not a one-off. That is how we build more often, including in wholesale and distribution. We call it vibe coding: the specification and the design stay human work, the dull typing AI does with us.

The practical effect: a targeted solution for one customer group, one product line or one market step now fits the budget. No more waiting "until we are big enough to have a dev team". Build now, at the scale you have.

For the full story behind this: [custom software is affordable for mid-market now](/blog/custom-software-affordable-mid-market).

## First, make demand and stock predictable

Pick one process that hurts right now. Usually that is order intake or price lists. Write down for a week where time goes that nobody really wants to spend. That is your first AI job.

Read on:
- [Odoo for wholesale](/industries/wholesale) - how Odoo lays the base.
- [A self-service portal for your B2B customers](/blog/odoo-b2b-customer-portal) - where AI can build further.
- [AI for your webshop](/blog/ai-in-ecommerce) - many B2C patterns work in B2B too.
- [Custom software is affordable for mid-market now](/blog/custom-software-affordable-mid-market) - the pillar.


# AI for your webshop: four things that already work
URL: https://www.fanatics.nl/blog/ai-in-ecommerce
Language: en

A webshop with four thousand items. Three languages. A product manager who never quite keeps up with all of it. That is where AI in a webshop starts today - not with predictions about next year, but with a hundred product texts this afternoon.

We have built for several webshops in the past while where AI makes a difference. Below are four patterns that work, with the places where we have them running.

## What AI can already do for your webshop

| What AI does | How it works | What you get |
|---|---|---|
| **Write product copy** | Drafts descriptions and translations from your catalogue. | New products online faster, in every language. |
| **Forecast stock** | Predicts how much of each item you need, from your own orders. | Fewer missed sales, less dead capital. |
| **Triage questions** | Reads incoming email and drafts a reply. | Faster service, less manual work for your team. |
| **Help visitors choose** | A chatbot or guided sale that lands on the right product in a couple of questions. | Higher conversion, fewer returns. |

For none of the four do you have to track anything new. Your orders, products and customers already sit in Odoo.

## CPQbuilder: our own showcase

[CPQbuilder.com](https://cpqbuilder.com) is a product configurator we built ourselves, on top of Odoo eCommerce. Customers click together a made-to-order product - colour, size, engraving, options - and see the right price straight away. Behind the scenes it runs through all of Odoo's pricing rules.

Building the same system through an external party would cost a multiple of what we paid. We built it with AI-assisted development, in a fraction of the time something like this used to take. Multiple Odoo webshops now run on it.

The same idea from another angle: [IDD Parts](/cases) bundled a complex, configurable product range, the sales process and a B2B portal into one Odoo. One database, one source of truth, and the catalogue your customer sees comes directly from the system your buying runs on.

## The questions we get

Our customers rarely start with "we want AI". They start with a concrete problem. What we have mostly heard in the past year:

**"Our product copy pipeline is stuck."** Four product managers translating by hand, no one quite keeping up. AI drafts from the catalogue, in three languages at once. A person checks and publishes. The time you get back is not in one moment but every week again.

**"Customers drop off at choices with many variants."** Someone landing on a made-to-order product who does not know which option to pick, leaves. A conversational chatbot that narrows the assortment one question at a time, keeps them in. Combine that with a configurator like CPQbuilder and you have something nobody built for a mid-market webshop in 2018, because it was too expensive.

**"Our stock never matches what we should have ordered."** AI predicts demand per item from your own sales history, season, weather. Not perfect - no forecast is - but better than gut feeling.

## Webshop checklist: start now or wait?

| Start with AI when... | Wait a bit when... |
|---|---|
| ...your product data is clean and up to date. | ...your catalogue is still full of wrong attributes and duplicate products. |
| ...something happens often (copy, questions, reordering). | ...it only happens now and then. |
| ...you can measure the result in time, conversion or stock. | ...you cannot say what a good result is. |
| ...shop and back office sit in one Odoo. | ...your stock still lives somewhere separate. |

AI on a messy catalogue mostly speeds up the mess.

## Why your own configurator suddenly works

Building CPQbuilder cost us a fraction of what a comparable project would have cost ten years ago. Not because developers are cheaper, but because AI speeds up the bare code work. The craft - working out how your product works, how you sell it, how a price falls out of three rules - stays human. But around that, much of the dull typing falls away.

That means your own configurator or a targeted extension on your Odoo webshop suddenly fits the budget, even if you do not have a hundred staff. For the wider story: [custom software is affordable for mid-market now](/blog/custom-software-affordable-mid-market).

## First, get your product data straight

Walk your own customer service for a day. Write down which question keeps coming back. Write down which products get returned too often. Those are your first two AI jobs. Both straightforward to start, both easy to measure.

Read on:
- [Odoo for ecommerce](/industries/ecommerce) - what the base already does for you.
- [Is Odoo's webshop good enough, or do you need custom?](/blog/is-odoo-ecommerce-good-enough) - where Odoo works fine and where it pinches.
- [AI in wholesale](/blog/ai-in-wholesale) - many B2B patterns apply to B2C too.
- [Custom software is affordable for mid-market now](/blog/custom-software-affordable-mid-market) - the pillar.


# From website visitor to concrete ERP lead
URL: https://www.fanatics.nl/blog/from-visitor-to-erp-lead
Language: en

Most companies follow the same pattern on their websites: a block of content, a contact form, and the hope that someone leaves a name and email. What do you get back? A list of names you know almost nothing about, and a sales team that loses half its time to conversations that go nowhere.

At Radical FANATICS we do it differently. Not because we're smarter - because we got tired of it.

## Where standard forms fall short

"Leave your details, we'll get in touch." It works. But it qualifies nothing, it delivers no value to the visitor, and the ball is now in sales' court to figure out whether there's anything there.

Meanwhile, the visitor leaves your site with the same feeling they arrived with. No insight into their own situation, no reason to come back.

## Updoo: your website runs the first sales call

With **[Updoo](/updoo)** we build interactive tools that do three things at once:

1. **The visitor assesses their own situation.** A short questionnaire, a completed scan, a configured example - and they know more leaving than they did arriving.
2. **The tool delivers immediate value.** A report, a score, a benchmark, a price indication. Not "we'll email you later" - *something in hand now*.
3. **The lead arrives qualified.** Lands in [Odoo CRM](/odoo-erp) with answers, score and context. Sales knows the question before they pick up the phone.

## Example: the ERP Reality Scanner

Our most-used tool is the **ERP Reality Scanner** - a four-minute questionnaire that measures how future-proof your current system is.

It asks about:
- Which modules / tools you use, and how they (don't) work together
- How much manual work still sits between them
- Whether reports are at your fingertips or a spreadsheet project
- How many years you still want to run on the current system

At the end, the visitor gets an **honest report** - not a pitch. Sometimes the conclusion is: "Your current setup is fine, wait two years." Sometimes: "Three of your five processes are stuck, here's what to do about it." For companies already evaluating a switch, the <a href="/pricing/roi">ROI calculator</a> makes the business case concrete.

And *because* the visitor got value first, the second conversation isn't a cold lead - it's someone who understands their situation and shows up with a specific question.

## What we see at clients

Since we started running the Reality Scanner, what stands out:
- **Higher conversation quality** - sales spends less time explaining, more time advising
- **Higher conversion** from first contact, because the fit is clearer earlier
- **Less time lost** on prospects who were never going to become customers

Want to see real examples of what this looks like at clients? Browse our <a href="/cases">client cases</a>.

## Beyond lead capture: the Updoo building blocks

The Reality Scanner is one application. With Updoo we also build:

- **Custom customer portals** where existing clients handle their own affairs
- **Shared dashboards** for external stakeholders (accountants, partners)
- **AI analyses and reports** as the value piece at the front door
- **Custom integrations** without endless custom-code projects

All on top of Odoo, all part of what we call [custom development](/odoo-custom-development).

## Want to try?

Have an idea for a tool that delivers value to your website visitors *and* lets your sales start better? [Plan a quick call](/contact) - we'll know straight away whether it fits, and if so, what it could look like.

Or browse our [Updoo case studies](/updoo) for inspiration on what we've already built.


# We are now an Odoo Gold Partner
URL: https://www.fanatics.nl/blog/we-are-now-odoo-gold-partner
Language: en

As of July 2025, Radical Fanatics is officially an [Odoo Gold Partner](/odoo-partner-nederland) - a title that puts us among the [top Odoo partners in the Netherlands](/blog/top-10-odoo-partners-netherlands-compared). But while others grow in headcount, we deliberately choose to grow in quality. We remain a compact, senior team with short lines, big impact, and the agility that makes a real difference in the SMB world.

## From silver to gold - and that's exactly big enough

Today I'm proud to announce that we reached Odoo Gold Partner status as of July 2025.

For us at Radical Fanatics, this isn't a checkbox on a list. It's a milestone that shows we consistently deliver top quality, and that we've earned our customers' trust.

But there's one important difference from many other Gold Partners: **we want to stay small**.

### Gold in status, compact in approach

Over the past few years we've grown more than 100% annually. For the years ahead we're planning controlled growth of around 60% per year. That growth isn't accidental: we work exclusively with senior consultants and developers, all with multiple years of Odoo experience. That means every new client immediately works with someone who knows what they're doing - no expensive learning curves.

We also always keep about 1.5 FTE of strategic capacity reserved (currently Tamara and myself) so we can scale up immediately when a project demands it. Since becoming a Gold Partner, attracting extra senior talent has become even easier. And yes, we don't just budget for revenue growth - we budget for the <a href="/team">people who make it happen</a>.

### Why staying small is our biggest strength

Because we believe a compact, specialised team has more impact. Short lines, fast decisions, and your project as top priority - that's what works. At larger firms a client quickly disappears into a long queue of running projects. With us, you know exactly who you're talking to and who's responsible.

### What you gain from our Gold Partner status

Gold Partner status gives us direct access to extra knowledge, resources, and support from Odoo itself. That translates to:

- Faster and better solutions for complex questions
- Even more up-to-date expertise
- Better access to new developments in Odoo

But the most important thing remains: with us, your project isn't one of many. It gets full attention and the knowledge of seasoned Odoo professionals - with the certainty that we can scale with you when needed.

I want to thank all our clients and partners who contributed to reaching this milestone. We're looking forward to building further, our way: with the power of Gold, but the focus of small. Want to see what we've built together? Browse our <a href="/cases">client cases</a>.

---

**Further reading:** [Top 10 Odoo partners in the Netherlands compared](/blog/top-10-odoo-partners-netherlands-compared) · [About FANATICS](/about) · [Our approach: the TARGET method](/target)


# The best Odoo partner in the Netherlands? Top 10 honestly compared (2025)
URL: https://www.fanatics.nl/blog/top-10-odoo-partners-netherlands-compared
Language: en

import PartnerMatchScrolly from '~/components/blog/PartnerMatchScrolly.astro'

A year ago we published our first top-10 list of Dutch Odoo partners. The IT landscape stays dynamic, so it felt like time for an update. In broad strokes: **six instead of two Gold partners** and **eight instead of ten Silver partners**. The number of Ready partners also rose from 23 to 30. Best of all: Radical Fanatics has climbed from #9 to #6 in the Dutch Odoo ranking, and we're the smallest Gold partner - a spot that fits us and that we're very proud of.

In this post I describe the top 10 Dutch Odoo partners, where they are based, and what I see as their strengths. The companies are ranked by the number of published references on Odoo.com as of 31 July 2025. And because the biggest partners are always at the top by default, we've reversed the list (small to large) - I think a typical SMB is better off with a smaller partner, both for cost and focus.

At this article's snapshot date (31 July 2025) the Netherlands counted **44 partners**, 10 more than a year earlier; by now there are 51. Below is the top 10 by number of implementations and references. Want to see every partner, including current tiers? Check [the complete Dutch Odoo partner landscape](/odoo-partners-netherlands), or how these partners score on [forward-thinking quality](/blog/most-forward-thinking-odoo-partners-europe).

<PartnerMatchScrolly lang="en" />

## At a glance

| # | Partner | Status | References | Segment | Location | Cost |
|---|---|---|---:|---|---|---|
| 10 | Wesolved Group | Silver | 31 | SMB/SMB+ | Kerkrade | $ |
| 9 | New Way | Silver | 41 | SMB+ | 's-Hertogenbosch | $ |
| 8 | ERP\|open | Silver (was Gold) | 62 | SMB+/Enterprise | Bunnik | $$$ |
| 7 | dooIT | Silver (was Gold) | 95 | SMB/SMB+ | Rotterdam | $ |
| 6 | **Radical Fanatics** | **Gold** | 44 | SMB/SMB+ | Amsterdam | $ |
| 5 | Cravit | Gold (was Silver) | 51 | SMB+/Enterprise | Breda | $$ |
| 4 | 360ERP | Gold | 85 | SMB+/Enterprise | 's-Hertogenbosch | $$ |
| 3 | Aardug | Gold | 91 | SMB+/Enterprise | Enter | $$ |
| 2 | Dynapps | Gold | 98 | Enterprise | Capelle aan den IJssel | $$$ |
| 1 | Odoo Experts | Gold | 103 | Enterprise | Zaandam | $$$ |

*Source: number of published references on Odoo.com as of 31 July 2025.*

*One editorial weighting in the interactive comparison above: partners that actively hinder their current customers from switching away get penalty points in my ranking. The numbers shown stay factual - only the order shifts. Customer freedom weighs heavily for me.*

---

## 10. Wesolved Group

| Property | Value |
|---|---|
| **Cost** | $ |
| **Segment** | SMB/SMB+ |
| **Sectors** | Wholesale, eCommerce/retail, food/hospitality |
| **Location** | Kerkrade |
| **References** | 31 |
| **Partner status** | Silver |
| **Website** | [www.wesolved.com](https://www.wesolved.com/) |

Wesolved is an Odoo partner with a focus on retail and wholesale operations. They were previously a partner of Bikebutler - originally set up by our colleague Michael Chin Sue - and they've also worked for VanMoof. Wesolved was a Ready partner not long ago; recently they moved up to Silver.

## 9. New Way

| Property | Value |
|---|---|
| **Cost** | $ |
| **Segment** | SMB+ |
| **Sectors** | Retail, trade, distribution |
| **Location** | 's-Hertogenbosch |
| **References** | 41 |
| **Partner status** | Silver |
| **Website** | [www.newway.nl](https://www.newway.nl) |

New Way has had a turbulent time with a merger/acquisition. They seem to be back on track, though they lose a spot in the ranking. I'd say New Way is the most experienced partner on the retail side.

## 8. ERP|open

| Property | Value |
|---|---|
| **Cost** | $$$ |
| **Segment** | SMB+/Enterprise |
| **Sectors** | Logistics, trade, eCommerce, manufacturing |
| **Location** | Bunnik |
| **References** | 62 |
| **Partner status** | Silver (formerly Gold) |
| **Website** | [www.erpopen.nl](https://www.erpopen.nl) |

ERP\|open is a nice group of people. They were Gold partner recently but slipped back to Silver under Odoo's new rules. In previous years ERP\|open grew faster than their own organisation could handle - that seems better in check now.

## 7. dooIT

| Property | Value |
|---|---|
| **Cost** | $ |
| **Segment** | SMB/SMB+ |
| **Sectors** | Finance, trade |
| **Location** | Rotterdam |
| **References** | 95 |
| **Partner status** | Silver (formerly Gold) |
| **Website** | [www.dooit.nl](https://www.dooit.nl) |

dooIT is part of the MOVE-IT group, which also includes eServiceware (an AccountView partner). That means they attract a lot of clients who've outgrown AccountView, mostly in finance and trade. dooIT was Gold not long ago but dropped to Silver under Odoo's new rules. The churn from AccountView to Odoo is driving significant growth.

## 6. Radical Fanatics

| Property | Value |
|---|---|
| **Cost** | $ |
| **Segment** | SMB/SMB+ |
| **Sectors** | eCommerce, trade, manufacturing, project-driven organisations, installation, finance |
| **Specialism** | Our own Odoo product configurator (CPQ / Configure-to-Order): [CPQ Builder](https://cpqbuilder.com) |
| **Location** | Amsterdam |
| **References** | 44 |
| **Partner status** | Gold |
| **Website** | [www.fanatics.nl](https://www.fanatics.nl) |

We find ourselves at position 6. In a year we've climbed **3 spots** - the fastest riser in the top 10. We've also been rewarded with the prestigious **Gold partnership**. In 2023 we won the prize for **Best Odoo Starter in Europe**. That probably says enough about our approach and how we serve new and existing clients - and our ambition for the future. Browse our <a href="/cases">client cases</a> to see what that looks like in practice.

What sets us apart technically: we built our own product configurator for Odoo, **CPQ Builder** (Configure, Price, Quote). It adds a configurator wizard to any Odoo product page and writes the configuration through the standard Odoo API as a sale order, a bill of materials (BOM) and a manufacturing order - with no custom module in Odoo. That lets us run **Configure-to-Order** for manufacturers entirely inside Odoo, from quote to manufacturing order. It runs as a standalone product at [cpqbuilder.com](https://cpqbuilder.com) and is not a standard offering for most partners on this list.

Our focus is SMB and SMB+. Deliberate, because we like to see the results of what we do, and we appreciate the "just-do-it" mentality that defines SMB. Want to know how we run projects? Read about [our TARGET method](/target) or [start the free Odoo scan](/scan).

## 5. Cravit

| Property | Value |
|---|---|
| **Cost** | $$ |
| **Segment** | SMB+/Enterprise |
| **Sectors** | Services, trade, manufacturing, projects, retail & eCommerce |
| **Location** | Breda (working worldwide) |
| **References** | 51 |
| **Partner status** | Gold (formerly Silver) |
| **Website** | [www.cravit.nl](https://www.cravit.nl) |

If you've searched for Odoo, chances are you've seen Cravit in a Google Ads ad. Cravit lost their Gold status for a while last year but is back in the race. They did lose some references over the past year.

## 4. 360ERP

| Property | Value |
|---|---|
| **Cost** | $$ |
| **Segment** | SMB+/Enterprise |
| **Sectors** | Retail, manufacturing, fashion, services |
| **Location** | 's-Hertogenbosch |
| **References** | 85 |
| **Partner status** | Gold |
| **Website** | [www.360erp.com](https://www.360erp.com) |

360ERP has grown quickly. That's likely down to a number of recognisable names in their client portfolio, combined with a business model where high-performing employees can become partners. The fact that this works for them as an Odoo partner shows in the rapid growth and the enthusiasm of management and team. A nice group with a fresh approach - and a golden future if you ask me. 360ERP lost a few spots in the ranking last year but still sits at a respectable #4.

## 3. Aardug

| Property | Value |
|---|---|
| **Cost** | $$ |
| **Segment** | SMB+/Enterprise |
| **Sectors** | Trade, manufacturing, installation, construction, services |
| **Location** | Enter |
| **References** | 91 |
| **Partner status** | Gold |
| **Website** | [www.aardug.nl](https://www.aardug.nl) |

Aardug is a Gold partner based in Enter, focused on Odoo implementations for the SMB market. They target trade, manufacturing and installation businesses, and favour standard Odoo over custom development.

## 2. Dynapps

| Property | Value |
|---|---|
| **Cost** | $$$ |
| **Segment** | Enterprise |
| **Sectors** | Retail, construction, energy, healthcare, automotive |
| **Location** | Capelle aan den IJssel |
| **References** | 98 |
| **Partner status** | Gold |
| **Website** | [www.dynapps.nl](https://www.dynapps.nl) |

Dynapps is one of the biggest - possibly globally the biggest - Odoo partner. They don't belong on the Silver list and will quickly move back to Gold. Dynapps serves mostly larger clients.

## 1. Odoo Experts

| Property | Value |
|---|---|
| **Cost** | $$$ |
| **Segment** | Enterprise |
| **Sectors** | Wholesale, eCommerce/retail, manufacturing/installation |
| **Location** | Zaandam |
| **References** | 103 |
| **Partner status** | Gold |
| **Website** | [www.odooexperts.nl](https://www.odooexperts.nl) |

Odoo Experts rightly deserves the title of "dinosaur" among Dutch Odoo partners. Founded in 2012, they're a partner from day one and rightly call themselves the biggest in the Netherlands. Odoo Experts is the right choice for larger organisations (>200 employees) looking for a capable partner. For smaller organisations, Odoo Experts may be on the expensive side.

---

## Frequently asked questions

### How many Odoo partners are there in the Netherlands?

As of mid-2025, there are **44 Odoo partners** in the Netherlands - 10 more than a year ago. Of those, 6 are Gold, 8 are Silver and 30 are Ready.

### Who is the biggest Odoo partner in the Netherlands?

**Odoo Experts** in Zaandam, with 103 published references, is the biggest Odoo partner in the Netherlands. Dynapps (98) and Aardug (91) come in second and third.

### Which Odoo partner is best for an SMB?

For SMB companies (5–250 employees), a **smaller Gold or Silver partner** is often a better fit than a large Enterprise partner. Smaller partners have shorter lines, lower costs and more focus per project. Radical Fanatics, Cravit, dooIT and Wesolved are examples of partners that focus specifically on the SMB segment. Curious about what working with us looks like? Read more on our <a href="/odoo-partner-nederland">Odoo Gold Partner page</a>.

### What's the difference between a Gold, Silver and Ready Odoo partner?

Odoo has three partner tiers: **Gold** (highest, requires multiple paying users and ongoing certification), **Silver** (mid-tier, experienced) and **Ready** (entry-level, recent partner). The tier reflects scale and ongoing quality assurance - not automatically the fit with your business.

### How is this top 10 compiled?

The ranking is based on the **number of published references on Odoo.com** at a snapshot date (31 July 2025 for the current edition). It's the most objective publicly available measure of partner size and activity.

---

## Comparing Odoo with other ERPs?

If you're weighing Odoo against another package: check our honest comparisons - [Odoo vs AFAS](/odoo-vs-afas), [Odoo vs Exact](/odoo-vs-exact), [Odoo vs Salesforce](/odoo-vs-salesforce), [Odoo vs Shopify](/odoo-vs-shopify), [Odoo vs Microsoft Dynamics](/odoo-vs-dynamics). Or see them all at [/compare](/compare).

---

With this list I've tried to describe the Dutch [Odoo](/odoo-erp)-partner landscape as accurately as possible - from the knowledge I have about these partners. Things may have shifted slightly by the time you read this. I'll try to keep the list up to date.

Comments or questions? Email me at [tim@fanatics.nl](mailto:tim@fanatics.nl).

---

**Further reading:** [We are now an Odoo Gold partner](/blog/we-are-now-odoo-gold-partner) · [Is your ERP ready for retirement?](/blog/time-to-retire-your-erp) · [What does Odoo cost?](/help/wat-kost-odoo)


# Subcontracting in Odoo ERP with traceability based on lots and serial numbers
URL: https://www.fanatics.nl/blog/subcontracting-odoo-traceability
Language: en

In this video, Tim Kieft from Radical Fanatics walks you through how subcontracting works in [Odoo ERP](/odoo-erp) - and more importantly, how to keep full traceability when outsourcing part of your production process.

The demo centers on a multi-component product, some parts of which are produced in-house, others purchased from suppliers, and one assembled by a subcontractor (in this case, ASML). Using lot numbers and serial numbers, Odoo allows you to track exactly where each component came from, when it was received, and how it moves through the production process - all the way to the finished product.

What makes this walkthrough particularly useful is that it shows the full subcontracting flow in Odoo: sending components to the subcontractor, receiving back sub-assembled items, and finishing the product internally. The demo includes Make to Order (MTO) logic, automated purchase and manufacturing order generation, and how Odoo handles resupplying subcontractors with your own components. You'll also see how to register incoming materials with the correct serial or lot numbers - a must-have for traceability in manufacturing.

Every step, from inventory movements to production completion, is visible and auditable. This is essential for companies that rely on outsourced manufacturing but still need to maintain strict quality control, regulatory compliance, or warranty tracking. See how similar companies solved this in our <a href="/cases">client cases</a>.

If you're working in [manufacturing](/industries/manufacturing), assembly, or any traceability-driven industry, and you use (or are considering) [Odoo ERP](/odoo-erp), this demo gives you a clear picture of what's possible without any [custom development](/odoo-custom-development) - using Odoo's standard inventory and manufacturing apps.

Want to learn more about how Odoo can streamline your production and subcontracting flows? Reach out to our team at [team@fanatics.nl](mailto:team@fanatics.nl) or [start a free scan](/scan) for more practical use cases.

---

**Further reading:** [Manufacturing accounting in Odoo](/blog/manufacturing-accounting-in-odoo) · [Which Odoo modules to start with](/help/odoo-modules-waar-beginnen) · [How fast can we go live?](/help/hoe-snel-live) · [Odoo ERP overview](/odoo-erp)


# Why I left AFAS for Odoo - and never looked back
URL: https://www.fanatics.nl/blog/why-i-left-afas-for-odoo
Language: en

*An honest comparison of two ERP systems, from my own practice.*

A few years ago I sold my cloud-software company. Nice deal, great people, and I got the chance to keep building inside the company that had bought us - a mature SMB with around 180 employees.

That's where I first ran into **AFAS**. Everything was in it: accounting, payroll, leave management. But let's be honest: as soon as you looked beyond the finance team, the story changed.

We used Topdesk for helpdesk. Parrot for newsletters. Outlook for communication. And reports… those often cost more time than the project itself.

The system worked, but it also got in our way. What were we missing? An overall picture. One central place where all the information came together. A **360-degree view** from customer to project to invoice. And that's exactly what AFAS couldn't give us.

A few years later I left that company. Not because of the people - because I felt it could be done differently. Better. And then I - luckily - ran into **[Odoo](/odoo-erp)** again.

Everything I'd been searching for suddenly fell into place. And I decided: **this is the platform SMB companies can really move forward with.** Today, with my company Radical FANATICS, I help dozens of entrepreneurs a year make the switch. And every day - like my clients - I'm grateful I did.

## Odoo vs AFAS: the big picture

| Feature | Odoo | AFAS |
|---|---|---|
| Usability | Modern and intuitive | Less accessible for non-finance users |
| Flexibility | Modular, extensible | Rigid, mostly within its own frame |
| 360 customer view | All integrated | Many separate tools needed |
| Pricing structure | Pay per user | Expensive quickly as you grow |
| Payroll processing | Via integration or import | Native |
| Open API and integrations | Yes, very open | More limited, more closed ecosystem |

 Want the full comparison? See our honest [Odoo vs AFAS comparison](/odoo-vs-afas).

## What if your company wants more than just bookkeeping?

###  Project-driven organisations

If you work with projects, work orders, time tracking and scheduling, you'll hit AFAS's limits quickly. Odoo's strength is the opposite: everything in one flow, from quote to invoice.

###  Inventory-heavy businesses

Odoo has advanced warehouse management, barcodes, real-time stock levels and automatic purchasing. In AFAS that's all a bit less integrated.

###  eCommerce & retail

With Odoo you run webshop, POS and inventory from one environment. AFAS? It's mostly focused on the back office, not the sales side. See more about how Odoo handles the <a href="/industries/ecommerce">e-commerce sector</a>.

###  Manufacturing and assembly

Odoo Manufacturing shows you exactly what needs to be produced when, what raw materials you need, and what's already on hand. In AFAS this is often an external solution or workaround. Read more about Odoo in the <a href="/industries/manufacturing">manufacturing sector</a>.

## And what about payroll?

Yes, AFAS scores a point here. **Payroll is fully integrated** - handy if you want to keep that in-house. Odoo doesn't (yet) have native payroll, but it offers [integrations](/help/koppelingen-exact-twinfield) and easy import options with the most-used tools - [Nmbrs](https://www.nmbrs.nl/), [Loket](https://www.loket.nl/), [Exact](/odoo-exact-integration).

## What I learned

Sometimes you need to walk away from something to see what you really need. For me that was AFAS. Solid? Sure. But not the platform that takes a modern SMB further. Weighing more options? Our <a href="/compare">ERP comparison hub</a> puts all the alternatives side by side.

With Odoo I felt: this is what we were looking for back then - in that company, and honestly in the company before it too.

I made it my mission to help other entrepreneurs make the right choice. And honestly? Every time I see a client thrive on Odoo, I'm glad I made the switch.

**Stuck between AFAS and Odoo?** [Let me know](/scan). I'll show you in 20 minutes what's possible - no fluff, just how it is.

---

**Further reading:** [Is your ERP ready for retirement?](/blog/time-to-retire-your-erp) · [Top 10 Odoo partners in the Netherlands compared](/blog/top-10-odoo-partners-netherlands-compared) · [What does Odoo cost?](/help/wat-kost-odoo)


# Is your ERP ready for retirement? Time to switch - without the headaches.
URL: https://www.fanatics.nl/blog/time-to-retire-your-erp
Language: en

import Checklist from '~/components/blog/Checklist.astro'
import ResearchTeaser from '~/components/blog/ResearchTeaser.astro'

You know the feeling. Your ERP has been doing its job loyally for years. You've built a love-hate relationship with it. But somewhere you've known for a while: this isn't working anymore. The system is slow, clunky, outdated, or just way too expensive. Or worse: your vendor is pushing you into an "upgrade" you didn't ask for.

Or maybe you're running a patchwork of separate tools. One for invoices. One for inventory. Another for the webshop. Oh, and that Excel file only your colleague Gert understands… Add it all up and you're already paying ERP-level prices - but with none of the calm an ERP should bring.

Sound familiar? Then this article is for you.

<Checklist title="Five signs it is time to switch" items={[
  'Your vendor is phasing out your system',
  'Too expensive for what you get',
  'Five separate tools that do not talk',
  'You grow, your system does not',
  'Every change needs an army of consultants',
]} />

## Why switching ERP doesn't have to be a punishment

For many SMB owners and managers, ERP still feels like a chore. Not a topic you get excited about. Until you run into the limits of your system day in, day out. You've lost overview. Departments work past each other. IT costs spike. And customers notice too.

So what are the main reasons companies actually take the step?

### 1. Your current ERP is being end-of-life'd

Vendors like [SAP](https://www.sap.com/netherlands/) and [Microsoft Dynamics](/odoo-vs-dynamics) phase out support for older versions. You **have** to upgrade. On their terms. And usually at their rates.

### 2. Too expensive for what you get

You started with a small package. Now you're spending thousands a month. And every extra report or change comes with: "That's custom work, extra cost." Try the <a href="/pricing/calculator">implementation cost calculator</a> to see what a modern alternative would actually set you back.

### 3. You're juggling five tools that don't talk to each other

Invoicing in Exact, inventory in a spreadsheet, CRM in another system, time tracking in a tool nobody's ever logged into. The question isn't *whether* something will go wrong - it's when. Our <a href="/compare">ERP comparison hub</a> helps you see which alternative fits your situation.

### 4. You're growing - but your system isn't

What once worked is now grinding to a halt. You have multiple warehouses, you sell across borders, you want to connect your webshop. But your ERP says: "Don't."

### 5. You want out from under IT-dependency

Every change in your current system takes time, money, and a six-page email thread. You want to steer your own ship without hiring a small army of consultants.

<ResearchTeaser lang="en" />

## When is the right moment to switch?

The honest answer? Before your organisation grinds to a halt. Many companies wait too long. Until everything creaks, employees grumble, customers leave.

The best time to switch isn't "when you have time" - it's **when your business demands it**. Whether that's growth, frustration, or a deadline from your current vendor - take it seriously.

**But switching is a drama, right?** It really doesn't have to be.

With a good plan, an engaged team, and a partner who knows what they're doing, an ERP implementation doesn't have to be a nightmare. Especially not when you choose a system like [Odoo](/odoo-erp) - flexible, modular, user-friendly, and built for SMB.

At Radical FANATICS we have one mission: radically improve your working life. No thick consultancy folders or 87-page project plans. Just no-nonsense, step by step.

## Checklist: is it time for a new ERP?

Answer yes or no:

- Will your ERP soon lose support?
- Do you pay extra for every change?
- Is your team using multiple separate tools?
- Have you lost real-time overview?
- Are reports late or incomplete?
- Do you want more control, less IT-dependency?
- Do you (or your team) groan about the system every week?

More than three "yes"? You know enough.

## What does a modern ERP like Odoo deliver?

- One system for all your processes
- Lower IT costs
- Faster decisions on real-time data
- Better collaboration between departments
- Easy to scale as you grow
- And most important: peace of mind

**Why pick [Radical FANATICS](/about)?** We help SMB companies switch to [Odoo](/odoo-erp). Not because they "have to" - because it can be better. We speak your language, we don't fetishise billable hours, and we make sure you get a grip on your business again.

Oh - and we do what we promise.

**Ready to (finally) say goodbye to your old ERP?** Schedule a <a href="/quickscan">no-strings intro call</a>. We'll show you how Odoo works, what to watch for in a switch, and what it delivers. No pitches. Just honest advice.

Because if you keep doing what you've always done, you'll keep getting what you've always gotten.

---

**Further reading:** [Why I left AFAS for Odoo](/blog/why-i-left-afas-for-odoo) · [Which Odoo modules to start with](/help/odoo-modules-waar-beginnen) · [What does Odoo cost?](/help/wat-kost-odoo)


# Why civil-engineering firms finally need to get their software sorted
URL: https://www.fanatics.nl/blog/civil-engineering-software
Language: en

*And how Odoo helps you get a grip on underground infrastructure projects.*

Years ago, I walked into a site shed at a civil-engineering company and got coffee in a mug whose handle was held on with duct tape. While the foreman pulled a paper work-order from his dashboard, he muttered: "Tim, we don't have time for systems. We need to make metres." I'll never forget that moment.

I got him. In the world of cables, pipes and excavators, it's all about speed, overview and just-doing-it. But I also noticed something else: without a good system, those metres got lost in stray [work orders](/blog/digital-work-orders), double-booked schedules and hours nobody ever logged.

Since then, with [Radical FANATICS](/about), I've helped dozens of similar companies get a grip - *with* a good system. Not with thick reports or consultants in suits, but with one smart solution: [Odoo](/odoo-erp).

## The reality at civil-engineering contractors

Companies in civil engineering - especially underground infrastructure (cables, pipes, fibre) - typically work with:

- Short, intense projects
- Constantly shifting crews and equipment
- Project-based procurement rather than stock management
- A working environment where "just a quick chat" doesn't really work when you're standing on a construction site

And yet I often see software that's hopelessly behind. Once built "to spec", no longer maintainable. Or a tangle of Excel files, Outlook calendars, and an accounting package that the rest of the company can't use.

## Enter Odoo

Odoo is a modern ERP that lines up well with the challenges of infrastructure contractors. It grows with you, it's affordable, and most of all - it works the way you work.

###  Project management as it should be

Start a project, break it into phases (digging, laying, testing), and track status live. Big project or small - Odoo keeps it manageable.

###  Crew and equipment planning

Who's working where? Which excavator is available? With a visual Gantt view you plan it and see clashes immediately.

###  Digital work-orders and time tracking on site

A simple app lets field staff log their hours, with photos and notes. No more paper clutter. And the back office? Real-time insight.

###  Smart per-project procurement

Order what you need directly from the project. No fuss with stock if you don't carry any. Odoo makes it easy.

###  Quotes, invoices and (optionally) accounting

Build quotes, link them to projects, invoice based on progress. Want to connect [Exact](/odoo-exact-integration) or [Twinfield](/odoo-twinfield-integration)? No problem.

###  Dashboards for overview and progress

Project lead, planner or director - you see exactly how things stand.

## Who is this for?

Are you active in:

- Civil engineering
- Underground infrastructure
- Cable and pipe work
- Fibre rollout
- Infrastructure with digging crews and temporary projects

And do you want to lose the old systems, the Excels and the paper work-orders? This is the moment to switch to an ERP that actually works. In the cloud. Set up fast. Ready to grow with you. Not sure what a switch would cost? Try the <a href="/pricing/calculator">implementation cost calculator</a> for a first indication.

## What I'd say to that foreman today

That duct-taped mug? I dropped it later that day, when the tape gave up. Broken, naturally. Like the hope that you can move forward on old, broken-down systems.

My message is pretty simple: making metres is good. Keeping a grip is better. And with Odoo that gets a lot easier. Want to see what other companies in <a href="/industries/manufacturing">manufacturing and infrastructure</a> have done with it? Browse the cases.

Curious how [Odoo](/odoo-erp) would work for your civil-engineering business? [Leave your details](/scan) and I'll show you how it works in 20 minutes - no fluff, just straight talk.

---

**Further reading:** [Is your ERP ready for retirement?](/blog/time-to-retire-your-erp) · [Which Odoo modules to choose?](/help/odoo-modules-waar-beginnen) · [How quickly can you go live?](/help/hoe-snel-live)


# Why switching to S/4HANA isn't always the right call - and the best alternatives
URL: https://www.fanatics.nl/blog/sap-s4hana-alternatives
Language: en

SAP users being "nudged" toward S/4HANA face a real decision: move to SAP's new platform, or look for something else. The forced switch usually comes with high cost and a complex implementation, so it pays to explore the alternatives to SAP S/4HANA first. There are several capable ERP solutions - NetSuite, Microsoft Dynamics, Acumatica, Odoo - that are often more flexible and more affordable. Below, the main options on one page.

> Want to go deeper? See the full, honestly scored overview of the [best SAP alternatives](/sap-alternative), the [Odoo vs SAP comparison](/odoo-vs-sap), or - if you are already considering the move - [how a SAP-to-Odoo migration works in practice](/blog/sap-to-odoo-migration).

## What are the alternatives to SAP S/4HANA?

### 1. NetSuite

NetSuite, part of Oracle, is a broad ERP and especially attractive for companies with growth ambitions. The cloud-based system supports inventory, eCommerce and CRM. Customisation and specific adjustments often require consultants, which can drive up cost.

### 2. Microsoft Dynamics 365

Microsoft Dynamics integrates tightly with other Microsoft products, making it a logical choice for organisations already deep in the Microsoft ecosystem. Dynamics 365 covers manufacturing and logistics well, but its complexity and cost make it less suitable for smaller companies. For a direct comparison, see our <a href="/odoo-vs-dynamics">Odoo vs Dynamics 365</a> page.

### 3. Infor CloudSuite

For sector-specific needs (healthcare, retail), Infor CloudSuite can be a good fit. The system offers industry-specific functionality, but implementations can be complex and expensive.

### 4. Acumatica Cloud ERP

Acumatica is a flexible cloud ERP known for its user-friendly interface and scalability. Particularly suitable for mid-sized businesses wanting a complete ERP without tying themselves to a giant software vendor. Acumatica is flexible and broadly useful, but in cost-efficiency and module catalogue it isn't always competitive with Odoo.

### 5. Odoo

[Odoo](/odoo-erp) earns a special spot among the alternatives because it goes beyond classic ERP. Alongside financial and operational processes, Odoo offers marketing automation, HR, knowledge management, and even niche apps like rental management and quoting/calculations. At a flat low price of under €40 per user per month, Odoo is also very affordable.

## Why Odoo goes beyond classic ERP

Odoo isn't limited to the usual ERP functions; it offers a complete ecosystem to support your business without extra software. Think modules for:

- **Marketing** - campaigns and social media;
- **HR and payroll** - recruitment, onboarding, salary admin;
- **Knowledge management** - integrated knowledgebase;
- **Rental management** - rental contracts and stock tracking;
- **Order-driven manufacturing and quotations** - essential for production businesses and project work.

With Odoo you have an all-in-one platform that scales your business without buying or integrating extra software.

## Customer example: Keizer International

One of our clients, Keizer International, went looking for a new system after their earlier SAP implementation didn't go entirely to plan - and SAP wanted to push them to S/4HANA. During their search they discovered Odoo and were quickly convinced by its usability and breadth. With Odoo they'll soon manage not only eCommerce, inventory and CRM but also accounting and HR - at a flat per-user price. The switch led to significantly lower IT cost and a faster operation.

## See whether Odoo is the right alternative for your move

Curious whether [Odoo](/odoo-erp) is the right alternative to S/4HANA for your business? Use the <a href="/pricing/calculator">implementation cost calculator</a> for a first estimate, or [book a no-obligation intro](/scan) where we map your needs and estimate the cost of a switch directly. So you know exactly where you stand - no surprises.

---

**Further reading:** [The best SAP alternatives, honestly scored](/sap-alternative) · [From SAP to Odoo: what a migration looks like](/blog/sap-to-odoo-migration) · [Odoo vs SAP](/odoo-vs-sap) · [What does Odoo cost?](/help/wat-kost-odoo)


# G.O.D. (Getting Odoo Done) - a success formula for Odoo implementations, with a smile
URL: https://www.fanatics.nl/blog/getting-odoo-done-en
Language: en

import Checklist from '~/components/blog/Checklist.astro'

For many entrepreneurs, implementing [software](/odoo-erp) is a bit like trying to assemble a motor using only an IKEA manual. You get pretty far on common sense, but it can definitely go faster and smoother. Most businesses are already busy enough with day-to-day work - and an ERP implementation usually isn't their core business.

We all know the Dutch tax office's famous slogan: "We can't make it more fun, but we can make it easier." Honestly? I think we can make it both more fun **and** easier. That's where **G.O.D.** comes in: **Getting Odoo Done**. No spiritual revelations, no magic - just a pragmatic approach to running your Odoo implementation smoothly and effectively. And if you want it done quickly and well, it helps to have a method that works. We've found that method.

<Checklist title="Getting Odoo Done in 3 steps" items={[
  'Good listening, not over-analysing',
  'Optimise and explore',
  'Do it, step by step',
]} />

## Getting Odoo Done in practice

G.O.D. is built on three simple but powerful principles. No endless reports or complicated analyses - just do what needs doing:

### 1. **G**ood listening, not over-analysing

Many software partners start with long analyses and complex process models. Not us. We listen first to what you actually need, then work toward that goal point by point. No thick reports - just action items you can run with immediately.

### 2. **O**ptimise and explore

Before implementing something new, we look together at which processes you want to keep and which can be improved. What works well, what can be better? With a clear overview and concrete choices we build a solid base for success.

### 3. **D**o it!

Odoo offers endless possibilities, but if you stay stuck in plans and theories, you get nowhere. At G.O.D. we believe in just-do-it. No endless planning, just step-by-step results.

## Getting Odoo Done with our TARGET method

You may have heard of our [TARGET method](/target) for project management. It's ideal when you want full control over every aspect of your project - from risk management to task monitoring. For many companies this part of **Getting Odoo Done** is exactly what they need: a quick, light approach that delivers results without complexity.

## Ready for G.O.D.?

At Radical FANATICS we're fanatical about one thing: making your Odoo implementation successful. No thick reports, no bureaucratic overhead - just do what needs doing. With **Getting Odoo Done** we make sure your ERP doesn't just get implemented, but actually works for you straight away. Wondering what an implementation typically costs? Use the <a href="/pricing/calculator">implementation cost calculator</a> to get an instant estimate. Or browse our <a href="/cases">client cases</a> to see how other companies made the switch.

Want to know more about how we apply **Getting Odoo Done**? [Get in touch](/contact) and discover how simple and effective a successful [Odoo implementation](/odoo-erp) can be.

---

**Further reading:** [The TARGET method](/target) · [I hate project management](/blog/i-hate-project-management) · [Start a free scan](/scan)


# Why people with an ownership mindset are indispensable in SMB
URL: https://www.fanatics.nl/blog/ownership-mindset-in-smb
Language: en

I wish there were more people with an ownership mindset. People you can hand something to, and they immediately start thinking: *How can I tackle this? What are the options?* You recognise them straight away. Every company has a few. People who take responsibility without being told what to do. They look at a challenge and say: *I'll fix this.* Looking for evidence that this mindset delivers results? Browse our <a href="/cases">client cases</a>.

Just as quickly you recognise people with an employee mindset. They look at the same situation and think: *Not my problem.* Or worse: they wait for someone else to solve it. The gap between the two mindsets isn't just big - it shapes the success of a company.

## First do, then ask for help

Recently I gave a project to a colleague I always trust. The project didn't go as planned - setbacks. But instead of standing back and waiting for me to solve it, he started thinking right away: *What can I do right now to get this back on track?*

He talked to the client, looked for ways to adjust the planning, and when he finally needed help, he didn't come with a problem - he came with options. *Here's what I see we can do,* he said. *Which one should we go with to save the project?*

To someone with an ownership mindset, you don't have to explain anything. They see a problem and act on it. They're indispensable in SMB.

## What's my role in this?

People with an ownership mindset always ask themselves: *What's my role in this?* They don't wait for someone else to come up with a solution. In many SMB companies projects stall because people keep pointing at external factors: *We don't have enough time. We don't have the right resources.*

But people with an ownership mindset don't think in constraints. They think in possibilities. They look at *what they can do*. And when they need help, they ask only after weighing all the options. Not because they want to do it alone - because they know it's their responsibility to take action first.

## Don't wait, act

You see it in the small things too. Imagine walking into the office and seeing a pile of mail on the floor by the door. It would be easy to step over it. You might even pretend you didn't see it - it isn't your task, after all. But someone with an ownership mindset thinks differently. They stop, pick it up, take it to reception.

It's not about the mail - it's about the attitude. People with an ownership mindset act instinctively. They see something that can be better and take responsibility, even if it isn't their task. They're the people who don't wait to be asked. They just do it. And exactly that is what makes them so important in a company.

## Weighing options and backing decisions

It's not only the action that characterises an ownership mindset, but also how they act. They don't make rushed decisions. They always weigh the options first. They think about the consequences of each choice, and only then do they act. And when they ask for help, they don't bring a vague problem. They bring concrete proposals. *I've tried this; here are the next steps we could take.*

## Personal satisfaction through ownership

The beautiful thing about this mindset is that it's not only good for the company - it's good for the person too. When you take ownership, you feel stronger, more confident. You know you have control over what happens around you, and that brings calm. I see it again and again in people with an ownership mindset. They're not only more effective, they're happier too. They don't have to wait - they act. And that brings satisfaction.

## Ownership in SMB: a key to success

SMBs need people with an ownership mindset. People who take initiative, carry responsibility, and aren't afraid to come up with solutions themselves. They're the engine of the company - the people who make sure everything keeps running, even when things get hard.

Whether it's a project on the verge of stalling, an unhappy customer, or a pile of mail on the floor - it's the people with an ownership mindset who make the difference. They create not only success on the work floor but also a sense of control and personal satisfaction. And in the end, that's what it's all about. That's also the spirit behind our <a href="/target">TARGET method</a> - and behind the <a href="/team">people who run it</a>.

---

**Further reading:** [I hate project management - and how I invented the TARGET method](/blog/i-hate-project-management) · [Expert meetings: an expert on hand when you need one](/blog/expert-meetings-en) · [Our method: TARGET](/target)


# I hate project management
URL: https://www.fanatics.nl/blog/i-hate-project-management
Language: en

*And that's how I invented the TARGET method.*

Project management. A word I'd happily walk around in a wide arc. As much as I'd like to feel differently about it, it sticks to me like an unpleasant smell that won't go away. From that first school project, long ago, I knew: this isn't for me. And honestly, that hasn't changed.

It might sound strange coming from someone who's spent the last 25 years doing nothing but project-based [software implementations](/odoo-erp) in SMB. But the moment I hear the words "project management", I get the same feeling my cat Mickey gets when a strange cat enters the garden: every hair on end. A deep, ancient resistance rises up, as if every fibre of my body is shouting at me to stay away from that world of jargon and templates.

*Timeboxing. Agile. Leverage. Touchbase. Steering committees. Alignment. Hybrid steering.* It's one big bullshit-bingo game. The moment I open a project-management book, I feel a tiredness that even the strongest coffee can't shake. One chapter and I'm either asleep, or my thoughts have drifted to things that actually matter. A bit like daydreaming in a mandatory meeting - you're there, but you're not.

No, I don't just hate it - I don't believe in it. To me it mostly looks like a system inflated to keep an entire profession busy with expensive words and hollow terms. Especially in SMB, we speak a different language. We don't have time for jargon or convoluted processes. And yet - here comes the paradox - at Radical Fanatics we run about thirty significant IT projects a year, and oddly enough… they mostly go well. Without the trappings of traditional project management. Without certified scrum masters. You can see the results in our <a href="/cases">client cases</a>.

How is that possible?

After 25 years of projects - some more successful than others - I took a hard look at what actually works. And yes, there were recurring elements. Always. Six things, simple but effective:

1. Top-management involvement
2. A [Quick scan](/scan) before you begin
3. Prioritising the risky parts
4. Weekly meetings, no longer than 30 minutes
5. [An expert on hand when you need one](/blog/expert-meetings-en)
6. [A simple system to track progress](/blog/keeping-projects-on-track)

On these six points I built the **[TARGET method](/target)**. No hocus pocus. No complex templates. Just a workable approach anyone can understand. Even if you're not a trained project manager, you can run it alongside your normal work.

It's time more companies - not just us - start using these insights. Out with the chaos, out with the intruders who disturb your work day. Let everyone work in peace, like my cat Mickey sleeping in the sun - no fuss, no worries. That's how it can be. Want to find out quickly whether this approach fits your situation? Start with a <a href="/quickscan">free quickscan</a>.


# Keeping projects on track: how to avoid surprises
URL: https://www.fanatics.nl/blog/keeping-projects-on-track
Language: en

In every project there comes a point when you wonder: "Are we still on track?" Without clear visibility on progress, even the best-planned project can run into trouble. That's where oversight becomes essential. It may sound like dull admin work, but it's the backbone of every successful project. Without task tracking you risk losing sight of the goals you set in the analysis phase.

## Why task tracking matters

The goals you set in the analysis phase form the blueprint of your project. They're based on a thorough fit-gap analysis where you've established exactly what you want to keep and what needs improvement. But having those goals is one thing - actually reaching them is another. That's where oversight comes in.

Oversight means continuously monitoring the project's progress to make sure you stay on schedule. It's about looking not only at what's been achieved, but also at what still needs to happen and whether you're still on course to hit your original goals. Without oversight, small problems can go unnoticed until they grow into big obstacles that threaten the project.

## How task tracking helps you hit project goals

Oversight isn't just registering what happens; it's an active role in monitoring progress and steering where needed. Here are some ways oversight helps you reach your project goals:

1. **Early detection of issues.** Regular oversight lets you spot trouble fast. Whether it's missed deadlines, budget overruns or technical complications, intervening early prevents escalation.

2. **Focus on the analysis-phase goals.** Oversight keeps you returning to the goals set in the analysis phase. It helps you check that the actions you're taking are still aligned with what you originally identified as priorities.

3. **Effective adjustments.** Oversight gives you the data and insight to steer at the right moment. When you see parts of the project drifting, you can act in time to get back on course.

4. **Transparency and accountability.** Regular reports and feedback to the team and stakeholders create transparency. Everyone knows where the project stands, what's going well and where attention is needed.

## Linking back to earlier phases: task tracking and the TARGET method

Oversight isn't a stand-alone activity; it links directly back to earlier phases, especially the analysis phase. The goals set there are the yardstick for project success. Without them, oversight would be meaningless - you wouldn't know what you're working towards.

In the analysis phase you've decided what to achieve: which processes to keep, which to improve, which risks to prioritise. Those goals form the basis of your oversight strategy. Regularly evaluating progress against them keeps the project on course.

What's more - discussing progress during scheduled check-ins (another crucial part of the [TARGET method](/target)) lets you adjust in time and keep the analysis-phase goals always in view. And when the team hits a specific knowledge gap, [expert meetings](/blog/expert-meetings-en) are the right tool to break through.

## Project-management tools for effective oversight

To exercise oversight effectively, you need the right tools - tools that give you insight into progress and let you adjust quickly when needed.

1. **[Odoo ERP](/odoo-erp).** If you use an ERP system like Odoo, you can integrate project-management modules that specifically target progress tracking. Odoo offers tools for task management, planning, milestones and reporting, giving you real-time insight into project status.

2. **Excel.** For smaller projects or if you don't have advanced PM software, Excel can be a great alternative. A simple progress monitor in Excel helps you keep tabs on task status, deadlines and responsibilities.

3. **Trello and other visual tools.** Visual PM tools like Trello can also be hugely useful for monitoring progress. Boards, cards and lists make it easy to organise tasks and follow status.

Whether you use a comprehensive system like Odoo or a simple tool like Excel - the most important thing is consistent oversight. Tools provide structure, but the discipline of monitoring and adjusting regularly is the real key to success.

## Conclusion

Oversight is the connecting thread that keeps a project from derailing. It helps you keep your goals sharp, spot problems early and adjust effectively. Without oversight you risk making the goals from the analysis phase unreachable. See how our clients handle this in practice - browse the <a href="/cases">client cases</a>.

With tools like Odoo ERP, Excel or visual aids like Trello, monitoring becomes straightforward. In the [TARGET method](/target), oversight is the phase that brings together all the work from earlier phases and ensures everything stays aligned with the original goals.

So keep oversight on your projects - not as an obligation, but as a strategy to hit your goals and bring the project to a successful close. Not yet started? A <a href="/quickscan">free quickscan</a> is the first step toward a well-managed implementation.

---

**Further reading:** [How expert meetings solve the toughest project problems](/blog/expert-meetings-en) · [The TARGET method explained](/target) · [Start a free Odoo scan](/scan)


# Want fast progress? Here's how expert meetings solve the biggest project problems
URL: https://www.fanatics.nl/blog/expert-meetings-en
Language: en

Know the feeling? You're deep in a project. Things look fine, until you hit a point where you simply lack the knowledge. It often surfaces during the [planned check-ins](/blog/keeping-projects-on-track).

That's the moment for an *expert meeting*. You bring the right people together - technical experts, or people with deeper experience and process knowledge from departments like HR or Production. You focus on a specific question and find the answer that moves you forward. It's not a broad discussion - it's a session where a small team with focus and expertise resolves one bottleneck. In the projects I run, this happens regularly. It's a prerequisite for getting a project to a good outcome.

## What is an expert meeting?

As the name suggests, an expert meeting is a gathering of a small professional team focused on one specific question or challenge within a project. Unlike general project meetings - which review progress and tackle daily issues - expert meetings exist to dig deeper and solve harder problems.

Expert meetings aren't only for technical challenges. They often hinge on substantive knowledge from a specific department or role - HR, production, marketing. Those people may not be technical, but their deep knowledge of processes, regulations or customers makes them indispensable for finding solutions that are not only technically feasible but also operationally effective.

For example: you're mid-[ERP implementation](/odoo-erp) and run into a problem that specifically affects HR processes. The technical side looks fine, but the new workflow doesn't match how the organisation registers and manages its employees. Here you organise an expert meeting with the HR manager, who knows exactly which processes are essential and which bottlenecks need solving. This makes sure the system actually fits the business needs - instead of just functioning correctly from a technical standpoint.

## When do you use an expert meeting?

The first expert meetings actually happen during the [fit-gap analysis](/scan). In many cases the employees with the most knowledge of a given process will join. In my experience, expert meetings during implementation are typically scheduled when:

1. **A specific technical problem needs solving.** Complex integrations, customisations, configuration issues.
2. **Deep process knowledge is required.** Sometimes expertise must come from people who know the process inside out - department heads or external experts.
3. **Operational changes need to be made.** When you're rolling out a new workflow for HR or production, you need the knowledge of the experts who do this daily.

The goal of the expert meeting isn't to meet endlessly, but to give focused, efficient depth to the most complex or process-oriented challenges a project can face.

## The benefits of an expert meeting

**1. Focus on a single problem.** Where general project meetings cover multiple topics, an expert meeting focuses on one - technical, process or operational. That gives you maximum concentration and speed in finding answers.

**2. The right people are involved.** Only the people with the right expertise - technical specialists, or people with substantive knowledge from HR, marketing or production. This prevents unnecessary opinions from muddying the discussion.

**3. Decision speed.** With the experts in one room, decisions get made on the spot. That avoids the delays of long decision processes or back-and-forth between departments.

**4. Quality of the solution.** Bringing the right people together means the solution works not only technically but also fits the operational needs of the organisation.

## Example: an HR expert meeting during an ERP implementation

Take a specific example. You're implementing a new system that will manage all employee data and leave requests. Technically the system looks fine, but when you bring in the HR manager you discover it doesn't account for certain local laws around leave rights. Plus it misses important features for managing employee files and tracking trainings and certifications.

This is the moment for an expert meeting with the HR manager. The session ensures that the system meets not only technical requirements but also the organisation's operational needs.

Thanks to this expert meeting, the system aligns with what the HR department actually needs - without costly adjustments after the system is already live.

## Expert meetings as a source of success

In my experience, expert meetings are often the turning point of a project. Whether it's a technical challenge or a process bottleneck, these focused sessions with the right experts can make the difference between a project that stays stuck and one that breaks through to success. Curious how this plays out in practice? Take a look at our <a href="/cases">client cases</a>.

## Conclusion

Expert meetings are an essential part of the [TARGET method](/target) and can make the difference at any point during a project. By bringing together a small specialised team to focus on one challenge, you prevent the project from getting stuck on technical, process or operational issues.

So when your project hits complex problems, get the experts together - technical or operational - and run a focused expert meeting to get the project back on track. Not yet sure whether your organisation is ready for an implementation? A <a href="/quickscan">free quickscan</a> is a good first step.

---

**Further reading:** [Keeping projects on track](/blog/keeping-projects-on-track) · [I hate project management - and how I built the TARGET method](/blog/i-hate-project-management) · [The TARGET method explained](/target)


# Without a thorough analysis, forget it: how a fit-gap analysis saves your project
URL: https://www.fanatics.nl/blog/fit-gap-analysis
Language: en

Every director or senior manager knows the feeling: you are about to start an important IT project, but something is nagging. Will this project actually hit the goals we have in mind? Or will we drift, after months of hard work and a serious budget, towards a result nobody really wants? Often the problem is not in the execution but at the start of the project, and more specifically in a lack of thorough analysis. Put simply: if you do not know where you stand and where you want to go, you have no steering. A good analysis prevents exactly that.

## What is a fit-gap analysis and why does it matter?

The fit-gap analysis is a simple but powerful method for making sure your project team and the rest of the organisation fully understand what is needed to finish a project successfully. In a fit-gap analysis you look at where you stand today (the fit) and where the gaps sit in the processes and systems that need improving (the gap). By mapping this thoroughly, you make sure your project does not waste time and resources solving the wrong problems.

In my years of experience with software implementations and IT projects in mid-sized companies, I have seen that projects without a fit-gap analysis have a far greater chance of going wrong. They overrun on cost, deadlines slip, and the resulting system often turns out not to match what the business actually needs. Those are expensive mistakes you can avoid by investing time up front in a thorough fit-gap analysis. And no, this does not have to take months or cost tens of thousands. A focused, pragmatic approach is usually more than enough to get clear on what you need, without eating your project budget.

## The benefits of a fit-gap analysis

What you often see, especially in mid-sized companies, is that time and budget are not always set aside for a proper analysis phase. That comes partly from the idea that "we will work it out as we go", or that the cost of the analysis does not justify the immediate savings. In reality the opposite is true. A thorough analysis saves money over the longer run by preventing expensive rework and making sure your project is on the right track from the start.

**Three crucial benefits of a fit-gap analysis:**

- **Clarity on the scope of the project:** A fit-gap analysis gives you clarity on what exactly has to happen. It helps you understand your existing processes and decide which should be kept and which should be improved or replaced. That stops you being pulled off course by less important matters and keeps everyone in the project team focused on the right goals.
- **Involvement across the organisation:** During the fit-gap analysis you bring in different departments and employees. That makes people feel heard and creates a shared understanding of what the project is trying to achieve. Involving employees early also makes them far more willing to embrace change once the system is rolled out.
- **Preventing surprises during implementation:** A fit-gap analysis helps you spot potential problems early. That stops you discovering halfway through the project that something is fundamentally wrong with your plans. By mapping the gaps and risks up front, you can adjust in time instead of letting the project get into trouble.

## How do you approach a fit-gap analysis?

A fit-gap analysis does not have to be a time-consuming process, but it does need to be done carefully. Here is my approach, which works well in practice for mid-sized companies:

- **Identify your current processes:** Start with an overview of your existing processes. That does not mean describing every step in detail, but you do need to be clear on the main elements of how you work today. Think of core processes such as production, logistics, sales and finance.
- **Determine what works and what needs to improve:** Then go through your processes point by point and establish what works well and what needs improving. This is the moment to involve every department and every employee. They often surface bottlenecks and improvements you would otherwise miss entirely.
- **Document your findings in a fit-gap spreadsheet:** Rather than producing a thick report, I recommend documenting your findings simply in a spreadsheet. In it you record which wishes and requirements exist, which fit inside the standard process of the intended software, and which need configuration or custom work. That gives you a clear view of the project scope and makes sure you have concrete goals from the start.
- **Decide which solutions close the gaps:** Once the gaps are clear, you can look at solutions. Does it fit inside the standard software, or is custom work needed? Sometimes it also means changing processes to fit the new system, which is often a better solution than building everything bespoke.

## Why you should never skip the analysis phase

Skipping the analysis phase is like setting off on a journey blind, without knowing where you are going or what you need along the way. It looks like it saves time, but it brings far more risk with it.

Every time I have guided a project where the analysis was not done thoroughly, I saw the same patterns: deadlines missed, costs climbing, and a final result that did not meet expectations. Those are the projects that fail, not because the team is not working hard enough, but because the foundation is missing.

Contrary to what some people think, a thorough fit-gap analysis does not cost unnecessary time or money. On the contrary, it stops you wasting time and money later in the project on problems you could have foreseen. It makes your project more agile and lets your team start the implementation with confidence, because they know exactly what they have to do.

## Conclusion

A fit-gap analysis is an essential step in any IT project, and particularly in ERP implementations. It gives you the clarity and focus you need to approach the project properly, and it stops you being surprised later by unexpected problems. By taking this analysis seriously, you make sure your project is not only delivered on time and on budget, but actually produces the value you expect.

So if you are starting a large project, take the time for a proper analysis. It is not a step you can skip if you want your project to succeed.

## What is the TARGET method?

The fit-gap analysis does not stand alone. It is the **A** of the [TARGET method](/target), an approach developed by Radical Fanatics across more than 80 projects: six essential steps for successful project management, aimed specifically at mid-sized companies. The acronym stands for:

- **T**op management on board: make sure the leaders of the business take an active part in the project.
- **A**nalysis up front (fit-gap): run a thorough analysis to establish where you stand and what needs improving.
- **R**isk first: identify the biggest risks and tackle those before the easy parts.
- **G**eared check-ins: hold regular, short meetings to track progress and surface problems early.
- **E**xpert sessions: bring the right people together to resolve specific challenges quickly.
- **T**racking: follow project progress closely so that it stays on course.

The TARGET method offers a pragmatic, structured way to run IT and change projects successfully, particularly at mid-sized companies where resources are tighter than at larger organisations. Want to talk through the analysis of your own project? [Get in touch](/contact).


================================================================

CASES

================================================================

# AgrowTeam: why we came back to FANATICS after a year away
URL: https://www.fanatics.nl/cases/agrowteam-en
Language: en

## A relationship built on domain knowledge

AgrowTeam B.V. works at the intersection of agronomy and technology: providing precision agriculture services, crop monitoring, and data-driven advisory to growers across the Netherlands. Their work combines field services, project-based consulting, and the supply of specialist equipment and inputs. It is not a business that fits neatly into a generic ERP template.

FANATICS implemented Odoo for AgrowTeam in 2022. The initial project covered Sales, Inventory, Manufacturing, Project & Timesheets, and Accounting, a relatively lean scope that matched AgrowTeam's size and the maturity of their processes at the time. The go-live went well, and the system was working.

## A year with a different partner

In 2023, AgrowTeam made a decision that many growing companies make: they were approached by a larger Odoo Gold Partner and decided to switch their support and development contract. The new partner was technically capable and well-resourced. What they lacked was familiarity with AgrowTeam's business: the seasonal rhythms of precision agriculture, the way a field service job connects to a multi-month project, the specific way AgrowTeam tracks labor against crop advisory assignments.

Over the following year, the gap between what the system could do and what AgrowTeam needed widened. Requests took longer to resolve because each one required explanation from scratch. Customizations were built that solved the stated problem but created friction elsewhere. The system worked, but it did not work well for this particular business.

## Coming back

AgrowTeam returned to FANATICS in 2025. The first task was a structured review of what had accumulated over the intervening years: configuration drift, customizations that could be replaced with standard Odoo features, and a handful of genuine requirements that had never been properly addressed.

What made the difference, in AgrowTeam's own words, was not a technical skill gap between the two partners; it was the accumulating cost of starting from zero every time. A partner who knows your business, who remembers the decisions made during implementation and why, and who understands the sector you operate in, is worth more than technical capability alone.

## What good partnership looks like

The AgrowTeam case is a useful reference point for any growing company evaluating Odoo partners. The questions that matter most are not about certifications or company size. They are: does this partner understand my industry? Will the same people be available to us next year? And when something breaks, will they know what they are looking at without a two-hour briefing?

FANATICS brought AgrowTeam back onto a clean, well-maintained Odoo setup in 2025. The system now reflects how the business actually operates; and the team who built it are still the team supporting it.

**Read more:** [Odoo for services](/industries/services) · [All cases](/cases)


# Amstelland Electronic: electronics manufacturing and distribution on one Odoo platform
URL: https://www.fanatics.nl/cases/amstelland-electronic-en
Language: en

**Amstelland Electronic** is a Dutch electronics producer and distributor based in Uithoorn. A company that both manufactures and supplies from stock, serving industrial and business customers. That mix of production and distribution needs an integrated system, not two separate tools.

## The challenge

Combining production and distribution makes things harder: for pure distribution an inventory and sales layer is enough, but production requires BOMs, work orders and lead times. Many smaller systems fall on one side or the other. Amstelland wanted one system that handled both.

Accounting also had to fit without double entry. Sales invoices, supplier invoices, stock valuation and VAT returns should flow automatically, not be retyped by hand.

## The approach

We set up Odoo for the full cycle: sales, purchase, inventory, manufacturing, shipping and accounting. One database, one product catalogue, and accounting that moves with what happens in operations.

For production, BOMs and work orders are set up the way the work actually runs, not the way a template method prescribes. Inventory and orders connect to production, so a sale immediately tells you what needs to be made or ordered.

## Result

Since go-live in 2024, Amstelland Electronic runs on one Odoo platform. Sales, production, inventory and finance see the same picture at the same time. What was previously scattered across separate systems and spreadsheets now lives in one environment that moves with the work.

---

**Read more:** [Odoo for manufacturing](/industries/manufacturing) · [Odoo ERP](/odoo-erp) · [All customer cases](/cases)


# Bos Cleaning & Finishing: from Exact Online to one system for manufacturing and warehouse
URL: https://www.fanatics.nl/cases/bos-cleaning-finishing-en
Language: en

**Bos Cleaning & Finishing** has been producing consumables for cleaning and finishing for decades: cutting and gluing based on bills of materials, three quarters make-to-order. Exact Online fell short in several areas; the company compared seriously, also looked at SAP Business One, and chose Odoo.

## The challenge

A warehouse with 1,800 locations only works if pickers do not have to search. Manufacturing runs on customer orders, so sales order, bill of materials, work order and inventory have to line up. And work order planning happened outside the ERP, in vPlan, which had to stay.

## The approach

The kickstart method: fit-gap first, then Sales, Inventory, Manufacturing, Shipping and Accounting. For the warehouse, a strategy with fixed pick locations and overstock locations, with automatic replenishment rules in between and barcode scanning on the floor. vPlan is connected to Odoo via webhooks, so work orders stay in sync in both systems. Smart additions such as order digitisation with OCR and automatic lot and serial numbers make the daily work lighter.

## The result

One system from sales order to packing slip, with a warehouse that replenishes itself and a planning that moves seamlessly with the shop floor. The price lists with volume tiers came along from Exact, the double entry stayed behind.

---

**Read more:** [Odoo for manufacturing](/industries/manufacturing) · [Odoo - vPlan integration](/odoo-vplan-integration) · [All cases](/cases)


# BSS van Paddenburg: from a stalled Odoo implementation to a webshop that runs
URL: https://www.fanatics.nl/cases/bss-van-paddenburg-en
Language: en

**BSS van Paddenburg** has been supplying cleaning products to businesses in and around Amsterdam since 1982. The company had already replaced Visma Mamut with Odoo, but the implementation through another partner disappointed: promised training and documentation never came, and the administration bore the traces.

## The challenge

A small team has no room for a system that half works. The question put to us was simple: take over the environment, turn it into something that works, and keep it manageable for a company with a handful of users.

## The approach

We took over the existing environment into our own clean Odoo.sh setup and cleaned up the financial legacy. Then we expanded step by step at the company's own pace: a webshop with its own catalogue and product variants, prices behind a customer login, payment and shipping methods and a version upgrade. No big project, but a steady partner who helps a little every year.

## The result

Odoo now works for the company instead of against it: one environment for sales, webshop and administration, managed by a partner who picks up the phone. Kept small, exactly as it should be for a company of this size.

---

**Read more:** [Switching Odoo partner](/blog/switching-odoo-partner) · [Odoo for wholesale](/industries/wholesale) · [All cases](/cases)


# Burned Wood: Odoo for complex product variants and price per m² in architectural wood
URL: https://www.fanatics.nl/cases/burned-wood-en
Language: en

**Burned Wood B.V.** processes and sells architectural charred wood, a material that develops a distinctive dark surface and exceptional weather resistance through controlled burning. The technique has Japanese roots (Shou Sugi Ban) and is now widely used in contemporary European architecture: as cladding, flooring, decking and interior finishes for construction and renovation projects.

The product range spans multiple wood species, profiles and finishes. These variants differ significantly in price and are sold almost entirely by surface area. Customers (contractors, architects and project developers) expect tailored quotes in their own language, with a clear price breakdown per m².

## The challenge

Burned Wood was working with separate tools for sales, purchasing, inventory and accounting. The complex product structure (many variants, price per m², international customers) was poorly suited to generic systems. Key pain points were error-prone manual quote entry, translating product attributes for international customers, and the lack of a single view connecting commercial and operational activities.

## The approach

We implemented Odoo in 2023 as a central platform, with custom modules tailored to Burned Wood's product environment.

### Product variants and price per m²

The core of the implementation is the configuration of product variants. Wood species, profile, length and finish are each attributes with their own variant prices. A custom module ensures that attribute values are automatically filled into quote lines: no manual copying required.

The quote displays the price per m², both on the interactive online quote and on the PDF version. Attribute values or prices that are zero are automatically hidden, keeping every quote clean and readable for the customer.

### Multilingual quotes

Burned Wood works with customers across multiple countries. When a quote is prepared in English, the attribute names in the product description must appear in the correct language too. A custom module ensures that translated fields are automatically carried over from the quote template to the final quote, without manual adjustment per customer.

### Web forms as lead intake

Project enquiries through the website are captured via a web form that lands directly in Odoo as a CRM lead. This keeps the entire sales process in one system, with no separate inboxes or manual data entry.

### Manufacturing roll-out

The initial implementation focused on commercial and logistical processes. In 2025, Burned Wood started extending into the Manufacturing module, enabling internal production orders to be managed from Odoo as well. This closes the full chain: from raw material purchasing through production to delivery and invoicing.

## Results

Burned Wood operates from a single platform across their entire business. Variant configuration and m² pricing give sales staff an accurate, professional quote instantly. Multilingual output is automated. Leads from the website flow directly into CRM. And with the Manufacturing module rolling out, the full value chain is managed from Odoo.

---

**Read more:** [Odoo for manufacturing](/industries/manufacturing) · [All cases](/cases)


# Color Control Group: Advanced Approval module backport to Odoo v17
URL: https://www.fanatics.nl/cases/color-control-group-en
Language: en

**Color Control Group** specialises in colour management for the print and production industry. They were already running Odoo actively for their own business operations and wanted to extend their approval workflows. Specifically, they came to us for our **FANATICS Advanced Approval module**, which we built on Odoo v19.

## The challenge

Standard Odoo has a limited approval system. For an organisation where multiple people have to assess something in sequence (think purchase orders above a certain amount, or contracts with multiple stakeholders), that's often not enough. An approval flow that accounts for roles, amounts, escalation rules and parallel approvals is a niche requirement that standard Odoo doesn't cover.

We had already built such a module, but on Odoo v19. Color Control runs on v17. The brief was to make the module usable in their existing environment without forcing them into an upgrade they weren't yet ready for.

## The approach

The project was tightly scoped in three phases:

1. **Analysis and backporting**: the v19 module was technically analysed and adapted to v17 APIs, model structures and views.
2. **Testing**: the revised v17 module was tested against realistic approval scenarios as Color Control knows them.
3. **Final delivery and support**: delivery including documentation and an ongoing support agreement, so updates to the module reach v17 as well.

The module is licensed for up to 25 approvers, with a fixed monthly support and upgrade fee.

## Result

Color Control can now operate within their existing v17 environment with approval workflows of the kind a larger organisation should have: multi-step, role-based escalation, amount thresholds. No upgrade pressure, no architectural intervention, just the piece of functionality that was missing.

This kind of work is characteristic of how we also collaborate with existing Odoo customers of other partners: deliver a targeted module or integration on the version they're running, rather than forcing a full reset.

---

**Read more:** [Odoo custom development](/odoo-custom-development) · [Our modules](/odoo-modules/supplier-invoice-approval) · [All customer cases](/cases)


# C&S Benelux: Odoo rescued from a failed implementation, from frustration to foundation
URL: https://www.fanatics.nl/cases/cs-benelux-en
Language: en

**C&S Benelux** buys in, assembles and sells under its own product number. The company was already running on Odoo, but was unhappy with the previous partner's implementation. The reports did not add up, and the question on the table was serious: back to a separate accounting package?

## The challenge

Whoever inherits a bad Odoo implementation does not immediately see where things go wrong. Dropshipments and returns were cumbersome, stock bookings and corrections took too many steps, general ledger and inventory valuation contradicted each other and the margins were inexplicable. On top of that: seventeen custom modules from the previous partner, without documentation.

## The approach

No big promises up front, but first a Quick Scan of the existing environment: screen recordings, fit-gap questionnaires and an honest verdict on what could be saved. Then the clean-up: general ledger and inventory valuation corrected, BOM cost prices untangled, dropship discrepancies resolved. The inherited custom work was assessed and the upgrade path to the latest Odoo version mapped out.

## The result

C&S Benelux stayed on Odoo, but now on a foundation that works: explainable margins, a general ledger that reconciles with inventory and a system that is ready for the next version instead of being stuck in the past.

---

**Read more:** [Switching Odoo partner](/blog/switching-odoo-partner) · [Odoo ERP](/odoo-erp) · [All cases](/cases)


# De Vreede Techniek: Odoo for operations, Twinfield for accounting
URL: https://www.fanatics.nl/cases/de-vreede-techniek-en
Language: en

**De Vreede Techniek** is a family-run technical services firm in Waddinxveen serving business clients. A team that works in the field, plans assignments, orders materials and invoices after delivery. For that kind of operation, a workable CRM, planning and project administration matters more than a deep accounting module. The accountant has Twinfield for that.

## The challenge

De Vreede has used Twinfield for accounting for years. It works, their accountant knows it, and year-end runs smoothly. But Twinfield is not an ERP. Sales, project planning, inventory and time tracking lived in separate spreadsheets and emails. That made it hard to see what was running, how many hours were booked per assignment, and which materials were still on order.

The request was straightforward: build a working operational layer without losing Twinfield. The accountant should be able to keep doing his job.

## The approach

We set up Odoo for the full operational cycle: CRM, sales, projects, inventory, purchase and field service. Anything to do with customers, assignments and execution lives in one database. Once an assignment is completed and invoiced, the invoice is automatically forwarded to Twinfield through the [Odoo-Twinfield integration](/odoo-twinfield-integration), so the accountant doesn't have to retype.

The biggest win is visibility. Anetta, Jasper and Ryan see in one place what's open, who's working on it, what's ordered and what's still to be invoiced. No more loose spreadsheets, no more emails to find something back.

## Result

De Vreede runs operations in Odoo, accounting in Twinfield, and has no overlap between the two. Since the initial implementation in 2023 there have been multiple expansions, stacked on what's already there. A setup that fits how a family business works: practical, building on what runs, not everything at once.

---

**Read more:** [Odoo - Twinfield integration](/odoo-twinfield-integration) · [Odoo for manufacturing](/industries/manufacturing) · [All customer cases](/cases)


# Decilux AV Sales: AV distribution with one central Odoo system
URL: https://www.fanatics.nl/cases/decilux-av-sales-en
Language: en

**Decilux AV Sales** distributes audiovisual equipment from Hengelo to installers, integrators and business end-users. Importing, holding stock, watching margins and delivering on time: typical wholesale dynamics with a specific niche focus on AV.

## The challenge

For an AV distributor, everything turns on stock availability and fast quoting. A customer scheduled to install on a given date can't wait a week for a price indication or a delivery confirmation. Decilux worked with tools that each handled part of the picture, but none gave a full view of what was on stock, what was in the pipeline and what was already out the door.

Decilux also wanted to accommodate growth without buying additional separate software every time. One platform that grows with them, not a patchwork that expands year over year.

## The approach

We set up Odoo as the central sales and inventory layer, connected to purchasing, eCommerce and accounting. CRM opportunities flow to quotes; quotes flow to orders; orders reserve stock; stock orders connect to purchase orders; everything lands in the same accounting.

For the team in Hengelo, a customer question can now be answered from one screen: what do we have, what does it cost, when can we deliver.

## Result

Since the 2025 implementation, Decilux works from one system for sales, inventory, purchasing and finance. Frank, Luuk and Sander see the same picture without having to ask around. The next step is building on what's there, eCommerce for dealers and richer reporting, on top of a foundation that's already running.

---

**Read more:** [Odoo for wholesale](/industries/wholesale) · [Odoo ERP](/odoo-erp) · [All customer cases](/cases)


# Decoflorall: from Logic4 to Odoo - 27,000 articles, webshop and warehouse live in two months
URL: https://www.fanatics.nl/cases/decoflorall-en
Language: en

import StatRow from '~/components/blog/StatRow.astro'

**Decoflorall VOF**, based in Zierikzee, supplies floral-arranging materials and seeds to bulk buyers and consumers. The webshop is the heart of the business: over 27,000 articles, around 300 orders a week on average, and two types of customer who each see their own prices.

Until 2025 that ran on Logic4. When the licence was cancelled and ran out, there was a hard deadline: a new system that ties webshop, inventory and accounting together, and goes live well before the busy autumn season.

<StatRow eyebrow="Decoflorall in numbers" stats={[
  { num: '27,000', label: 'articles migrated' },
  { num: '2 months', label: 'to webshop and warehouse live' },
  { num: 'Logic4', label: 'to Odoo in one move' },
]} />

## The challenge

Decoflorall wasn't looking for a standalone webshop package with separate accounting beside it. They wanted one system in which an order flows straight through to inventory, picking and invoice. The bar was high on three points.

Inventory first. With 27,000 articles, product variants, composite items and deliberate negative stock on fictitious locations, the inventory model had to be right before anything else could build on it. On top of that, two price lists - business and consumer - that automatically show the correct rate, in the back end and in the webshop. And finally, time: the Logic4 licence was expiring, so the switch had to be fast and without a gap in sales.

## The approach

We started with a fit-gap analysis: per process - purchasing, inventory, sales, webshop, accounting - establishing what standard Odoo already does and where configuration or customization is needed. We then set up the modules in phases on Odoo Enterprise, with a separate test environment alongside the live environment on Odoo.sh.

### Data migration from Logic4

We pulled the full article master - over 27,000 products with variants, internal references, supplier data and images - out of Logic4 and imported it into Odoo in a structured way. Supplier prices and stock came across partly via the Logic4 API, so purchase prices were correct from day one.

### Inventory, variants and warehouse

The warehouse runs on location management with barcode scanning and batch picking. We handled negative stock with fictitious locations, so sales don't stall when an article reads zero on paper. Min-max levels replenish stock automatically based on sales, and products with multiple suppliers automatically pick the right purchasing source.

### Purchasing with multiple suppliers

Purchasing is built around supplier price lists for tens of thousands of products, with prices adjustable per order line. A warning on purchase and sales orders flags anomalies before they go out the door.

### Sales, price lists and webshop

The Odoo webshop serves both customer groups from one catalogue: business buyers and consumers each see their own price list, with a loyalty programme on top. Product pages, variant filters and the search function are tuned for findability, including schema markup and a Google Search Console connection for SEO.

### Shipping via a direct carrier integration

Instead of an intermediate layer like SendCloud, Odoo connects directly to Decoflorall's own carrier API. From the delivery order, labels and track-and-trace run straight to the carrier.

### Dutch accounting and payments

Accounting runs entirely in Odoo, on the Dutch fiscal localization. EU deliveries automatically get 0% VAT after a VAT-number check, bank transactions are reconciled via a bank feed, and webshop payments via Mollie run through a suspense account that ties out cleanly. Invoicing is set to "invoice what's delivered", which keeps cash flow predictable.

## Results

In roughly two months, the full configuration and go-live of inventory, logistics and webshop were in place. Decoflorall has since run the entire operation - from purchasing to picking to invoice - from one Odoo platform, with the webshop and the warehouse connected in real time. The switch from Logic4 was done before the busy autumn.

---

**Read more:** [Odoo for e-commerce](/industries/ecommerce) · [All cases](/cases)


# Fine Wine Club & Co.: a new wine club, on Odoo from the first bottle
URL: https://www.fanatics.nl/cases/fine-wine-club-en
Language: en

**Fine Wine Club & Co.** is Louis Arts's new fine wine venture: a club for enthusiasts and a trade business for professional buyers at the same time. No legacy system, but a clear bar: from the very first bottle, inventory, sales and accounting have to be right.

## The challenge

A wine club does not sell like a regular webshop. Club members and trade customers order from the same assortment, but at different prices and conditions. Wine lives by vintage, so every bottle must be traceable per year. Minimum quantities and packaging rules apply, delivery runs on fixed days in the club's own region, and tastings and events are part of the club feeling: publicly visible, but registration is for members.

## The approach

Following our kickstart method: fit-gap first, then the core processes. One webshop for both customer groups, with price lists making the difference between member and trade. Products set up per vintage, with packaging rules for minimum quantities. Shipping via SendCloud alongside own delivery on fixed days per postcode area. And deliberately train-the-trainer: in workshops with our consultants, Louis configured large parts of the system himself, so the knowledge lives in the company, not with us. The club model got its own twist: membership is free, and whoever refers a friend who places an order automatically becomes a Gold Member with extra benefits.

## The result

Fine Wine Club & Co. runs on one system from day one: webshop, vintage-level inventory, delivery and accounting in the same environment. The founder manages products, prices and pages himself, and the platform scales from club to trade without a second package.

---

**Read more:** [Odoo for eCommerce](/industries/ecommerce) · [Odoo ERP](/odoo-erp) · [All cases](/cases)


# FritsJurgens: from niche world brand to integrated manufacturing and dealer portal
URL: https://www.fanatics.nl/cases/fritsjurgens-en
Language: en

## A global niche product

FritsJurgens B.V. is a Dutch manufacturer with a genuinely global reputation in a remarkably narrow niche: floor pivot hinge systems for heavy, oversized, and architecturally significant doors. Their systems are used in airports, museums, premium office towers, and luxury residential projects around the world, installed invisibly into the floor, carrying doors that can weigh hundreds of kilograms, with no visible hardware.

The product is technically sophisticated and commercially complex. FritsJurgens sells through an international network of specialist dealers and architectural hardware distributors. Each dealer has their own article numbering system, their own credit terms, and their own ordering patterns. Before Odoo, managing this network required significant manual coordination across multiple systems.

## The dealer ordering challenge

One of the defining requirements of the FritsJurgens project was the **Product Customer Code** module. Dealers do not order using FritsJurgens' internal SKUs. They use their own article codes, which differ by country and by dealer. The module creates a mapping layer: when a dealer places an order using their own code, Odoo automatically resolves it to the correct internal product and variant. The dealer sees their familiar codes; the warehouse and production team see the internal references.

This seemingly straightforward requirement has significant downstream benefits. Order processing is faster, error rates drop, and dealers can place orders without needing to translate between numbering systems.

## Atradius credit limit integration

FritsJurgens extends trade credit to its dealer network, with credit limits managed through **Atradius**, the credit insurance and risk management platform. FANATICS built a real-time integration between Odoo and Atradius: when a dealer order is confirmed, Odoo checks the dealer's current credit exposure against their Atradius-approved limit. Orders that would breach the limit are flagged for review before they enter the production queue.

This automated credit check removes a manual step from the order processing workflow and ensures that the commercial team is alerted to credit risk before goods are committed to production, not after they have been shipped.

## Production and shipping

The Manufacturing module handles production planning for FritsJurgens' pivot systems, which are assembled from precision-machined components. Bills of materials are structured to reflect the various product families and size ranges. The Shipping module integrates with carrier services for international dispatch, with export documentation generated directly from Odoo.

The eCommerce module was deployed as a dealer portal rather than a public shop. Dealers log in, place and track orders, and access their invoices and documentation. The portal is the primary interface for the international dealer network.

## Outcome

With 20 users, FritsJurgens is rolling out a single integrated platform covering the full cycle from dealer order through production, shipping and invoicing. Go-live is planned for 2026. The Atradius integration and the dealer article code module address two of the most specific requirements of their business model, and the result will be a system that fits how FritsJurgens actually works.

**Read more:** [Odoo for manufacturing](/industries/manufacturing) · [All cases](/cases)


# GenKey: from NetSuite to Odoo, cheaper in year one already
URL: https://www.fanatics.nl/cases/genkey-en
Language: en

**GenKey** develops biometric identity and security solutions from The Hague. A technical company that runs on sales, projects, purchasing and a tight administration, but that paid for it like a multinational.

## The challenge

GenKey ran on Oracle NetSuite. Powerful, but with a price tag that did not fit the size: a hefty amount per user per year, on licence alone. For a team of eight users that adds up fast, before you have spent anything on implementation or further development. The question was not whether NetSuite could do what GenKey needed, but whether that weight and cost were in proportion to what the company got out of it day to day.

## The approach

We set up Odoo as one platform for CRM, sales, purchasing, projects and accounting, tailored to how GenKey works. We calculated the project up front with our own calculator: a phased implementation for eight users, in the order of a few months, at a fraction of the annual NetSuite licence.

## The result

That sum was the heart of the business case: the implementation plus the Odoo licence in the first year stayed below what GenKey spent on NetSuite in a single year. No more enterprise overhead, but a modern platform that grows with them, with customisations GenKey owns itself.

---

**Read more:** [Odoo vs NetSuite](/odoo-vs-netsuite) · [NetSuite alternative](/netsuite-alternative) · [All cases](/cases)


# GreenSecure: a circular manufacturer from WeFact and Twinfield to one Odoo environment
URL: https://www.fanatics.nl/cases/greensecure-en
Language: en

**GreenSecure** from Hengelo produces circular security products and was nominated as circular start-up of Overijssel for good reason. The company stood at the start of its digitalisation: invoices in WeFact, accounting in Twinfield, and the rest in heads and lists.

## The challenge

Some thirty own products plus fifty by-products, spread across three warehouses, with a firm seasonal peak from September to March. Serial numbers and batches have to be right, and the accountant wanted to keep Twinfield. The wish: sales, purchasing, inventory and manufacturing in one system, live quickly.

## The approach

The kickstart method in compact form: fit-gap, then Sales, Inventory, Manufacturing and Accounting. For the accountant we deployed our own [Odoo-Twinfield integration](/odoo-twinfield-integration), so Odoo runs the operation and Twinfield stays filled automatically. Barcode scanning with label printers on the floor, on-site training for serial numbers and batches, and when a second legal entity was added, the environment simply grew along.

## The result

From loose tools to one system that handles the seasonal peak: inventory is right across three warehouses, manufacturing runs on traceable batches, and the accounting flows automatically through to the accountant.

---

**Read more:** [Odoo for manufacturing](/industries/manufacturing) · [Odoo - Twinfield integration](/odoo-twinfield-integration) · [All cases](/cases)


# Hart Haarlem: ticketing, venue rental, and eCommerce in one cultural platform
URL: https://www.fanatics.nl/cases/hart-haarlem-en
Language: en

## Where culture meets operational complexity

Hart Haarlem is a major cultural and events venue in the city of Haarlem, in the Dutch province of North Holland. The venue hosts theater performances, concerts, conferences, and a range of community and cultural events. It also offers rental space to external organizations and businesses, manages subsidy-funded cultural projects, and runs an online shop alongside its venue activities.

This multi-revenue-stream model is what makes Hart Haarlem an interesting Odoo project. Most cultural venues run one primary system (a ticketing platform or a venue booking tool) and patch the gaps with spreadsheets and separate invoicing software. Hart Haarlem chose a different path: one integrated platform for everything.

## Events and ticketing

The Odoo Events module was configured to handle Hart Haarlem's programming calendar: individual performances, multi-day festivals, and recurring series. Each event has its own capacity, pricing tiers, and associated resources. Ticket sales flow directly into accounting, eliminating manual reconciliation between a ticketing system and a separate finance tool.

For the programming team, working in the same system as finance means that revenue reporting per event is available in real time, with no waiting for an export or a monthly reconciliation. For the finance team, every ticket sale, cancellation, and refund is accounted for automatically.

## Venue rental and the client portal

Hall rental is a significant revenue stream for Hart Haarlem. Regular hirers (companies, cultural organizations, and event producers who use the venue repeatedly) needed a way to view their bookings, access invoices, and manage their relationship with the venue without needing to call or email for every piece of information.

FANATICS built a custom client portal on top of Odoo's standard Customer Portal. Regular clients log in and see their upcoming and past bookings, download invoices, and view the status of their rental agreements. For hirers who use Hart Haarlem regularly across a season, this self-service capability represents a meaningful reduction in administrative back-and-forth.

The CRM module supports the commercial side of venue rental: tracking prospects, managing relationships with regular clients, and monitoring the pipeline for larger events and corporate bookings.

## Subsidized projects

Cultural organizations in the Netherlands often operate a mix of commercial and subsidy-funded activities. Hart Haarlem manages a portfolio of cultural projects that are partly or wholly funded by municipal or provincial grants. The Projects module tracks hours, costs, and deliverables per project, providing the documentation required for subsidy reporting.

## eCommerce and ongoing operations

Hart Haarlem's online shop, selling merchandise, gift vouchers, and related products, runs through the Odoo eCommerce module, integrated with the same inventory and accounting foundation as the rest of the platform. Orders placed online flow directly into fulfillment and finance.

The system went live in 2025 and is actively in use as of 2026. Hart Haarlem continues to expand its use of the platform as the team grows more familiar with the system's capabilities.

**Read more:** [Odoo for culture & events](/industries/culture) · [All cases](/cases)


# Hotel Supply International: wholesale with WooCommerce integration and Twinfield accounting
URL: https://www.fanatics.nl/cases/hotel-supply-en
Language: en

## Supplying hospitality at scale

Hotel Supply International BV supplies the professional hospitality sector with the products that keep hotels and restaurants running: bed linens, towels, tableware, room accessories, and operational consumables. Their customers range from independent hotels and boutique restaurants to larger hospitality groups with multiple properties.

Operating in a trilingual market, Dutch, English, and German, with a webshop, an existing accounting system, and a growing customer base, Hotel Supply International needed a way to bring their operations together without replacing the tools that were already working.

## Keeping what works, adding what was missing

The key principle of this project was integration, not replacement. Hotel Supply International had two established systems: a **WooCommerce** webshop that was performing well and had SEO value they did not want to lose, and **Twinfield** as their accounting platform. Both were staying.

What was missing was an operational layer in between: a system that could receive orders from WooCommerce, manage inventory and purchasing, handle shipping and fulfillment, and pass the resulting financial transactions to Twinfield without manual data entry at every step.

Odoo was deployed as that operational core. The WooCommerce integration brings online orders directly into Odoo's sales and inventory flow. Stock levels are synchronized back to WooCommerce, so the webshop always reflects actual availability. When an order is fulfilled and invoiced in Odoo, our own [Odoo-Twinfield integration](/odoo-twinfield-integration) automatically pushes the accounting records to Twinfield, maintaining the finance team's existing workflow without disruption.

## Trilingual team and training

Hotel Supply International's team works across Dutch, English, and German. Their customer communications and product catalog are maintained in all three languages. FANATICS delivered training in all three languages, and the Odoo interface is configured to match each user's language preference.

The multilingual capability extends to customer-facing documents: order confirmations, delivery notes, and invoices are generated in the customer's preferred language, an important detail for their German-speaking hotel clients.

## Outcome

Hotel Supply International now operates with a connected stack: WooCommerce for online sales, Odoo for operations, and Twinfield for accounting. Orders flow through automatically, inventory is accurate across both the webshop and the warehouse, and the finance team works in the same Twinfield environment they have always used. The integration layer built by FANATICS removed the manual work that previously connected these systems.

**Read more:** [Odoo for wholesale](/industries/wholesale) · [All cases](/cases)


# House of Medicals: a new pharma wholesaler, on Odoo from day one
URL: https://www.fanatics.nl/cases/house-of-medicals-en
Language: en

**House of Medicals** is a new wholesaler of medical devices and medicines. The founder comes from pharma himself and is building the company from the ground up, with Odoo as the foundation from day one.

## The challenge

A new company has no old system to migrate from, but does have a choice to make that will last for years. House of Medicals looked for one programme that covers everything a pharma wholesaler needs - purchasing, sales, inventory and administration - and that can grow from a handful of users to fifteen, without buying a second package along the way. They found us through Odoo's website.

## The approach

Because there is no legacy to account for, we could start clean: set up Odoo around the processes of a medical-products wholesaler, with purchasing, sales and inventory on one data model and accounting linked to it. A base that is right from the first order, and that leaves room for the requirements that come with pharma as the company grows.

## The result

House of Medicals starts on a platform that gives one truth from day one: what is in stock, what is coming in and what is going out. No later switch, but the right choice up front, with room to scale to fifteen users and beyond.

---

**Read more:** [Odoo for wholesale](/industries/wholesale) · [Odoo ERP](/odoo-erp) · [All cases](/cases)


# HR Subsidie Specialist: WBSO consultancy on a structured Odoo platform
URL: https://www.fanatics.nl/cases/hr-subsidie-specialist-en
Language: en

**HR Subsidie Specialist** is an Amsterdam-based consultancy that helps companies apply for and account for innovation subsidies such as the Dutch WBSO. The work demands detailed time logging, long-running client dossiers and strict deadlines per application. A field where a missed invoice or forgotten hour costs real money.

## The challenge

For a consultancy in this segment, client relationship, active applications, hours and invoicing get tangled when they don't sit in one system. Ronald and the team worked with separate tools for CRM, projects and invoicing. That worked up to a certain size, but growth meant more dossiers, more people and more chance that an hour or a milestone slipped out of view.

The ambition wasn't a heavy ERP, but a platform that fits how consultancy works: track relationships, manage projects, log hours, invoice.

## The approach

We set up Odoo around the way HR Subsidie Specialist works:

- **CRM** for relationships with clients and partners like tax advisors and accountants.
- **Projects** for every active WBSO or subsidy application, with milestones, deadlines and time bookings.
- **Time tracking** per team member per project, with direct linkage to invoicing.
- **Sales and accounting** for quotes, invoices and VAT.

All on one database, so an hour logged immediately shows up in the project dossier, in the billable-hours report and in the invoicing queue.

## Result

Since 2024, Ronald, Wesly and Koen work from one system. Client contact, project progress, hours and invoicing live in the same place. An hour booked on an application flows without retyping to the billable side and ultimately to the invoice. What used to get lost between tools now stays visible.

---

**Read more:** [Odoo for professional services](/industries/services) · [Odoo ERP](/odoo-erp) · [All customer cases](/cases)


# IDD Parts: B2B webshop and full ERP for an ASSA ABLOY subsidiary
URL: https://www.fanatics.nl/cases/idd-parts-en
Language: en

## From complex catalog to seamless B2B portal

IDD Parts B.V. is the distribution arm of ASSA ABLOY in the Benelux, supplying door hardware, lock cylinders, and physical access security systems to professional installers and security integrators. Operating as a subsidiary within a large international group brings a specific challenge: every system must talk to the parent company's financial consolidation platform, while remaining agile enough for day-to-day commercial operations.

When IDD Parts approached FANATICS, they were managing a fragmented landscape of tools that could not keep pace with their catalog complexity. ASSA ABLOY products come in hundreds of variants (key profiles, cylinder lengths, keying systems, door dimensions) and customers needed to be able to configure and order exactly the right combination online, without requiring a phone call or a sales rep in the loop for every transaction.

## Configurable products at scale

The heart of the project is Odoo's **Product Configurator**, extended to handle IDD Parts' access-hardware logic. B2B customers log in to the portal and work through a structured configuration flow: door type, function, cylinder type, key system, and finishing. The configurator validates combinations in real time and generates a precise bill of materials that feeds directly into production planning and stock allocation.

For a group of this scale, the visual configuration experience is delivered through a **Twikit** integration, while Odoo stays the backbone that turns each configuration into the right bill of materials, price and stock allocation. For smaller manufacturers that want native configure-to-order without that platform weight, we build [CPQ Builder](/odoo-product-configurator) instead.

Because the product catalog spans multiple ASSA ABLOY sub-brands and product families, catalog management was a core concern. Products are structured with clean attribute matrices in Odoo, making it straightforward for the internal team to add new variants or retire discontinued lines without developer intervention.

## Automated sync with Onestream

As an ASSA ABLOY subsidiary, IDD Parts is required to submit financial data into Onestream, the group's consolidation platform. FANATICS built a dedicated integration layer that exports the relevant journal entries and financial aggregates from Odoo on a scheduled basis and pushes them to Onestream in the format required by the group reporting team.

This eliminates the manual extraction and reformatting work that previously consumed significant time at month-end close. The finance team at IDD Parts now works exclusively in Odoo; the Onestream submission is handled automatically.

## B2B portal and order management

The Odoo eCommerce module was configured as a gated B2B portal rather than a public webshop. Dealers and installers log in with individual credentials, see their account-specific pricing and available product range, and can place, track, and manage orders without leaving the portal. Order confirmations, delivery notes, and invoices are all available in the customer portal.

The Sales and Inventory modules work in tandem to keep stock visibility accurate. Reservation logic ensures that confirmed orders are immediately reflected in available stock, preventing overselling on fast-moving product lines.

## Outcome

IDD Parts went live in 2025 with an integrated Odoo environment that covers the full commercial and operational cycle: from online product configuration through to production, shipping, and group financial reporting. The Onestream integration removed a significant manual burden from the finance team, and the B2B portal has raised the self-service capability of IDD Parts' dealer network considerably.

**Read more:** [Odoo for wholesale](/industries/wholesale) · [All cases](/cases)


# IMAGIN.studio: subscription invoicing for an automotive SaaS, with Stripe on autopilot
URL: https://www.fanatics.nl/cases/imagin-studio-en
Language: en

**IMAGIN.studio** creates car imagery for the automotive industry: photorealistic visuals from 3D models, sold as a subscription service in some 140 countries. The company's own platform is the engine of the business; the financial administration ran on Twinfield and lacked functionality.

## The challenge

The invoicing model is exactly what makes SaaS hard: 95% of customers pay a fixed monthly fee, the rest comes from overusage on top of the subscription. Standard subscription tooling cannot handle that, and the administration has to be right worldwide, including a separate entity in India with local tax rules.

## The approach

Odoo became the financial layer next to the company's own platform. An API integration pulls debtors, subscription invoices and overusage from the backoffice and reports the payment status back. For collection we built custom work on Stripe: recurring credit card charges that run automatically, including for the invoices that differ from month to month. Multi-company and multi-currency, with the India entity in the same environment.

## The result

Invoicing and collection run on autopilot, from fixed subscription to variable overusage, and finance works in one environment instead of muddling along next to the platform. The accounting scales with every country that gets added.

---

**Read more:** [Odoo for services](/industries/services) · [Odoo custom development](/odoo-custom-development) · [All cases](/cases)


# Keizer International: ERP for international distribution of food packaging
URL: https://www.fanatics.nl/cases/keizer-international-en
Language: en

**Keizer International B.V.** distributes packaging solutions, bottles and caps, for the food industry to customers across the Netherlands and internationally. It is a B2B market with specific demands: customers are food manufacturers, volumes are high, delivery commitments are tight, and contract prices sometimes run for years while procurement conditions change.

That makes Keizer International's operations more complex than a standard wholesale business. A solid order flow is not enough. You also need control over price history, returns, customer communication and international shipping across multiple carriers and routes.

## The challenge

Keizer International had been running on SAP Business One as their ERP for many years. SAP B1 offered insufficient flexibility for the specifics of their operation: the historical pricing structure did not fit neatly into standard SAP logic, customisations were expensive to build, and connecting to carriers required significant manual work.

The decision to migrate to Odoo was driven by the need for a platform that fits their processes more closely, and where custom requirements can be realised faster and at lower cost.

Specific pain points were tracking historical customer prices, processing returns, managing shipments to international customers through multiple carriers with complex routing logic, and the absence of structured authorisation workflows for orders outside standard parameters.

## The approach

We implemented Odoo as the central platform for the entire operation.

### Sales, purchasing and warehousing

The Odoo modules for CRM, Sales, Inventory and Purchase form the backbone of daily operations. Sales and purchase orders are linked to the stock administration. Customers and prospects are managed in CRM, with full order history visible per account.

### Historical pricing

One of the most valuable customisations is the historical customer pricing module. Food manufacturers sign contracts with price agreements that span multiple quarters or years. Odoo displays the current price by default, but Keizer International also needs the historical price per customer and per period, for verification, disputes and billing decisions. This functionality was built to measure.

### RMA and customer service

The Helpdesk module handles customer enquiries and complaints. Through website forms, customers can submit an RMA request, a return or complaint request. That request lands directly in Odoo, is assigned to the right team member and linked to the relevant order. No more separate inboxes.

### Carrier integration and complex routing

Keizer International works with multiple carriers for international distribution. Different rules apply per destination, weight and order type: which carrier, which route, which documentation. This has been implemented as a custom routing logic within Odoo. The correct carrier is selected automatically based on order and destination characteristics.

Odoo generates the required shipping documents and pushes the right information to the carrier. Orders that fall outside standard parameters (in terms of volume, discount or destination) go through an authorisation workflow before they are confirmed.

## Result

Keizer International now operates from a single platform: from CRM and quotation to delivery, invoice and any return. The migration from SAP Business One to Odoo has delivered a system that fits their processes more closely and where custom requirements are realised at a fraction of the previous cost. The historical pricing module provides certainty when contract questions arise. Carrier routing is automated. The RMA flow runs in a structured way. And authorisations no longer travel through loose email threads.

---

**Further reading:** [Odoo for wholesale](/industries/wholesale) · [All client cases](/cases)


# OneEightyOne (181): Odoo for a lighting specialist combining product sales, bespoke projects and warehouse management
URL: https://www.fanatics.nl/cases/oneeightyone-en
Language: en

**Invent Design Beheer B.V.**, known as **OneEightyOne (181)**, is an Amsterdam-based company specialising in dynamic and custom light systems. They design and supply lighting for a wide range of sectors: architectural facade lighting for hotels, video lighting systems for exhibitions, linear and concealed lighting for offices and retail environments.

Their product range runs from direct view LED displays and linear lighting profiles to complete bespoke light systems and installation components, drivers, power supplies, cabling and mounting profiles. Alongside off-the-shelf products sold via a webshop, OneEightyOne also executes bespoke lighting commissions for architects, project developers and clients in hospitality and retail.

The combination of product sales via a webshop and project-based work demands a system that handles both streams: inventory and component management for standard products, and project administration that gives clear visibility into the progress and profitability of each installation commission.

## The challenge

OneEightyOne was working with separate systems for product sales, inventory and project administration. The webshop had no direct link to the stock of lighting components. Bespoke commissions were tracked via spreadsheets and email, without an integrated view of project status, associated purchases or invoicing progress. They needed a single platform integrating both business streams.

## The approach

We are implementing Odoo in phases at OneEightyOne. CRM and sales went live first; the remaining modules are being rolled out step by step.

### CRM and sales

The commercial processes are in place: quotes, orders, customer management and sales reporting all run through Odoo. The sales team has full visibility into the pipeline and the complete order history per customer.

### Purchasing, inventory and barcodes

Purchasing and inventory are managed from Odoo. Lighting components, LED modules, drivers, profiles, cabling, are registered with barcodes. Products are scanned on receipt for immediate stock updates. Labels are printed via the integrated printer infrastructure.

### Manufacturing and bills of materials

The manufacturing module manages the assembly of light systems. Bills of materials define which components are required per product or system. Production orders are created from sales orders and tracked through to completion.

### Project management for bespoke commissions

Alongside standard products, OneEightyOne carries out bespoke lighting projects for clients in hospitality, architecture and retail. The Projects module brings structure to these engagements: from quote and task planning through time registration, delivery and invoicing. This makes it possible to track profitability per project and assign tasks to team members.

### eCommerce

The webshop runs on the Odoo eCommerce platform. Standard products are ordered directly through the shop, connected to inventory and the warehouse.

### Accounting

Accounting connects to all operational processes, invoices, debtors, creditors and financial reporting all run through Odoo.

## Results

OneEightyOne is building step by step towards one integrated platform for product sales, warehouse management, project administration and accounting. CRM and sales are live. The remaining modules are being added in phases, ensuring each is properly configured before the next stage begins.

---

**Read more:** [Odoo for manufacturing](/industries/manufacturing) · [All cases](/cases)


# Ons Broodje Bonaire: POS, self-order and eCommerce for a sandwich shop on the island
URL: https://www.fanatics.nl/cases/ons-broodje-bonaire-en
Language: en

**Ons Broodje Bonaire** is a sandwich shop in Kralendijk, run by Daphne Nossels. A small team, a physical till, a growing stream of take-out orders, and the operational reality of an island: local banks, a local tax regime (ABB instead of VAT), local network infrastructure. We were asked to set up Odoo so the shop could open and run without the system getting in the way.

## The challenge

Daphne's brief was practical: a working till, a way for staff to clock in and out, and online ordering for take-out, without the project budget spiraling. On top of that, a few Bonaire-specific complications:

- **Local banks** (MCB, RBC, ORCO) whose PIN terminals cannot be directly coupled to a POS the way Dutch terminals can.
- **ABB instead of VAT**: pricing structure and invoice rules need to follow Bonaire's tax system.
- **A constrained budget**: 20 consultancy hours to deliver a working setup. Not enough for a full implementation. Plenty for a strong start.

## The approach

We started with the minimum working set of modules: Point of Sale, POS Self-Order, Restaurant, time tracking and accounting. All in one Odoo database, all in the same language, so a counter order, an online order and a timesheet later all flow into the same place.

### Point of Sale with physical hardware

The till runs on standard Odoo POS, paired with an Epson TM-M30II thermal printer for receipts. Daphne registers card payments manually for now (a direct integration with Bonaire's local banks is not part of the standard product), with a small partner-built module that adds a payment reference field on each POS transaction so end-of-day reconciliation with the bank stays simple.

### QR-based self-order

Customers scan a QR code and see the full menu, including combos, toppings and allergens, in Dutch or English. The flow is "pay at the counter": the system sends the order to the kitchen, the customer pays at the till when they collect. No Stripe needed, no friction with international payment providers that are not fully supported on the island yet.

The QR works both at the tables inside and outside, so take-out customers can order without first standing in line.

### Time tracking

The team clocks in and out via the Odoo Timesheet app on a tablet at the counter. Hours flow into payroll without retyping.

### eCommerce for take-out

The webshop is connected to the same product catalogue as the POS. An online order is a real sale order in the same system: stock, revenue and receipt print all behave identically to a counter order.

## Result

The shop opened on 7 May 2026. The same night Daphne sent us a message in our Teams chat:

> "We had our opening day today and it went great! The till worked, clock-in and clock-out worked, online ordering with pay-at-the-counter worked. Absolutely TOP. ... I'm thrilled with this result and this first day."
>
>, Daphne Nossels, owner, Ons Broodje Bonaire

The system has been running stably since opening. Next steps are building on what's there: extra reporting, a friendlier URL for the self-order page, and eventually a more direct PIN integration once the local banks support it. Pragmatic and in steps, exactly the approach we took for the first 20 hours.

---

**Read more:** [Odoo for hospitality & retail](/industries/hospitality) · [Odoo ERP](/odoo-erp) · [All customer cases](/cases)


# QPOWER Group: Odoo kickstart for sales and accounting
URL: https://www.fanatics.nl/cases/qpower-group-en
Language: en

**QPOWER Group** is an organisation in Harderwijk whose operations revolve mainly around sales and finance. A team of two that needed a working administrative base, without rolling out all Odoo modules at once. This is exactly what our kickstart method is built for.

## The challenge

For a small team, a full ERP implementation is often overkill. You don't need a production, inventory, eCommerce, HR and marketing layer at the same time if the core of the work is sales and invoicing. But you do need a serious system that grows with you and doesn't have to be replaced once the organisation gets bigger.

The brief was to set up a working base quickly, sales and accounting, with the option to add the rest later when relevant.

## The approach

We started with our **Radical Fanatics kickstart method**: a structured, focused implementation that runs in five project parts.

1. **Inventory and fit-gap analysis** to lock down scope.
2. **Set up core processes**: in this case sales and accounting. Inventory, manufacturing, projects, eCommerce, HR and marketing were explicitly out of scope.
3. **Project management and training** so the team can work independently from day one.
4. **Data import** for contacts, open positions and historical records.
5. **Standard extensions and customisation** only when and if needed.

On top of that, a fixed support and upgrade plan, so maintenance and version updates are predictable.

## Result

Since 2026, QPOWER runs on a working Odoo environment for sales and accounting, with two users and a fixed support agreement. The other modules stand ready for when the organisation needs them. No unnecessary investment in functionality that isn't used, but a system that can scale without being replaced.

---

**Read more:** [Our TARGET method](/target) · [Odoo ERP](/odoo-erp) · [All customer cases](/cases)


# Reany Bikes: eCommerce, EDI logistics and dealer management for a European e-bike distributor
URL: https://www.fanatics.nl/cases/reany-bikes-en
Language: en

**MISSINGLNK B.V., Reany Bikes Europe** is the European distribution arm of the Reany Bikes e-bike brand. From the Netherlands, Reany Bikes distributes e-bikes to dealers and consumers across Europe, with an external fulfilment centre (JCL Logistics in Zetten) handling order execution and DHL for direct shipments.

The combination of B2B dealer sales, a consumer webshop, external logistics and complex product variants (frames, sizes, battery packs) demands a platform that connects all these moving parts. Add to this European legal requirements: products containing batteries must include a disposal fee, transparently listed on each invoice.

## The challenge

Reany Bikes was operating with separate systems for sales, logistics and customer service. Growth made clear that a central platform was needed: one that connects the webshop to the order flow, drives external logistics via EDI, and handles dealer and customer queries in a structured way.

Additional complexity: battery variants carry separate pricing (as part of a kit or standalone), and the disposal fee for batteries must be automatically calculated on every invoice.

## The approach

We implemented Odoo as the central ERP platform for Reany Bikes' European operation.

### eCommerce and showroom mode

The Odoo webshop serves both consumers and business buyers. A showroom mode is configured for the physical showroom: products are visible and configurable, but the ordering flow is set up for dealers and business customers. Stock availability is shown via a traffic light indicator: green for immediately available, orange for limited stock, red for out of stock.

### JCL Logistics EDI integration

The JCL Logistics fulfilment centre processes orders for Reany Bikes. The EDI integration with Odoo automates the transfer of delivery orders to JCL and the return of shipping status and tracking numbers. This eliminates manual handover and provides real-time visibility into the status of every shipment.

### DHL integration

Direct shipments are handled via DHL. From the delivery order in Odoo, shipping documents, track-and-trace codes and packing slips are generated automatically.

### Battery disposal regulation

European legislation requires sellers of battery-containing products to charge a disposal fee. In Odoo this is automated: products with a battery automatically include the disposal fee in the sale price, with the amount listed separately on the invoice.

### B2B and payments

Dealer customers can order on account via the webshop. SEPA payments to suppliers are processed in a structured way through Odoo. Customers can also pay open invoices online via a payment link in the invoice email.

### Helpdesk and knowledge base

The Helpdesk module handles customer and dealer queries. Alongside the helpdesk, an Odoo Knowledge Base has been set up for frequently asked questions and product information, available to dealers and end users alike.

## Results

Reany Bikes manages its entire European distribution from one Odoo platform. The JCL EDI integration automates logistics handover. DHL documents are generated directly from the delivery order. Battery disposal fees are fully automated. And dealers order and pay directly through the webshop.

---

**Read more:** [Odoo for wholesale](/industries/wholesale) · [All cases](/cases)


# RGS Development: precision manufacturing for space, structured in Odoo
URL: https://www.fanatics.nl/cases/rgs-development-en
Language: en

**RGS Development** produces parts for the space industry. A sector where tolerances are low, traceability is mandatory, and you don't simply redo a batch when something goes wrong. For a mid-sized supplier in this segment, a working ERP is not a luxury but a requirement.

## The challenge

RGS worked with separate tools for quotations, production and inventory. For the kind of work they do (precision parts, small batches, international customers) a central place for bills of materials, work orders, inventory movements and certifications is essential. Without it you lose traceability, and in this sector that is a serious problem.

The team also works internationally. Engineering, sales and execution don't sit in the same chair. A platform where everyone can access the same data from their own role, instead of asking around, was the second requirement.

## The approach

We set up Odoo as the central operational backbone: manufacturing with BOMs, work orders and routings; inventory with serial and batch tracking; purchase with approval flows; project structure for active customer orders. All on one database, with clean reporting per customer and per project.

Manufacturing settings are tuned to the reality of precision manufacturing: small batches, long lead times and strict quality requirements. Documents, certificates and processing steps are recorded per work order, so you can trace afterwards what happened where.

## Result

Since 2023, RGS runs operations on Odoo. Sales knows what's possible, manufacturing knows what's needed, inventory knows what's there. The traceability that the sector demands now sits naturally in the process, no longer in an Excel sheet on someone's laptop.

---

**Read more:** [Odoo for manufacturing](/industries/manufacturing) · [Odoo ERP](/odoo-erp) · [All customer cases](/cases)


# Rhea Vendors: one Odoo platform for the Benelux, Germany, and Austria
URL: https://www.fanatics.nl/cases/rhea-vendors-groep-en
Language: en

import StatRow from '~/components/blog/StatRow.astro'

<StatRow eyebrow="Rhea Vendors in numbers" stats={[
  { num: '3', label: 'countries on one platform (NL · AT · DE)' },
  { num: '40', label: 'users in Germany' },
  { num: '1', label: 'template for the whole group' },
]} />

## Scaling a manufacturer across three countries

Rhea Vendors Groep designs and manufactures vending machines for professional environments: coffee machines, snack dispensers, and combination units deployed in offices, healthcare facilities, and public spaces. With operations spanning the Netherlands, Austria, and Germany, the group needed an ERP backbone that could serve as a single source of truth while accommodating the fiscal and operational realities of each country.

FANATICS designed a three-phase rollout: the Benelux entity as the template, followed by the Austrian subsidiary, and finally the German operation. Each phase built on the previous one, reducing implementation risk and allowing lessons from earlier rollouts to inform later ones.

## Phase 1: Benelux as the template

The Dutch entity was the first to go live, in 2023. It had been running on [Microsoft Dynamics](/odoo-vs-dynamics) and [SnelStart](/odoo-vs-snelstart), with accounting and logistics split across separate systems; the logistics modules in particular were hitting their limits, which is what triggered the move to one Odoo platform. This phase established the core manufacturing and commercial processes in Odoo: production planning with bills of materials, purchase and inventory management, sales and customer portal, and Dutch-localized accounting. Field Service was implemented to support the service and maintenance arm of the business: technicians managing installations, repairs, and preventive maintenance on deployed machines.

Labels & Barcodes was deployed early in the process, giving the warehouse team a reliable way to track components and finished goods through production and dispatch.

## Phase 2: Österreich GmbH

The Austrian entity introduced additional complexity: Austrian fiscal requirements, a different VAT regime (ATU40171103), and ÖNORM-compliant accounting structures. FANATICS implemented the Odoo Austrian localization and adapted the chart of accounts and tax configuration accordingly.

For warehouse operations in Austria, **Ventor Tech** was integrated: a mobile warehouse scanning solution that gives the floor team a purpose-built app for receiving, picking, and inventory counts, without requiring full Odoo access on every device.

## Phase 3: Servomat Deutschland GmbH

The German rollout was the largest in terms of user count, with approximately 40 users onboarded. Germany brought its own requirements: German DATEV-compatible accounting, German-language training, and an integration with **two [Apfel](https://apfel-gmbh.de/) storage lift systems** (LTL and LTK series), automated vertical storage units used in the German warehouse for high-density component storage. The integration works goods-to-person: when a warehouse operator picks an order in the **Odoo Barcode app**, the lift automatically brings the right shelf forward. The operator does not walk to the stock, the stock comes to the operator. What warehouse automation with Odoo can and cannot do is covered in [Odoo as a WMS](/blog/odoo-as-wms).

The Apfel integration connects Odoo inventory movements to the automated lift: when a picking order is confirmed in Odoo, the storage lift is instructed to retrieve the relevant tray, reducing picking time and warehouse footprint errors.

## Unified reporting, local operations

Despite the complexity of three country entities, the group operates from a single Odoo database. Inter-company transactions between Rhea Netherlands and its subsidiaries are handled natively in Odoo, and management reporting consolidates figures across all three entities. Each country team works in its own language and sees its own fiscal configuration, while the group has full visibility across the entire operation.

## In the client's words

> "Communication with Fanatics throughout the implementation process was prompt and clear, making the entire experience seamless. Fanatics demonstrated deep expertise in their field, expertly answered all questions, and provided valuable insights. Thanks to this all-in-one solution, we now have access to various features and tools within the same interface. This not only saves time but also promotes better collaboration, with faster learning curves for employees as they only have to familiarise themselves with a single platform."
>
> Claudio Cottica, Rhea Vendors

**Read more:** [Odoo for manufacturing](/industries/manufacturing) · [All cases](/cases)


# Stil Orthosis: Odoo as the backbone for medical device production with strict component traceability
URL: https://www.fanatics.nl/cases/stil-orthosis-en
Language: en

**Stil Orthosis B.V.** develops and produces an anti-tremor orthosis: a smart device that significantly reduces trembling in neurological conditions such as essential tremor and Parkinson's disease. The product helps people continue to perform everyday tasks (eating, writing, working) independently.

A medical device of this kind falls under European MDR regulation. That means every component must be traceable, every production step recorded, and quality assurance embedded in every process. This places specific demands on the ERP system.

## The challenge

Stil Orthosis had grown to the point where operations could no longer be managed without a structured system. Separate spreadsheets for bills of materials, stock management via email and manual quality checks do not fit a company delivering medical devices. They needed a system that structures their production processes and provides the component traceability their sector requires.

## The approach

We implemented Odoo with a focus on manufacturing, quality management and traceability.

### Manufacturing and bills of materials

The Odoo Manufacturing module manages the bills of materials (BoM) for the orthoses. Every component (from the frame to electronic parts) is registered with lot and serial numbers. When a device is produced, Odoo records exactly which specific components were incorporated. That is the core of MDR traceability: in the event of a report or recall, you know precisely which devices contain which component batch.

### Quality Management (QM)

The Quality Management module adds quality control checkpoints to the production flow. For each step in the production process, Stil can define which checks must be carried out. The results are recorded in Odoo, not in a separate system or spreadsheet, but directly linked to the production order. This makes quality reporting considerably simpler.

### Inventory and shipping

The inventory administration tracks what is in stock, what is in production and what is going out. Lot and serial numbers are carried through all inventory movements. When shipping to end users or distributors, Odoo records the correct serial numbers per delivery.

### Data import prepared by Stil themselves

A notable detail: Stil Orthosis prepared the data import files entirely on their own. This is by no means a given in ERP implementations; it requires an understanding of the data structure and discipline in preparation. The result was a smooth import and a faster go-live.

## Result

Stil Orthosis now has a production management environment that meets the traceability requirements of the medical industry. Every device can be traced back to its components. Quality checks are an integral part of the workflow. And the operation runs on a system that grows with the business.

---

**Further reading:** [Odoo for manufacturing](/industries/manufacturing) · [All client cases](/cases)


# T. van der Plas: ten packing lines for sprouts, driven from the sales order
URL: https://www.fanatics.nl/cases/t-van-der-plas-en
Language: en

**T. van der Plas** grows and packs sprouts for retail. Fresh product, short lead times and a packing department with ten lines that has to run tightly every single day. The company worked in Exact and found us through our website, looking for a solution that actually drives the packing department.

## The challenge

With fresh products, everything starts with today's order: every sales order line must directly become a production order, visible on a planning board per packing line. Retailers order via EDI and expect invoices along the same route, with the correct GTIN per consumer and trade unit. And returnable packaging and deposits have to run along without manual work.

## The approach

The kickstart method: fit-gap, then Sales, Inventory, Manufacturing and Accounting, with data import largely done by the team itself. The custom work sits where it counts: automatic production orders from order lines with their own production phases, deposit and returnable packaging registration on the sales order, extensive approval flows and the EDI connection to SPS Commerce for orders in and invoices out. Fixed weekly progress moments kept the project on course, and with Odoo Heartbeat the support is arranged afterwards.

## The result

The packing department runs on the system instead of on experience and Excel: ten lines with a clear planning board, batches that can be traced and retailers that are served automatically. Exact has been waved goodbye.

---

**Read more:** [Odoo for manufacturing](/industries/manufacturing) · [Odoo custom development](/odoo-custom-development) · [All cases](/cases)


# The Set Company: projects, workshop and material budgets in one system
URL: https://www.fanatics.nl/cases/the-set-company-en
Language: en

**The Set Company** builds sets and decors for productions: project work with a real workshop behind it, machine planning, assembly on location and many hands writing hours. The company found us through Odoo's website and wanted everything in one system: from quote to workshop to delivery.

## The challenge

For project builders, the profit or loss sits in the material. Every decor has a budget, every task consumes material, and without a system you only see at the final invoice whether it added up. On top of that: planning of machines and people, field service on location and multiple legal entities in the same administration.

## The approach

The full chain in Odoo: CRM, sales, projects, time tracking, field service, workshop and accounting. The heart is custom work we built: material budget and actual consumption per project task, purchase orders directly from the task, stock reservation on task date and visible over- or underrun before it hurts. On top of that, a planning board for workshop and projects.

## The result

Project margins are visible during the project instead of after it. The workshop plans on the same system as the project managers, and development continues: the system has been growing with the company for years.

---

**Read more:** [Odoo for manufacturing](/industries/manufacturing) · [Odoo custom development](/odoo-custom-development) · [All cases](/cases)


# Tierrafino: switched from another Odoo partner
URL: https://www.fanatics.nl/cases/tierrafino-en
Language: en

**Tierrafino** makes and supplies natural clay and loam wall finishes from Amsterdam. The company already ran on Odoo, so this is not an implementation story but a partner switch: from another Odoo partner to Radical Fanatics.

## The challenge

Odoo was in place, but the relationship with the previous partner no longer fit where Tierrafino wanted to go. Such a switch often feels scarier than it needs to be: companies fear they will lose their database, licences or customisations if they change partner. That is almost never the case - your Odoo stays yours.

## The approach

We did not start blindly with support, but with a handover: mapping what is there, who owns and administers the environment, and which configuration and customisations are live. Then we took over the management and further development, without touching the existing Odoo.

## The result

Tierrafino keeps working on the same Odoo environment, now with a partner that fits the next phase. Database, licences and customisations were preserved; the switch did not mean starting over, just a careful handover.

---

**Read more:** [Switching Odoo partner](/blog/switching-odoo-partner) · [Odoo ERP](/odoo-erp) · [All cases](/cases)


# Top Vision Group: production management and label automation for in-store visual merchandising
URL: https://www.fanatics.nl/cases/topvision-en
Language: en

**Top Vision Group B.V.** manufactures visual merchandising materials for the retail sector: in-store displays, POS materials and presentation solutions deployed in shops around the world. Their website is [topvisioninstore.com](https://topvisioninstore.com). Their products end up in retail environments where accuracy, brand consistency and logistical reliability are the standard.

That places specific demands on their ERP: many SKUs, complex labelling requirements for products and shipments, international shipping and a production process that must be planned across multiple orders simultaneously.

## The challenge

Top Vision Group was working with a combination of separate systems for manufacturing, sales and logistics. The lack of integration made it difficult to plan production based on current orders, coordinate shipments with the correct documentation, and generate labels consistently for different use cases. On top of that, the need for a structured barcode and label workflow was growing: from goods receipt through to delivery.

## The approach

We implemented Odoo in phases, with sales and accounting going live first, followed directly by manufacturing.

### Phase 1: Sales, purchasing and accounting

The first phase focused on the commercial and financial processes. CRM, Sales, Purchase and Accounting were set up as the foundation. Customers, suppliers and the product catalogue were imported. Top Vision Group now works from a single system for quotations, purchase orders and invoices.

### Manufacturing and MO planning

The manufacturing phase, currently in rollout, brings manufacturing orders (MOs) into Odoo. One of the standout customisations is the automatic planning of MOs: based on sales orders and lead times, production orders are scheduled automatically. This gives the production planner immediate visibility into what needs to be made and when, without manual calculations.

### Custom label system

One of the most extensive components of the Top Vision implementation is the label system. Retail environments place specific demands on labels: both for internal use (barcode labels for warehouse scanners) and for external communication (product labels, shipping documents).

We built multiple label formats:
- **ZPL labels** for direct printing on thermal printers (goods receipt, production, warehouse)
- **PDF labels** in various formats (100×50mm, A4) for products and cartons
- **Barcode automation**: when a product is created, the internal reference is automatically set as the barcode

The label printer is connected via Direct Print, so team members can print labels without exporting a PDF or going through a download step.

### UPS integration and CMR documents

Outbound shipments are handled via UPS. The integration with Odoo ensures that shipping labels, track-and-trace and customs documents are generated directly from the delivery order. For international road freight, Odoo generates CMR documents (consignment note) at the time of shipment.

### Barcodes and purchase orders

Suppliers receive purchase orders with attachments directly by email via the PO mail attachments module. On receipt of goods, products are scanned and automatically assigned the correct lot or serial number.

## Result

Top Vision Group now operates from a single platform for sales, purchasing, warehousing and, in the ongoing phase, manufacturing. The label system eliminates manual work at every point that something moves through the warehouse. The UPS integration and CMR documents ensure streamlined international shipping. And the automatic MO planning gives the production team a realistic picture of the work order for the days ahead.

Top Vision Group is supported under a Heartbeat support agreement.

---

**Further reading:** [Odoo for manufacturing](/industries/manufacturing) · [All client cases](/cases)


# Tulppack: from Brincr to one Odoo platform, with self-service ordering and stock that adds up
URL: https://www.fanatics.nl/cases/tulppack-en
Language: en

**Tulppack** supplies packaging and tea-filter material to business customers. A large part of the range comes in on big rolls and is sold to size: by the metre or by the tea bag, printed with the customer's logo or plain. A process with its own logic - and a stock question most off-the-shelf packages cannot answer.

## Three systems that did not add up to a whole

Tulppack ran on three separate subscriptions: **Brincr** for orders and inventory, **Exact Online** for accounting and a **separate webshop** for online orders. Connected on paper, three islands in practice.

And Brincr was starting to pinch:
- inventory management got complex, with support that was hard to reach
- the semi-finished to finished-product process was poorly supported
- batch numbers could not be managed the way Tulppack wanted
- their own article-numbering logic (built from supplier, article group and the article itself) did not fit the system

## The real problem: self-service ordering, and stock that has to add up

Under that list was one core wish: **customers had to be able to order themselves through the webshop, without anyone in between.** And not just order - they had to choose between the metre and the tea bag, and between printed and plain. For printed, the logo had to be uploaded right inside the order process.

Beneath that lay the stock puzzle. A roll comes in at **140 mm wide**, but is sold **by the metre** or **by the 60 mm tea bag** - with around **3% waste** per roll. How do you keep your stock figures correct across all those units? Standard order and accounting software had no answer.

## The urgency: a machine that had to run by 1 September

In mid-August a new machine arrived that had to be in operation by **1 September**. A hard deadline makes a decision concrete.

Tulppack also looked at Dynamics (it could do it, but no love for American software), King, Exact Handel and AFAS - none solved the core problem. Odoo Experts turned them away: they found Tulppack too small. We did not.

## One Odoo platform shaped to the process

Odoo replaced all three systems in one environment:

- **eCommerce & Customer Portal** - a B2B webshop where customers order themselves. Product variants handle the choice between metre and tea bag and between printed and plain; for printed, the customer uploads the logo right in the order process.
- **Inventory with multiple units of measure** - the roll as the purchase unit, metre and tea bag as sales units, with the conversion and the waste configured so stock stays correct.
- **Manufacturing** - the path from semi-finished (roll) to finished product, with batch numbers managed the way Tulppack wants.
- **Sales, Purchase and Accounting** - on one data model, so order, inventory and finance share the same truth. Their own article-numbering logic was adopted rather than worked around.

## The result

- **Three subscriptions became one.** Brincr, Exact Online and the separate webshop were gone; Odoo brought orders, inventory, production, webshop and accounting together.
- **Customers order themselves**, with variant choice and logo upload, with no one in between.
- **Stock adds up** across roll, metre and tea bag, waste included.
- **Live on the deadline**, ready for the new machine.

## In the client's words

> "Tim provides professional, efficient and structured guidance for the Odoo implementation, and is flexible in responding to specific needs. His extensive eye for detail is crucial in the implementation process. We are extremely satisfied with Fanatics and highly recommend them."
>
> Arjen Peetoom, Tulppack

---

**Read more:** [Odoo vs Brincr](/odoo-vs-brincr) · [Odoo for manufacturing](/industries/manufacturing) · [All customer cases](/cases)


# VIXY: from planning-in-Gripp to one platform for the whole business
URL: https://www.fanatics.nl/cases/vixy-en
Language: en

**VIXY** is a Dutch video platform from Hilversum: a SaaS solution to host, manage and stream video - from API and player to analytics - for hundreds of organisations. On top of that a second branch joined: the B2B webcasting and broadcasting of large events. Two business units, each with their own processes, under one roof.

## The challenge

VIXY's project planning ran through [Gripp](/gripp-alternative), connected to Exact for the accounting. On paper a logical combination, in practice not smooth: a planning tool next to a bookkeeping package means connecting, reconciling and re-typing. And with a SaaS branch (consumption and monthly fees per customer) plus a project-driven webcasting branch, the processes drifted too far apart to keep clear in loose tools.

## The approach

We moved VIXY onto one Odoo environment: project management, CRM and quotations, time tracking, purchasing and sales and a knowledge base on the same data model, with the accounting inside it instead of alongside. In the same move Odoo replaced a number of loose tools, so the planning no longer had to talk to the administration through a connector.

## The result

VIXY now runs its two business units from one system: the projects and hours, the commercial side and the administration come together on the same platform. No planning tool that has to be connected to a bookkeeping package, but one overview from customer to project to invoice.

---

**Read more:** [Gripp alternative](/gripp-alternative) · [Odoo for professional services](/industries/services) · [All cases](/cases)


# Wijnwinkel Barneveld: one platform for shop, POS and webshop, with Exact Online integration
URL: https://www.fanatics.nl/cases/wijnwinkel-barneveld-en
Language: en

**Wijnwinkel Barneveld** is a specialist wine shop with a physical store in Barneveld and an online shop. Customers can browse a broad selection of wines with expert in-store advice or order online for home delivery. The combination of in-store POS sales and eCommerce puts specific demands on the underlying system.

Beyond day-to-day retail, there are also legal and logistical considerations: online alcohol sales require age verification, wine cases have specific packaging rules, and bottle deposits must be tracked throughout the administration.

## The challenge

Wijnwinkel Barneveld was working with separate systems for the shop, webshop and accounting. Keeping stock accurate, managing customer relationships and closing the books was laborious. They needed a single platform unifying physical retail, online sales and administration, with functionality specifically suited to a specialist wine retailer.

## The approach

We implemented Odoo as the central platform for Wijnwinkel Barneveld's entire operation.

### Point of Sale for the physical shop

The Odoo POS module replaces the standalone cash register. Products are scanned by barcode, receipts printed and payments processed at the counter. The POS is directly connected to inventory, so stock is updated accurately with every transaction.

### Webshop with 18+ age verification

The Odoo webshop replaces the external eCommerce environment. A custom module adds an age check at checkout: customers confirm they are 18 years or older before completing their order. This is a legal requirement for online alcohol sales and is now built into the checkout flow as standard.

### Wine-specific packaging logic

Wine is also sold by the case or crate. Two custom packaging rules are in place:
- When six bottles are added to the basket, the customer is offered the option to build a case
- When twelve or more bottles are added, the appropriate packaging unit is automatically suggested

### Bottle deposits

Wijnwinkel Barneveld operates with deposits on crates and bottles. Odoo registers deposits at every transaction, keeping the stock of empty crates and bottles accurate and ensuring correct financial settlement.

### Exact Online integration

The accounting runs through Exact Online. The integration with Odoo synchronises purchase and sales invoices, debtors and creditors, and cost centres to Exact. Outstanding items are returned from Exact to Odoo. The team always has up-to-date financial information without double entry.

### Printnode

Labels and receipts are printed via Printnode, a direct printing experience from within Odoo, without download steps or manual file handling.

### Loyalty programme

In roll-out: a loyalty programme for returning customers. Odoo tracks reward points that customers can redeem, both in-store and online.

## Results

Wijnwinkel Barneveld now operates from one platform for shop, webshop and administration. The 18+ check is built into the checkout flow. Bottle deposits are automatically processed. The Exact integration eliminates double bookkeeping entry. And the loyalty programme is rolling out for deeper customer retention.

---

**Read more:** [Odoo for retail](/industries/retail) · [All cases](/cases)


# Studio Marcel Wanders: design work in a structured Odoo platform
URL: https://www.fanatics.nl/cases/wonders-marcel-wanders-en
Language: en

**Studio Marcel Wanders** is an internationally recognised design studio in Amsterdam, part of Wonders Holding. Work that appears in interiors of iconic hotels, restaurants and residential projects worldwide, and products licensed to major brands. An organisation whose output is culturally charged, but whose operations still have to look like a normal business inside.

## The challenge

For a design studio running international projects, administration is not a side concern. Customer contracts, time logging, royalty flows and invoicing get tangled when they don't sit in one system. Studio Marcel Wanders worked with separate tools that each handled a part, without giving a shared view of what was running and where the value was.

The brief was to build that overview without disrupting the creative way of working. A system that offers structure rather than forcing it.

## The approach

We set up Odoo around the studio's way of working. CRM for relationships with brands, hotels and project developers. Projects for active design work, with time tracking per team member and per assignment. Sales for quotes and invoices. Accounting for everything that comes out of it.

The emphasis is on project administration. For a studio, an assignment is rarely just "sell product, send invoice". There's a phase of designing, reviewing, prototyping and delivering. Odoo Projects accommodates that, with time tracking that flows directly into invoicing.

## Result

Since the 2025 go-live, the team of Walther, Joy, Robin and Francisca works from one platform for projects, time, sales and finance. The studio keeps its creative way of working, but now with administration underneath that moves with it rather than trailing behind.

---

**Read more:** [Odoo for wholesale & design](/industries/wholesale) · [Odoo ERP](/odoo-erp) · [All customer cases](/cases)


# Zo Veilig: security systems for 6,000 customers, managed from one platform
URL: https://www.fanatics.nl/cases/zo-veilig-en
Language: en

import StatRow from '~/components/blog/StatRow.astro'

**Zo Veilig** installs and manages security systems for private individuals and businesses across the Netherlands. With around 6,000 active customers, their operation is more complex than a typical installation company: every customer has an installation, a subscription, an active contract with a monitoring centre, and sooner or later a relocation or a service call.

That combination of planning, work orders, monitoring centre management and recurring invoicing demands a system that connects all those streams. Separate tools led to manual re-entry, missed activation steps and inconsistent customer data.

<StatRow eyebrow="Zo Veilig in numbers" stats={[
  { num: '~6,000', label: 'active customers' },
  { num: '~10,000', label: 'subscription invoices per month' },
  { num: '1 platform', label: 'planning to invoicing' },
]} />

## The challenge

The challenge at Zo Veilig centres on three interconnected processes that traditionally don't align well.

**Monitoring centre integration**: After installing a security system, the customer must be activated at the monitoring centre, either Securitas or Alarm.com. This was a manual process: the engineer completes the job, someone coordinates the activation with the monitoring centre. On relocation, the same had to happen again: deactivate the old address, activate the new one. Error-prone and time-consuming.

**Work orders and sign-off**: Engineers work with job sheets in the field. After completing an assignment, multiple actions need to be triggered: activate the contract, link the monitoring centre, update customer data. These were manual steps that depended on the right person at the right moment.

**Invoicing at scale**: With ~6,000 active subscriptions, thousands of invoices need to be generated and sent every month. An error in the batch, a duplicate invoice, an incorrect amount, immediately affects a large portion of the customer base. That requires a controlled and auditable process.

## The approach

We implemented Odoo as the central platform, with Field Service at the heart of daily operations.

### Field Service and work orders

The Field Service module manages engineer scheduling and job execution. Engineers work with digital job sheets on their phone or tablet, including mandatory checklists per job type. Only once all checklist items are ticked can the work order be closed, guaranteeing that the right steps have been completed before sign-off.

Closing a work order automatically triggers follow-up actions: the subscription is activated, customer data is updated and the monitoring centre is notified.

### Monitoring centre integration: Securitas and Alarm.com

We built an API integration with both Securitas (MAS) and Alarm.com. The moment a work order is closed as completed, Odoo automatically sends an activation request to the correct monitoring centre. Which centre that is depends on the customer's product and subscription type.

On relocation, the address change in Odoo automatically triggers a deactivation at the old address and an activation at the new one, without any manual coordination. This custom development eliminates one of the most error-prone steps in the operation.

### Automated batch invoicing

Zo Veilig invoices ~6,000 subscriptions every month. We developed a controlled batch invoicing module: at the start of each month, all invoices are automatically generated based on current subscription data, checked for anomalies and then sent in bulk.

The process is transparent: deviations are flagged before sending, so corrections can be made before any incorrect invoices go out. A substantial improvement over the previous manual process.

### CRM, Helpdesk and subscription management

Customer contacts, quotes and active subscriptions are managed through CRM and Subscriptions. Fault reports and service requests come in via Helpdesk and are immediately linked to the correct customer and location. Engineers see their open tasks in the planning module and can access relevant customer history directly from within the work order.

## Result

Zo Veilig manages the complete lifecycle of a security customer, from acquisition and installation through contract, monitoring centre, service and invoicing, from a single platform. The integration with Securitas and Alarm.com is fully automated: activation on sign-off and on relocation happens without manual intervention. The monthly batch run of ~10,000 invoices has become a controlled, auditable process. And field engineers work with digital job sheets that enforce the correct sign-off steps.

---

**Further reading:** [Software for field-service installers](/software-for-field-service-installers) · [Odoo for professional services](/industries/services) · [All customer cases](/cases)


================================================================

COMPARISONS

================================================================

# Odoo vs AFAS. Where each one wins.
URL: https://www.fanatics.nl/odoo-vs-afas
Language: en

## Verdict
AFAS is the safest choice if your priority is Dutch payroll and HR compliance and you want a single vendor for both. Odoo wins when you need breadth across processes (CRM, manufacturing, projects, e-commerce), an international rollout, or deep customization. Both are mature. The right answer depends on which way your scope leans.

## At a glance
- Country coverage | Odoo: 80+ countries | AFAS: 3 (NL focus)
- Implementation time | Odoo: 3–9 months | AFAS: 4–12 months
- Module breadth | Odoo: 80+ built-in apps | AFAS: HR/payroll + finance core
- Customization | Odoo: Open-source, deep custom OK | AFAS: Closed, parameterised only
- Pricing model | Odoo: Per user, all modules included | AFAS: Per employee, all-in
- Dutch payroll compliance | Odoo: Add-on partner module | AFAS: Native, leading
- Manufacturing / Field service | Odoo: Strong native | AFAS: Limited
- Ecosystem partners | Odoo: 5,000+ globally | AFAS: NL partner network

## Five things people actually decide on
1. Functional breadth
   Odoo: Odoo ships 80+ apps. CRM, sales, e-commerce, inventory, manufacturing, MRP, projects, timesheets, HR, helpdesk, marketing: all in one platform, sharing one database.
   AFAS: AFAS is deep in HR, payroll and finance. Other domains (manufacturing, e-commerce, project portfolio) are thinner or absent. Many AFAS customers run a second system alongside for those.
   Verdict: Need breadth? Odoo. Need leading Dutch payroll above all? AFAS.

2. Customization
   Odoo: Open-source under the hood. Custom modules in Python, accessible source code, you can take it elsewhere if you ever need to. Strong fit when your process has genuinely unique requirements.
   AFAS: Closed platform. Configurable via parameters and workflows; harder to extend with deeply custom logic. Strong fit when your process is standard and you want the vendor to handle complexity.
   Verdict: Special process or integration? Odoo bends. Standard process? AFAS gives you less to maintain.

3. Pricing
   Odoo: Per-user subscription with all modules included. Standard plan from ~€20/user/month (Odoo SaaS). Most implementations with custom code run the Custom plan at ~€35/user/month (Odoo.sh or self-hosted). Implementation is on top.
   AFAS: Per-employee all-in pricing: straightforward, but the entry-level cost is higher and you may pay for modules you don't need.
   Verdict: Small team picking 3 modules? Odoo will be cheaper. Larger team using everything across HR? AFAS becomes competitive.

4. Support and partner ecosystem
   Odoo: Global ecosystem of partners (5,000+) including ourselves. You can switch partner without losing your data. Odoo SA provides the platform; partners provide the work.
   AFAS: AFAS is the single party. They own the software and the support. Easier escalation path; fewer outside options if the relationship sours.
   Verdict: Want option-value? Odoo. Want one throat to choke? AFAS.

5. International rollout
   Odoo: 80+ country localisations out of the box. Multi-company, multi-currency, multi-language. Strong fit for cross-border SMB.
   AFAS: Designed for the Netherlands, with limited Belgium / Curaçao support. Cross-border is achievable but uncomfortable.
   Verdict: Operating in 2+ countries? Odoo. NL-only? Either works; AFAS is more idiomatic.

## Pick Odoo if…
- You need breadth: multiple business domains (sales, ops, finance, HR, projects) in one system.
- Your process has genuine custom requirements that need real code. See our custom development work.
- You operate (or plan to operate) in more than one country.
- You want flexibility on partners and on cost: pay for what you use.

## Pick AFAS if…
- Dutch payroll and HR compliance is your top priority and your scope is largely there.
- Your business is NL-only and likely to stay that way.
- You prefer one vendor for software + support, with no third-party partners involved.
- Your processes are standard enough that 'configurable, not customizable' is fine.

## FAQ
Q: What is the best alternative to AFAS?
A: For Dutch SMEs that want more than HR and payroll, Odoo is the most common alternative to AFAS: one platform for CRM, sales, e-commerce, inventory, manufacturing, projects and finance, with Dutch payroll handled through a partner module or connector. AFAS stays strong if payroll is your core need; Odoo wins on breadth, customization and international rollout.

Q: What is the main difference between Odoo and AFAS?
A: Odoo covers 80+ process domains in a single platform: CRM, sales, e-commerce, inventory, manufacturing, projects, HR and finance. AFAS is strong in HR, payroll and finance, but thinner in manufacturing and e-commerce. Choose AFAS if your scope is mostly HR/payroll. Choose Odoo when you need breadth.

Q: Can I run Dutch payroll in Odoo like I would in AFAS?
A: Not natively. For Dutch payroll we use a partner module in Odoo or a connector to Nmbrs or Loonbrein. AFAS has a proprietary payroll engine that is widely seen as the Dutch market standard. If payroll is your primary driver, AFAS remains stronger.

Q: How does Odoo's pricing compare to AFAS?
A: Odoo charges per user, starting around €20/month (Standard) or €35/month (Custom, with customization), and includes all 80+ apps. AFAS charges all-in per employee with a higher entry cost. For a small team Odoo is usually cheaper. For a large HR-heavy team AFAS can become competitive.

Q: How complex is migrating from AFAS to Odoo?
A: Doable, but not trivial. The big work items are master data, open AR/AP, payroll history and external system integrations. We run a phased migration with a dry-run before go-live. Read Tim's account of switching from AFAS to Odoo for our own experience.


# Odoo vs Exact. Where each one wins.
URL: https://www.fanatics.nl/odoo-vs-exact
Language: en

## Verdict
Exact is the natural choice if accounting is your starting point and you want a tightly-localized Dutch financial system. Odoo wins when you outgrow accounting-first thinking: when CRM, projects, manufacturing or e-commerce need to live in the same system as finance. Many Dutch SMBs eventually migrate from Exact to Odoo for exactly that reason; the inverse is rare.

## At a glance
- Module breadth | Odoo: 80+ built-in apps | Exact: Accounting + light ERP
- Best entry point | Odoo: Any process domain | Exact: Accounting / bookkeeping
- Customization | Odoo: Open-source, deep custom OK | Exact: Closed, limited extension
- Implementation time | Odoo: 3–9 months | Exact: 1–4 months (accounting only)
- Dutch accounting compliance | Odoo: Strong via NL partner package | Exact: Native, gold standard
- Manufacturing / E-commerce | Odoo: Strong native | Exact: Limited / via integrations
- Pricing model | Odoo: Per user, all modules included | Exact: Per user, tier-based
- Open API | Odoo: Full | Exact: Available, less open

## Five things people actually decide on
1. Starting domain
   Odoo: Odoo is designed to be your ONE system from day one, even if you start with 2-3 modules. The accounting module is solid (and easily compliant with NL standards via partner packs), but you're not paying for an accounting system you'll outgrow.
   Exact: Exact is best-known as accounting software. ERP capabilities have been layered on but it shows: many Exact customers run separate CRM, separate e-commerce, separate project tools. The system was built around the books.
   Verdict: Accounting-only or accounting-first? Exact is great. Multi-domain from day one? Odoo.

2. Customization
   Odoo: Open-source codebase, Python modules, full API. We can build the integration or custom workflow you need, you keep the code. When your process is genuinely non-standard, this matters.
   Exact: Closed platform. Configurable but not deeply extensible. If your process needs to bend the system, you bend the process instead.
   Verdict: Custom process? Odoo. Standard process? Exact gives you fewer moving parts.

3. Pricing
   Odoo: Per-user, all-modules-included. Standard plan from ~€20/user/month (SaaS); Custom plan ~€35/user/month for Odoo.sh/self-hosted with custom code. No per-module add-on fees.
   Exact: Tier-based per-user. The accounting tier is competitive for small bookkeeping needs; full ERP tiers are higher.
   Verdict: Small accounting need? Exact's entry tier is cheap. Multi-module ERP? Odoo is usually cheaper at equivalent scope.

4. Switching cost
   Odoo: Open-source means data portability and partner choice. If you're unhappy with us, another partner can pick up your project. Your code stays yours.
   Exact: Tightly coupled to the vendor. Switching to a different system later means re-implementation and data migration; common but painful.
   Verdict: Want optionality? Odoo. Want to commit to one vendor for the long haul? Exact.

5. Manufacturing, e-commerce, projects
   Odoo: First-class modules. BOMs, MRP, work orders, online webshop, project profitability tracking: all native, all sharing the database.
   Exact: These domains are addressed via integrations or thinner modules. Functional but not the strongest fit.
   Verdict: You make things, sell online, or run project-based work? Odoo is the better fit.

## Pick Odoo if…
- Your business spans more than accounting: sales, ops, projects, manufacturing, e-commerce.
- You expect to grow and want a system that grows modularly.
- Custom workflows or integrations matter for your process.
- You want to keep options open for partner-switching later.

## Pick Exact if…
- Your need is primarily accounting / bookkeeping and you want best-in-class Dutch tax compliance.
- Your scope is unlikely to expand much beyond finance.
- You prefer a closed, lower-decision-fatigue platform.
- You're already on Exact and the cost-to-switch outweighs the benefits.

## FAQ
Q: What is the best alternative to Exact?
A: Odoo is the most common alternative to Exact for SMBs that want more than accounting: it puts finance on the same platform as CRM, sales, inventory, manufacturing, projects and e-commerce, so you stop stitching Exact to separate tools. Exact stays a fine fit if you only need accounting; Odoo wins once the rest of the business needs to be integrated.

Q: What is the difference between Odoo and Exact Online?
A: Exact Online is strong in bookkeeping and light ERP. Odoo is broader, with 80+ apps for sales, e-commerce, inventory, manufacturing, projects, HR and finance on one database. For pure administration Exact remains fine. To grow into a full ERP, Odoo gives more room.

Q: Does Odoo have the same Dutch accounting features as Exact?
A: Yes. Odoo Accounting supports Dutch VAT (BTW) declaration, SEPA, eHerkenning, UBL, automated bank reconciliation and the Dutch chart of accounts. The module has been production-ready for the Netherlands since 2022 and is widely accepted by Dutch accountants.

Q: How does Odoo pricing compare to Exact Online?
A: Odoo Standard starts around €20/user/month with all apps included. Exact Online charges per module package starting around €40/month. For administration only Exact can be cheaper. Once you need three or more modules (sales, inventory, projects), Odoo gets more affordable.

Q: When do you pick Exact and when Odoo?
A: Exact: when you want pure administration, don't need breadth and the standard works fine. Odoo: when you want sales, manufacturing, projects or e-commerce next to finance in one system, and you're ready to do an implementation.


# Odoo vs Salesforce. Where each one wins.
URL: https://www.fanatics.nl/odoo-vs-salesforce
Language: en

## Verdict
Salesforce is the gold standard for CRM at scale, if your sales team is large, your sales process is complex, and you have the budget. Odoo wins when CRM needs to share a database with inventory, finance, projects and e-commerce, and when the per-seat Salesforce cost stops making sense. Many SMBs start on Salesforce because it's the famous name, then switch to Odoo when the back-office fragmentation gets in the way.

## At a glance
- Scope | Odoo: Full ERP (CRM + 79 more modules) | Salesforce: CRM-first (Sales Cloud is core)
- Per-user pricing (entry) | Odoo: ~€20–35/user/month, all-modules | Salesforce: ~€80–€175/user/month, by tier
- Customization | Odoo: Open-source, full code access | Salesforce: Apex + Visualforce; closed
- Back-office (inventory, finance) | Odoo: Native, same DB | Salesforce: Via 3rd-party apps or AppExchange
- Sales team scale | Odoo: Fits 5–500 well | Salesforce: Built for 50–50,000+
- Implementation time | Odoo: 3–9 months | Salesforce: 6–18 months (enterprise scope)
- Sales-specific features | Odoo: Good but lighter | Salesforce: Industry-leading (forecasting, territory)
- App ecosystem | Odoo: Odoo apps (~40K) | Salesforce: AppExchange (~7K, deeper)

## Five things people actually decide on
1. Sales depth vs business breadth
   Odoo: Odoo's CRM covers the core: pipeline, contacts, quoting, automation, forecasting. Not as deep as Salesforce's Sales Cloud: no native territory management, less sophisticated forecasting AI, smaller third-party plugin ecosystem for sales-specific tools.
   Salesforce: Salesforce was built around sales, and it shows. Best-in-class pipeline visibility, forecasting, territory management, sales coaching, enablement tools. If your sales process has multiple stages, regions, hierarchies, and KPIs, Salesforce handles it natively where Odoo would need configuration.
   Verdict: Pure sales depth? Salesforce. CRM as part of one connected business? Odoo.

2. Total cost of ownership
   Odoo: Per-user pricing is roughly half Salesforce's at the entry level. The standard plan includes nearly all modules: no per-module surcharge for the core. Customization and implementation are competitive too.
   Salesforce: Per-user list price runs €80–€175/month depending on tier. Add Service Cloud, Marketing Cloud, CPQ. Each is its own subscription. Multi-product Salesforce deployments at 50+ users routinely cost 3-5x equivalent Odoo.
   Verdict: Cost-sensitive? Odoo wins, often by a lot. Enterprise budget that prioritizes feature depth? Salesforce earns its price.

3. Customization model
   Odoo: Open-source. You can read the code, change it, take it to another vendor. Custom Python modules. Integration via standard API. When you need real flexibility, you have real flexibility.
   Salesforce: Closed platform with a deep developer ecosystem: Apex code, Lightning components, declarative tools. Highly customizable within the Salesforce world, but you can't take that customization anywhere else.
   Verdict: Want vendor-portability? Odoo. Want deep customization inside Salesforce? Salesforce delivers, at a price.

4. Back-office integration
   Odoo: Sales sees inventory levels. Quote becomes an order, becomes a stock pick, becomes an invoice. All in one database. Finance, projects, manufacturing: all native.
   Salesforce: Salesforce is the front office. Inventory, finance, manufacturing, projects all live in third-party AppExchange tools or in a separate ERP (often Microsoft Dynamics or NetSuite). Integration tax is real.
   Verdict: Multi-domain business? Odoo's integration is built-in. Sales-only org? Doesn't matter for you.

5. Reporting and analytics
   Odoo: Reports, dashboards, pivot tables: all in-platform, no extra cost. Easy enough for end-users; powerful enough for finance.
   Salesforce: Salesforce reports are very good; CRM Analytics pushes into actual BI territory. But the strongest capabilities live in higher-tier products with their own pricing.
   Verdict: Sales-specific BI? Salesforce. Cross-domain operational reporting in-tool? Odoo.

## Pick Odoo if…
- You're SMB scale (5–500 employees), CRM is one of several systems you need.
- Sales connects to inventory, projects, finance, and you want one source of truth.
- Cost-per-seat matters, especially as your team grows.
- You want open-source flexibility and vendor portability.

## Pick Salesforce if…
- Sales is your primary domain and you have 50+ reps with complex processes.
- You need best-in-class forecasting, territory management, and sales analytics.
- Budget for premium per-seat pricing is available.
- You're already deeply embedded in the Salesforce ecosystem (Marketing Cloud, AppExchange).

## FAQ
Q: What is the difference between Odoo and Salesforce?
A: Salesforce is a deep CRM platform and a market leader in enterprise sales and service. Odoo is a broad ERP platform where CRM is one of many apps. For CRM-only with enterprise requirements Salesforce remains deeper. For SMBs wanting CRM alongside sales, inventory and finance, Odoo is simpler and cheaper.

Q: Is Odoo a good alternative to Salesforce for CRM?
A: For SMBs with up to a few hundred users, yes. Odoo CRM covers pipelines, email templates, automations, lead scoring and integrations with website and bookkeeping. For enterprise scenarios with hundreds of custom workflows, Salesforce remains a deeper platform.

Q: How does Odoo CRM compare in pricing to Salesforce?
A: Salesforce starts at around €25/user/month (Starter) and quickly scales to €150-300 for Enterprise. Odoo CRM is included in every Odoo subscription starting at €20/user/month, with all other modules bundled. For SMBs Odoo is 3-10x cheaper in licenses.

Q: When do you pick Salesforce and when Odoo?
A: Salesforce: when your organization is large, you need heavy automations and budget is not the main constraint. Odoo: when you're an SMB, want CRM-breadth combined with finance, inventory and e-commerce, and cost and simplicity matter.


# Odoo vs Shopify. Where each one wins.
URL: https://www.fanatics.nl/odoo-vs-shopify
Language: en

## Verdict
Shopify is unmatched if your business IS the storefront: fast time-to-market, beautiful themes, vast app ecosystem, frictionless checkout. Odoo wins when e-commerce is one face of a larger operation: inventory across warehouses, manufacturing, B2B portals, project-based work, multi-channel sales. The decision is really about how much of your business lives behind the shop.

## At a glance
- Storefront UX | Odoo: Functional, less polished | Shopify: Best-in-class
- Time to first store | Odoo: Weeks (with ERP setup) | Shopify: Days
- Inventory across multi-warehouse | Odoo: Native, sophisticated | Shopify: Add-ons / Shopify POS Pro
- Manufacturing / BOM | Odoo: Native (MRP) | Shopify: Not supported
- B2B portals | Odoo: Native | Shopify: Shopify Plus tier only
- Accounting | Odoo: Native, full | Shopify: Integration to external (QB / Xero)
- Themes / customization | Odoo: Modest theme library | Shopify: Huge theme/app marketplace
- Pricing model | Odoo: Per user, all modules included | Shopify: Per store + % transaction fees

## Five things people actually decide on
1. Storefront and time-to-market
   Odoo: Odoo's webshop is functional and integrated, but Shopify's storefront experience is in a different league: themes, page-builders, checkout UX, mobile performance. If your primary KPI is conversion-rate, Shopify has a head-start measured in years.
   Shopify: Shopify gets you live in days, with a beautiful storefront, mobile-optimized checkout, and a marketplace of plugins for every niche tweak. Time-from-zero-to-selling is unmatched.
   Verdict: If the shop IS the business, Shopify. If the shop is one channel among many, Odoo.

2. Back-office and ERP
   Odoo: Inventory across multiple warehouses, manufacturing (BOMs, MRP, work orders), accounting, HR, project tracking, all native, sharing one database with the shop. When a sale happens, inventory updates, accounting books, manufacturing schedules adjust, without integration glue.
   Shopify: Shopify ends at the order. Inventory beyond the storefront, manufacturing, accounting, HR, all live in separate tools or integrations. Each integration is a thing to maintain (and pay for).
   Verdict: Need real ERP behind the shop? Odoo. Shop-only or shop + light back-office? Shopify with apps.

3. B2B and complex pricing
   Odoo: Native B2B portal: per-customer pricing, payment terms, ordering against quotes, hidden products. Built into the standard product, no special tier required.
   Shopify: Shopify Plus required for B2B features (~$2,300/month list). The B2B features are good once you have Plus, but the price gap is significant.
   Verdict: B2B or mixed B2C+B2B? Odoo is cheaper at scope. Pure B2C scaling fast? Shopify Plus has the playbook.

4. Customization and platform-lock
   Odoo: Open-source. Your shop logic, integrations, custom modules, you own the code. If you ever need to move (or even just switch implementation partner), the door is open.
   Shopify: Closed platform. Shopify Liquid templating is powerful within the box. Outside the box, you work on Shopify's roadmap. Migrating to another platform later is non-trivial.
   Verdict: Want optionality? Odoo. Happy committing to Shopify long-term? Closed is faster.

5. Total cost
   Odoo: Per-user subscription, all modules included. No transaction fees on your own sales. Implementation upfront, but recurring cost stays flat with growth.
   Shopify: Shopify Basic/Standard/Advanced runs €29–€289/month, cheap to start. BUT: payment processing fees apply per transaction (~1.7-2.6%), and apps add up fast. At scale (€1M+/year in sales), Shopify can cost more in app + transaction fees than running Odoo with native everything.
   Verdict: Small starter shop? Shopify is cheaper. Mid-scale (€1M+ revenue) with ERP needs? Odoo often wins on total cost.

## Pick Odoo if…
- E-commerce is one channel, you also have B2B, wholesale, retail, or manufacturing.
- You need real ERP behind the storefront (multi-warehouse, MRP, project work).
- You want B2B portals without upgrading to a premium tier.
- Total cost matters more than out-of-the-box storefront polish.

## Pick Shopify if…
- Your business IS the storefront, D2C, fashion, lifestyle brand.
- Time-to-market is critical and you want to be selling in days.
- You want the best app ecosystem for storefront tweaks and marketing tools.
- You're happy to bolt on accounting / inventory externally if needed.

## FAQ
Q: What is the difference between Odoo and Shopify for e-commerce?
A: Shopify is a specialized webshop platform with a large app ecosystem for B2C merchants. Odoo eCommerce is one part of a broader ERP. Inventory, manufacturing, finance and service sit in the same database. Shopify has a faster time-to-launch; Odoo needs no integrations between webshop and back office.

Q: Can Odoo replace Shopify Plus?
A: For mid-market B2B and B2C with manufacturing or complex inventory movements, often yes, because everything lives in one system. For pure B2C with high volumes, international marketplaces and dependency on specific Shopify apps, Shopify remains stronger.

Q: How does Odoo's pricing compare to Shopify Plus?
A: Shopify Plus starts around €2,000/month. Odoo eCommerce + Sales + Inventory + Finance is included in every Odoo subscription (€20-35/user/month). For SMBs with 5-20 users and direct ERP integration Odoo is significantly cheaper.

Q: Does Odoo work well for B2B e-commerce?
A: Yes. Odoo eCommerce supports customer portals, per-customer pricelists, credit limits, B2B payment terms and self-service quotes. Combined with CRM, inventory and finance, you have an end-to-end B2B flow without external integrations.


# Odoo vs Microsoft Dynamics. Where each one wins.
URL: https://www.fanatics.nl/odoo-vs-dynamics
Language: en

## Verdict
Microsoft Dynamics 365 (Business Central for SMB, F&O for enterprise) is a strong choice if you're already deep in the Microsoft ecosystem (Azure, Teams, Power Platform) and want tight integration with that stack. Odoo wins on cost, time-to-implement, and openness, and is a better fit for SMBs that aren't already committed to Microsoft. The decision often comes down to existing IT stack and team familiarity.

## At a glance
- Target segment | Odoo: SMB to mid-market | Microsoft Dynamics: SMB (BC) to enterprise (F&O)
- Per-user pricing | Odoo: ~€20–35/user/month | Microsoft Dynamics: ~€100–€210/user/month
- Implementation time | Odoo: 3–9 months | Microsoft Dynamics: 6–18 months
- Open-source | Odoo: Yes | Microsoft Dynamics: No, proprietary
- Microsoft ecosystem integration | Odoo: Via connectors | Microsoft Dynamics: Native (Teams, Azure, Power BI)
- Customization | Odoo: Python modules, full code | Microsoft Dynamics: AL extensions (BC) / X++ (F&O)
- Manufacturing depth | Odoo: Strong native | Microsoft Dynamics: Strong (especially F&O)
- Partner ecosystem | Odoo: 5,000+ global | Microsoft Dynamics: Massive (10K+) but enterprise-skewed

## Five things people actually decide on
1. Cost and pricing model
   Odoo: From €20/user/month (Standard, SaaS) to ~€35/user/month (Custom, for Odoo.sh/self-hosted with custom code). All modules included at both tiers. Implementation is a separate one-time cost. No per-transaction or per-document fees.
   Microsoft Dynamics: Business Central runs ~€100–€210/user/month (Essentials vs Premium tiers). F&O is more, often €210+/user/month. Implementation is typically more expensive too, given the partner ecosystem skews enterprise.
   Verdict: Cost-sensitive SMB? Odoo, often by 2-3x. Already paying Microsoft per-user pricing for other licenses? Marginal cost is lower.

2. Microsoft ecosystem integration
   Odoo: Connectors exist for Outlook, Teams, OneDrive, Azure AD, but they're connectors, not native. If your team lives in Microsoft 365, integration works, but it's not seamless.
   Microsoft Dynamics: Dynamics is built BY Microsoft FOR Microsoft. Teams, Outlook, SharePoint, Power BI, Power Automate, all native, deep, polished. If you're a Microsoft shop, this is the single biggest reason to pick Dynamics.
   Verdict: Microsoft-shop? Dynamics's integration is hard to beat. Mixed/open stack? Odoo doesn't impose a lock-in.

3. Customization model
   Odoo: Open-source codebase, Python custom modules, full API. We write the code, you keep the code. Move to another partner if you need to.
   Microsoft Dynamics: Closed but extensible. Business Central uses AL for extensions; F&O uses X++. Extensions are well-supported but live inside Microsoft's runtime. Partner-portability is harder.
   Verdict: Want code you can take elsewhere? Odoo. Comfortable inside Microsoft's customization model? Dynamics.

4. Implementation speed
   Odoo: Modular design means you can go live in 3-6 months for a focused scope. Partner network is wide; we (and others) can typically start within weeks.
   Microsoft Dynamics: Dynamics implementations average 9-18 months, partly due to deeper enterprise feature scope, partly due to a partner ecosystem optimized for larger projects. Quality is high; speed is lower.
   Verdict: Want to be live this year? Odoo. Multi-year enterprise rollout already planned? Dynamics fits that cadence.

5. Long-term ownership
   Odoo: Open-source means you own the code. Migration to a different partner, or even self-hosting, is on the table. License costs are predictable; customizations are portable.
   Microsoft Dynamics: Microsoft owns the platform. License costs change at Microsoft's pace. Custom AL/X++ code is portable between Microsoft partners but locked to the Dynamics runtime.
   Verdict: Long-term ownership and flexibility matter? Odoo. Trust in Microsoft platform direction? Dynamics is bet-on-Microsoft.

## Pick Odoo if…
- You're SMB to mid-market and cost-per-seat matters at scale.
- You're not already deeply committed to the Microsoft 365 ecosystem.
- You want open-source flexibility and partner portability.
- You want to be live in 3-9 months, not 12-18.

## Pick Dynamics if…
- You're already running Microsoft 365 (Teams, Azure, Power BI) and want native integration.
- You're enterprise-scale and need F&O's depth in manufacturing, supply chain, finance.
- You have the budget for premium per-seat pricing.
- You want to bet on Microsoft's long-term platform direction.

## FAQ
Q: What is the best alternative to Microsoft Dynamics?
A: Odoo is the most common alternative to Microsoft Dynamics in the SMB and mid-market: the same process breadth, but more open, faster to adapt and with lower total cost. Dynamics stays a logical fit for those deep in the Microsoft ecosystem who need enterprise governance; Odoo wins on agility and price - the reason Rhea Vendors switched.

Q: What is the difference between Odoo and Microsoft Dynamics 365?
A: Dynamics 365 is Microsoft's enterprise suite (Business Central for SMB, F&O for enterprise) with deep Office and Teams integration. Odoo is an open-source ERP with 80+ apps on one database, aimed at SMB through mid-market. Dynamics is stronger in Microsoft-stack environments; Odoo is simpler and cheaper for the average SMB implementation.

Q: Which is better for SMB: Odoo or Dynamics 365 Business Central?
A: For most SMBs Odoo is lighter to implement and cheaper in licenses. Business Central is stronger when your organization is already deep in the Microsoft stack (Power BI, Teams, Azure AD) and you have consultancy budget for a longer implementation.

Q: How does Odoo's pricing compare to Dynamics 365 Business Central?
A: Business Central Essentials runs around €95/user/month, Premium €135. Odoo Standard sits at around €20/user/month, Custom €35, with all 80+ apps included. For SMBs with 10-50 users, Odoo is 3-5x cheaper in licenses.

Q: When do you pick Dynamics 365 and when Odoo?
A: Dynamics 365: you're deep in the Microsoft stack, have enterprise requirements (Power Platform, AI Copilot) and an enterprise budget. Odoo: you're an SMB, want to implement fast and pragmatically, and don't want to pay for features you don't use.


# Odoo vs Lightspeed POS. Which one fits your shop?
URL: https://www.fanatics.nl/odoo-vs-lightspeed
Language: en

## Verdict
Lightspeed is an excellent till: fast to go live, lovely to work with at the counter, strong hardware and payments. Odoo isn't a standalone till, it's one system that also runs your inventory, accounting, webshop and purchasing. Got one shop and not much behind it? Stay with Lightspeed. Got a webshop alongside, multiple locations, or an inventory that already doesn't add up? That's when Odoo starts paying for itself.

## At a glance
- How it works at the counter | Odoo: Functional, integrated | Lightspeed: Years-refined, very strong
- Hardware and payments | Odoo: Solid, growing | Lightspeed: Mature, built-in
- Time to go live | Odoo: Weeks | Lightspeed: Fast
- Inventory across shop and webshop | Odoo: In one system | Lightspeed: Separate or via integration
- Accounting | Odoo: Built in | Lightspeed: Separate tool + integration
- Webshop | Odoo: Built in | Lightspeed: Separate e-commerce line or integration
- One system for everything | Odoo: Yes | Lightspeed: No, integrations between tools
- Ownership of your system | Odoo: Self-host, your data | Lightspeed: Lightspeed cloud

## Five things it really comes down to
1. A till, or a whole system?
   Odoo: Odoo isn't a standalone till. It's one system doing everything at once: till, inventory, accounting, webshop, customer records. Ring something up at the counter? Inventory updates immediately and the sale posts to the books, in the same system, with nothing to integrate.
   Lightspeed: Lightspeed shines at the counter: fast to go live, lovely to work with, with strong hardware and payments. Everything after that, inventory across channels, accounting, webshop, is a separate tool you wire into the till.
   Verdict: Want the best counter experience? Lightspeed. Want the till to be part of the whole system? Odoo.

2. One shop? Keep it simple.
   Odoo: For one shop or cafe, Odoo is heavier than you need. Buying a whole business system to run one till is taking a forklift to fetch a coffee.
   Lightspeed: One shop, one cafe, or a small chain whose world is 'ring it up and look good'? Lightspeed is hard to beat: the fastest route to a polished counter, years of front-of-house experience, hardware and payments that just work.
   Verdict: If that's you, you probably shouldn't switch.

3. More than just a till?
   Odoo: Inventory, accounting, purchasing and the webshop all run on the same database as the till. No nightly sync, no 'which number is right now', no integrations to maintain. And it grows with you: wholesale, B2B, manufacturing or more locations are modules you switch on, not separate systems you buy.
   Lightspeed: Strong at the counter, but everything behind it is another system you connect to it. Grow toward multiple channels, locations or a webshop and those connections, and their cost, stack up.
   Verdict: Multiple channels, or growth toward wholesale or manufacturing? That's when one system earns its keep.

4. The integrations you don't see
   Odoo: There's nothing to integrate, because it's already one system. Inventory, accounting, purchasing and the webshop share the same database as the till.
   Lightspeed: A standalone till looks cheaper than a complete system, until you add up what it doesn't do. Inventory across channels, accounting, purchasing, a webshop: each is another tool, and every tool has to be wired to the till. Those connections are real software someone has to build, pay for, and keep working through every update.
   Verdict: You don't see that cost in the demo. It shows up six months later, when a price change in one system never reached the other and your shop-floor stock is wrong.

5. Multiple tills? That changes the math.
   Odoo: The more tills and locations you have, the more Odoo works in your favour: you pay per user, not per till. And because the software is open, you can self-host it, your data and customizations stay yours.
   Lightspeed: Fine for one counter. But every extra till, location or integration adds to the bill. And your data and logic live in the Lightspeed platform, not in a system you own.
   Verdict: One till? The gap is small. Multiple tills or locations? Then it starts to count.

## Pick Odoo if…
- You have multiple channels (shop + webshop), or you're growing toward wholesale or manufacturing.
- Your inventory sync already hurts: manual, too slow, or the numbers don't match. Like at Wijnwinkel Barneveld, who switched from Lightspeed to Odoo for exactly that reason.
- You want till, inventory and books in one system, with nothing to integrate.
- You want to own your system: self-host, your data and customizations in your hands.

## Pick Lightspeed if…
- You have one shop or cafe and not much behind the scenes, and it works.
- Your world is 'ring it up and look good': no webshop, no wholesale.
- You want a polished counter quickly, with hardware and payments that just work.
- Buying a whole business system to run one till feels like a forklift for a coffee, because it is.

## FAQ
Q: What is the best alternative to Lightspeed?
A: For retailers who want more than a till, Odoo is the most common alternative to Lightspeed: POS, inventory, purchasing, webshop and accounting on one platform, so the shop floor and the back office share the same truth. Lightspeed stays a strong standalone till; Odoo wins once you want to move off separate tools - as Wijnwinkel Barneveld did.

Q: What are you hearing lately from Lightspeed users?
A: Over the past few months, more businesses have come to us wanting to move from Lightspeed to Odoo. That's our own intake talking, not market research, but the pattern is consistent enough to write down. Three reasons keep coming back. We pass them on as signals, not verdicts: we haven't independently checked Lightspeed's roadmap, and you're reading this on the site of a partner that builds Odoo. Weigh them, and test them against your own experience.

Q: "Lightspeed's attention is on e-commerce."
A: Several teams tell us the energy in the product seems to have shifted toward a newer e-commerce line, and that the till they bought it for is no longer the centre of gravity. What's on anyone's roadmap we can't confirm, but if you feel it too, it's worth naming.

Q: "Not much is being developed."
A: The sense that the pace of improvement on the till itself has slowed. Subjective, and easy to over-weight on a few loud voices, test it against your own release notes and your own wishlist.

Q: "The inventory integration leaves something to be desired."
A: The most concrete complaint, and the easiest to verify yourself: look at how your till and your inventory actually stay in sync today, how often, how manually, and how often the numbers are wrong. If that already hurts, it's a real signal.

Q: And if none of this sounds familiar?
A: Take that as a good sign and stay where you are. We'd rather see you keep a working system than switch on a rumour, even one we're passing along.

Q: Has anyone actually made the switch?
A: Yes. Wijnwinkel Barneveld was on Lightspeed and moved to Odoo: shop, POS, inventory, webshop and accounting on one platform, with an Exact Online integration. Read the case.


# Odoo vs Zoho. Suite, or single source of truth?
URL: https://www.fanatics.nl/odoo-vs-zoho
Language: en

## Verdict
Honestly: a real comparison is barely possible, because these are fundamentally different products with different philosophies. Zoho is a collection of business apps under one login and one logo - excellent for early-stage companies that need a single Zoho product. Odoo is one integrated platform where CRM, sales, inventory, manufacturing, projects, helpdesk, timesheets and invoicing share the same data model. Single sign-on isn't single source of truth. A suite is only really a suite when your process doesn't start over at every module boundary.

## At a glance
- Philosophy | Odoo: One integrated platform | Zoho: Collection of separate apps under one login
- Data model | Odoo: One database, shared objects | Zoho: Per-module, syncs between Commerce, Inventory, Books, CRM
- MSP / helpdesk | Odoo: Helpdesk + Contracts + Timesheets native | Zoho: Zoho Desk + ManageEngine ServiceDesk Plus MSP (separate product line, one-way sync)
- RMM / endpoint management | Odoo: Not built in; clean integration with external RMM tools | Zoho: Endpoint Central MSP, Site24x7, MSP Central (limited integration between modules)
- eCommerce + inventory + accounting | Odoo: One customer view, one product model | Zoho: Commerce ↔ Inventory ↔ Books ↔ CRM, sync settings per integration
- Manufacturing / MRP | Odoo: Multi-level BOM, work orders, routing, QC, costing | Zoho: Composite items for light assembly; multi-level BOM is a community request
- Projects → hours → invoice | Odoo: One operational screen | Zoho: Zoho Projects ↔ Zoho Books with sync, duplication settings, error overviews
- Customisation | Odoo: Open-source Python modules, the code is yours | Zoho: Deluge + custom functions inside the Zoho platform
- Ownership | Odoo: Self-host, your data and code | Zoho: SaaS at Zoho Corporation

## Five module boundaries where 'suite' breaks
1. MSP process: Zoho Desk and ServiceDesk Plus MSP aren't one system
   Odoo: One platform with CRM, Helpdesk, Contracts, Timesheets and Invoicing on the same data model. A ticket knows which customer, which contract, which SLA and which hours. Worklogs aren't 'synced' to accounting - they live there already.
   Zoho: For real MSP/ITSM functionality you quickly end up with ManageEngine ServiceDesk Plus MSP - part of the Zoho Corporation world, but functionally a separate product line. The integration with Zoho CRM is a one-way sync of accounts and requesters (add and update only), with worklogs going back toward Zoho Books. Exactly the kind of 'it integrates with CRM' where you later discover: yes, but not the way my process actually means.
   Verdict: Single sign-on isn't single source of truth. For MSP processes, that gap becomes felt quickly.

2. RMM and monitoring live in ManageEngine, not in Zoho
   Odoo: RMM stays an external world; Odoo doesn't compete there. But the commercial and operational process around it - customer, contract, asset, ticket, hours, invoice, renewal - runs on one data model, not on four systems that have to sync.
   Zoho: There's no 'Zoho RMM'. You end up at Endpoint Central MSP, Site24x7 and the MSP Central bundle. Recent reviews mention 'limited integration between modules' and a steep learning curve. Even inside the MSP bundle, it's multiple good tools behind one portal, not one data model or one workflow engine.
   Verdict: Several good tools behind one portal isn't the same as one continuous workflow.

3. eCommerce, inventory and accounting: four modules, four truths
   Odoo: Webshop, inventory and accounting all run on the same database. B2B price lists, returns, reservations and backorders are modules on the same model - not four tools that have to talk to each other. One customer, one product, one order, one stock move, one invoice.
   Zoho: Zoho's own documentation describes how Commerce, Inventory, Books and CRM influence each other, how guest customers land in Books and which sync settings you choose. In practice: for every process you have to decide where your truth lives - and remake that decision at every exception, return or B2B pricing rule.
   Verdict: For simple sales it works. As soon as complex pricing, returns or B2B appear, you feel where the seams run.

4. Manufacturing: light assembly versus real MRP
   Odoo: Multi-level BOMs, work orders, routing, work centres, capacity planning, MTO/MTS, lot and serial traceability, quality controls and costing on the same model as inventory and sales. From a single production order you see materials, labour, scrap and inventory valuation come together.
   Zoho: Zoho Inventory has 'composite items' for light assembly. Multi-level or 'exploded' BOMs have been a community request for years. For 'product A is made of part 1, 2 and 3' it works. As soon as you need real BOMs, work centres, planning, quality control and costing, it gets thin - or you end up working outside Zoho anyway.
   Verdict: For trade with light assembly, Zoho is fine. For real manufacturing, it gets puzzle-shaped fast.

5. Ownership: your code and data, or Zoho's?
   Odoo: Open-source under LGPLv3. Customisation is Python code you can take to another partner or self-host. Your data lives in a database you can back up, export and migrate. Switching partners is on the table.
   Zoho: Customisation in Deluge and custom functions lives on the Zoho platform. Licensing, availability and roadmap sit with Zoho Corporation. For a small team that's no issue; for an MSP or manufacturer with long-term dependencies it's a trade-off worth naming.
   Verdict: Not a moral question - just a sober one: how much dependency are you taking on a platform that isn't yours?

## Pick Odoo if…
- You are an MSP, manufacturer or B2B organisation with processes touching multiple departments: lead → customer → contract → asset → ticket → hours → invoice → renewal.
- You want out of the integration tax between CRM, inventory, accounting and projects - one data model.
- You need B2B price lists, returns, reservations or multi-level BOMs.
- You want to own your code and data, with the option to self-host and switch partners.
- You recognise what FritsJurgens or 181 describe: the same Zoho limitations, the same switch.

## Pick Zoho if…
- You are an early-stage company and you need one specific Zoho product (Zoho Mail, Zoho CRM, Zoho Books). Cheap, fast to deploy.
- You are a service business or marketing-driven organisation with simple processes that don't cross module boundaries.
- You are a small trader with limited inventory complexity and no manufacturing.
- Low licence costs matter more to you than process depth across modules.
- Single sign-on and shared branding are your definition of "integrated".

## FAQ
Q: Tim, what's your own experience with Zoho?
A: I once tried running an IT company on Zoho myself. I came back from that quickly: I discovered Zoho is essentially a bought-and-stitched-together suite, with often patchy integrations between the various product lines. For my own MSP process it ended up feeling like a collection of tools behind one login, not one system. Not bad software - just not what I needed in an MSP.

Q: Is Odoo really comparable to Zoho?
A: Honestly: barely. They are fundamentally different products with different philosophies. Zoho is a collection of separate business apps - each strong on its own - with shared login and branding. Odoo is one platform where CRM, sales, inventory, manufacturing, projects, helpdesk, timesheets and invoicing share the same data model. If you're looking for a single app, Zoho is great. If you have a continuous process across multiple departments, Odoo is more natural.

Q: When is Zoho fine and shouldn't I switch?
A: For early-stage companies and small organisations that need one specific Zoho product. Zoho Mail for email, Zoho CRM for your sales pipeline, Zoho Books for your accounting - each is solid and affordable on its own. If your process doesn't cross those module boundaries, switching is unnecessary and Zoho gives you good value.

Q: Which customers have switched from Zoho to Odoo recently?
A: Among others FritsJurgens and 181. Both hit the same limitation: their operation ran across CRM, inventory, projects and invoicing, and the Zoho integrations between those modules became harder to maintain than having the whole system in one platform.

Q: But Zoho does integrate CRM, Books and Inventory, doesn't it?
A: At the 'sync records' level, yes. Zoho's own documentation for the CRM ↔ Desk integration describes how Contacts, Accounts and Products get synchronised, but notes that the relationships between products and contacts/accounts aren't automatically preserved - you need workflows and Deluge/custom functions for that. Useful, but it's a different concept than one shared data structure across modules.

Q: How does the MSP stack compare: Zoho Desk vs ManageEngine ServiceDesk Plus MSP?
A: For real MSP/ITSM functionality you end up with ManageEngine ServiceDesk Plus MSP - part of Zoho Corporation, but functionally a separate product line. The integration with Zoho CRM is a one-way sync (accounts and requesters from Zoho to ServiceDesk Plus MSP; worklogs back to Zoho Books). For RMM/monitoring you sit with Endpoint Central MSP and Site24x7, or the MSP Central bundle. Recent reviews mention 'limited integration between modules' inside that bundle. It's several good tools behind one portal, not one data model.

Q: Does Odoo always fit better, then?
A: No. For a service business with a simple process, a marketing-driven organisation or an early-stage company, Zoho is often cheaper and faster to deploy. The question isn't 'which is better', it's 'which fits how deep your process runs through your organisation'. For MSP, manufacturing, B2B eCommerce and project-driven businesses with inventory, Odoo is more natural. For a 12-person marketing agency, Zoho often is.


# Odoo vs HubSpot. Market leader, but what does it really cost?
URL: https://www.fanatics.nl/odoo-vs-hubspot
Language: en

## Verdict
HubSpot is the market leader - and for good reason. No other product combines CRM, marketing automation, email flows, landing pages and sales pipelines as tightly in one place. For sales- and marketing-driven teams who run their pipeline seriously, HubSpot is hard to beat. The other side: tier-creep. The basics are fine, but you quickly bump into menu options that only exist in a higher tier - especially once you want Marketing, Sales and Service together. Starts low (around €50/month), but stacks toward €700 or €2,500. For customers already deep in HubSpot, we sometimes propose a third option: keep HubSpot for marketing and sales, run Odoo underneath for operations, inventory, projects and invoicing. Best of both worlds, via integration.

## At a glance
- Strongest point | Odoo: One platform from CRM to invoice | HubSpot: Market leader in CRM + marketing automation
- Target | Odoo: SMB / scale-up with ops + finance | HubSpot: Sales- and marketing-driven teams
- Marketing automation | Odoo: Present, functional | HubSpot: Best-in-class: workflows, lead scoring, A/B
- Pipeline + deal management | Odoo: Integrated with invoicing and inventory | HubSpot: Tight, with deep reporting and attribution
- Starting price | Odoo: ~€20/user/month | HubSpot: Free CRM + Starter around €20-€50/month
- Price curve | Odoo: Predictable per user | HubSpot: Jumps toward €700-€2,500+ when stacking Marketing+Sales+Service on Pro/Enterprise
- Inventory, manufacturing, projects | Odoo: Native, on one database | HubSpot: Not present - requires a separate system
- Accounting | Odoo: Native module | HubSpot: Not present - integration with Books/Exact/Twinfield
- Customisation | Odoo: Open Python, the code is yours | HubSpot: Workflows + custom objects inside HubSpot
- Integration between the two | Odoo: Native via the Odoo HubSpot connector | HubSpot: Bi-directional sync of contacts, deals, invoices

## Five module boundaries where 'all-in-one' breaks
1. CRM + marketing: HubSpot leads here, let's be fair
   Odoo: Odoo has CRM, email marketing, marketing automation, landing pages and forms - all integrated with sales orders, invoicing and projects on one database. Functionally strong enough for most SMB cases where marketing is a supporting process.
   HubSpot: No one combines CRM, marketing automation, email flows, landing pages, forms, A/B tests and sales pipelines as tightly in one product as HubSpot. Workflows with conditional logic, lead scoring, multi-touch attribution: enterprise-grade in a UI that stays workable.
   Verdict: For pure CRM + marketing, HubSpot is the best tool on the market. Not a marketing claim - that is just the market.

2. Tier-creep: starting cheerful, hitting menu boundaries fast
   Odoo: One Odoo licence gives access to all 80+ apps. CRM, sales, marketing, projects, helpdesk, accounting: switch them on without paying again. The licence grows per user, not per feature.
   HubSpot: HubSpot's Starter tier is fine for basic CRM and simple mailings. But workflows with conditional logic, custom reports, A/B tests, lead scoring and multi-touch attribution sit in Professional. Custom objects, SLAs and advanced permissions sit in Enterprise. Want Marketing and Sales and Service together on Pro? It stacks.
   Verdict: You start low and end high. Not by upsell magic - just because your process pushes you toward features that live in higher tiers.

3. The €50 → €700 → €2,500 price curve
   Odoo: From around €20/user/month (Standard SaaS) up to about €35/user/month (Custom on Odoo.sh, for customisation). All modules included. Implementation is a separate one-off, not a per-feature licence.
   HubSpot: Starter Suite starts around €20-€50/month for small teams. Marketing Hub Professional sits in the hundreds per month; Sales and Service Pro on top push you toward €700-€1,000+. Enterprise - what you need for custom objects, multi-team architecture and advanced reporting - easily climbs to €2,500+ per month. (Snapshot - check current HubSpot pricing for your situation.)
   Verdict: HubSpot is not an expensive tool, until you actually use it fully. For SMBs with three hubs on Pro, the moment "what does this cost?" tips is the inflection point.

4. All-in-one or best-of-breed?
   Odoo: Odoo is all-in-one across the board: CRM and inventory and manufacturing and projects and accounting on one database. Marketing is good enough, but not the centre of gravity. If marketing is your core process, Odoo's marketing is not your best pick.
   HubSpot: HubSpot is best-of-breed in CRM + marketing, but stops where operations begin. No inventory, no manufacturing, no projects, no full accounting. What HubSpot does, it does superbly; what sits underneath is for another system.
   Verdict: Marketing-driven SaaS, agencies, B2B lead-gen: HubSpot. Operations-heavy businesses (manufacturing, B2B trade, project-driven): Odoo. For both: see pillar 5.

5. The third option: HubSpot + Odoo via integration
   Odoo: For customers deep in HubSpot for marketing and sales, who also have a real operation (inventory, projects, invoicing), we sometimes propose a hybrid: HubSpot on top (lead capture → marketing automation → sales pipeline → deal closed), Odoo underneath (customer view, inventory, projects, invoicing, contracts, support). A bi-directional sync keeps contacts, deals and invoices consistent.
   HubSpot: HubSpot itself offers an Odoo app in the marketplace. Bi-directional: contacts, companies and deals to Odoo; sales orders and invoices back. Not perfect (a true single source of truth still lives in one system), but for businesses that don't want to give up HubSpot's marketing power and at the same time need an ERP layer, it's a workable middle path.
   Verdict: Not for everyone, but an honest third option - especially when your marketing investment in HubSpot is already large and switching doesn't make sense.

## Pick Odoo if…
- Your process lives deep in operations: inventory, manufacturing, projects, invoicing - not just sales pipeline.
- You want predictable per-user costs, with all modules included.
- You're fine with marketing-as-feature; you don't have a marketing team that lives in the system.
- You want open code and data: self-host, switch partners, your code.
- You're cost-conscious SMB with more than just CRM.

## Pick HubSpot if…
- Marketing or sales is your core process; your team lives in workflows, sequences, forms and reports.
- You're a sales- or marketing-driven SaaS, agency or B2B lead-gen organisation.
- You seriously use marketing automation, A/B tests, lead scoring or attribution reporting.
- You don't have a complex operation underneath: accounting can be separate, inventory barely exists.
- You have Pro/Enterprise budget and consciously choose the best CRM + marketing tool on the market.

## FAQ
Q: Tim, what's your own experience with HubSpot?
A: I used HubSpot myself at one of my companies. The basics were fine - CRM, a few emails, forms - that worked. What disappointed me was how quickly you get seduced by menu options that only exist in a higher tier. Upgrade notifications kept coming, especially once I wanted Sales and Support alongside Marketing. It's not a scam - those features really do sit in higher tiers - but as your process pushes you there, you discover that 'starter' becomes 'professional' fairly fast, and that's a very different number.

Q: Is HubSpot really the market leader in CRM + marketing?
A: Honestly: yes. For pure CRM + marketing automation, HubSpot is the best tool on the market. No other product combines CRM, email flows, landing pages, A/B tests, lead scoring and sales pipelines as tightly. Salesforce can do it too but feels heavier; Pipedrive or ActiveCampaign are lighter. HubSpot sits in the sweet spot for sales- and marketing-teams that run their pipeline seriously.

Q: What does HubSpot actually cost?
A: Honestly: it depends on so much that a fixed answer would mislead. Starter Suite starts low (around €20-€50/month for small teams). But most of the features you actually pick HubSpot for - workflows with conditional logic, custom reports, lead scoring, attribution - sit on Professional. Marketing Hub + Sales Hub + Service Hub on Pro adds up to €700-€1,000+/month quickly. Enterprise, for custom objects and multi-team architecture, climbs toward €2,500+/month. Check current HubSpot pricing for your situation - it is what it is, not cheap or expensive in itself, but it stacks faster than many buyers expect.

Q: When is HubSpot fine and shouldn't I switch?
A: When marketing and sales are your core process and your team genuinely lives in workflows and sequences. When you have no complex operation underneath: accounting can be separate, inventory barely exists, projects are small. When you have consciously accepted Pro/Enterprise budget. In that case HubSpot is a very solid investment and switching to Odoo is a strange optimisation.

Q: Is there an Odoo HubSpot integration?
A: Yes. HubSpot offers an Odoo app in its marketplace and there are community modules for the other direction. Bi-directional: contacts, companies and deals sync with partners, sales orders and invoices, and vice versa. Not perfect (a real single source of truth still lives in one system), but for businesses with serious HubSpot investment and a growing operation, it is a workable middle path.

Q: When is the 'third option' (HubSpot + Odoo via integration) logical?
A: When your marketing investment in HubSpot is already large - workflows running, attribution set up, your team knows the system - and at the same time you need an ERP layer for inventory, projects, manufacturing or invoicing. It is not 'best of both worlds' magic; it is a deliberate hybrid with a sync in between that you have to manage. But for businesses where switching to Odoo-only would throw away too much marketing work and HubSpot-only can't carry the operation, it is the most pragmatic route.

Q: Does Odoo always fit better than HubSpot, then?
A: No. For a sales- or marketing-driven team without operations underneath, HubSpot is often more natural and stronger. The question isn't 'which wins' - it's 'where does your centre of gravity sit'. Marketing/sales-heavy → HubSpot. Operations-heavy → Odoo. Both → integration.


# Odoo vs Monday. Make work visible, or hold the truth?
URL: https://www.fanatics.nl/odoo-vs-monday
Language: en

## Verdict
Monday is brilliant at making work visible, governable and flexible. But it gets dangerous when customers start using it as pseudo-ERP. Monday wins on flexibility, speed of understanding and adoption by non-technical teams. Odoo wins as soon as the process has to be financially, logistically or operationally reliable. My rule: Monday is for organising work - Odoo is for holding the transactions. Shorter: use Monday for overview, use Odoo for truth.

## At a glance
- Category | Odoo: All-in-one ERP | Monday: Work management platform
- Strongest point | Odoo: One process from CRM to invoice | Monday: Making work visible and governable
- Data model | Odoo: Fixed, transactional, with general ledger | Monday: Flexible boards, columns and views
- Inventory / manufacturing | Odoo: Native MRP, BOM, lot/serial traceability | Monday: Not designed for it
- CRM | Odoo: Integrated with invoicing and inventory | Monday: Monday CRM, visual pipeline-driven
- Projects / planning | Odoo: Present, task-oriented | Monday: Best-in-class: Gantt, workload, Kanban, dashboards
- Accounting | Odoo: Native module | Monday: Not present - integrates with external accounting
- Adoption by non-technical teams | Odoo: Requires ERP discipline and training | Monday: Quick to grasp, strongly visual
- Audit / source of truth | Odoo: Transactional, with general ledger and VAT logic | Monday: Board-level, not a financial source of truth
- Place in the stack | Odoo: The truth | Monday: The overview

## Five questions that matter
1. Making work visible: Monday wins here
   Odoo: Odoo has Projects, Helpdesk and task boards. Workable for teams already in Odoo. But it is not primarily built to organise work visually and flexibly - the UX is ERP-first, not board-first.
   Monday: Monday feels logical to most users: boards, columns, statuses, deadlines, owners, views, dashboards. You usually do not have to spend weeks explaining how to work with it. For marketing planning, customer onboarding, recruiting, content calendars, internal projects and approvals: best-in-class.
   Verdict: Honestly: for pure work management, Monday is stronger than Odoo. Not a marketing claim - just the UX reality.

2. Pseudo-ERP: where Monday gets dangerous
   Odoo: Item management, inventory valuation, purchasing, sales orders, invoicing, VAT logic, reservations, serial numbers, manufacturing orders, BOMs, warehouse routes, costing, post-calculation, permissions, auditability - all on one database. Transactional, with a general ledger.
   Monday: You can build an 'inventory board' in Monday. Or an 'order board'. Or an 'invoicing board'. Technically it works, but that is different from inventory administration or order processing. No financial source of truth, no transactional integrity, no audit trail an accountant would accept.
   Verdict: Monday can make the work around it visible, but should not become the manufacturing or invoicing system itself. That is the pain point customers come to us with.

3. Freedom in year one, mess in year two
   Odoo: A fixed data model means sales orders, stock moves and invoices have exactly one meaning in the system. Discipline up front, predictability over the long run.
   Monday: Anyone can create boards. Anyone can add columns. Anyone can build views. Delightful at first. After a year: 80 boards, duplicated customer lists, different statuses for the same process, automations no one understands anymore, dashboards that are half right. Monday needs governance - without an owner it becomes a prettier version of Excel chaos.
   Verdict: Monday's strength is also its risk. Decide up front who owns boards, who builds views, who manages automations.

4. Inventory, manufacturing, invoicing: Monday is not designed for the truth
   Odoo: Multiple warehouses, reservations, backorders, dropshipping, barcode scanning, cycle counts, batch/lot/serial, inventory valuation, purchase planning, returns. Multi-level BOMs, work centres, routing, capacity, MTO/MTS, quality controls, post-calculation. All on the same model as CRM and invoicing.
   Monday: For simple tracking - samples, assets, internal stock, marketing materials, laptops, event gear - Monday is fine. But for real inventory or manufacturing it is fragile: no reservations, no multi-level BOM, no serial traceability, no cost calculation that lands in your general ledger.
   Verdict: For deep inventory or manufacturing processes, the truth belongs in Odoo. Monday around it is fine - in place of, not.

5. The third option: Monday on top of Odoo, not instead of
   Odoo: Odoo is the source of truth for customer, product, order, inventory, invoice, project and contract. The transactional work that has to be financially reliable.
   Monday: On top of Odoo you can run Monday as a management and collaboration layer: quarterly planning, marketing calendar, sales campaigns, customer onboarding before the implementation, project portfolio overview, recruitment, HR tasks, leadership action lists, content planning, light approval flows. Work that needs visibility and flexibility, separate from financial truth.
   Verdict: Monday is for organising work - Odoo is for holding the transactions. No sales orders, inventory, manufacturing or invoicing in Monday if Odoo is the source of truth for them.

## Pick Odoo if…
- You have inventory, manufacturing, projects with purchasing, or complex invoicing.
- You need a general ledger: audit trail, VAT logic, financial truth.
- Your process has to be transactionally reliable, with integrity between sales, inventory and accounting.
- You want one data model for customer, product, order and invoice.
- You see yourself growing into serial numbers, multi-level BOMs, or quality controls.

## Pick Monday if…
- You are a marketing agency, professional services firm or software company focused on projects and campaigns.
- Your work is internal planning, customer onboarding, content calendars, recruitment or HR flows.
- Your adoption challenge is bigger than your process challenge - people need to get going themselves quickly.
- You operate without complex inventory or manufacturing underneath.
- You accept that the financial source of truth lives in another system (accounting or ERP).

## FAQ
Q: Tim, when do Monday customers come to you?
A: Almost always at the same point: when they want more ERP function and start hitting the limits. Inventory that no longer matches because six people maintain the same board, invoicing that does not line up with accounting, manufacturing planning that has no link to actual stock. Monday served them well up to that point - work made visible, processes accelerated - but it is not where you hold transactions. Nine out of ten times the conversation ends with "Monday stays, Odoo goes underneath".

Q: Is Monday not an ERP?
A: No. Monday is a work management platform - flexible, visual, strong for planning and collaboration. ERP has a different bar: item management, inventory valuation, purchasing, sales orders, invoicing with VAT logic, reservations, serial numbers, manufacturing orders, BOMs, costing, post-calculation, permissions and auditability on one transactional data model. Monday is not designed for that, and that is not a shortcoming - it is a different product.

Q: But you can build anything in Monday, right?
A: Technically you can recreate a lot: an order board, an inventory board, an invoicing board. But recreating is not the same as having. There is no general ledger, no VAT logic, no audit trail an accountant accepts, no transactional integrity between sales, inventory and accounting. For a marketing plan none of that is needed; for your invoicing it is.

Q: When is Monday the right choice?
A: For marketing agencies, professional services firms, software companies and project-driven teams without complex inventory or manufacturing. For internal projects, customer onboarding, recruiting, HR flows, marketing calendars and light approval flows. And for scale-ups that want temporary structure without immediately starting an ERP track - provided they put governance in up front.

Q: Does Odoo always fit better, then?
A: No. For pure work management, Monday is stronger than Odoo - the UX and adoption are not comparable. The question is which layer you need. Work that should be visible? Monday. Transactions that have to be reliable? Odoo. Both? Both, with a clear line between them.

Q: Can we use Monday and Odoo together?
A: Yes, and that is often the best solution. Monday on top, Odoo underneath. Monday for quarterly planning, marketing calendar, customer onboarding, project portfolio, recruiting, HR tasks, leadership action lists and content planning. Odoo for sales orders, inventory, manufacturing, invoicing, contract administration and the general ledger. A light sync on top (deals, customers, project statuses) can help, but the source of truth stays clear per layer.

Q: What if we are already deep in Monday and now need an ERP?
A: Keep Monday for work management - there is probably a lot of configured work you do not want to throw away. Add Odoo for the transactional layer (sales, inventory, manufacturing, invoicing, accounting). Start with a Quickscan where we decide per process: 'does this belong in Monday or in Odoo'. A good conversation about what-goes-where is far more valuable than an impulsive 'all in one'.


# Odoo vs Teamleader. From quote to invoice, or lead to delivery?
URL: https://www.fanatics.nl/odoo-vs-teamleader
Language: en

## Verdict
Teamleader is solid when your business is mostly about customers, quotes, projects, time and invoicing. It runs into limits as soon as your processes become logistical, inventory-driven, manufacturing-driven or financially complex. My rule: Teamleader organises your customer work - Odoo organises your business. Sharper: Teamleader is strong from quote to invoice; Odoo is strong from lead to delivery, inventory, manufacturing, service and accounting. Teamleader sits between Monday/Zoho and Odoo: less flexible than Monday, less deep than Odoo, but inside its niche - the standard service flow - often a fine choice.

## At a glance
- Category | Odoo: All-in-one ERP | Teamleader: Business management for service firms
- Strongest point | Odoo: One process from CRM to manufacturing and ledger | Teamleader: CRM → quote → project → invoice in one flow
- Target | Odoo: SMB with ops + finance | Teamleader: Small and mid-size service businesses
- Data model | Odoo: Fixed and extendable via Python modules | Teamleader: Fixed - field relations have limited customisability ("not customisable" per reviews)
- Inventory | Odoo: Native, multi-warehouse, lot/serial | Teamleader: Products on quotes/invoices, no full inventory management
- Manufacturing | Odoo: Native MRP, BOM, routings, QC | Teamleader: Not designed for MRP
- eCommerce | Odoo: Native webshop on the same database | Teamleader: Not present
- Accounting | Odoo: Native module | Teamleader: Not present - integrates with external accounting
- Reporting | Odoo: Multi-dimensional + API for BI | Teamleader: Strong for pipeline/projects/time, limited for advanced analytics
- Automation | Odoo: Workflow engine + server actions + Studio | Teamleader: Strong on basic workflows, limited at conditional multi-step
- Export & migration | Odoo: Open Python, your data in your own database | Teamleader: Limited - reviews mention "lousy export functionality"
- Pricing model | Odoo: Per user, all modules included | Teamleader: Entry-level affordable; project mgmt, planning, lead capture as package extensions

## Five questions that matter
1. CRM → quote → project → invoice: Teamleader wins here for service firms
   Odoo: Odoo does this flow too (CRM, Sales, Project, Timesheets, Invoicing are all native), but it is broader. For a pure service business with no inventory or manufacturing, that can feel like "too much platform".
   Teamleader: Teamleader Focus is built around exactly this flow: capture customer, follow up deal, build quote, convert quote into project or invoice, track time, invoice. One click to turn a quote (or part of it) into a project or invoice. For agencies, consultants, installers and creative businesses, that feels far more natural than a heavy ERP.
   Verdict: For pure service firms without inventory/manufacturing, Teamleader is often faster live and simpler than Odoo. Not bashing - just the fit.

2. Data model: how far does 'standard' take you?
   Odoo: Odoo has a fixed data model, but the codebase is open-source Python. Field relations, custom objects, multi-company structures and exceptional processes are all reachable through custom modules. The cost lives in implementation and discipline, not in a ceiling.
   Teamleader: Teamleader has a fixed data model that works well for the standard flow. But public reviews flag limited customisability: a 2024 Trustpilot review explicitly calls it "not flexible, not customisable" and says field relations cannot be adjusted. For a small service business that is rarely an issue. For a growing organisation with exceptions, it is.
   Verdict: Standard processes: fine in Teamleader. Non-standard or multiple business units with different flows: friction.

3. Scale: deals, contacts, attribution, reporting
   Odoo: Multi-company, multi-currency, segmentation per channel/team/business unit, lead attribution, and direct API access for Power BI or Looker. Reporting grows with the organisation.
   Teamleader: A Capterra review from a 2+ year user notes that the way deals, contacts and companies are linked makes it hard to keep a good sales flow structure as the organisation grows. The same review calls out "lousy export functionality" and the absence of attribution. Reviews praise reporting for the basics (pipeline, projects, time) but flag it as limited for advanced analytics, multi-dimensional reporting and forecast-vs-actuals.
   Verdict: Multiple contacts per customer, multiple sites, holdings, campaign source, lead attribution, different sales processes: technically possible, but more puzzle than a platform built for it.

4. Inventory, manufacturing, eCommerce: not the natural core
   Odoo: Inventory, manufacturing and eCommerce all run on the same data model as CRM and invoicing. Multi-warehouse, reservations, backorders, multi-level BOM, work centres, quality control, returns, dropshipping, webshop with B2B price lists - all native modules.
   Teamleader: Teamleader lets you put products on quotes and invoices, and has work orders for light field service. But reviews make clear it is not a full inventory product, not an MRP, not an eCommerce platform. For warehouse routes, batch/lot/serial, inventory valuation, complex purchasing or webshop orders, Teamleader is not the right base.
   Verdict: For customers with inventory, manufacturing or eCommerce, the operational core belongs in Odoo. Teamleader can wrap around it - not be it.

5. Place in the stack: between Monday/Zoho and Odoo
   Odoo: Odoo is the deepest platform: one operational process from lead to delivery, inventory, manufacturing, service and accounting. Demands more choices and implementation discipline.
   Teamleader: Teamleader sits squarely in the middle: less flexible than Monday as a generic workflow layer, less deep than Odoo as an ERP, but inside its niche (CRM/quote/project/invoice for service firms) often more natural than either. A good middle solution - until the business model outgrows it.
   Verdict: For service firms with standard processes, Teamleader is a strong choice. Add inventory, manufacturing, eCommerce, multi-administration, or push reporting deep, and you get pushed toward Odoo - or Monday on top of Odoo. The middle solution has a natural ceiling.

## Pick Odoo if…
- Beyond projects you also have inventory, purchasing, manufacturing, eCommerce, subscriptions, service or warehouse processes.
- Your process has to be reliable financially, logistically or operationally, with audit trail and general ledger.
- Your organisation runs multiple administrations, business units or sites.
- You want advanced reporting, attribution, forecast-vs-actuals or API access for BI.
- You want to own your code and data, with the option to self-host and switch partners.

## Pick Teamleader if…
- You are a service business: agency, consultancy, small/mid-size installer, IT services or architecture/interior firm.
- Your process is CRM → quote → project → time → invoice, in that order, without many exceptions.
- You have no inventory or manufacturing underneath. Products on quotes/invoices is enough.
- You accept that accounting lives in a separate package, linked via e-invoicing and accounting sync.
- You want to go live quickly and independently, without an ERP implementation track.

## FAQ
Q: What is the best alternative to Teamleader?
A: Odoo is the usual alternative to Teamleader once you need more than CRM, projects and invoicing: inventory, purchasing, manufacturing or a webshop. You keep the same lead-to-invoice flow, but on a platform that grows with you. Teamleader stays fine for agencies and consultancies with a standard service flow; Odoo wins once the operation broadens.

Q: Tim, what's your own experience with Teamleader?
A: I have worked with Teamleader a few times and on paper it looks strong. CRM → quote → project → invoice runs fast, it is clean, and users are usually positive at first. But I kept bumping into a few fundamental things that simply could not be done: field relations you cannot adjust, limited attribution, reporting not deep enough for management decisions, and exports that disappoint as soon as you want to seriously analyse or migrate. Not bad software - just the natural ceilings of a product built for the standard service flow.

Q: Is Teamleader bad software?
A: No, the opposite. For service firms that want CRM, quotes, projects, time and invoicing in one simple flow, Teamleader is often fine. Faster live, easier to grasp and cheaper than an Odoo implementation. The question is not 'is Teamleader good', it is 'does Teamleader fit how complex your process is going to get'.

Q: When do you still recommend Teamleader?
A: For agencies, consultancies, small installers, IT services, architects and creative firms with a standard quote-project-invoice flow and no inventory or manufacturing underneath. For companies that say "we want to finally get customers, quotes, projects, time and invoices in one clean flow". Then Teamleader is often faster, cheaper and simpler than Odoo.

Q: Why do customers eventually hit a wall?
A: Reviews on Trustpilot, Capterra, G2 and Software Advice point to recurring patterns: the data model is not flexible ("not customisable", fixed field relations), deals/contacts/companies get harder at scale, reporting is good for basics but limited for advanced analytics, exports disappoint ("lousy export"), integrations are narrower than larger platforms, automation is basic (no complex conditional multi-step), and pricing climbs through package extensions like project management, planning and lead capture. For standard processes none of that is a problem. For growing organisations, it is.

Q: Does Odoo always fit better?
A: No. For pure service firms without inventory or manufacturing, Teamleader is often more natural and faster live. An Odoo implementation demands process choices, configuration and discipline. Teamleader you can stand up independently far quicker. The question is not 'which wins' - it's 'does your process fit Teamleader's standard flow, or does it need more'.

Q: What are the real costs compared?
A: Teamleader looks simply priced, but features like project management, planning and lead capture come as package extensions. On the pricing page they show up as boosters/add-ons. Odoo works differently: from around €20/user/month (Standard) to about €35/user/month (Custom) with all 80+ modules included. Implementation is a separate one-off. When comparing, do not stack entry price against entry price - stack real total cost for your function need.

Q: When is Odoo the logical next step?
A: As soon as your process broadens beyond service: inventory, manufacturing, eCommerce, complex subscriptions, multiple administrations, warehouse processes, complex purchasing or multi-company. As soon as reporting has to go deep: attribution, multi-dimensional, forecast-vs-actuals, BI via API. As soon as automation gets complex: conditional multi-step workflows, server actions, integration with niche systems. That is when you hit Teamleader's natural ceiling - not a bug, just where the product ends.


# Odoo vs NetSuite. Enterprise power, or ERP without enterprise complexity?
URL: https://www.fanatics.nl/odoo-vs-netsuite
Language: en

## Verdict
NetSuite is a mature, serious cloud ERP for international, finance-driven and inventory-/order-driven businesses. But over time users run into implementation complexity, escalating total cost, performance, reporting expertise, customisation debt and partner dependence. We recently migrated a customer from NetSuite to Odoo for one concrete reason: the annual NetSuite licence cost alone was higher than Odoo's licences plus the one-off migration cost. My rule: NetSuite is strong, but heavy. Odoo is often faster, more open and a better fit for European SMB businesses that don't want to become an enterprise ERP organisation. Sharper: NetSuite gives you enterprise power, Odoo gives you ERP power without enterprise complexity.

## At a glance
- Category | Odoo: All-in-one ERP (open source) | NetSuite: Cloud ERP (Oracle), enterprise-positioned
- Target | Odoo: SMB to mid-market | NetSuite: Mid-market to enterprise, often international
- Licence cost | Odoo: ~€20-€35/user/month, all modules included | NetSuite: Premium pricing per edition, modules, users, service tiers, SuiteCloud, sandbox
- Implementation time | Odoo: 3-9 months for scoped projects | NetSuite: 6-18+ months, typically with more upfront preparation
- Data model & customisation | Odoo: Open Python modules, the code is yours | NetSuite: SuiteScript / SuiteFlow / SuiteBundler - powerful but specialist
- Inventory / warehousing | Odoo: Native MRP, multi-warehouse, lot/serial | NetSuite: Strong, with WMS and demand planning as add-ons
- Manufacturing | Odoo: Native MRP, BOM, routings, QC | NetSuite: Strong, demands solid implementation
- eCommerce | Odoo: Native webshop on the same database | NetSuite: SuiteCommerce or integration with Shopify/Magento
- International finance | Odoo: Multi-company, multi-currency native | NetSuite: Mature, one of its strongest points
- UX | Odoo: Modular, more modern | NetSuite: Functionally rich, often described as dated and click-heavy
- Performance on large datasets | Odoo: Scales via Odoo.sh / self-hosting | NetSuite: Reviews flag slowness on heavy saved searches and high transaction volumes
- Partner dependence | Odoo: Open ecosystem, partners are swappable | NetSuite: Higher - contracts, scripts and bundles are specialist
- Ownership | Odoo: Open source, self-hosting possible | NetSuite: SaaS at Oracle

## Five questions that matter
1. NetSuite is a mature, serious ERP
   Odoo: Odoo is a mature open-source ERP with 80+ modules on one database. For SMB to mid-market it is broadly applicable; it only gets heavy at enterprise scale when the organisation adds enterprise discipline as well.
   NetSuite: NetSuite is a serious cloud ERP platform from Oracle with deep finance, internationalisation, order management, inventory, manufacturing and commerce. For growing mid-market businesses with international finance complexity, it can be the right scale. Reviews name real-time dashboards, centralised finance and operations and a single source of truth as strong points.
   Verdict: Honestly: NetSuite is not a toy. For some businesses it is the logical step up. The question is whether that step up matches your organisation and your budget.

2. Total cost: licence is not the whole bill
   Odoo: From around €20/user/month (Standard SaaS) to about €35/user/month (Custom on Odoo.sh). All 80+ modules included. Implementation is a separate one-off. No per-module fees, no separate sandbox costs on base plans, no service-tier staircase.
   NetSuite: NetSuite is premium-priced. The total bill stacks from edition, modules, users, service tier, SuiteCloud licences, sandboxes, support/SLA and training - plus implementation and partner work. Reviews and price guides point out that the entry price is not the end price and that costs climb modularly. A real comparison is not licence-vs-licence; it is three-year TCO including everything.
   Verdict: We recently migrated a customer from NetSuite to Odoo. Their annual NetSuite licence cost alone was higher than Odoo licences plus the one-off migration. A year in, the business case had already passed break-even. Not a marketing number - that was the actual bill on the table.

3. Customisation: power and technical debt
   Odoo: Open-source Python modules. Customisation is code you can take to another partner or self-host. There is no platform-specific runtime: a competent Python developer can read, maintain and extend an Odoo module.
   NetSuite: NetSuite is very customisable through SuiteScript, SuiteFlow and SuiteBundler. Reviews praise that customisation. But consultants and users also warn about technical debt: many scripts, workflows, custom records and exceptions can affect performance, maintainability and upgrades. "NetSuite can adapt to anything" is a benefit at first; "nobody dares touch this script anymore" can be the later reality.
   Verdict: Both systems can carry a lot of customisation. The difference sits in accessibility: with Odoo the bar for a good developer is lower; with NetSuite each change more often needs a SuiteScript specialist.

4. Implementation and partner dependence
   Odoo: An Odoo implementation of 3-9 months for scoped projects is realistic. The partner ecosystem is broad and open; switching partners is on the table because the code and data are yours.
   NetSuite: NetSuite implementations typically take 6-18+ months. Reviews mention lengthy implementation processes, disruptive upgrades and customisation that gets expensive fast. The role of the implementation partner is heavier than with Odoo: contracts, modules, SuiteScript, accounting setup and data model are more complex. A Reddit user described a small FSM customisation that took far longer than promised - anecdotal, but recognisable.
   Verdict: With NetSuite, success depends more heavily on the partner and the internal owner. No enterprise IT organisation? The risk grows, not shrinks.

5. Who fits which?
   Odoo: European SMB and mid-market that want ERP power without becoming an enterprise organisation. Predictable per-user costs, all modules included, faster live, code and data yours. Good for businesses with breadth (inventory, manufacturing, projects, eCommerce) and realistic scope expectations.
   NetSuite: Mid-market and above with international finance complexity, multi-entity multi-currency, heavy governance/audit requirements and an existing Oracle stack or enterprise IT organisation. Businesses that truly need enterprise control and depth and have budget and internal capacity for it. Reviews are more positive among those mid-market customers and more critical from smaller businesses that 'probably never should have bought it'.
   Verdict: NetSuite is not "bad" for SMB - there is just a floor on process maturity, budget and internal capacity. Below that floor, Odoo is more natural.

## Pick Odoo if…
- You are a European SMB or mid-market business that wants ERP power without becoming an enterprise organisation.
- You want predictable per-user costs with all modules included, instead of module-by-module stairs.
- You want to be live in 3-9 months for a scoped project, not 12-18+ months enterprise track.
- You want to own your code and data, with the option to self-host and switch partners.
- You need a serious ERP (inventory, manufacturing, projects, eCommerce, finance) but you don't run an Oracle stack.

## Pick NetSuite if…
- You are a mid-market or enterprise organisation with international finance complexity (multi-entity, multi-currency, complex consolidation).
- You have heavy governance and audit requirements and need enterprise-grade control.
- You are already deep in the Oracle stack or want to deepen it strategically.
- You have an enterprise IT organisation that can manage SuiteScript, SuiteFlow and SuiteCloud, or a strong partner who can.
- You have premium budget and consciously pick enterprise power over entry simplicity.

## FAQ
Q: What is the best alternative to NetSuite?
A: For European SMB and mid-market companies, Odoo is the logical alternative to NetSuite: comparable ERP power without the enterprise complexity, at substantially lower licence cost and with less partner dependence. In a recent migration, the annual NetSuite licences alone cost more than the Odoo licences plus the one-off migration. NetSuite stays strong for those who genuinely need enterprise depth.

Q: Tim, why did one of your customers migrate from NetSuite to Odoo?
A: One concrete reason: the annual NetSuite licence cost alone was higher than Odoo licences plus the one-off migration cost to Odoo. Not "a bit higher" - high enough that the entire business case paid back inside a year. On top of that came the second reason we hear more often: NetSuite is hard to change, and when you do change it, it costs a lot. For this customer - a European SMB with international ambitions but no enterprise IT organisation - Odoo was simply the better fit. A year on, they run faster live, with more modules, for less money.

Q: Is NetSuite bad software?
A: No, the opposite. NetSuite (Oracle) is a mature, serious cloud ERP for mid-market and enterprise. Real-time dashboards, strong finance, internationalisation, order management and inventory - those are real strengths. The question is not 'is NetSuite good', it's 'does NetSuite match your scale, budget and internal capacity'. For some businesses it's the right step up; for others it's overkill.

Q: What does NetSuite actually cost?
A: Not what the entry licence suggests. The total bill stacks from edition, modules (manufacturing, WMS, SuiteCommerce, etc.), users, service tier, SuiteCloud licences, sandboxes, support/SLA and training - plus implementation and partner work. Reviews and price guides note that entry price is not end price and that costs climb modularly. An honest comparison with Odoo is about three-year TCO including everything, not entry licence next to entry licence.

Q: When is NetSuite the right choice?
A: For mid-market and enterprise organisations with international finance complexity (multi-entity, multi-currency, complex consolidation), heavy governance/audit requirements, and an existing Oracle stack or enterprise IT organisation. For businesses that truly need enterprise control and have budget plus internal capacity for it. Reviews are more positive from exactly those mid-market customers and more critical from smaller businesses that probably never should have bought it.

Q: Does Odoo always fit better?
A: No. For an internationally operating mid-market business with deep finance complexity and an existing Oracle stack, NetSuite can be the right scale. The question is not 'which wins', it's 'which fits your organisation, your scale and your budget'. For European SMB that don't want to become enterprise, Odoo is often more natural. For international enterprise with an Oracle stack, NetSuite can be.

Q: How much customisation is realistic in NetSuite?
A: A lot. SuiteScript, SuiteFlow and SuiteBundler are powerful and reviews praise that customisation. But that is where the trap lives: many scripts, workflows, custom records and exceptions can lead to technical debt, performance issues and painful upgrades. The rule we apply to every ERP: only build customisation that someone will still be able to maintain in three years. For NetSuite that means a SuiteScript specialist. For Odoo, a Python developer.

Q: What is the difference in implementation time?
A: Odoo implementations of 3-9 months for scoped projects are realistic. NetSuite implementations typically take 6-18+ months, partly due to broader enterprise features, partly because the partner ecosystem is geared toward larger projects. No value judgement - it's just a different cadence. Want to be live this year? Odoo is on the more logical tempo.


# Odoo vs Bemet. Production ERP, or business platform?
URL: https://www.fanatics.nl/odoo-vs-bemet
Language: en

## Verdict
Bemet (formerly Plan-de-CAMpagne) is a serious industry-specific ERP for engineer-to-order manufacturers: quoting, work prep, planning, production, inventory and invoicing sit in its DNA. But many businesses have grown beyond production control alone - they want sales, customer portal, eCommerce, service and finance in one modern browser environment. Two structural pain points come up often: small adjustments cost €10K or more (more rule than exception), and 'cloud' in practice often means hosting via terminal server, not browser-first SaaS. We migrated Argrowteam (Foliekassen) from Bemet to Odoo. My rule: Bemet is strong at the factory - Odoo connects the factory to the rest of the business. Sharper: hosted ERP solves the server location; cloud ERP renews how work gets done.

## At a glance
- Category | Odoo: Open all-in-one ERP | Bemet: Industry-specific production ERP (ECI Bemet, formerly Plan-de-CAMpagne)
- Target | Odoo: SMB to mid-market, broad | Bemet: Engineer-to-order manufacturers: metal, plastics, machine building, tool & die
- Strongest point | Odoo: One process from CRM to manufacturing and ledger | Bemet: Quoting, work prep, planning and MRP in the industry DNA
- Cloud model | Odoo: Browser-first (Odoo Online, Odoo.sh, self-host) | Bemet: Often hosted/RDS - called cloud, in practice terminal server
- CRM + sales | Odoo: Native, integrated with invoicing and inventory | Bemet: Present around quote/calculation, less focused on modern pipeline and marketing
- Quoting + work prep | Odoo: Strong, with configuration | Bemet: Industry DNA, one of the strongest points
- Manufacturing / MRP | Odoo: Multi-level BOM, work centres, routings, quality | Bemet: Strongly positioned for engineer-to-order production
- eCommerce + customer portal | Odoo: Native webshop + portal on the same data model | Bemet: Not the natural core
- Service / aftersales | Odoo: Helpdesk + contracts + tickets native | Bemet: Mentioned, mostly from production delivery
- Accounting | Odoo: Native module | Bemet: Integration with external accounting packages
- Cost per adjustment | Odoo: Open Python modules, broad partner ecosystem, code is yours | Bemet: What we often hear: €10K+ for a relatively simple adjustment is more rule than exception
- Release cadence | Odoo: Annual major release + continuous community updates | Bemet: Industry roadmap; trainings around Qlik and Report Editor for reporting

## Five questions that matter
1. Production core: Bemet wins fairly here
   Odoo: Odoo has Manufacturing (MRP), Inventory, Purchase, Quality and Maintenance on one data model. For engineer-to-order production it can be configured strongly - but you pay for breadth, not for industry-specific calculation rituals.
   Bemet: Bemet descends from Plan-de-CAMpagne and is built around the make process: fast calculation, converting quotes to production orders, materials and operations, capacity, subcontracting, progress, post-calculation. For a work prep planner or production lead in an engineer-to-order maker, it feels natural.
   Verdict: For engineer-to-order manufacturers with deep production processes, do not underestimate Bemet. The question is whether production is the only thing you want to modernise.

2. Plan-de-CAMpagne heritage: industry depth and classical ERP limits
   Odoo: Modern web-first platform. CRM, sales, marketing, eCommerce, customer portal, service, helpdesk and finance live in the same stack as production. One source for customer, product, order, inventory and invoice.
   Bemet: Plan-de-CAMpagne emerged from the Dutch manufacturing industry. Functionally rich on the factory floor, but weaker in modern browser UX, CRM/marketing, eCommerce, customer portal, mobile workflows and API-first integration. Not a production weakness - the classical ERP architecture showing at the edges.
   Verdict: Once you want sales, portal, service and finance modern too, the gap between Bemet strengths and what the market asks for opens up.

3. 'Cloud' is not always cloud: hosted ≠ browser-first
   Odoo: Browser-first. Odoo Online, Odoo.sh or self-host have different trade-offs, but the UI is natively web. No terminal server, no RDS printer wrangling, no Mac incompatibility. Mobile-accessible via app or browser.
   Bemet: Bemet is described as 'on premise or in the cloud'. In practice 'cloud' often means hosting via terminal server or RDS. That is remote access, not modern SaaS. Shop floor feels remote-desktop sluggishness, scaling issues on modern laptops, printer-session noise and limited mobile access.
   Verdict: Hosted ERP solves the server location. Cloud ERP renews how work gets done.

4. Small adjustments, big invoices
   Odoo: Open Python modules. The partner ecosystem is broad (5,000+ globally), switching partners is on the table. Customisation is code you take with you. A small change is - with a good partner - a scoped ticket.
   Bemet: What we often hear from Bemet customers: €10K or more for a relatively simple adjustment is more rule than exception. Not a customer-service issue, but a market-structure issue of industry-specific ERPs: fewer developers per customer, a single partner with deep specialisation, more complex data models under the hood.
   Verdict: You do not feel the difference in year one - you feel it in year three. Argrowteam (Foliekassen) hit exactly that pattern and switched.

5. The question: production control, or business platform?
   Odoo: Odoo connects production to sales, eCommerce, customer portal, service and finance. One browser, one data model, one place where management information converges. For businesses that want to modernise not only the factory but the whole company, that is the more natural pick.
   Bemet: Bemet is production control with the factory at its centre. Sales, customer portal, eCommerce, modern service and cross-domain reporting sit outside the natural core. For pure production optimisation, that can be exactly right.
   Verdict: Not 'which ERP is better'. The real question: is your biggest problem production control, or business-wide coherence? Answer 1: keep looking seriously at Bemet. Answer 2: look at Odoo.

## Pick Odoo if…
- Your business is more than production alone: sales/CRM, eCommerce, customer portal, service and finance need to come together in one modern environment.
- You're done with terminal server / RDS and want browser-first work, from any browser, on any device.
- You want a customer portal or B2B ordering environment that is not a bolt-on next to your ERP.
- You want predictable adjustment costs, not €10K+ per relatively simple change.
- You recognise the Argrowteam (Foliekassen) migration: from Bemet to Odoo because the broader business needed modernisation.

## Pick Bemet if…
- You are an engineer-to-order manufacturer in metal, plastics, machine building or tool & die.
- Your biggest pain sits in calculation, work prep, capacity planning and production control.
- You have limited modern CRM, eCommerce or customer portal demands.
- You accept hosted/RDS working and your IT environment supports it well.
- You value industry-specific ERP function more than platform breadth.

## FAQ
Q: What is the best alternative to Bemet?
A: For manufacturers wanting to move off Bemet/Plan-de-CAMpagne, Odoo is the most common alternative: costing, work preparation and production connected to sales, purchasing, inventory and accounting on one platform. Bemet stays strong as a pure metal package; Odoo wins once you want to modernise more than production alone - as Agrowteam did.

Q: Tim, what's your own experience with Bemet?
A: We recently moved Argrowteam (Foliekassen) from Bemet to Odoo. Not because Bemet was bad at the production core - it suited their make process. The deciders were two things we often hear from Bemet customers: small adjustments structurally costing €10K or more (more rule than exception), and their 'cloud' being hosting via terminal server in practice - not a browser-first experience. Once they wanted sales, customer portal, service and eCommerce modern too, the gap between Bemet and what they needed grew too wide.

Q: Is Bemet bad software?
A: No, the opposite. Bemet (ECI) is an industry-specific ERP for engineer-to-order manufacturers with deep roots in calculation, work preparation, planning and production. For metal, plastics, machine building or tool & die, it is a serious choice. The question is not 'is Bemet good', it's 'does Bemet match what you'll need in three years'.

Q: What is the difference between Bemet and Plan-de-CAMpagne?
A: Same product, evolved. Plan-de-CAMpagne was announced under that name as recently as 2017, and the KING App Store still describes the system that way. ECI now uses Bemet as the brand, but the DNA is the same: production ERP from the classical Dutch manufacturing industry. That history explains both the strong production core and the classical ERP architecture that shows at the digital edges.

Q: What do adjustments in Bemet actually cost?
A: What we often hear: €10K or more for a relatively simple adjustment is more rule than exception. Not a Bemet-specific issue but a market-structure issue of industry-specific ERPs: fewer developers per customer, one partner with deep specialisation, more complex data models under the hood. Odoo's structure is different: open Python codebase, broad partner ecosystem (5,000+ globally), your code and your data. A small change is - with a good partner - a scoped ticket.

Q: Is Bemet cloud or not?
A: Depends on what you call 'cloud'. Capterra describes Bemet as 'on premise or in the cloud'. In practice 'cloud' at many installations means hosting via terminal server or RDS. That is remote access, not a modern SaaS experience. Shop floor feels remote-desktop sluggishness, scaling issues on modern laptops, printer-session noise and limited mobile access. Odoo is browser-first: one modern web UI for sales, production, inventory, portal and finance, from any browser, on any device.

Q: When is Bemet the right choice?
A: For engineer-to-order manufacturers who mainly want to optimise the factory - better calculation, stronger work prep, grip on capacity and planning, better post-calculation - and have relatively limited modern CRM, eCommerce or customer portal demands. For metal, plastics, machine building or tool & die, Bemet is a serious choice. If you mostly hear yourself say 'production needs to be better', Bemet is worth keeping on the table.

Q: Does Odoo always fit better, then?
A: No. For pure production optimisation in a classical maker, Bemet can be stronger than a broad platform that still needs to be configured well. The question is not 'which wins', it's 'what is your biggest problem'. Production control → keep looking seriously at Bemet. Business-wide coherence (production + sales + eCommerce + service + portal + finance on one browser-first platform) → look at Odoo.


# Odoo vs MKG. Metal ERP, or business platform?
URL: https://www.fanatics.nl/odoo-vs-mkg
Language: en

## Verdict
MKG (Metaal Kennis Groep) is a serious industry-focused ERP specialist for Dutch metalworking companies between 5 and 150 employees - clear focus on engineer-to-order production, cloud options, a REST API and an active add-on ecosystem. In metal production MKG wins fair: quoting, work prep, work orders, hours, post-calculation and shop floor sit in its DNA. But it stays primarily a specialised production ERP. Odoo gets stronger the moment you want more than metalworking: CRM, eCommerce, customer portal, service, finance and international growth on one modern browser-first platform. My rule: MKG organises metal production. Odoo connects metal production with the rest of the business. Shorter: MKG is metal ERP. Odoo is business platform with production as one part of the whole.

## At a glance
- Category | Odoo: Open all-in-one business platform | MKG: Industry-specific ERP for metalworking companies (Metaal Kennis Groep)
- Sweet spot | Odoo: SMB to mid-market, broad | MKG: Suppliers, machine/equipment builders, surface treatment, 5-150 employees
- Strongest point | Odoo: One process from CRM to production and ledger | MKG: Quoting, work prep, work orders and post-calculation in industry DNA
- Cloud model | Odoo: Browser-first (Odoo Online, Odoo.sh, self-host) | MKG: Cloud, on-premise, and MKG Terminal Server environments for the client software
- CRM + sales | Odoo: Native, pipeline, marketing and eCommerce on one data model | MKG: Relationship management present, supporting quote and calculation
- Production / MRP | Odoo: Multi-level BoM, work centres, routings, quality | MKG: Strong positioning for engineer-to-order metal production
- eCommerce + portal | Odoo: Native webshop + portal on the same data model | MKG: Not the natural core
- Service / aftersales | Odoo: Helpdesk + contracts + field service native | MKG: Among others via Service Module with McMain as add-on
- Accounting | Odoo: Native module | MKG: Integrated bookkeeping in MKG3
- API + integrations | Odoo: Open source, broad API/custom dev, your own modules in Python | MKG: REST API; in the cloud environment, integrations via add-on partners
- Release cadence | Odoo: Annual major release + continuous community updates | MKG: Industry roadmap; cloud-based ERP under the proALPHA portfolio for metalworking

## Five questions that matter
1. Industry focus: here MKG wins fair
   Odoo: Odoo has Manufacturing (MRP), Inventory, Purchase, Quality and Maintenance on one data model. Strong for engineer-to-order production, but you pay for breadth - not for industry-specific quoting and work-prep rituals that a metalworking company is used to.
   MKG: MKG is built for metalworking companies: machining, sheet metal, surface treatment, welding and structural work, machine building, assembly and tooling. Quick calculation, materials and operations, work orders, hours, work in progress, post-calculation, shop floor. MKG speaks the language of these businesses.
   Verdict: For pure metal production with deep work prep, do not underestimate MKG. The question is whether metal production is the only thing you want to modernise.

2. CRM and commercial: supporting or orchestrating?
   Odoo: CRM, Sales, Website, Marketing, eCommerce and ERP sit in the same stack. Lead scoring, pipeline, marketing campaigns, web forms, email automation, account planning, lost-deal analysis and sales dashboards come together with production and inventory data.
   MKG: Relationship management and CRM exist in MKG and support sales and production. For metal companies with relationship-driven sales and repeat orders that is often enough. For commercial growth with marketing automation, B2B acquisition and pipeline discipline, it is less the natural engine.
   Verdict: Once sales becomes a serious department alongside work prep, the gap appears between what MKG supports and what a modern commercial business needs.

3. eCommerce, customer portal and service: core or edge?
   Odoo: Native webshop, B2B portal, customer login, order status, documents and certificates, online quote requests, configure-to-order, spare parts portal, service tickets, returns - all on the same data model as sales, inventory, production and accounting. Helpdesk, Field Service, Repair and Subscriptions native.
   MKG: eCommerce is not the natural core of MKG. The Service Module is offered among other things via McMain as add-on. Much can be solved via partners or integrations, but the core question is: does it sit in the platform or hang off it?
   Verdict: For a metalworking business that wants a customer portal, B2B order environment, configure-to-order or a professional service flow, Odoo is platform-wise better positioned.

4. Cloud is present, browser-first is something else
   Odoo: Browser-first. Odoo Online, Odoo.sh or self-host have different trade-offs, but the UI is natively web. No terminal server, no RDS session, no Mac incompatibility. Accessible from app or browser on mobile.
   MKG: MKG offers cloud hosting and managed cloud options including backups and version updates. At the same time, documentation describes MKG Client software in a terminal-server environment connecting to the MKG cloud or on-premise server. Cloud accessibility is arranged; browser-first work experience is a separate question.
   Verdict: The right question is not "do you run in the cloud" but "do you work fully in a browser, or via a client and remote session?". That is where the difference shows up on the shop floor.

5. API and integrations: controlled ecosystem or open platform
   Odoo: Open source. As a partner you can build your own Python modules, use APIs, write controllers, extend portals, change workflows, extend the data model and add AI layers. At Fanatics we use our own <a href="https://www.updoo.app/" target="_blank" rel="noopener">Updoo</a> building blocks for configurators, lead capture and integrations.
   MKG: MKG has a REST API. In the MKG cloud environment, third-party integrations are - per the system requirements - available via add-on partners. There are visible API integrations with third-party software (Arkoni, McMain, SOLIDWORKS, logistic scanning systems). Strong in metal context, but controlled through MKG/add-on partners rather than as an open dev platform.
   Verdict: MKG is controlled-extensible inside the metal ecosystem. Odoo is open-extensible as a business platform - matters when speed, openness and innovation weigh in.

## Pick Odoo if…
- Sales and production are not well connected yet, and CRM needs to become a serious department alongside work prep.
- You want a B2B order portal, customer login, online order status, configure-to-order or webshop next to production.
- Service and aftersales is growing: helpdesk, field service, contracts, spare parts and returns in one platform.
- You want to work browser-first on laptop, Mac, tablet and mobile - without terminal server or remote session.
- Integrations need to be more open, faster and cheaper - without depending on a single partner ecosystem.
- You want to connect AI and automation to production and sales without asking add-on partners for permission.
- You want to connect the whole business, not just control metal production.

## Pick MKG if…
- Your business is pure metalworking: machining, sheet metal, surface treatment, welding or structural work, machine building or tooling.
- Quoting, work prep, work orders, hours and post-calculation are the core of your daily work.
- You have no or limited modern CRM, eCommerce or customer-portal ambitions.
- You sit between 5 and 150 employees and value industry know-how over platform breadth.
- You accept client software in a terminal-server environment, or an MKG cloud with integrations via add-on partners.
- There is existing MKG know-how in the organisation and you want little custom dev outside production.

## FAQ
Q: What is the main difference between MKG and Odoo?
A: MKG is a specialised ERP for metalworking companies with deep roots in quoting, work prep, production and shop floor. Odoo is an open, broad business platform that connects production with CRM, sales, website, eCommerce, service, finance and portal on one data model. MKG organises metal production. Odoo connects metal production with the rest of the business.

Q: Is MKG bad software?
A: No, on the contrary. MKG is a serious Dutch industry package with a clear focus on metalworking companies, a logical process from CRM/quoting to production and invoicing, cloud options, a REST API and an active add-on ecosystem. For metal companies that mainly want to control their production process, MKG is a serious choice. The question is not "is MKG good", it is "does MKG fit what you will need three years out".

Q: Does MKG really run in the cloud, or via terminal server?
A: Both, depending on how you set it up. MKG has a cloud offering with backups and updates included, but documentation also describes MKG Client software running in a terminal-server environment connecting to the MKG cloud or on-premise server. Cloud accessibility is arranged; browser-first work experience is a separate question. Odoo is browser-first: one modern web UI from any browser, on any device, with no terminal server or remote session.

Q: What does Fanatics do differently from an MKG partner?
A: An MKG partner specialises in metal production within the MKG platform - strong when production is the only thing you want to modernise. We build Odoo implementations that connect production with CRM, sales, eCommerce, customer portal, service and finance in one modern browser environment. For integrations and specific processes we use our own Updoo building blocks (configurator, lead capture, integrations) so you do not get locked into a closed add-on ecosystem.

Q: How do integrations work if I use Odoo instead of MKG?
A: Odoo is open source: you can build your own Python modules, use REST/XML-RPC, write your own controllers and portals, and extend the data model. In the MKG cloud environment, third-party integrations are mainly available via add-on partners - strongly controlled within the metal ecosystem, but less open. At Fanatics we handle integrations around Odoo via our own Updoo building blocks where that is faster or smarter than custom dev.

Q: When is MKG the better choice?
A: For metalworking companies between 5 and 150 employees where quoting, work prep, work orders and post-calculation are the core, the need for modern CRM/eCommerce/portal is limited, and you are happy with client software in a terminal-server environment or an MKG cloud with integrations via add-on partners. For pure production optimisation in a classic metal business, MKG can be stronger than a broad platform that also needs to be set up well.

Q: Does Odoo always fit better, then?
A: No. The question is not "which wins", it is "what is your biggest problem". Production control in a pure metal business without large commercial or digital ambitions outside production → keep MKG seriously in the running. Whole-business coherence (production + sales + eCommerce + service + portal + finance on one browser-first platform) → look at Odoo. We have no interest in a forced switch; we have interest in you knowing three years out where you stand.