Laadpunten verwijderen

Beheerders kunnen een laadpaal niet rechtstreeks verwijderen. Verwijdering verloopt altijd via een verwijderverzoek dat door de klant moet worden goedgekeurd. Dit voorkomt onbedoelde dataverlies en zorgt ervoor dat de eigenaar van de laadpaal instemt met het wissen van alle gekoppelde gegevens.

Wanneer gebruiken

Gebruik deze flow in situaties als:

• De klant heeft een laadpaal dubbel aangemaakt of met verkeerde gegevens
• De klant vraagt zelf (bijvoorbeeld via support) om verwijdering
• Een laadpaal is per ongeluk aangemaakt tijdens onboarding of import
• Een laadpaal hoort niet bij de huidige eigenaar en kan niet via een asset transfer worden opgelost

Onomkeerbaar bij goedkeuring

Zodra de klant het verzoek goedkeurt, worden de laadpaal en alle gekoppelde kWh-records, laadsessies, ERE claims, legacy ERE records en berekeningen permanent verwijderd. Documenten gaan naar de prullenbak en zijn daar nog 30 dagen herstelbaar.

Toegang

Open Admin > Laadpunten, klik een laadpaal aan om de detailpagina te openen. In de rechter sidebar vindt u de kaart Laadpaal verwijderen (rood omrand). Vanuit hier start u het verzoek.

Blokkerende controles

Voordat een verwijderverzoek kan worden aangemaakt, controleert het systeem of er financiele afhankelijkheden zijn. Wanneer een van onderstaande condities geldt, is verwijdering geblokkeerd en verschijnt een foutmelding in de modal:

Controle	Toelichting
Uitbetaalde ERE claims	ERE claims gekoppeld aan kWh-records van deze laadpaal met status PAID of paidAt gezet
Verkochte ERE claims	ERE claims met soldAt gezet of gekoppeld aan een saleBatchId
Uitbetaalde legacy ERE records	Legacy ERERecord entries met status PAID voor deze laadpaal

Als een van deze blokkades geldt, moet de onderliggende financiele situatie eerst handmatig worden opgelost (bijvoorbeeld door uitbetalingen terug te draaien of te herboeken) voordat een verwijderverzoek kan worden gestart.

Geen dubbele verzoeken

Per laadpaal kan slechts een verzoek tegelijk openstaan. Bestaat er al een verzoek met status "In afwachting", dan moet dat eerst worden beantwoord of geannuleerd.

Flow

1. Verzoek aanmaken

1. Klik in de sidebar op Verwijderverzoek starten
2. Het systeem controleert automatisch de blokkerende condities (zie hierboven)
3. Vul het Bericht aan klant in — leg uit waarom u de laadpaal wilt verwijderen. Dit bericht verschijnt in de e-mail en op de responspagina
4. Klik op Verzoek versturen

Bij het versturen gebeurt het volgende automatisch:

• Een uniek responseToken wordt gegenereerd (32 bytes hex)
• De vervaldatum wordt gezet op 30 dagen vanaf aanmaak
• Optioneel wordt een referentie naar een bestaand support-gesprek (ticketReference in formaat TIC-0001) vastgelegd
• De klant ontvangt direct een e-mail met het verzoek en een link naar de responspagina
• Er wordt een audit log entry aangemaakt (zie Audit trail)

2. Klant reageert

De klant ontvangt een e-mail en opent de responspagina via de unieke tokenlink. De klant moet ingelogd zijn en moet eigenaar (of EIGENAAR van de organisatie) van de laadpaal zijn om te kunnen reageren.

De klant kan kiezen:

• Goedkeuren — de laadpaal en alle gekoppelde data worden verwijderd
• Afwijzen — optioneel met reden; het verzoek blijft bestaan met status "Afgewezen"

3. Systeem verwerkt de respons

Bij goedkeuring voert de backend een veilige verwijdering uit:

1. Blokkerende condities worden nogmaals gecontroleerd (als safety net). Is er alsnog een blokkade, dan wordt het verzoek op CANCELLED gezet
2. Alle gekoppelde documenten worden naar de prullenbak verplaatst (soft-delete, 30 dagen herstelbaar)
3. In een database-transactie wordt het volgende hard verwijderd:
   • ERE claims gekoppeld aan de kWh-records
   • Monthly kWh records
   • Laadsessies (ChargingSession)
   • Legacy ERE records (ERERecord)
   • Berekeningsgeschiedenis (CalculationHistory)
   • De laadpaal zelf (ChargingPoint)
4. Het verzoek krijgt status APPROVED met deletionExecutedAt en documentsMovedToTrash geteld
5. De aanvragende beheerder ontvangt een bevestigingsmail

Bij afwijzing wordt het verzoek op status REJECTED gezet met de opgegeven reden. De aanvragende beheerder ontvangt een e-mail met de reden. De laadpaal blijft ongewijzigd.

4. Verzoek annuleren (optioneel)

Zolang het verzoek de status "In afwachting" heeft, kan de beheerder het annuleren via de knop Verzoek annuleren in de sidebar. De klant kan dan niet meer reageren via de tokenlink.

Statussen

Status	Betekenis
PENDING	Verzoek is verstuurd, wacht op reactie klant
APPROVED	Klant heeft goedgekeurd, laadpaal is verwijderd
REJECTED	Klant heeft afgewezen, laadpaal blijft bestaan
EXPIRED	Niet beantwoord binnen 30 dagen
CANCELLED	Ingetrokken door beheerder (of door safety-net blokkade tijdens uitvoering)

Automatisch verlopen

Een dagelijkse achtergrondtaak (chargingPointDeletionExpiryJob) draait elke dag om 07:45 en zet openstaande verzoeken ouder dan 30 dagen automatisch op status EXPIRED. Een verlopen verzoek kan niet meer worden beantwoord; de beheerder kan een nieuw verzoek aanmaken.

Audit trail

Alle acties rondom verwijderverzoeken worden vastgelegd in de audit log:

Actie	Moment
CHARGING_POINT_DELETION_REQUESTED	Beheerder maakt verzoek aan
CHARGING_POINT_DELETION_APPROVED	Klant keurt goed, laadpaal is verwijderd
CHARGING_POINT_DELETION_REJECTED	Klant wijst af
CHARGING_POINT_DELETION_CANCELLED	Beheerder annuleert openstaand verzoek

Elke audit log entry bevat de laadpaal-ID, de naam van de laadpaal, het IP-adres van de handelende gebruiker, en bij goedkeuring het aantal verplaatste documenten en verwijderde kWh-records. Bekijk de audit log via Admin > Audit logs.

Endpoints

Voor ontwikkelaars en troubleshooting, een overzicht van de betrokken routes:

Admin-zijde — mounted onder /api/v1/admin/charging-point-deletions

Methode	Pad	Doel
GET	/check/:chargingPointId	Controleer blokkerende condities vooraf
POST	/	Nieuw verwijderverzoek aanmaken
GET	/:chargingPointId	Geschiedenis van verzoeken voor een laadpaal
PATCH	/:id/cancel	Openstaand verzoek annuleren

Klant-zijde — mounted onder /api/v1/charging-point-deletions

Methode	Pad	Doel
GET	/token/:token	Verzoek ophalen via tokenlink (auto-expire indien verlopen)
POST	/:id/respond	Goedkeuren of afwijzen (body: approve, optioneel rejectionReason)