Filematch Foretak Vask og vedlikehold

Versjon: 1.0 Dato: 31.05.12 evry.com Tjenestebeskrivelse Filematch Foretak Vask og vedlikehold

Revisjonshistorie Revisjon nr. Revisjonsdato Endringer Revidert av 0 31.05.12 Konvertert til EVRY-mal Tove Reitan Side 2/22

Innhold 1 Generell beskrivelse av tjenesten 4 1.1 EVRY er Distributør av Enhet- og foretaksregisteret 4 2 Oversikt over tjenesten/ løsningsskisse 5 2.1 Igangsetting: Start med initiell vask! 6 2.2 Løpende behandling av tilgang/ avgang 7 2.2.1 Inn/ utmelding med batch/ filbasert prosess 7 2.2.2 Inn/ utmelding med online integrert prosess 8 2.3 Periodisk vedlikehold av dataendringer 9 3 Grensesnittbeskrivelse 10 3.1 Input til vask 10 3.2 Retur fra vask og periodisk vedlikehold 11 3.2.1 Standard returfil 1 12 3.2.2 Standard returfil 2 14 3.2.3 Feilfil fra vask 18 3.2.4 Antallsoversikt fra vask 18 3.2.5 Header og Trailer ved periodisk vedlikehold 20 3.2.6 Inn- og utmelding til vedlikehold 21 4 Endringslogg 22 Side 3/22

1 Generell beskrivelse av tjenesten Filematch Foretak er en tjeneste som hjelper deg med å holde ditt foretakregister à jour over tid. Basert på Enhets- og foretaksregisteret kan man få oppdatert egne kunderegistre. Registereier er Brønnøysundregistrene. Tjenesten består av 2 sentrale deler: Vask er løsning for identifisering og oppdatering av opplysninger om foretak i kundens system. Vedlikehold er løsning for å vedlikeholde identifiserte foretak i brukerens system etter hvert som data om objektene endres i Enhets- og foretaksregisteret Tjenesten forutsetter at kunden må identifisere de foretaksobjekter det skal gjøres vask og vedlikehold av. Identifisering gjøres på organisasjonsnummer Ved å ta i bruk mulighetene i tjenesten vil man både kunne spare unødvendige arbeidsoppgaver, samt oppnå bedre funksjonalitet og kvalitet i egen løsning. Tjenesten støtter funksjonalitet for å: holde ditt foretakregister oppdatert til enhver tid sikre at post kommer frem til rett adresse og riktig foretak redusere returpost automatisere oppdatering av egne foretakdata automatisere bedriftsinterne prosesser, eks: Utsendelse av brev til kunder som flytter Oppgjør av konti i forbindelse med konkurs, avvikling o.l Overføre kundeoppfølging til annen avdeling ved flyttemelding m.fl. Denne dokumentasjonen beskriver detaljene i prosessen med vask og vedlikehold. 1.1 EVRY er Distributør av Enhet- og foretaksregisteret Gjennom avtale med Brønnøysundregistrene er EVRY distributør av Enhet- og foretaksregisteret. Vår oppgave er å gi enheter innen både offentlig og privat virksomhet tilgang til data i Enhet- og foretaksregisteret. EVRY kan også gi tilgang til andre tjenester fra Enhet- og foretaksregisteret, samt andre sentrale informasjonsdatabaser. Dette kan være: Online skjermbaserte oppslag Online integrerte oppslag basert på programgrensesnitt Datauttrekk Se kontaktinformasjon i kapittel 4. Side 4/22

2 Oversikt over tjenesten/ løsningsskisse For å skape et bilde av hvordan Filematch kan etableres viser følgende eksempel en mulig løsning. Løsningen baserer seg på "full" Filematch, dvs. både initiell vask, behandling av tilgang/avgang og vedlikehold over tid. "Porteføljen" benyttes som betegnelse for det foretakregister man ønsker å vaske og vedlikeholde. Prosessen består av følgende trinn: 1. Igangsetting. Initiell vask av hele porteføljen med innmelding til vedlikehold. Prosessen sørger for at kundens portefølje blir oppdatert med data fra Enhet- og foretaksregisteret. I tillegg utveksles nøkler som er grunnlag for å vedlikeholde identifiserte objekter over tid. 2. Løpende behandling av tilgang/ avgang i porteføljen (inn- og utmelding). Vedlikehold (tilgang/avgang) av kundens portefølje som vedlikeholdes over tid, og tilføring av initielle data på nye objekter. Dette kan gjøres på 2 måter; Det første alternativet er basert på batch prosess og datafiler, mens det andre er basert på online oppslag via program-til-program-integrasjon (PTP-integrasjon). 3. Periodisk vedlikehold av dataendringer i porteføljen. Dette omfatter vedlikehold av data i kundens portefølje over tid. Vedlikeholdsintervall kan være daglig, ukentlig, 14-daglig, månedlig eller kvartalsvis. Side 5/22

2.1 Igangsetting: Start med initiell vask! For å komme i gang starter man gjerne med vask (oppdatering) av hele registeret slik at man på starttidspunktet er à jour med data fra Enhets-og foretaksregisteret. Dette kan beskrives med følgende figur: Kunde EVRY Uttrekk av data Vask forbehandling 1 2 Vaskemotor (identifisering) Kunde- Vaskeregister database 3 Oppdatering av register 5 Vask etterbehandling 4 Enhet- og foretaksregiste EFR Historikk Kunde DB (kopi) 1. Kunden laster ned sitt foretakregister på datafil og sender det til EVRY på CD/DVD, vedlegg til e-mail eller via SFTP. 2. Porteføljen mottas av EVRY, leses inn og kjøres igjennom forbehandling til vask. Dette er i korte trekk en formattering, kontroll og analyse av data som skal vaskes. 3. Når porteføljen er klargjort for vask, gjennomføres vask for identifisering av objektene i filen. Identifiseringen gjøres på organisasjonsnummer. De objekter som blir identifisert tilføres forslag til treff. 4. Etter at vask er gjennomført foretas etterbehandling. Data tilføres de objekter som fant treff, formatteres til retur-format og legges klar til filforsendelse. Antall treff/ ikke treff loggføres og statistikk produseres. Identifiserte foretak meldes inn til vedlikehold i en egen vedlikeholds-database. Av data fra kunden trenger vi kun å ta vare på unik id som er grunnlag for identifisering når data skal ajourføres senere i tid. 5. Den vaskede filen returneres tilbake til kunde på CD/DVD, vedlegg til e-mail eller via SFTP, og kunden mottar returfil og oppdaterer eget register med aktuelle data. Side 6/22

2.2 Løpende behandling av tilgang/ avgang Kundens register vil (sannsynligvis) fortløpende endre innhold. Det vil komme til og falle fra objekter over tid. Det finnes alternative måter å behandle tilgang/ avgang i kundens portefølje: 1. Inn/ utmelding med batch/ filbasert prosess. 2. Inn/ utmelding med online prosess. For innmeldinger vil det være behov for å vaske/ oppdatere data fra det register man skal ha et løpende ajourhold fra. Dette for å sikre at man er ajour med kilderegisteret fra det tidspunkt man starter ajourhold. 2.2.1 Inn/ utmelding med batch/ filbasert prosess Kunde EVRY Uttrekk av data Vask forbehandling 1 2 Kunde- SFTP 1b Vaskemotor (identifisering) Vaskeregister database 3 Oppdatering av register 5 Utmelding Vask etterbehandl. 4 Enhets- og foretaksreg. EFR Historikk Kunde DB (kopi) Periodisk vask av nye kunder har nesten identisk behandling som initiell vask av hele porteføljen. Hovedforskjellen ligger i at antallet til vask (sannsynligvis) er betydelig mindre enn antallet i den initielle vasken. Automatisert løsning med bruk av f.eks. FTP til å overføre data til og fra EVRY kan være å foretrekke. En annen forskjell ligger også i utmelding av objekter fra vedlikehold. Disse blir ikke vasket, men kun tatt med videre for utmelding fra vedlikeholdsporteføljen (se pkt. 2b i figuren). Side 7/22

2.2.2 Inn/ utmelding med online integrert prosess EVRY har etablert et online integrasjonsgrensesnitt som gir kunden mulighet til å etablere rutiner for både oppslag mot Enhet- og foretaksregisteret (og andre registre), samt inn/ utmelding av vedlikeholdsporteføljen. Løsningen gir kunden mulighet til å gjøre denne operasjonen samtidig som brukeren foretar behandling av tilgang/ avgang i sitt eget saksbehandlersystem. Kunde EVRY Kundedatabase 3 Oppslag med inn-/utmelding 1 2 Vaskemotor (identifisering) Enhets- og 6 5 foretaksreg. Inn-/utmelding av objekter 4 Kunde DB (kopi) 1. Under sin saksbehandling av tilgang/ avgang kan brukeren via det online-baserte integrasjonsgrensesnittet etablere automatikk i løsningen for tilføring/ oppdatering av grunninformasjon fra EVRY. 2. Forespørsel om data, samt inn-/utmelding til ajourhold sendes som en transaksjon til EVRY Online Integrasjonserver. 3. Objektet identifiseres med Enhet- og foretaksregisteret og eventuelle andre aktuelle kilderegistere. 4. Vedlikehold (inn/utmelding) gjøres mot kundeobjektdatabasen. 5. Data og statusinformasjon returneres på et feltbasert format (f,eks. XML). 6. Kunden oppdaterer sitt eget register og viser data på skjerm for brukeren i eget saksbehandlersystem. Ta kontakt med EVRY for nærmere informasjon om integrasjonsgrensesnittene. Vi har utarbeidet integrasjonspakker som skal bidra til å forenkle arbeidet med å etablere integrasjon inn i kundens saksbehandlersystem. Side 8/22

2.3 Periodisk vedlikehold av dataendringer For å kunne vedlikeholde opplysningene over tid må man sørge for å få tilført endringer på objektene i kundens portefølje. Det periodiske vedlikeholdet produserer endringstranser for oppdatering av kundens eget kunde-, klient- eller medlemsregister. Dette kan beskrives med følgende figur: EVRY Kunde Kunde DB (kopi) 1 DSF Endringer 2 Kundedatabase Vedlikehold Enhets- og foretaksreg. 3 EFR Oppdatering av register 5 SFTP 4 Vedlikehold etterbehandling Historikk 1. EVRY mottar daglige endringer for oppdatering av Enhet- og foretaksregisteret (og andre registre). 2. Periodisk, f.eks. ukentlig kontrolleres kundens portefølje for endringer. 3. Ved endring tilføres aktuelle endrede data siden forrige vedlikehold. Endringstranser lages. 4. Endringstransene returneres til kunden på fil. 5. Kunden oppdaterer sitt register med endringer, og iverksetter eventuelle interne prosesser ifbm. med endringen. Side 9/22

3 Grensesnittbeskrivelse 3.1 Input til vask Mottaksrutinene for vask er fleksible. Før data vaskes behandles de i rutiner som preparerer dataene slik at de blir vaskbare. Dette omfatter bl.a. formatkonvertering, feltidentifisering, soundex(lydkode)-generering og rensing av elementer som vil kunne bidra til å øke treffandelen. Standard mottaksformat er basert på txt-format (eller tilsvarende), med faste felt- og recordlengder. Vi kan motta data på ASCII, ANSI og EBCDIC tegnsett. Feltene kan inneholde både små og stor bokstaver. Vi kan også motta filer på andre formater mot et tillegg i pris for å konvertere til vaskeformatet. Dette kan eksempelvis være filer med variabel felt- og recordlengde med ulike separatorer mellom felter og records. Excel-filer er et annet eksempel. Normalt tar vi betalt på timebasis for å gjøre formatkonverteringer. Standard recordformat for input til vask er følgende: Feltnavn Start Type/lengde Beskrivelse FIL-ID 1 A/16 Fritt valgt kort beskrivelse av kjøring. REC-ID 17 A/3 FFI KUNDE 20 A/6 Gyldig kundenr. AVDELING 26 A/6 Utfylles ved eventuelt ønske om å skille Kundens forskjellige kjøringer fra hverandre i forbindelse med periodisk vedlikehold. Benyttes vanligvis ikke ved ordinær vask uten innmelding til vedlikehold. KUNDEREF 32 A/16 Kundens kundenr for objektet. ORGNR 48 A/9 Organisasjonsnr i henhold til Br.sund. REDNAVN 57 A/36 Redigert navn. Utfylles dersom en ønsker sammenligning av soundex er. OFFNAVN 93 A/35 Offisielt navn. Fylles ut dersom en ønsker sammenligning av navne-soundex er. FADRESSE 128 A/35 Forretningsadresse. FPOSTNR 163 A/9 Forretnings-postnr PADRESSE 172 A/35 Postadresse PPOSTNR 207 A/9 Post-postnr SIKKER-UNIK-TREFF 216 A/2 Ikke i bruk AJH-INDIKATOR 218 A/1 J = objekt innmeldes til ajourhold. Ellers ingen innmelding. Side 10/22

3.2 Retur fra vask og periodisk vedlikehold Fra vask kan det leveres flere type returfiler: Standard returfil 1: Inneholder inputrecord og retur-record med treffkoder på alle forekomster i inputfilen. Standard returfil 2: Består kun av identifiserte orgnr påført informasjon fra Enhetsog foretaksregisteret i henhold til kundens porteflje. Feilfil: Inneholder inputrecord med indikatorer for type feil ved vask. Antall: Inneholder én record med antallsoversikt fra vask. Hvis ikke annet er avtalt leveres kun Standard returfil 2 etter vask. Ved periodisk vedlikehold leveres kun Standard returfil 2 Returfilen er sekvensiell, og de første 31 posisjonene er lik pr. rekord, bortsett fra utsnittskode som forteller hvilke utsnitt rekorden gjelder. Side 11/22

3.2.1 Standard returfil 1 Returfilen er sekvensiell, og de første 50 posisjonene består av HODE som beskrevet under. 3.2.1.1 Hode pr. record Feltnavn Start Type/lengde Forklaring FIL-ID 1 A/16 Fritekst som identifiserer kjøring. REC-ID 17 A/3 ST1 PRODUKT 20 A/4 GRUI KUNDEREF 24 A/16 Kundereferanse hentet fra kundens input-fil. TREFFNIVAA 40 A/2 IN = input-record Retur-records. 01 = unikt treff 97 = Kun tilgjengelig for off. myndighet. 99 = ikke-treff. Ved ikke-treff kommer teksten "### INGEN TREFF I DATABASE ###" i feltet REDNAVN EL1-LIK-REDNAVN 42 A/1 Brukes ikke pr i dag. Fylles kun ut for retur-records. J = likhet i soundex mellom 1. element i inngitt navn og 1. element i foretakets redigerte navn (søkenavn). N = manglende likhet. EL2-LIK-REDNAVN 43 A/1 Brukes ikke pr i dag. Fylles kun ut for retur-records. J = likhet i soundex mellom 2. element i inngitt navn og 2. element i foretakets redigerte navn (søkenavn). N = manglende likhet. EL1-LIK-OFFNAVN 44 A/1 Fylles kun ut for retur-records. J = likhet i soundex mellom 1. element i inngitt navn og 1. element i foretakets offentlige navn. N = manglende likhet. EL2-LIK-OFFNAVN 45 A/1 Brukes ikke pr i dag. Fylles kun ut for retur-records. J = likhet i soundex mellom 2. element i inngitt navn og 2. element i foretakets offentlige navn. N = manglende likhet. FILLER 46 A/4 Blank UNIK-TREFF 50 A/1 Brukes ikke pr i dag. Side 12/22

3.2.1.2 GRUI-informasjon Feltnavn Start Type/ lengde Forklaring Hode 1 A/50 ORGNR 51 A/9 Foretakets organisasjonsnr. REDNAVN 60 A/36 Foretakets redigerte navn (søkenavn). Hvis treffkode=99 kommer følgende tekst: "### INGEN TREFF I DATABASE ###" FPOSTADR 96 A/35 Forretningsadresse FPOSTNR 131 A/4 Postnr som tilhører forretningsadresse. ENHETSTYPE 135 A/4 Enhetstype (selskapsform) KOMMUNE 139 A/4 Kommunenr NAVN1 143 A/35 Foretakets navn (kun 1. navne-element) POSTBOKSADR1 178 A/35 Postadresse POSTB-POSTNR 213 A/4 Postnr som tilhører postadresse. TLF 217 A/15 Telefon. ORGH 232 A/9 Organisasjonsnr til hovbedforetaket. STIFT-DATO 341 A/10 Stiftelses-dato. Side 13/22

3.2.2 Standard returfil 2 3.2.2.1 Hode pr. record Feltnavn Start Type/lengde Forklaring RECORDTYPE 1 A/1 Verdi : 1 Ajourholdstrans KUNDEID 2 A/16 ORGNR 18 A/9 REKKEFØLGENR 27 A/1 For sortering av utsnitt pr org.nr UTSNITTSKODE 28 A/4 GRUI Grunninformasjon. NKOD Bransjer/ næringskoder STAT - Status felt... 32 Her kommer de feltene som kunden skal ha fra 3.2.2.2 Utsnitt GRUI - Grunninformasjon Feltnavn Start Type/ lengde Forklaring Hode 1 A/31 KOMMUNE 32 A/4 Kommunenr. ENHETSTYPE 36 A/4 Selskapsform aktuelt utsnitt i den rekkefølgen de ligger på profilen. Profilen forteller også om feltlengdene er faste eller variable med valgfri felt-separator. Se kap. Nedenfor for beskrivelse av utsnittene ENH-TP-BESKR 40 A/70 Selskapsform beskrivelse REKLAME 110 A/1 Reservasjon mot reklame J/N NAVN1 111 A/35 Foretakets navn NAVN2 146 A/35 Feltets innhold kan være: Blankt Resten av foretakets navn, hvis dette går utover 35 posisjoner i NAVN1, eller Utfyllende informasjon til navnet/foretaket. NAVN3 181 A/35 Feltets innhold kan være: Blankt Resten av foretakets navn, hvis dette går utover 70 posisjoner i NAVN1+NAVN2, eller Utfyllende informasjon til navnet/foretaket. NAVN4 216 A/35 Feltets innhold kan være: Blankt Resten av foretakets navn, hvis dette går utover 105 posisjoner i NAVN1+NAVN2+NAVN3, eller Utfyllende informasjon til navnet/foretaket. NAVN5 251 A/35 Feltets innhold kan være: Blankt Resten av foretakets navn, hvis dette går utover 140 posisjoner i NAVN1+NAVN2+NAVN3+NAVN4, eller Utfyllende informasjon til navnet/foretaket. Side 14/22

REDIGERT-NAVN 286 A/36 For søk. FORR-POSTADR1 322 A/35 Forretningsadresse FORR-POSTADR2 357 A/35 FORR-POSTADR3 392 A/35 FORR-POSTNR 427 A/9 FORR-POSTSTED 436 A/35 FORR-LAND 471 A/35 FORR-ADR-UTL 506 A/35 FORR-KOMMUNE 541 A/35 POSTBOKSADR1 576 A/35 Postadresse POSTBOKSADR2 611 A/35 POSTBOKSADR3 646 A/35 POSTB-POSTNR 681 A/9 POSTB-POSTSTED 690 A/35 POSTB-LAND 725 A/35 POSTB-STED-UTL 760 A/35 TELEFON 795 A/15 TELEFAKS 810 A/15 MOBILTLF 825 A/15 E-POST 840 A/100 HJEMMESIDE 940 A/100 WWW-adresse ORGNR-HOVEDF 1040 A/9 Orgnr. Hovedforetak STIFT-DATO 1049 A/10 ÅÅÅÅ-MM-DD REG-DATO 1059 A/10 ÅÅÅÅ-MM-DD ENDRET-DATO 1069 A/10 ÅÅÅÅ-MM-DD SLETTET-DATO 1079 A/10 ÅÅÅÅ-MM-DD FORR-LANDKODE 1089 A/2 POSTB-LANDKODE 1091 A/2 3.2.2.3 Utsnitt NKOD Næringskoder Feltnavn Start Type/ lengde Forklaring Hode 1 A/31 REKKEFOLGE 32 A/4 1 er hovednæring NKODE 36 A/6 BESKR-DEL1 42 A/70 Næringsbeskrivelse del 1 BESKR-DEL2 112 A/70 Næringsbeskrivelse del 2 Side 15/22

3.2.2.4 Utsnitt STAT - Status Feltnavn Start Type/ lengde Forklaring Hode 1 A/31 STATUS 32 A/4 FR Reg. i Foretaksreg. MVA Registrert i Merverdiavg.manntallet KONK Konkurs TVOP Tvangsoppløst FUSJ Fusjon, Overdragende/ Overtagende selskap FISJ Fisjon, Overdragende/ Overtagende selskap OPPL Oppløst AKKO Meldt akkord OS Oversendt skifteretten SLET Sletting av enhet RR Regnskap registrert STATUS-DATO 36 A/10 Dato registrert (ÅÅÅÅ-MM-DD) DATA 46 A/10 Når STATUS: RR => sist leverte regskapsår (ÅÅÅÅ) SLET => dato for sletting (ÅÅÅÅ-MM-DD) 3.2.2.5 Utsnitt SEKO - Sektorkode Feltnavn Start Type/ lengde Forklaring Hode 1 A/31 SEKTORKODE 32 A/4 SEKTORKODE-NAVN 36 A/70 Side 16/22

3.2.2.6 Utsnitt HNVN Historisk navn Feltnavn Start Type/ lengde Forklaring Hode 1 A/31 LINJE 32 N/ 4 En intern nummerering hvis flere historiske navn på NAVN1 36 A/35 Foretakets navn foretaket. Det eldste navnet kommer da som nr 1. NAVN2 71 A/35 Feltets innhold kan være: Blankt Resten av foretakets navn, hvis dette går utover 35 posisjoner i NAVN1, eller Utfyllende informasjon til navnet/foretaket. NAVN3 106 A/35 Feltets innhold kan være: Blankt Resten av foretakets navn, hvis dette går utover 70 posisjoner i NAVN1+NAVN2, eller Utfyllende informasjon til navnet/foretaket. NAVN4 141 A/35 Feltets innhold kan være: Blankt Resten av foretakets navn, hvis dette går utover 105 posisjoner i NAVN1+NAVN2+NAVN3, eller Utfyllende informasjon til navnet/foretaket. NAVN5 176 A/35 Feltets innhold kan være: Blankt Resten av foretakets navn, hvis dette går utover 140 posisjoner i NAVN1+NAVN2+NAVN3+NAVN4, eller Utfyllende informasjon til navnet/foretaket. Side 17/22

3.2.3 Feilfil fra vask Feltnavn Start Type/ lengde Forklaring FIL-ID 1 A/16 Kkort beskrivelse av kjøring. REC-ID 17 A/3 FFI KUNDE 20 A/6 Gyldig kundenr. AVDELING 26 A/6 Utfylt ved eventuelt ønske om å skille Kundens forskjellige kjøringer fra hverandre. KUNDEREF 32 A/16 Kundens kundenr for objektet (egen-id) ORGNR 48 A/9 Oppgitt organisasjonsnr i inputfil SIKKER-UNIK-TREFF 218 A/2 Indikator for sikker unik treff (01) AJOURH-KODE 238 A/1 N=ikke innmeldt til vedlikehold J=Meldt inn til vedlikehold LINJENR 292 A/9 Internt nr. FEILKODE 301 A/3 Feilkode: DPL = duplikat på orgnr + kunderef UIN + UGO = ugyldig orgnr UNO = unumerisk orgnr TRF = ikke treff i ENHET FILLER 305 A/1 FEILKODE-TEKST 306 A/36 Se FEILKODE over 3.2.4 Antallsoversikt fra vask Feltnavn Start Type/ lengde Forklaring FIL-ID 1 A/16 Kkort beskrivelse av kjøring. REC-ID 17 A/3 TRL FILLER1 18 A/1 ANT-REC-INN 19 N/9 Antall records i inputfil FILLER2 28 A/1 ANT-MED-NAVN 29 N/9 Antall med Organisasjonsnavn FILLER3 38 A/1 ANT-OBJ-FORKAST 39 N/9 Antall objekter forkastet pga ugyldig orgnr. De forkastede objektene ligger i Feilfil. FILLER4 48 A/1 ANT-DUPL-FORKAST 49 N/9 Antall objekter forkastet pga duplikat på Orgnr og Kunderef. De forkastede objektene ligger i Feilfil. FILLER5 58 A/1 ANT-OBJ-UTILGJ 59 N/9 Ikke i bruk. FILLER6 68 A/1 ANT-TREFF 69 N/9 Antall objekter identifisert og tilført informasjon fra Enhets- og foretakstregisteret. Side 18/22

FILLER7 78 A/1 ANT-RECS-ST1 79 N/9 Antall records i standard returfil 1. FILLER8 88 A/1 ANT-RECS-ST2 89 N/9 Antall records i standard returfil 2. FILLER9 108 A/42 Side 19/22

3.2.5 Header og Trailer ved periodisk vedlikehold Disse to recordtypene kommer kun ved periodisk vedlikehold av kundens portefølje. Kundens portefølje ligger da lagret hos EVRY EVRY, ref. kap. 2.3. Datainnhold fra EFR følger for øvrig samme recordlayout som beskrevet kap. 3.2.2 Standard returfil 2 avhengig av hvilke produkter man ønsker tilført. 3.2.5.1 Header Feltnavn Start Type/lengde Forklaring RECORDTYPE 1 A/1 Verdi : 0 Header-record KJOREDATO 2 N/8 KJORENR 10 N/6 ANTOBJ-TOT 16 N/9 Ant. obj. til overv. Totalt ANTOBJ-ENDR 25 N/9 Ant. obj. med endr. i overv. ANTOBJ-INN 34 N/9 Ant. objekter meldt inn til siste overv. ANTOBJ-UT 43 N/9 Ant. objekter meldt ut til siste overv. ANT-SLETT 52 N/9 Ant. objekter meldt slettet i siste overv. 3.2.5.2 Trailer Feltnavn Start Type/lengde Forklaring RECORDTYPE 1 A/1 Verdi : 9 Trailer-record Side 20/22

3.2.6 Inn- og utmelding til vedlikehold Der det oppstår endringer på noen av kundens objekter blir endringen rapportert tilbake til kundens registerportefølje for oppdatering. For å sikre kvalitet presiserer vi følgende: Foretaksobjektene bør være identifisert som gyldige foretak før innmelding til periodisk vedlikehold. Man bør også sikre at foretaksobjektene er oppdatert pr. innmeldingstidspunkt Kundens egen ID (nøkkel) blir lagret i en kundeobjekt-database hos EVRY. Kundeobjekt-databasen benyttes for å sjekke om endringer gjelder noen av kundens objekter. Følgende beskriver hvordan det batch/ filbasert grensesnittet ser ut for inn- og utmelding: Feltnavn Start Type/lengde Beskrivelse Inn/utmeldingsdata: KUNDENR 1 A/6 Kundens kundenummer hos EVRY. AVDNR 7 A/6 Evt. avdelingsnr. dersom dette er aktuelt. Som regel blank EGEN-ID 13 A/16 Egen unik ID/referanse på kunde/medlem ORGNR 29 N/9 Organisasjonsnr Ikke i bruk 38 A/3 STATUS 41 A/1 AJOURHOLDSKODE 42 A/1 I Innmelding, S Sletting KILDE 43 A/3 Normalt blank DATO 46 A/8 Dato for innmelding/utmelding (AAAAMMDD) TID 54 A/7 Tidspunkt for innmelding/utmelding (TTMMSST) TT=Time MM=Minutt SS=Sekund T=Tiendel (som regel 0) Ikke i bruk 61 A/20 Felt er foreløpig ikke i bruk, settes blank. Side 21/22

4 Endringslogg Dato Kapittel Beskrivelse av endring 15.11.06 3.2.2 Rettelser i recordbeskrivelse av GRUI: Nytt felt inn: MOBILTLF posisjon 825. 2 felt er flyttet pga feil angivelse: FORR-LANDKODE fra tidligere posisjon 471 til 1081 POSTB-LANDKODE fra tidligere posisjon 727 til 1083 08.02.10 3.2.6 Nytt utsnitt HNVN lagt inn 04.10.10 3.2.1 Lagt inn recordlayout på Standard returfil 1, feilfil og antallsoversikt. 27.03.11 3.2.1.1 Rettet opp feltlengde på KUNDEREF 27.03.11 3.2.1.2 Rettet feltlengde på felt NAVN1 fra 36 til 35. 27.03.11 3.2.1 Rettet innledende tekst i kapittel. 27.03.11 3.2.5.3 Nytt kapittel: Beskrivelse av record for inn- og utmelding. 01.01.12 3.2.2.5 Feltet SEKTORKODE er utvidet med 1 tegn fra 3 til 4 tegn. Startposisjon for SEKTORKODE-NAVN er forskjøvet tilsvarende. 02.03.12 3.2.6 Kap. 3.2.5.3 endret til kap. 3.2.6 Side 22/22