Download kassen

CTpos Kasse 0.8.0

(Samme ændringer i CTpos Kasse til Android 1.7.0, også på Sunmi, og i iOS-kassen, der bruger samme kerne.)

Nyt: kasserne flytter selv til https://api.ctpos.online

• Serveren oplyser sin foretrukne adresse i hver synkronisering (pull-feltet apiUrl, sat med Server:PublicUrl / Server__PublicUrl, i deploy API_PUBLIC_URL). Tom = ingen flytning.
• Efter en vellykket synkronisering prøver kassen GET <ny adresse>/health (5 sekunder, uden token eller kasse-id). Svarer den 200, gemmes adressen som Server-URL (pc: Opsætning › Synkronisering; Android: ☰ › Opsætning), og alt bruger den fra nu af: synkronisering, opdateringer (/downloads/pc/, /downloads/android/latest.json), kort via serveren (relæet), S5 CLOUD, CTpos Payment-opslag, tidsbestilling, e-mail af kvitteringer og backoffice-genvejen. Kalenderens live-forbindelse skifter ved næste genstart; den gamle adresse virker imens.
• Svarer den nye adresse ikke, bliver kassen på den gamle og prøver igen højst én gang i timen (pr. adresse).
• Kun https://-adresser uden brugernavn, forespørgsel eller fragment accepteres; kassen flytter aldrig fra https tilbage til http. Adressen tages kun fra kassens egen, godkendte synkronisering med den server, den allerede taler med.
• En egen opdateringskilde (UpdateFeedUrl) på den gamle servers adresse (samme vært og port) flytter med; andre kilder røres ikke.
• Skiftet skrives i kassens log (error.log, uden fejlrapport): "Server-adresse skiftet fra … til …", og ses i kassens opsætning på administrationssitet (Kasser og opsætning, Server).
• Pc: Synkronisér nu under Opsætning gemmer kun en adresse, der er skrevet i feltet – en åben opsætningsside skriver ikke den gamle adresse tilbage efter en flytning.

Ændret: ny standardadresse

• Nye installationer: https://api.ctpos.online (før http://109.176.202.182:8080) på pc, Android og iOS, i administrationssitets SMS (parringskode, QR-kode og APK-link; SMS_GATEWAY_SERVER_URL, ellers API_PUBLIC_URL, ellers standarden), og i CTpos Payment og CTpos SMS (Settings.kt DEFAULT_SERVER; appene udgives for sig). CTpos Payment bruger den nye standard efter opdateringen, hvis Gem serveradresse aldrig er trykket; en CTpos SMS-telefon beholder adressen fra parringen.
• Den gamle adresse holdes åben i overgangen. Ren-tekst (cleartext) er stadig tilladt i CTpos Payment og CTpos SMS (network_security_config.xml), så enheder på den gamle adresse virker.

Rettet: Swagger på serveren

• GET /swagger/v1/swagger.json gav 500 ("Can't use schemaId "$HeartbeatRequest" …"), fordi Pos.Infrastructure.Terminals.HeartbeatRequest og Pos.Server.Endpoints.HeartbeatRequest havde samme korte navn. Schema-id'er er nu det fulde typenavn (SwaggerSchemaIds: indlejrede typer med ".", generiske som ListOfX, ugyldige tegn som "_"). En test starter serveren og kræver 200 fra swagger.json, så et nyt navnesammenfald ikke kan bryde den igen.

Drift (leverandøren)

• deploy/install.sh sætter API_PUBLIC_URL=https://api.<DOMAIN> i deploy/.env, når api.<DOMAIN> peger på serveren (ellers tom), som det allerede gør for BACKOFFICE_PUBLIC_URL og ADMIN_PUBLIC_URL.
• deploy/docker-compose.yml: serveren får Server__PublicUrl: ${API_PUBLIC_URL:-}; admin får SmsGateway__ServerUrl: ${SMS_GATEWAY_SERVER_URL:-${API_PUBLIC_URL:-}}.
• For ctpos.online: API_PUBLIC_URL=https://api.ctpos.online (sættes af install.sh, eller i hånden i deploy/.env og genstart).

Teknik

• Server: PullResponse.ApiUrl (Pos.Infrastructure/Sync/SyncContracts.cs), BackofficeUrlOptions.ApiPublicUrl, udfyldt i SyncPullService. Kasse: PullResponse.ApiUrl (Pos.Windows/Api/SyncDtos.cs), ServerAddressMove (Pos.Windows/Services/Sync/, delt med Pos.Client.Core), ISyncApiClient.IsHealthyAsync og kaldet i SyncService efter en vellykket runde.
• Pull-format: uændret (10). apiUrl sendes i hvert pull og gemmes ikke lokalt, så der skal ikke hentes alt igen.
• Tests: ServerApiUrlPullTests, SwaggerAndApiUrlWebTests (Pos.Tests), ServerAddressMoveTests (Pos.Windows.Tests), ServerAddressMoveTillTests (Pos.Client.Core.Tests).
• iOS: Info.plist har stadig ATS-undtagelsen NSAllowsArbitraryLoads til den gamle http-adresse; den fjernes sammen med TestFlight, når alle iOS-enheder er på https.

SAF-T

• Ingen påvirkning. Kun transport (hvilken adresse kassen taler med): ingen hændelseskoder, transaktionsfelter, Z/X-data eller eksport ændres, journalen og signaturkæden er urørt, og skiftet journaliseres ikke. Det er den samme server og database bag begge adresser.

Også

• Mindste version: hæv ikke mindste version for pc, Android eller iOS. Ældre kasser ignorerer apiUrl og bliver på den gamle adresse, som stadig virker; de flytter, når de opdateres. Hæv den først, når den gamle adresse skal lukkes.
• Sikkerhed: ingen hemmeligheder i koden eller konfigurationen. Adressen accepteres kun fra et godkendt pull (kassens token) over den nuværende forbindelse, kun som https, og kun når /health svarer 200 over https; sundhedstjekket sender intet token. Over den gamle http-forbindelse kunne en mellemmand i forvejen se trafikken; flytningen til https fjerner netop den risiko.

CTpos Kasse 0.7.9

(Samme ændringer i CTpos Kasse til Android 1.6.9, også på Sunmi.)

Ændret: hovedgrupper og grupper som knapper i flere rækker

• Hovedgrupper (fx "Frisør", "Produkter") er ikke længere helt runde "piller", men knapper med let afrundede hjørner som kassens øvrige knapper (samme hjørneradius som Betal, Parkér osv.).
• Grupper står ikke længere som faner på én linje, der skulle stryges til siden (fx blev "Refle…" skåret over uden tegn på, at der var flere). De er nu knapper, der fortsætter på næste linje, når der ikke er plads. Den valgte gruppe er farvet (kassens accentfarve), de andre er almindelige knapper. Grupper har ingen farve i varekataloget, så de er neutrale.
• Hovedgrupper og grupper fylder højst tre rækker hver; er der flere, ruller området lodret med en synlig rullebjælke, så varerne stadig kan ses på små skærme som Sunmi.
• Gælder Salg og Indlevering på pc og Android, og på pc'en også varevalget ved retur uden kvittering (samme katalogvisning).
• Knapperne er mindst 44 px høje.

Ændret: mere luft mellem knapperne

• Øverst i kurven er der nu 8 px mellem knapperne: Android Proforma, Retur, Medlem, Klippekort; pc Klippekort, Medlem, Ryd. Er kurven smal, rykker knapperne ned på en ny linje i stedet for at blive klemt. Knapperne er 44 px høje (pc: før 32 px).
• Samme afstand (8 px) mellem knapper ved siden af hinanden andre steder, hvor den var mindre: pc Kalender (1/2/3 dage), Kasseoptælling (Antal/Beløb), kundens journal (Ret, Historik, Se formular, Vis foto) og backofficevisningens genveje.
• Backoffice og administrationssitet: knapper i samme tabelcelle (handlinger i lister) får 8 px imellem, og knaprækken på Download (btn-row) har nu afstand og ombrydning (før stod knapperne klistret sammen).
• CTpos Payment (terminal-appen) og CTpos SMS: knapperne har let afrundede hjørner (8 dp) i stedet for Materials helt runde form, og knapper ved siden af tekst eller andre knapper har 8 dp afstand. Ingen ændring i, hvad appene gør.

Rettet: knapperne øverst i kurven på iPad

• På iPad (på tværs, to kolonner) viste kurven kun Proforma og Retur; Medlem og Klippekort lå uden for kurven til højre. Knapperne lægges nu ud af kassen selv (WrapRow): de står til højre for "Kurv" med 8 px imellem, rykker ned på en ny linje (8 px imellem rækkerne), når der ikke er plads, og bliver aldrig placeret uden for kurven – også når Medlem/Klippekort dukker op efter en synkronisering, eller vinduet skifter størrelse. Knapperne er 44 px høje.
• Samme kode på Android: på en Android-tablet står knapperne som før på én linje til højre; på en smal kurv (Sunmi) rykker de ned som før, nu med 8 px mellem rækkerne (før 4 px).

Ændret: platformene hedder Windows, Android og iOS på administrationssitet

• Versioner: feltet Kasse til iPad (mindste version) hedder nu Kasse til iOS (mindste version) (ved siden af Kasse til Windows (mindste version) og Kasse til Android (mindste version)), og hjælpeteksten taler om iOS-kassen. Listen Kasser viste allerede platformen som Windows, Android eller iOS.
• Fejlrapporter: komponenterne hedder Kasse Windows, Kasse Android og Kasse iOS (før Kasse PC og Kasse iPad) – i listen, filteret, detaljen, hændelsesloggen og alarm-SMS'en ("CTpos fejl: Kasse Windows K1 - …").
• Fjernsupport: hjælpeteksten under iOS (kommer senere) siger "iOS-kasse" i stedet for "iPad-kasse".
• Hændelsesloggen for Mindste version skriver "iOS …" i stedet for "iPad …".
• iOS-kassen (under udvikling) skriver "CTpos Kasse til iOS …-ios" under Status, i Opsætning og i hovedet på den delte fejllog (før "CTpos Kasse til iPad"); Android er uændret ("CTpos Kasse til Android …"). Engelske oversættelser er opdateret.
• Det, der gemmes, er uændret: komponentkoderne (pos-windows, pos-android, pos-ios), versionssuffikserne og platformsværdierne er de samme, så gamle fejlrapporter og kasser vises med de nye navne uden ændringer i databasen.

Sikkerhed: opdaterede pakker

• Alle Microsoft.*-pakker, der var låst til 9.0.9 (EF Core Sqlite, Extensions.Hosting/Http/Logging.Debug, SignalR-klienten, ProtectedData, System.IO.Ports), er hævet til 9.0.22 i Pos.Client.Core, Pos.Windows og Pos.Android (Pos.iOS får dem via Pos.Client.Core). Det lukker NU1903 for Microsoft.AspNetCore.SignalR.Common 9.0.9 (GHSA-334f-vvp4-7g6p) og SQLitePCLRaw.lib.e_sqlite3(.ios) 2.1.10 (CVE-2025-6965, GHSA-2m69-gcr7-jv3q) – EF Core Sqlite 9.0.22 bringer SQLitePCLRaw 2.1.13. Serverens pakker (9.0.*) hentede allerede 9.0.22.
• MailKit 4.18.0 → 4.18.2 (Pos.Infrastructure): bringer MimeKit 4.18.2 og System.Security.Cryptography.Pkcs 10.0.13 i stedet for 10.0.0 (GHSA-846f-f764-76mx, GHSA-2fmv-rv2c-59x7) på server, backoffice og admin.
• dotnet list package --vulnerable --include-transitive: ingen sårbare pakker i nogen projekt (PosSystem.sln, PosWindows.sln, Pos.Android og Pos.iOS). Tilbage som "forældet": xunit 2.9.2 (kun testprojekterne; skift til xunit.v3 er en større opgave).
• Docker-billederne (server, backoffice, admin; sdk:9.0/aspnet:9.0) bygger uændret. Ingen ændring i databasen eller i SchemaUpgrader.

Teknik

• Fælles design-tokens i Pos.Domain/Ui/UiTokens.cs (UiMetrics): RadiusPill = RadiusButton (8), ny ButtonSpacing (8), GroupMaxRows (3) og GroupAreaMaxHeight (156). Pc: ButtonGap/ButtonGapWrap i Themes/Pos.xaml og den nye stil GroupItem (erstatter TabItem). Android: Ui.GroupButton, Ui.Wrap (FlexLayout med ombrydning) og Ui.WrapArea. Web: CSS-variablen --btn-gap.
• Testene i Pos.Windows.Tests (DesignTokenTests/ThemeTests) tjekker, at pc-stilene følger de fælles værdier. Den nye SaleScreenLayoutTests lægger de rigtige stilarter ud i 380 px bredde og tjekker, at grupperne ombrydes (ingen uden for kanten), højst 3 rækker vises, knapperne er mindst 44 px høje, og at knapperne øverst i kurven har 8 px imellem.
• CTpos Payment og CTpos SMS kunne ikke bygges i agentens sandkasse (Gradle fik ikke lov at åbne sin lokale forbindelse); byg dem som normalt før udgivelse. Ændringen er kun shape/afstand på knapperne.
• Noter til en senere iOS-kasse: docs/plans/ios-ui-notes.md.

SAF-T

• Ingen påvirkning. Kun udseende (hjørner, afstand, ombrydning); intet ændres i salg, journal, hændelser, Z/X-data eller eksporten.
• Opfølgningen (pakker, platformsnavne, kurvens knapper på iPad) påvirker heller ikke SAF-T: ingen hændelseskoder, transaktionsfelter, Z/X-data eller eksport ændres, og journalen og signaturkæden er urørt. EF Core 9.0.22/SQLitePCLRaw 2.1.13 er patch-opdateringer; testene, der laver SAF-T-eksporten og validerer den mod Skats XSD, er grønne.

Også

• Mindste version: hæv ikke mindste version for pc eller Android – rent visuelt. Ingen ændring på serveren, i pull-formatet eller i databasen. Der findes ingen iOS-kasse.
• Opfølgningen kræver heller ingen ny mindste version (pc, Android eller iOS): pakkeopdateringerne og navnene ændrer ikke pull-formatet eller det, kasserne sender, og kurvens knapper er kun udseende.
• Sikkerhed (opfølgning): de sårbare pakker er opdateret (se ovenfor); ingen nye adresser, rettigheder eller data.
• Sikkerhed: ingen nye adresser, rettigheder eller data.

CTpos Kasse 0.7.8

(Samme ændringer i CTpos Kasse til Android 1.6.8, også på Sunmi.)

Ændret: kortslip følger kvitteringen

• De kortslip, kassen udskriver for terminalen (Print kortkvittering på kassens printer), følger nu valget under Opsætning › Kvitteringsudskrift i backoffice – før blev de altid udskrevet, også når kvitteringen ikke blev det.
• Altid: kvittering og kortslip udskrives som før (kundens kortslip på kvitteringen, butikkens kortslip for sig).
• Spørg: ét spørgsmål "Kvittering?" dækker begge. Ja, udskriv giver kvittering og kortslip, Nej (eller når spørgsmålet lukker af sig selv) giver ingen af dem.
• Kun på knap: ingen af dem udskrives efter salget. Knappen Kvittering udskriver den originale kvittering med kortslip, præcis som ved Altid; næste tryk er en kopi som før. Også efter en genstart af kassen og fra Kvitteringer / Udskriv kopi: kortslippet hentes fra de gemte kortdata.
• Undtagelse, der bevares: står der på terminalens kortslip, at kunden skal skrive under (underskrift i stedet for PIN), udskriver kassen butikkens kortslip med det samme, så kunden kan skrive under – også ved Nej og Kun på knap. Butikkens kortslip kommer så ikke igen med originalen. Ingen af terminalintegrationerne (S5, Verifone VIM, CTpos Payment) sender kortholderverifikationen som et felt, så kassen genkender det på kortslippets tekst ("Underskrift", "Signatur", "Signature", medmindre der står, at underskrift ikke er nødvendig).
• Afviste, annullerede og tilbageførte betalinger har aldrig udskrevet kortslip på kassen og gør det heller ikke nu (terminalens egen udskrift eller Hent sidste transaktion).
• Udskriver terminalen selv kortslip (fx Verifones betalingsprogram på CTpos Payment), styres det på terminalen – ikke af kassens valg. Med S5 udskriver terminalen ikke selv; kassen gør. For Verifone VIM afhænger det af terminalens opsætning.
• Backoffice-siden Kvitteringsudskrift og manualerne er opdateret (kortslip står ikke længere på listen over det, der altid udskrives).

Nyt: e-conomic under Regnskab (backoffice)

• Regnskab › Regnskabsprogram: e-conomic ved siden af Dinero og OFINDA. Gem, derefter Forbind e-conomic: brugeren logger ind i e-conomic og godkender adgangen (e-conomics grant-flow), og CTpos gemmer aftalens Agreement Grant Token krypteret i virksomhedens egen database. Test forbindelse viser firmanavn og aftalenummer. Afbryd forbindelse sletter adgangen i CTpos (e-conomic har ingen API-kald til at tilbagekalde; appen fjernes under apps i e-conomic). Kræver adgang til alle butikker og rettigheden Regnskab.
• Kassekladde: vælges fra e-conomics liste (standard: kladden med "Kassekladde" i navnet, ellers den første, der tager finansbilag).
• Hver Z-rapport → ét bilag i kassekladden med e-conomics bilagsnummer (vises ved Z-rapporten). Bilaget lægges som kladde og bogføres ikke af CTpos – revisor/ejer bogfører kassekladden i e-conomic; derefter viser CTpos Bogført. Bilaget dateres med Z-rapportens dato og lægges i det regnskabsår, der dækker datoen; mangler regnskabsåret eller er det lukket, sendes intet, og fejlen siger det.
• Moms: beløbene sendes inkl. moms med kontoens momskode (som en linje skrevet i kassekladden); e-conomic trækker momsen ud ved bogføringen. Betalinger, gæld og 0 %-linjer sendes uden momskode – momsen tælles aldrig to gange.
• Z-rapporten som PDF vedhæftes bilaget (salg, betalinger, kontanter og bilagets posteringer; ingen kundedata). Ved overførsel pr. dag vedhæftes bilagets posteringer som PDF.
• Afdelinger (dimensioner): hver butik kan få sin afdeling; den sættes på posteringer på driftskonti. Konti, der kræver afdeling i e-conomic, afvises uden afdeling. Aftaler uden dimensionsmodul virker uden afdelinger.
• Kontrollér konti under Kontoplan: alle konti i brug (kontoplanen, udgiftskonti, bogføringskonti på varer og grupper) slås op – findes, ikke spærret, ikke overskrift/sum, åben for posteringer, afdeling, momskode findes; advarsel ved en betalingskonto med momskode. Virker også for Dinero og OFINDA (findes kontoen). Før hver overførsel kontrolleres bilagets konti; ved fejl sendes intet.
• Én overførsel pr. Z-rapport: kontrolleres i overførselsloggen og i e-conomics kassekladde (et bilag, der allerede er oprettet, findes igen på sin markør i teksten og oprettes ikke igen; fejler en del af oprettelsen, slettes de oprettede linjer igen). En Z-rapport, der er overført til Dinero eller OFINDA, overføres ikke igen til e-conomic.
• Vent før overførsel (automatisk overførsel pr. Z-rapport): med det samme, 15 minutter, 1 time eller 4 timer.
• Fejl der bliver ved: vises øverst på Regnskab; virksomhedens e-mail får besked højst én gang i døgnet.
• Send faktura (kundekonto) understøttes ikke med e-conomic (beskeden siger det).

Nyt: udlægsbilag for pengeudtag (kasse og backoffice)

• Kassen (pc, Android, Sunmi): Kontant ind/ud › Pengeudtag (ud) har Bilag (udlæg): Tag foto (Android/Sunmi) / Vælg billede (pc, også en scanning), Udgiftskonto fra backoffices liste eller et kontonummer, og Uden moms. Valgfrit; virker uden internet (sendes senere).
• Backoffice: Regnskab › Udlægsbilag viser pengeudtag med bilag; Tilføj bilag, Ret og Nyt bilag (JPEG, PNG eller PDF, højst 3 MB), Vis bilag og Overfør. Kontoplan › Udgiftskonti til udlægsbilag (konto, navn, momskode).
• Bilaget overføres til e-conomic som sit eget bilag med billedet vedhæftet: udgiftskontoen (debet, momskoden) mod kontoen for Pengeudtag (kredit). Z-rapporten har allerede bogført pengeudtaget mod kassen, så Pengeudtag er mellemregning og går i 0 – intet bogføres to gange. Automatisk med Overfør automatisk, når billedet er modtaget.
• Billeder gemmes krypteret i virksomhedens database (lageret fra 0.7.6, ny type cash-receipt), kun med rettigheden Regnskab i backoffice, og slettes efter 7 år (5 år efter regnskabsårets udløb, bogføringsloven, med plads til et forlænget regnskabsår).

Nyt: e-conomic-appen (administrationssitet)

• Regnskab › e-conomic (kunders regnskab): App Secret Token, App Public Token og Partner-token (valgfri) (gemmes kun). Krypteret med SIGNING_MASTER_KEY, vises aldrig igen, skrives aldrig i loggen. Siden viser den Redirect URL, der skal stå på appen i e-conomic: <Backoffice:PublicUrl>/regnskab/economic/callback.

Teknik

• API: e-conomics OpenAPI (apis.e-conomic.com) – Journals (kassekladdens draft-entries), Accounts, AccountingYears, Dimensions (afdelinger på kladdelinjer), Documents (bilagsfil på bilaget) og BookedEntries (er bilaget bogført). To kald bruger det gamle REST-API (restapi.e-conomic.com), fordi OpenAPI ikke har dem: /self (aftale og firmanavn) og /vat-accounts (momskoder til Kontrollér konti). Klienten ligger bag IEconomicApi, så et senere skift er nemt.
• Kun de faste e-conomic-værter kaldes; tokens sendes som headere og logges aldrig. 429 ventes ud (Retry-After, højst 3 gange), netværksfejl og 5xx prøves igen automatisk med stigende pauser.

SAF-T

• Ingen nye koder og intet ændres i transaktionerne. Kortslip, der udskrives sammen med kvitteringen, er dækket af kvitteringens 13012 (13013 retur, 13017 træning) som før – også når Kvittering-knappen udskriver originalen senere.
• Spørg → Nej og Kun på knap: intet udskrives, intet registreres (ingen 13012 og ingen 13018).
• Kun kortslip til underskrift, der udskrives uden kvitteringen, registreres som 13018 "Andre rapporter eller kvitteringer" med teksten "Kortslip til underskrift udskrevet – kvitteringen er ikke udskrevet".
• Hændelser fra 0.7.7-kasser (13018 "Kortslip udskrevet – kvitteringen er ikke udskrevet") bliver stående uændret; signaturkæden er urørt.
• XSD-valideret testforløb i tests/Pos.Client.Core.Tests/Release078TillTests.cs: kortbetaling med Spørg → Nej (ingen udskrift, ingen hændelser), Spørg → Ja (kvittering med kortslip, 13012), Kun på knap → Kvittering (original med kortslip, 13012, derefter 13014), kortslip til underskrift (13018 alene, senere original 13012 uden butikkens slip igen) og original efter genstart (kortslip fra de gemte kortdata). Eksporten valideres mod Skats XSD.
• Bekræftes med revisor/Skattestyrelsen: at 13018 er rigtig for et kortslip til underskrift uden kvittering.
• Ingen ændring i salgsregistreringen. Overførslen til e-conomic læser kun journaliserede data (Z-rapporten og dens transaktioner) og ændrer intet.
• Pengeudtag journaliseres på kassen præcis som før: transaktion 11010 (Out Payment, LT-KASSE) og hændelse 13019 (Cash withdrawal). Udlægsbilaget er ekstra bogføringsdata (admin-ændringen cash.receipt og et foto) og kommer ikke i journalen eller SAF-T-filen. Ingen nye koder.
• XSD-valideret: Pos.Tests/EconomicTests (pengeudtag med bilag overført til e-conomic – eksporten har de samme transaktioner og hændelser og er gyldig) og Pos.Client.Core.Tests/CashReceiptTillTests (pengeudtag med foto og udgiftskonto på kassen, push, eksport med 11010 og 13019).

Også

• Mindste version: hæv ikke mindste version for pc eller Android. En 0.7.7-kasse udskriver stadig kortslip alene ved Nej/Kun på knap og registrerer dem korrekt som 13018 – det giver papir, men aldrig forkerte data. Ingen ændring på serveren, i pull-formatet eller i databasen. Der findes ingen iOS-kasse.
• Sikkerhed: ingen nye adresser, rettigheder eller data; kortslippets tekst læses kun lokalt for at finde en underskriftslinje. Kortdata gemmes og maskeres som før.
• Menuen i backoffice og administrationssitet: grupperne virker som en harmonika – kun én gruppe er åben ad gangen, og når du åbner en gruppe, lukker den, der var åben. Gruppen med den side, du står på, er åben. Administrationssitet har nu samme sammenfoldelige grupper som backoffice.
• Pull-formatet er uændret (listen over udgiftskonti hentes online, når Kontant ind/ud åbnes). Ingen ny mindsteversion: ældre kasser virker som før, men uden bilag ved pengeudtag.
• Ingen nye rettigheder: e-conomic og udlægsbilag i backoffice bruger Regnskab, bilag på kassen Kontant ind/ud.

CTpos Kasse 0.7.7

(Samme ændringer i CTpos Kasse til Android 1.6.7, også på Sunmi.)

Nyt: Skønhed som egen branche

• Branchen Skønhed findes nu ved siden af Frisør (der ikke længere hedder "Frisør/Skønhed"). Samme funktioner: tidsbestilling, medarbejdere, behandlinger, drikkepenge, klippekort, allergitest, helbredsoplysninger osv. Tidsbestilling er slået til fra start.
• En ny skønhedsvirksomhed med eksempelgrupper får behandlinger inden for negle (manicure, gelélak, pedicure), vipper og bryn (lash lift, vippeextensions nyt sæt og opfyldning, brow lamination, farvning), hudpleje (ansigtsbehandling, kemisk peeling), massage, voks og makeup på to briks, produkterne dagcreme, neglebåndsolie og vippeserum med lagerstyring og kostpris, og to eksempler på konsultationsformularer. Vippe- og brynbehandlinger kræver allergitest. En ny frisør får eksemplet "Konsultation før farve".
• Alle eksempler har 25 % moms. Almindelig massage og kosmetiske behandlinger er momspligtige; kun sundhedsbehandling (fx hos en autoriseret fysioterapeut) er momsfri – den skal i en gruppe med 0 % moms. Eksisterende virksomheder ændres ikke.

Nyt: Lager (alle brancher)

• Varer › Lager i backoffice (ny rettighed Lager (beholdning, varemodtagelse, regulering, optælling og lagerværdi), Leder får den én gang – trin permissions.stock): Lagerstyring, Genbestil ved og Kostpris pr. vare, Beholdning pr. butik med Lav beholdning, Varemodtagelse, Regulér med årsag (Svind, Beskadiget eller udløbet, Intern brug (back-bar), Andet), Optælling (start, optalt, bogfør/annullér), Bevægelser og Lagerværdi til kostpris.
• Salg trækker fra og retur lægger til, når salget når serveren – ud fra de journaliserede salg, én gang pr. kvitteringslinje (også ved gentaget push), ikke for træning, annullerede salg eller særlige linjer (klippekort, gavekort, onlinebetaling). Serverens bevægelsesliste er sandheden; beholdningen kan blive negativ. Et salg blokeres aldrig – heller ikke uden internet.
• Kassen henter beholdningen (nyt pull-afsnit stockLevels) og viser en besked, når en vare med lagerstyring er udsolgt eller har lav beholdning (slås fra under Lager › Indstillinger).

Nyt: konsultationsformularer med underskrift (frisør, skønhed – alle med tidsbestilling)

• Tidsbestilling › Formularer: spørgsmål (tekst, ja/nej, afkrydsningsliste, dato), samtykketekst, behandlinger, Gyldig i (måneder) og Kan udfyldes online før besøget. En rettelse giver en ny version; underskrevne formularer har deres egen kopi.
• Udfyldes på kassen med kundens underskrift (finger på Android/Sunmi, mus på pc) under Journal, formularer og fotos på tiden, eller af kunden før besøget fra siden for tiden (linket i bekræftelsen og Mine tider). Formular mangler står på tiden i kalenderen.
• Underskrevne formularer krypteres, får et SHA-256-kontroltal og ændres aldrig – Ny version erstatter. De behandles som helbredsoplysninger (rettighederne Helbredsoplysninger: se og skrive, alt logges i Helbredslog), slettes efter sidste besøg (Persondata (GDPR), standard 24 måneder) og er med i dataudtræk og anonymisering.

Nyt: før/efter-fotos med samtykke

• Tag foto (Android/Sunmi) / Vælg billede (pc) i journalen: Før/Efter, kundens samtykke (påkrævet) og et særskilt samtykke til markedsføring (fra som standard). Gemmes krypteret i virksomhedens database (samme lager som fotos fra 0.7.6, type customer-photo), aldrig på kassen og aldrig via de almindelige foto-adresser. Ses på kassen og under Kunder › Behandlingsjournal med de nye rettigheder Før/efter-fotos: tage og se / Før/efter-fotos: se, slette og ændre samtykke; hver visning logges. Slettes efter sidste besøg (standard 24 måneder), ved Slet foto og ved anonymisering.

Nyt: behandlingsjournal

• Kundens tider med behandlinger, medarbejder, farveformel, noter, formularer og fotos – på kassen og under Kunder. Noter kan rettes; alle udgaver gemmes (Historik). Nye rettigheder Behandlingsjournal: se og skrive noter (kassen – også nye Ekspedient-roller – og backoffice). Leder-roller får journal- og foto-rettighederne én gang (trin permissions.salon-journal).

Nyt: Kvitteringsudskrift (alle brancher)

• Opsætning › Kvitteringsudskrift (rettigheden Indstillinger; alle butikker med egen indstilling pr. butik): Altid (som før), Spørg ("Kvittering?" Ja, udskriv/Nej efter betalingen; Ja er standard (Enter); lukker efter 10 sekunder som Nej – kan ændres eller slås fra med 0) eller Kun på knap. I Spørg og Kun på knap står knappen Kvittering på salgsskærmen for det sidste salg: den originale kvittering første gang, derefter Kvittering (kopi). Udskriv kopi under Kasse og Kvitteringer giver også originalen, hvis den aldrig er udskrevet.
• Eksisterende virksomheder fortsætter med Altid. Nye virksomheder: Renseri, Service/Værksted og Andet = Altid; Café/Restaurant, Detail/Butik, Frisør og Skønhed = Spørg.
• Udskrives altid uanset valget: returneringer og udbetalinger (11013/11006, fx retur og erstatning), indlevering og afhentning af ordrer (kvittering, afhentningsbon og mærker), salg med flere originaler (mærker), gavekort-, klippekort- og anonyme stempelkort-slip, de kortslip kassen selv udskriver for terminalen, X- og Z-rapporter og kasseoptællinger. Pengeskuffen åbner stadig ved kontant betaling.
• Regler (vores læsning – bekræftes med revisor/Skattestyrelsen): der er ingen generel pligt til at udlevere en kvittering til en privat kunde i Danmark; kunden kan forlange en (momsloven § 52 og momsbekendtgørelsen om (forenklet) faktura gælder salg til virksomheder og på forlangende). Det digitale salgsregistreringssystem skal kunne udstede kvitteringer, og alle udskrevne kvitteringer og kopier skal registreres (bogføringsloven § 15 og bekendtgørelsen om krav til digitale salgsregistreringssystemer) – det gør CTpos med hændelserne nedenfor.

SAF-T

• Lager, formularer, fotos og journal er ikke SAF-T-data: SAF-T Cash Register har ingen lagerdel, og intet journaliseret ændres. Lageret læser kun de modtagne salgslinjer (ItemId, Qty, TransType). XSD-valideret: Pos.Tests/Release077Tests (salg og retur af en lagerført vare, eksporten er uændret og gyldig) og Pos.Client.Core.Tests/Release077TillTests (salg på kassen, push, pull, eksport).
• Kvitteringsudskrift: en kvitteringshændelse journaliseres kun, når en kvittering faktisk udskrives. Altid/Spørg → Ja: 13012 (13013 retur, 13017 træning) ved salget som før. Spørg → Nej og Kun på knap: ingen hændelse. Kvittering-knappen senere: 13012 (originalen, med salgets transID) første gang, 13014 (kopi) derefter. Kortslip, der udskrives uden kvitteringen: 13018 "Andre rapporter eller kvitteringer" med teksten "Kortslip udskrevet – kvitteringen er ikke udskrevet". Ingen nye koder, intet ændres i transaktionerne. XSD-valideret testforløb (automatisk, afvist, udskrevet senere som original, kopi, kun på knap) i Pos.Client.Core.Tests/Release077TillTests.
• Bekræftes med revisor/Skattestyrelsen: at en original udskrevet senere skal have 13012 (ikke 13014), og at 13018 er rigtig for kortslip uden kvittering.

Også

• Pull-formatet er hævet til 10: kasserne henter alt én gang efter opdateringen, så stockLevels, indstillingerne stock.settings og receipt.print og rettighederne bo.stock, booking.journal, bo.booking.journal, booking.photos og bo.booking.photos kommer frem.
• Rækkefølge: opdatér serveren først. Ældre kasser virker uændret mod den nye server (de udskriver altid kvittering og har ingen journal); lageret tæller også deres salg.
• Mindste version: hæv ikke mindste version for pc eller Android. Ingen ældre kasse skader data: lageret beregnes på serveren ud fra alle kassers salg, og formularer, fotos og journal findes kun på nye kasser. Sæt den først, når en butik vil bruge Spørg/Kun på knap eller journalen på alle kasser. Der findes ingen iOS-kasse.
• Databasen udvides kun (SchemaUpgrader): server StockItems, StockLevels, StockMovements, StockCounts, StockCountLines, ConsultationFormTemplates, ConsultationForms, TreatmentNotes, TreatmentNoteRevisions og nye kolonner på Attachments (AppointmentId, Label, ConsentTextVersion, ConsentBy, MarketingConsent, MarketingConsentAt); kasserne StockLevels.
• Sikkerhed: den offentlige formular kræver tidens hemmelige link (eller den indloggede konto, der ejer tiden) og CSRF-token, er hastighedsbegrænset, kan ikke indlejres og viser alle salonens tekster HTML-kodet; underskriften er kun tal (tegnes som SVG-sti). Fotos af personer udleveres aldrig via de almindelige foto-adresser (/api/sync/attachments, /bo/attachments).

CTpos Kasse 0.7.6

(Samme ændringer i CTpos Kasse til Android 1.6.6, også på Sunmi.)

Nyt: postnummer → by og adresseforslag

• Indbygget postnummerliste (alle 1089 danske postnumre fra Klimadatastyrelsens officielle register, øjebliksbillede 16. september 2026, før DAWA lukkede): fire cifre i Postnr. udfylder By – også uden internet. En by, man selv har skrevet, bliver stående. Gadeniveau-postnumre i det indre København står med bynavnet (fx 1050 København K). Færøerne, Grønland og stormodtagere er ikke med.
• Gælder Lokal administration › Kunder på kassen (pc, Android, Sunmi), Kunder og Butikker og kasser i backoffice og virksomheder, butikker og Mine oplysninger i administrationssitet. Kunder har nu felterne Postnr. og By (ud over adressen).
• Adresseforslag (Adresse, fra 3 tegn): kasserne og browserne spørger serveren, som spørger Klimadatastyrelsens Adressevælger (afløseren for DAWA's autocomplete efter 1. oktober 2026). Vælg et forslag, så udfyldes adresse (med etage og dør), postnr. og by. Tokenet bliver på serveren; svar gemmes i 24 timer; grænse pr. kasse/bruger (standard 30 pr. minut og 1000 pr. dag) og en samlet grænse. Er søgningen ikke sat op, over grænsen eller nede, virker feltet som almindelig tekst med postnummerlisten.
• Administrationen › Beskeder › Adressesøgning: Slå adressesøgning til, Token, Tjenestens adresse, Søgesti, grænser, Gem og Test forbindelse. Adressevælgeren kræver et token: opret en gratis bruger på Dataforsyningen (dataforsyningen.dk › Log ind › Opret bruger) og et token under Mine tokens / Brugerstyring, og skriv det selv i feltet. Indtil da er adresseforslag slået fra (postnummerlisten virker altid).
• Bookingsiden spørger ikke om adresse og har derfor ingen adressesøgning (ingen åben proxy for bots).

Nyt: stand ved indlevering og fotos (renseri og andre brancher med ordrer)

• Indlevering: knappen Stand på hver linje – Plet, Skade, Hul, Manglende knap, Misfarvning, Slid, Mærke, Farve, Kunden accepterer risikoen og Bemærkning, og op til 4 fotos (Tag foto med kameraet på Android/Sunmi, Vælg billede fra en fil på pc'en – pc'en har ingen direkte webcam-optagelse).
• Standen står på indleveringskvitteringen og begge proformaer ("Stand ved indlevering:"), kort på mærket ("Plet, Hul, Risiko"), på Afhentning (Stand ved indlevering, Vis fotos), under Reklamationer og i backoffice under Ordrer og salg.
• Fotos sendes til serveren (også senere, hvis kassen er offline), gemmes krypteret i virksomhedens egen database, kan kun hentes af virksomhedens egne kasser og backoffice-brugere med adgang (ingen offentlig adresse) og slettes efter 180 dage (fotos på reklamationer efter 3 år). Lageret er generelt ("vedhæftninger" med samtykke-felt), så det senere kan bruges til før/efter-fotos.

Nyt: uafhentede ordrer

• Ordrer og salg › Uafhentede: ordrer, der ikke er hentet efter afhentningsdagen, med påmindelser, afhentningsfrist og overskredet; Send påmindelse nu, Markér bortskaffet / Fortryd bortskaffet.
• Indstillinger for uafhentede (virksomhed eller pr. butik): Påmind efter (dage), Anden påmindelse efter (dage), Afhentningsfrist / bortskaffelse efter (dage) og Send påmindelse på e-mail, når kunden ikke har mobilnummer. Alt er slået fra som standard. Fristen står på indleveringskvitteringen: "Afhentes senest … Uafhentede ting kan derefter bortskaffes."
• Påmindelser sendes én gang hver gennem SMS-udbakken og den SMS-afsender, leverandøren har sat op (udbyderneutralt; venter til åbningstiden som "ordre klar"), eller på e-mail. Intet journaliseres, og ordren ændres ikke.

Nyt: reklamationer

• Reklamationer på kassen (pc: topbjælken; Android: ☰ › Reklamationer) og i backoffice (Salg og kunder › Reklamationer): registrér en reklamation på en udleveret ordre (hele ordren eller en vare, Årsag, Bemærkning, fotos). Virker offline på kassen.
• Afgør på kassen: Gratis omgang (ny ordre med 100 % rabat "Reklamation", 0 kr-kvittering og nye mærker), Refusion (den almindelige Retur på den oprindelige kvittering), Erstatning (beløb udbetalt kontant eller på kort uden returnering) eller Afvis. Backoffice kan registrere, skrive noter, tilføje fotos, afvise og genåbne en afvist – men ikke flytte penge.
• Nye rettigheder Afgøre reklamationer (gratis omgang, refusion, erstatning) (kassen) og Reklamationer og uafhentede ordrer (backoffice). Leder-roller får dem én gang (vedligeholdelsestrin permissions.claims); at registrere kræver kun Afhentning.
• Ny konto Erstatninger (reklamationer) under Regnskab › Kontoplan (tom = salgskontoen som momsfrit beløb).
• GDPR: kundens navn og telefon fjernes fra reklamationerne, når kunden anonymiseres; postnr. og by er med i dataudtræk og anonymisering.

Rettet

• Forældede "kommer senere"-tekster: Tidsbestilling og online booking er frigivet, og betaling online findes (testtilstand) – teksterne under Funktioner, Indstillinger for tidsbestilling og i manualerne er rettet.

SAF-T

• Gratis omgang: et almindeligt salg 11001 af den nye ordres linjer til deres pris med 100 % linjerabat af den nye kategori reklamation → rabattypen DSC-REKLAMATION; beløb 0,00 kr, ingen betaling; kvittering 13012.
• Refusion: den almindelige retur 11013 (LT-RETUR, kvittering 13013) – intet journaliseret ændres.
• Erstatning: 11006 "Udbetaling til kunde ved returnering" med én linje af den nye linjetype LT-ERSTATNING, 0 % moms (en erstatning er ikke betaling for en levering), betalingen er den foruddefinerede kontant- (12001) eller kortkode med negativt beløb; kvittering 13013. Tæller under returer på kassens X/Z.
• Afvist, selve reklamationen, standen, fotos, påmindelser og "bortskaffet" journaliseres ikke. Standen og afhentningsfristen står kun i kvitteringsteksten (receiptText) på det nye indleveringssalg. Ingen nye hændelseskoder; intet journaliseret ændres.
• Nyt XSD-valideret testforløb: Pos.Client.Core.Tests/AftercareTillTests (indlevering med stand og foto, gratis omgang 11001 med DSC-REKLAMATION, erstatning 11006 med LT-ERSTATNING kontant, refusion 11013, afvist) og serverregler i Pos.Tests/AftercareServerTests.
• Bekræftes med revisor/Skattestyrelsen: at gratis omgang er rigtigt som et 0 kr-salg med 100 % rabat; at erstatning uden returnering er 11006 med 0 %-linje (uden for momsområdet) – er erstatningen i virkeligheden et afslag i prisen, skal det laves som Refusion/Retur.

Også

• Pull-formatet er hævet til 9: kasserne henter alt én gang efter opdateringen, så indstillingen orders.pickup, kundernes postalCode/ city og rettighederne pos.claims/bo.claims (som ældre kasser smed væk) kommer frem.
• Rækkefølge: opdatér serveren først. En 0.7.5-server afviser kundeændringer med postnr./by ("Ukendt felt") og reklamationer ("Ukendt ændringstype"), kender ikke fotos (de venter i kassens kø) og taber linjetypen for erstatning. Ældre kasser virker uændret mod den nye server: en stand, de ikke kender, slettes ikke, når de sender ordren igen.
• Mindste version: hæv ikke mindste version for pc eller Android for at få 0.7.6 / 1.6.6 ud – ingen ældre kasse skader data (serveren beholder standen og postnr./by). Ældre kasser kan bare ikke notere stand, vise den, printe fristen eller afgøre reklamationer. Sæt den først, når en butik vil kræve stand og reklamationer på alle kasser. Der findes ingen iOS-kasse.
• Databasen udvides kun (SchemaUpgrader): server Attachments, OrderClaims, OrderReminders, OrderLines.Condition, Customers.PostalCode/City, kontrol-databasen AddressLookupSettings; kasserne OrderLines.Condition, Customers.PostalCode/City.
• Androids manifest har fået android.media.action.IMAGE_CAPTURE under <queries> (kamera-appen til Tag foto); kamera-tilladelsen fandtes.

CTpos Kasse 0.7.5

(Samme ændringer i CTpos Kasse til Android 1.6.5, også på Sunmi.)

Nyt: gavekort

• Backoffice › Salg og kunder › Gavekort: Ny gavekort-type med Faste værdier (fx 200, 500, 1000) og/eller Valgfrit beløb (mindste og højeste), Udløber efter (måneder, tom = ingen udløbsdato) og moms: Enkeltformål – moms ved salget (normalt i Danmark) eller Flerformål – moms ved indløsning. Hver værdi bliver en vare i gruppen Gavekort (SKU GAVEKORT-1 …, Ingen rabat; valgfrit beløb = åben pris). Uden udløbsdato udløber kortet ikke i CTpos (forældelsesloven: normalt 3 år – står på siden).
• Kassen (pc, Android, Sunmi, alle brancher): sælg gavekortet som en vare; efter kvitteringen udskrives gavekortet med QR-kode, Code128, nummeret i grupper (G7Q2 H9XR 4M3P), saldo, udløb og "gælder for ihændehaveren". Et flerformålsgavekort sælges for sig.
• Betaling › Gavekort: scan eller skriv nummeret, evt. et beløb, Indløs (Saldo viser saldoen). Delvis brug; resten står på kvitteringen ("rest 300,00 kr"). Kvitteringer viser kun de sidste fire tegn af nummeret. Med internet holdes beløbet på serveren (højst 15 min), så to kasser ikke bruger de samme penge; uden internet bruges kassens kopi, og serveren markerer Overforbrug.
• Retur: varer betalt med gavekort – beløbet sættes tilbage på gavekortet først, resten betales tilbage ("card first"). Et ubrugt gavekort kan returneres; et brugt kan ikke.
• Solgte gavekort (søg, saldo, historik, Annullér kortet med årsag, Udskriv kort igen) og Skyldig værdi pr. type med udløbet ubrugt værdi (vises kun, bogføres ikke). Z/X viser Gavekort: Solgt og Brugt (indløst).
• Ny rettighed Gavekort (…) – Leder-roller får den én gang (vedligeholdelsestrin permissions.giftcards).
• Optankning af et eksisterende gavekort og salg af gavekort online kommer senere (se nedenfor).

Nyt: eksterne gavekort (fx LifePeaks), manuel tilstand

• Gavekort › Eksterne gavekort: Ny udbyder (navn, kode som LIFEPEAKS, Enkeltformål (minuslinje) med momssats eller Flerformål (12005)). Personalet indløser først kortet i udbyderens app/portal og registrerer så koden og beløbet under Betaling › Gavekort. Afstemning pr. udbyder og periode med Hent CSV. Én konto pr. udbyder under Regnskab › Kontoplan.
• LifePeaks udbetaler salget (minus provision) den 15.–20. i måneden efter uanset indløsning – en indløsning nedskriver gavekortgælden, den er ikke et tilgodehavende. API-integration med LifePeaks (claim/refund) kommer senere, når en pilotbutik og API-adgang er på plads.

Nyt: kundekonti på bookingsiden (frisør/skønhed)

• Tidsbestilling › Online booking › Kundekonti: Kundekonti på bookingsiden (log ind med adgangskode) og Kræv konto ved online booking – begge slået fra, også for nye butikker (hver oprettelse koster en SMS); eksisterende butikker virker som før.
• Bookingsiden: Log ind / Opret konto (navn, mobilnummer eller e-mail, adgangskode på mindst 10 tegn; kode på 6 cifre på SMS eller e-mail), Husk mig på denne enhed i 90 dage, Glemt adgangskode. Mine tider: se, flyt og aflys egne tider (samme frist som linket), gemte kort med Fjern kort, Skift adgangskode, Log ud, Slet min konto (kunden og tiderne bliver hos salonen).
• Sikkerhed: PBKDF2-SHA256 600.000 iterationer, liste over almindelige/lækkede adgangskoder (lokal, intet eksternt opslag), samme svar for kendte og ukendte logins (ingen enumeration), spærring efter 5 forkerte forsøg, koder hashet (10 min, 5 forsøg), session-cookie HttpOnly/Secure/SameSite=Lax med token kun gemt hashet og roteret dagligt, CSRF-felt på alle formularer, ALTCHA på oprettelse og glemt adgangskode, grænser pr. IP, pr. nummer/e-mail og pr. virksomhed på koder (SMS-pumpning).

Nyt: mindste version for Android

• Administrationen › Versioner: Kasse til Android (mindste version). Sendes i pull'et (update.minAndroidVersion). En Android-kasse under mindste version viser "Kassen skal opdateres til version …" øverst og søger straks efter opdateringen; salg stoppes ikke. Listen over kasser markerer Android-kasser under deres egen mindste version.

Ændret: 1000 kr-sedlen tælles ikke længere

• Kasseoptællingen starter ved 500 kr (1000-kronesedlen er ikke gyldig fra 31. maj 2025). Gamle optællinger med 1000 kr vises og regnes som før.

SAF-T

• Enkeltformålsgavekort: salget er 11001 med linjetypen LT-GAVEKORT og moms; indløsningen er varerne plus minuslinjen LT-GAVEKORT-INDLOEST med samme moms – ingen 12005, så omsætning og moms ikke tælles to gange (som klippekort). Retur: LT-GAVEKORT-RETUR (ubrugt kort) og LT-GAVEKORT-INDLOEST-RETUR (beløbet tilbage på kortet).
• Flerformålsgavekort: salget er ingen levering – 11005 (indbetaling) med linjen LT-GAVEKORT-FLERFORMAAL og 0 % moms (uden for salgsmoms og varegrupper; Z: reportPayIn "Salg af flerformålsgavekort (11005)"). Indløsningen er et almindeligt salg med moms betalt med den foruddefinerede betalingskode 12005 "Gift token" (paymentRefID = kortnummeret). Retur til kortet: negativ 12005; et ubrugt kort betalt tilbage: 11006 med LT-GAVEKORT-FLERFORMAAL-RETUR.
• Eksterne gavekort: enkeltformål = minuslinje LT-GAVEKORT-EKSTERN-INDLOEST (artikel DIVERSE); flerformål = 12005-<KODE> (foruddefineret 12005, som kortmærkerne).
• Ingen nye hændelseskoder; intet journaliseret ændres; annullering og udløb journaliseres ikke. Kundekonti og 1000 kr-ændringen påvirker ikke SAF-T. Mindste version påvirker ikke SAF-T.
• Nye XSD-validerede tests: Pos.Client.Core.Tests/GiftCardTillTests (enkeltformål: salg, delvis, fuld og offline indløsning, retur af varer, ubrugt og brugt kort; flerformål: indbetaling, 12005, retur til kortet, 11006; eksterne enkelt- og flerformål) og Pos.Tests/GiftCardServerTests.
• Bekræftes med revisor/Skattestyrelsen: minuslinje uden betalingskode for enkeltformål; 11005 med 0 %-linje for flerformål (Skats validator lægger 11005 i grand total); rabat-/bonuskort (momsgrundlag = betalt beløb); breakage og udløbet værdi; at et LifePeaks-kort er butikkens eget enkeltformålskort.

Også

• Pull-formatet er hævet til 8: kasserne henter alt én gang efter opdateringen, så gavekort og bevægelser, som andre kasser har solgt, indstillingerne giftcards.types/giftcards.providers og rettigheden bo.giftcards (som ældre kasser smed væk) kommer frem.
• Rækkefølge: opdatér serveren først. En 0.7.4-server afviser betalingskoden 12005 ("unknown paymentType") og kender ikke gavekortene. Ældre kasser virker uændret mod den nye server (de sælger ikke gavekort; ældre Android-kasser ignorerer minAndroidVersion).
• Mindste version: hæv ikke mindste version for at få 0.7.5 ud – ingen gammel kasse skader data. Sæt den først, når I vil kræve gavekort på alle kasser i en butik (en ældre kasse kan ikke indløse gavekort).
• Databasen udvides kun (SchemaUpgrader): server GiftCards, GiftCardEntries, GiftCardReservations, BookingAccounts, BookingAccountCodes, BookingAccountSessions, Appointments.BookingAccountId, ReleasePolicies.MinAndroidVersion; kasserne GiftCards, GiftCardEntries.

CTpos Kasse 0.7.4

(Samme ændringer i CTpos Kasse til Android 1.6.4, også på Sunmi.)

Nyt: drikkepenge (slået fra, indtil butikken slår det til)

• Backoffice › Kasse og kontanter › Drikkepenge og kortgebyr: Tag imod drikkepenge, Ved kassen og/eller På betalingsterminalen, Procentknapper (fx 5, 10, 15) og Fordeling (Efter behandlinger eller Til ekspedienten). Gælder alle butikker eller en butik med egen indstilling. Alle brancher: café/restaurant, butik, renseri og frisør/skønhed.
• Kassen: på betalingsskærmen 5 %, 10 %, 15 %, Beløb og Fjern drikkepenge; Fordeling skifter mellem Efter behandlinger / Efter linjer, Ekspedienten (…), Ligeligt og Kun …. Virker med alle betalingsformer. Kvitteringen viser Drikkepenge (pr. medarbejder, når de er flere) og Betalt i alt; X/Z viser Drikkepenge (ikke salg) pr. medarbejder.
• Terminalen: Drikkepenge på terminalen under Betalingsterminaler virker nu (var "kommer senere"). Kassen beder terminalen om drikkepenge, og beløbet kommer tilbage med betalingen: CTpos Payment på Verifone (PSDK gratuityAmount; selve spørgsmålet er en del af terminalprofilen hos Verifone/indløseren) og på PAX/S5, og S5 direkte (Carte-opsætning; feltnavnene i svaret bekræftes med S5). Kræver den næste CTpos Payment (1.8) for CTpos Payment-terminaler. Den direkte Verifone-forbindelse (VIM) har ingen drikkepenge – der tastes de på kassen. En terminal, der ikke kan, stopper aldrig betalingen.
• Drikkepenge er ikke omsætning: de er ikke i salget, momsen eller grand total, men i betalingen.

Nyt: kortgebyr fra terminalen

• Terminalen må lægge kortgebyr på (slået fra som standard, med advarsel: betalingsloven forbyder gebyr på danske/EU-forbrugerkort). Et gebyr, terminalen lægger på, bliver salgslinjen Kortgebyr (varen oprettes automatisk i gruppen Gebyrer, SKU KORTGEBYR), med samme moms som varerne (25 % ved blandede satser – revisoren bør bekræfte). Er gebyret der, selv om det ikke er slået til, registreres det alligevel (pengene er trukket) og skrives i fejlloggen.

Nyt: afrunding af kontant pr. butik

• Kassebeholdning › Afrund kontant i kroner: Fra (ingen afrunding) (standard – eksisterende butikker er uændrede), Til nærmeste 50 øre eller Til nærmeste krone. Kun kontant i kroner, der betaler resten; aldrig kort, MobilePay, kundekonto eller fremmed valuta. Konto for øreafrunding (valgfri) pr. butik; tom = virksomhedens Øreafrunding under Regnskab.
• Kasserne gemmer nu en butiks egen Kassebeholdning for sig (før vandt den senest ændrede af virksomhedens og butikkens).

Nyt: Medarbejderrapport og provision

• Rapporter og SAF-T › Medarbejderrapport: pr. medarbejder og periode/butik – salg og retur som ekspedient, rabat, udførte behandlinger og varer ekskl. moms (frisør: medarbejderen på linjen fra Til betaling), drikkepenge og provision. Provision: regler pr. medarbejder eller rolle (Behandlinger %, Varer %). Eksportér CSV (løn).
• Ny rettighed Medarbejderrapport – Leder-roller får den én gang (vedligeholdelsestrin permissions.reports.staff).

Nyt: flere medarbejdere på én tid

• Kassen (pc og Android): Ny tid › Flere behandlinger – hver behandling med sin medarbejder. Backoffice-kalenderen: Medarbejder til behandling 2. Ret tid og online booking (Første ledige) kunne det allerede.
• Til betaling gemmer nu frisøren på hver linje (journal og SAF-T), så Medarbejderrapport og fordelingen af drikkepenge følger det.

Nyt: kortkonti i Regnskab

• Regnskab › Kontoplan: Dankort (inkl. Visa/Dankort), American Express, Andre kort, MobilePay via terminal og Drikkepenge (skyldig til medarbejdere). Tomme kortkonti = Kort/MobilePay som før. Fordelingen bruger kortmærket på betalingen (terminal og Stripe; Stripe kun når Onlinebetalinger (Stripe) er tom). Kortbetalinger uden kortmærke nævnes ved bilaget (nogle terminaler melder MobilePay som et almindeligt kort).

SAF-T

• Drikkepenge: transAmntIn/transAmntEx og signaturen er uændret kun varelinjerne. Én cashtransaction/raise pr. medarbejder med raiseType 10001 (basistype 10, foruddefineret 10001 "Amount from gratuity/tip"), raiseAmnt og empID. Betalingen (paidAmnt) er inkl. drikkepenge; derfor er reportPayment/reportEmpPayment i Z/X inkl. drikkepenge, mens salg, moms og grand total er uden.
• Kortgebyr: en almindelig salgslinje med linjetypen LT-KORTGEBYR (basistype 05; LT-KORTGEBYR-RETUR ved retur), artikel KORTGEBYR, med moms og i salget.
• Afrunding: den eksisterende cashtransaction/rounding/roundingAmnt = betalinger − linjer − drikkepenge.
• Medarbejder på linjen: ctLine/empID (frisøren), transaktionens empID er stadig ekspedienten. Ældre kasser udelader det.
• En linje, hvis varenummer ikke er en artikel i filen, får nu den generiske artikel DIVERSE (så filen altid holder XSD-reglen ctlArtIDRef).
• Ingen nye hændelseskoder; intet journaliseret ændres. Kortfordelingen i Regnskab ændrer ikke betalingskoderne (12002/12003-<mærke>, 12011).
• Nye XSD-validerede tests: drikkepenge på kassen fordelt på to frisører + afrunding til 50 øre, drikkepenge og kortgebyr fra terminalen, alt slået fra som standard (Pos.Client.Core.Tests/TipsAndRoundingTillTests), og et pushet salg med drikkepenge, gebyrlinje, medarbejder på linjen og afrunding (Pos.Tests/PaymentExtrasTests).
• Bekræftes med revisor/Skattestyrelsen: drikkepenge som raise uden for transAmntIn, momsen af kortgebyr, at rounding er nok til kontantafrunding, og hvordan drikkepenge indberettes med lønnen.

Også

• Pull-formatet er hævet til 7: kasserne henter alt én gang efter opdateringen, så indstillingen payment.extras (som ældre kasser smed væk), butikkens egen cash.settings (gemmes nu for sig) og rettigheden bo.reports.staff kommer frem.
• Rækkefølge: opdatér serveren først. En 0.7.3-server tager imod salg fra en 0.7.4-kasse, men smider drikkepengene (tips) og medarbejderen på linjen (staffEmpId) væk, og betalingen ville så se ud som øreafrunding. Ældre kasser virker uændret mod den nye server. CTpos Payment 1.8 (drikkepenge/kortgebyr i paymentResult) kan komme før eller efter; ældre apps og kasser ignorerer felterne.
• Databasen udvides kun (SchemaUpgrader): tabellen TransactionTips og kolonnen TransactionLines.StaffEmpId – på serveren og på kasserne.
• Provisionsreglerne (staff.commission) bliver i backoffice og sendes ikke til kasserne.

CTpos Kasse 0.7.3

(Samme ændringer i CTpos Kasse til Android 1.6.3.)

Rettet: klippekort – et klip er værd kortets pris / antal klip

• Når et klip bruges, er minuslinjen "Klippekort – … (1 klip)" nu klippets værdi: kortets pris delt med antal klip, rundet til øre. Øreafrundingen kommer på det sidste klip, så alle klip på et kort tilsammen er præcis kortets pris (fx 100,00 kr for 3 klip: 33,33 + 33,33 + 33,34). Minuslinjen er højst varens pris og højst korttypens Højeste værdi pr. klip.
• Dyrere vare end klippet: resten står som rabat på varen ("Kaffekort 10 for 9: klippekortrabat"), så kunden stadig betaler 0 kr for den. Rabatten kræver ingen godkendelse og står i Z/X-rapporten under Rabatter som Klippekort.
• Billigere vare end klippet: minuslinjen er varens pris, ingen rabat. Resten af klippets værdi bliver på kortkontoen (breakage).
• Retur af en vare betalt med klip fører de samme beløb tilbage (minuslinjen og rabatten) som en ny retur, og klippet kommer tilbage på kortet. Retur › Find kvittering vælger nu klippekort-linjen med, før beløbet tjekkes, også når kun varen er valgt.
• Et kort, der lige er solgt på kassen og endnu ikke er nået frem til serveren, kan nu bruges med det samme på samme kasse (kassens egen kopi bestemmer, som uden internet).
• Backoffice: Skyldig værdi har den nye kolonne Breakage (rest af brugte klip). Ubrugt værdi regnes som de klip, der er tilbage, til deres værdi (det sidste med øreafrundingen).
• Bogføring: med kontoen Klippekort (forudbetalt) krediteres kortets pris ved salget og debiteres klippenes værdi ved brug. Et kort, der er brugt op ved normale priser, står derfor i præcis 0 på kontoen; varens salgskonto viser prisen minus klippekortrabatten. Billigere varer efterlader breakage på kontoen.

SAF-T

• Et klip er stadig varen (LT-SALG) plus minuslinjen LT-KLIPPEKORT-INDLOEST med samme moms, men minuslinjen er nu klippets forudbetalte værdi. Er varen dyrere, får varens linje resten som linjerabat med dscTp DSC-KLIPPEKORT (basistype 08, "Rabat af prisen – Klippekort"), bygget som DSC-LOYALTY: en systemkategori (klippekort, rabattype clipcard), som kun kassen sætter og aldrig tilbydes på faste rabatter eller kampagner. Varen giver stadig 0 kr og 0 kr moms; ingen betalingskode (hverken 12005 eller 12007).
• Returer er nye transaktioner (11013/13013) med de samme beløb som salget: LT-RETUR med samme DSC-KLIPPEKORT-rabat og LT-KLIPPEKORT-INDLOEST-RETUR.
• Journaliserede data røres ikke: salg fra 0.7.2 (minuslinjen = varens pris) står uændret; den nye regel gælder kun nye salg. Det gælder også klip brugt offline på en kasse, der endnu ikke er opdateret – de kommer med den gamle regel.
• Nye XSD-validerede tests: dyr vare (minuslinje = klippets værdi + DSC-KLIPPEKORT), billig vare (minuslinje = varens pris), et kort brugt helt op (kortkontoen summer til 0 inkl. øreafrunding) og retur af en vare betalt med klip (samme beløb tilbage).

Også

• Pull-formatet er uændret (6): kasserne henter ingen nye felter. Klippets forudbetalte værdi (prepaidOre) sendes fra kassen til serveren i "clipcard.use" og gemmes i den nye kolonne ClipCardUses.PrepaidOre, men sendes ikke tilbage til kasserne (de bruger kun antal klip). Rabattypen clipcard er en journalværdi, som kassen selv sætter.
• Kræver, at serveren opdateres først: en 0.7.2-server afviser feltet prepaidOre i "clipcard.use".
• Databasen udvides kun (kolonnen ClipCardUses.PrepaidOre, nullable) med SchemaUpgrader.
• Breakage og udløbet ubrugt værdi vises kun; der bogføres intet automatisk. Revisoren afgør, hvornår de føres til indtægt.

CTpos Kasse 0.7.2

(Samme ændringer i CTpos Kasse til Android 1.6.2.)

Nyt: klippekort

• Klippekort (backoffice: Salg og kunder › Klippekort): forudbetalte kort uden navn, fx "Kaffekort 10 for 9". En korttype har navn, Pris (kr inkl. moms), Antal klip, hvad kortet gælder til (grupper eller varer), valgfri Højeste værdi pr. klip og valgfrit udløb (standard: udløber ikke). Hver type får automatisk sin egen vare (KLIPPEKORT-1 …) i den nye gruppe Klippekort med Ingen rabat; varen giver aldrig loyalitetsstempler.
• Sælg et kort på kassen som en vare: hvert kort får et tilfældigt nummer (12 tegn, K + 10 tilfældige tegn + kontroltegn), og efter kvitteringen udskrives kortet med QR-kode, Code128-stregkode, nummer, "10 tilbage" og udløb (ESC/POS på pc'en og Sunmi).
• Brug et klip: scan kortet på Salg (scanner, kamera, Sunmi-knap) eller tryk Klippekort, skriv nummeret og Brug klip. Ét klip betaler ét stk af den dyreste vare i kurven, som kortet gælder til. Kvitteringen viser "Kaffekort 10 for 9: 7 tilbage" / "brugt op". Ryd eller ✕ giver klippet tilbage.
• Serveren bestemmer: med internet holder kassen klippet på serveren (højst 15 minutter, svar inden 5 sekunder), så to kasser ikke kan bruge det sidste klip. Uden internet bruger kassen sin egen kopi af kortene (alle kort og klip hentes til alle kasser), klippet sendes ved næste synkronisering, og serveren markerer Overforbrug, hvis kortet kom under 0. Salget blokeres eller ændres aldrig.
• Retur: en vare betalt med klip returneres sammen med klippekort-linjen (0 kr tilbage, klippet kommer tilbage på kortet). Et ubrugt kort kan returneres (kortets pris tilbage, kortet lukkes); et brugt kort afvises, før noget journaliseres.
• Backoffice: Solgte kort med søgning, klip tilbage, historik, Overforbrug, Annullér kortet (med årsag) og Udskriv kort igen, og Skyldig værdi pr. korttype (ubrugt forudbetalt værdi og udløbet ubrugt værdi – vises kun, bogføres ikke). Ny rettighed Klippekort (korttyper, solgte kort, annullering og skyldig værdi); Leder-roller får den én gang.
• Regnskab: ny konto Klippekort (forudbetalt) under Kontoplan til kortets salg og klippene.
• Z- og X-rapport: nyt afsnit Klippekort med solgte kort og brugte klip.

Nyt: stempelkort uden kunde

• På et loyalitetsprogram: Tillad anonyme stempelkort (uden kunde). Så står Nyt stempelkort under Medlem på kassen: et stempelkort uden navn og telefon kommer på salget med det samme (også uden internet), optjener fra dette køb og udskrives med kvitteringen (QR-kode og medlemsnummer). Det scannes som et medlemskort, og Indløs virker som før.
• Kortet er aldrig salgets kunde på kvitteringen, i journalen eller i SAF-T, og der gemmes ingen persondata eller samtykke.
• Knyt til kunde (backoffice, på kortet under Kunder): stemplerne flyttes til en kunde, der bliver medlem med samtykke, og kortet holder op med at virke.

SAF-T

• Et klippekort er et enkeltformålsvoucher med moms ved salget: salget er et almindeligt kontantsalg (11001) af kortets vare med linjetypen LT-KLIPPEKORT og varens moms (25 % som standard) og hændelsen 13012.
• Et klip: varen sælges som altid (LT-SALG) plus en minuslinje på kortets vare med samme moms, LT-KLIPPEKORT-INDLOEST (amntTp D), så klippet giver 0 kr i omsætning og moms. Ingen ny betalingskode: hverken 12005 (gavekort) eller 12007 (loyalitet), fordi en betaling mod en momsbelagt linje ville tælle omsætning og moms to gange; samme mønster som "Betalt online".
• Returer er altid nye transaktioner (11013/13013): LT-KLIPPEKORT-RETUR for et ubrugt kort, LT-KLIPPEKORT-INDLOEST-RETUR for en vare betalt med klip. Annullering og udløb journaliseres ikke (ingen beløb). Klippekortenes forbrug (ClipCardUses) er ikke journaldata og eksporteres ikke.
• Anonyme stempelkort: belønningen er stadig linjerabatten DSC-LOYALTY; kortet står ikke som kunde (custSupID).
• Nye tests kører SAF-T-eksporten for salg af et kort, et klip, det sidste klip, retur af et ubrugt kort, retur af en vare betalt med klip og klip brugt offline og synkroniseret senere, og for stempelkortet uden kunde, og validerer mod Skats XSD.

Også

• Kræver, at serveren også er opdateret. En ældre server svarer ikke på de nye kald; så bruger kassen sin egen kopi af kortet som uden internet.
• Pull-formatet er hævet til 6: nye sektioner clipCards og clipCardUses, indstillingen clipcards.types, feltet anonymousCard på kunder og rettigheden bo.clipcards, som ældre kasser ikke kendte. Kasserne henter derfor alt én gang fra version 0 efter opdateringen.
• Databasen udvides kun (nye tabeller ClipCards, ClipCardUses, ClipCardReservations og kolonnen Customers.AnonymousCard) med SchemaUpgrader – på serveren og på kasserne.
• Åbent (revisor): at kortet er et enkeltformålsvoucher, bogføringen af bonusklippet (fx det 10. i "10 for 9") og af udløbet ubrugt værdi.

CTpos Kasse 0.7.1

(Samme ændringer i CTpos Kasse til Android 1.6.1.)

Nyt: frisør og skønhed (fase 4b)

• Aflys sent i Kalender (pc, Android og backoffice): kunden aflyste efter fristen for gratis afbud. Et beløb betalt online beholdes, og et gebyr kan trækkes.
• Gem kort ved booking (backoffice: Online booking › Betaling, pr. butik eller behandling): Nej, Ja, altid eller Kun når der ikke betales forud, sammen med Udeblivelsesgebyr og Gebyr ved sen aflysning (beløb pr. booking eller procent af prisen). Kunden ser gebyrerne på bookingsiden og skal sætte flueben ved "Kortet gemmes hos Stripe og kan kun trækkes for udeblivelse eller sen aflysning efter salonens betingelser." Kortet gemmes på Stripes side med godkendelse i banken (uden betaling: Stripe Checkout i setup-tilstand; med depositum: kortet fra betalingen). CTpos gemmer kun Stripes reference, korttypen og de sidste 4 cifre. Kunden kan fjerne kortet på siden for sin tid (Fjern kort), salonen under Kunder › Gemte kort. Kun Stripes testtilstand; live-nøgler afvises stadig.
• Træk gebyr (kassen og backoffice): for en tid, der står som Udeblevet eller Aflyst sent, med et kort gemt ved bookingen. Beløbet bekræftes (højst gebyret minus det, der allerede er beholdt eller trukket for tiden), og serveren trækker det på kortet som en betaling uden kunden (off-session, med en idempotensnøgle, så et nyt forsøg aldrig trækker to gange). Afviser banken blødt eller kræver godkendelse, får kunden et betalingslink på SMS/e-mail (23 timer). Gebyret trækkes aldrig automatisk. Ny rettighed Træk gebyr for udeblivelse og sen aflysning i backoffice (på kassen fandtes den som pladsholder); Leder-roller får den én gang.
• Helbredsoplysninger (GDPR art. 9): allergi, hud/hovedbund, medicin, graviditet og en note pr. kunde – kun med kundens udtrykkelige, særskilte samtykke; tilbagetrækning sletter dem. Ses og skrives kun med den nye rettighed Helbredsoplysninger: se og skrive (Leder; Ekspedient kun hvis ejeren giver den). På kassen står ⚠ Se helbredsoplysninger: oplysningerne hentes fra serveren ved tryk, gemmes aldrig på kassen og kan ikke ses offline. Hver visning og ændring logges (hvem, hvornår, hvad, hvor) i den nye side Tidsbestilling › Helbredslog (rettigheden Helbredsoplysninger: se adgangsloggen). Valgfrit på bookingsiden (Spørg om helbredsoplysninger ved online booking). Slettes automatisk 24 måneder efter sidste besøg (kan ændres under Persondata (GDPR)), er med i dataudtrækket sammen med loggen og slettes ved anonymisering.

SAF-T

• Et udeblivelsesgebyr eller gebyr ved sen aflysning er et kontantsalg (11001) på webkassen K<butik>-WEB (serversigneret) med én linje på varen Udeblivelsesgebyr (UDEBLIVELSESGEBYR) eller Sen aflysning (SENAFLYSNING) i den inaktive gruppe Gebyrer, linjetypen LT-AFLYSNINGSGEBYR, varens moms (25 % som standard, til revisoren har svaret) og konto. Betalingen er kort (12002/12003 med korttypen) med Stripes PaymentIntent som paymentRefID, og hændelsen 13012 (kvitteringen til kunden). Det gælder også, når kunden betaler via betalingslinket.
• En refusion af gebyret er en ny returtransaktion (11013) med LT-AFLYSNINGSGEBYR-RETUR og 13013; salget ændres aldrig.
• Ingen dobbelt betaling: er der beholdt et depositum, en forudbetaling eller et reservationsgebyr for tiden (13999 som før), kan gebyret højst være reglen minus det beholdte. 13999 og gebyrets 11001 står ved siden af hinanden.
• Gebyret trækkes aldrig fra på kassen og kommer ikke på kassens journal eller Z-rapport. At gemme et kort flytter ingen penge og journaliserer intet. Helbredsoplysninger, gemte kort og rettighederne er ikke salgsdata.
• Nye tests kører SAF-T-eksporten for gebyrsalget, refusionen, gebyret efter et beholdt depositum og gebyret fra kassen og validerer den mod Skats XSD.

Også

• Kræver, at serveren også er opdateret. En ældre server svarer ikke på de nye kald; så siger kassen, at det ikke kan lade sig gøre lige nu.
• Pull-formatet er uændret (5): ingen nye felter på rækker, kasserne henter. Rollerne med de nye rettigheder stemples og hentes som almindelige ændringer; helbredsoplysninger og kort kommer aldrig med synkroniseringen, og gebyret står på tiden, som kassen henter fra kalenderens API.
• Databasen udvides kun (nye tabeller StoredPaymentMethods, HealthRecords, HealthRecordAccessLogs og nye kolonner på OnlinePayments) med SchemaUpgrader.
• Åbent: momsen på gebyrer for en behandling, der ikke blev leveret (revisor), og live-tilstand for onlinebetaling (plan §7.6).