# Eltilmeldinger til netselskabet, indsendt af en robot.

> elmeld indsender eltilmeldinger for en elinstallatør: nye ladestandere og plombebrud, meldt til netselskabet. En robot betjener netselskabets portal, som et menneske ville, én adresse ad gangen, og et dashboard og en daglig e-mail viser, hvad der er indsendt, hvad der fejlede, og hvad der kræver en person.

- URL: https://bon.do/cases/elmeld
- Client: elmeld
- Sector: El-installation
- Platforms: Browserrobot, webdashboard og daglig e-mail
- Role: Automatiseringsplatform
- Outcome: Indsender eltilmeldinger med en robot og giver kun en person de sager, der kræver en.
- Tags: Automation, SaaS

## Overview

elmeld indsender eltilmeldinger for en elinstallatør: nye ladestandere og plombebrud, meldt til netselskabet. En robot betjener netselskabets portal, som et menneske ville, én adresse ad gangen, og et dashboard og en daglig e-mail viser, hvad der er indsendt, hvad der fejlede, og hvad der kræver en person.

Hver ny ladestander og hvert plombebrud skal meldes til netselskabet i en webportal uden API. I hånden betyder det at logge ind, taste adressen, vente på adressevalideringen, kontrollere at adressen hører til netselskabet og udfylde en formular i flere sektioner, igen og igen. En adresse, der hører under et andet netselskab, viser sig først halvvejs, og en tilmelding, der stille fejlede, opdages først, når nogen leder efter den.

Vi byggede en RPA-platform i Node 22 og TypeScript. En Playwright-robot logger ind via portalens Azure B2C-login én gang og holder derefter sessionen i live med AES-256-GCM-krypterede tokens og stille fornyelse. Hver adresse kører syv trin: portal, tilmeldingstype, adresseopslag mod DAWA, elnetkontrol, oprettelse af sagen, formular og indsendelse, hvert trin tidsmålt. Køen er PostgreSQL med SKIP LOCKED-claiming og recovery af hængte jobs. Genforsøg afhænger af fejlkoden: forkert elnet prøves aldrig igen, men lægges til side og rapporteres pr. netselskab, og efter fem fejlede forsøg overgår et job til en person. Et Angular 21-dashboard og en daglig rapport på e-mail viser resultatet, og platformen kører på Kubernetes.

Tilmeldinger kommer ind via API’et, en Zapier-integration eller en CSV-batch, og robotten indsender dem, mens holdet laver andet. Hver sag viser sine syv tidsmålte trin og, når den fejler, en navngiven fejl i stedet for en stacktrace. Adresser i forkert elnet holdes adskilt fra rigtige fejl, og den daglige e-mail viser, hvad der kræver opfølgning. Platformen har 594 automatiserede tests i 73 filer.

## Results

- **Pr. tilmelding:** 7 steps. Hvert trin tidsmålt, fra portal til indsendelse.
- **Før en person tager over:** 5 attempts. Genforsøg følger fejlkoden. Forkert elnet prøves aldrig igen.
- **Automatiserede:** 594 tests. Unit-, integrations- og simulationstests i 73 filer.

## At a glance

- **Kunde:** Anderup Ntech (elmeld)
- **Produkt:** RPA til eltilmeldinger
- **Brugere:** Elinstallatører · kontorpersonale
- **Vores rolle:** Design, udvikling og drift
- **Type:** B2B-automatisering
- **Teknologi:** Node 22 · TypeScript · Hono · Playwright · PostgreSQL · Angular 21 · Kubernetes
- **Tidslinje:** Løbende produktpartnerskab

## What we built

### 01. En robot med en session der holder

Playwright gennem Azure B2C, krypterede tokens, stille fornyelse, DAWA-adresseopslag og en elnetkontrol, der venter på, at portalen falder til ro.

### 02. En kø der kender sine fejl

PostgreSQL med SKIP LOCKED, hård timeout, recovery af hængte jobs og genforsøg valgt efter fejlkode, så en person kun ser det, en person skal tage stilling til.

### 03. Et dashboard og en daglig rapport

En live kø, tidsmåling pr. trin, et års historik i kalender og på kort, og en e-mail hver dag med det indsendte og det, der kræver opfølgning.

## How it ran

### 01. Afklar: Portalen, trin for trin

Login, adresseopslag, elnetkontrol og hvert formularfelt, kortlagt for begge tilmeldingstyper.

### 02. Design: En fejltype til hver situation

En navngiven fejl pr. situation, så køen ved, hvad der skal prøves igen, lægges til side eller gives til en person.

### 03. Byg: Testet uden browser

En hexagonal backend, 594 tests og en dry run, der kontrollerer en hel batch uden at indsende noget.

### 04. Drift: Drevet, ikke kun leveret

Kubernetes, en hukommelsesvagt på browseren, Datadog-monitorer på kørsler og rapporter, og en runbook til de fejl, der faktisk opstår.



## Contact

Bon.do ApS · Rantzausmindevej 228, 5700 Svendborg, Denmark · info@bon.do · https://bon.do/kontakt