Odoo 19 implementeren zonder iets over te doen: wat je eerst beslist, in welke volgorde, wat je niet migreert en waar het schuurt ten opzichte van 17 en 18

Apps geïnstalleerd voordat iemand bepaalt waar de database draait. Een webshop gekoppeld voordat de catalogus is opgeschoond. Jaren aan facturen geïmporteerd die niemand ooit opent. Dit zijn de volgordefouten die het meeste herwerk opleveren, en Odoo 19 verandert daar niets aan. Wat deze versie ten opzichte van 17 en 18 wel toevoegt, zijn valkuilen die in geen enkel overzicht van nieuwigheden staan.

Wat je beslist voordat je iets aanraakt

Sommige beslissingen zijn aan het begin goedkoop en later duur om terug te draaien. Waar het wordt gehost: in het standaardplan van Odoo Online kun je geen modules met eigen Python-code installeren, dus als je een connector nodig hebt, heeft de hosting al voor je beslist. Community of Enterprise. In Spanje: welk systeem de wettelijke factuur uitgeeft. Als de kassa of de webshop al factureert, mag Odoo dezelfde verkoop niet nog eens factureren, en met VeriFactu laat elke uitgegeven factuur een geketend record achter dat je niet ongedaan maakt. En een zakelijke vraag: welke processen moeten op dag één werken.

De echte volgorde van een project

1. Bedrijf met het juiste land, de juiste valuta en de juiste fiscale gegevens.
2. Grootboekschema, btw en fiscale posities.
3. Stamdata: contacten, producten, varianten, prijslijsten en leveranciers.
4. Processen: verkoop, inkoop, magazijn, facturatie en betaling, één voor één ingesteld en getest.
5. Integraties: webshop, marktplaatsen, vervoerders en bank.
6. Een volledige cyclus op een kopie met echte gegevens: bestelling, levering, label, factuur, betaling en retour.
7. Openingssaldi en voorraad op de afsluitdatum, en dan de start.

De eerste stap lijkt triviaal en is dat niet. Odoo kiest het grootboekschema op basis van het land van het bedrijf bij het installeren van Boekhouding: met het verkeerde land komt er een generiek schema in, en dat later wijzigen botst met rekeningen die al bestaan. De valuta kun je niet meer wijzigen zodra er een boeking is.

Stamdata: hier win of verlies je het project

Eén SKU per product, zonder dubbelen. Varianten als attributen, geen losse producten met de kleur in de naam. Gewicht en afmetingen ingevuld: zonder die gegevens is er geen vervoerderslabel. Contacten zonder dubbelen en met hun btw-nummer. En één verantwoordelijke per blok gegevens. Het loont om het meteen goed te doen, want een product met voorraadbewegingen kun je niet meer verwijderen, alleen archiveren. Sjabloon en details in stamdata voorbereiden vóór de migratie.

Wat je NIET migreert

De verleiding is om alles mee te nemen, en dat loont bijna nooit. Naar Odoo gaan saldi, geen historie: openstaande facturen van klanten en leveranciers, de openingsbalans op de afsluitdatum en de voorraad per locatie op diezelfde datum. De rest blijft erbuiten:

• Facturen en orders van afgesloten boekjaren: die raadpleeg je in het vorige systeem of in een export die je blijft bewaren.
• Oude voorraadbewegingen: je importeert de hoeveelheid per locatie, niet de route van elke eenheid.
• Producten en klanten zonder activiteit: de grens bepaalt de business, niet de technicus.
• Velden die niemand invult en automatiseringen die beperkingen van het vorige programma omzeilden. Die migreren is het probleem migreren.

Bij e-commerce komt de webshop na de catalogus

Bij een Odoo-implementatie voor e-commerce is de eerste beslissing of de webshop Odoo Website wordt of extern blijft. Met Odoo Website valt er niets te synchroniseren, omdat een webbestelling een verkooporder is (wanneer dat past en wanneer niet). Draait de webshop op Shopify of WooCommerce, of verkoop je op marktplaatsen, dan is Odoo de centrale voorraad en de SKU de gedeelde sleutel. Daarom komen de integraties als laatste: een connector die aanstaat op een vuile catalogus verspreidt de rommel over alle kanalen.

Onze gepubliceerde connectoren (Shopify, Amazon, Mirakl, Temu en de rest van de catalogus) werken op Odoo 17, 18 en 19, en de meeste ook op Odoo 20 (elke productpagina vermeldt de versies).

De valkuilen van Odoo 19 ten opzichte van 17 en 18

Voor wie ermee werkt, lijkt Odoo 19 veel op 18. Wat schuurt zit eronder, in modules van derden. Een productpagina die "compatibel met 19" zegt, garandeert niet dat de module installeert: in 19 is de categorie van de toegangsgroepen verhuisd naar een nieuw model, res.groups.privilege, en een haastig overgezette module faalt met Invalid field 'category_id' in 'res.groups' (waarom het compileert maar niet installeert).

De ergste geeft geen foutmelding: in 19 wordt _sql_constraints genegeerd met een waarschuwing in de log. De module installeert, de tests slagen en de uniciteitsregel die voorkwam dat dezelfde bestelling twee keer werd geïmporteerd, staat gewoon niet in de database. En het onkostenrapport (hr.expense.sheet) uit 17 en 18 bestaat niet in 19: een goedkeuringsproces dat erop is gebouwd, moet je opnieuw opzetten. Volledige lijst in dezelfde module onderhouden op Odoo 19, 18 en 17.

Wanneer je geen integrator nodig hebt

Als je Odoo Online gebruikt, je processen in de standaard passen en er geen webshop, marktplaatsen of vervoerders te koppelen zijn, heb je geen engineering nodig: de standaardconfiguratie brengt je tot de start. Ons bellen is zinvol wanneer er verkoopkanalen, integraties, eigen modules of een migratie met op te schonen gegevens zijn; dat doen wij in implementatie van Odoo 17, 18 en 19.

Veelgestelde vragen

Nuttige links binnen FlexigoTech