ABN Data Model

Over dit document

Dit document legt uit hoe we vacaturegegevens opslaan en wat elk veld betekent. We schrijven het in heldere taal, oftewel Algemeen Beschaafd Nederlands, zodat iedereen het kan volgen, of je nu in de backoffice werkt, kandidaten matcht, of gewoon wilt snappen hoe het systeem in elkaar zit.

Waarom hebben we een datamodel nodig?

Vacatures komen uit verschillende bronnen: STRIIVE, Flextender, Yacht, Maandag en andere DAS-platformen. Elk platform gebruikt eigen termen. De een noemt het "tarief", de ander "salaris" of "rate". Het ene systeem geeft uren per week, het andere per dag.

Dat levert verwarring op. Als je vacatures wilt vergelijken, filteren of publiceren, moet je eerst weten wat er staat en hoe het bedoeld is.

Ons datamodel lost dit op. Het is een afspraak: ongeacht waar een vacature vandaan komt, we slaan hem altijd op dezelfde manier op. Vaste veldnamen, vaste formaten, vaste betekenissen.

Praktisch voorbeeld:

Het resultaat: alle vacatures zien er hetzelfde uit, ongeacht de bron.

Wie gebruikt dit waarvoor?

Het datamodel is niet alleen voor technici. Het bepaalt wat iedereen ziet en kan doen:

Backoffice gebruikt het om vacatures te controleren voordat ze online gaan. Klopt het tarief? Is de sluitingsdatum ingevuld? Past de opdrachtgever bij de standplaats?

Frontoffice gebruikt het om kandidaten te matchen en vragen te beantwoorden. Als een kandidaat vraagt "hoeveel uur per week?", moet dat veld kloppen.

Kandidaten zien uiteindelijk wat er gepubliceerd is. Fouten in de data worden fouten op de website.

Daarom is elk veld belangrijk, niet alleen technisch maar ook operationeel.

Hoe is het datamodel opgebouwd?

We werken met drie lagen:

1. Kern van de vacature: titel, status, datums, inhoud, tarieven, uren, indieningsvereisten en AVG-beperkingen.
2. Relaties: opdrachtgever (met type en regio), standplaats, contactpersoon, rollen, thema's, contractvormen.
3. Publicatie en bewijs: documenten, snapshots, broninformatie, integraties.

Hieronder leggen we elke laag stap voor stap uit.

De vacature zelf

Elke vacature heeft een kern: de basisgegevens die je nodig hebt om te weten wat het is en wanneer het speelt.

Titel en status

De titel is simpelweg de functienaam. "Senior Java Developer", "Projectleider Digitalisering", dat soort dingen. Dit is wat kandidaten als eerste zien.

De status vertelt waar de vacature staat in het proces:

Technische velden: job.job_title, job.job_status

Datums

Een vacature heeft meerdere datums. Dit zijn de belangrijkste:

Als de sluitingsdatum ontbreekt of in het verleden ligt, kan de vacature niet gepubliceerd worden. Dat is een harde regel.

Technische velden: job.job_closure_datetime, job.job_start_datetime, job.job_end_datetime, job.job_published_at

Omschrijving en eisen

De omschrijving is de volledige tekst van de opdracht, vaak in HTML-formaat zodat we opmaak kunnen behouden.

De eisen zijn wat de opdrachtgever vraagt: opleidingsniveau, jaren ervaring, certificaten, VOG.

De selectiecriteria leggen uit hoe de opdrachtgever kiest: "Prijs 40%, Kwaliteit 60%" of "Laagste prijs wint".

Voorbeeld:

• Eisen: HBO, minimaal 5 jaar ervaring, VOG vereist
• Selectiecriteria: Prijs 40%, Kwaliteit 60%

Technische velden: job.job_description_html, job.job_requirements, job.job_selection_criteria

Geld en tijd

Tarief

Het tarief is wat de kandidaat per uur verdient. We slaan dit op als een bandbreedte: een minimum en een maximum.

Let op: Het minimum mag nooit hoger zijn dan het maximum. Als dat wel zo is, klopt er iets niet en moet je de bron checken.

Tarieven zijn altijd in euro's per uur. Als de bron dagtarieven geeft, rekenen we die om.

Als een bron geen uurtarief geeft maar een maandrange, rekenen we die alleen terug naar een indicatief minimum- en maximumuurtarief als het aantal uren per week bekend is. Ontbreekt die context, dan blijft de maandrange broninformatie en markeren we de vacature voor handmatige controle.

Technische velden: job.contract_min_rate_eur, job.contract_max_rate_eur

Uren per week

Hoeveel uur per week werkt de kandidaat? Ook dit slaan we op als bandbreedte.

Realistische waarden liggen tussen 8 en 40 uur per week. Alles daarbuiten is verdacht.

Technische velden: job.contract_min_hours_per_week, job.contract_max_hours_per_week

Duur en verlenging

Hoe lang duurt de opdracht? En kan die verlengd worden?

Voorbeeld: "6 maanden, optie tot 2x 3 maanden verlenging"

Dit betekent: het contract duurt eerst 6 maanden, en daarna kan het twee keer met 3 maanden verlengd worden.

De verlenging slaan we op als een object met drie onderdelen:

• Status: yes, no, possible, of onbekend
• Aantal: hoeveel keer verlengen
• Maanden: hoeveel maanden per verlenging

Technische velden: job.contract_duration_months, job.contract_extension

Indieningsvereisten

Bij veel aanbestedingen gelden regels over hoe een kandidaat zich mag aanbieden. Die regels komen uit het DAS-platform en slaan we mee op.

Dit is belangrijk voor frontoffice bij het voorbereiden van een aanbieding. Als je meer pagina's of kandidaten aanbiedt dan toegestaan, wordt de inschrijving afgekeurd.

Technische velden: job.contract_submission_requirements

DAS-vereisten

Sommige DAS-platformen stellen aanvullende eisen aan leveranciers. Denk aan verplichte certificeringen, registratie bij het platform, of een specifiek kwaliteitskeurmerk.

We slaan deze eisen mee op zodat backoffice kan controleren of we aan de voorwaarden voldoen voordat we een kandidaat aanbieden.

Technische velden: job.contract_das_requirements

AVG-beperkingen

Bij bepaalde opdrachten gelden privacyregels voor wat je wel en niet mag delen over een kandidaat. Voorbeelden:

• Geen pasfoto meesturen
• Geen woonadres vermelden
• Geheimhoudingsverklaring vereist
• VOG (Verklaring Omtrent het Gedrag) vereist

Als deze beperkingen zijn ingevuld, moet frontoffice hier rekening mee houden bij het opstellen van de aanbieding. Het systeem kan hier ook automatisch op controleren.

Technische velden: job.contract_gdpr_requirements

Wie en waar

Opdrachtgever

De opdrachtgever is de organisatie die de opdracht uitschrijft. Dit kan een gemeente zijn, een waterschap, een ministerie, of een andere publieke instelling.

We slaan het volgende op:

Zonder opdrachtgever kan een vacature niet gevalideerd worden. Dit is een verplicht veld.

Organisatietypes:

Regio's (provincies):

Technische velden: headquarters (met alle adresvelden), org_type, region

Standplaats

De standplaats is waar de kandidaat daadwerkelijk gaat werken. Dit kan anders zijn dan het hoofdkantoor van de opdrachtgever.

Voorbeeld: De opdrachtgever is Rijkswaterstaat in Den Haag, maar de standplaats is een projectlocatie in Groningen.

Technische velden: work_location

Contactpersoon

Als er een aanspreekpunt is voor vragen over de opdracht, slaan we die hier op.

Technische velden: contact

Categorisering

Rollen

Een rol beschrijft wat voor functie het is. Een vacature kan meerdere rollen hebben.

Voorbeeld: Een vacature "Technisch Projectleider" kan zowel de rol "Project Manager" als "Tech Lead" hebben.

Technische velden: job_role, role

Thema's

Thema's beschrijven waar de opdracht over gaat. Ook hier kan een vacature meerdere thema's hebben.

Voorbeeld: Een vacature "Data Engineer voor Digitale Transformatie" kan de thema's "Digitalisering" en "Data & Analytics" hebben.

Technische velden: job_theme, theme

Contractvormen

Hoe kan de kandidaat ingehuurd worden? Dit bepaalt hoe de facturatie en contractering verloopt.

Een vacature kan meerdere contractvormen toestaan. Bijvoorbeeld: "ZZP of Detachering".

Technische velden: job_contract_type, contract_type

Sector en opleidingsniveau

Voor filtering gebruiken we ook sector en opleidingsniveau.

Sectoren:

Opleidingsniveaus:

Technische velden: job.sector_id, job.education_level

Herkomst en traceerbaarheid

Platform

Elke vacature komt van een DAS-platform. We houden bij welk platform dat is en wat het originele ID was.

Technische velden: platform, platform_id, job.platform_job_id

Bronverwijzing

Om altijd terug te kunnen naar de originele vacature, slaan we de bron-URL op. Dit is de link naar de pagina waar we de vacature vandaan gehaald hebben.

Technische velden: job.job_source_url

DPP referentie

We geven elke vacature ook een eigen referentienummer. Dit is ons interne nummer, los van wat het platform gebruikt.

Voorbeeld: DPP-2026-001234

Technische velden: job.job_dpp_reference_id

Documenten

Vaak zitten er bijlagen bij een vacature: het aanbestedingsdocument (tender PDF), aanvullende eisen, algemene voorwaarden.

We slaan de documenten op en halen er waar mogelijk tekst uit, zodat we kunnen zoeken in de inhoud.

Technische velden: job_document

Publicatie

Waar staat de vacature online?

Als een vacature gepubliceerd is, slaan we op waar die te vinden is:

Technische velden: job_posting, integration_frontend, newsletter_job

Koppelingen met andere systemen

De vacaturedata gaat niet alleen naar de website. We koppelen ook met:

WordPress (depubliekepartner.nl)

• Vacatures worden automatisch gepubliceerd
• We slaan de post ID en URL op

VBout (nieuwsbrieven)

• Geselecteerde vacatures gaan naar de nieuwsbrief
• We houden bij in welke nieuwsbrief een vacature is opgenomen

TESS (kandidaat matching)

• Alle vacaturedata gaat naar TESS
• TESS matcht kandidaten, genereert voorstellen, en regelt inschrijving

Relaties (visueel)

erDiagram
  PLATFORM ||--o{ JOB : bron
  JOB ||--|| HEADQUARTERS : opdrachtgever
  JOB ||--|| WORK_LOCATION : standplaats
  JOB ||--o{ JOB_ROLE : heeft
  ROLE ||--o{ JOB_ROLE : tag
  JOB ||--o{ JOB_THEME : heeft
  THEME ||--o{ JOB_THEME : tag
  JOB ||--o{ JOB_CONTRACT_TYPE : optie
  CONTRACT_TYPE ||--o{ JOB_CONTRACT_TYPE : type

Hoe data van bron naar publicatie stroomt

Een vacature maakt een reis van het DAS-platform naar de website. Dat gaat zo:

flowchart LR
  A[DAS-platform] --> B[Scraper haalt op]
  B --> C[Vertaling naar ons model]
  C --> D[Opslag in database]
  D --> E[Controle door backoffice]
  E --> F[Publicatie op website]

Stap 1: Ophalen De scraper haalt de vacature op van het DAS-platform. Dit kan een API-koppeling zijn of het uitlezen van een webpagina.

Stap 2: Vertalen We zetten alle velden om naar ons datamodel. "Rate" wordt contract_min_rate_eur, "tarief per uur" ook.

Stap 3: Opslaan De vacature gaat de database in met status "draft".

Stap 4: Controleren Backoffice checkt of alles klopt: tarief, uren, opdrachtgever, datums.

Stap 5: Publiceren Als alles goed is, wordt de status "published" en verschijnt de vacature op de website.

Status veranderingen

Een vacature doorloopt deze statussen:

draft → published → closed → archived

Checklist voor data review

Als je een vacature controleert, check dan het volgende:

Verplichte velden

Belangrijke controles

Veelvoorkomende problemen

Tips

1. Klik altijd door naar de bron-URL - Vergelijk wat er in ons systeem staat met het origineel
2. Let op tarieven - Sommige bronnen geven dagtarieven in plaats van uurtarieven
3. Check verlengingen - Die staan vaak in de PDF bijlagen, niet in de hoofdtekst
4. Regio vs standplaats - De standplaats kan in een andere regio liggen dan het hoofdkantoor
5. Check indieningsvereisten - Maximaal aantal CV-pagina's en kandidaten verschilt per aanbesteding
6. AVG altijd controleren - Als er beperkingen staan, gelden die voor elke aanbieding op die vacature

Samenvatting

Feedback geven

Zie je iets dat niet klopt? Gebruik de technische veldnaam in je opmerking. Dat scheelt zoeken.

Voorbeeld: "Het veld contract_max_rate_eur lijkt te hoog, 500 EUR/uur is onrealistisch voor deze functie."

Een korte zin met het veld en het probleem is genoeg.