Felles

Funksjonalitet som er felles for alle eller flere av tjenestetypene.

På denne siden:

Her beskrives funksjonalitet som er felles for alle eller flere av tjenestetypene, innenfor hhv. tjenestespesifikasjon, utgavespesifikasjon og tjenesteinnhold.

Tjenestedefinering utføres fra tjenestens arbeidsflate, mens definering av utgave gjøres fra utgavens arbeidsflate.

Å definere tjenesten består i å utarbeide tjenestespesifikasjonen, som omfatter kun tjenesteparametere. Å definere utgaven består i å utarbeide utgavespesifikasjonen, som består av alle parametre som ikke er knyttet til eventuelt tjenesteinnhold. Eksempel på tjenesteinnhold er skjema som utvikles i InfoPath.

Tjenestespesifikasjonen vil være den samme for alle utgaver i gitt tjeneste, mens hver enkelt utgave kan ha forskjellige spesifikasjoner.

Tjenestespesifikasjon

Tjenestespesifikasjonen initieres allerede idet du velger å opprette en ny tjeneste, ved at siden Tjenesteparametre åpnes.

Tjenesteparametre

Når tjenesteparametrene er fylt ut, er tjenesten ferdig definert. Du kan senere komme til denne siden ved å klikke på Tjenesteparametere på arbeidsflaten for tjenesten. Et utsnitt fra skjermbildet av siden vises under.

Det som er verdt å merke seg, er at ekstern tjenestekode og tjenestetype ikke kan endres etter at det er valgt og lagret.

Følgende parametre kan defineres på tjenesteparametersiden:

Utgavespesifikasjon

Fra tjenestens arbeidsflate kan du opprette en utgave under tjenesten. Du kan senere komme til denne siden ved å klikke på Utgaveparametere på arbeidsflaten for tjenesteutgaven. Hvilke parametre som må angis for en tjenesteutgave, kommer an på hva slags tjenestetype som ble valgt for tjenesten. Oversikt over alle parametere gis i neste avsnitt.

I tillegg til utgaveparametrene kan du fra utgavearbeidsflaten navigere deg inn på andre parametersider for å definere utgaven. For alle tjenestetyper kan du i tillegg til utgaveparametrene velge å overstyre rettighetene til tjenesteutgaven. For å definere dette må du velge Overstyr rettigheter under området for Utgavespesifikasjon.

De andre parametrene som definerer utgaven, vil avhenge av type tjeneste.

Utgaveparametere og overstyr rettigheter er beskrevet i dette kapitlet, mens de parametersidene som er spesifikke for en gitt utgavetype, er beskrevet i kapitlet som omhandler den aktuelle typen.

Utgaveparametere

Utgaveparametrene brukes for å identifisere og konfigurere egenskaper ved utgaven. Parametrene er tilpasset den aktuelle tjenestetypen. Selve parametrene er listet midt på siden. Parametrene er gruppert etter type parameter og til venstre på siden fins en forklaring til parametrene.

Figur 25 – Utgaveparametere, innsendingstjeneste

Følgende parametre kan definers på utgaveparametersiden:

Rettighetskrav settes på Rolleadministrasjon-siden som lenkes fra startsiden og Overstyr rettigheter-siden som lenkes fra tjenesteutgavens arbeidsflate.

For hver utgave må man også angi hvilket sikkerhetsnivå som kreves for å åpne tjenesteutgaven i SBL. Sikkerhetsnivåene er fra 0 til 4 og hvert nivå kan ha en eller flere innloggingsmetoder. Disse vises i tabellen under:

Overstyr rettigheter

I TUL kan systemeier definere roller med tilhørende rettigheter, mens alle har tilgang til informasjon om hva som er definert. En rettighet gir sluttbruker tilgang til å utføre en bestemt operasjon på en bestemt ressurs for en bestemt avgiver – for eksempel å lese momsoppgavene i arkivet til virksomheten brukeren er ansatt i. Se Rolleadministrasjon for nærmere beskrivelse.

I definisjon av roller i TUL settes rettigheter på tjenestenivå. En utgave vil arve disse rettighets­kravene automatisk når den migreres til SBL. Dette betyr at når du lager en helt ny tjeneste, må du vurdere hvilke rolledefinisjoner som skal oppdateres for å gi tilgang til tjenesten. Tilsvarende, når du lager en ny utgave, må du vurdere om rolledefinisjonene på tjenestenivå er tilstrekkelige, eller om de bør justeres eller overstyres for akkurat denne utgaven. Du kan hente fram en oversikt over alle rettigheter til tjenesten fra tjeste­arbeidsflaten, se rettigheter fra tjenestearbeidsflaten

Roller som gir rettigheter til tjenesteeiers arkiv kan ikke overstyres. Dette er roller med rollekategori = tjenesteeier.

Endring av roller på tjenestenivå må man be systemeier utføre, mens overstyring for den enkelte utgave kan gjøres av tjenesteutvikler fra utgavens arbeidsflate.

Overstyring av rettigheter kan være aktuelt å bruke hvis en tjeneste har to utgaver som benyttes av forskjellige brukergrupper, f eks eBrev som kan benyttes av både virksomheter og privat person.

For samhandlingstjenester har du også muligheten til å gi roller tilgang til spesifikke rollestyrte dialogsider gjennom å benytte Overstyr rettigheter. Ved å gi en rolle tilgang til en spesifikk dialogside vil man kunne skape ulike arbeidsflater for ulike roller for samhandlingstjenesten.

I følgende tilfeller er det aktuelt å gå inn på siden Overstyr rettigheter:

• Rettigheter på tjenestenivå skal normalt gjelde, men det er spesielle behov knyttet til akkurat denne utgaven.
• Utgaven skal følge en prosessflyt med mer enn ett signeringstrinn.
• Samhandlingstjenesteutgaven har dialogsider som skal vises for bestemte roller.

Du kan overstyre rettigheter på utgave-, side- eller feltnivå; side- og feltnivå gjelder bare innsendingstjenester. For samhandlingstjenester kan du i tillegg overstyre på dialogsidenvå. Du velger først ressursnivå og deretter hvilke operasjoner som skal overstyres per rolle. Du kan definere flere overstyringer for hver utgave.

For å overstyre rettigheter som gjelder utgaven som helhet, velger du radioknappen Utgave/prosessflyt for innsendingstjeneste, Utgave for andre tjenestetyper, og trykker på knappen Legg til overstyring. Du vil da få opp en pop-up med en rettighetsmatrise*.* Her listes de roller som har rettigheter for valgt ressurs vertikalt. Horisontalt listes tilgjengelige operasjoner. Operasjonene som listes, vil avhenge av hvilken ressurs som er valgt. Hvis det for eksempel er en innsendingstjeneste med to signeringssteg, vil det være en kolonne for hvert signeringssteg.

Du har også muligheten til å liste alle roller, noe som er nødvendig for å tildele rettigheter til roller som ikke allerede har det på tjenestenivå. Nederst til venstre i pop-up-vinduet er det en sjekkboks, og ved å ta bort haken i denne vil listen utvides til å vise alle roller.

Du overstyrer rettighetene ved å legge til eller fjerne markeringer for hvilke operasjoner hver enkelt rolle skal kunne utføre. Deretter trykker du på OK­-knappen for å lagre og lukke pop-up-vinduet. Du vi se at det nederst på siden kommer et nytt innslag i listen over alle ressurser med overstyrte rettigheter.

For innsendingstjenester kan du i tillegg overstyre rettigheter for en enkelt side eller et enkelt felt. Du må da velge radioknappen Side/felt og deretter hvilken side og eventuelt hvilket felt det gjelder, før du klikker på knappen Legg til overstyring. Da kommer du til rettighets­matrisen og fortsetter som for overstyring på utgavenivå.

For samhandlingstjenester som har rollestyrte dialogsider, kan du gi tilgang til disse ved å velge radioknappen Dialogside og deretter velge aktuell dialogside. Bare dialogsider som er lagt til som ”rollekontrollert” på siden Tilstander, er tilgjengelig for slik overstyring. Marker valget i kolonnen Dialogside-tilgang for de rollene som skal få tilgang til siden. Også her har du mulighet til å liste alle roller, men det er uansett bare roller som har rettighet til selve tjenesteutgaven som vil kunne se tjenesten i sin meldingsboks. Merk at for en ny utgave opprettet ved å kopiere en eksisterende vil eventuelle overstyringer også bli kopiert.

Du kan senere endre eller slette overstyringene ved å trykke på Endre- eller Slett-lenkene som er knyttet til hvert enkelt innslag i listen med overstyringer.

For å overstyre rettigheter på felter som blir hentet fra sekundær datakilde vil dette kun fungere sammen med følgende URL:

http://mapperservices.altinn.no:87/ServiceEngine/FormsEngineFieldLevelDataSource.svc?wsdl

For mer informasjon om sekundær datakilde / kodelister.

Skriv inn URL som er oppgitt over for å angi web service lokasjon:

Trykk Neste.

Velg GetFieldAuthorization method og Neste

Du kan nå velge sample values. Velg “-1” i alle felter.

Velg bort Hent data automatisk når skjemaet åpnes check box. Klikk Finish.

Den sekundære datakilden kan ses i InfoPath skjema under Datakilder (Sekundær).

Legg merke til at navn med prefix “ns6” vil kunne variere fra skjema til skjema.

Den sekundære datakilden må nå legges inn i InfoPaths kodefil (FormCode.cs). Trykk Utvikler Innlastingshendelse i InfoPath.

Følgende kode må være lagt inn i FormEvents_Loading-metoden:

string FormID     = (FormState["FormID"] != null) ? FormState["FormID"].ToString() : string.Empty;
string UserID     = (FormState["UserID"] != null) ? FormState["UserID"].ToString() : string.Empty;
string ReporteeID = (FormState["ReporteeID"] != null) ? FormState["ReporteeID"].ToString() : string.Empty;

NamespaceManager.AddNamespace("namespaceprefix", "http://www.altinn.no/services/ServiceEngine/FormsEngine/2009/10"); // refer the figure below!!
NamespaceManager.AddNamespace("dfs", "http://schemas.microsoft.com/office/infopath/2003/dataFormSolution");

XPathNavigator xnav = this.DataSources["GetFieldAuthorization"].CreateNavigator();
XPathNavigator formid = xnav.SelectSingleNode("copy & paste the XPath of the formID from the GetFieldAuthorization secondary data source", NamespaceManager);
XPathNavigator userid = xnav.SelectSingleNode("copy & paste the XPath of the userID from the GetFieldAuthorization secondary data source", NamespaceManager);
XPathNavigator reporteeid= xnav.SelectSingleNode("copy & paste the XPath of the reporteeID from the GetFieldAuthorization secondary data source", NamespaceManager);

formid.SetValue(FormID);
userid.SetValue(UserID);
reporteeid.SetValue(ReporteeID);

this.DataSources["GetFieldAuthorization"].QueryConnection.Execute();

Legg merke til at XPath brukt i XPathNavigator fra koden over må hentes fra feltene i den sekundære datakilden som ble lagt inn i skjemaet.

Høyreklikk på de aktuelle feltene i InfoPath og velg kopier XPath for å finne korrekt XPath. Hvis den korrekte XPath ikke blir benyttet i koden vil det resultere i en “null reference” og en skjema exception vil bli kastet i SBL. Hvis koden over allerede finnes i skjemakoden bør denne koden sammenslåes med den eksisterende koden.

Følgende elementer i InfoPath støttes av overstyring av rettigheter i Altinn:

• Text Box
• Rich Text Box
• Combo Box
• List Box
• Check Box

Repeterende tabeller og seksjoner støttes ikke.

Tjenesteutgavens innhold

Tjenesteinnholdet består av den informasjonen som formidles mellom tjenesteeier og bruker. For de fleste tjenestetypene kan slikt innhold presenteres og eventuelt registreres gjennom et skjema som utvikles i InfoPath, som er et standard Microsoft Office-produkt. Et InfoPath-skjema representerer dermed tjenesteinnholdet og interaksjonen med sluttbruker i SBL. Det definerer utgavens ”brukergrensesnitt” og grafiske layout.

For innsendingstjenster og innsynstjenester er InfoPath-skjema en sentral og nødvendig del. For de andre tjenestetypene er andre innholdstyper sentrale, og disse beskrives under den enkelte tjenestetypen.

InfoPath-skjema i Altinn

Nedenfor følger en beskrivelse av prinsippene for håndtering av skjemaer i TUL. Mer informasjon som er rettet direkte mot hver enkelt tjenestetype, finnes i tjenestetype-kapitlene i underkapitler under ”Iinnhold”. Der refereres det også til vedlegg med detaljinformasjon rettet mot den enkelte tjenestetypen.

En generell brukerveiledning i InfoPath gis ikke i denne brukerveiledningen, og det henvises til Microsoft sin generelle brukerdokumentasjon på dette standardproduktet.

Skjemabibliotek, skjema og visning

Under området for Innholdsspesifikasjon på utgavens arbeidsflate kan du legge til et InfoPath-skjema og åpne og redigere skjemaet i Microsoft Office InfoPath.

Skjemaet lastes opp og vedlikeholdes i skjemabiblioteket på arbeidsflaten, som vist i Figur 1. Dette er et standard SharePoint dokumentbibliotek, men godtar kun InfoPath-filer(.xsn). Sjekk ut/sjekk inn, versjonerings- og dokumentbibliotekfunksjonalitet er tilgjengelig. Se detaljer om hvordan sjekke ut og inn.

Et skjema kan om ønskelig bestå av mange visninger som man kan navigere mellom under utfylling i SBL, eller benyttes for utskrift eller kvittering. En visning er synonymt med side. Det er verdt å merke seg at navnene og rekkefølgen som er på visningene inne i InfoPath, er irrelevant. Hvordan de ulike sidene skal benyttes, angis på utgavens arbeidsflate under Sideegenskaper.

Når man utvikler skjema for en utgave, gjør man det for utgavens hovedspråk. Som nevnt tidligere angis hovedspråket blant utgaveparametrene. For at man skal kunne ha skjema på flere språk, er det flere ting som er viktig. Alle språkavhengige elementer i skjemaet (ledetekster, overskrifter og lignende) må defineres som uttrykksfelter (expression boxes) i InfoPath, slik at de skal kunne oversettes i oversettermodulen i TUL. Hvordan du setter opp uttrykksfelter er beskrevet i Vedlegg A: Skjemautvikling i InfoPath. Tekster som «flyter fritt» utenfor uttrykksbokser vil ikke la seg oversette. Det er da også viktig å merke seg at tekster knyttet til radioknapper og sjekkbokser, samt tabelloverskrifter etc. må ligge i uttrykksbokser.

Skjemaet selv, og de ulike komponentene skjemaet består av, bør navngis i henhold til gjeldende navnestandard, se Vedlegg E: InfoPath navnestandard.

Når skjemaet er ferdig og lagret, laster du det opp på utgavens arbeidsflate. Klikk på Last opp nytt dokument under området for Innholdsspesifikasjon, og velg den filen du ønsker å benytte.

Dersom det oppstår en feil i forbindelse med opplasting, så vil utgaven bli merket med at den har en skjemafeil. Da vil du se en advarsel i rød tekst på utgavearbeidsflaten. En utgave med en slik feil vil kunne få problem med funksjonalitet som baserer seg på skjema. Dersom dette har skjedd må du slette skjemaet og laste opp på nytt. Meldingen vil forsvinne når du sletter skjemaet. Dukker meldingen opp på nytt etter ny opplasting, bør du ta kontakt med Altinn support.

Sjekke ut, editere og sjekke inn InfoPath-skjema

For å kunne editere InfoPath-skjemaet, er det viktig at du sjekker ut først. Hvis ikke vil du få en melding om at skjemaet er i bruk. Når du har sjekket ut, trenger du bare å klikke på skjemaets navn for å editere. Det som skjer nå er at skjemaet åpnes i design-modus, men du kan bli bedt om å taste inn brukernavn og passord. Dette er helt normalt og skyldes at InfoPath ikke deler sikkerhetsinformasjon med TUL SharePoint.

Når skjemaet så åpnes, er det i read-only modus. Derfor må du lagre til TULShare før du begynner å editere. Grunnen til at du bør gjøre dette er at da har du en sikkerhetskopi på lokal disk. Velg derfor å lagre.

Når alle endringer er gjort, så kan du lagre tilbake til TUL SharePoint. Velg Publiser fra Fil-meny. Så velger du Nettverksplassering, som vist i figuren under.

Trykk Neste. Så skal du angi hvor du vil publisere skjemaet. Det vil være tilbake til TUL og skjemabiblioteket i Innholdsspesifikasjonen.

Det som typisk vil stå i øverste feltet er:

http://tul.altinn.basefarm.net/sites/<tjenesteeier>/<tj.kortnavn\>/<tj.utg.kortnavn>/FormLibrary/Forms/<skjemanavn>.xsn

F.eks.

http://tul.altinn.basefarm.net/sites/skd/RF1113/RF11132009/FormLibrary/Forms/RF1113.xsn

En måtene å finner fram til denne adressen på, er å velge Vis egenskaper og så høyreklikke på skjemanavnet velge Kopier snarvei. Dette limer du så inn igjen i InfoPath. Merk at dette er noe du kun trenger å gjøre en gang for hvert skjema/utgave. Klikk Neste og verifiser at samme bane og filnavn som i forrige skjermbilde står også her. Klikk Neste, og så Publisér. Nå lagres skjema tilbake i TUL og du kan klikke Lukk når dette er fullført.

Det er viktig å påpeke at valget Rediger i Microsoft InfoPath, som finnes i kontekstmenyen til skjemaet, ikke skal benyttes. Dette valget støtter ikke åpning i designmodus eller SharePoint sin utsjekk/innsjekk-funksjonalitet.

XSD-egenskaper

Informasjon om dataformat (tidligere meldingsformat eller “spesifikasjon”) angis per InfoPath-skjema etter at det lastes opp. Du kan senere endre informasjonen ved å velge XSD-egenskaper fra kontekstmenyen til hvert enkelt skjema.

Dette er informasjon som benyttes for skjemahåndtering i SBL for å identifisere dataformatet entydig på tvers av utgaver og versjoner. Informasjonen brukes også til å identifisere felles datakilde i skjemasett.

I tidligere versjoner av Altinn benyttet man alltid dataformat fra Oppgaveregisteret. Nå er løsningen gjort mer fleksibel, slik at dataformater fra flere leverandører kan benyttes. Derfor har feltene fått mer generelle navn enn tidligere.

XSD-egenskapene består av XSD-leverandør, XSD-id og XSD-versjon. Til sammen identifiserer disse tre parametrene unikt XSD’en som er benyttet som hoveddatakilde i InfoPath, mao. dataformatet som skjemadata lagres på. Alle parametrene er obligatorisk for migrering av skjema. Hvis XSD-leverandør er Oppgaveregisteret eller SERES, vil disse parametrene populeres automatisk når skjema lastes opp.

Tilleggsegenskaper for skjema

Når et skjema er ferdigutviklet i InfoPath, kan det defineres tilleggsegenskaper i TUL for å gi tjenesten ønskede egenskaper. Tilleggsegenskapene som kan legges inn, er avhengig av tjenestetypen. Sideegenskaper og innholdsreferanser er relevant for flere tjenestetyper og beskrives i dette kapitlet. Øvrige egenskaper beskrives under den enkelte tjenestetypen.

Sideegenskaper

Under Sideegenskaper kan du tildele egenskaper til skjemaets visninger fra InfoPath. Egenskapene bestemmer hvordan en visning fra InfoPath skal benyttes i sluttbrukerløsningen. Dette er relevant for innsendings- og innsynstjenester.

De neste seksjonene angir hva som må angis for hver visning. For at en migrering av utgaven til SBL skal være vellykket, må sideegenskaper være komplett utfylt.

Sidenavn i ELMER-skjema

Sidenavn gjelder innsendingstjenester der man som utgaveparameter har valgt visning i henhold til ELMER-retningslinjene. Navnet du angir skal være gjeldene for utgavens hovedspråk. Navnet kan inneholde norske bokstaver, og vil kunne oversettes i språkverktøyet. Navnet på siden vises i venstre kant av skjermbildet under utfylling i SBL, også kalt navigasjonsmenyen i SBL. Navnet vil deles ved mellomrom hvis det er langt, men det er verdt å tenke på at navnene ikke bør inneholde lange ord uten mellomrom. Hvor mange bokstaver et ord kan ha, vil avhenge av oppløsningen sluttbruker har på sin skjerm under utfylling. Det bør dog tae hensyn til at denne kan være så liten som 1024x768.

Siderekkefølge i ELMER-skjema

Rekkefølge gjelder innsendingstjenester der man som utgaveparameter har valgt visning i henhold til ELMER-retningslinjene. I InfoPath er det ikke mulig å definere rekkefølge/sekvens på sidene, men dette er nødvendig for å styre sluttbrukers utfylling. Det er derfor i sideegenskaper mulig å angi et unikt nummer for en visning, hvor prinsippet med stigende rekkefølge vil være gjeldene. Det vil ikke være mulig å velge samme nummer på to sider da det nummeret man velger vil byttes med den siden som allerede har gjeldene nummer. Ved åpning av sideegenskaper vil visningene være listet i rekkefølgene de befinner seg i skjemaet. Dette medfører at en visning tiltenkt utskrift eller kvittering kan ligge i listen før andre visninger tiltenkt utfylling. Det er da viktig at sekvens/rekkefølge tar hensyn til dette.

Det er derimot viktig at siden som er satt til å være først i TUL, i InfoPath har egenskapen ”Angi som standardvisning” avkrysset. Dette gjøres på egenskaper for gitt view i InfoPath.

Visningstype

InfoPath har mulighet for å angi utskriftversjon for et skjema, men denne funksjonaliteten skal ikke benyttes, da det setter begrensninger for PDF-generering av visninger.

Du kan velge mellom følgende visningstyper:

• Web: Dette vil være typen de fleste visninger har. Skjemaside skal vises til brukeren i SBL, for utfylling av en innsendingstjeneste, og for navigasjon og presentasjon av data i en innsynstjeneste. Denne typen blir også automatisk gjeldende for skjemaet i en meldingstjeneste.

• Utskrift: Angir at denne visningen skal benyttes ved generering av utskriftsformat i sluttbrukerløsningen. Dersom man ønsker utskrift basert på webvisning av skjema, skal man opprette så mange visninger som det er sider i skjema og kopiere og lime inn innholdet fra hver side til tilhørende visning for utskrift. Utskrift-visningene kan settes til å være read-only ved å klikke på Fil, så Sideegenskaper og krysse av for Read-only. Der kan man også sette formatet på side som skal skrives ut, samt at man kan se forhåndsvisning for utskriftsversjon.

• Kvitteringssammendrag (gjelder innsendingstjeneste): Vises til sluttbruker etter innsending. Kvitteringssammendrag opprettes ved at man lager ekstra visning og kaller den f.eks for Kvittering, definerer layout og legger deretter på de feltene som man ønsker å ha på kvitteringssammendraget. Man kan definere hjelpefelter og legge dem på utskriftsvisninger og på kvitteringen.

• Signering: Angir at denne visningen skal brukes som signeringsversjon. Hvis signeringsversjon er definert ,er det denne sluttbruker signerer for en innsendingstjeneste, og det er denne Altinn signerer ved arkivering av en innsynstjeneste. Denne visningstypen er tenkt brukt hvis tjenesteeier vil ekskludere informasjon ved signering.

• Sensitive opplysninger/SPO (gjelder innsendingstjeneste): Du velger denne visningstypen for en skjemaside som inneholder SPO. Alle feltene på denne siden vil krypteres ende-til-ende. Sluttbruker vil få informasjon om dette og mulighet for å låse opp med passord, hvis dette er satt som utgaveparameter. Merk at skjemasiden da bare må inneholde tekstbokser, ikke for eksempel nedtrekkslister og sjekkbokser.

• Signeringssammendrag (gjelder innsendingstjeneste): Vises til sluttbruker under signering. Signeringssammendrag opprettes ved at man lager ekstra visning og kaller den f.eks for Sammendrag, definerer layout og legger deretter på de feltene som man ønsker å ha på signeringssammendraget.

• Betalingssammendrag (gjelder innsendingstjeneste): Vises til sluttbruker i betalingssteget før bruker blir sendt videre til betalingsleverandøren. Dette kan brukes til å gi detaljerte opplysninger om hva betaling gjelder og/eller hvordan beløpet er regnet ut. Denne visningstypen vil bare bli vist på betalingssteget. Vil du at disse opplysningen skal vises på kvitteringen etter innsending, så må du legge det inn på kvitteringssammendrag. Vil du vise det begge steder må du ha både betalingssammendrag og kvitteringssammendrag. Betalings­sammendrag opprettes ved at man lager ekstra visning og kaller den for eksempel for Betalingssammendrag, definerer layout og deretter legger på de feltene som man ønsker å ha med.

For å gjøre det enklere å opprettholde riktig rekkefølge og sidetype i TUL så bør sidene i InfoPath gis navn som klart indikerer hva de skal brukes til: Web 1, Web 2 osv, Utskrift 1, Utskrift 2 osv og Kvittering.

Figuren nedenfor viser skjermbilde av siden for sideegenskaper. For innsynstjeneste vil bare Visningstype være tilgjengelig.

Innholdsreferanser

Innholdsreferanser er en side i TUL der du kan definere referanser til utvalgte felter i InfoPath-skjema, for at det skal knyttes spesiell funksjonalitet til disse i SBL. Presentasjonsfelt brukes for innsendings- og innsynstjeneste, mens geografisk tilhørighet brukes bare for innsendingstjenester. Siden het tidligere Presentasjonsfelt.

Presentasjonsfelt

Presentasjonsfelt brukes i SBL for å skille flere innsendinger av samme utgave fra hverandre i meldingsboksen og i arkivet. Måten dette gjøres på er å vise det utfyller har skrevet i gitt(e) felt sammen med navnet på utgaven. Presentasjonsfeltene listes etter utgavenavnet og henter verdier som brukeren har oppgitt under utfylling av skjemaet. Naturlige presentasjonsfelt kan være f.eks. organisasjonsnummer, navn eller termin.

I TUL velges presentasjonsfelt ved først å velge side. Rekkefølgen på de presenterende feltene kan endres. Det er mulig å oppgi maksimalt seks innholdsreferanser. Rekkefølgen vil være gjeldende i SBL hvor innholdsreferansen med ID 1 vil komme først etter utgavenavn, så ID 2 osv.

Definerte innholdsreferanser fjernes ved å klikke på Fjern.

Eksempel:

Tjenesten RR-0002 Årsregnskap for små, store og øvrige selskap kan benytte feltet Organisasjonsnavn som innholdsreferanser. I sluttbrukerløsningen vil ulike innsendinger av denne tjenesten bli listet med tjenestenavnet først og verdien i feltet Organisasjonsnavn bak, eksempelvis:

RR-0002 Årsregnskap for små, store og øvrige selskap, Nordmanns advokatselskap

RR-0002 Årsregnskap for små, store og øvrige selskap, Hansens Bygg og Håndverksselskap

Geografisk tilhørighet

Det er mulig å definere roller i Altinn som gir tilgang til skjema som «tilhører» et bestemt geografisk område. Dette gjelder for tjenesteeiers arkiv. Tilhørighet bestemmes ved innholdet i utvalgte felt i skjema.

Du kan spesifisere hvilke felt i skjema som inneholder geografisk informasjon ved å velge visning og felt for hhv. fylke, kommune og bydel. Det er mulig å angi kun fylke, fylke og kommune, eller alle tre. Det kommer an på hvor nyanserte roller det er behov for. I de fleste tilfeller vil du ikke definere geografiske referanser i det hele tatt.

For at geografiske referanser skal fungere i SBL, må innholdet i feltene være format på det standardiserte formatet “NO-KKKK nnnn”:

• Fylke: KK
• Kommune: KK
• Bydel: nnnn

Dette formatet bygges på eksisterende standard for fylke, kommunenummer og bydel. Bruk av NO-KK for fylke er en ISO-standard (3166), mens kommunenummer består av 2 ekstra siffer.

Felter som overstyres av sluttbrukersystem ved komplett innsending

Ved komplett innsending fra sluttbrukersystem skal følgende tre prinsipper gjelde:

1. Altinn skal ikke endre på felter i skjemasettet som blir sendt inn av SBS.
2. Altinn kan tilføye kalkulerte felter for felter som er unnlatt å sende inn.
3. Skjemasett med feil skal stoppes av Altinn og innsending skal feile.

Tjenesteeier har mulighet til å fravike det tredje prinsippet ved å definere overstyrbare felter i TUL. For felter som spesifiseres her, vil verdi fra sluttbrukersystem aksepteres også ved avvik fra validering/kalkulering i Infopath. Avvik som normalt gir valideringsfeil, gir i stedet kun advarsal tilbake til sluttbrukersystem.

Hvis “kun XSD validering” er angitt under XSD-egenskaper, er det ikke nødvendig å spesifisere felter her. Overstyrte felter påvirker ikke utfylling i SBL, uavhengig om det er definert her eller under «XSD-egenskaper».

Hvis skjema har et attributt med navn SentFromEUS i namespacet my (@my:SentFromEUS), så vil det bli lagt inn verdien true i dette feltet hvis skjema er sendt fra sluttbrukersystem. Denne attributten kan benyttes til å ha ulik validering/kalkulering for innsending fra SBS og fra portal selv om det kanskje ikke er ønskelig vedlikeholdsmessig.

Trekk ut data fra innsendelse

Tjenesteeier har mulighet til å definere metadatafelter som kan brukes til å styre videre behandling av skjema etter de er mottatt fra Altinn. Metadatafeltene legges i en liste utenfor skjema-XMLen og kan så brukes direkte uten at man trenger å pakke ut og tolke hele skjema-XML-en for å finne den samme informasjonen. Metadatafeltene returneres som ShipmentMetadata av webservicemetoden GetDownloadQueueItems, og utnyttelse av definerte metadatafelt forutsetter derfor at tjenesteeier har valgt “Hente ved bruk av webservice (DownloadQueue)” under seksjonsoverskriften “Oversending”.

Tjenesteeier kan spesifisere hvilke data i skjema som skal trekkes ut ved å velge visning, felt og skrive inn et nøkkelnavn (metadatafeltnavn) som kan brukes til uthentelse senere. Når tjenesteeier har skrevet inn et nøkkelnavn og klikker seg ut fra feltet vil en ny rad dukke opp hvis skjemaside og felt er valgt. Hvor mange rader som er maksimalt mulig å oppgi, er spesifisert i beskrivelsen av feltet rett under seksjonsoverskriften “Trekk ut data fra innsendelse”

Definerte metadatafelter fjernes ved å klikke på Fjern.