Holding-beheer

Bedrijfsklanten kunnen meerdere juridische entiteiten (BV's) onder een holdingstructuur beheren. Als beheerder heeft u volledig inzicht in holdings, dochterondernemingen en de koppelingverzoeken daartussen.

Organisatietypes

Elke organisatie heeft een organizationType die het gedrag in het systeem bepaalt. Het type wordt automatisch bijgewerkt zodra er een koppeling wordt gemaakt of verbroken.

Type	Label in UI	Betekenis
STANDALONE	Zelfstandig	Een op zichzelf staande organisatie zonder moeder- of dochterrelaties. Standaardwaarde voor nieuwe bedrijven.
HOLDING	Holding	Moederorganisatie met een of meer gekoppelde dochter-BV's. Kan zelf ook eigen laadpalen en claims hebben.
SUBSIDIARY	Dochter-BV	Organisatie die is gekoppeld aan een holding via parentOrganizationId.

Automatische overgangen

• Een STANDALONE organisatie wordt automatisch HOLDING zodra de eerste dochter-BV wordt gekoppeld.
• Een HOLDING zonder overgebleven dochters wordt teruggezet naar STANDALONE wanneer de laatste dochter wordt losgekoppeld.
• Een SUBSIDIARY blijft dochter zolang parentOrganizationId gevuld is. Loskoppelen maakt de organisatie weer STANDALONE.

Beperkingen

• Een organisatie kan niet aan zichzelf worden gekoppeld.
• Een dochter-BV kan niet zelf holding worden zolang deze nog gekoppeld is.
• Een bestaande holding kan niet als dochter van een andere holding worden gekoppeld (geen geneste hierarchieen).
• Een holding kan maximaal 50 dochterondernemingen hebben (inclusief openstaande verzoeken).

Overzicht en filtering

Ga naar Admin > Organisaties voor het organisatieoverzicht met twee weergaven:

• Per holding (standaard) — groepeert holdings met hun dochters genest onder de moeder. Holdings tonen een samengevatte regel met totaal aantal leden en laadpalen inclusief dochters.
• Platte lijst — toont alle organisaties in een enkele tabel zonder grouping.

Gebruik het Type-filter om specifiek te zoeken op HOLDING, SUBSIDIARY of STANDALONE. Bovenaan de gegroepeerde weergave ziet u aggregatiestatistieken: aantal holdings, dochter-BV's, zelfstandige organisaties, leden en laadpalen op de huidige pagina.

Koppelingverzoeken

Een holding-eigenaar (rol EIGENAAR) start een verzoek om een andere organisatie als dochter te koppelen. Het verzoek loopt langs de EIGENAAR van de doelorganisatie die het moet accepteren of afwijzen.

Flow en statussen

Status	Betekenis
PENDING	Verzoek verstuurd, wacht op reactie van dochter-eigenaar. E-mail met goedkeuringslink is verzonden.
APPROVED	Doelorganisatie is gekoppeld als SUBSIDIARY. parentOrganizationId is gezet, moederorganisatie is zo nodig geupgrade naar HOLDING.
REJECTED	Doelorganisatie heeft het verzoek afgewezen (rejectionReason verplicht). Moeder-eigenaren krijgen een notificatie.
EXPIRED	Verzoek is ouder dan 7 dagen en automatisch verlopen.
CANCELLED	Moeder-eigenaar heeft het verzoek zelf teruggetrokken voordat er gereageerd werd.

Expiry-job

De cronjob subsidiaryLinkExpiryJob draait dagelijks om 06:00 en zet openstaande verzoeken ouder dan 7 dagen op EXPIRED. Naast deze job is er ook een lazy check bij het openen van een verzoek via token of bij een accept/reject actie: verzoeken voorbij de expiry worden on-the-fly op EXPIRED gezet.

Productie-alleen

De expiry-job draait standaard alleen op productie (NODE_ENV=production). Op acceptatie of lokaal kan hij geforceerd worden via ENABLE_LINK_EXPIRY_JOB=true.

Concurrency-safeguards

De backend gebruikt optimistic locking bij acceptatie. Twee gelijktijdige reacties op hetzelfde verzoek leveren een 409-conflict op met de melding dat het verzoek al verwerkt is. Hierdoor kan een verzoek nooit dubbel worden goedgekeurd.

Op het moment van accepteren valideert het systeem opnieuw:

• Staat de dochter nog niet gekoppeld aan een andere holding?
• Is de dochter zelf geen HOLDING geworden in de tussentijd?

Faalt een van deze checks, dan wordt het verzoek alsnog geweigerd met een duidelijke foutmelding.

ERE-consolidatie

Geen automatische consolidatie

ERE-claims en kWh-records worden niet geaggregeerd op holding-niveau. Elke organisatie (moeder en elk van haar dochters) houdt haar eigen claims en jaaroverzichten via het dual ownership-patroon (userId OF organizationId, nooit beide).

Dit betekent concreet voor admin-verwerking:

• Elke dochter-BV heeft eigen laadpalen, documenten, kWh-records, authorizations en EREClaims.
• Een jaaroverzicht wordt per organisatie-ID gegenereerd; er is geen "holding-jaaroverzicht" dat automatisch alle dochters optelt.
• Uitbetalingen lopen altijd naar de IBAN van de specifieke organisatie waarop de claim geregistreerd staat, niet centraal via de holding.
• De custom pricing (fees 1/3/5 jaar) staat per organisatie. Een holding kan andere tarieven hebben dan haar dochters.

Voor een geaggregeerd financieel beeld moet u handmatig de claims per organisatie combineren, bijvoorbeeld via export van het EREClaims-overzicht gefilterd op organisatie.

Asset-zicht vanuit holding-detailpagina

Op de admin detailpagina van een holding ziet u alleen de direct aan de holding gekoppelde assets: haar eigen leden, laadpalen, authorizations, documenten, kWh-records en ERE-claims. Dochter-assets zijn niet genest zichtbaar op de holding-detailpagina — u moet doorklikken naar de detailpagina van de dochter-BV zelf.

Het organisatie-overzicht in de gegroepeerde weergave toont wel de aggregatietotalen (leden en laadpalen) van een holding inclusief haar dochters als hulpmiddel voor snelle inschatting.

Sectie op detailpagina	Scope
Basisgegevens (KVK, adres, IBAN)	Deze organisatie
Prijsstelling (custom fees)	Deze organisatie
Leden (OrgMembersSection)	Deze organisatie
Authorizations	Deze organisatie
Documenten	Deze organisatie
kWh-records	Deze organisatie
ERE-claims	Deze organisatie
Laadsessies	Deze organisatie

Troubleshooting

Koppeling faalt: "Organisatie al gekoppeld aan andere holding"

Dit treedt op als iemand anders de dochter al heeft gekoppeld of als een eerder verzoek al is goedgekeurd. Controleer het huidige parentOrganizationId op de detailpagina van de dochter. Los op door de bestaande koppeling te verbreken (via de dochter-eigenaar in hun portaal), waarna een nieuw verzoek gemaakt kan worden.

Koppeling faalt: "Een holding kan niet als dochter worden gekoppeld"

De doelorganisatie is zelf al een HOLDING omdat er dochters aan haar gekoppeld zijn. Een holding kan niet tegelijk ondergeschikt zijn aan een andere holding. Ontkoppel eerst alle dochters van de doel-holding.

Verzoek zit vast op PENDING

Mogelijke oorzaken:

• De dochter-eigenaar heeft de goedkeuringsmail niet ontvangen. Controleer de audit-log voor de e-mailpoging en vraag de ontvanger het spamfolder te controleren.
• Er zijn geen actieve EIGENAAR-memberships op de dochterorganisatie. Het verzoek zal blijven openstaan tot expiry.

Manual intervention: als admin kunt u via het organisatie-overzicht de dochter-BV bewerken en handmatig parentOrganizationId toewijzen. Dit omzeilt het verzoekmechanisme maar omzeilt ook de audit trail — gebruik alleen bij technische problemen en noteer de reden.

Ongewenste koppeling verbreken

Alleen de dochter-eigenaar kan in hun eigen portaal de koppeling met de holding verbreken. Als admin kunt u dat forceren via een directe databasewijziging of door de subsidiary-delete-route te gebruiken (DELETE /organizations/:id/subsidiaries/:childId). Bij het loskoppelen wordt de holding automatisch teruggezet naar STANDALONE als er geen dochters meer over zijn.

Audit-logging

Alle holding-gerelateerde acties worden gelogd in OrganizationAuditLog. Voor elk koppelingverzoek komen er twee logregels per goedkeuring: een bij de moeder (SUBSIDIARY_LINK_APPROVED) en een bij de dochter (SUBSIDIARY_LINK_ACCEPTED).

Actie	Entiteit die logt	Details
SUBSIDIARY_LINK_REQUESTED	Moederorganisatie	childOrganizationId, childName, childKvk
SUBSIDIARY_LINK_APPROVED	Moederorganisatie	childOrganizationId, childName
SUBSIDIARY_LINK_ACCEPTED	Dochterorganisatie	parentOrganizationId, parentName
SUBSIDIARY_LINK_REJECTED	Moederorganisatie	childOrganizationId, rejectionReason
SUBSIDIARY_LINK_CANCELLED	Moederorganisatie	childOrganizationId, childName

Elke logregel bevat userId (wie de actie uitvoerde), ipAddress en een timestamp. Hiermee is iedere wijziging in de hierarchie traceerbaar voor compliance- en supportdoeleinden.

Zichtbaarheid audit-logs

Audit-logs van een organisatie zijn zichtbaar via de admin gebruikersdetailpagina (tab audit-log) en via de algemene audit-log viewer. Zie Audit logs voor meer details.