Systemstatus

ETAPE 12 (sidste) — Model B: pakkeshop egen kurér-API som tilkøbsmodul: (1) Nyt modul "Egen kurér-API" i modulsystemet. Det er opt-in og vises KUN for en pakkeshop når vendor eksplicit aktiverer det under Moduler. (2) Når aktivt får pakkeshoppen en ny fane "🔑 Egen kurér-API" i deres indstillinger, hvor de kan indtaste deres egne API-credentials (shop-nr, API-nøgle, token) pr. kurér + vælge in/outbound. (3) Pr. kurér kan de vælge "Brug min egen API" — så bruges deres credentials i stedet for den centrale (Model A). Lader de det stå, bruges fortsat den centrale adgang. (4) Tre-lags sikkerhed: fanen er skjult uden modul, API-endpoints afviser uden modul (streng check uden bagudkompat-fallback), og override-logikken ignorerer egne credentials medmindre modulet er aktivt OG kunden har valgt det. (5) Pakkeshoppen kan kun indtaste credentials for kurerer de faktisk er tildelt. PackTrack-platformen er nu funktionelt komplet jf. kortlægningen — alle 12 etaper leveret.

ETAPE 11 — Flere label-størrelser med automatisk tekst-tilpasning: (1) Pakkeshoppen kan nu selv vælge mellem 7 label-størrelser i deres egen admin: 50x30 (rulle), 58x40, 62x50, 80x40, 80x50, 100x50 og 100x150 (fragtlabel). (2) Teksten tilpasses AUTOMATISK den valgte størrelse — hver størrelse har sine egne, afstemte skriftstørrelser så kønummer og kurér altid er store og læsbare uden at flyde ud over kanten. (3) Kønummeret fremhæver de sidste 4 cifre (det medarbejderen råber op): på små labels vises kun de sidste 4 stort; på større vises hele nummeret med de sidste 4 forstørret. (4) Kurér-mærket skaleres ligeledes pr. størrelse. (5) Live forhåndsvisning ("👁️ Forhåndsvis label") i pakkeshoppens admin viser labelen i ægte størrelse før valg. (6) Terminalen kan også skifte størrelse on-the-fly. Hardkodet 50x30 er nu erstattet af den valgte størrelse fra config — i tråd med nul-hardkodning.

ETAPE 10 — Bogføring (Dinero + Billy + e-conomic): (1) Ny adapter-arkitektur (src/accounting/) der understøtter ALLE TRE systemer fra start, så du kan vælge senere uden kodeændring. (2) Hver udbyder har sin korrekte auth-model: Dinero (OAuth2 via Visma Connect, client id/secret + org-id), Billy (access token + org-id), e-conomic (app-secret-token + agreement-grant-token). (3) Vendor admin → Bogføring: vælg aktivt system, konfigurér alle tre, "Test forbindelse"-knap pr. udbyder. Secrets gemmes krypteret og maskeres. (4) Automatisk overførsel: når slået til, sendes nye fakturaer automatisk til det valgte system. (5) Du kan skifte system når som helst. Faktura-felt-mapping (kontonumre, momskoder, kunde-referencer) finjusteres mod det valgte system ved go-live med rigtige credentials.

ETAPE 9 — Betalingsløsninger samlet: (1) Nyt samlet menupunkt Betalingsløsninger med undermenuer pr. udbyder: Stripe, Viva Wallet, MiiPay og SumUp. (2) Hver udbyder har aktiverings-checkbox + egne credential-felter. Secrets gemmes krypteret, maskeres og bevares ved tom indtastning. (3) Viva og MiiPay migreret fra Labels-fanen ind i den fælles struktur (bagudkompatibelt — gamle værdier læses stadig). (4) Aktiverede løsninger vises automatisk som betalingsvalg ved label-køb. (5) VivaWallet-integrationen læser nu fra den fælles betalingsstruktur. Stripe recurring-abonnement, SumUp OAuth-flow og webhook-signaturverifikation udbygges når I aktiverer den enkelte udbyder.

ETAPE 8 — Faktura + abonnement + automatisk fakturering: (1) Abonnement pr. pakkeshop: 1/3/6/12 måneder, sat i kunde-redigering. Prisen beregnes automatisk som sum af kundens aktive moduler × antal måneder. (2) Ny Subscription-klasse styrer perioder, næste fornyelsesdato og fornyelse. (3) cron.php: beskyttet endpoint (hemmelig nøgle, timing-safe) der ved planlagt kald fornyer forfaldne abonnementer → genererer + sender faktura automatisk, markerer udløbne trials som expired, og sætter forfaldne fakturaer til "overdue". Idempotent (én faktura pr. periode) og chunked (max pr. kørsel, så Simply-timeout ikke rammes). (4) Virker med BÅDE Simply indbygget cron OG cron-job.org — samme URL. (5) Vendor admin → Fakturering: cron-nøgle genereres/gemmes, færdig cron-URL vises til indsætning, og seneste kørsel vises.

UI: grå tekst i vendor admin gjort lysere og mere læsbar. Den dæmpede tekstfarve (--mu) var #64748b som var for mørk på den mørke baggrund — ændret til #94a3b8. Gælder al hjælpetekst, labels, hints og sekundær tekst (106+ steder). Gamle mørke værdier bumpes automatisk til den lysere ved indlæsning, så ændringen slår igennem selvom den gamle farve er gemt.

Etape 7 forbedret — to-lags TMS (Model A): (1) Central TMS-partneraftale: PackTrack-s egne partner-credentials pr. kurér (API-nøgle/secret/bruger/base-URL) indtastes ÉN gang i vendor admin → Kurérer & TMS og deles af alle pakkeshops. (2) Pr. pakkeshop tilføjes nu KUN deres shop-/pakkeshopnummer + in/outbound-aktivering (ikke API-nøgle længere) — meget mindre besværligt og sikrere (nøglen ligger ét sted). (3) carrierRegister fletter automatisk central API-nøgle + pakkeshoppens shop-nummer. (4) Override forberedt: en pakkeshop kan senere få egne credentials der vinder over de centrale (Model B). Model B — pakkeshop egen kurér-API som tilkøbsmodul — er noteret som Etape 12.

ETAPE 7 — Kurér-API (adapter-arkitektur): (1) Ny adapter-struktur (src/carriers/): CarrierAdapter-interface med trackParcel/registerInbound/registerOutbound/createLabel. GLS-adapter med ægte offentligt Track & Trace-opslag; generisk adapter for øvrige kurerer; factory der bygger den rette. (2) To driftstilstande pr. kurér pr. kunde: "Track & Trace-mode" (virker nu, read-only status-opslag) og "TMS-mode" (ægte in/outbound-registrering — aktiveres når TMS-aftale + credentials er på plads). (3) Vendor admin → Kurérer & TMS: TMS-knap pr. pakkeshop åbner credential-opsætning pr. kurér (shop-/kundenummer, API-nøgle, token, in/outbound-aktivering). Secrets gemmes krypteret og maskeres. (4) Inbound-hook på scan og outbound-hook på udlevering: registrerer automatisk hos kuréren når TMS er aktivt, ellers logges lokalt som "afventer TMS". Hver synkronisering logges pr. kunde. (5) Tenant-side Track & Trace: pakkeshoppen kan slå en kundes pakke op hos kuréren. Når dine TMS-aftaler kommer, sættes blot tms_supported på kuréren + credentials pr. kunde — så er både scan-ind og udlevering live uden kodeændring.

ETAPE 7 — Kurér-API (adapter-arkitektur): (1) CarrierAdapter-interface med fire operationer: trackParcel, registerInbound, registerOutbound, createLabel. Generisk adapter + factory der vælger rette adapter pr. kurér. (2) Track & Trace virker i dag: vendor sætter en Track-URL (med {code}) pr. kurér i kataloget; tenant kan slå pakker op. (3) In/outbound TMS-hooks indbygget i scan_in (inbound) og pickup (outbound). Indtil TMS-aftale: kører "afventer"-tilstand, logges lokalt i carrier_sync.json. Når TMS aktiveres pr. kunde, sendes ægte kald — uden kodeændring. (4) Vendor admin → Kurérer & TMS: shop-nummer/credentials pr. kurér pr. pakkeshop, med aktiverings-checkbox for TMS in/outbound. Secret krypteres (del af krypteret tenant-record), maskeres, bevares ved tom indtastning. (5) Når du får en TMS-aftale med fx GLS, tilføjes en GlsAdapter i factory uden at røre resten — interface er klar til både inbound (pakke ankommet) og outbound (udleveret).

Label-print justeret til 50x30 mm: terminalens label er nu formateret til 50x30 mm termo-rulleetiketter (1500/2000 stk ruller). Layout omdesignet og skaleret til den lille størrelse — kønummer størst, derefter kurér, modtager, tidspunkt, fuld stregkode og fod. (Konfigurerbare etiket-typer med valgfri bredde/længde i vendor admin er planlagt som Etape 11 — sidste etape — når label/rulle/printer-specifikationer er undersøgt.)