Uppdaterad dokumentation 20221020

[johantjader]

Mina ärenden har den 20 oktober 2022 uppdaterat lösningsdokumentationen för byggblocket. För att hålla arbetet transperent och göra det enklare att förstå vilka ändringar som gjorts kommer vi att löpande skapa inlägg här på Dataportalens community i samband med att dokumentationen uppdateras/förändras.

Om du som läser detta har några frågor så är du välkommen att skriva de i denna tråd.

Förändringar

ID	Vart	Beskrivning
2022-10-18-01	Tjänstebeskrivning	Lagt till möjlighet att fråga på ärende utöver kund efter önskemål från Bolagsverket.
2022-10-18-02	Tjänstebeskrivning	Ensat attributnamn kundhandelseRequest och kundhandelseResponse. Bytt bokstaven ä mot a i kundhändelse-attribut i svar.
2022-10-18-03	Tjänstebeskrivning	Attributet kundhandelsekategori ersatt med producentarendetKraverKundatgard och producentarendetKlart. Tidigare lösning med kundhandelsekategori har vållat en del osäkerhet hos producenter mot vilket värde man ska mappa en kundhändelsetyp mot. Eftersom det ursprungliga behovet är att det ska vara tydligt "vem som har bollen", eller snarare "behöver jag som kund agera" så bedöms det bli enklare och renare med dessa två booleans.
2022-10-18-04	Verksamhetsguide	Uppdaterat kap.2 "Att utforma en kundhändelse" och kap. 2 "Att skriva en kundhändelse" med anledning av att attributet kundhandelsekategori ersatts.
2022-10-18-05	Verksamhetsguide	Nytt avsnitt "Notifiering av kundhändelser" i kap. 2. Beskriver behovet av att avisera kundhändelser och kort om relationen kundhändelse - meddelande.
2022-10-26-06*	Tjänstebeskrivning	Lagt till information om vilken URL skall användas.

Eftersom ändringen innebär ett attrbut utgår (kundhandelsekategori) i den tekniska standarden så har vi valt att skapa en ny plats för tidigare versioner -> Mina ärenden - tidigare versioner.

Befintlig plats på dataportalen kommer istället alltid innehålla den aktuella versionen.

---

*Tillagd efter urspungligt inlägg postades

[jonass]

@johantjader Finns det tankar att föreslå en konvention för hur URI-strukturen för kundhändelser bör implementeras av konsumenter?

Snabbt exempel bara för att förtydliga frågan:
myndighet_x.se/arenden/{id}/handelser
myndighet_x.se/arenden/{id}/handelser/{handelse_id}/detaljer

Poängen är att försöka skapa en förutsägbarhet som möjliggör att en myndighet kan länka till en annan myndighet på ett robust sätt.

I ert exempel med "Pias Tacotruck" som ser händelsen "komplettering krävs" från Bolagsverket är frågan hur klienten räknar ut vilken URL som användaren ska trycka på för att kunna slutföra arbetsuppgiften. I de fall det går att definiera i kundhändelsen är det såklart väldigt bra. Min åsikt (opinionated) är att det inte alltid går att definiera på förhand exakt vad nästa steg är men användaren behöver säkert få tips om hur hen "kan ta sig vidare i processen" ändå.

[johantjader]

Hej @jonass

Bra fråga, delar upp svaret i två delar:

URL:er för kundhändelse-API:
Det finns absolut ett värde att ensa URL:en för de kundhändelse-API:er som tas fram. Dock blir det svårt att standardisera annat än sista delen av URL:em eftersom respektive producenter redan har etablerade lösningar för hur deras URL:er ska se ut. Vi tar dock med oss detta och lägger till i Mina ärendens tjänstebeskrivning att sista delen av URL:en ska heta "/kundhandelser". Vi slänger upp en ny version pronto som borde synas på dataportal inom kort.

Med "sista delen av URL:en" menar vi:
Skv.se/…/…./…./kundhandelser

Mönster för tvåvägskommunikation
Du lyfter även behovet för en användare att kunna agera på informationen den får till sig i en kundhändelse. Vi har för det behovet valt att prata om behovet av "mönster för tvåvägskommunikation". Vi tror att det kommer finnas behov av olika lösningar beroende på vad man som producent har att erbjuda kunden för lösningar samt i vilket sammanhang användaren tar del av en kundhändelse.

Exempel:
Scenario 1 - en användare (privatperson) tar del av en kundhändelse "du behöver komplettera ditt bygglovsärende" på Mina sidor hos en kommun. I denna kontext kanske behovet är att kunna hänvisa användaren till en e-tjänst där användaren kan komplettera med efterfrågat underlag.
Scenario 2 - en användare (företagare) tar del av en kundhändelse "du ska lämna in momsdeklaration senast 12 september" i användarens affärssystem. Skatteverket som producerat kundhändelsen skulle då kunna erbjuda möjligheten att lämna momsdeklaration direkt från affärssystemet via ett API istället för att hänvisa till t.ex. en e-tjänst.

D.v.s. lösningarna för att möta behovet kan variera beroende på situation och kontext varför det blir mer naturligt att prata om mönster för tvåvägskommunikation.

Vi har på inget sätt en färdig lösning utan har för avsikt att börja titta närmare på det här, helst tillsammans med de som först går ut och börjar ta utforska området (deltagare i Verksamt, Värmdö och potentiella konsumenter att SKV:s KH-API). Området adresseras kort i Verksamhetsguiden i sista avsnittet i kap 3 - "Länkar och mönster för tvåvägskommunikation"

[jonass]

@johantjader Tack för bra svar. Uppfriskande att ni har ett avsnitt om mönster!