In het kort
- Wat er misging. Exact levert de lijst met codes in stukjes van 60. De koppeling las alleen het eerste stukje, terwijl het er in totaal 190 zijn. Daardoor kende de app maar 5 van de 21 vestigingen en 9 van de 20 uitvoeringen.
- Jullie lijsten kloppen precies. We hebben beide bijlagen naast Exact gelegd: alle 21 vestigingen en alle 20 uitvoeringen staan er correct in. Er valt bij jullie niets aan te maken of te corrigeren.
- Het is verholpen en staat live. Nieuwe debiteuren krijgen vanaf nu automatisch zowel de vestiging als de uitvoering.
- De bestaande relaties worden bijgewerkt. Het gaat om circa 686 relaties waar de vestiging of uitvoering leeg was. Die vullen we aan zonder iets te overschrijven wat jullie zelf hebben ingevuld.
1 Wat er mis was
Bij het aanmaken van een debiteur vraagt onze koppeling aan Exact welke vestigingen en uitvoeringen er bestaan, en zoekt daar de juiste code bij. Exact stuurt die lijst niet in een keer terug maar in stukjes van 60 regels, met een verwijzing naar het volgende stukje. Onze koppeling las dat eerste stukje en negeerde de verwijzing.
In totaal telt die lijst 190 regels. We zagen er dus 60, en daarbinnen zaten toevallig maar 5 vestigingen en 9 uitvoeringen.
| Veld | Wat onze app zag | Wat er echt in Exact staat |
|---|---|---|
| Vestiging | 5 codes | 21 codes |
| Uitvoering | 9 codes | 20 codes |
Kende de app een code niet, dan liet hij dat veld bewust leeg in plaats van er iets te verzinnen. Dat is precies zoals het hoort, maar hier gebeurde het om de verkeerde reden.
Waarom juist de vestiging opviel. In jouw voorbeeld ging het om PTN (Numansdorp). Die code zat toevallig wel in het eerste stukje bij de uitvoeringen en niet bij de vestigingen. Vandaar dat je bij hetzelfde project de uitvoering gevuld zag en de vestiging leeg, terwijl die twee volgens afspraak altijd gelijk horen te zijn. Het leek daardoor willekeurig, maar er zat een vast patroon achter.
Dit verklaart ook waarom het al langer speelde. Bij de invulronde van eind juli zijn 745 relaties bijgewerkt zonder foutmeldingen, maar ook toen konden alleen de codes uit dat eerste stukje gezet worden. Een code die de app niet kende telde niet als fout, dus het rapport zag er schoon uit.
2 Jullie codelijsten kloppen
We hebben beide bijlagen regel voor regel naast Exact gelegd. Er is geen enkel verschil, in geen van beide richtingen.
| Lijst | In jullie bestand | In Exact | Verschil |
|---|---|---|---|
| Vestiging | 21 codes | 21 codes | geen |
| Uitvoering | 20 codes | 20 codes | geen |
Ook de verschillen tussen de twee lijsten kloppen aan beide kanten: BP en VAK bestaan alleen als vestiging, PTHO alleen als uitvoering. Dat is dus geen omissie maar bewust zo ingericht, en onze koppeling gaat daar goed mee om.
Over je opmerking bij de omschrijvingen. Je vermoeden klopt: wij kijken alleen naar de code, nooit naar de omschrijving. Dat PTB bij de vestiging "Parket Tree Blaricum" heet en bij de uitvoering "Vloershopper" maakt voor de koppeling niets uit. Datzelfde geldt voor kleine schrijfverschillen zoals "Ten dam" tegenover "Ten Dam".
3 Wat er nu goed gaat
De aanpassing staat sinds vandaag live. We hebben daarna gecontroleerd wat de app werkelijk ziet: alle 190 regels, en daarmee alle 21 vestigingen en 20 uitvoeringen.
Voor de zekerheid hebben we het ook op een echte relatie nagekeken in plaats van alleen in onze eigen logboeken. Bij een project van Parkettree Velddriel staan nu zowel de vestiging als de uitvoering correct op de relatiekaart, met de leveringswijze "V - Verzekering" erbij.
Vanaf nu krijgt elke nieuwe debiteur beide velden automatisch ingevuld.
4 De bestaande relaties
De aanpassing werkt vooruit, dus relaties die er al stonden hadden nog steeds een leeg veld. We hebben eerst een proefronde gedraaid zonder iets te wijzigen, om te zien hoe groot het is:
| Situatie | Aantal projecten |
|---|---|
| Vestiging of uitvoering nog leeg, wordt aangevuld | 686 |
| Stond al goed, blijft ongewijzigd | 467 |
| Nog geen relatie in Exact (16 geannuleerd, 4 net aangemaakt) | 20 |
| Relatienummer al bezet door een ander bedrijf | 2 |
Die aanvulling zijn we vandaag gestart, in kleine blokken zodat de koppeling ondertussen gewoon beschikbaar blijft voor het dagelijkse werk. We beginnen bewust klein en controleren tussendoor.
Wat jullie eigen invoer betreft: we vullen alleen velden die leeg zijn. Heeft iemand bij jullie een vestiging of uitvoering handmatig ingevuld, dan blijft die staan zoals hij is.
5 Wat nog openstaat
Twee groepen projecten krijgen de velden niet. Geen van beide is een gevolg van deze storing, en bij de meeste is er ook niets aan de hand.
20 projecten zonder relatie in Exact
Hiervan zijn er 16 geannuleerd. Daar hoort geen debiteur bij, dus die krijgen ook geen vestiging of uitvoering. De overige vier zijn net aangemaakt, tussen 7 en 24 augustus, en staan nog in de inspectie- of bevestigingsfase. Zodra die verder in het proces komen, wordt de relatie aangemaakt en krijgen ze de velden vanzelf mee.
Hier is dus geen actie nodig.
Twee projecten met een bezet relatienummer
Bij PT-2026-01289 en PT-2026-01798 staat op het relatienummer dat bij het project hoort al een andere relatie: een verzekeringstussenpersoon en een expertisebureau, allebei met eigen facturen op dat nummer.
| Project | Klant in de app | Staat in Exact op dat nummer |
|---|---|---|
| PT-2026-01289 | R.J. Kuijl, Almere | VMD Koster verzekeringen (1 factuur) |
| PT-2026-01798 | N.W. Gerritse, Limbricht | Hommeles Expertise B.V. (2 facturen) |
Onze koppeling laat deze twee met opzet ongemoeid. Zou hij de velden toch invullen, dan kwamen er gegevens van een herstelproject op de relatiekaart van een bedrijf te staan waar dat project niet bij hoort. Dit punt loopt al apart bij jullie.
Verder is er van jullie kant niets nodig. Zodra de aanvulling van de bestaande relaties klaar is, laten we het weten.