Overslaan naar inhoud

Odoo BOM en documentstroom voor installatiebedrijven

Wat er verandert als een offerte niet meer handmatig wordt doorgerekend — maar automatisch
11 september 2026 in
Odoo BOM en documentstroom voor installatiebedrijven
Daniel
Deel 2 van 3  ·  Serie: Van offerte tot factuur  ·  Leestijd: ca. 6 minuten
Een spreadsheet, een rekenmachine en veel geduld. Zo maakte een hekwerkinstallateur jarenlang zijn offertes. Tot Odoo het overnam — met één druk op een knop.


In deel 1 van deze serie beschreven we waarom het project overstapte van Odoo Online naar Odoo.sh. Die keuze opende de deur naar iets dat op het standaardplatform niet mogelijk was: een calculatiemodel dat volledig in Odoo leeft, en een documentstroom die van offerte tot factuur in één systeem loopt.

Dit deel gaat over wat er concreet is gebouwd — en wat dat betekent voor de dagelijkse praktijk van de verkoper, de monteur en de boekhouder.


Het vertrekpunt — de spreadsheet als bottleneck

Elke offerte begon hetzelfde. De verkoper opende een Excel-bestand, koos het hekwerktype, vulde het aantal meters in en rekende handmatig de volledige productstructuur door: hoeveel panelen, hoeveel tussenpalen, eindpalen, hoekpalen, doppen, beugels, boutjes, matten. Vervolgens de montage-uren, de materiaalprijzen, de marge. Alles bij elkaar optellen. Een PDF genereren en versturen.

Bij elke wijziging — een andere kleur, een extra meter, een poort die erbij komt — begon het proces opnieuw. De koppeling met inkoop en planning ontbrak volledig: wat in de offerte stond, moest handmatig worden overgenomen in het bestelproces.

Dit is geen uitzonderlijk verhaal. Het is de realiteit bij de meeste installatie- en aannemersbedrijven die met maatwerk offertes werken. De vraag is niet of dit beter kan — de vraag is hoe je het beter inricht zonder de flexibiliteit te verliezen die dit soort werk vereist.


De architectuur — drie lagen, één logica

De kern van de oplossing is een productstructuur in drie categorieën, waarbij elke laag een eigen verantwoordelijkheid heeft.

Laag 1 — Componenten

Componenten zijn de kleinste bouwstenen: een staander, een dop, een beugel, een slotbout. Zij zijn de enige categorie met een directe kostprijs. Op elk component worden twee margepercentages vastgelegd: overhead en winst. Alle prijsberekeningen in het systeem zijn uiteindelijk herleidbaar tot deze laag.

Laag 2 — Halffabrikaten

Halffabrikaten zijn samengestelde producten met een eenvoudige stuklijst: vaste aantallen componenten per eenheid. Een tussenpaal bestaat altijd uit dezelfde combinatie van staander, doppen, beugels en montagemateriaal. Die samenstelling wordt één keer vastgelegd. De kostprijs van het halffabrikaat volgt automatisch uit de onderliggende componenten.

Laag 3 — Eindproducten

Eindproducten bevatten een complexe stuklijst die werkt per strekkende meter, gecombineerd met de zogenaamde hartmaat — de onderlinge afstand tussen de palen. Die combinatie bepaalt automatisch hoeveel tussenpalen er nodig zijn bij een gegeven lengte. De kostprijs en verkoopprijs van het eindproduct zijn volledig afgeleid van de onderliggende halffabrikaten en componenten. Er is geen handmatige prijsinvoer op dit niveau.


Waarom deze structuur werkt

Doordat alleen componenten een kostprijs hebben, is de prijsberekening volledig transparant en centraal beheersbaar. Een prijswijziging bij een leverancier wordt één keer doorgevoerd op het component — alle halffabrikaten en eindproducten die dat component bevatten, zijn direct actueel. Geen verborgen marges, geen verouderde prijzen in losse spreadsheets.


De offerte in de praktijk — wat de verkoper doet

Het offerteproces is teruggebracht tot twee handelingen: eindproduct kiezen en het aantal meters invullen.

Op basis van die twee gegevens laadt Odoo automatisch de volledige lijst van halffabrikaten en componenten. De hartmaat van het gekozen hekwerktype bepaalt het aantal benodigde tussenpalen. De stuklijst van elk halffabrikaat vult de componentenaantallen in. De kostprijzen en marges berekenen de verkoopprijs. Dit gebeurt in één beweging, zonder handmatige tussenkomst.

De begeleidende teksten — projectomschrijving, specificaties, uitvoeringsdetails — zijn onderdeel van de stuklijst en worden automatisch meegeladen. De offerte is daarmee voor circa 99% voorbereid op het moment dat de verkoper op bevestigen drukt.

Flexibiliteit waar het nodig is

Automatisering betekent hier niet: niet meer aanpassen. De verkoper behoudt volledige vrijheid om tot op componentniveau wijzigingen door te voeren — een andere kleur, een afwijkende paalafstand, een specifiek component vervangen. Na elke aanpassing kan de offerte opnieuw worden doorgerekend. Het systeem volgt de logica van het werk, niet andersom.

Kortingslogica zonder margerisico

Via een prijslijst kan de verkoper een kortingsniveau toepasssen op de offerte. Die korting wordt uitsluitend verrekend met de winstmarge — nooit met de kostprijs of de overhead. Een negatieve marge is daarmee structureel onmogelijk, ongeacht welk kortingsniveau de verkoper kiest. De commerciële beveiliging zit in de architectuur, niet in een procedure.


Voor en na — het verschil in de praktijk


Voorheen — Excel

Nu — Odoo

Productstructuur handmatig doorrekenen per offerte

Eindproduct + meters → volledige structuur automatisch geladen

Prijswijziging doorvoeren in elk open offertebestand afzonderlijk

Prijswijziging één keer op het component — direct actueel in het hele systeem

Offertetekst handmatig opstellen per project

Begeleidende teksten automatisch meegeladen vanuit de stuklijst

Geen koppeling tussen offerte en inkoop of planning

Order stuurt automatisch inkooporders, leverbon en montagebon aan

Korting handmatig berekenen — risico op verliesgevende offerte

Kortingslogica werkt op winstmarge — negatieve marge onmogelijk


Wat de klant ziet — en wat de organisatie ziet

De kracht van de Kit/BOM-constructie zit in het onderscheid tussen de klantversie en de interne versie van dezelfde offerte.

De klant ontvangt een heldere, overzichtelijke offerte: één regel per eindproduct, met de omschrijving, het totaalbedrag en de relevante projectspecificaties. Geen componentenlijst, geen artikelcodes, geen interne prijsopbouw. Een turnkey propositie — levering en montage van een compleet hekwerk volgens specificatie.

In de Odoo-backend ziet de organisatie de volledige structuur: het eindproduct als hoofdregel, daaronder de uitgevouwen stuklijst met alle halffabrikaten en componenten, inclusief aantallen en berekende kostprijzen. Diezelfde structuur stuurt automatisch de inkooporders aan — de juiste componenten gaan naar de juiste leverancier, in de juiste hoeveelheden.


"De klant ziet wat hij koopt. De organisatie ziet wat er geleverd en ingekocht moet worden. Uit dezelfde databron."


De documentstroom — van offerte tot factuur

Een installatiebedrijf heeft niet één document nodig, maar zes — elk gericht op een ander publiek, elk met een eigen functie in het proces. In de nieuwe situatie komen ze allemaal voort uit dezelfde order in Odoo.


Document

Doelgroep

Functie in het proces

Offerte / Order

Klant

Turnkey projectpropositie — eindproduct, levering en montage als compleet geheel volgens klantspecificaties

Inkooporder

Leverancier

Gebaseerd op de componenten die voor het project benodigd zijn — automatisch aangemaakt vanuit de order

Leverbon

Magazijn / montageploeg

Overzicht van de componenten die voor het project worden uitgeleverd

Montagebon

Klant + monteur

Opleveringsdocument — ondertekening door de klant markeert het startmoment voor facturatie

Factuur

Klant / administratie

Sluit naadloos aan op de order — geen herberekening, geen hertypwerk


Huisstijl als selectiecriterium

Alle zes documenten zijn volledig aangepast aan de huisstijl van het bedrijf: kop, voet en achtergrond van elk extern document zijn 1-op-1 overgenomen uit de vernieuwde bedrijfsidentiteit. Logo, kleurgebruik, typografie, keurmerken in de voettekst — het geheel oogt als één professioneel pakket.

Dit is een aanpassing die in Odoo Online niet mogelijk is. Het vereist toegang tot de onderliggende QWeb-rapportagetemplate — de technologie waarmee Odoo PDF-documenten genereert. Die toegang is alleen beschikbaar op Odoo.sh of On-Premise. Voor bedrijven waarbij de uitstraling van externe documenten een commercieel belang is, is dit een concreet en vaak onderschat selectiecriterium bij de platformkeuze.


Wat er nu ligt

Het systeem is gebouwd en opgelevert. De calculatielogica werkt. De documentstroom loopt van offerte tot factuur zonder handmatige tussenkomst. Het maatwerk is gerealiseerd binnen het oorspronkelijke projectbudget.

De volgende stap is de gebruikersacceptatietest — de fase waarin de medewerkers het systeem in de dagelijkse praktijk doorlopen. Niet als formaliteit, maar als essentieel onderdeel van het project. Want een goed gebouwd systeem is pas waardevol als de mensen die ermee werken het ook daadwerkelijk begrijpen en gebruiken.

Deel 3 van deze serie gaat over die fase: wat UAT inhoudt, waarom het de meest onderschatte stap in een ERP-project is, en wat er gebeurt als je er te licht over denkt.


Serie

Dit is deel 2 van een driedelige serie over de Odoo-implementatie bij een installatiebedrijf in de Randstad. Deel 1 ging over de platformkeuze: waarom het project overstapte van Odoo Online naar Odoo.sh. Deel 3 verschijnt na afronding van de go-live en behandelt de UAT-fase en de rol van de eindgebruiker.


Odoo Online of Odoo.sh
wanneer is standaard niet meer genoeg?