Konvolutt og melding

En inndelt i tre logiske deler: Adressering, forretningsmelding og dokumentpakke - som er selve meldingen man ønsker å sende. Adresseringen og forretningsmeldingen er realisert ved hjelp av Standard Business Document.

Standard Business Document er en GS1-standard utviklet for å forenkle utveksling av dokumenter i en B2B kontekst. Standardkonvolutten inneholder informasjon for identifisering, adressering og routing av forretningsmeldingen. SBD er obligatorisk i neste versjon av PEPPOL-infrastrukturen for fakturaformidling.

Xsd for SBD

Adressering

Adresseinformasjon legges i Standard Business Document Header.

{
    "standardBusinessDocument": {
        "standardBusinessDocumentHeader": {
            "headerVersion": "1.0",
            "sender": [ {
                "identifier": {
                    "authority": "iso6523-actorid-upis",
                    "value": "0192:<orgnr>"
                }
            }],
            "receiver": [{
                "identifier": {
                    "authority": "iso6523-actorid-upis",
                    "value": "0192:<orgnr>"
                }
            }],
            "documentIdentification": {
                "standard": "urn:no:difi:<meldingstype>:xsd::<forretningsmelding>",
                "typeVersion": "1.0",
                "instanceIdentifier": "ff88849c-e281-4809-8555-7cd54952b916",
                "type": "<forretningsmelding>",
                "creationDateAndTime": "20xx-04-11T15:29:58.753+02:00"
            },
            "businessScope": {
                "scope": [
                    {
                        "type": "ConversationId",
                        "instanceIdentifier": "37efbd4c-413d-4e2c-bbc5-257ef4a65a45",
                        "identifier": "urn:no:difi:profile:arkivmelding:<område>:ver1.0",
                        "scopeInformation": [
                            {
                                "expectedResponseDateTime": "20xx-05-10T00:31:52Z"
                            }
                        ]
                    },
                    {
                        "type": "SenderRef",
                        "identifier": "<UUID>"
                    },
                    {
                        "type": "ReceiverRef",
                        "identfier": "<UUID>"
                    }
                ]
            }
        },
        "forretningsmelding": {}
    }
}

sender/receiver.identifier.value

value feltet krever prefiks 0192: før organisasjonsnummer for alle forsendelser til norske virksomheter. Prefiks er ikke påkrevd på mottaker om mottaker er innbygger.

På-vegne-av-avsender - DPV og DPI

DPV og DPI støtter å sende meldinger på-vegne-av andre virksomheter. Dette angis i sender.identifier.value med følgende syntaks: 0192:<orgnr>:<paa-vegne-av-orgnr>. Når det gjelder DPI, støttes også avsenderidentifikator. Se eksempel under Digital post til innbygger.

messageId

Unik identifikator for meldingen, og brukes til å referere meldinger i grensesnittene. Mapper til documentIdentification.instanceIdentifier i SBD. Denne “erstatter” den gamle ConversationId for meldinger, se info under.

conversationId

Unik identifikator for konversasjonen, knytter meldinger og tilhørende kvitteringer sammen. Mapper til businessScope.instanceIdentifier.

creationDateAndTime

Dette feltet kan utelates da det vil bli satt automatisk til nåtid ved oppretting av SBD. Om en benytter UTC så bør dette feltet utelates.

Forretningsmelding

Forretningsmeldingen inneholder meldingsformidlings-spesifikk informasjon. Dette er informasjon som ikke krypteres og dermed kan brukes til f.eks. routing av meldingen, samt som beslutningsgrunnlag ved mottak av meldingen.

Forretningsmelding kan være en av åtte typer meldinger, de tre hovedmeldingstypene er : Arkivmelding, eInnsyn og Digitalpost. Hver forretningsmelding har en prosess som inneholder “meldingstype” og “område” som er underkategorier for adressering urn:no:difi:profile:<meldingstype>:<område>:ver.1.0. Meldingstype forteller hvilken type melding som skal sendes, mens område blir brukt til å spesifisere hvor/hvordan mottakeren ønsker meldingen. Virksomheten må selv velge hvilke prosesser de ønsker på hvilke kanaler.

Dokumentpakke

Payloaden består av en eller flere filer man ønsker å sende. Dette kan være både strukturert og ustrukturert informasjon.

Dokumentpakken realiseres ved hjelp av Associated Signature Containers.

Associated Signature Containers er et pakkeformat som er designet for å ivareta integriteten til innholdet over lang tid. Kort fortalt definerer standarden hvordan man skal sette sammen en zip-fil med en filstruktur der man lager en digital signatur for hver enkelt fil med en kombinasjon av et digitalt fingeravtrykk av filen og et PKI-sertifikat eid av en virksomhet. Dette medfører at man kan verifisere at filene kommer fra rett virksomhet, og om de har blitt endret etter signering.

Meldingstypene

Arkivmelding

Arkivmeldinger er meldinger som sendes mellom sak-/arkivsystemer basert på NOARK5 metadata. Dersom mottaker ikke har integrasjonspunkt, vil avsenders integrasjonspunkt mappe meldingen til mottakers foretrukne mottaksplattform. I første omgang vil dette i hovedsak dreie seg SvarInn og SvarInn2 etterhvert som denne tas i bruk. Dersom mottaker ikke er knyttet til en annen plattform, vil meldingen sendes til Digital postkasse for virksomheter (DPV). En kan som mottaker med integrasjonspunkt velge at en ikke ønsker motta alle meldingstyper i sitt integrasjonspunkt. Meldingene man ikke ønsker å motta vil da sendes til virksomhetens postboks i AltInn via DPV.

* dokumenttypen er forbeholdt kontrollmeldinger i infrastrukturen og skal ikke brukes av integrasjoner

Forretningsmelding arkivmelding:

"arkivmelding": {
    "sikkerhetsnivaa": "3", // Alt. "4". Valgfri, kun benyttet for DPF
    "dpv": { // Valgfri
        "varselType": "VarselDPVMedRevarsel", // "VarselDPVUtenRevarsel"
        "varselTransportType": "EpostOgSMS", // "Epost", "SMS
        "varselTekst": "Valgfri tekst",
        "taushetsbelagtVarselTekst": "Valgfri tekst", // Kun benyttet for taushetsbelagte meldinger, se under.
        "dagerTilSvarfrist": 7
    }
}

Forretningsmelding arkivmelding_kvittering:

"arkivmelding_kvittering": {
    "receiptType" : "OK",
    "relatedToMessageId" : "5f57494f-9ce7-47ec-853d-f212a65b3dbe",
    "messages" : [ {
        "code" : "Recno",
        "text" : "315890"
    } ]
}

Taushetsbelagt DPV

eFormidling støtter å sende taushetsbelagt post via DPV. Denne meldingskategorien skal benyttes dersom meldingen inneholder særlig sensitive personopplysninger og taushetsbelagt informasjon. Mer om forutsetninger for bruk av meldingen, og krav til roller for lesetilgang kan leses på Altinns sider her.

Standard varslingstekst for taushetsbelagte meldinger er:

$reporteeName$, har mottatt en taushetsbelagt melding fra $reporterName$. For å få tilgang til meldingen, er det nødvendig at noen i $reporteeName$ har fått tildelt rollen «Taushetsbelagt post fra det offentlige» i Altinn. Dersom dere er usikre på om noen har slik tilgang, anbefaler vi sterkt at dette sjekkes. Les mer om å gi tilgang til rollen «Taushetsbelagt post» på Altinns nettsider.

Denne varslingsteksten kan enten overstyres per melding i dens respektive forretningsmelding, eller generelt for alle meldinger ved å sette difi.move.dpv.sensitive-notification-text til valgt tekst i Integrasjonspunktet. Teksten kan inneholde substitusjonsvariablene $reporteeName$ (mottakernavn) og $reporterName$ (avsendernavn).

Digital post til innbygger

Ved sending av digital post til innbygger må man ta stilling til om meldingen har varslingsplikt eller ikke. Les mer om dette her

Begge prosessene støtter både digitalpost og fysisk post.

• Info = informasjonsmeldinger uten varslingsplikt
• Vedtak = meldinger som medfører varslingsplikt

Digital post

{
    "digital": {
        "sikkerhetsnivaa": "",
        "hoveddokument": "",
        "avsenderId": "", // valgfri
        "tittel": "",
        "spraak": "NO",
        "digitalPostInfo": {
            "virkningsdato": "",
            "aapningskvittering": "false"
        },
        "varsler": { // valgfri
            "epostTekst": "Varseltekst",
            "smsTekst": "Varseltekst"
        },
        "metadataFiler": { // valgfri
            "test.pdf": "test-metadata.xml"
        }
    }
}

Fysisk post

{      
    "print" : {
        "hoveddokument": "",
        "mottaker":{
            "navn": "Kan hentes fra capabilitylookup eller supleres fra eget register",
            "adresselinje1": "Kan hentes fra capabilitylookup eller supleres fra eget register",
            "adresselinje2": "Kan hentes fra capabilitylookup eller supleres fra eget register *",
            "adresselinje3": "Kan hentes fra capabilitylookup eller supleres fra eget register *",
            "adresselinje4": "Kan hentes fra capabilitylookup eller supleres fra eget register *",
            "postnummer": "Kan hentes fra capabilitylookup eller supleres fra eget register",
            "poststed": "Kan hentes fra capabilitylookup eller supleres fra eget register",                
            "land": "Kan hentes fra capabilitylookup eller supleres fra eget register"
        },         
        "utskriftsfarge" : "SORT_HVIT",
        "posttype": "B_OEKONOMI",
        "retur":{
            "mottaker":{
                "navn": "Kan hentes fra capabilitylookup eller supleres fra eget register",
                "adresselinje1": "Kan hentes fra capabilitylookup eller supleres fra eget register",
                "adresselinje2": "Kan hentes fra capabilitylookup eller supleres fra eget register *",
                "adresselinje3": "Kan hentes fra capabilitylookup eller supleres fra eget register *",
                "adresselinje4": "Kan hentes fra capabilitylookup eller supleres fra eget register *",
                "postnummer": "Kan hentes fra capabilitylookup eller supleres fra eget register",
                "poststed": "Kan hentes fra capabilitylookup eller supleres fra eget register",                
                "land": "Kan hentes fra capabilitylookup eller supleres fra eget register"
            },
            "returhaandtering": "DIREKTE_RETUR"
        } 
    }  
}

* ikke påkrevd

Digital DPV-melding

{
    "digital_dpv": {
        "tittel": "",
        "sammendrag": "",
        "innhold": ""
    }
}

Lenke uten for brev støttet funksjonalitet og er dokumentert her

eInnsyn

* dokumenttypen er forbeholdt kontrollmeldinger i infrastrukturen og skal ikke brukes av integrasjoner

Journal

{
    "publisering": {
        "orgnr": ""
    }
}

Innsynsbegjæring

{
    "innsynskrav": {
        "orgnr": "991825827",
        "epost": "test@example.com"
    }
}

Møte

{
    "publisering": {
        "orgnr": ""
    }
}

Avtalt

Avtalt er en bilateral meldingstype som lar avsender og mottaker sende en forhåndsbestemt forretningsmelding som kan være strukturert eller ustrukturert.

Det er ikke opprettet en egen type kvittering for forretningsmelding av typen Avtalt.

Avtalt

{
	"avtalt": {
		"identifier": "<type>",
		"content": {
		}
	}
}

Eksempel

{
	"avtalt": {
		"identifier": "no.difi.avtalt.test.v1",
		"content": {
			"eksempel" : "innhold",
			"eksempel2" : "<?xml....>"
		}

	}
}

Forretningsmeldinger som inneholder “ “ må disse endres til ‘ ‘ for å unngå at json-validatoren leser det som et json-element. Dette kan spesielt være aktuelt i XML-filer som inlines i forretningsmeldingen.

Avtalt-meldingen forklart på Integrasjon og sikkerhetsforum 2020. (00:26 – 11:31)

Fiks IO

Integrasjonspunktet støtter å sende meldinger over Fiks IO-platformen. Dette forutsetter konfigurasjon beskrevet her.

Det er opp til den enkelte avsender å verifisere at gitt mottaker kan motta meldinger over valgt meldingsprotokoll; integrasjonspunktet validerer kun at kontoId til mottaker er gyldig.

SBD’en må inneholde følgende:

• receiver.identifier.value: mottakers kontoId, UUID
• documentIdentification.type: fiksio
• documentIdentification.standard: meldingsprotokoll
• businessScope.scope.identifier: meldingsprotokoll (repetert)
• Tom forretningsmelding

Eksempel på full SBD:

{
  "standardBusinessDocumentHeader": {
    "businessScope": {
      "scope": [
        {
          "scopeInformation": [
            {
             "expectedResponseDateTime": "20xx-05-10T00:31:52Z"
           }
         ],
          "identifier": "fiks.io.testprotokoll",
          "type": "ConversationId"
        }
      ]
    },
    "documentIdentification": {
      "standard": "fiks.io.testprotokoll",
      "type": "fiksio",
      "typeVersion": "2.0"
    },
    "headerVersion": "1.0",
    "receiver": [
      {
        "identifier": {
         "authority": "iso6523-actorid-upis",
         "value": "fe3070c9-6fc9-4342-becb-cc56f1bc11d3"
       }
     }
   ]
  },
  "fiksio": {
  }
}

NB: avsender kan ikke overstyres da det alltid er kontoId fra konfigurasjon som benyttes, og kan derfor utelates fra SBD.

Vedlegg håndteres som normalt. Det er ingen kjente begrensninger mot platformen på verken antall vedlegg eller størrelse. For vedlegg større enn 5mb benyttes mellomlagring i Fiks Dokumentlager. Dette er automatisk håndtert av klienten.

Dokumentasjon av Fiks IO finnes her.