TL;DR
Två regler ligger under svensk fakturanumrering. Ett nummer delas aldrig ut två gånger, och i en fakturaserie hoppas det aldrig heller över. En utställd faktura går inte att ändra; rättelsen är ett andra dokument med omvänt tecken. Båda är lätta att formulera och lätta att bryta, och de fyra sätten program bryter dem på är alla rimliga beslut fattade av andra skäl.
Vad lagen faktiskt ber om
Bokföringslagen vill tre saker av en kundfaktura. Serien har inga luckor, så att avsaknaden av nummer 1043 är en fråga någon kan besvara. Dokumentet går att återskapa exakt som det skickades, i sju år. Och ett fel rättas med ett nytt dokument i stället för genom att ändra det gamla, eftersom det gamla redan har lästs av någon utanför företaget.
Allt nedan följer ur de tre meningarna.
Fel 1: att numrera utkastet
Den frestande lösningen är att skapa en fakturarad, ge den ett nummer och låta kontoret fylla i den. Det ser bra ut i ett databasschema och det spricker första gången någon påbörjar en faktura och lägger ner den.
Ett utkast är ingen faktura. Det har inget nummer, det kanske aldrig skickas, och det kan slängas utan konsekvenser. I samma ögonblick som ett utkast bär ett nummer lämnar en radering ett hål i serien, och ett år senare kan ingen säga om 1043 makulerades, tappades bort eller skickades till en kund och doldes.
Därför tas numret när fakturan ställs ut och vid inget annat tillfälle. Ett utkast som makuleras samma eftermiddag lämnar inget spår i serien, eftersom det aldrig tog något ur den.
Fel 2: en databassekvens
Den andra lösningen låter databasen dela ut numren: en sekvens, eller en autoökande kolumn. Det är rätt verktyg för en primärnyckel och fel verktyg för ett fakturanummer, av ett bestämt skäl.
En sekvens överlever en återrullning. Det är en egenskap — det är den som gör sekvensen snabb, eftersom den aldrig behöver vänta in någons transaktion. Det är också precis det man inte kan ha här. Hämta ett nummer ur en sekvens, misslyckas tre rader senare, rulla tillbaka transaktionen, och numret är borta för alltid. Ingenting bär det. Nästa faktura blir 1044 och 1043 existerade aldrig.
Räknaren är därför en rad i en tabell, som låses medan den läses och skrivs. Samtidiga anrop ställer sig i kö bakom låset i stället för att tävla; den som förlorar väntar några millisekunder och får nästa nummer i stället för ett fel. Och eftersom det är en rad och inte en sekvens ger en återrullning tillbaka numret till nästa anropare. Ingenting hoppas över och ingenting ställs ut två gånger.
Fel 3: att hämta numret utanför transaktionen
Den tredje lösningen hämtar numret, gör sedan det långsamma arbetet — renderar PDF:en, sparar den, skriver raden — och committar på slutet.
Om renderingen kastar ett fel har räknaren redan flyttat sig. Ingenting bär numret den flyttade sig förbi. Bokföringslagen ber om en förklaring till luckan och ingen kan ge den ett år senare.
Alltså hämtas numret inuti samma transaktion som använder det, tillsammans med renderingen och sparandet. Priset är verkligt och värt att nämna: serieraden är låst medan PDF:en renderas, så två personer som skickar olika fakturor under samma sekund köar bakom varandra i några hundra millisekunder. Det är rätt ordning. Att skicka är ingen het kodväg, och en obruten serie är ett lagkrav medan genomströmning här är en preferens.
Fel 4: den andra klicken
Någon trycker Skicka, webbläsaren får timeout, de trycker igen. Eller så gör ett återförsök om på en begäran vars svar aldrig sågs. Två anrop, en faktura, och om båda passerar kontrollen "är det här ett utkast?" tar de ett nummer var — ett dokument, två nummer, och det andra sitter i serien utan något som förklarar det.
Lösningen är att läsa fakturan igen under ett radlås i stället för att lita på det routen slog upp, och att göra kontrollen på nytt inuti låset. Förloraren väntar, läser sitt eget arbete och får tillbaka en rak konflikt med numret som redan ställdes ut: den här fakturan ställdes redan ut som A-1043 och kan inte skickas igen; rätta den med en kreditfaktura. Det är ett sanningsenligt svar i stället för en 500:a, och det är sanningsenligt just därför att kontrollen skedde under låset.
Vad "skickat är skickat" betyder i praktiken
Tillstånden en faktura kan befinna sig i är utskrivna i stället för underförstådda. Ett utkast kan bli skickat eller makulerat. En skickad faktura kan bli delbetald, betald, förfallen, krediterad eller avskriven. Det finns ingen väg från skickad tillbaka till utkast, och kommer aldrig att finnas.
Förfallen är medvetet inget tillstånd någon sätter. Det är vad skickad blir när ett datum passerar, och ett schemalagt jobb skriver ner det. Att behandla det som ett beslut skulle innebära att en faktura kunde göras förfallen för hand, vilket inte är något som händer.
Kreditfakturan tar en egen serie
En kreditfaktura är ett eget dokument med ett eget nummer, och numret kommer ur en egen räknare. Det är inte kosmetika. Båda räknarna börjar på 1, och fakturor är unika på kombinationen organisation, serie och nummer — så att lämna kreditfakturor i fakturaserien får kreditfaktura 1 att krocka med faktura 1, och kontorets första rättelse faller på en databasspärr. Spärren har rätt, och det den säger är att det här är två serier och inte en. Vår härleds ur originalets serie, så ett företag som håller en egen löpnummerserie per kontor behåller den.
En kreditfaktura bär heller ingen OCR-referens, med flit. De två serierna räknar oberoende av varandra, så kreditfaktura 1 och faktura 1 reduceras till samma siffror och därmed samma referens — och matchningen skulle hitta två dokument till en inbetalning utan något sätt att välja. OCR-nummer och bankgiro går igenom det.
Datumet är svenskt, inte UTC
Applikationen går i UTC. En faktura daterad ur UTC är daterad i går de två timmarna efter midnatt varje sommar. Den första i en månad lägger det dokumentet i föregående momsperiod — deklarerat i fel kvartal, och upptäckt av den som stämmer av deklarationen snarare än av någon på kontoret.
Därför tas fakturadatumet i Europe/Stockholm och förfallodatumet räknas från det. Betalningsvillkoren läses av fakturan i stället för av kunden igen, eftersom villkoren kopierades till utkastet när det skapades och en ny läsning av kundregistret tyst skulle flytta förfallodatumet på ett dokument vars villkor avtalades för veckor sedan.
PDF:en renderas en gång
En faktura ska gå att återskapa exakt som den skickades, i sju år. En mall som ändras nästa vår skulle annars skriva om förra höstens dokument, utan att någon version av dem finns kvar att jämföra med.
Alltså renderas PDF:en en gång, vid utställandet, sparas med en kontrollsumma och serveras därefter. Utkast får renderas hur ofta som helst, eftersom ett utkast är en förhandsvisning och vattenstämplas som en — utan stämpeln är ett utskrivet utkast som räcks över till en kund omöjligt att skilja från en faktura, och det bär inget nummer, så kunden betalar mot en referens som inte matchar någonting.