AFAS en je eigen portaal. Ieder een duidelijke rol.

Als AFAS al de administratieve basis vormt, hoeft een eigen portaal die niet over te nemen. De vraag is wat medewerkers, klanten of planners buiten die omgeving nodig hebben. Misschien moeten zij een beperkte set gegevens zien of een specifieke handeling uitvoeren die bij hun werk past.

We leggen de grens tussen de systemen vast. Welke informatie blijft in Profit beheerd, wat wordt in het portaal aangevuld en welke wijzigingen mogen terug? Een eigen scherm mag niet ongemerkt een tweede, afwijkende bronadministratie worden.

De leverancier maakt onderscheid tussen GetConnectoren voor het ophalen van gegevens en UpdateConnectoren voor wijzigingen. Alleen de aan de app connector gekoppelde connectoren kunnen binnen die inrichting worden aangeroepen. Zie de officiële uitleg over app connectoren.

Samen met jullie beheerder controleren we of de gewenste velden, relaties en handelingen beschikbaar zijn. Een export kunnen bekijken betekent niet dat dezelfde gegevens ook gewijzigd mogen worden. De gekozen modules, inrichting en autorisatie bepalen mede wat haalbaar is; we claimen geen algemene toegang tot iedere functie.

• Lezen: alleen de gegevens die een bepaalde werkstroom nodig heeft, met herkenbare broncodes.
• Schrijven: alleen vooraf afgesproken mutaties, na de bijbehorende inhoudelijke controle.
• Terugmelden: duidelijk maken of een wijziging is geaccepteerd, afgewezen of nog aandacht nodig heeft.

We bepalen hoe vaak gegevens moeten worden bijgewerkt en welke vertraging in het proces acceptabel is. Bronverwijzingen blijven bewaard, zodat een bestaande registratie niet opnieuw als een nieuw item wordt verwerkt. Bij een wijziging in beide systemen is vooraf duidelijk welke kant leidend is.

Niet iedere technische afwijzing kan automatisch hersteld worden. Een ongeldige code of ontbrekende verplichte waarde vraagt soms om beoordeling door een beheerder. Het portaal moet kunnen laten zien wat verwerkt is en wat niet, zonder een succesvolle ontvangst te verwarren met een inhoudelijk geaccepteerde mutatie.

Voor de bouw hebben we een procesverantwoordelijke, een beheerder van de omgeving en representatieve, bij voorkeur geanonimiseerde voorbeelden nodig. We spreken af welke afgeschermde omgeving of andere testaanpak gebruikt wordt. Een test mag niet per ongeluk een echte personeels- of administratieve mutatie doorvoeren.

De acceptatie bevat correcte verwerking, afgewezen wijzigingen, opnieuw aanbieden en het wegvallen van toegang. We controleren bovendien de zichtbaarheid per rol. De veldafspraken en resultaten vormen onderdeel van de overdracht, zodat een latere wijziging gericht opnieuw getest kan worden.

Bij een bestaande koppeling controleren we ook de gebruikte autorisatiemethode. De leverancier beschrijft de uitfasering van Classic tokens; een oude inrichting wordt dus niet zonder beoordeling als blijvende basis genomen. De planning voor aanpassing stemmen we af op jullie omgeving en de actuele leveranciersvoorwaarden.

Je krijgt de afgesproken koppeling, uitleg over connectoren en toegang en een herstelroute voor fouten. Veranderingen aan velden, filters of autorisatie moeten met de beheerder worden afgestemd. Bespreek wat jullie portaal moet kunnen, of bekijk eerst de bredere dienst maatwerk systemen.