De drie grootste valkuilen bij een Exact Online-koppeling
De techniek van een koppeling is zelden het echte probleem. De projecten die misgaan, stranden bijna altijd op een van deze drie punten, en alle drie zijn ze vooraf te ondervangen.
Valkuil 1: rate limits negeren
Zoals vrijwel elke API kent ook die van Exact Online gebruikslimieten: je mag per tijdseenheid een beperkt aantal aanroepen doen. Een koppeling die naïef alles direct wil synchroniseren (elke wijziging meteen, elk record apart) loopt daar vroeg of laat tegenaan en valt dan stil of mist updates.
De oplossing is een koppeling die met limieten rekening houdt vanaf het ontwerp: wijzigingen verzamelen in een wachtrij, verwerken in batches, en netjes wachten en opnieuw proberen als de limiet bereikt is. Voor jou als gebruiker merkbaar als: het synchroniseert gewoon, ook op drukke dagen.
Valkuil 2: autorisatie als bijzaak behandelen
Toegang tot de Exact Online-API verloopt via OAuth: jouw software krijgt tokens die periodiek verlopen en ververst moeten worden. Gaat dat verversen één keer mis (bijvoorbeeld door een storing of een gewijzigd wachtwoord), dan staat de koppeling stil zonder dat iemand het doorheeft.
Een goede koppeling bewaakt daarom zijn eigen toegang: tokens veilig opslaan, tijdig verversen en alarm slaan zodra de autorisatie wegvalt. Spreek ook af wíé de koppeling autoriseert: een persoonlijk account van een medewerker die later vertrekt, is een klassieke stille storing.
Valkuil 3: geen foutafhandeling en monitoring
Een synchronisatie kán mislukken: een time-out, een onderhoudsvenster bij Exact, een record dat net niet aan de validatie voldoet. Dat is normaal. Het probleem ontstaat als de koppeling die fout stilletjes wegslikt: dan ontdek je ontbrekende boekingen pas bij de btw-aangifte.
Wat je wilt: mislukte synchronisaties worden gelogd, automatisch opnieuw geprobeerd en, als het blijft mislukken, gemeld aan een mens. Plus de zekerheid dat een herhaalde poging niet per ongeluk een dubbele factuur boekt. Vraag elke bouwer hoe dit geregeld is; het antwoord zegt meer dan de prijs.
Bonus-valkuil: geen leidend systeem afspreken
Niet technisch, wel de meest voorkomende ontwerpfout: beide systemen mogen dezelfde gegevens wijzigen, zonder afspraak welk systeem per gegeven de bron is. Het gevolg is conflicten, dubbele relaties en discussie met je accountant. Leg vóór de bouw per gegevensstroom vast wie leidend is. Dat kost één werksessie en voorkomt maanden gedoe.