Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Om Test op imod Test database

Disse test retter sig imod: **invoice controller**.

Disse manuelle tests udføres i **middleware / Swagger UI** ("Try it out"). Testeren kan kun sætte **kald-parametre** og observere svaret.

Der er **ingen** adgang til lokale json-konfig-filer såsom: `appsettings.json` / `MyConfiguration.json`.

Synlighedsfiltre styres via BCHEC-indstillinger for det givne firmanr i SonWin **Test-databasen**.

> **Delt Test-database — vigtigt:**
> - **A, B, E*, F, G, H** er læse-tests bundet til bestemte konti → kan køres samtidig med andre testere.
> - **C, D, E** kræver, at et BCHEC-flag sættes for **firmaet** + at API'et genstartes. Det er **globalt for hele firmaet** (ikke pr. konto), så det påvirker **alle** testere på firmaet uanset `accountId`. Koordinér disse (stille vindue eller dedikeret firmanr).

Før du går i gang

- Testene køres mod **Swagger UI** på endpointet `GET /accounts/{accountId}/invoices`.
- Datoer angives som `ÅÅÅÅ-MM-DD`. Udelades `limit`, returneres kun de **nyeste 100** fakturaer. Testkontiene herunder er små (≤ 46 fakturaer), så standard-`limit` rækker — men sæt et højere `limit`, hvis du udvider til større konti.
- **Fejl returneres i øjeblikket som HTTP 500** med en forklarende tekst i svaret. Vurdér derfor på **beskeden**, ikke på statuskoden.
- Filtrene i afsnit **C–E** styres af **BCHEC** i databasen. Efter en ændring i BCHEC skal API'et **genstartes**, før ændringen slår igennem.

Konkrete værdier nedenfor er hentet fra **Test-databasen** (2026-06-24). Foretrukne testkonti `305493`, `307375`, `309941` (valgt for at undgå sammenstød med andre testere).

Hvor en sag ikke fandtes på disse konti (parkeret, annulleret, kreditnota, PDF), bruges en **delt fallback-konto** — markeret tydeligt.

Bchec-indstillinger:

Her er de relevante Bchec-indstillinger som kan sættes for at hente en liste af SonWin fakturaer:

────────────────────────────────────────

UDSMARK- / fremtidsdaterings-flag

KODENAVN: WEB011_WEB012
KODETYPEA: VISEJPARKEREDE
Filter (kode): ExcludeParked
Virkning på resultatet: Skjuler parkerede fakturaer.
Tilføjet SQL-prædikat: (a.UDSMARK IS NULL OR a.UDSMARK <= 25)
────────────────────────────────────────
KODENAVN: WEB011_WEB012
KODETYPEA: CHECKUDSMARK
Filter (kode): CheckUdsmark
Virkning på resultatet: Beholder kun UDSMARK NULL / 0 / 2–25; fjerner også UDSMARK = 1
  (markeret-men-ikke-udskrevet).
Tilføjet SQL-prædikat: (a.UDSMARK IS NULL OR a.UDSMARK = 0 OR a.UDSMARK BETWEEN 2 AND 25)
────────────────────────────────────────
KODENAVN: WEB011_WEB012
KODETYPEA: VISKUNUDSKREVNE
Filter (kode): ShowOnlyDelivered
Virkning på resultatet: Viser kun udsendte/udskrevne fakturaer: UDSMARK <= 25 plus et
  SNEX/DSEND-leveringstjek (DELIVERYSTATE IN (5, 9)).
Tilføjet SQL-prædikat: UDSMARK <= 25 + DSEND/SNEX EXISTS/NOT EXISTS-blokken
────────────────────────────────────────
KODENAVN: WEB011_WEB012
KODETYPEA: EJFREMTID
Filter (kode): ExcludeFutureDated
Virkning på resultatet: Skjuler fremtidsdaterede fakturaer (BILAGSDATO efter i dag).
Tilføjet SQL-prædikat: a.BILAGSDATO <= @Today

De tre UDSMARK-varianter (VISEJPARKEREDE, CHECKUDSMARK, VISKUNUDSKREVNE) er alternative måder at frasortere parkerede/ikke-udsendte fakturaer på; et firma aktiverer typisk én af dem, men de kan kombineres.

────────────────────────────────────────

Frasortering af afregningstyper

KODENAVN: W11_W12EJAFRTYP
KODETYPEA: hver konfigureret rækkes KODETYPEA = én AFREGNTYPE-værdi der skal udelukkes
Filter (kode): ExcludeAfregnTypes
Virkning: Udelukker fakturaer hvis AFREGNTYPE er i det konfigurerede sæt. NULL-AFREGNTYPE rammes ikke af NOT
  IN og bliver derfor stående.

## Endepunkter

- **Liste:** `GET /accounts/{accountId}/invoices?dateFrom=&dateTo=&limit=`
- **PDF:** `GET /v1/accounts/{accountId}/invoices/{invoiceId}/pdf` hvor `invoiceId = {INSTNR}-{FORBNR}-{UDEBNR}-{REGNINGNR}`

Tests

A. Grundlæggende test ("virker det overhovedet?")
**Formål:** Bekræfte at endpointet svarer, og at felterne ser rigtige ud.

**A1 – Hent fakturaer for en kendt kunde**

1. Kald endpointet med `accountId = 305493`, `dateFrom = 2015-01-01`, `dateTo = 2026-12-31`.
2. *Forventet:* HTTP 200 og en liste med fakturaer (46 stk., ikke tom).

**A2 – Tjek felterne på en faktura**

1. Brug svaret fra A1, og se på den første faktura.
2. *Forventet:* `id` har formen `INSTNR-FORBNR-UDEBNR-REGNINGNR`, og felterne `invoiceDate`, `dueDate`, `totalAmount`, `remainingAmount` (saldo), `invoiceStatus` og `invoiceType` er udfyldt.

**A3 – Begræns til én faktura**

1. Gentag A1, men tilføj `limit = 1`.
2. *Forventet:* Præcis 1 faktura — den nyeste (`BILAGSDATO 2026-04-14`).

**A4 – Fremtidigt interval uden fakturaer**

1. Kald med `accountId = 305493`, `dateFrom = 2099-01-01`, `dateTo = 2099-12-31`.
2. *Forventet:* HTTP 200 og en **tom liste** `[]` (ikke en fejl).

B. Inputvalidering ("pæne fejl ved forkert input")
**Formål:** Bekræfte at forkert input giver en klar fejlbesked (i dag HTTP 500 + tekst), ikke en kryptisk databasefejl.

**B1 – Manglende dato (fra)** — Kald uden `dateFrom`, med `dateTo = 2030-12-31`. *Forventet:* Besked om at `DateFrom` mangler/er ugyldig (interval 1753–9999) — ikke "SqlDateTime overflow".

**B2 – Manglende dato (til)** — `dateFrom = 2000-01-01`, intet `dateTo`. *Forventet:* Tilsvarende besked om `DateTo`.

**B3 – Omvendt datointerval** — `dateFrom = 2030-01-01`, `dateTo = 2000-01-01`. *Forventet:* Besked om at `DateFrom` skal være ≤ `DateTo`.

**B4 – Ugyldigt limit** — gyldige datoer + `limit = 0`. *Forventet:* Besked om at `Limit` skal være ≥ 1.

**B5 – Manglende kunde-id** — tomt `accountId`. *Forventet:* Fejl om manglende `AccountId`.

**B6 – Dato før databasens minimum** — `dateFrom = 1500-01-01`, `dateTo = 2030-12-31`. *Forventet:* Pæn valideringsfejl — ikke "SqlDateTime overflow".

**B7 – Ukendt kunde** — `accountId = 999999999`, gyldigt interval. *Forventet:* Fejl med besked om at kunden ikke findes.

C. Synlighed af parkerede fakturaer (UDSMARK-varianter)
**Formål:** Bekræfte at de tre UDSMARK-flag skjuler en parkeret faktura.

> **Ingen parkerede fakturaer i Test-databasen p.t.** Ingen faktura på firmaet har `UDSMARK > 25`, så C kan ikke køres på eksisterende data. Du skal først **oprette** en parkeret faktura. Dette ændrer delt testdata + kræver et globalt BCHEC-flag og genstart → **koordinér med andre testere**.

**Forberedelse (opret + nulstil testdata).** Park en eksisterende faktura på `305493` (den forfaldne `503-1-1-56`):
```sql
-- 1) Notér nuværende værdi (til nulstilling bagefter):
SELECT UDSMARK FROM Sonlinc.AKOND WITH (NOLOCK)
WHERE FIRMANR = @CompanyId AND INSTNR = 503 AND FORBNR = 1 AND UDEBNR = 1 AND REGNINGNR = 56;
-- 2) Park den:
UPDATE Sonlinc.AKOND SET UDSMARK = 26
WHERE FIRMANR = @CompanyId AND INSTNR = 503 AND FORBNR = 1 AND UDEBNR = 1 AND REGNINGNR = 56;
-- ... kør C-trinene ...
-- 3) Nulstil til den oprindelige værdi fra trin 1 (typisk NULL eller 0):
UPDATE Sonlinc.AKOND SET UDSMARK = <oprindelig værdi>
WHERE FIRMANR = @CompanyId AND INSTNR = 503 AND FORBNR = 1 AND UDEBNR = 1 AND REGNINGNR = 56;
```
Brug i alle C-trin: `accountId = 305493`, `dateFrom = 2026-04-01`, `dateTo = 2026-04-30`.

C0 – Udgangspunkt (uden flag)**
1. Med fakturaen parkeret (UDSMARK 26) og **uden** `WEB011_WEB012`-flag: kald med ovenstående parametre.
2. *Forventet:* `503-1-1-56` **er** med. Notér antal.

**C1 – VISEJPARKEREDE** — Opret `WEB011_WEB012 / VISEJPARKEREDE`, genstart, gentag. *Forventet:* `503-1-1-56` **forsvinder**.

**C2 – CHECKUDSMARK** — Fjern C1-flaget, opret `WEB011_WEB012 / CHECKUDSMARK`, genstart, gentag. *Forventet:* `503-1-1-56` forsvinder (UDSMARK 26 uden for NULL/0/2–25).

**C3 – VISKUNUDSKREVNE** — Fjern C2-flaget, opret `WEB011_WEB012 / VISKUNUDSKREVNE`, genstart, gentag. *Forventet:* `503-1-1-56` forsvinder (UDSMARK > 25).

**C4 – Flere flag samtidig** — Aktivér fx VISEJPARKEREDE + VISKUNUDSKREVNE, genstart, gentag. *Forventet:* Resultatet er snittet (færrest rækker).

> Husk at nulstille `UDSMARK` (forberedelsens trin 3) og fjerne BCHEC-flagene + genstarte, når C er færdig.

D. Fremtidsdaterede fakturaer (EJFREMTID)
**Formål:** Bekræfte at `WEB011_WEB012 / EJFREMTID` skjuler fakturaer med bilagsdato efter i dag.

> **Ingen testdata p.t.:** Firmaet har ingen fakturaer med bilagsdato i fremtiden, så D kan ikke demonstreres uden først at oprette en fremtidsdateret faktura. (Forveksl ikke med A4, der tester et fremtidigt *datointerval* → tom liste.)

**D1 – Skjul fremtidsdaterede (når data findes)** — Find/opret en faktura med bilagsdato efter i dag, opret `WEB011_WEB012 / EJFREMTID`, genstart, kald med interval der dækker datoen. *Forventet:* Den fremtidsdaterede faktura er **ikke** med.

**D2 – Uden flaget** — Fjern flaget, genstart, gentag. *Forventet:* Den fremtidsdaterede faktura **er** med.

## E. Frasortering af afregningstyper (W11_W12EJAFRTYP)
**Formål:** Bekræfte at fakturaer med en bestemt afregningstype kan frasorteres.

**Testdata:** Konto `305493` har `KV-EN` (41), `KV-I` (4) og præcis **1** faktura med `AFREGNTYPE = NULL` (i alt 46). Brug i alle E-trin: `accountId = 305493`, `dateFrom = 2015-01-01`, `dateTo = 2026-12-31`.

E2 – Udgangspunkt (tom liste i BCHEC)**
1. Sørg for at `W11_W12EJAFRTYP` **ingen** rækker har for firmaet.
2. Kald med ovenstående parametre. *Forventet:* Antal = **46**.

**E1 – Udeluk én afregningstype**

1. Opret `W11_W12EJAFRTYP` med `KODETYPEA = KV-I`, og genstart.
2. Gentag kaldet. *Forventet:* 4 færre = **42**. (Større alternativ: udeluk `KV-EN` → 41 færre = 5.)

**E3 – NULL rammes ikke**

1. Med `KV-I` stadig udelukket, kig efter fakturaen med `AFREGNTYPE = NULL`.
2. *Forventet:* Den ene NULL-faktura er stadig med (`NOT IN` matcher ikke NULL).

F. PDF-tilstedeværelse og fakturatype
**Formål:** Bekræfte at listen som udgangspunkt kun viser fakturaer med en færdig PDF, markeret `invoiceType = pdf`.

> Ingen af de tre foretrukne konti har en renderet PDF → brug **delt fallback-konto `200229`**.

**Testdata:** `200229 / 400-1-1-56` har en renderet PDF (bilagsdato 2026-04-14).

**F1 – Kun fakturaer med PDF, markeret som `pdf`**

1. Kald med `accountId = 200229`, `dateFrom = 2026-04-01`, `dateTo = 2026-04-30`.
2. *Forventet:* `400-1-1-56` er med, og de returnerede fakturaer har `invoiceType = pdf`. (Fakturaer uden renderet PDF kommer som udgangspunkt slet ikke med.)

G. Download af faktura-PDF
**Formål:** Bekræfte at PDF'en kan hentes, og at fejl håndteres pænt. Endpoint: `GET /v1/accounts/{accountId}/invoices/{invoiceId}/pdf`.

**G1 – Hent en gyldig PDF** — `accountId = 200229`, `invoiceId = 400-1-1-56`. *Forventet:* HTTP 200, binær PDF (`application/pdf`) der kan åbnes.

**G2 – Ugyldigt id-format** — `invoiceId = 123-456` (mangler led). *Forventet:* Håndteret fejl om at `InvoiceId` skal have formen `INSTNR-FORBNR-UDEBNR-REGNINGNR`.

**G3 – Velformet, men ikke-eksisterende id** — korrekt format, ikke-eksisterende nr. *Forventet:* Passende fejl — ikke en tom/ødelagt fil.

H. Status på fakturaer (saldo-model)
**Formål:** Bekræfte at `invoiceStatus` og `remainingAmount` afspejler den løbende saldo (SonWin er saldo-baseret).

**Testdata:** Ét kald på konto `309941` med `dateFrom = 2015-01-01`, `dateTo = 2026-12-31` returnerer H2–H4 på én gang. H1 ligger på den delte konto `200229`.

**H1 – Annulleret (`cancelled`)** *(delt konto)*

1. Kald med `accountId = 200229`, `dateFrom = 2015-07-01`, `dateTo = 2015-07-31`.
2. *Forventet:* `400-1-1-2` har status `cancelled`.
3. *Bonus:* `400-1-1-3` (samme dag) er både `KORTSTATUS = 99` og `KR < 0` → bekræfter at `cancelled` vinder over `credited`.

**H2 – Kreditnota (`credited`)**

1. Kald med `accountId = 309941`, `dateFrom = 2016-01-01`, `dateTo = 2016-12-31`.
2. *Forventet:* `479-1-1-9` (−165,65) har status `credited`.

**H3 – Betalt (`paid`)**

1. Kald med `accountId = 309941`, `dateFrom = 2015-01-01`, `dateTo = 2015-12-31`.
2. *Forventet:* `479-1-1-1` (beløb 0,00, **saldo 0,00**) har status `paid`. *(Bemærk: dette er kontoens åbnings-/nul-postering — den eneste linje hvor saldo ≤ 0; kontoen er i debet derefter.)*

**H4 – Forfalden (`overdue`)**

1. Kald med `accountId = 309941`, `dateFrom = 2026-01-01`, `dateTo = 2026-12-31`.
2. *Forventet:* `479-1-1-54` (saldo 601,01, **forfald 2026-05-04**, dvs. før i dag) har status `overdue`.

**H5 – Ubetalt (`unpaid`)**

> **Ingen testdata p.t.:** Ingen faktura på firmaet er **fremtidsforfalden med positiv saldo** — de nyeste fakturaer er allerede forfaldne (→ `overdue`). H5 kan derfor ikke demonstreres uden at oprette en faktura med fremtidig forfaldsdato og positiv saldo.

**H6 – Saldo stemmer med kilden**

1. Vælg en kendt konto, sammenlign `remainingAmount` med den løbende saldo i SonWin/RVV for samme forbrugssted.
2. *Forventet:* Beløbene stemmer (samme `lbsum`-beregning).

---------------------------------- Nedenfor findes Test rettet imod Produktionsdata --------------------------------------

Om

Disse test retter sig imod: invoice controller. 

Disse manuelle tests udføres i **middleware / Swagger UI** ("Try it out"). Testeren kan kun sætte **kald-parametre** og observere svaret.

Der er **ingen** adgang til lokale json-konfig-filer såsom: "appsettings.json" / "MyConfiguration.json".

Synlighedsfiltre styres via BCHEC indstillinger for det givne firmanr i SonWin Test-database.

Før du går i gang

- Testene køres mod **Swagger UI** på endpointet `GET /accounts/{accountId}/invoices`.
- Datoer angives som `ÅÅÅÅ-MM-DD`. Udelades `limit`, returneres kun de **nyeste 100** fakturaer — sæt derfor `limit` højere, når en bestemt (ofte ældre) faktura skal findes.
- **Fejl returneres i øjeblikket som HTTP 500** med en forklarende tekst i svaret. Vurdér derfor på **beskeden**, ikke på statuskoden.
- Filtrene i afsnit **C–E** styres af **BCHEC** i databasen. Efter en ændring i BCHEC skal API'et **genstartes**, før ændringen slår igennem.

  • Som en (måske) hjælp er der på nogle Test tilføjet konkrete værdier som er hentet fra produktionsdata som i et eller andet forhold må forventes at ligne Test databasen.

Bchec-indstillinger:

Her er de relevante Bchec-indstillinger som kan sættes for at hente en liste af SonWin fakturaer:

────────────────────────────────────────

UDSMARK- / fremtidsdaterings-flag

KODENAVN: WEB011_WEB012
KODETYPEA: VISEJPARKEREDE
Filter (kode): ExcludeParked
Virkning på resultatet: Skjuler parkerede fakturaer.
Tilføjet SQL-prædikat: (a.UDSMARK IS NULL OR a.UDSMARK <= 25)
────────────────────────────────────────
KODENAVN: WEB011_WEB012
KODETYPEA: CHECKUDSMARK
Filter (kode): CheckUdsmark
Virkning på resultatet: Beholder kun UDSMARK NULL / 0 / 2–25; fjerner også UDSMARK = 1
  (markeret-men-ikke-udskrevet).
Tilføjet SQL-prædikat: (a.UDSMARK IS NULL OR a.UDSMARK = 0 OR a.UDSMARK BETWEEN 2 AND 25)
────────────────────────────────────────
KODENAVN: WEB011_WEB012
KODETYPEA: VISKUNUDSKREVNE
Filter (kode): ShowOnlyDelivered
Virkning på resultatet: Viser kun udsendte/udskrevne fakturaer: UDSMARK <= 25 plus et
  SNEX/DSEND-leveringstjek (DELIVERYSTATE IN (5, 9)).
Tilføjet SQL-prædikat: UDSMARK <= 25 + DSEND/SNEX EXISTS/NOT EXISTS-blokken
────────────────────────────────────────
KODENAVN: WEB011_WEB012
KODETYPEA: EJFREMTID
Filter (kode): ExcludeFutureDated
Virkning på resultatet: Skjuler fremtidsdaterede fakturaer (BILAGSDATO efter i dag).
Tilføjet SQL-prædikat: a.BILAGSDATO <= @Today

De tre UDSMARK-varianter (VISEJPARKEREDE, CHECKUDSMARK, VISKUNUDSKREVNE) er alternative måder at frasortere parkerede/ikke-udsendte fakturaer på; et firma aktiverer typisk én af dem, men de kan kombineres.

────────────────────────────────────────

Frasortering af afregningstyper

KODENAVN: W11_W12EJAFRTYP
KODETYPEA: hver konfigureret rækkes KODETYPEA = én AFREGNTYPE-værdi der skal udelukkes
Filter (kode): ExcludeAfregnTypes
Virkning: Udelukker fakturaer hvis AFREGNTYPE er i det konfigurerede sæt. NULL-AFREGNTYPE rammes ikke af NOT
  IN og bliver derfor stående.

────────────────────────────────────────

Endepunkter:

- **Liste:** "GET /accounts/{accountId}/invoices?dateFrom=&dateTo=&limit="
- **PDF:** "GET /v1/accounts/{accountId}/invoices/{invoiceId}/pdf"
hvor invoiceId = {INSTNR}-{FORBNR}-{UDEBNR}-{REGNINGNR}

Information om controlleren findes her:

Invoice Controller

Tests

GetInvoices (Returner en liste af fakturaer på 0 eller flere fakturaer for kunden)

A. Grundlæggende test ("virker det overhovedet?")

Formål: Bekræfte at endpointet svarer, og at felterne ser rigtige ud.

A1 – Hent fakturaer for en kendt kunde
1. Kald endpointet med accountId = 327080, dateFrom = 2015-01-01, dateTo = 2026-12-31.
2. Forventet: HTTP 200 og en liste med fakturaer (ikke tom).

A2 – Tjek felterne på en faktura
1. Brug svaret fra A1, og se på den første faktura.
2. Forventet: id har formen INSTNR-FORBNR-UDEBNR-REGNINGNR, og felterne invoiceDate, dueDate, totalAmount, remainingAmount (saldo), invoiceStatus og invoiceType er udfyldt.

A3 – Begræns til én faktura
1. Gentag A1, men tilføj limit = 1.
2. Forventet: Præcis 1 faktura returneres, og det er den nyeste (sorteret efter bilagsdato faldende).

A4 – Fremtidigt interval uden fakturaer
1. Kald med accountId = 327080 og et interval langt ude i fremtiden, fx dateFrom = 2099-01-01, dateTo = 2099-12-31.
2. Forventet: HTTP 200 og en tom liste [] (altså ikke en fejl).

B. Inputvalidering ("pæne fejl ved forkert input")

Formål: Bekræfte at forkert input giver en klar fejlbesked (i dag HTTP 500 + tekst), ikke en kryptisk databasefejl.

B1 – Manglende dato (fra)
1. Kald uden dateFrom, men med dateTo = 2030-12-31.
2. Forventet: Besked om, at DateFrom mangler/er ugyldig (interval 1753–9999) — ikke "SqlDateTime overflow".

B2 – Manglende dato (til)
1. Kald med dateFrom = 2000-01-01 og uden dateTo.
2. Forventet: Tilsvarende besked om DateTo.

B3 – Omvendt datointerval
1. Kald med dateFrom = 2030-01-01 og dateTo = 2000-01-01.
2. Forventet: Besked om, at DateFrom skal være tidligere end eller lig DateTo.

B4 – Ugyldigt limit
1. Kald med gyldige datoer og limit = 0.
2. Forventet: Besked om, at Limit skal være 1 eller derover.

B5 – Manglende kunde-id
1. Kald med tomt accountId.
2. Forventet: Fejl om manglende AccountId.

B6 – Dato før databasens minimum
1. Kald med dateFrom = 1500-01-01, dateTo = 2030-12-31.
2. Forventet: Pæn valideringsfejl — ikke "SqlDateTime overflow".

B7 – Ukendt kunde
1. Kald med accountId = 999999999 og et gyldigt interval.
2. Forventet: Fejl med forklarende besked om, at kunden ikke findes.

C. Synlighed af parkerede fakturaer (UDSMARK-varianter)

Formål: Bekræfte at de tre UDSMARK-flag skjuler en parkeret faktura. Kræver, at flaget sættes i BCHEC (familie WEB011_WEB012) + genstart.

Testdata: Parkeret faktura 1084-3-1-51 på konto 403881 (UDSMARK = 26, bilagsdato 2022-04-07). Brug i alle C-trin: accountId = 403881, dateFrom = 2022-04-01, dateTo = 2022-04-30, limit = 500.

C0 – Udgangspunkt (uden flag)
1. Kald med ovenstående parametre, mens firmaet ingen WEB011_WEB012-flag har.
2. Forventet: Fakturaen 1084-3-1-51 er med i listen. Notér antal fakturaer som sammenligningsgrundlag.

C1 – VISEJPARKEREDE
1. Opret BCHEC WEB011_WEB012 / VISEJPARKEREDE for firmaet, og genstart API’et.
2. Gentag kaldet.
3. Forventet: 1084-3-1-51 er forsvundet; antallet er lavere end i C0.

C2 – CHECKUDSMARK
1. Fjern flaget fra C1. Opret i stedet WEB011_WEB012 / CHECKUDSMARK, og genstart.
2. Gentag kaldet.
3. Forventet: 1084-3-1-51 forsvinder (UDSMARK 26 ligger uden for NULL/0/2–25).

C3 – VISKUNUDSKREVNE
1. Fjern flaget fra C2. Opret i stedet WEB011_WEB012 / VISKUNUDSKREVNE, og genstart.
2. Gentag kaldet.
3. Forventet: 1084-3-1-51 forsvinder; antallet er lavere end eller lig C0.

C4 – Flere flag samtidig
1. Aktivér fx både VISEJPARKEREDE og VISKUNUDSKREVNE, og genstart.
2. Gentag kaldet.
3. Forventet: Resultatet er snittet af filtrene (færrest rækker).

D. Fremtidsdaterede fakturaer (EJFREMTID)

Formål: Bekræfte at flaget WEB011_WEB012 / EJFREMTID skjuler fakturaer med bilagsdato efter i dag.

Bemærk – ingen testdata p.t.: Firmaet har aktuelt ingen fakturaer med en bilagsdato i fremtiden, så D kan ikke demonstreres på de eksisterende data. 

Det kræver, at der først oprettes/findes en fremtidsdateret faktura. (Forveksl ikke med A4, der tester et fremtidigt datointerval og giver en tom liste.)

D1 – Skjul fremtidsdaterede (når data findes)
1. Find/opret en faktura med bilagsdato efter i dag. Opret WEB011_WEB012 / EJFREMTID, og genstart.
2. Kald med et interval, der dækker den fremtidige dato.
3. Forventet: Den fremtidsdaterede faktura er ikke med.

D2 – Uden flaget
1. Fjern flaget, og genstart.
2. Gentag kaldet.
3. Forventet: Den fremtidsdaterede faktura er med.

E. Frasortering af afregningstyper (W11_W12EJAFRTYP)

Formål: Bekræfte at fakturaer med en bestemt afregningstype kan frasorteres via BCHEC-familien W11_W12EJAFRTYP (én række pr. type, der skal udelukkes).

Testdata: Konto 327080 har bl.a. MD-I (141 fakturaer), KV-I (29) og præcis 1 faktura med AFREGNTYPE = NULL. Brug i alle E-trin: accountId = 327080, dateFrom = 2015-01-01, dateTo = 2026-12-31, limit = 2000 (så hele sættet på 1.542 kommer med).

E2 – Udgangspunkt (tom liste i BCHEC)
1. Sørg for, at W11_W12EJAFRTYP ingen rækker har for firmaet.
2. Kald med ovenstående parametre.
3. Forventet: Ingen afregningstyper frasorteres — antal = 1.542.

E1 – Udeluk én afregningstype
1. Opret en BCHEC-række W11_W12EJAFRTYP med KODETYPEA = MD-I, og genstart API’et.
2. Gentag kaldet.
3. Forventet: 141 færre fakturaer — antal = 1.401. (Mindre alternativ: udeluk KV-I → 29 færre.)

E3 – NULL rammes ikke
1. Med MD-I stadig udelukket fra E1, kig efter fakturaen med AFREGNTYPE = NULL.
2. Forventet: Den ene NULL-faktura er stadig med (en NOT IN-liste matcher ikke NULL).


Test af PDF-fakturaer (bør nok have sin Confluence side, men for her-og-nu, står det her)

F. PDF-tilstedeværelse og fakturatype

Formål: Bekræfte, at listen som udgangspunkt kun viser fakturaer, der har en færdig PDF i databasen, og at disse er markeret med invoiceType = pdf.

Testdata: Konto 476261 har en faktura 1201054-1-1-2 med en renderet PDF (bilagsdato 2026-06-23). Flere med PDF: 313587 / 1200923-1-1-2, 401925 / 1200836-1-1-2, 307701 / 1200949-1-1-2, 224789 / 1200990-1-1-2 (alle 2026-06-22).

F1 – Kun fakturaer med PDF, markeret som pdf
1. Kald med accountId = 476261, dateFrom = 2026-06-01, dateTo = 2026-06-30.
2. Forventet: Fakturaen 1201054-1-1-2 er med, og alle returnerede fakturaer har invoiceType = pdf. (Fakturaer uden renderet PDF kommer som udgangspunkt slet ikke med.)

Bemærk: Muligheden for også at vise fakturaer uden PDF (invoiceType = missing) samt finjustering af PDF-genkendelsen styres af lokal konfiguration og kan ikke ændres fra Swagger. De scenarier hører til udvikler-appendikset og indgår ikke i denne gennemgang.

G. Download af faktura-PDF

Formål: Bekræfte, at PDF’en kan hentes for en faktura, der har en PDF, og at fejl håndteres pænt.

Endpoint: GET /v1/accounts/{accountId}/invoices/{invoiceId}/pdf.

G1 – Hent en gyldig PDF
1. Kald med accountId = 476261 og invoiceId = 1201054-1-1-2 (fra F1).
2. Forventet: HTTP 200, og svaret er en binær PDF (application/pdf), der kan åbnes.

G2 – Ugyldigt id-format
1. Kald med et forkert formateret invoiceId, fx 123-456 (mangler led).
2. Forventet: En håndteret fejl om, at InvoiceId skal have formen INSTNR-FORBNR-UDEBNR-REGNINGNR.

G3 – Velformet, men ikke-eksisterende id
1. Kald med et korrekt formateret, men ikke-eksisterende invoiceId (eller en faktura uden PDF).
2. Forventet: En passende fejl — ikke en tom eller ødelagt fil.

H. Status på fakturaer (saldo-model)

Formål: Bekræfte, at invoiceStatus og remainingAmount afspejler den løbende saldo på kontoen (SonWin er saldo-baseret), og at hver status udledes korrekt.

Testdata: Ét kald på konto 327080 med dateFrom = 2026-01-01, dateTo = 2026-12-31, limit = 500 returnerer status-eksemplerne H3–H5 på én gang. H1 og H2 ligger på andre konti og er ældre, så de bruger hvert sit snævre datovindue.

H1 – Annulleret (cancelled)
1. Kald med accountId = 308678, dateFrom = 2015-07-01, dateTo = 2015-07-31.
2. Forventet: Fakturaen 14684-1-1-2 har status cancelled.
3. Bonus: 14684-1-1-3 (samme dag) er både annulleret og har negativt beløb — den skal stadig vise cancelled (annulleret vinder over kreditnota).

H2 – Kreditnota (credited)
1. Kald med accountId = 410166, dateFrom = 2023-12-01, dateTo = 2023-12-31.
2. Forventet: Fakturaen 14685-2-1-49 (−149,64) har status credited.
3. Alternativer (hvert sit vindue): 410166 / 14685-2-1-29 (2019-01), 260447 / 14686-1-1-13 (2016-06), 327080 / 31901-7-1-61 (2026-06).

H3 – Betalt (paid)
1. Kald med accountId = 327080, dateFrom = 2026-01-01, dateTo = 2026-12-31, limit = 500.
2. Forventet: Fakturaen 18587-3-1-58 (beløb 37,96, saldo 0,00) har status paid.

H4 – Forfalden (overdue)
1. Brug samme kald som H3.
2. Forventet: Fakturaen 19271-4-1-78 (saldo 94,16, forfald 2026-06-04, dvs. før i dag) har status overdue.

H5 – Ubetalt (unpaid)
1. Brug samme kald som H3.
2. Forventet: Fakturaen 17349-7-1-78 (saldo 117,70, forfald 2026-07-03, dvs. i fremtiden) har status unpaid.

H6 – Saldo stemmer med kilden
1. Vælg en kendt konto, og sammenlign remainingAmount med den løbende saldo i SonWin/RVV for samme forbrugssted.
2. Forventet: Beløbene stemmer (samme lbsum-beregning).


----------------------------------------------------

  • Regnings info kan hentes
    • Input parametre som matcher regningslinjer, og se at de kan findes.
  • Regnings relation er konsistent
    • Test at det ikke kan lade sig gøre at trække regningslinjer ud som tilhører andre kunder
    • Test at det ikke kan lade sig gøre at trække regningslinjer ud for tidligere eller fremtidige leverancer end denne kunde

About

The tests in this class applies to the invoice controller. 
<JESNI SKRIV NOGET HER>

Information

Information about the controller can be found in this link: 

<link til invoice controller doc>

Tests

Unique identification

  • Account returned should be unique and identifiable 
    • Error if more than one account with the same active customerid and status for active customer
  • Account detail match the things in Billing

...