Altinn. Elektronisk innrapporteringskanal for næringslivet. Implementasjonsguide. Fagsystem grensesnitt

Transkript

1 Altinn Elektronisk innrapporteringskanal for næringslivet Implementasjonsguide Fagsystem grensesnitt 03.April VERSJON 5.6 Implementasjonsguiden skal være informasjon til alle fagsystemleverandører, og som fagsystemleverandørene kan benytte for å utvikle integrasjonsløsningen for sine systemer til Altinn. Innholdet i implementasjonsguiden skal utelukkende benyttes for dette formål.

2 - 2 - Endringslogg Versjon Dato Endring Initiell versjon Systemtest versjon Første versjon tilgjengelig offentlig Samtlige skjema beskrevet Fagsystemregistrering beskrevet Kvitteringsendring i Altinn versjon 1.1 lagt til Ny funksjonalitet for systemstatus er lagt til Utvidet kvitteringsfunksjonalitet i Altinn versjon 1.2 er lagt til Lagt til beskrivelse av feilmelding ved flere oppgavesett i en batch Beskrevet funksjonalitet for versjon Oppdatert etter review Oppdatert etter ytterligere review Oppdatering: - Enterprise feltene i SignaturElementet er nå satt til obligatorisk - Lagt til en kommentar ved henting av pinkoder til fagsystem Oppdatering: - Formatet på signeringselementet til innsendte batcher og henting av prefill data er litt endrett. Oppdaterte DataExchangeBatch_v3.0.xsd og EnterprisePrefillRequest_v1.00.xsd er lagt ut. - Det er kommet krav om at fagsystemet må autentiseres ved henting av prefill data. Det er derfor lagt til enterprise passord i EnterprisePrefillRequest_v1.00.xsd. - Det er lagt til noen flere retur statuskoder i EnterprisePrefillResponse_v1.00.xsd. - Det er fjernet en tag RequestError fra EnterprisePrefillResponse_v1.00.xsd som ikke er i bruk Rettet opp noen feil i formatet på kvitteringen og fjernet autogenerert kode for xsd. Det er lagt til en DataExchangeReceipt.xsd som spesifiserer formatet på kvitteringen. Det er ingen endringer i Altinn grensesnittene som følge av disse endringene.

3 Lagt til AltinnStatus_v1.0.xsd. - Lagt til archivereference i DataExchangeReceipt_v.2.0.xsd Basert på brukerstøttesaker er forklaringen på de ulike metodekallene i web servicen noe endret Endringer i forbindelse med Altinn versjon 4.0: Lagt til ekstra felter ved henting av prefilldata - ContentDescription - StatusDescription - SignAttachment EnterprisePrefillResponse_v1.00.xsd er oppdatert Forbedring av Systemdokumentasjon Ny funksjonalitet i forbindelse med Altinn versjon 5.0: Lagt til ny webservice: MessageReceiptExchange.wsdl Lagt til Web Service URL for DataExchange og MessageReceiptExchange Ny versjon av DataExchangeReceipt-spesifikasjon: DataExchangeReceipt_v2.1.xsd Ny gyldighet på pinkoder og faktura i AltUt Bedre feilmeldinger fra fagsystem Tinglysning fast eiendom Rettet feil lenke under punkt 3 til spesifikasjonene fra OR.

4 Innholdsfortegnelse ENDRINGSLOGG... 2 INNHOLDSFORTEGNELSE... IV 1 INNLEDNING DEFINISJONER REFERERTE DOKUMENTER OG LINKER OVERORDNET ARKITEKTUR DATAFLYT FRA FAGSYSTEM TIL ALTINN INTEGRASJON Resending GRENSESNITT FORMATER SKJEMA OG OPPGAVESETT VEDLEGG KVITTERINGER SIGNATUR SIKKERHET WEBSERVICE DATAEXCHANGE OVERSIKT OVER TILGJENGELIGE METODER I DATAEXCHANGE TILGJENGELIGE METODER I DATAEXCHANGE SubmitBatchPw SubmitBatch BatchReceiptPw BatchReceipt ActiveForms AltInnStatus GetSchemaDefinition RequestPrefillData RequestAuthenticationChallenge RequestInfoText DATAEXCHANGE MELDINGSFORMATER OG EKSEMPLER SubmitBatchPw Kvitterings format Altinn versjon Aktive skjema format Altinn status format GetSchemaDefinition Preutfylling format Pinforespørsel format Signeringstekst format WSDL DataExchange.wsdl AltinnReceipt.wsdl Konstruksjon av link til signeringsside i fagsystem URL TIL WEB SERVICE MOTTAK WEBSERVICE MESSAGERECEIPTEXCHANGE OVERSIKT OVER TILGJENGELIGE METODER I MESSAGERECEIPTEXCHANGE TILGJENGELIGE METODER I MESSAGERECEIPTEXCHANGE GetReceiptList GetReceipt GetAltUtMessageListForParticipant GetAltUtMessageListForArchiveRef AltInn Side iv av 47

5 8.2.5 GetAltUtMessage GetInvoiceData GetAltUtInvoiceMessageListForParticipant MESSAGERECEIPTEXCHANGE MELDINGSFORMATER OG EKSEMPLER WSDL MessageReceiptExchange.wsdl URL TIL WEB SERVICE MOTTAK AltInn Side v av 47

6 1 Innledning Dette dokumentet beskriver hvordan fagsystem kan integrere seg mot Altinn. Løsningen for integrasjon mot Altinn er utviklet etter følgende mål: Være sikker for avsender og mottaker Baseres på XML Benytte aksepterte internett standarder Unngå bruk av klient/modul hos fagsystem, som gir en sømløs integrasjon. Være uavhengig i forhold til fagsystemets tekniske plattform Ved bruk av web services og et felles format (oppgaveregisteret) er alle disse målene oppnådd. Dette dokumentet beskriver web servicene som skal brukes for å sende/motta data til/fra Altinn, samt beskriver de skjemaene fra oppgaveregisteret som er støttet. For å vise hvordan et fagsystem kobles opp mot Altinn, tilbys en eksempelapplikasjon som simulerer et fagsystem - FagsysSim. Denne applikasjonen implementerer de fleste funksjonalitetene til grensesnittet til Altinn. 2 Definisjoner Navn Fagsystem Arkiv Arbeidsflyt Avgiver DIME Base64 SOAP XSD WSDL WS-Security Sertifikat Signering Hovedskjema Underskjema Vedlegg Beskrivelse System som leverer data til Altinn. Modul som håndterer sikker langtidslagring av data i Altinn. Modul som støtter arbeidflyt knyttet til data i Altinn. Juridisk eier av data som sendes inn, f.eks. en bedrift eller person. Direct Internet Message Encapsulation. Protokoll for effektiv overføring av binære data over internett. Standard for å representere binære data som tekst, slik at binære data kan være en del av f.eks. en XML struktur. Protokoll for overføring av XML data over internett. XML Schema. Meta beskrivelse for XML data. Beskrivelse av hvordan XML dataene skal være strukturert og beskrivelse av alle data elementene. Blir også brukt til å validere XML data. Web Service Description Language. Beskrivelse av dataene og metodene som er støttet av en web service. Denne brukes av utviklingverktøyene for å kunne kalle web servicene. Implementasjon av sikre web services definert av IBM, Verisign og Microsoft. Sikker nøkkel som kan brukes til signering og kryptering av data. Bruk av sertifikat for å sikre at data kommer fra eieren av sertifikatet og at dataene ikke har blitt endret etter at de ble signert. Skjema som kan opprettes som en selvstendig enhet. Skjema som er knyttet til et hovedskjema. Binære filer som f.eks. Word eller Excel som er knyttet til et Altinn Side 6 av 47

7 Oppgavesett FagsysSim Signaturelement hovedskjema. Hovedskjema med tilhørende underskjema og/eller vedlegg. Eksempel applikasjon implementert på.net plattformen som kan sende meldinger til Altinn på lik linje med et faktisk fagsystem. XML-element som inneholder verdier for autentisering og autorisering mot en gitt oppgave, f.eks. signering av skjema fra fagsystem. Altinn Side 7 av 47

8 3 Refererte dokumenter og linker Dokumenter DataExchangeBatch_v3.0.xsd DataExchangeReceipt_v2.1.xsd DataExchange.wsdl AltinnReceipt.wsdl EnterprisePrefillRequest_v1.00.xsd Beskrivelse XML Schema for batch innpakning fra Fagsystem XML Schema for batch kvittering til Fagsystem Beskrivelse av DataExchange web service Beskrivelse av AltinnReceipt web service som kan implemeteres av fagsystem for mottak av kvitteringer XML Schema for innpakning av preutfyllingsforespørsel EnterprisePrefillResponse_v1.00.xsd XML Schema for kvittering av preutfyllingsforespørsel AltInnAuthenticationRequest_v1.0 AltinnSigningText_v1.00.xsd ActiveForms_v1.00.xsd MessageReceiptExchange.wsdl ReceiptListResponse1.0.xsd ReceiptResponse1.0.xsd AltUtMessageListResponse1.0.xsd AltUtMessageResponse1.0.xsd InvoiceDataResponse1.0.xsd XML Schema 0.xsd for forespørsel av pin XML Schema for forespørsel av signeringstekst XML Schema for forespørsel av tilgjengelige skjema Beskrivelse av MessageReceiptExchange web servce XML Schema for returverdi av web metode for å hente liste over kvitteringer XML Schema for returverdi av web metode for å hente kvittering XML Schema for returverdi av web metode for å hente liste over AltUt-meldinger XML Schema for returverdi av web metode for å hente AltUt-melding XML Schema for returverdi av web metode for å hente fakturainformasjon Linker Beskrivelse Nedlasting av OR formatene fra Oppgaveregisteret. Nedlasting av OR formatene fra Altinn. Altinn Side 8 av 47

9 4 Overordnet arkitektur Figuren under illustrerer hvordan hovedkomponentene i Altinn henger sammen. Sentrale komponenter for integrasjon med fagsystem er web servicene samt arkiv- og arbeidsflyt modulene i formidlingssentralen. Les mer om Altinn på Figur 1: Overordnet arkitektur Altinn Side 9 av 47

10 4.1 Dataflyt fra fagsystem til Altinn Integrasjon Når et fagsystem sender data til Altinn, sendes disse som en batch som kan inneholde mange skjema, underskjema og vedlegg. Altinn definerer et XML format for denne batchen, og dette formatet er beskrevet i detalj i dette dokumentet. Figuren under med beskrivelse viser hvordan dataene flyter gjennom løsningen. Altinn Side 10 av 47

11 Figur 2: Dataflyt - skjemadata til Arkiv/Arbeidsflyt Altinn Side 11 av 47

12 Beskrivelse av prosessen som kjøres når fagsystem sender data: Motta batch fra fagsystem Sjekk om signaturelement eksisterer, og autentiserer og autoriserer innsendingen for signering hvis det eksisterer. Valider at fagsystemet er registrert (Autentisering) Sjekk at fagsystemet har rett til å levere for avgiveren(e) (Autorisering) Mottak validerer ytre format Kontrollerer om skjemaversjon er gyldig Kontroll av underskjema / hovedskjema kombinasjon er gyldig Kontroll av hvorvidt binære vedlegg er tillatt Virussjekk vedlegg Splitt batch i enkeltskjema Send skjemadata til konvertering asynkront. Dette gjøres av BizTalk Server. Lagre vedlegg. Vedlegg skal ikke konverteres. Send initiell batch kvittering til Fagsystem. Resten av prosessen håndteres asynkront. Send data til Arbeidsflyt eller Arkiv Komplett/Ikke komplett flagget fra fagsystem styrer veien videre Data som markeres som komplett vil valideres mot obligatoriske felter som definert av OR XSD, samt følge tilleggsvalideringer gitt for skjemaet i denne beskrivelsen. Kun komplette data kan leveres til Arkiv hvis de ikke trenger signering Ikke komplette data leveres alltid til Arbeidsflyt Data som skal godkjennes/signeres leveres alltid til Arbeidsflyt Hvis data er markert med signaturelement vil de ble signert i arbeidsflyt og overført til arkivet. Hvis det er mer enn ett signeringssteg vil de bli liggende i arbeidsflyt i påvente av manuell prosessering etter første signering. Når alle data er levert vil kvittering sendes hvis fagsystemet har indikert at kvittering skal sendes fra Altinn. Det er alltid mulig for fagsystemet å hente kvitteringene via web services ved behov. Data som sendes til Arkiv fra Arbeidsflyt Oppdaterer kvittering med arkivreferanse Initierer ny kvittering hvis fagsystemet har indikert at kvittering skal sendes fra Altinn. Mottaker mottar data fra Arkivet Kun data som er lagret i Arkivet vil være tilgjengelig for mottaker Mottaker har mulighet til å sende mottakerreferanse tilbake til Altinn. Dette initierer ny kvittering hvis fagsystemet har indikert at kvittering skal sendes fra Altinn Mottaker har mulighet til å sende informasjonsmelding tilbake til fagsystemet. Dette initierer ny kvittering hvis fagsystemet har indikert at kvittering skal sendes fra Altinn Fagsystemet kan på denne måten følge dataene fra start til slutt ved at kvitteringen oppdateres med: Initiell referanse Arbeidsflyt referanse Arkiv referanse Mottaker referanse Altinn Side 12 av 47

13 Status på de ulike skjema i forsendelsen (sendt til 1.signeringssteg, sendt til 2.signeringssteg, slettet) KID (MVA skjema) De ulike hendelsene kan man se i kvitteringen som det er mulig å hente ut fra altinn for fagsystemet. Når en hendelse som kan knyttes til et oppgavesett/skjema i Altinn portalen, vil det asynkront sendes en oppdatert hendelse til integrasjonsplattformen av Altinn løsningen. Det er denne plattformen som nyttes for å genrere de kvitteringer som sendes tilbake til fagsystemet, således kan det være noe forsinkelse mellom når hendelsen har skjedd og når dette gjenspeiles i kvitteringen til fagsystemet Resending Dersom man sender inn en ny batch med en ny batcid, men med samme sendersreference på skjemaene i batchen, så vil de gamle skjemadataene bli erstattet av de nye. Altinn Side 13 av 47

14 5 Grensesnitt Grensesnittene mot Altinn er implementert basert på XML og bruk av web services, og Oppgaveregisteret er en meget sentral komponent for datadefinisjonene som benyttes i Altinn. Dette kapittelet forklarer de forskjellige delene som benyttes i grensesnittet. 5.1 Formater Alle skjema som benyttes av Altinn baserer seg på formatet til Oppgaveregisteret. Skjemaene defineres etter XML Schema (XSD) standarden. Fagsystem benytter seg av disse XSD definisjonene til å bygge opp og validere meldingene. Dataene vil også bli validert av Altinn basert på de samme definisjonene. I første versjon av Altinn vedlikeholder Oppgaveregisteret alle skjemaene, men Altinn kan også definere egne skjema, og da på Oppgaveregisterets format. Det er et mål at flest mulig skjema vedlikeholdes av Oppgaveregisteret. Skjemadefinisjonene kan lastes ned fra henholdsvis Oppgaveregisteret og Altinn. Se liste over alle lenker i kapittel 3. I tillegg til disse spesifikasjonene som definerer datainnholdet i hvert skjema, definerer Altinn et XML rammeverk (konvolutt) som ligger rundt disse spesifikasjonene for å håndtere bunting ( batching ) av dokumenter, vedlegg og informasjon som ikke direkte er knyttet til data i skjemaene. Batch formatet er beskrevet i kapittel og kvitteringsformatene (utvidet fra versjon 1.1 av løsningen) er beskrevet i kapittel Skjema og oppgavesett Definisjoner: Hovedskjema er skjema som kan opprettes som en selvstendig enhet. Skjema som hører til et hovedskjema kalles underskjema. Binære filer som f.eks. Word eller Excel, kalles vedlegg. Hovedskjema med tilhørende underskjema og/eller vedlegg kalles oppgavesett. Underskjema håndteres på samme måte som hovedskjema når det gjelder konvertering, den eneste forskjellen er at underskjema har en referanse til hovedskjemaet. Vedlegg virussjekkes og hele batchen vil feile om den inneholder filer med virus. Vedlegg kan kun sendes inn sammen med hovedskjema, men det er ikke mulig å sende inn vedlegg som selvstendige skjema eller i etterkant. Det er mulig å komplettere hovedskjema og underskjema i Arbeidsflyt modulen inntil de er godkjent i portalen og lagret i arkivet. Hvis skjemaene har blitt modifisert i portalen, vil dataene bli sammensmeltet med de nye dataene fra fagsystemet. Hvorvidt det er mulig å editere dokument som er opprettet fra fagsystem er en del av skjemadefinisjonen. Oppgavesett håndteres på følgende måte: Til Arbeidsflyt o Underskjema legges bare inn dersom hovedskjema allerede er opprettet i Arbeidsflyt. o Underskjema kan leveres i forskjellige batcher. Til Arkiv o Kun oppgavesett som er markert som komplette kan lagres i Arkivet. o Ikke mulig å endre oppgavesettet etter at det er lagret. Altinn Side 14 av 47

15 5.3 Vedlegg Vedlegg er binære data som refererer til et hovedskjema. Vedleggene kan være f.eks Word eller Excel filer, men alle typer filer er støttet. Vedleggene kan sendes på to forskjellige måter, enten som en del av batch XML en i SOAP meldingen, eller med bruk av DIME protokollen. Når vedleggene sendes som en del av XML meldingen, benyttes Base64 koding av dataene for at datene skal kunne legges inn i XML en som tekst. Når vedleggene sendes over DIME protokollen, er de ikke en del av XML en, og kan derfor sendes binært. Dette er den store fordelen ved å bruke DIME, da bruk av Base64 koding vil øke meldingsstørrelsen med ca 35%. Ytelsen vil også økes både på avsender- og mottakersiden, da vedleggene ikke behøver å konverteres til/fra Base64. Filnavn på vedleggene kan ikke være lenger enn 40 tegn. 5.4 Kvitteringer Kvitteringene i Altinn er lagt opp slik at fagsystemet skal kunne ha full kontroll over flyten av innsendte data gjennom Altinn. Fagsystemet kan derfor få kvitteringer i følgende situasjoner: Når meldinger er mottatt av grensesnittet for prosessering. Når meldinger er validert og avlevert Arbeidsflyt modulen eller Arkivet. Når meldinger signeres i Arbeidsflyt (1. og 2. signeringssteg) Når skjema slettes fra oppgavesett Når meldinger går fra Arbeidsflyt til Arkivet. Når et offentlig enhetsystem sender kvittering eller melding (alle offentlige enheter sender ikke kvitteringer). Kvitteringene er basert på batchen som sendes inn, men hvert eneste dataelement (Hovedskjema, underskjema eller vedlegg) som ligger i kvitteringen har sin egen status og sitt eget meldingsfelt. Dette betyr at selv om batchen har status OK, vil ikke nødvendigvis alle dataelementene ha dette. Det er fullt mulig at tre oppgavesett leveres OK, mens ett ikke validerer korrekt. I dette tilfelle er det kun det oppgavesettet som feiler som må rettes opp og sendes inn på nytt. Fagsystemet kan motta kvitteringer på to forskjellige måter. Enten ved at fagsystemet selv kaller Altinn og spør etter en kvittering for en gitt batch, eller at Altinn sender kvittering til fagsystemet når endringer oppstår. Hvis Altinn skal sende kvitteringene, må fagsystemet implementere en web service som Altinn kaller. Denne web service må være implementert etter WSDL beskrivelsen i AltinnReceipt.wsdl, se kapittel Altinn anbefaler at fagsystemene spør om kvitteringer pga utsendelse av kvitteringer krever brannmur konfigureringer for hver enkelt bruker. 5.5 Signatur Noen forespørsler til Altinn krever utvidet autentisering og autorisering. I disse tilfellene er det nødvendig å sende ved et signaturelement som bl.a. inneholder pinkode. Signaturen vil så benyttes til å kontrollere de nødvendige rettighetene for oppgaven som skal utføres. Signatur datakreves i forbindelse med Signering fra fagsystem. Henting av preutfyllingsdata til fagsystemene Altinn Side 15 av 47

16 6 Sikkerhet Det tilbys serversertifikat og passord for å beskytte dataene. Sikkerhetsimplementasjonen skal sikre at meldingene som sendes over internett ikke kan leses eller modifiseres av andre, og at Altinn kan være sikker på at fagsystemet som sender dataene kan autentiseres, samt at fagsystemet har rett til å sende inn data for den gitte avgiver (er autorisert). Eieren av et fagsystem må derfor registrere fagsystemet i Altinn slik at Altinn har mulighet til å autentisere og autorisere. Ved registrering i portalen opprettes en unik fagsystem identifikator, og denne identifikatoren sendes med hver melding som sendes Altinn. Fagsystemet har rett til å levere data for alle avgivere eieren av fagsystemet har rett til å levere for. Eierens rettigheter hentes i utgangspunktet fra enhetstregisteret, men det er også mulig for en avgiver å legge på disse rettighetene eksplisitt i portalen. For å unngå ekstra administrasjon er det derfor meget viktig at avgivere sørger for at enhetsregisteret til enhver tid er oppdatert med korrekte opplysninger. For at et fagsystem skal kunne gi data til skjema i Altinn, må den ansvarlige for selskapet for eksempel daglig leder eller styreformann registrere systemet i portalen. Dette gjøres fra siden Brukeradministrasjon på følgende måte: 1. Klikk på lenken Registrere virksomhetens datasystemer nederst til høyre. 2. Fyll ut feltene for datasystemet du ønsker å registrere. Sertifikat DN må du kopiere fra oversikten over sertifikat som du bl.a. finner i nettleseren din. 3. Klikk Lagre og det nye datasystemet vil komme opp i listen til venstre på siden. 4. Feltet ID må brukes for innsending fra fagsystemet i kombinasjon med passord eller klientsertifikat for sikkerhetskontroll ved innsendelse fra fagsystemet. For videre informasjon om registrering og rettighetsadministrasjon, benytt hjelpesystemet til Altinn på Altinn Side 16 av 47

17 7 WebService DataExchange Denne web servicen implementerer metodene for å sende inn data fra fagsystemer, samt for uthenting av status for disse dataene. Definisjonen av web servicen ligger i filen DataExchange.wsdl, og WSDL er beskrevet i Oversikt over tilgjengelige metoder i DataExchange Metode Kort beskrivelse GetSchemaDefinition Henter xsd spesifikasjonen for et gitt OR nummer og versjon BatchReceiptPw Henter kvittering for en gitt innsending ActiveForms Henter en liste over aktive skjemaer I Altinn RequestInfoText Henter signeringstekst I forbindelse med signerte innsendinger AltInnStatus Henter status informasjon om Altinn. SubmitBatchPw Innsending av batcher RequestAuthenticationChallenge Forspørring om pinkoder for SMS eller brevkoder RequestPrefillData Henter preutfyllingsdata BatchReceipt Bør ikke brukes. Erstattet med BatchReceiptPw BatchStatus Bør ikke brukes. Erstattet med BatchReceiptPw SubmitBatch Bør ikke brukes. Erstattet med SubmitBatchPw. BatchStatusPw Bør ikke brukes. Erstattet med BatchReceiptPw Tabell 1 Oversiktsliste over tilgjengelige metoder i DataExchange Altinn Side 17 av 47

18 7.2 Tilgjengelige metoder i Dataexchange SubmitBatchPw Denne metoden tar en instans av XML data etter spesifikasjonen DataExchangeBatch_v3.0.xsd (se kapittel 7.4) som parameter, og leverer innholdet for videre prosessering. Batchen inneholder all informasjon Altinn trenger for å legge inn dataene. Vedlegg sendes over DIME protokollen eller som Base64 kodede data i selve XML en. Ved bruk av DIME protokollen sendes dataene over linjen binært, og er derfor mye mer effektivt i forhold til Base64, både prosesseringsmessig og plassmessig. Se kapittel 5.3. Metoden sjekker først om fagsystemet er registert som et gyldig fagsystem og er autorisert for å levere data for den/de angitte avgiver(e). Eventuelle vedlegg virussjekkes. Hvis disse sjekkene feiler, vil hele batchen feile, og kvitteringen vil gi informasjon om hva som er feil. Se beskrivelse av kvitteringene i kapittel Batchen splittes så opp i enkeltdokumenter og lagres for videre prosessering. Når denne metoden returnerer med en OK kvittering, betyr det at Altinn har lagret batchen. Altinn vil asynkront prosessere dataene videre, og statusen vil kontinuerlig oppdatere seg. Hvis status skal hentes ut med BatchStatus metoden, bør denne implementeres brukerstyrt, eventuelt med polling med økende tidsintervall for å unngå unødig belastning av løsningen. Viktige styreparametre i batch XML: receipttype: Denne styrer hvordan Altinn håndterer kvitteringer. Hvis denne settes til OnDemand, betyr det at det er avsenders ansvar å hente statusen på batchen via BatchReceipt metoden. Det er også mulig å sette opp at Altinn skal kalle fagsystemets web service når statusen for dataene endres. Når denne kvitteringsmetoden benyttes, må fagsystemet til enhver tid være tilgjengelig. Altinn vil forsøke å levere kvitteringene et gitt antall ganger før leveransen feiler. completed: Dette attributtet styrer hvorvidt Altinn skal behandle dataene som ferdigstilte, slik at det kun er eventuelt godkjenning som mangler. Dataene vil da bli validert før de legges inn, både i forhold til påkrevde felter, og om oppgavesett er komplette. Tilleggsvalideringer utover XML Schema vil også bli utført. Denne bør derfor bare settes på data som skal rett i arkivet. locked: Dette attributtet styrer om data skal kunne modifiseres i portalen selv om de er sendt inn fra fagsystem. Dersom oppgavesett er sendt inn som komplett vil ikke data kunne endres selv om feltet settes til usann. EnterpriseSignature (nytt i v3.2): Denne XML blokken er valgfri, og kan brukes til å sende inn signeringsinformasjon for hvert oppgavesett i batchen. Når batchen inneholder korrekt signeringsinformasjon vil Altinn gjennomføre 1. signeringssteg for oppgavesettet. Krever skjemaet kun ett signeringssteg vil det deretter sendes direkte til arkivet. Krever skjemaet 2 signeringssteg vil Altinn utføre det første signeringssteget og skjemaet blir liggende i portalen slik at brukeren kan logge inn og utføre det andre signeringssteget. Når signeringsinformasjon skal brukes ved SubmitBatchPw må følgende steg utføres i sekvens av fagsystemet: Altinn Side 18 av 47

19 o o o Fagsystemet kaller metoden RequestAuthenticationChallenge( ) for å spørre om pinkode på SMS eller referanse til pinkode brev. Denne pinkoden er gyldig i 30 minutter. Beskrevet i kapittel Fagsystemet kaller metoden RequestInfoText( ) for å hente signeringstekst for skjemaet som skal sendes inn signert. Fagsystemet er pliktig til å vise signeringsteksten til brukeren for det aktuelle skjemaet før det kan sendes inn. Metoden er beskrevet i kapittel Brukeren taster inn enten SMS koden eller pinkoden fra brevet som fagsystemet setter inn i SignatureData elementet i batchen, og SubmitBatchPw brukes for å sende batchen. Det er ikke nødvendig at fagsystemet kaller metoden RequestAuthenticationChallenge( ) før hver eneste innsending. Brukeren vil være autentisert i 30 minutter etter at Altinn sender ut koden. I dette tidsrommet kan brukeren sende inn et valgfritt antall batcher ( og forespørre preutfyllingsdata som beskrevet i kapittel 7.2.8). Hvis brukeren sender inn en batch når 30 minutter er overskredet, vil Altinn gi beskjed om at ny autentisering er nødvendig. Merk at batchen som sendes inn kan inneholde flere EnterpriseSignature elementer. Hvert EnterpriseSignature element inneholder SenderesReference som er referansen til oppgavesettet som skal signeres, dvs referansen til hovedskjemaet. Det skal ikke lages EnterpriseSignature elementer for underskjemaer eller vedlegg. For at antall kombinasjoner av signerte oppgavesett og usignerte oppgavesett i samme batchen ikke skal være for komplisert, gjelder følgende begrensninger: (Viktig!) Kun ett signaturelement per oppgavesett. Hvis ikke alle oppgavesett har ett signaturelement blir batchen forkastet direkte. Det vil si at enten skal batchen inneholde EnterpriseSignature element for alle oppgavesettene, eller så skal batchen ikke inneholde signaturinformasjon. Hele batchen blir forkastet hvis ett av signaturelementene ikke passerer autentisering og autorisering. Har f.eks. ikke brukeren rettigheter til å signere ett av oppgavesettene i batchen blir hele batchen forkastet. Hvis det ikke er signaturelementer i batchen, behandles den tilsvarende som før versjon 3.2. Innsending fra fagsystem i versjon 3.2 vil være bakoverkompatibel med løsningen før versjon 3.2 Hvis det er skjemaer i batchen som egentlig ikke trenger signering vil de behandles på normal måte. Det vil da registreres et signaturelement, men det vil ikke knyttes opp mot noen godkjenningssteg. Det vil si at skjemaer som ikke trenger signering i portalen vil håndteres likt om skjemaet er en del av en signert batch eller del av en usignert batch. (Under forutsetning at det er sendt inn komplett) Signaturenen vil ligge i en egen samling i batchen (<EnterpriseSignatures/>), se xsd definisjonen Signatur elementet inneholder bl.a. 5 elementer som inneholder Enterprise informasjon, dvs informasjon om fagsystemet. Elementene er listet under sammen med en beskrivelse. Feltene vil ikke være synlig for brukeren i Altinn løsningen og har heller ingen annen funksjonell verdi. De er inkludert for å kunne feilsøke mellom fagsystemet og Altinn Feltnavn EnterpriseSystemLoginDateTime EnterpriseSystemSignatureDateTime EnterpriseSystemSignatureLogId Beskrivelse Skal inneholde tidsstempelet når brukeren logget inn i fagsystemet Skal inneholde tidsstempel når brukeren signerte batchen i fagsystemet Hvis fagsystemet genererer en identifikator når batchen Altinn Side 19 av 47

20 EnterpriseSystemVersion EnterpriseSystemUserId signeres av brukere skal den puttes inn her. Denne er tiltenkt at Altinn kan matche en Altinn arkivering med en unik referanse i fagsystemet for et signert oppgavesett. Dette feltet skal inneholde versjonen av fagsystemet. Bruken id til vedkommende som er logget inn i fagsystemet I tillegg til feltene listet over inneholder signeringselementet informasjon om brukeren som sender inn den signerte batchen. Signeringsinformasjonen er ikke påkrevd ved sending av batcher og Altinn vil være fullt ut bakoverkompatibel med forrige versjon. Public string SubmitBatchPw (string) Type Navn Beskrivelse string batch XML i henhold til batch spesifikasjon (DataExchangeBatch_v3.0.xsd). Se kapittel string password Passord fra registreringen av fagsystemet Returverdi string Beskrivelse XML i henhold til kvitterings spesifikasjon (DataExchangeReceipt_v2.1.xsd), se kapittel SubmitBatch Bør ikke benyttes. Bruke SubmitBatchPw BatchReceiptPw Etter ønske fra fagsystemleverandørene vil det fra lanseringsdato for Altinn versjon 1.2 bli tilbudt utvidet kvitteringsfunksjonalitet fra Altinn til fagsystemene. Den nye kvitteringsfunksjonaliteten vil inneholde historikk for skjemaene, noe som vil gjøre det enklere å se hvilke hendelser som har skjedd med de oppgavesett som er blitt sendt inn. Kvitteringsfunksjonaliteten i Altinn versjon 1.2 bygger på den allerede eksisterende kvitteringsfunksjonaliteten som eksisterer i løsningen i dag. For å ikke skape forvirring rundt hva som tilbyes/returneres av de ulike webservicene, er kvitteringsfunksjonaliteten som tilbyes av Altinn v1.1 ikke nevnt i denne versjonen av implementasjonsguiden. For detaljer rundt dette, se Implementasjonsguiden v1.1.5 som også er tilgjengelig for nedlasting på fagsystemportalen. Public string BatchReceiptPw (int, string, string, int) Altinn Side 20 av 47

21 Type Navn Beskrivelse int enterprisesystemid Identifikator for fagsystemet som sender data string batchid Unik identifikator for batchen innenfor fagsystemet string password Passord fra registreringen av fagsystemet int version Hvilken versjon av kvitteringsfunksjonaliteten som man ønsker å benytte (ved senere utvidelser) Returverdi string Beskrivelse XML i henhold til kvittering spesifikasjon (DataExchangeReceipt_v2.1.xsd), se kapittel BatchReceipt Bør ikke brukes. Erstattet med BatchReceiptPw ActiveForms Metoden henter oversikt over aktive skjema i Altinn. Metoden gir oversikt over metadata om det enkelte skjema som er nødvendig for å sikre en smertefri integrasjon med Altinn. Blant de viktigste metadata er særælig skjemanummer og spesifikasjonsnummer nevnes, da bruk av feil versjon vil forkaste hele eller deler av innsendingen Public string ActiveForms () Type Navn Beskrivelse Returverdi String Beskrivelse XML i henhold til spesifikasjon (ActiveForms_v1.00.xsd), se kapittel Altinn Side 21 av 47

22 7.2.6 AltInnStatus Dagens webservice utvides med en ny metode som vil kunne gi status på systemet til sluttbrukere. Status vil kunne inneholde Varsel om planlagt nedetid med tidspunkt for oppstart og avslutning Melding om at systemet er nede og når det forventes oppe Tall og andre indikasjoner på mengden av dokumenter i asynkron meldingskø for å kunne gi indikasjon på hvor lang prosesseringstid som kan forventes før en innsending ligger i arbeidsflyt. Public string AltInnStatus () Type Navn Beskrivelse Returverdi String Beskrivelse XML i henhold til spesifikasjon (AltInnStatus_v1.0.xsd), se kapittel GetSchemaDefinition Dette er en ny webservice som tilbyes fom Altinn v1.2. Denne muliggjør å laste ned skjemadefinisjoner for skjema som eksisterer i Altinn løsningen (skjemadefinisjoner for gyldiger og tidligere versjoner av skjema). Webservicen returnerer skjemadefinisjonen for det aktuelle skjemaet (med gitt kombinasjon av OR-nummer og OR-versjon) eller en tekst streng som inneholder informasjon om feil. Public string GetSchemaDefinition (long, long) Type Navn Beskrivelse long ornumber ornummer til skjema long orversion orversjon til skjema Returverdi string Beskrivelse Skjemadefininsjonen for det aktuelle skjemaet eller tekststreng om at den aktuelle skjemadefinisjonen ikke finnes. XML i henhold til kvittering spesifikasjon (SchemaDefinition_v1.0.xsd) Webservice for å laste ned xsd bør vurderes brukt sammen med webservice som returnerer ActiveForms da denne gir hvilke skjema som er gyldige i løsningen. Følgende muligheter finnes for kombinasjonen OR nummer/or versjon: Inputparametre Returverdi OR-nummer og OR-versjon har gyldige verdier Skjemadefinisjonen for det aktuelle skjemaet OR-nummer og OR-versjon finnes ikke (begge feil) Tekst om at skjemadefinisjonen med ORnummer og OR-versjon ikke eksisterer Altinn Side 22 av 47

23 OR-nummer eksisterer, OR-versjon er feil OR-nummer eksisterer, OR-versjon = 0 Tekst om at skjemadefinisjonen med ORnummer og OR-versjon ikke eksisterer, siste versjon av skjemaet er. Siste gyldige versjon av skjemaet RequestPrefillData Dette er en ny webservicemetode som tilbys f.o.m. Altinn v3.2. Denne muliggjør å hente preutfylte oppgavesett som eksisterer i Altinn. Metoden returnerer preutfyllingsdata for et oppgavesett basert på det aktuelle hovedskjemaet med gitt kombinasjon av OR-nummer og OR-versjon for en bruker. Et oppgavesett vil være et preutfylt hovedskjema og eventuelle preutfylte underskjemaer og binære vedlegg. Preutfyllingsdataene er XML filer som følger standardene som er definert i oppgaveregisteret. Dette gjelder både hovedskjemaet og eventuelle underskjemaer. De binære vedleggene er BASE64 encodede strenger som er inkludert i XML fila. Når fagsystemet henter preutfyllingsdata er følgende steg nødvendig: Fagsystemet kaller metoden RequestAuthenticationChallenge( ) for å hente pinkode for SMS eller fra brev. Pinkoden er gyldig i 30 minutter. Fagsystemet henter preutfyllingsdata med RequestPrefillData( ) for et gitt hovedskjema og bruker. Preutfyllingsdataene brukes i fagsystemet og skjemaet sendes inn med SubmitBatch/SubmitBatchPw. Det er ingen forskjell i måten batchen sendes til Altinn på utfra om preutfyllingsdata er brukt eller ikke. Det er ikke nødvendig at fagsystemet kaller RequestAuthenticationChallenge( ) i forkant av hvert eneste RequestPrefillData( ) kall. Autentisering fra RequestAuthenticationChallenge( ) er gyldig i 30 minutter og innefor denne tidsperioden kan brukeren hente preutfyllingsdata et vilkårlig antall ganger ( og sende inn signerte batcher som er beskrevet i kapittel 7.2.1). Når 30 minutter er overskredet vil Altinn gi melding om at ny autentisering er nødvendig. Det er mulig at de offentlige enhetene har sendt ut flere sett med preutfyllingsdata for et skjema for en bruker. RequestPrefillData( ) vil returnere alle preutfylte oppgavesett som eksisterer. Hvert oppgavesett har en unik kombinasjon av identifiserende felter. De identifiserende feltene kan også være blanke for et oppgavesett, men alle settene skal ha en unik kombinasjon. Det er opp til fagsystemleverandørene å bestemme hvordan dette skal håndteres. Det beste er selvfølgelig at brukeren kan velge hvilket sett som skal brukes. Preutfyllingsdataene kan osgå inneholde presentasjonsfelter og det er data som er karakteristisk for et oppgavesett. Altinn anbefaler en sammensetning av presentasjonsfeltene som en ledetekst hvis brukeren må ta et valg hvilke oppgavesett som skal brukes. I denne sammenhengen skal det også nevnes at Altinn returnerer kun gyldige preutfylte oppgavesett (ValidFrom, ValidTo). Det vil ikke være muligheter for fagsystemer å hente historiske preutfyllingsdata, og det er heller ikke mulig å forespørre preutfyllingsdata kun for et underskjema. Merk at Altinn ikke har noen begrensninger på at skjemaet blir sendt tilbake til Altinn innenfor ValidFrom og ValidTo som er definert i preutfyllingsdataene. Hvis brukeren henter preutfyllingsdata fra Altinn og deretter venter med innsending til etter ValidTo vil Altinn godta denne innsendingen. For versjon 4.0 av Altinn er det lagt til 3 attributter for binære filvedlegg: Altinn Side 23 av 47

24 - ContentDescription - StatusDescription - SignAttachment Fagsystemene skal ikke sende inn denne informasjonen når dataene sendes inn med Submitbath()/SubmitbatchPw() metodene. Foreløpig er det kun til informasjon. Fagsystemet må autentiseres med fagsystemid og passord. public string RequestPrefillData( string prefillrequestxml ) Type Navn Beskrivelse string prefillrequestxml XML i henhold til preutfyllingsspesifikasjon (EnterprisePrefillRequest_v1.00.xsd) Returverdi String Beskrivelse Preutfyllingsdata for den aktuelle forespørselen eller status som omhandler feil i forespørselen XML i henhold til kvittering spesifikasjon (EnterprisePrefillResponse_v1.00.xsd) RequestAuthenticationChallenge Dette er en ny webservicemetode som tilbys f.o.m. Altinn v3.2. Denne muliggjør å forespørre pinkode per SMS eller å sette aktiv pinkode fra brev. Metoden skal brukes i forkant av innsending av signerte batcher, beskrevet i kapittel 7.2.1, og henting av preutfyllingsdata, beskrevet i kapittel Gyldighet på pinkoder fungerer på følgende måte: Når en pinkode blir bestilt per SMS eller brev har den en gyldighet på 30 minutter. I dette tidsrommet kan brukeren sende inn signerte batcher og hente preutfyllingsdata. (Dette gjøres av webservicemetoder som bruker pinkode.) Hvis pinkoden er gyldig, og brukeren kaller en webservicemetode som benytter pinkode, vil pinkodegyldigheten utvides med 30 minutter fra det tidspunktet webservicemetoden ble kalt. Hvis pinkoden er ugyldig, og brukeren kaller en webservicemetode som benytter pinkode, vil det bli returnert en feilmelding som sier at pinkoden ikke lengre er gyldig. (Brukeren er ikke lenger autentisert.) Hvis det har gått 8 timer etter at den opprinnelige pinkoden ble bestilt, og brukeren prøver å kalle en webservicemetode som benytter pinkode, vil brukeren få en feilmelding som sier at maksimum gyldighetsperiode har utgått. Når en pinkode er ugyldig eller maksimum gyldighetsperiode har utgått må brukeren bestille en ny pinkode. Det er en fordel om fagsystemet implementerer en klokkenedtelling etter at pinkoden blir mottatt slik at brukeren til enhver tid vet hvor lenge den nåværende pinkoden kan brukes. Dette vil redusere antall SMS-utsendinger og medføre at pinkodebrev vil ha lenger holdbarhet. I tilfeller der pinkoden er/blir ugyldig, er det en fordel om fagsystemet enkelt gir brukeren tilgang til å hente pinkode på nytt og deretter sende inn den signerte batchen på nytt. Altinn Side 24 av 47

25 string RequestAuthenticationChallenge( int EnterpriseId, string FNumber, string Password, EnterpriseSigningAuthenticationMethod AuthenticationMethod ) Type Navn Beskrivelse int EnterpriseId Fagsystem id string FNumber Fødselsnummer til brukeren som spør om pinkoden string Password Passord brukeren som spør om pinkoden EnterpriseSigning AuthenticationMet hod AuthenticationMethod Autentiseringsmetoden (Brev/SMS) Returverdi String Beskrivelse Kvittering med infomasjon om pin. Svaret varierer basert på type av forespørsel (Brev/SMS) XML i henhold til kvittering spesifikasjon (AltinnAuthenticationRequest _v1.00.xsd) RequestInfoText Dette er en ny webservicemetode som tilbys f.o.m. Altinn v3.2. Denne muliggjør å forespørre signeringstekst fra fagsystemet. Fagsystemet er pliktig til å vise signeringsteksten til brukeren før en signert batch skal sendes inn til Altinn. public string RequestInfoText(EnterpriseInformationType informationtype, long ornumber, long orversion, int languagecode )) Altinn Side 25 av 47

26 Type Navn Beskrivelse EnterpriseInformationT ype informationtype Fagsystem id long ornumber OR nummer for skjema long orversion OR versjon for skjema int languagecode Språkkoden for signeringsteksten Returverdi Beskrivelse Signeringsteksten for skjemaet. String XML i henhold til kvittering spesifikasjon (AltinnAuthenticationRequest _v1.00.xsd) Hvis signeringsteksten ikke finnes for språkkoden vil Altinn sende tilbake signeringstekst for språkkode 1044 (Norsk bokmål). Altinn Side 26 av 47

27 7.3 DataExchange meldingsformater og eksempler SubmitBatchPw Formatet som benyttes baserer seg på Oppgaveregisterets meldingsdefinisjon. For alle skjema i første versjon er Oppgaveregisteret eier av den XSD som beskriver dataformatet for det enkelte skjema. Innsending av data krever en del tilleggsinformasjon (metadata) som blant annet inneholder informasjon om avsender og hvordan dataene skal behandles. Det er også mulig å sende inn data for mer enn ett skjema av gangen, samt vedlegg. De kommende kapitler beskriver hvordan denne strukturen er bygd opp. Beskrivelse attributter: Attributt schemaversion Beskrivelse Versjon av XSD som dataene er generert ut i fra. Alle Altinn spesifikasjoner har denne attributten. Verdien skal være 1.1 i denne versjonen. enterprisesystemid Unik identifikator for fagsystemet. Denne identifikatoren mottas når fagsystemet registerers i Altinn. batchid Unik identifikator for batchen som sendes inn. Denne identifikatoren må være unik innenfor enterprisesystemid, det vil si at flere fagsysstem kan levere data med samme batchid. receipttype receipturl Denne styrer hvordan Altinn håndterer kvitteringer. Hvis denne settes til OnDemand, betyr det at det er avsenders ansvar å hente statusen på batchen via BatchStatusPw metoden. Det er også mulig å sette opp at Altinn skal kalle fagsystemets web service når statusen for dataene endres. Fagsystemet angi web adressen til fagsystemets web service. Eksempel: Denne web servicen må være implementert etter wsdl beskrevet i kapittel participantid sendersreference parentreference completed locked Avgivers identifikator. Dette er enten et fødselsnummer eller organisasjonsnummer. Avsenders referanse for hvert av dataelementene som sendes inn. Hovedskjema, underskjema eller vedlegg. Referanse til hovedskjemaets sendersreference. Settes på underskjema eller vedlegg. Styrer hvorvidt Altinn skal behandle dataene som ferdigstilte, slik at det kun er eventuelt godkjenning som mangler. Dataene vil da bli validert før de legges inn, både i forhold til påkrevde felter, og om oppgavesett er komplette. Tilleggsvalideringer utover XML Schema vil også bli utført. Denne bør derfor bare settes på data som skal rett i arkivet. Styrer hvorvidt Altinn skal behandle låse innsendte data i portalen. Altinn Side 27 av 47

28 deliverymethod filename Id Dersom skjema er merket som komplett vil skjemadata alltid låses, men ved ikke komplett vil man kunne styre hvorvidt data skal kunne endres i portalen. Dersom ingen verdi er satt i attributtet tolkes dette til at data skal være låst. Styrer hvordan vedlegg er levert. BASE64 betyr at vedlegg leveres i XML som Base64 kodede data. DIME betyr at vedlegg leveres på DIME protokollen. Fil navn uten sti som informasjon om det originale filnavnet. Brukes kun når deliverymethod er DIME for å identifisere vedleggene som sendes utenfor SOAP meldingen. submissionreference Unik referanse innen Altinn som opprettes for hvert enkelt dataelement (Hovedskjema, underskjema eller vedlegg) som sendes Altinn. workflowreference archivereference receiversreference timereceived status Unik referanse fra Arbeidsflyt pr dataelement Unik referanse fra Arkiv pr dataelement Referanse fra mottaker av dataene Tidsstempel for når dataene ble mottatt for prosessering Både batch og skjema/vedleggsnivå har status Kode Beskrivelse Batch/Data nivå OK Ingen feil. Begge AccessDenied FormatError ValidationError Autentisering eller autorisasjonsfeil. Dette vil si at enten er passord/sertifikat feil, eller så har fagsystemet ikke lov å levere for en av avgiverene i batchen. Formatet er ikke i henhold til XSD spesifikasjonen, melding i Message. Validering feilet, valideringsmelding i Message. Batch Begge Data AllreadyExists Batchen finnes allerede fra før. Batch DoesNotExist GenericError InternalError Batch has failed due to several main forms in databatch Batchen finnes ikke (Hvis man spør etter kvittering). Uspesifisert feil (melding kan gis i Message). Intern feil har oppstått i Altinn. Feilen er logget og tas tak i av Altinn drift. Databatchen inneholder mer enn ett oppgavesett/hovedskjema og kan ikke håndteres av Altinn løsningen. Batch Begge Begge Batch SigningAuthenticationError Signaturen feilet ved autentisering Batch SigningAuthorisationError Signaturen feilet ved autorisering Batch SigningOptionError Kombinasjon av signatur og type batch er ikke gyldig, f.eks. batch markert som signert men markert ikke komplett Batch Altinn Side 28 av 47

29 FormNotFound Kombinasjonen av skjemanummer og skjemaversjon finnes ikke i Altinn. Dette vil resultere i følgende Messageelement: <Message> Form with or number 179 and or version does not exist in Altinn</Message> Data Viktige elementer: DataUnit: Dette elementet holder skjemadataene. Dette er definert slik at det kan legges inn vilkårlig XML under dette elementet. XML en som legges inn her må ikke inneholde den normale xml headeren (<?xml version=...), og være i henhold til XML Schema beskrivelsen for skjema dataene. Message: Vil inneholde tekst for system meldinger Vil inneholde xml for valideringsmeldinger <ValidationMessages> <Message fieldtype= type field= id > text </Message> <Message fieldtype= type field= id > text </Message> </ValidationMessages> fieldtype= OR betyr at field vil inneholde OR id til feltet som ikke validerer. Tekst vil være en tekst som kan presenteres til brukerene. Eksempel: <ValidationMessages> <Message fieldtype= OR field= 532 >Kan ikke fylles inn når totalsum er større enn 8000.</Message> </ValidationMessages> Vil kunne inneholde tekst eller xml fra mottaker. Formatet på denne gis for hvert skjema Eksempel: Hovedskjema med id 30, har et underskjema og tre vedlegg som skal sendes over DIME protokollen. Skjemaene er ikke komplette (de vi derfor bli sendt til Arbeidsflyt). Avgivende organisasjon har organisasjonsnummer , og er sendt fra et fagsystem identifisert med id 10. <?xml version="1.0" encoding="utf-8"?> <DataBatch batchid="1000" enterprisesystemid="10" schemaversion="1.1" receipttype="ondemand"> <DataUnits> <DataUnit participantid=" " sendersreference="30" parentreference="" completed="0"> <Skjema xmlns:brreg=" xmlns:xsi=" skjemanummer="212" spesifikasjonsnummer="240" blankettnummer="rf-0002" tittel="alminnelig omsetningsoppgave" gruppeid="20" etatid=" "> <GenerellInformasjon-grp-2581 gruppeid="2581"> <Avgiftspliktig-grp-50 gruppeid="50"> Altinn Side 29 av 47

30 <EnhetNavn-datadef-1 orid="1">fagsysorg</enhetnavn-datadef-1> <EnhetPostadresse-datadef-14 orid="14">fagsysvegen</enhetpostadresse-datadef-14> </Skjema> </DataUnit> <DataUnit participantid=" " sendersreference="34" parentreference="30" completed="0"> <Skjema xmlns:brreg=" xmlns:xsi=" skjemanummer="215" spesifikasjonsnummer="250" blankettnummer="rf-0345" tittel="underskjema alminnelig omsetningsoppgave" gruppeid="20" etatid=" "> <GenerellInformasjon-grp-2581 gruppeid="2581"> <Avgiftspliktig-grp-50 gruppeid="50"> <UnderData-datadef-1 orid="1">300</underdata -datadef-1> </Skjema> </DataUnit> </DataUnits> <Attachments deliverymethod="dime"> <Attachment participantid=" " sendersreference="31" parentreference="30" filename="test1.doc" id="1"/> <Attachment participantid=" " sendersreference="32" parentreference="30" filename=" test2.doc " id="2"/> <Attachment participantid=" " sendersreference="33" parentreference="30" filename=" test3.doc" id="3"/> </Attachments> </DataBatch> Spesifikasjonen er definert i DataExchangeBatch_v3.0.xsd Kvitterings format Altinn versjon 1.2 Eksempel: I det følgende er to kvitteringer listet opp kvitteringen er utvidet for økt lesbarhet. Som tidligere vil historikken for batch kunne sees på hovedskjema (at skjema er motatt av altinn og eventuelle feil vil kunne sees på hvert enkelt skjema). Pga ytelsesmessige vurderinger vil det ikke gis full historikk på alle skjema. Dersom et underskjema slettes vil workflow reference for det aktuelle skjemaet settes til DELETED. Som tidligere vil den intielle kvitteringen inneholde submissionreference dette betyr at ingen av disse dokumentene er ferdig prossessert. Videre kan man også lese ut av kvitteringen om et skjema har blitt sendt til prosesering eller ikke. Videre vil kvitteringen gi historikk over hendelser som er knyttet til batchen. Feil knyttet til underskjema kan sees på underskjema som tidligere, og innslaget i Message elementet vil for eksempel rapportere spesifikt at det dreier seg om feil kombinasjon av skjemanummer og skjemaversjon. Eksempel 1: Skjema som er komplett innsendt. <?xml version="1.0"?> <DataBatchInReceipt schemaversion="1.0" batchid=" a736-4c1d-bb0d-e0c2356f469c" enterprisesystemid="43" status="ok"> <DataUnitInReceipt sendersreference="4f0039f ea-82cd-ab6c2efb07fd" submissionreference="{88591ea5-9f2e-4f5d-9a fce46f48}" workflowreference="wm854055" archivereference="am200" status="ok" timereceived=" :27:30" ornumber="890" orversion="2206" participant=" " completed="1" locked="1"> <Message> <MessageEntry type="received" logged=" t12:27:30" user="maestro">motatt av Altinn</MessageEntry> <MessageEntry type="signedbyparticipant" logged=" t12:29:50" user="etternavn, Fornavn" rolerequirement="sigai">signert skatteyter</messageentry> <MessageEntry type="signedbyaccountant" logged=" t12:45:50" user="etternavn, Fornavn" rolerequirement="revai">signert revisor</messageentry> <MessageEntry type="archived" logged=" t12:50:50" user="altinn">sendt til arkiv</messageentry> </Message> </DataUnitInReceipt> <DataUnitInReceipt sendersreference="ee8295f8-f88a a816127cdb4e" submissionreference="{d78946e f6-a265-04c0798a50dc}" workflowreference="ws824055" archivereference="as200" status="ok" timereceived=" :27:30" ornumber="923" orversion="2208" participant=" " completed="1" locked="1"> <Message> <MessageEntry type="received" logged=" t12:27:30" user="maestro">motatt av Altinn</MessageEntry> </Message> </DataUnitInReceipt </DataBatchInReceipt> Altinn Side 30 av 47