Dato: 26. marts 2020 09:13
Forfatter: Jens Bruntt

Introduktion til afsenderoplysninger

I denne blog skriver jeg om hvordan man kan forsyne en Digital Post Meddelelse med god afsenderinformation i Næste generation Digital Posts MeddelelsesModel (MeMo).

Lige som med papir-breve så kan også Næste generation Digital Post forsynes med information om hvem man sender til og om hvem der er afsenderen.

Når jeg en sjælden gang modtager et papir-brev så er jeg interesseret i om det er til mig eller en anden i husholdningen, og så er jeg interesseret i hvem afsenderen er.

Det som afsenderen skriver på brevet - om sig selv - gør at jeg som modtager kan vælge at sortere hvor posten skal hen.

Men ikke mindst så er god information om afsenderen også det der gør at jeg kan svare tilbage igen på en god måde. Til rette modtager. Som afsender bør man være meget interesseret i at den man skriver til er i stand til at svare korrekt tilbage igen.

Og det gælder selvfølgelig også for Digital Post, hvor MeddelelsesModellen har masser af mulighed for at afsenderen fortælle om sig selv, og om hvor eventuelle svar ønskes sendt hen.

Blogserien

Bloggen her er den tredje i en serie af blogs jeg skriver om NgDP. Nederst på siden er der links til de andre blogs i serien.

Det jeg skriver er baseret på hvad jeg ved om MeMO den 26/5-2021. MeMO er offentligt tilgængelig i version 1.1. Jeg har en forventning om at der kun vil være ganske få ændringer i formatet frem mod den færdige version.

MeMo og afsenderoplysninger

Her ses den fulde MeMO-struktur - klik på figuren for høj opløsning:

I denne blog ser jeg på MessageHeader, og det er nu Sender jeg går længere ned i - hvilke faciliteter findes der til at jeg som afsender kan sige noget om mig selv?

Basal afsenderinformation

Når man skal sende Digital Post, så skal man angive senderID og idType.

idType vil for min målgrupper altid være "CVR". Hvis der her i stedet stod "CPR", så ville afsenderen være en borger. Så både myndigheder og virksomheder skal altså her angive "CVR".

senderID vil være afsenderens CVRnummer.

label skal udfyldes med afsenderorganisationens navn. Navnet skal hænge sammen med det CVRnummer der er brugt. Så det kunne for eksempel være "Horsens kommune"

Ovenstående er nok til at fortælle modtageren om hvem der er afsender. Det er minimums-oplysningerne. Men der findes så muligheder for at fortælle mere. Og det kan give værdi både for den der sendes til, men også for os som afsender.

AttentionData

Vi her ser på AttentionData når de er brugt i forhold til det at være afsender: Sender. AttentionData kan også bruges i forhold til modtageren, og det har jeg skrevet om i NgDP MeMO - adressering med AttentionData og ContactPoint.

AttentionData indeholder en lang række under-noder som man kan vælge at udfylde med oplysninger om os som afsender. Så vi skriver her flere linjer "på bagsiden af kuverten".

Hvad der giver mening afhænger af situationen. Nedenfor er mulighederne illustreret.

For alle dise under-elementer gælder at man skal tænke på dem i den kontekst at det handler om at fortælle modtageren noget om hvem afsenderen er. Det svarer til det der er på bagsiden af et papir-brev.

Ved at udfylde disse oplysninger gør man det muligt for modtageren at svare tilbage og inkludere de samme oplysninger i svaret - men blot knyttet op som AttentionData på Recipient; ved at give rige afsender-oplysninger kan du blive belønnet med at få rige modtager-oplysninger tilbage.

Og ved at udfylde disse oplysninger gør man det også muligt for modtageren at sortere den post vi sender korrekt, så den havner i det system, eller hos den person, der skal håndtere netop denne Digital Post Meddelelse.

GlobalLocationNumber er en ID på tretten tal efter en international standard. Den udpeger en fysisk lokation. Det kan for eksempel være en bygning. Den kan i MeMo følges af en tekst der nanvgiver lokationen, f.eks. "vaskeriet".

AttentionPerson kan angives med en personIId og en label. personID er ikke veldefineret/standardiseret; det kan være for eksempel brugernavn i et IT-system. label er personens navn, for eksempel "Nancy Ann Berggreen". Så det vil altså være afsenderens navn. Det er oplagt her at skrive navnet på den person der har trykke på send-knappen, hvis der altså er sådan en person (hvis Meddelelsen er sendt helt maskinelt er der nok ikke sådan en). Om borger.dk/virk.dk-Visningsklienterne vælger at vise denne information vides endnu ikke, men andre visningsklienter kan vælge at gøre det. Hvis man kan udfylde den vil jeg anbefale at gøre det.

ProductionUnit kan bestå af productionUnitNumber og productionUnitName. ProductionUnitNumber er det tanken skal indeholde P-nummer, et tal som er en ID på virksomheder/organisationers "produktionsenheder", hvis virksomheden har flere lokationer. P-nummer er en standardiseret størrelse. ProductionUnitName er en betegnelse for den enhed der har P-nummeret. Jeg vil mene at brug af ProductionUnit giver rigtigt god mening, specielt når en virksomhed sender Digital Post, da det giver modtageren mulighed for at svare tilbage igen til samme P-nummer. Hvis man er en myndighed der sender, så er det mere relevant at se på ContactPoint-faciliteterne, der er mere rige.

ContentResponsible giver mulighed for at sige noget mere præcist om hvem der er ansvarlig for Meddelelsen der er sendt. Tidligere har vi set at man som virksomhed eller Myndighed skal angive sit CVRnummer (senderID), men det kan være meget upræcist hvis der er tale om en stor organisation. Men her kan vi angive en contentResponsibleID som det ikke er defineret hvad er, så den ignorerer vi, og så kan vi angive label, som er en tekst, det kunne for eksempel være "Rigshospitalets vaskeri" eller "Andeby Taxa - Bogholderiet". Visningsklienterne på borger.dk og virk.dk forventes helt klart at ville vise den label der angives her.

GeneratingSystem kan bruges til at angive hvilket IT-system der har oprettet Meddelelsen. Der kan her bruges en generatingSystemID og en label. Det er ikke defineret hvordan de skal bruges, men ved at angive dem med værdier der er de samme altid, så giver man modtageren mulighed for at sortere posten til det rigtige sted. Så en label kunne for eksempel være "Rykkersystemet" eller "Synsindkaldelsessystemet", og generatingSystemID bør så være nogle unikke værdier som hænger sammen med disse (eksempelvis "RYKKERSYS", "SYSIND").

SORdata (Sundhedsvæsenets Organisationsregister) kan bestå af en kode og et navn. Kode er en unik talkombination, som identificerer et organisationsenhed i sundhedsvæsenet. Så det kunne være Blodbanken på Rigshospitalet. Navn er her navnet på enheden - "Blodbanken" for eksempel. Hvis afsenderorganisationen har en SOR-kode, så giver det rigtigt god mening at udfylde den. Det giver mulighed for at modtageren kan sortere godt, og det giver mulighed for at den kan blive udfyldt i svarets AttentionData når der svares på Meddelelsen.

Email er afsenders emailadresse. Består af emailAddress og relatedAgent. emailAddress er selvfølgelig en emailadresse - denne kan sagtens være en funktionspostkasse/fællespostkasse, og relatedAgent er et navn på den postkasse der skrives fra. Om Email vises i Visningsklienter på borger.dk/virk.dk vides endnu ikke. Men andre visningsklienter kan vælge at vise oplysningen.

SEnumber består af seNumber og companyName. seNumber - SE-nummer - er et tal som indentificerer en logisk delmængde af en virksomhed, hvis virksomheden har haft brug for moms-teknisk at dele forskellige aktiviteter. companyName er det tilhørende navn på SE-nummerenheden. På samme måde som med ProductionUnit (P-nummer), så kan det hjælpe virksomheds-modtagere med at fordele indgående Digital Post, og værdien kan blive sendt tilbage igen ved retursvar, hvis den svarende organisation vælger at sende den retur.

Telephone består af telephoneNumber og relatedAgent. telephoneNumber er selvfølgelig et telefonnummer, men formatet er ikke specificeret, så der er risiko for fejltolkning her. relatedAgent er det meningen skal indeholde navnet på den ansvarlige afsender. Bemærk, som med Email, at det jo ikke behøver at være en persons telefonnummer, det kan for eksempel være en afdeling. Om oplysningen vises i Visningsklienterne på borger.dk/virk.dk vides endnu ikke, men andre visningsklienter kan vælge at vise den.

EID består af eID og en label. eID er jeg sikker på, det er tanken skal være et nummer som kommer fra en medarbejdersignatur - NemID for virksomhedsansatte. label forestiller jeg mig vil være navnet på den person som eID-nummeret hører til. EID-numre er den velstrukturerede udgave af AttentionPerson, men til gengæld er der, tror jeg, ikke så mange ansatte der rent faktisk har medarbejdersignaturer. Man kan sagtens godt forestille sig modeller for hvordan modtageren kan være i besiddelse af RID-numre på personer de modtager post fra, men det at bruge RID-numre til addressering vil kræve at afsender og modtager er enige om at man bruger dem. Hvis man som afsender udfylder RID-numre giver man modtageren mulighed for at vælge at returnere de samme RIDData i svarets AttentionData, og det vil så kunne bruges til sortering af svaret.

Address består af en lang række felter til at skrive en struktureret adresse, svarende til det vi skriver på papir-breve. Vejnavn, husnummer og så videre. Under Address findes et underelement der hedder AddressPoint, som kan indeholde længde-, bredde- og højde-angivelse. Om Address vises i Visningsklienter på borger.dk/virk.dk vides endnu ikke. Men andre visningsklienter kan vælge at vise oplysningen.

UnstructuredAddress svarer til Address, men er et slags fritekstområde til adresseoplysninger, hvis afsenderen ikke har struktureret adresseoplysninger i delfelter.

ContactPoint

ContactPoint er en datastruktur som udpeger et "kontaktpunk" som en myndighed har i Næste generation Digital Post. Det er altså ikke noget som almindelige virksomheder har.

Nedenfor ser vi en illustration af hvor ContactPoint er i den samlede MeMO-stuktur. Jeg ser nu på kontaktpunkt-oplysningerne når de er brugt i forhold til en afsender: Sender. ContactPoint kan, ligesom AttentionData, bruges i forhold til modtageren - det ser vi ikke på i denne blog.

Myndigheder skal på NgDP-platformen definerer et eller flere kontaktpunkter som man kan kontakte myndigheden på. Et kontaktpunkt i en kommune kunne for eksempel hedde "teknik og miljø" eller"børn og unge". Detaljeringsgraden og navngivningsformen er op til den enkelte myndighed.

NgDP udstiller web services som gør at man kan slå op og finde myndigheders kontaktpunkter i Myndighedsregisteret.

Skriver man til en myndighed skal man angive et ContactPoint. Det giver ikke mening at sende ContactPoint til borgere eller virksomheder (der ikke er myndigheder). På den baggrund er der en interessant tanke her: Når en myndighed sender Digital Post til en anden myndighed (eksempel: Rigspolitiet til Horsens kommune), så vil det der gør at modtager-myndigheden kan se at der er tale om myndighed-til-myndighed kommunikation være tilstedeværelsen af ContactPoint under Sender-området af Headeren kombineret med at der også er ContactPoint under Recipient-området af Headeren.

ContactPoint skal indeholde et contactPointID og en label, og kan også indeholde en contactGroup. Alle disse oplysninger skal hentes ved opslag til Myndighedsregisterets webservice. contactPointID er en unik nøgle der identificerer et kontaktpunkt, mens label er kontaktpunktets brugervendte navn - eksempelvis "teknik og miljø".

Under ContactPoint kan der være op til to sæt af ContactInfo. Det om der skal findes et eller to sæt ContactInfo vil være noget man finder ved opslaget til Myndighedsregisteret. Hvis der ved opslaget er fundet en eller to af disse så er label givet, og det er forventningen at afsenderen sørger for at udfylde value med en meningsfuld værdi. Grundlæggende er ConttactInfo et område, hvor myndigheden der skrives til kan bede om uddybende information. Så det kunne for eksempel være at myndigheden der skrives til beder afsender om at tage stilling til "barnets alder" (label) og at afsender så skriver "14 år" i value.

Når man sender en Digital Post Meddelelse, og man vælger at knytte ContactPoint-oplysninger til Sender-området, så er det et meget kraftigt signal til modtageren om hvor man ønsker at svar skal sendes hen. Hvis den man sender til er en borger (der læser gennem en Visningsklient på borger.dk) eller en virksomhed (der læser gennem Visningsklienten på virk.dk) så kan man forvente at et svar vil indeholde de samme ContactPoint-oplysninger i AttentionData under Sender-området.

Hvis den man sender til er en myndighed, eller en virksomhed der har eget modtager-system, så kan man ikke være sikker på at svaret vil indeholde de samme ContactPoint-oplysninger i AttentionData under Sender-området, da det er op til disses afsender-systemer at sørge for at genbruge disse oplysninger i svaret. Men det er den klare forventning at det benyttes.

Om det at skrive fra og til myndigheder

MeMo har mulighed for at afsendere kan være:

Borgere
Virksomheder
Myndigheder

Når man skriver til nogen (borger, virksomhed, myndighed) og man selv har rollen myndighed, så sker det ved at at angive ContactPoint-information under Sender.

MeMo har mulighed for at modtagere - dem man skriver til - kan være:

Borgere
Virksomheder
Myndigheder

Når man skriver til en myndighed i dennes rolle som myndighed, så skal det ske ved at angive ContactPoint-information under Recipient.

Har man ikke mulighed for at angive ContactPoint-information under Recipient, så kan man i stedet - i MessageHeader.PostType angive "MYNDIGHED". Det har samme signalværdi - dette er til en myndighed.

Og iøvrigt, så kan man skrive "VIRKSOMHED" i PostType, og så er det et signal om at man skriver til modtageren i dennes rolle som virksomhed. I det tilfælde skal man bestemt ikke angive ContactPoint-information under Recipient.