bmc_hub/fremtidige planer/also-cloud-marketplace-periodefakturering.md

Plan: Korrekt periodefakturering af ALSO Cloud Marketplace til e-conomic

Dato: 15. oktober 2026
Status: Delvist implementeret lokalt — beløbsfejl og linjetekst rettet; ikke lagt på serveren.

0. Afklaret omfang og aktuel kodegennemgang

Status pr. 15. oktober 2026: Brugeren har efterfølgende autoriseret rettelsen med »løs problemet« og bekræftet, at sagsreferencen skal udelades.

Lokalt implementeret: nye ALSO-kladder bruger antal 1 og godkendt periodebeløb, mens licensantal/månedspris bevares i metadata og kundetekst. Eksklusive perioder vises med sidste inkluderede dato og dage. Eksisterende pending-kladder uden eksterne dokumentnumre eller eksportforsøg normaliseres i læsevisningen uden databaseskrivning. Eksport validerer mod den gemte kladde, og stale browserdata, dublerede kildelinjer eller ændrede beløb afvises. ALSO-linjer undtages fra almindelig kataloggenberegning og låses i kladdeeditoren. Kildebeløb med mere end to betydende decimaler, negativt beløb, manglende tal eller rabat kræver afklaring; de overskrives ikke automatisk. Hvis råkilden kun har Charge og ingen særskilt månedspris, må Charge ikke præsenteres som månedspris; godkendelsen blokeres.

Ikke implementeret som del af denne rettelse: udvidet fortjenestemodel, ny automatisk genlæsning/afstemning efter eksport, kontrol af senere fakturakladder, historisk audit og ændringer af dokumenthoved/referencefelter. Den eksisterende interne Hub-reference bevares af hensyn til dubletbeskyttelsen. Ingen migration eller produktionsændring udført. Ekstern e-conomic-test og PDF-kontrol udestår.

Omfanget er udelukkende ALSO Cloud Marketplace. Andre abonnementer, manuelle ordrelinjer og integrationer bevarer eksisterende adfærd. Afgræns med eksisterende kildeidentitet (source_type=also_cloud og relation til importlinjen); produktnavn alene må ikke aktivere løsningen.

Den konkrete fejl i den lokale kode

app/modules/also/backend/service.py, oprettelsen af draft_lines, gemmer både faktisk antal i quantity, månedspris i unit_price og kildebeløbet i amount. app/modules/orders/backend/economic_export.py bygger derimod e-conomic-linjen fra quantity og unit_price som quantity og unitNetPrice. Det særskilte periodebeløb bestemmer dermed ikke det eksporterede linjebeløb. Også app/products/backend/economic_documents.py:line_snapshot beregner nettobeløb ud fra antal gange enhedspris og rabat. Den fælles eksportkode må ikke ændres generelt for at rette ALSO.

Med oplæggets eksempel giver 116 × 67,08 kr. = 7.781,28 kr. for en linje, der skal være 7.028,25 kr. for 28 dage. Fejlen er 753,03 kr. på denne linje, hvis de nævnte værdier sendes uændret. Begge F3-periodelinjer vil tilsammen blive 15.562,56 kr. mod det forventede 7.781,28 kr., hvis begge eksporteres med fuldt antal og månedspris. Dette er en kodebaseret forklaring og regneeksempel, ikke en opgørelse over faktiske kundefakturaer. Den oprindelige Excel-fil og produktion er ikke kontrolleret her.

Eksisterende arbejde, der skal genbruges

• ALSO-import og ordrekladder findes allerede med line_key=also:<id>, kilde-id og importrelationer.
• Periodebeskrivelse med linjeskift findes allerede. _format_charge_period viser i dag kildens slutdato direkte; eksklusiv slutdato skal håndteres afgrænset for dokumenterede kildeformater.
• Migrationerne 192/193 omhandler ALSO-grundlag og godkendelse; 245 eksportkvittering; 246 ordreopdatering/status; 247 ALSO-reference og periode; 248 periodelinjeskift. Filernes tilstedeværelse beviser ikke, at de er anvendt i produktion. Genbrug skema, og tilføj kun dokumenterede mangler.
• Ordre-routeren anvender både eksisterende eksportbeskyttelse og, når aktiveret, app/workflows/export_guard.py. Denne kræver ved afstemning den præcise Hub-reference i references.other. Referencen må ikke blot fjernes uden en kompatibel løsning på genfinding og dubletkontrol.
• economic_documents.py har snapshots og afstemning, men det er ikke dokumentation for, at alle krav i denne plan allerede opfyldes. Undersøg hele den aktive eksportvej før ændring.
• ALSO_EFFECTIVE_COST_SQL kan bruge produktets aktuelle leverandørpris gange antal og reserveværdien nul. Det dokumenterer ikke korrekt periodeindkøb; manglende kildeindkøb skal fremgå som ukendt, indtil reglerne er afklaret.
• economic_write_policy.py tillader oprettelse af ordrekladder og særskilt godkendte opdateringer. Planen udvider ikke tilladelser til at oprette, bogføre eller sende fakturaer. Fakturakontrol skal være læsende.
• Arbejdstræet var rent før dette dokumentationsarbejde. Ingen testkørsel eller databaseforbindelse indgår i kodegennemgangen.

Åbne beslutninger før implementering

Disse punkter er ikke stiltiende godkendt. Afklar dem med brugeren, og dokumentér svar før den berørte funktion implementeres:

1. Om både Excel, CSV og eventuelle andre ALSO-importveje skal omfattes.
2. Hvilket kildefelt der er endeligt salgsbeløb, og om kundeaftaler/tillæg/manuelle rettelser fortsat kan ændre beløbet før godkendelse.
3. Om manglende dokumenteret indkøb skal blokere eksport eller alene vise ukendt fortjeneste. Aktuel produktpris må ikke antages at være historisk periodeindkøb.
4. Momsregler og valutaer; DKK og 25 % eksklusiv moms er endnu ikke bekræftet som universelle regler.
5. Om referenceforbuddet også omfatter dokumenthoved/referencefelter, og hvordan en intern eksportidentitet bevares uden synlig reference på PDF.
6. Om eksisterende fakturagebyr må tilføjes. Et godkendt gebyr skal indgå i afstemningen som forventet linje; det må ikke fejlagtigt tælles som en uventet abonnementslinje.
7. Hvor ordre-til-faktura-konvertering foretages i dag. Udgangspunktet er eksisterende arbejdsgang og ingen nye fakturaskrivninger fra Hub.
8. Om eksisterende ikke-eksporterede ALSO-kladder skal kunne omdannes via preview og ny godkendelse, eller kun nye importer omfattes. Ingen automatisk omskrivning foreslås.
9. Regler for gyldige nullinjer og negative reguleringer. Eksportvalideringen afviser i dag negativ enhedspris; denne plan autoriserer ikke en generel lempelse.
10. Startdato og kundekreds for historisk, læsende kontrol.
11. Tilgængelighed af separat e-conomic-testaftale, relevant layout og den oprindelige Norva24-fil. Eksempeltallene nedenfor stammer fra det indsendte oplæg og er ikke genvalideret mod Excel-filen.

Arbejdspakker og beslutningsporte

A. Fastlæg kildefelter og beløbsregler med råfil og anonymiserede fixtures. Dokumentér en feltmapping og afklar ovenstående forretningsregler.

B. Spor alle aktive eksportveje, snapshots, prisvalidering, gebyrer, referencefelter, genforsøg og statusmodeller. Afklar via officiel e-conomic-dokumentation og testmiljø, hvordan linjetekst, læsning, konverteringsrelationer og PDF virker. API-adfærd er endnu ikke verificeret.

C. Udarbejd konkret ændringsdesign: afgrænset ALSO-normalisering til antal 1 og godkendt periodebeløb, bevaret faktisk antal i metadata/tekst, godkendt snapshot og uafhængig kontrolstatus. Den normale eksportstatus må ikke uden videre udvides med værdier, som ældre klienter ikke forstår. Kontrolgrundlaget skal omfatte hele det godkendte dokument, inklusive eventuelle tilladte gebyrer.

D. Implementér først efter særskilt implementeringsbesked. Gennemfør fokuserede regressionstests for begge eksportveje, prisvalidering, snapshots, genfinding uden synlig reference og eksisterende ALSO-kladder. En pris på hele perioden må ikke fejlfortolkes som ændret månedspris af eksisterende priskontrol.

E. Gennemfør den samlede test og visuelle fakturakontrol beskrevet nedenfor. Manglende eksternt testmiljø skal rapporteres som en manglende acceptkontrol.

F. Fremlæg resultat, opt-in-aktivering og tilbageførsel til særskilt produktionsgodkendelse. Historisk kontrol er en separat læsende arbejdspakke; eventuelle rettelser kræver særskilt beslutning.

Resten af dokumentet bevarer brugerens detaljerede krav. Hvor et krav afhænger af et åbent punkt ovenfor, skal afklaringen ske før implementering.

1. Mål og aftalt løsning

Ret BMC Hubs eksport af periodeopdelte abonnementer, så kundens beløb i e-conomic svarer præcist til de godkendte salgsbeløb i Hub.

På hver økonomisk varelinje bruges antal 1 og periodens samlede salgsbeløb som enhedspris. Under varelinjen vises tekst med det faktiske antal licenser, månedspris pr. licens, periode og antal fakturerede dage. Den forklarende tekst skal stå umiddelbart under den tilhørende varelinje på kundens faktura.

Ingen bestillingsreference, sagsreference eller teksten Reference: sag-xx11 skal med i dette fakturalayout. Bevar eksisterende interne relationer og sporbarhed i Hub.

Hub skal beregne og vise indkøbsbeløb, salgsbeløb og fortjeneste internt. Indkøbspriser, fortjeneste og avanceprocenter må ikke sendes til e-conomic eller indgå i kundens fakturatekst.

Hub skal læse de oprettede dokumenter tilbage fra e-conomic og afstemme dem mod det godkendte grundlag. En eksportkvittering alene er ikke en bestået kontrol.

2. Afgrænsning og kompatibilitet

• Genbrug eksisterende ALSO-import, ordrekladder, eksport, dokumentrelationer og skabeloner.
• Begræns ændringen til de relevante importerede abonnementslinjer. Bevar adfærd for andre varelinjer og integrationer.
• Bevar eksisterende API-kontrakter. Eventuelle nye felter og statusværdier skal være additive og kompatible med eksisterende klienter.
• Hold test og produktion adskilt. Brug ingen rigtige kundedokumenter til test.
• Ingen automatisk bogføring, afsendelse, sletning eller ændring af historiske fakturaer.
• Denne plan autoriserer ikke implementering eller produktionsændringer.

3. Før programmering: undersøg den aktuelle løsning

AI-programmøren skal først:

1. Læse gældende AGENTS.md og undersøge eksisterende lokale ændringer.
2. Finde den nuværende import af antal, enhedspriser, periodebeløb og indkøbsbeløb.
3. Spore hele forløbet fra import til godkendt Hub-kladde, e-conomic-ordre og eventuel fakturakladde.
4. Undersøge eksisterende databasetabeller og migrationshistorik, før nye felter foreslås.
5. Kontrollere den aktuelle e-conomic API og eksisterende klient: linjetekst med linjeskift, tekstlinjer, afrunding, dokumentlæsning, moms og konvertering fra ordre til fakturakladde.
6. Afklare præcis hvilke dokumenttrin integrationen allerede udfører. Bevar eksisterende sikkerhedsregler og godkendelser.
7. Dokumentere, hvad der allerede virker, og hvad der mangler, inden ændringen gennemføres.

Mulige undersøgelsessteder fra tidligere arbejde, som skal verificeres i den aktuelle kode: app/modules/also/backend/service.py, ordre-modulets eksportfunktioner samt economic_export.py og economic_documents.py.

4. Datagrundlag og beregninger

Bevar følgende oplysninger separat pr. kildelinje:

Oplysning	Anvendelse
Kunde og produkt	Match og fakturabeskrivelse
Kilde-id, import-id og abonnements-id	Sporbarhed og beskyttelse mod dubletter
Faktisk licensantal	Forklarende kundetekst og intern kontrol
Salgspris pr. licens pr. måned	Forklarende kundetekst
Indkøbspris pr. licens pr. måned	Intern beregningskontrol
Periodestart og eksklusiv periodeslut	Periodeberegning
Fakturerede dage og beregningsgrundlag	Forklaring og kontrol
Godkendt salgsbeløb for perioden	Autoritativt beløb ved eksport
Godkendt indkøbsbeløb for perioden	Intern fortjeneste
Valuta og momsbehandling	Afstemning og fakturering

Brug decimalberegning til penge. Afrund efter dokumenteret leverandør- og e-conomic-praksis. Bevar rå kildeoplysninger og det godkendte eksportgrundlag, så senere prisændringer ikke ændrer historiske kontroller.

For august-eksemplet kan beløbet kontrolleres som:

antal licenser × månedspris × fakturerede dage / 31

Dette er en valideret regel for den undersøgte fil, ikke en universel regel for alle abonnementer. Brug kildens dokumenterede periodiseringsregel for andre måneder og produkter. Ved manglende eller modstridende grundlag kræves afklaring før eksport; ingen tavs nulstilling eller automatisk overskrivning af kildebeløbet.

Periodens godkendte salgsbeløb er eksportens beløb. En afvigelse mellem kildebeløb og kontrolberegning skal vises og afklares før godkendelse.

5. Fakturalayout og eksport

For hver godkendt kildelinje:

• Opret én økonomisk varelinje med antal 1, enhedspris lig periodens salgsbeløb og ingen perioderabat.
• Vis produktnavnet på varelinjen.
• Vis faktisk antal, månedspris, periode og dage under varelinjen.
• Brug helst den eksisterende linjebeskrivelse med linjeskift, hvis den vises korrekt i e-conomic og på PDF. Brug ellers en tilknyttet tekstlinje, hvis API og eksisterende integration understøtter det.
• Forklarende tekst må ikke oprette et ekstra beløb eller løsne sig fra sin varelinje.
• Medtag ingen sags- eller bestillingsreference i kundeteksten.
• Bevar periodeopdelte linjer. Sammenlægning er ikke en del af denne ændring.

Kildens slutdato er eksklusiv. 01.08.2026–29.08.2026 skal derfor vises som 01.08.–28.08.2026. Bevar det oprindelige interval internt, og håndter også månedsskift, årsskift og skudår korrekt.

Eksempel: Norva24, august 2026

Alle beløb i DKK. Momsbehandling skal bekræftes særskilt.

Varelinje	Antal på varelinjen	Enhedspris	Linjebeløb
Microsoft 365 F3	1	7.028,25	7.028,25
Microsoft 365 F3	1	753,03	753,03
Microsoft Defender Suite Add-on FLW	1	6.543,55	6.543,55
Microsoft Defender Suite Add-on FLW	1	701,09	701,09
Exchange Online – Plan 1	1	17,10	17,10
Microsoft 365 Business Basic	1	19,46	19,46
Sum af salgsbeløb			15.062,48

Tekst direkte under de seks varelinjer, i samme rækkefølge:

1. 116 licenser á 67,08 kr./måned. Periode: 01.08.–28.08.2026, 28 af 31 dage.
2. 116 licenser á 67,08 kr./måned. Periode: 29.08.–31.08.2026, 3 af 31 dage.
3. 108 licenser á 67,08 kr./måned. Periode: 01.08.–28.08.2026, 28 af 31 dage.
4. 108 licenser á 67,08 kr./måned. Periode: 29.08.–31.08.2026, 3 af 31 dage.
5. 1 licens á 27,90 kr./måned. Periode: 13.08.–31.08.2026, 19 af 31 dage.
6. 1 licens á 50,28 kr./måned. Periode: 20.08.–31.08.2026, 12 af 31 dage.

Hvis priserne er eksklusive moms, og 25 % moms gælder, bliver moms 3.765,62 kr. og total 18.828,10 kr. Filen dokumenterer ikke selv momsbehandlingen.

6. Fortjeneste: kun i Hub

Beregn pr. linje, dokument og kunde for den relevante periode:

• Fortjeneste i kroner = godkendt salgsbeløb minus godkendt indkøbsbeløb.
• Dækningsgrad = fortjeneste / salgsbeløb × 100. Ved nul i salgsbeløb vises procenten som ikke beregnelig.
• Hvis avance i procent også vises, skal den navngives særskilt: fortjeneste / indkøbsbeløb × 100. Bland ikke de to procenter sammen.
• Brug samme valuta og sammenlignelige beløb uden moms. Manglende indkøbspris må ikke blive til en falsk fortjeneste.
• Betegn beløbet som fortjeneste før øvrige omkostninger.

Norva24-eksemplet skal i Hub vise:

Post	Beløb
Indkøbsbeløb	13.095,14 kr.
Salgsbeløb	15.062,48 kr.
Fortjeneste før øvrige omkostninger	1.967,34 kr.

Genbrug eksisterende økonomifelter og adgangsrettigheder. Tilføj kun manglende felter efter skemagennemgang. Fortjeneste og indkøb må hverken findes i eksportdata, fritekst, noter eller kundevendte bilag til e-conomic.

7. Kontrol efter oprettelse i e-conomic

Gem et godkendt eksportgrundlag med linjer, beløb, valuta, moms og en versionsidentifikation. Knyt det til de konkrete eksterne dokument-id'er.

Efter oprettelse skal Hub hente dokumentet direkte fra e-conomic og kontrollere:

1. Rigtig kunde, valuta og dokumenttype.
2. Alle forventede økonomiske linjer findes præcis én gang. Ingen uventede ekstra linjer.
3. Antal er 1, enhedspris svarer til periodebeløbet, og rabat er som forventet.
4. Hvert linjebeløb matcher det godkendte beløb i valutaens mindste enhed.
5. Produkt, faktisk licensantal, månedspris, periode og dage fremgår korrekt og er knyttet til den rigtige linje.
6. Ingen reference, indkøbspris eller fortjeneste er sendt med i de berørte linjer.
7. Sum før moms matcher Hub. Moms og total matcher dokumentets godkendte momsbehandling og afrundingsregler.

Afstem linjer gennem gemte relationer til eksterne linje-id'er, hvor muligt. Stol ikke alene på rækkefølge, produktnavn eller oprindeligt fakturalinjenummer. Håndter tekstlinjer særskilt fra økonomiske linjer.

Hvis første eksport opretter en ordre, skal både ordren og den senere fakturakladde kontrolleres. En kontrolleret ordre beviser ikke, at den konverterede faktura er korrekt.

Ved manglende adgang til fakturakladden vises Fakturakladde ikke kontrolleret. Vis aldrig en faktura som korrekt alene på baggrund af en ordrekontrol.

Kontrollen gælder dokumentets aktuelle version. Efter kendte redigeringer, ny konvertering eller før en videre handling gennem Hub skal kontrollen gentages. Gem kontroltidspunkt og hvilket dokumentindhold kontrollen omfattede. Undersøg eksisterende hændelser og muligheder for at opdage eksterne ændringer; en gammel kontrol må ikke fremstilles som en garanti for senere ændringer.

8. Status, afvigelser og genforsøg

Genbrug eksisterende statusmodel, og supplér kun efter behov med tydelige tilstande:

• Klar til overførsel.
• Overførsel i gang.
• Oprettet i e-conomic — kontrol afventer.
• Kontrol bestået, med dokumenttype og tidspunkt.
• Afvigelse fundet.
• Kontrol kunne ikke udføres.
• Dokument ændret — ny kontrol kræves.

Vis forventet værdi, faktisk værdi, difference og berørt linje ved fejl. Hub må ikke markere dokumentet som korrekt eller tillade en afhængig videre godkendelse ved afvigelser eller ukendt kontrolstatus.

En spærring i Hub forhindrer ikke i sig selv manuelle handlinger direkte i e-conomic. Gør dette tydeligt ved fejl; lov ikke en ekstern spærring, som integrationen ikke kan håndhæve.

Ved timeout eller usikkert oprettelsesresultat skal Hub først afklare, om dokumentet allerede findes. Ingen blind genoprettelse. Brug eksisterende dubletbeskyttelse og en stabil eksportidentitet, og gem eksternt dokument-id så tidligt som muligt. En teknisk kontrolfejl skal kunne genforsøges uden ny faktura eller ordre.

9. Test og acceptkriterier

Kør relevante eksisterende tests og tilføj fokuserede tests for:

• Norva24: seks økonomiske linjer, subtotal 15.062,48 kr., interne indkøb 13.095,14 kr. og fortjeneste 1.967,34 kr.
• Korrekt forklarende tekst under alle linjer uden sag-xx11 eller andre bestillingsreferencer.
• Ingen interne indkøbs- eller fortjenesteoplysninger i eksport eller kundebilag.
• Delmåned, hel måned, februar, skudår, månedsskift og årsskift.
• Gyldigt nul, manglende antal/priser, negativ regulering efter eksisterende regler og modstridende kildebeløb.
• Afrunding pr. linje og dokument; ingen generel tolerance, der skjuler en forskel på én øre.
• Forkert kunde, beløb, valuta, moms, tekst, ekstra linje, manglende linje og dublet i et tilbagesendt dokument.
• API-fejl, timeout efter oprettelse, gentagne klik og samtidige eksportforsøg uden dubletter.
• Konvertering fra ordre til fakturakladde og redigering efter en bestået kontrol.
• Eksisterende eksport af andre varetyper uden ændret adfærd.

Gennemfør desuden en samlet test i et adskilt testmiljø: import, godkendelse, eksport, genlæsning, kontrol og fakturavisning/PDF. Bekræft visuelt, at kundeteksten står umiddelbart under den rigtige varelinje, og at kroner, perioder og danske tegn vises korrekt.

Accept kræver både korrekte eksporterede værdier, bestået kontrol af det genlæste dokument og læsbar fakturavisning. En mocktest alene dokumenterer ikke e-conomics faktiske adfærd.

10. Implementeringsrækkefølge og tilbageførsel

1. Dokumentér nuværende adfærd og eksisterende arbejde. Opret isoleret gren/checkpoint.
2. Fastlæg og test eksportgrundlag, beløbsregler og intern fortjeneste.
3. Tilføj fakturalayout og afgrænset eksportændring bag en opt-in-indstilling.
4. Implementér genlæsning, afstemning, dokumentrelationer og sikker håndtering af genforsøg.
5. Start eventuelt med intern kontrol i observationstilstand, hvor kontrollens resultat registreres uden at fremstille eksporten som fuldt verificeret.
6. Gennemfør tests og visuelt eftersyn i testmiljøet.
7. Fremlæg konkret ændring, testresultater og produktionsplan til godkendelse før idriftsættelse.

Hvis databaseændringer er nødvendige, skal de være additive. Forklar ændringerne først, tag backup før migration og dokumentér tilbageførsel. Ingen sletning eller omskrivning af historiske økonomiposter.

Ved tilbageførsel deaktiveres den nye eksport for nye dokumenter. Bevar oprettede dokumentrelationer og kontrolhistorik. En tilbageførsel må ikke automatisk geneksportere eksisterende dokumenter eller genåbne fejlramte dokumenter til ukontrolleret behandling.

11. Eksisterende og historiske dokumenter

Planlæg en separat, læsende afstemning af allerede eksporterede relevante dokumenter efter kildegrundlag og e-conomic-data. Find manglende, dobbelte eller fejlberegnede linjer, og opgør forskelle pr. dokument og kunde.

Historiske ændringer kræver særskilt godkendelse. Ret ikke bogførte fakturaer ved at overskrive Hub-data. Eventuelle krediteringer eller nye fakturaer skal følge den eksisterende kontrollerede regnskabsproces. Opgør ikke faktisk over- eller underbetaling uden at afstemme fakturaer, korrektioner og betalinger.

12. Aflevering fra AI-programmøren

Aflever en kort dansk status med:

• Hvad der er implementeret, og hvilke dele der stadig er planlagt.
• Berørte komponenter og eventuelle additive migrationer.
• Testresultater og dokumentation fra e-conomic-test samt fakturavisning.
• Dokumenteret dubletbeskyttelse og kontrol ved fejl.
• Aktivering, tilbageførsel og kendte begrænsninger.
• Tydelig forskel på rettet lokalt, testet i testmiljø og lagt på produktion.

Kildegrundlag

Brugerens aftaler i denne samtale og den tidligere gennemgåede Invoice_Aggregation-6.xlsx, fanen Worksheet - 02.09.26 - 08.23.44, Norva24-rækkerne 6–11. Tallene er fra den tidligere filkontrol i samtalen. Den aktuelle kode, skemastruktur og e-conomic API er ikke gennemgået som del af denne planfil og skal verificeres under punkt 3.