Alkohol och tobak i Draken

Verksamheten

Alkohol & Tobak beslutar om serveringstillstånd och tillstånd för försäljning av tobak, e-cigaretter och folköl — och utövar tillsyn över att villkoren fortsatt uppfylls.

Arbetet har tre delar. Tillståndsgivning — ansökningar kommer via e-tjänst, men ett stort antal ärenden är fortfarande blanketter eller direktkontakt med handläggare. Lämplighetsprövning — ekonomisk och personlig granskning där kommunen begär yttranden från Polisen, Skatteverket och Kronofogden, och där varje person med betydande inflytande i bolaget måste prövas. Löpande tillsyn — kontroll av att tillståndshavaren fortsatt uppfyller kraven.

Organisation

Under IAF, flyttar 2026 till kommande Samhällsförvaltningen

Målgrupp

Restauranger, krogar, butiker, folkölsförsäljare

Remissinstanser

Polismyndigheten, Skatteverket, Kronofogden, Räddningstjänsten, Miljökontoret, Syna

Tillsyn ovanför

Länsstyrelsen Västernorrland, Folkhälsomyndigheten

Dagens system

OpenE, Alk-T (alkohol), OL2 (tobak), Public 360 (diarium), syna.se

Systembilden

Fyra applikationer runt ett ärendelager. Ingen av dem integrerar mot någon annan — de skriver och läser i samma namespace.

Katla loggar in medborgare, inte medarbetare. IdP:n skickar inga roll- eller gruppclaims — bara ett personnummer, som växlas mot ett partyId redan vid inloggning. Det id:t är identiteten i varje efterföljande anrop. Förväxla den inte med web-app-katla-sm, som är färdtjänst och AD-skyddad.

Så hänger delarna ihop

Ärendetypen är navet. Den väljs som en label, och ur den följer vilket formulär sökanden fyller i, vilken process ärendet kör och vilka steg handläggaren går igenom.

Sex begrepp brukar blandas ihop: kategori, ärendetyp, ärendeuppgifter, status, fas och process. De bor på olika ställen och sätts av olika aktörer, men de hänger ihop i en kedja som börjar i labelträdet.

• Byggt finns i Draken, Katla eller på AoT-grenen
• På gren byggt i SupportManagement eller hos Avvikelse, inte i bruk för AoT
• Målbild i verksamhetens skiss, inte byggt
• Kvar känd lucka

Vägar in

Ett AoT-ärende kan börja på fem sätt. Två finns i dag, och de ger ärendet olika mycket från start.

Skillnaden märks längre fram. Ett ärende från Katla bär sitt ifyllda formulär, medan ett som registreras manuellt har en tom flik för Ärendeuppgifter. Ett åtgärdsärende har dessutom en koppling tillbaka till tillsynen det kom ur.

Två verksamheter, en kodbas

Avvikelse och Alkohol & Tobak bygger båda myndighetsprocess ovanpå samma SupportManagement och samma Draken, samtidigt. Överlappet sitter i utredning, beslut och faser.

Avvikelsehanteringen, IAF och VOF med lex Sarah och HSL-avvikelser, har kommit längre. Dess gren ska in i develop först, och AoT-grenen förs in ovanpå och anpassar sig. Utvecklarna har en regel som styr resten:

Vi kan inte blanda investigation på flera ställen.

Utvecklare i Draken-teamet, om utredning i errand.investigation och errand.jsonParameters

Var utredningen lagras

I dag lagrar Avvikelse sin utredning och sitt beslut som JSON-dokument i jsonParameters, bredvid den inkomna avvikelsen. AoT har ingen utredning ännu. SupportManagement bygger nu en gemensam handläggningsmodell där utredning, yttrande och beslut är egna resurser på ärendet, med verksamhetens detaljer som JSON inuti dem.

Sömmen i Draken

Avvikelse-grenen har redan byggt den struktur AoT ska in i. Utredningsfliken är en söm: delad kod frågar ett register efter en variant, och varje verksamhet är en egen modul bakom en egen flagga. En AoT-variant finns redan där, som platshållare.

• Inga importer mellan aot/ och avvikelse/. Ett kontraktstest bygger två varianter utan att röra avvikelsekoden och slutar kompilera om kontraktet får ett beroende.
• Utredningslogik grenar aldrig på applikation – inte på NEXT_PUBLIC_APPLICATION och inte på isAOT().
• Fliken väljs på flagga, inte på profilstatus. AoT har ingen utredningsprofil i BFF:en och skulle annars försvinna tyst.
• Ändras delad kod körs både vof- och aot-sviten. ”Skipped” betyder fel dev-server, inte godkänt.

Samma problem, två lösningar

När grenarna förs samman

En simulerad sammanslagning, utan att röra grenarna, ger en konflikt när Avvikelse går in i develop och 23 filer i konflikt när AoT läggs ovanpå. Grundorsaken är att Avvikelse redan har byggt AoT:s env-filer, skript och testprojekt på sitt eget sätt. De farligaste felen är ändå de som slås samman utan konflikt:

Hela konfliktlistan med lösning per fil, och checklistan i elva steg, finns i Draken-skillen under references/flera-namespace.md.

Vad som är uppsatt

Uppsättningen berör fyra lager. Tre av dem ligger utanför repot, och det är där de flesta blockeringarna har suttit.

Utöver det: utan en kategori får ärendet ingen klassificering, och då är supportErrandIsEmpty() sant för ärendets hela livstid. Det låser flikarna, avsluta-knappen och tilldelningen. Ett ärende som ser halvfärdigt ut i gränssnittet beror nästan alltid på det.

Sprint-API:et är tillfälligt

AoT går mot support-management-alkt-sprint/15.3 i stället för ordinarie supportmanagement. Det är ett eget API-namn i WSO2, inte bara en annan version, vilket krävde ett service-fält i Drakens APIS som skiljer uppslagsnyckeln från URL-segmentet.

Versionen i APIS är global, så alla elva drakar går mot sprint-klonen så länge det står kvar. Det är försvarbart bara för att branchen är en PoC som aldrig driftsätts. När sprint-instansens ändringar synkats in i ordinarie SupportManagement blir det en vanlig versionsbump och service-fältet utgår.

Hur ärendet klassificeras

Två träd i samma struktur: ett för vad ärendet är, ett för fria etiketter man sätter flera av. Båda ligger inlagda, och sedan DRAKEN-4895 läser Draken kategoriträdet rätt.

Klassificeringen bärs av labels — plattformsteamets besked är att det är den mekanismen som gäller nu, oavsett om verksamheten behöver två nivåer eller tre. Den äldre categories + types-strukturen lever kvar i drakar som ännu inte migrerat; nya drakar sätts upp med labels.

Underkategorierna finns av en enda anledning. Stadigvarande servering, tillfälligt tillstånd till allmänheten, tillfälligt till slutet sällskap, gårdsförsäljning och catering till slutna sällskap är fem separata e-tjänster i OpenE som alla landar i samma ärendetyp. Tredje nivån är det som skiljer dem åt när de väl kommit in.

Tillsyn blev en egen kategori, och etiketter vid sidan av. Alkohol- och tobakstillsyn låg först som ärendetyper under Alkohol respektive Tobak. Nu är kategoriseringen en enda INSPECTION med typerna INSPECTION och MEASURES, medan vad tillsynen gällde uttrycks med fria etiketter.

Det andra trädet: fria etiketter

Strukturen har två rotnoder, båda med classification: "ROOT". Den ena bär ärendekategoriseringen, den andra etiketter som sätts flera per ärende — ungefär som etiketter i Jira.

CATEGORYROOT

Kategori-rot — Alkohol, Tobak, Tillsyn, Dokumentation

TAGROOT

Etikett-rot — Inre tillsyn, Yttre tillsyn, Alkoholtillsyn, Tobakstillsyn. Bär classification: "TAG"

Det löser en fråga som stått öppen: inre kontra yttre tillsyn behövde varken bli en tredje nivå eller en egen ärendetyp. Ett tillsynsärende klassificeras som tillsyn och taggas sedan med vad det gällde och hur det gick till.

Vad tjänsten tillåter, och vad Draken klarar

Label-noden har inget fast nivåbegrepp. classification är en fri sträng med enda kravet att den inte är tom — ingen enum. Plattformsteamet: "man kan skapa hur många nivåer som helst med vilka classification-värden ni vill, utan kodändringar från vår sida."

classification

Fri sträng. Nodens nivå, i praktiken CATEGORY / TYPE / SUBTYPE

resourceName

Nodens eget namn, versaler och understreck

resourcePath

Read-only, sätts av tjänsten. Inte garanterat kedjan av namnen ovanför

attributes

Fri nyckel/värde. Bär bland annat funktionsbrevlådan

deprecated

Får inte väljas, men får finnas kvar

För AoT valdes samma lösning som avvikelsehanteringen använder: ärendekategoriseringen ligger under en rotnod, så att andra rotnoder kan bära labels för helt andra syften — statistik, taggning av myndigheter, inre kontra yttre tillsyn. Rotnoden är en markör som säger "allt under mig är ärendetyper". Trädet ovan ligger i AOT-namespacet under CATEGORYROOT.

Kedjan som låste varje inkommet ärende

Ett ärende bär två klassificeringar. Draken skriver båda när en handläggare klassificerar: labels med de valda noderna, och samtidigt classification med samma värden i den äldre tvåfältsmodellen. Det är bakåtkompatibilitet — men supportErrandIsEmpty() tittar bara på classification, aldrig på labels.

Katla skickar labels men ingen classification. Verkliga ärenden i AOT har classification: {}. Fem fel hakade i varandra, och tre av dem är lösta:

Kvar är beslutet om classification. Antingen sätter Katla den, eller så slutar Draken grunda låsningen på den. Det senare är rimligare på sikt, men rör delad kod och alla drakar. BFF-filtret ligger dessutom i den delade metadata-controllern och måste provas mot Avvikelses labelträd innan grenarna förs samman, se Två verksamheter, en kodbas.

Ansökningsdata

Serveringsyta, öppettider, egenkontrollprogram, uppgifter om varje person med betydande inflytande — inget av det har någon plats i den gemensamma ärendemodellen.

Lösningen är jsonParameters: fri JSON på ärendet, validerad mot ett registrerat JSON Schema. Katla skriver dem, Draken visar dem skrivskyddat under Ärendeuppgifter. Ett schema definierar formuläret i båda ändar, så en ny blankett kräver inget nytt gränssnitt.

Vem äger vad

Schemaregistret är delat mellan gatewayerna — samma instans bakom både den externa och den interna — så ett schema registrerat från endera sidan syns för båda.

Processen framåt

Myndighetsspårets processtruktur ska bäras över till SupportManagement. Sju steg, där Utkast tillkommer i och med registreringsgränssnittet.

Vad verksamhetens skiss lägger till

Projektledaren har tillsammans med administratörerna som ska arbeta i draken tagit fram en interaktiv skiss av hela handläggargränssnittet. Den bekräftar processen ovan — sex steg, utan Utkast, eftersom det steget hör hemma i Katla. Och den mappar faser till flikar: utredning, beslut och uppföljning är varsin flik som låses upp när ärendet når fasen. Det är ett argument för att realisera processen med tjänstens fasmodell snarare än som statusgrupper.

Skissen fyller också i de steg processdokumentet lämnade öppna. Beslut fattas enligt delegationsordning — handläggare, utskott, nämndsordförande eller nämnd. Verkställande ger ett beslutsbevis och skapar tillståndet som asset. Uppföljning är tillsyn av att villkoren fortsatt uppfylls. Överklagande är ett eget ärende.

Utfallen är inte längre en gissning

Att utfallen skiljer sig mellan ansökan och anmälan är nytt för Draken. Varje ärendetyp i skissen bär en axel — ansokan eller anmalan — och det är den som avgör vilka koder som erbjuds. Utredningens förslag är dessutom ett eget fält, satt innan beslutet fattas, inte en lösningskod.

Tre flöden som inte finns i Draken alls

• Tillsyn — protokoll ur fyra mallar (servering, folköl, tobak, nikotin), tillsynsbesök, och tre vägar ut: avsluta utan anmärkning, skapa åtgärdsärende, eller starta en tillsynsutredning som leder till eget beslut. Med egna avsnitt för medverkande myndigheter och för vilka tillstånd som ingår.
• Åtgärdsärende — uppföljning av krav efter tillsyn, skapat från tillsynsärendet. Förutsätter ärendekopplingar i båda riktningarna.
• Överklagan — omprövning enligt 38 § förvaltningslagen, rättidsprövning enligt 45 §, överlämnande till överinstans enligt 46 §, och verkställande.

Därtill förutsätter kundbilden uppslag Draken inte har: bolagsordning, styrelse och ägare, aktuella fullmakter, serveringsställen per bolag, ärenden i externa system och ärenden i andra drakar. Plus fakturering som egen sektion och PDF-export av ärendet.

Utredning och beslut får egna bärare. SupportManagement-grenen draken-4892 bygger investigations, statements och decisions som underresurser på ärendet, och alkt-sprint bygger processmotorn. Hur de används visas i de tre ärendena.

Dyrköpta lärdomar

Sju fel som kostade tid under uppsättningen. Gemensamt för de flesta: symptomet pekar på fel ställe.

Mönstret är värt att internalisera: när något ser trasigt ut i Draken ligger orsaken oftast i konfiguration utanför repot — namespace, metadata, WSO2-prenumerationer. Koden är sällan felet.

Öppna frågor

1. När landar handläggningsmodellen? investigations, statements och decisions finns på SupportManagement-grenen draken-4892, som bygger på main och inte på AoT:s sprintgren. Utredningen kan inte byggas förrän modellen finns på support-management-alkt-sprint.
2. Förslag till beslut kontra beslutsutfall. Modellens recommendation ska vara ett av namespacets beslutsutfall. Skissens förslag – Tillstyrker, Tillstyrker med villkor, Ingen erinran, Avstyrker – är en annan vokabulär.
3. Utfall per ärendetyp. Utfallen registreras per namespace, men en ansökan och en anmälan ska erbjuda olika uppsättningar. Något behöver avgöra vilka som visas för vilket ärende.
4. Vad Uppföljning betyder. För Avvikelse är det uppföljning av åtgärder bakom useMeasures. För AoT är det tillsyn av att tillståndets villkor följs. Samma flik, eller två?
5. Processnyckeln. Vilka labels i AOT-trädet ska bära processKey, och med vilken startmod? Ansökningar kan rimligen starta automatiskt, tillsyn och åtgärdsärende manuellt.
6. Faser i AOT-namespacet. Fasraden, fasgrinden för flikarna och Avvikelses fasknappar förutsätter att namespacet har faser med tillåtna statusar.
7. Var classification ska sättas. Antingen börjar Katla sätta den, eller så slutar Draken grunda låsningen av ärendet på den. Det senare är riktigare när draken kör på labels, men ändringen träffar alla drakar.
8. Ytan för fria etiketter. Etiketterna under TAGROOT behålls när ärendet sparas, men de går varken att sätta, visa eller filtrera på.
9. Var senaste tillsyn lagras. Kundbilden visar den per serveringsställe, men ingen bärare är bestämd.
10. Alk-T och OL2. Dagens handläggningssystem för alkohol respektive tobak – ersätts de, speglas de, eller samexisterar de med Draken?
11. Diarieföring i Public 360. Allt ska diarieföras oavsett delegationsordning. Ingen sådan integration finns i Draken.
12. Redigering av ansökningsdata. Ska handläggaren kunna rätta uppgifter under utredningen? API:et stödjer det, gränssnittet inte.
13. Ansökan som privatperson. Egen ärendetyp, eller samma process där partyId skiljer sökandena åt?

Sammanställt under uppsättningen av AoT-draken, augusti–september 2026. Bygger på verksamhetsdokumentationen för Objekt Ärendehantering, källkoden i web-app-draken, web-app-katla-aot, web-app-business-center och api-service-support-management med grenarna alkt-sprint, avvikelse-sprint och draken-4892, Avvikelse-grenen feature/utvecklingssprint-start, verksamhetens UI-skiss, samt verifiering direkt mot API:erna i testmiljön. Beskriver nuläget där inget annat anges; avsnitt märkta som målbild är under arbete och inte byggda. Fristående kopia av artefakten, version 6, 2026-09-15.