Underskjema som konsept avvikles, og finnes ikke i Altinn 3. Vår løsning er å etablere strukturerte vedlegg som oppfører seg tilnærmet lik de tidligere underskjemaene. For enkelthets skyld omtaler vi dem fremdeles som underskjema.

Den største forskjellen fra bruk av underskjemaer i Altinn II til Altinn 3, er at de i Altinn 3 kun kan brukes i forbindelse med en annen innsending – ikke alene.

I dag er følgende underskjema i bruk i Altinn 3:

• Gjennomføringsplan (v6)

• Dispensasjonssøknad (v1)

• Gjenpart av nabovarsel (v5)

Underskjemaene har egne valideringsregler som ikke er bakt inn i valideringsreglene for de overordnede tjenestene (“hovedskjema” i Altinn II). Disse har egne dokumentasjonssider, og det vil være lenket mellom sidene når det er relevant.

Altinn 3 krever at det kun er strukturerte data (xml) i datatyper som er satt opp som underskjema. Vedlegg som kan lastes opp enten som pdf eller som underskjema må derfor endres. Dette betyr at vi må innføre en splitting av datatyper – for eksempel for vedleggstypen gjennomfoeringsplan – slik at vi ender opp med:

• dataType gjennomfoeringsplanData, med kun xml som mulig contentType. Det er denne som brukes til underskjema-funksjonaliteten, og ved bruk av denne genereres det en pdf basert på xml-en.

• dataType gjennomfoeringsplan, med flere mulige ustrukturerte contentTypes (pdf, jpg, etc). Denne brukes i de tilfellene der søker laster opp en fil som vedlegg, og underskjema ikke er benyttet.

Splittingen av datatyper er en rendyrking av funksjonaliteten som ligger i Altinn 3. Det løser med et sentralt grep problemstillinger som hadde krevet flere mindre tilpasninger og gir et godt grunnlag for fremtidig utvikling.

• Sjekking av filtype ved generering av pdf

• Skjuling av tekniske filer i Altinn-innboks og -arkiv

• Muliggjør innsending av ustrukturerte vedlegg som et alternativ til bruk av strukturerte data i underskjemaet

Underskjema vil, på lik linje med andre skjema, utvikle seg og endres over tid. Dette må håndteres av FtPB økosystemet. Man kan kategorisere endringer slik:

1. Minor changes

2. Breaking changes

Dette er endringer som er av en slik art at data og funksjonalitet blir ivaretatt med eksisterende løsning. Dette gjelder typisk utvidelser av funksjonalitet. Et eksempel kan være behov for et nytt felt. Så lenge dette feltet er valgfritt, vil eksisterende data være kompatiblet og man kan oppdatere og bruke samme dataelement.

For underskjema vil en breaking change være endring av eksisterene struktur eller felt. I disse tilfeller må man versjonere skjema for å unngå at eksisterende funksjonalitet i økosystemet fortsetter å fungere.

Versjonering vil komme tydelig frem i navnet på dataelementet.

Strukturen i navnet er: {dataelement navn}DataV{versjonsnummer}

Eksempel: GjennomfoeringsplanDataV7