Administraties zijn op papier vaak netjes. Een order komt binnen, er volgt een factuur, de goederen worden geleverd en uiteindelijk klopt alles aan beide kanten. In de praktijk is het natuurlijk nooit zo simpel.
Zeker niet wanneer je met meerdere Exact Online administraties werkt. Dan krijg je al snel een situatie waarin een verkooporder in de ene administratie gevolgen heeft voor een andere administratie. Een order moet worden gespiegeld. Een inkooporder moet worden aangemaakt. Leveringen moeten op de juiste plek terechtkomen. Creditfacturen moeten oude regels weer netjes opruimen. En ondertussen stuurt Exact Online op allerlei momenten updates door.
Ik heb een koppeling gebouwd om precies dat proces te automatiseren. Niet als een simpele “kopieer order A naar order B”-oplossing, maar als een slimme laag tussen meerdere administraties. Een laag die kijkt wat er werkelijk moet gebeuren en vervolgens de juiste documenten, regels, leveringen en ontvangsten aan elkaar knoopt.
De basis van het systeem is vrij eenvoudig: Exact Online geeft een seintje via de Exact Online webhook zodra er iets belangrijks gebeurt. Denk aan een nieuwe of gewijzigde verkooporder, of aan een verkoopfactuur die wordt aangemaakt of aangepast.
Zodra zo’n signaal binnenkomt, kijkt de koppeling eerst of het om een administratie gaat die actief meedoet. Daarna wordt bepaald wat voor soort gebeurtenis het is. Gaat het om een order? Gaat het om een factuur? Is het relevant? Mag het verwerkt worden? Pas daarna start de echte verwerking.
Dat is belangrijk, want bij financiële koppelingen wil je niet zomaar blind op ieder binnenkomend signaal reageren. Je wilt eerst zeker weten dat het event klopt, dat de juiste administratie wordt geraakt en dat de benodigde toegang tot Exact Online beschikbaar is. De koppeling beheert per administratie welke Exact Online events gevolgd worden, waaronder verkooporders en verkoopfacturen.
Het belangrijkste uitgangspunt van deze koppeling is dat de oorspronkelijke verkooporder leidend blijft. Die order bepaalt uiteindelijk welke regels meegaan naar de andere administratie en welke juist niet.
Dat klinkt misschien logisch, maar het is een heel belangrijke keuze. Een factuur is namelijk vaak het moment waarop de koppeling in actie komt, maar de factuur is niet per se de volledige waarheid. De order bevat de onderliggende regels, aantallen, statussen, prijzen, omschrijvingen en leverdatums. Door steeds terug te kijken naar de originele order voorkomt de koppeling dat er te veel, te weinig of verkeerd wordt gespiegeld.
In gewone taal: de koppeling vraagt niet alleen “wat is er net gebeurd?”, maar vooral “hoe zou de administratie er nu uit moeten zien?”
Wanneer een orderregel relevant wordt, zorgt de koppeling ervoor dat die ook in de gekoppelde administratie terechtkomt. Dat kan betekenen dat er een verkooporder in de hoofdadministratie wordt aangemaakt, maar ook dat er aan de andere kant een inkooporder ontstaat.
Zo wordt een commerciële beweging automatisch vertaald naar de juiste administratieve beweging. De ene administratie verkoopt, de andere administratie verwerkt dat als interne levering of inkoop. Daardoor hoeven deze documenten niet handmatig te worden aangemaakt en blijft de relatie tussen de administraties helder.
Het systeem kijkt daarbij niet alleen naar de order als geheel, maar juist naar de regels. Sommige regels moeten mee, andere niet. Denk bijvoorbeeld aan aanbetalingen, geannuleerde regels of regels die nog niet relevant zijn voor facturatie. Alleen wat echt gespiegeld moet worden, wordt meegenomen.
Veel koppelingen zijn goed in iets aanmaken. Maar daarna begint vaak de ellende. Want wat als een orderregel later wordt aangepast? Wat als een regel vervalt? Wat als er een creditfactuur komt? Wat als een document al deels geleverd is?
Deze koppeling probeert dat netjes op te lossen. Hij kijkt steeds opnieuw welke regels zouden moeten bestaan in de gekoppelde administratie. Ontbreekt er iets, dan wordt het toegevoegd. Is er iets gewijzigd, dan wordt het bijgewerkt. Staat er iets dat er eigenlijk niet meer hoort, dan wordt het verwijderd als dat administratief nog veilig kan.
Dat laatste is belangrijk. Als een regel bijvoorbeeld al geleverd of gefactureerd is, kun je die niet zomaar meer verwijderen. De koppeling houdt daar rekening mee. Daardoor wordt de administratie niet alleen automatisch gevuld, maar ook beschermd tegen te agressieve correcties.
Creditfacturen zijn altijd een gevoelig punt in financiële processen. Een credit is niet zomaar “een negatieve factuur”. Administratief betekent het vaak dat eerder gespiegeld werk deels of volledig moet worden teruggedraaid.
Deze koppeling behandelt creditfacturen daarom apart. Er wordt gekeken welke oorspronkelijke orderregels door de credit worden geraakt. Daarna wordt bepaald of alleen specifieke regels moeten worden verwijderd, of dat het hele gekoppelde document geen functie meer heeft.
Als een creditfactuur bijvoorbeeld de laatste relevante regel wegneemt, kan de koppeling ook de bijbehorende order of inkooporder opruimen. Als er nog andere regels overblijven, blijft de rest gewoon bestaan.
Dat maakt de flow veel realistischer. In plaats van alles rigoureus weg te gooien, wordt gekeken wat er na de credit nog over hoort te blijven.
De koppeling stopt niet bij orders en facturen. Ook leveringen worden meegenomen.
Wanneer in de oorspronkelijke administratie goederen geleverd worden, kijkt het systeem hoeveel er geleverd is, op welke regels dat betrekking heeft en welke leverdatum daarbij hoort. Vervolgens wordt die levering ook gespiegeld naar de andere administratie.
Daarbij wordt niet blind het volledige aantal opnieuw geboekt. Het systeem kijkt wat er al geleverd is en verwerkt alleen het verschil. Dat voorkomt dubbele leveringen. Ook wordt gecontroleerd of een regel niet al volledig geleverd is en of de hoeveelheid niet hoger is dan oorspronkelijk besteld.
Aan de inkoopkant wordt hetzelfde principe gebruikt. Als de levering aan de ene kant plaatsvindt, kan de gekoppelde inkooporder aan de andere kant als ontvangen worden verwerkt.
Dat is precies waar een intercompany-koppeling waarde toevoegt. Je voorkomt dat iemand handmatig moet controleren welke verkoopregel bij welke inkoopregel hoort. De relatie is al bekend, dus de ontvangst kan automatisch op de juiste plek worden geboekt.
Het resultaat: minder handwerk, minder kans op fouten en een administratie die sneller aansluit op de werkelijkheid.
Achter de schermen houdt het systeem bij welke documenten en regels aan elkaar gekoppeld zijn. Een order in de ene administratie hoort bij een order in de andere administratie. Een orderregel hoort bij een specifieke gespiegelde regel. Een verkooporder kan weer gekoppeld zijn aan een inkooporder. En facturen worden aan dezelfde keten toegevoegd.
Die geheugenlaag is cruciaal. Zonder zo’n koppeling zou het systeem telkens opnieuw moeten gokken welke regels bij elkaar horen. Dat wil je niet. Zeker niet bij financiële data.
Doordat de relaties worden opgeslagen, kan de koppeling later ook veilig bijwerken, verwijderen, corrigeren, leveren en ontvangen.
In de praktijk gaat data nooit altijd perfect. Soms ontbreekt een relatie. Soms komt een event eerder binnen dan verwacht. Soms is een eerdere verwerking niet volledig gelukt. Daarom zit er herstelgedrag in de koppeling.
Als een relatie tussen documenten ontbreekt, probeert het systeem die alsnog terug te vinden via de gegevens in Exact Online. Bijvoorbeeld door te kijken naar factuurregels, orderregels of herkenbare referenties. Zo hoeft een ontbrekende mapping niet direct te betekenen dat de hele verwerking stopt.
Dit is typisch zo’n onderdeel dat je pas waardeert wanneer je met echte administratieve data werkt. Want daar gebeuren altijd uitzonderingen.
Exact Online kan meerdere signalen kort na elkaar sturen. Soms komt een update binnen terwijl de onderliggende data nog niet helemaal klaarstaat. Als je dan alles direct verwerkt, krijg je kans op dubbele acties of halve synchronisaties.
Daarom werkt de koppeling met een gecontroleerde verwerking. Gebeurtenissen kunnen worden klaargezet, later worden uitgevoerd en opnieuw worden geprobeerd als iets tijdelijk niet lukt. Denk aan een tijdelijk API-probleem, een tokenprobleem of data die nog niet beschikbaar is.
Die wachtrij zorgt ervoor dat het systeem niet zenuwachtig reageert op elke losse prikkel, maar gecontroleerd verwerkt wat er moet gebeuren.
Naast orders, facturen, leveringen en ontvangsten is er ook een productmatige kant. Artikelen uit de hoofdadministratie kunnen worden opgezocht in andere administraties. Bestaat een artikel al, dan kan het worden bijgewerkt. Bestaat het nog niet, dan kan het worden aangemaakt.
Daarbij worden alleen relevante artikelvelden meegenomen, zoals code, omschrijving, extra omschrijving, kostprijzen, notities en voorraad- of verkoopinstellingen. Ook afbeeldingen kunnen worden meegenomen en doorgestuurd naar de andere administratie.
Dat zorgt ervoor dat niet alleen de transacties gelijklopen, maar ook de basisdata waarop die transacties draaien.
Zonder deze koppeling zou iemand continu moeten meekijken:
Is er een factuur aangemaakt?
Moet er nu een order in de hoofdadministratie komen?
Welke regels moeten mee?
Welke regels zijn geannuleerd?
Is er een credit geweest?
Moet de inkooporder worden aangepast?
Is er al geleverd?
Moet er ontvangst worden geboekt?
Kloppen de artikelen in alle administraties nog?
Dat is precies het soort werk dat foutgevoelig wordt zodra het volume stijgt. Het is repetitief, maar wel belangrijk. Eén verkeerd gekoppelde regel kan later zorgen voor verschillen in voorraad, omzet, inkoop, levering of facturatie.
Deze koppeling neemt dat proces over. Niet door domweg alles te kopiëren, maar door per stap te beoordelen wat de juiste administratieve consequentie is.
Wat deze oplossing sterk maakt, is dat hij niet alleen automatiseert, maar ook voorzichtig is.
Er wordt gecontroleerd voordat er iets gebeurt. Er wordt gelogd wat er gebeurt. Er wordt voorkomen dat processen tegelijk door elkaar lopen. Er wordt geprobeerd ontbrekende relaties te herstellen. Er wordt niet zomaar verwijderd als een document al verder in het proces zit. En bij tijdelijke fouten kan de verwerking later opnieuw worden geprobeerd.
Dat is precies wat je wilt bij een koppeling met financiële impact. Snel waar het kan, voorzichtig waar het moet.
Deze koppeling vormt een slimme administratieve brug tussen meerdere Exact Online administraties. Verkooporders, facturen, inkooporders, leveringen, ontvangsten, credits en artikelen worden niet als losse onderdelen behandeld, maar als één samenhangend proces.
De oorspronkelijke order blijft leidend. Facturen bepalen wanneer er actie nodig is. Regels worden alleen gespiegeld wanneer ze echt relevant zijn. Credits ruimen op wat niet meer hoort te bestaan. Leveringen en ontvangsten worden automatisch doorgezet. Artikelen kunnen worden bijgewerkt tussen administraties. En achter de schermen wordt steeds bijgehouden welke documenten en regels bij elkaar horen.
Het resultaat is een koppeling die veel administratief handwerk wegneemt, fouten vermindert en meerdere Exact Online administraties beter met elkaar laat samenwerken.
Eigenlijk is het systeem een soort verkeersregelaar voor intercompany administratie. Het zorgt dat iedere order, factuur, levering en ontvangst op het juiste moment de juiste afslag neemt. En dat is precies wat je nodig hebt wanneer administraties niet los van elkaar staan, maar continu met elkaar in gesprek moeten blijven.
Altijd direct contact via WhatsApp of telefoon.
Geen uurtje factuurtje mentaliteit.
Jij hebt geen online marketing vraagstuk, wij hebben dat
Heb je een vraagstuk op het gebied van SEO, SEA of WordPress development? Neem contact op!
