Unit4.
Geïntegreerd.

Heet het nu Unit4 of Agresso?

Allebei, en dat verklaart een hoop verwarring. Agresso Business World is inmiddels hernoemd naar Unit4 ERP, maar in de praktijk noemen veel organisaties het systeem nog steeds Agresso — zeker bij implementaties die al jaren draaien. Loop je tegen documentatie of consultants aan die over Agresso praten terwijl jij Unit4 gebruikt: het gaat om hetzelfde platform.

Voor een koppeling maakt de naam niet uit, maar de leeftijd van je implementatie wel. Oudere Agresso-omgevingen ontsluiten hun gegevens vaak via SOAP-webservices, terwijl nieuwere Unit4-cloudomgevingen met REST-API's werken. Unit4 documenteert die via Swagger, zodat inzichtelijk is welke endpoints beschikbaar zijn en welke rechten een integratiegebruiker nodig heeft. Dat verschil bepaalt het bouwwerk, dus het is het eerste wat we uitzoeken.

Een webshop koppelen aan Unit4

De meest gestelde vraag rond Unit4 gaat over e-commerce: hoe krijg ik mijn webshop en mijn ERP met elkaar in de pas? Bij een B2B-webshop is dat een wezenlijk andere opgave dan bij een consumentenshop, en het is precies daar dat standaardkoppelingen omvallen.

Prijzen zijn niet één getal

In een consumentenshop heeft een artikel een prijs. In een B2B-omgeving heeft datzelfde artikel een basisprijs, een klantspecifieke prijsafspraak, een staffel op afnamehoeveelheid en soms een contractprijs die per periode verschilt. Die logica leeft in Unit4, niet in je webshop. Een koppeling die alleen artikelen met een prijs synchroniseert, laat de shop dus verkeerde bedragen tonen aan precies de klanten met wie je de scherpste afspraken hebt gemaakt.

De werkbare aanpak is de prijs niet te kopiëren maar op te vragen: de webshop vraagt bij het tonen van een artikel de geldende prijs voor déze klant op, met een korte cache erachter zodat je niet bij elke paginaweergave het ERP belast.

Voorraad is een momentopname, geen waarheid

Verkoop je ook via vertegenwoordigers, telefoon of een marktplaats, dan is de voorraad in Unit4 het enige punt dat alles ziet. Maar de voorraad die je aan een klant toont hoeft niet de werkelijke voorraad te zijn: gereserveerde partijen, inkomende bestellingen en minimumniveaus horen erin verwerkt. Een koppeling die het kale voorraadgetal doorzet, belooft je klanten dingen die je niet waar kunt maken.

Klantnummers zijn de kern van het probleem

Een webshopaccount en een debiteur in Unit4 zijn niet automatisch dezelfde entiteit. Eén inkooporganisatie kan meerdere bestellers hebben, meerdere afleveradressen en één factuuradres. Wie dat plat slaat tot één account per e-mailadres, krijgt orders die op de verkeerde debiteur landen. We leggen die relatie daarom expliciet vast in plaats van hem af te leiden.

Wat je van tevoren moet uitzoeken

Drie dingen bepalen bij een Unit4-koppeling het meeste van de doorlooptijd, en ze zijn geen van drieën technisch. Wie beheert de Unit4-omgeving — jullie zelf of een implementatiepartner die toegang moet verlenen? Welke rechten krijgt de integratiegebruiker, en is daar iemand voor nodig die dat mag toekennen? En bestaat er een acceptatieomgeving, of moet er op productie getest worden?

Dat laatste is bij ERP-koppelingen geen detail. Een verkeerd geboekte order in een testomgeving is een leermoment; dezelfde order in productie is een correctie die door de administratie heen moet.

Wat er misgaat als een order het ERP niet haalt

Bij een webshopkoppeling is een mislukte synchronisatie vervelend. Bij een ERP-koppeling is het duurder, omdat er een order tegenover staat die de klant al geplaatst en soms al betaald heeft. De vraag is dus niet óf er ooit iets faalt, maar wat er dan gebeurt.

Drie dingen die een koppeling moet regelen voordat hij live gaat:

Elke order moet precies één keer landen

Een netwerkfout tussen "order verstuurd" en "bevestiging ontvangen" is niet te onderscheiden van "order niet aangekomen". Probeert de koppeling het dan gewoon opnieuw, dan staat de order er mogelijk twee keer in. De oplossing is de order een eigen sleutel meegeven en vóór het aanmaken controleren of die sleutel al bestaat — idempotente verwerking, en het is het eerste wat we inbouwen.

Een fout moet zichtbaar zijn zonder dat iemand ernaar zoekt

De meeste ERP-koppelingen die we overnemen falen stil. Er is een logbestand, maar niemand kijkt erin, en de fout komt pas boven water als een klant belt over een bestelling die nooit geleverd is. Wij zetten er daarom een wachtrij achter met zichtbare status: wat is gelukt, wat wacht op een nieuwe poging, en wat vraagt om een mens. Dat laatste rijtje hoort leeg te zijn, en als het dat niet is krijgt iemand bericht.

Er moet een weg terug zijn

Soms is een order gewoon fout: een verkeerd artikelnummer, een debiteur die niet meer bestaat, een prijsafspraak die verlopen is. Zo'n order moet je kunnen corrigeren en opnieuw kunnen aanbieden, zonder dat een ontwikkelaar erbij nodig is. Een koppeling zonder herstelknop verplaatst het probleem alleen maar naar de wachtrij.

De andere richting: gegevens uit Unit4 terug naar je klanten

Een koppeling wordt vaak bedacht als eenrichtingsverkeer — orders naar het ERP — maar de waarde zit net zo vaak in de terugweg. Ordernummer, verwachte leverdatum, pakbon, factuur en openstaande posten leven allemaal in Unit4 en zijn precies wat je klanten willen zien.

Ontsluit je dat in een klantportaal, dan verdwijnt een categorie telefoontjes die niets opleveren: waar blijft mijn bestelling, wat stond er ook alweer op die factuur, hoeveel staat er nog open. Voor B2B-klanten die maandelijks tientallen orders plaatsen is dat vaak het onderdeel van de koppeling met de kortste terugverdientijd.

Hoe zo'n traject verloopt

Een Unit4-koppeling bouwen we in fases, en niet omdat dat netjes staat op een offerte. Een ERP is het systeem waar de financiële administratie op draait; daar wil je niet in één keer een grote verandering op loslaten.

We beginnen met één richting en één ordertype — meestal een standaard verkooporder van shop naar Unit4 — en zetten die live zodra hij aantoonbaar werkt. Daarna komen de uitzonderingen erbij: klantspecifieke prijzen, afwijkende afleveradressen, deelleveringen, creditnota's. Elke stap is los te testen en los terug te draaien.

Dat duurt langer dan alles tegelijk bouwen, maar het verschil zit in wat er gebeurt als er iets niet klopt. Bij een gefaseerde koppeling weet je binnen een dag welke stap het was.