Side 1 af 111 Navision Stat 5.3 ØKO/KKP 09.10.2011 Elektronisk fakturering Introduktion Vejledningen er gældende for elektronisk købs- og salgsfakturering i NS 5.3. Med den nærmest foregående version (NS 5.2) blev det muligt at modtage Forsyningsspecifikation, fra forsyningsselskaber; at sende elektroniske handelsdokumenter til debitorer, som har registreret sig på UDDI med en anden elektronisk adresseid end et EAN nummer og at modtage elektroniske fakturaer fra udenlandske firmaer som ikke har dansk CVR nummer. OIOXML07 udfases iht. bekendtgørelse pr. 1. dec. 2011 for handel med det offentlige. Det falder tilfældigvis sammen med release af NS 5.3 og der er i manualen derfor renset en del ud i referencer til OIOXML07. Med NS 5.3 er der på området for elektronisk fakturering forholdsvis få ændringer som brugeren skal forholde sig til. Derudover er der nogle tekniske ændringer, idet skematronvalideringerne er opgraderet, og visningsstylesheets er udskriftet. Overblik Dokumentet beskriver opsætning og anvendelse af Navision Stats funktion til brug for modtagelse og afsendelse af elektroniske handelsdokumenter. Opbygningen følger i væsentlig strukturen i Navisions menusuite under følgende udvalgte opsætningpunkter: Generelt, Virksomhedsoplysninger, Generel integration for Elektronisk fakturering, opsætninger på Køb, Salg, Kreditorer og Debitorer, samt håndtering af selve modtagelsen og afsendelse af elektroniske handelsdokumenter. Opsætning af transportlag, samt Aliaskontering er kun perifert berørt. Her må du søge information i de relevante manualer frigivet for samme version af Navision Stat. Endvidere henvises til øvrige manualer for eksempelvis Finans og Betalinger. Vejledningen henvender sig til de medarbejdere, som arbejder med elektroniske købs- og salgsdokumenter, samt de medarbejdere, der skal foretage de tilhørende opsætninger i Navision.
Indholdsfortegnelse Side 2 af 111 Begreber... 6 Generelt... 7 Programopsætning, Generelt... 8 Regnskabsopsætning... 8 Virksomhedsoplysninger... 8 Sælgers navn og adresse i salgsdokumenter... 9 Sælgers betalingsoplysninger... 9 Programopsætning, Generel integration... 10 NS TS Integration... 10 Dokumenttype og Profiler... 11 Dokumenttype, profiler og valideringer for IndFak... 12 Validering af dokumenter... 12 NS TS Udvekslingstabel... 12 Rapport NS TS Udvekslingsstatus... 13 Automatisk åbning af indbakken... 14 Endpoint Keytype Opsætning... 15 E-Bilag opsætning... 15 Styringsopsætning... 15 OIO Betalingsmetode... 19 Indgående Gebyr og konto... 23 XML-bro... 23 XML-bro Mapning... 23 Kodelister... 24 Enheder... 24 Kodelistemapning... 24 Indadgående kodelistemapning... 26 Udadgående kodelistemapning... 27 Periodiske aktiviteter... 27 Indlæs XML fra fil... 28 Importer eksempelskabelon... 28 Dokumentation XML-bro... 28 Indlæs / udlæs opsætning... 28 Integration m. IndFak... 28 Check stamdata... 28 Eksporter stamdata... 31 Eksportér transaktionsdata... 32 Alias i Navision og IndFak... 32 Køb Opsætning... 34 Købsopsætning... 34 Nummerering... 34 Disposition... 34 Kreditor opsætning... 34 Kreditor skabelon... 38 Kreditor opsætning for IndFak... 39
Kreditors E-bilags partner opsætning... 39 Kreditor E-bilagspartner, fanen Generelt... 41 Kreditor E-bilagpartner, Fanen Købslinjer... 43 Valutakoblinger... 44 Valutakoder... 45 Masseopret Kreditor E-Bilag partnere... 45 Salg opsætning... 46 Debitoropsætning... 46 Indenlansk/Udenlandsk debitor... 47 Betalingsoplysninger... 48 Rykker og rentebetingelser... 48 Debitors E-bilag Endpoint opsætning... 48 Undersøg Debitors Ebilag Endpoint på UDDI... 49 Analysér svar fra UDDI... 50 Debitor kan modtage OIOUBL2 dokument via OIOSI... 50 Debitors EAN nummer findes ikke i UDDI... 51 Debitor har ikke registreret dokumenttypen på UDDI.... 51 Debitor E-bilags partner opsætning... 52 Masseopret Debitor E-Bilag partnere... 53 Håndtering af elektroniske købsbilag... 54 Indgående dokumenter... 54 Arbejdsgange for indgående købsdokumenter... 54 Indgående købsdokumenter... 55 Visning af mislykkede dokumenter i NSTS udvekslingstabellen... 56 Status i Indgående købsdokumentkladde... 56 Indgående købsdokumenthoved faner og felter... 57 Generelt fanen... 57 Fakturer fanen... 60 E-bilag fanen... 61 Betaling fanen... 62 OIO fanen... 64 Følsomme persondata... 67 Afvis Årsagsbeskrivelse... 68 Original bilag inkl. følsomme persondata... 68 Indgående købsdokumenthoved menuknappen Dokument... 68 Indgående købsdokumenthoved menuknappen Linje... 72 Indgående købsdokumenthoved menuknappen Funktion... 72 Indgående købsdokumentlinjer... 72 Manuel konterings felter... 72 Mange linjer... 73 Indgående købsdokument hoved og linje Dimensionskontostreng... 73 IndFak... 73 Indgående købsdokument hoved og linje dimensioner... 74 IndFak... 74 Dimensionskontostrenge fra Indfak... 75 Finans... 75 Side 3 af 111
Anlæg... 75 Vare... 75 Indgående købsdokument Moms og afgifter... 75 IndFak, OIOUBL-2... 76 Indgående dokumentgebyr... 77 OIOUBL2... 78 IndFak... 78 Indgående købsdokument betalingsmetoder (flere)... 78 Indgående Købsdokumenttyper... 78 Købsfaktura... 78 Købsordre... 78 Købsordreændring... 78 Købskreditnota... 79 UTS forsyningsspecifikation... 79 Accept af indgående købsdokument... 79 Accepter (normal)... 80 Købsfaktura... 80 Købsordre... 80 Købsordreændring... 80 Købskreditnota... 80 UTS forsyningsspecifikation... 80 Tjek af Referenceordre... 80 Tjek af Dokumenttotal... 81 Acceptér m afvigende moms... 82 Købsfaktura og Kreditnota... 82 Afvisning af dokument i indbakken... 83 Identifikation af entydig kreditor... 84 Identifikation af entydig Faktureringsleverandør... 84 Massebehandling af dokumenter i indbakken... 85 Masseaccept af dokumenter i indgående købsdokumentkladde... 85 Masseaccept/-afvis - Ordinær... 86 Massemarkér før masseaccept... 88 Massefjern Valgt dokument... 89 Masseaccepter m afvigende moms.... 89 Efter Accept... 89 Håndtering af elektroniske rykker... 89 Indgående købsrykkerkladde... 90 Indgående købsrykkerhoved... 91 Indgående Rykkerhoved menuknappen Rykker... 92 Indgående Rykkerhoved menuknappen Linje... 92 Indgående Rykkerhoved menuknappen Funktion... 92 Indgående kontoudtog... 93 Indgående kontoudtogshoved... 94 Håndtering af elektroniske salgsbilag... 95 Opret salgsdokument... 95 Salgshoved obligatoriske felter... 96 Side 4 af 111
Salgsfakturalinjer... 98 Bemærkning til salgshoved eller salgslinje... 100 Udvidede tekster... 100 Rabat (AllowanceCharge)... 101 Vedhæft bilag til salgsdokument... 101 Udskriv ikke det elektroniske salgsdokument... 103 Bogfør og send elektronisk salgsfaktura... 103 Send usendte E-bilag... 104 Bogfør elektronisk salgsfaktura fra salgsordre... 105 Tjek forsendelses status for elektronisk dokument... 105 Status Mislykket forsendelse af ebilag... 107 Ofte stillede spørgsmål om mislykket E-bilag... 109 Gensend elektronisk dokument... 109 Elektronisk salgskreditnota... 110 Elektronisk Rykker... 110 Elektronisk kontoudtog... 110 Side 5 af 111 Versioner Publiceret første gang: NS 3.60 22. december 2004 Nærværende version: NS 5.3 9. december 2011 Målgruppe Vejledningen henvender sig til medarbejdere i institutionen, som arbejder med elektroniske købs- og salgsdokumenter i Navision Stat 5.3, samt de medarbejdere i institutionen og i IT-driftsorganisationen, der skal foretage de nødvendige opsætninger i Navision Stat og af transportlag.
Side 6 af 111 Begreber Nedenfor finder du nogle begreber som benyttes i forbindelse med elektronisk fakturering og elektroniske handelsdokumenter. Begreb E-bilag EndpointID E-dokument Nøgletype GLN/EAN Lokationsnr. Indbakke Udbakke E-bilag- Partner Indgående E- bilag Udgående E- bilag OIOUBL-2.0 Beskrivelse Den nøgleværdi som sammen med en type, bruges af systemet til at finde den webservice-adresse, hvortil du skal sende et elektronisk handelsdokument. E-bilag EndpointID bruges nu i Navision sammen med en Endpoint type. E-bilag Endpoint kan eksempelvis være et GLN/EAN nummer eller et CVR nummer. Angiver typen for E-bilag Endpoint identifikatoren. E-dokument Nøgletype bruges i Navision sammen med en E- bilag EndpointID. E-dokument nøgletype kan eksempelvis være EAN, GLN, CVR, P mfl. Bruges af Navision Stat sammen med Ebilag EndpointID til at foretage opslag i UDDI for at finde den webserviceadresse, hvortil et elektronisk handelsdokument skal sendes. Er én af de identifikatorer der kan bruges som opslagsværdi i UDDI. Tidligere kunne Navision kun bruge denne type værdi. Identifikatoren for et Navision Stat regnskabs er altid et GLN/EAN nummer. De sæt af tabeller i Navision Stat, hvor data fra indkomne dokumenter opbevares. Synonymt m Indgående dokumentkladder for faktura, kreditnota, ordre, rykkere og kontoudtog. De sæt tabeller i Navision Stat, hvor data til udgående dokumenter opbevares. Der findes Udgående dokumentkladder for faktura, kreditnota, rykkere og kontoudtog. E-BilagPartner knyttes til debitor- og kreditorkort, som i Navision skal sende eller modtage elektroniske handelsdokumenter Et elektronisk modtaget dokument, som findes i en af de Indgående købsdokumentkladder. Et elektronisk afsendt dokument, som findes i en af de udgående salgsdokumentkladder. Navision 5.x understøtter OIOUBL2 der er den gældende standard for elektroniske handelsdokumenter. Navision understøtter kun et udvalg af dokumenter indenfor standarden.
Side 7 af 111 OIOXML-0.7 OIOXML07, herunder LæsInd standarden udfases fra maj til december 2011. Derfor er referencer til denne standard næsten fjernet fra nærværende manual. UDDI Funktionaliteten vil blive fjernet i forbindelse med en senere release. Navisions funktionalitet i forhold til OIOXML07 er ikke ændret. Hvis du har brug for at vide noget om NS og OIOXML-07 skal du anvende manualen for elektronisk fakturering i Navision 5.2. IT- og Telestyrelsen indførte i forbindelse med OIOUBL2 en ny OIOSI forsendelsesform. For at man kan modtage elektroniske handelsdokumenter med OIOSI forsendelse, skal regnskabets være registreret i det centrale UDDI register. Navision Stat regnskaber skal altid registreres med et EAN nummer. Når Navision Stat skal afsende elektronisk handelsdokument foretager for hver enkelt afsendelse foretager transportlaget opslag på IT- & Telestyrelsens UDDI, for at få oplysninger om den webserviceadresse der skal sendes til og hvilken dokumenttype der skal afsendes. (OIO UDDI 1.1 definerer en samlet datamodel og søgearkitektur for serviceregistre i den offentlige sektor.) Generelt For at dit regnskab kan modtage eller afsende elektroniske salgsfakturaer, skal du foretage nogle generelle opsætninger i Navision Stat; opsætninger på de enkelte kreditorer og debitorer, samt sikre at der er installeret og opsat det nødvendige komponenter på de servere hvor hhv. din Navision database og det tilhørende transportlag ligger. Konsulter din It afdeling /Host og relevante manualer via Moderniseringsstyrelsens release- og supportsite. Yderligere skal dit regnskab være Nemhandelsregisteret/ UDDI databasen. Se nærmere herom i Moderniseringsstyrelsens gældende vejledning om UDDI registrering for Navision Stat institutioner. Vær opmærksom på at registreringen afhænger af hvorledes Navision evt. er sammenkoblet med et fakturahåndteringssystem. For at du kan oprette eller redigere registreringen på UDDI, skal du have et gyldigt medarbejdercertifikat, som tilhører samme CVR som det pågældende regnskab føres for. Du skal også have informationerne om det funktionscertifikat som er installeret på den transportlags-server, som dit regnskab bruger. Det er nødvendigt, at Regnskabsafdelingen og IT-afdelingen aftaler nærmere vedrørende dette.
Side 8 af 111 Navision Stat kan afsende og modtage elektroniske handelsdokumenter i OIOUBL-2.0 format, samt modtage ordredokumenter fra IndFak. Endvidere kan Navision stat modtage forsyningsvirksomhedernes OIOUBL-2 specifikationsdokument (UTS). Hvis NS forsøger at afsende OIOXML07 skyldes det at det anvendte EANnummer ikke er registreret i UDDI. Programopsætning, Generelt Regnskabsopsætning Sti: Økonomistyring \ Opsætning\ Regnskabsopsætning\ Faneblad Generelt. Feltet Regnskabsvalutakode. Ved dannelse af data til Udadgående E-bilag benyttes værdien som den valutakode, der faktureres i, hvis der ikke er opsat en anden valutakode på debitoren. Du skal enten angive DKK, eller lade feltet stå blankt, når der faktureres i danske kroner. Hvis dit regnskab fakturerer i en anden valuta, skal ISO koden for denne valuta angives. Virksomhedsoplysninger Sti: Økonomistyring\ Opsætning\ Firmaoplysninger\ Faneblad Generelt. Oplysningerne indgår som sælgers oplysninger i handelsdokumenter og elektroniske handelsdokumenter.
Sælgers navn og adresse i salgsdokumenter Side 9 af 111 Elementerne for sælgers navn og adresse i OIO-salgsdokumenter udfyldes med værdier fra Virksomhedsoplysningernes Generelt faneblad. Udfyld som minimum CVR nummer, Navn, Adresse, Postnr., By og Landekode. Udfyld også de øvrige felter hvis der findes data for bogføringskredsen. Sælgers betalingsoplysninger De betalingsoplysninger som du skal anvende i forbindelse med salgsfakturering opsættes her. Der er intet specielt i forhold til fakturering på papir.
Programopsætning, Generel integration Side 10 af 111 NS TS Integration Her finder du integrationsopsætningen mellem Navision regnskaber, transportlags-server og databaser. Den skal ske i Navision Stat for udveksling af E-bilag med transportlaget. Sti: Administration/Programopsætning/Generel Integration/ NS TS Integration. Denne tabel er fælles for alle regnskaber på samme Navision Stat database. Regnskabet skal opsættes i tabellen, hvis det skal sende eller modtage elektroniske dokumenter. For at redigere i tabellen skal du have rettigheder til opsætning af Køb m. E-handel. Opsætningerne styrer sammenhængen mellem regnskaberne i Navision databasen og tilhørende transportlag. Navision bruger opsætningen til at finde sit transportlag og transportlaget bruger opsætningerne til at finde det korrekte regnskab at indsætte dokumenter i. Data skal typisk opsættes én gang i forbindelse med installationen og herefter IKKE røres. Der skal være mindst en linje for hvert regnskab i databasen, som skal sende eller modtage handelsdokumenter, stamdata eller NKS betalinger. Indgår dit regnskab i en konstruktion hvortil der er offentliggjort flere EAN numre som kan bruges når man sender regninger til samme regnskab, skal du eller din IT enhed sørge for at alle de relevante EAN numre er opsat i tabellen. Der skal i det tilfælde findes en linje for hvert EAN nummer, således at de pågældende EAN numre er listet i kolonnen REGNSKABSEAN. Resten af linjernes opsætning skal være identisk for alle linjer som tilhører samme regnskab. Der leveres ikke nogen standardopsætninger til tabellen.
Side 11 af 111 Obs! Det samme EAN nummer må ALDRIG pege på to forskellige regnskaber. Nærmere om opsætning af tabellen er beskrevet i dokumentet opsætningsvejledningen OES Transportlag 5.3 Installationsvejledning. Opsætning skal ske af en bruger med nødvendige opsætningsrettigheder eller superbruger, typisk den person der administrerer serveren. Bemærk: Når dit regnskab overgår til at bruge IndFak, skal du synkront hermed justere opsætningen af regnskabets EAN nummer, idet Skyggenummer udgår. Dokumenttype og Profiler Sti: Administration/Programopsætning/Generel Integration/Dokumenttype og Profiler. Under dette menupunkt findes opsætninger for de E-handels dokumenter og datastrømme, som Navision Stat og transportlaget kan sende og/eller modtage. Moderniseringsstyrelsen udsender de datafiler, som du skal bruge til at vedligeholde standardopsætningen af tabellerne. Når du indlæser ny opsætning fra Navision bliver alle indadgående og udadgående valideringer automatisk slået til. Det er ikke normalt at institutionen selv skal foretage nogen rettelser i disse opsætninger. Bemærk: Der er dog én undtagelse fra ovenstående, nemlig opsætning af skemaog skematronvalideringen af visse ind og udadgående dokumenter, hvis du bruger
IndFak. I så fald skal du foretage en justering, hver gang du har indlæst standardopsætningen. Se nedenfor. Side 12 af 111 Rettelser i tabellerne har vidtgående betydning for transportlagets funktion. En fejl kan betyde, at dannelse, forsendelse og modtagelse af xml-dokumenter sættes ud af funktion, herunder også afsendelse af betalingsfiler. Har institutionen ønske om andre ændringer, skal der ske en dybtgående analyse af konsekvenserne, inden ændringen iværksættes. Dokumenttype, profiler og valideringer for IndFak Hvis du anvender IndFak SKAL du foretage efteropsætning idet validering skal sættes til Nej for visse dokumenter, jf. nedenstående. For IndFak gælder det for kolonnen SkematronvalideringInd for de rækker, hvor værdien i feltet Type = UBL20 OG samtidig værdien i Rodnode er Invoice, CreditNote, Statement, Reminder, Order, OrderChange eller UtilityStatement. For IndFak skal yderligere værdien i SkematronvalideringUD sættes til Nej for linjen, hvor feltet Type = UBL20 OG værdien i Rodnode er ApplicationResponse. Frakoblingen SKAL ske fordi IndFak og Navision kommunikerer på private profiler, som ikke er indeholdt i den officielle skematronvalidering fra ITST og derfor vil medfører valideringsfejl. Validering af dokumenter Med frigivelse af NS 5.3 transportlag releaser Moderniseringsstyrelsen samtidig det aktuelt nyeste sæt af officielle skema- og skematronvalideringsfiler som ITST har frigivet, hvilket pt. er pr. 1. dec. 2011. NS TS Udvekslingstabel Denne tabel er ikke en opsætningstabel. Indholdet er dynamisk. I NS TS udvekslingstabellen mellemlagres overordnet information om xml-dokumenter som er på vej til eller fra regnskabets Indbakketabeller hhv. Udbakketabeller. Her placerer transportlaget information om ankommende dokumenter. Navision anvender informationen når en indbakke åbnes eller opdateres. Navision anmoder om selve XML filen fra transportlaget, som herefter mappes til den pågældende indgående dokumentkladde. Når et dokument er kommet succesfuldt ind i Navision, eller afsendes korrekt, så bliver det slettet fra tabellen, i mellemtiden står linjen markeret med status = Behandler.
Side 13 af 111 Du må normalt ikke redigere i tabellens indhold. Hvis der opstår et problem som kræver redigering eller sletning skal du tage kontakt til Moderniseringsstyrelsens regnskabssupport. Den afhjælpende handling vil afhænge af deres analyse. Brugere der i givet fald skal slette eller redigere i tabellen skal have tilknyttet rollen NS_OPS_INTEGRATION Sti: Administration/Programopsætning/Generel Integration/NS TS Integration/Udvekslingstabel Det kan ske at et eller andet går galt enten i kommunikationen eller i behandlingen af dokumentet og det efterlader linjer i tabellen med status Mislykket. Skulle det ske, kan du finde information om problemet i tabellen. Værdien i feltet status vil typisk være Mislykket. Som hjælp til overvågningen for mislykkede dokumenter, finder du i Navisions dokumentkladder for Indgående købsdokumenter, Indgående rykkere, Indgående kontoudtog og Indgående NKS retursvar et felt øverst til højre, som viser, hvis der findes et eller flere dokumenter med status Mislykket, som hører til i den pågældende kladde. Rapport NS TS Udvekslingsstatus Du kan også benytte rapporten NS TS Udvekslingsstatus, som findes under flg.: Sti: Administration/Programopsætning/NSTS Integration/Rapporter/NS TS Udvekslingsstatus Bemærk: Hvis der ligger data i tabellen så vær opmærksom på løbenummeret. Hvis du ser en linje med et tydeligt lavere løbenummer end linjerne for de aktuelle dokumenter i transport, betyder det, at dette dokument er strandet uanset status.
Bemærk: Hvis et dokument strander, på vej ind eller ud, ser du det som en linje, der ligger i tabellen i længere tid, typisk m. status Mislykket eller evt. Behandler. Du finder en beskrivelse af problemet i feltet Fejlbeskrivelse og feltet Navision Fejl. Får du brug for support i forbindelse med et strandet dokument, og hvis rapportens informationer ikke er tilstrækkelige, skal du kopiere indholdet af tabellen til et regneark, som sendes til supporten sammen med din beskrivelse af problemet. Hvis kommunikationen mellem Navision og transportlaget får et ukontrolleret nedbrud, kan dokumenter strande med anden status angivelse, eksempelvis Behandler. Side 14 af 111 Automatisk åbning af indbakken Af hensyn til at kunne afstemme de dokumenter der er afsendt fra IndFak til Navision Stat med de dokumenter der faktisk er modtaget i Navision Stat, er der nu mulighed for at automatisere åbning af indbakkerne, således at det kan ske eksempelvis en gang i døgnet, uden at det absolut kræver en brugers indgriben. Dataudtrækket til afstemningen sker fra Indgående købsdokumenthoved tabellerne. Derfor er en periodisk åbning en betingelse for at afstemningen kan give et nogenlunde retvisende billede. Jobbet sættes op ved at oprette et Batch Job kort og opsætte Codeunit 6006950 edoc Refresh Inbound. Sti: Administration/Programopsætning/Batch/Job. Forudsætningen for at jobbet kan afvikles, er at der findes en NAS instans til regnskabet med startparameter GIS. Se nærmere i vejledningerne til GIS og opsætning af NAS.
Endpoint Keytype Opsætning Side 15 af 111 Navision Stat kan sende elektroniske handelsdokumenter til debitorer som har ladet sig UDDI registrere med en anden identifikator for deres endepunkt /modtagepunkt end et EAN nummer. Tabellen indeholder listen over de gyldige typer af Endepunkts identifikatorer. Tabellen findes sammen med øvrige opsætninger for elektronisk handel. Sti: Administration/Programopsætning/Generel Integration/NS TS Integration/Endpoint KeyType Opsætning. Tabellen er også tilgængelig for opslag fra debitorkortet. Moderniseringsstyrelsen udsender den datafil, som du skal bruge til at vedligeholde standardopsætningen af tabellen. Det er ikke normalt at institutionen selv skal foretage nogen rettelser her. E-Bilag opsætning Styringsopsætning Styringsopsætningen rummer generelle opsætninger af betydning for elektronisk fakturering. Sti: Administration/Programopsætning/NS TS Integration/E-Bilag /Styringsopsætning Der skal foretages opsætning her, når regnskabet skal modtage eller sende elektroniske bilag. Omfanget afhænger bl.a. af om regnskabet er knyttet til IndFak, eller ikke benytter noget foranliggende godkendelsessystem.
Side 16 af 111 Hvis din institution benytter IndFak, er flere af opsætningerne obligatoriske. Forklaring til felterne Felt Sti til XML Dokument er Put på lager Afstem beløb Afstemningspræcision Brug digital Beskrivelse I feltet angives stien til det elektroniske arkiv for ankommende og afsendte e-handelsdokumenter (jf. installationsvejledning for transportlaget). Det er den faktiske placering ad afgør hvad der skal stå. Syntaksen er ofte på denne form: http://xxx.xxx.xxx.xxx/elektroniskarkiv/xmldetail.aspx, hvor xxx.xxx.xxx.xxx er IP nummeret på den Internet Information Server, der kører Elektronisk Arkiv. Kan kun anvendes for OIOXML-0.7 faktura. Ja hvis man ønsker, at NS ved accept af købsfaktura/kreditnota skal foretage kontrolberegning af totalen for det oprettede dokument og sammenholde resultatet med den medsendte fakturatotal fra fakturaudstederen. Angiv den afvigelse du ved accept vil tolerere mellem fakturaudsteders angivelse af totalbeløb og Navisions beregning af fakturatotalen inkl. moms. Navision bogfører og betaler det beløb Navision udregner. I dette tilfælde kan det blive nødvendigt at bogføre en evt. "øredifference" for at betale det, som fakturaudsteder ønsker. Ja, hvis man har en aftale med sine leverandører eller med et foranliggende dokumenthåndteringssystem om, at data til
signatur Regnskab EAN Lokation Ekstern- PartnerID Rykker kladdetype Rykker kladdenavn Sæt Brug Dimensionskontostreng Tillad Købsdoku mentaccept m afvigende moms Finanskonto ID kode Budget ID kode Dimension ID kode Anlæg ID kode Side 17 af 111 Navision skal være forsynet med informationer om digital signatur. Ved Ja tjekker Navision Stat for om felterne Valideringsdato, Signatur ID og Signatur udsteder er udfyldt. Dette er relevant, når institutionen anvender IndFak. Denne værdi bruges når man fra Navision afsender elektroniske handelsdokumenter og NKS betalingsordre. Værdien i feltet angives som fysisk afsender i elektroniske salgsdokumenter. Værdien SKAL ligeledes genfindes i feltet REGNSKABSEAN i én af linjerne i NSTS Integrationstabellen for at transportlaget kan blive aktiveret, samt for at retursvar til regnskabet, dels for OIOUBL handelsdokumenter og NKS Retursvar håndteres korrekt. Feltet anvendes i forbindelse med IndFak idet værdien angives i udtrukne Stamdata som identifikation af det regnskab stamdata hører til. Tilsvarende bruges værdien til at placere stamdatasættet i den rigtige instans IndFak. Ved accept af indgående rykkere kan man få overført rykkergebyret til en kladde. Angiv kladdetypen her. Ved accept af indgående rykkere kan man få overført rykkergebyret til en kladde. Angiv kladdenavnet her. Feltet er boolesk. Marker feltet med JA hvis du ønsker at E- Bilagspartnere oprettes med dimensionskontostreng som standard. Ellers Nej. JA, er den obligatoriske værdi for brugere af IndFak. NEJ, er den foretrukne værdi for institutioner, der ikke bruger Indfak. Feltet er boolesk. Marker feltet med ja, hvis du tillader at brugere kan acceptere elektronisk købsfaktura og købskreditnota med denne metode. Metoden beregner den afløftede moms på grundlag af linjernes momsbeløb og momsbogføringsopsætningen. For ØSC institutioner skal det være aftalt med institutionen. 01 blev anvendt v Eprocurement til afkodning af Finanskonto i dimensionskontostreng i OIOXML-0.7 dokumenter. 02 opsættes, hvis man benytter IndFak. Benyttes ved afkodning af Budget i dimensionskontostrengen. 03 opsættes, hvis man benytter IndFak. Benyttes ved afkodning af dimensioner fra dimensionskontostrengen. 04 blev anvendt v. Eprocurement. Benyttes ved afkodning af Anlægskonto i dimensionskontostreng i OIOXML-0.7
Artskonto ID kode Omposterings ID Udlignings kode Send E- Bilag Brug kun købshoved dimension Medtag indbakkehoveddimension Automatisk opdatering af Kreditor Side 18 af 111 dokumenter. 05 opsættes, hvis man benytter Indfak. Benyttes ved afkodning af artskontotyperne Finans, Anlæg og Vare i en dimensionskontostreng i OIOUBL-2.0 dokumenter. 99 opsættes, hvis man benytter Indfak. Benyttes ved afkodning af dimensionskontostreng. 99 angives på omkonteringsdokumenter og benyttes til visse check i forbindelse med omposteringsdokumenter. UDLIGNING opsættes, hvis man benytter Indfak. Benyttes ved afkodning af dimensionskontostreng. Angives på omkonteringsdokumenter og benyttes til visse check i forbindelse med udligningen ved ompostering. Benyttes kun for OIOXML-0.7 dokumenter og Eprocurement. Anvendes ikke med IndFak. Benyttes kun for OIOXML-0.7 dokumenter og Eprocurement. Ja betyder, at alle købslinjer kan dimensionskonteres med dimensioner fra indbakkehovedets dimensionskontostreng. Anvendes ikke med IndFak. Feltet har tre mulige værdier: Nej Spørg Ja Feltet angiver om salgs E-Bilag skal sendes automatisk. Den foretrukne opsætning er Ja for afsendelse af salgsdokumenter i umiddelbar forlængelse af bogføring. Ønsker man primært at massebogføre, eller at afsendelsen skal ske batch-vist, anvendes en af de andre indstillinger. Ja angiver, om betalingsoplysningerne fra det modtagne dokument automatisk skal opdatere betalingsoplysninger på kreditor, og om der evt. skal oprettes nyt kreditorbankkort ved accept af indgående E-Bilag. Funktionen virker sammen med opsætning af Handling for den aktuelle betalingsmetode i OIO betalingsmetode -tabellen. Værdien i Handling for den pågældende metode skal være Brug betalingsmetode fra det modtagne dokument. NS vil først søge at oprette komplette betalingsoplysninger. Hvis det ikke kan ske med de medsendte data, oprettes betalingsmetode for en ukomplet betaling. Nej betyder, at opsætningen af Handling i OIO Betalingsmetode-tabellen har sædvanlig betydning for dokumentet.
Kontroller E-bilag afrunding Side 19 af 111 Her angiver du om Navision Stat skal kontrollere for, om der er tastet flere end to decimaler på linjeantal og enhedspriser ved elektronisk salgsfakturering. Den normale opsætning er Nej (blank), da valideringerne for decimaler på enhedspriser og antal er lempet. Oplever du, at en fakturamodtager alligevel validerer skrappere, må du kreditere og bogføre ny faktura, hvor du højst har to decimaler på enhedspriser og antal. Værdien Ja sørger for at gennemføre check for at der kun er to decimaler på enhedspris og antal. I det følgende refereres der til det foranliggende indkøbs- og fakturahåndteringssystem som værende Indfak. OIO Betalingsmetode Sti: Administration/Programopsætning/NS TS Integration/E-Bilag /Styringsopsætning/ Menuknap Funktion/Menupunkt OIO Betalingsmetode I tabellen opsættes, hvorledes Navision Stat skal behandle de informationer om betalingsmåde, kreditor medsender i sin OIOUBL-2.0 faktura (og OIOXL07), dvs. hvilke interne betalingsmetoder det modtagne skal oversættes til. Moderniseringsstyrelsen leverer data til standardopsætning af tabellen. Opsætningen indlæses via dataport. Sti: Økonomistyring/Finans/Periodiske aktiviteter/ Generel data ind og udlæsning/oio betalingsmetoder I felterne Betalings måde kode, Konto Type, Kort Type og OIO Documenttype er opsat de kombinationer af værdier, der forventes modtaget fra kreditorerne. Hvis der modtages kombinationer fra kreditorer, som ikke umiddelbart er legale, kan disse kombinationer oprettes i tabellen for på denne måde at få det modtagne dokument accepteret (jvf. afsnit vedr. kontrol af betalingsoplysninger senere). I tilfælde af at man accepterer ukomplette eller
ugyldige kombinationer, bør du gøre afsenderen opmærksom på, at der er ugyldige data i hans/hendes dokument. Side 20 af 111 Bemærk. OIOXML07 udgår formelt 1. dec. 2011. Opsætningerne for OIOXML07 forventes fjernet i en senere frigivelse. Indtil videre vil der være opsat linjer for såvel OIOUBL-2.0 som OIOXML-0.7 dokumenttyperne PIE, PIP, PCM og PCP. Felt Betalingsmåde Konto Type Kort Art OIO Document Type Betalings Form PM Handling Beskrivelse Feltet indeholder en betalingsmåde eksempelvis Indbetalingskort, Kontooverførsel, FÆLLES INDBETALINGSKORT (93) el. a. Feltet indeholder en konto type eksempelvis FIK, Giro, Bank eller IBAN. Feltet indeholder kortart eksempelvis 01, 04, 71 eller NULL (i tilfælde af at der ikke anvendes indbetalingskort). Her kan tastes de OIO dokumenttyper, som anvendes samt blank. Værdien giver mulighed for at håndtere betalingsoplysninger på de forskellige OIO dokumenttyper (og blank type) forskelligt. Årsagen til at denne mulighed ønskes er, at LæsInd dokumenterne ofte ikke har angivet betalingsinformationer korrekt. Feltet indeholder den betalingsmetode i Navision Stat regnskabet, som svarer til den givne kombination af Betalingsmåde, Kontotype og Kort Art for dokumentet. Feltet kan indeholde følgende handlinger, Spærring med fejl (Handlingen medfører, at der ved forsøg på Accept af dokumentet udløses en fejlmeddelelse.) Brug Kreditor Standard (Ingen opdatering) Handlingen medfører, at betalingsoplysninger fra kreditor stamkortet anvendes på det aktuelle dokument. Der foretages ikke nogen opdatering af betalingsoplysninger på kreditorstamkortet. Brug betalingsmetode fra det modtagne dokument (Handlingen medfører, at betalingsoplysninger fra det modtagne dokument anvendes afhængig af Opsætningen i Styringsopsætningens felt Automatisk opdatering af kreditor: JA/Nej.) For Ja anvendes dokumentets betalingsdata ved oprettelsen, og kreditoren opdateres samtidig. For Nej valideres dokumentets betalingsdata mod de opsatte betalingsoplysninger på Kreditorkortet. Vis meddelelse (Handlingen medfører, at der vises en meddelelse angivet i feltet Meddelelse.)
Maske Meddelelse Side 21 af 111 Her vælges hvorledes betalingsoplysningerne fra dokumentet skal overføres til den oprettede købsfaktura i Navision. Her kan opsættes tekst for en skærmmeddelelse, som vises, hvis der for den fundne betalingsmetode er opsat Vis meddelelse i feltet Handling. I OIO betalingsmetode tabellen skal kun opsættes komplette betalingsmetoder. Ved accept af et købsdokument undersøger Navision Stat om dokumentets data matcher en linje med en komplet betalingsmetode. Hvis ja, anvendes den, og fakturaen accepteres. Hvis der ikke findes data der matcher en opsætningslinje for en komplet betalingsmetode kan det skyldes flg.: manglende opsætning eller fakturaafsender har angivet mystiske informationer om Betalingsmetode, Konto Type eller Kort Type, eller afsender netop IKKE har lagt data til identifikation af en komplet metode. I de to første tilfælde kan du vælge at udbedre med en tilføjelse i opsætningen. I tredje tilfælde vil Navision spørge, om du ønsker at oprette med en ukomplet betalingsmetode (CPR, CVR eller P-nr. betaling). Der skal ikke lappes i opsætningen. Findes information om komplet betaling, oprettes dokumentet med komplette betalingsoplysninger afhængig af opsætningen for Automatisk opdatering af kreditor. Når Automatisk opdatering af kreditor på Styringsopsætningen er Ja : Der søges på det modtagne dokument for nødvendige data til afvikling af komplet betaling. Hvis dette er i orden, accepteres fakturaen med en komplet betaling baseret på oplysningerne i dokumentet. Hvis den aktuelle betalingsoplysning ikke findes på kreditoren, oprettes den. Hvis eksempelvis kortart eller betalingsadresse er anderledes så ændres den. Hvis der anvendes en anden bankkonto så oprettes nyt bankkort. Findes der i bilaget ikke tilstrækkelige data til at foretage en komplet betaling, søger Navision Stat om der findes P, CVR, SE, CPR-nummer på det modtagne bilag. Navision opretter herefter NKS betalingsdata til en ukomplet betalingsmetode og anvender disse på dokumentet. Denne indstilling anbefales. Når Automatisk opdatering af kreditor på Styringsopsætningen er Nej : Ved accept valideres at betalingsoplysningerne på det indgående dokument (se Faneblad Betaling) er i overensstemmelse med betalingsmetode og oplysning, opsat på kreditors opsætning.
Side 22 af 111 Ved afvigelse standses accept med meddelelse og du må justere opsætningen. Ved Match: Funktionen afhænger af feltet Handling i OIO betalingsmetode tabellen. A) Handling = Brug betalingsmetode fra det modtagne dokument, OG der findes en mapning i OIO betalingsmetodetabellen: Så undersøges efterfølgende om data i det ankomne dokument stemmer med opsætningen på kreditor. Er det tilfældet, fortsættes oprettelsen. Hvis data til betalingsmetoden findes OG afviger fra kreditorkortets, så standses med meddelelse om at kreditor oplysninger skal rettes. Hvis data til den fundne betalingsmetode mangler, får du en dialogboks, om du ønsker at NS forsøger at oprette en ukomplet betaling. Svar Ja hvis det ønskes, ellers Nej og accepten standses. B) Handling = Brug betalingsmetode fra Kreditorkort, OG der findes en mapning i OIO betalingsmetodetabellen: Dokumentet accepteres og oprettes med betalingsdata fra opsætningen. De anvendte betalingsdata kan i så fald afvige fra de medsendte og kræve en forklaring i forbindelse med frigivelse. P nummer og CVR nummer er tidligere i processen anvendt til at identificere det relevante kreditorkort. Hvis der svares Ja til anvendelse af ukomplette betalingsmetoder, anvendes disse oplysninger igen. Det undersøges, hvilke værdier af P-nummer, CVR-nummer, SE-nummer og CPR-nummer der skal anvendes. Der anvendes fortrinsvist P-nummer betaling ellers CVR nummer. CVR nummer er obligatorisk på OIOUBL-2.0 faktura, og denne værdi anvendes hvis P-nummer ikke findes. For OIOXML-0.7 faktura kan anvendes såvel CVR som SE nummer til identifikation af kreditor. I mangel af P-nummer anvendes CVR nummer, hvis det findes, ellers SE. På Moderniseringsstyrelsens hjemmeside www.oes.dk på Navision Stat release sitet finder du fil til opsætning af OIOBetalingsmetode tabellen OIO Betalingsmetoder_ddmmåååå.txt. Se nærmere i Systeminfoen for den seneste frigivelse. Anvend den seneste version.
Indgående Gebyr og konto Sti: Administration/Programopsætning/NS TS Integration/E-Bilag /Gebyropsætning Side 23 af 111 Bemærk: Gebyropsætningstabellen blev anvendt for OIOXML-0.7 dokumenter. Opsætningen er IKKE relevant for IndFak og OIOUBL.2 købsdokumenter. Opsætningen udgår i en senere release. XML-bro Sti: Administration/Programopsætning/ Generel Integration/NS TS Integration/XML Bro Her finder du opsætningerne, vedrørende Navision Stats dannelse og afkodning af XML-dokumenter som afsendes, hhv. modtages af Navision Stat. Kun brugere med opsætningsrettighed til generel integration kan foretage opsætninger. Det vil være usædvanligt, at du som bruger i institutionen eller dens regnskabsafdeling skal ændring i opsætningen. Moderniseringsstyrelsen levere og vedligeholder standardopsætning til punkterne XML Bro Mapninger og Kodelister. Du skal kun finpudse opsætningen under kodelistemapninger, hvis du anvender enheder som ikke er indeholdt i Moderniseringsstyrelsens standardopsætning. Har institutionen behov for andre ændringer end i kodelistemapningen, skal der ske en dybtgående analyse af konsekvenserne inden ændringen iværksættes. XML-bro Mapning Sti: Administration/Programopsætning/ Generel Integration/NS TS Integration/XML Bro/XML Bro mapninger Her finder du de dokumentspecifikke opsætninger, der vedrører Navision Stats behandling af indad- og udadgående XML-handelsdokumenter. Opsætningerne rummer mapning på feltniveau mellem Navision Stats ind/udbakketabeller og elementerne i de respektive xml-dokumenter. Hvert dokument som håndteres, har sit eget xmlns (Namespace). Der findes et XML Bro mapningskort for hvert dokument som håndteres. Bemærk: Det vil være udsædvanligt, hvis du i en Navision Stat institution selv skal foretage nogen som helst rettelser i disse opsætninger! Moderniseringsstyrelsen frigiver datafiler til vedligehold af standardopsætningen af tabellerne. Rettelser i tabellerne har vidtgående betydning for transportlagets funktion.
Bemærk: Anvend kun opsætningsfil som svarer til din aktuelle version af NavisionStat. Filerne er navngivet svarende til Navision Stat versionen. Side 24 af 111 Bemærk: Har institutionen behov for en ændring skal der ske en dybtgående analyse af konsekvenserne inden ændringen iværksættes OG institutionen er selv ansvarlig for at sikkerhedskopiere denne opsætning. Bemærk: Har du behov for ændringer eller tilføjelser i XML bro mapningerne eller helt nye XML brokort, skal du sikre dig dokumentation for din opsætning. Det kan ske ved at du udlæser opsætningen helt eller delvist. Moderniseringsstyrelsen opsætningsfil til Navision Stat 5.3 overskriver dine lokale rettelser i alle de XML-bro kort som Moderniseringsstyrelsen understøtter. Hvis du foretager rettelse i en af disse mapninger, skal du derfor selv efterfølgende tilføje/tilpasse for at genetablere dine lokale rettelser. Har du oprettet nye XML bro mapningskort m andre navne og til andre Namespaces vil de ikke være berørt ved indlæsning af Standard opsætningen. Kodelister Under dette menupunkt opsætter du lister for værdier som skal skiftes ud ved mapningen, eksempelvis enhedskoder. Enheder Under dette menupunkt finder du tabellen med de enhedskoder for køb og salg der er sat op i dit regnskab Kodelistemapning Du skal specifikt sikre at dine enhedskoder er mappet i forhold til de OIOUBLgyldige værdier. Kun hvis standardopsætningen dækker alle dine private enhedskoder skal du ikke gøre noget Der er for OIOUBL-2.0 dokumenter defineret en fast liste af gyldige enhedskoder. Enhedskoder fra den liste SKAL optræde i OIOUBL-2.0 dokumentet. Der må IKKE mangle enhedsværdier i dokumentet eller anvendes værdier som er ukendt på listen. Værdierne skal kunne findes i urn:un:unece:uncefact:codelist:specification:66411:2001, som eksempelvis kan ses her: http://docs.oasis-open.org/ubl/os-ubl- 2.0/cl/gc/cefact/UnitOfMeasureCode-2.0.gc Derfor findes i Navision Stat en kodelistemapning, som anvendes i XML-Bro mapningen. Med Navision Stats XML bro levers listen med de enhedskoder som skal anvendes i OIOUBL-2.0, samt en standard kodelistemapning mellem et antal typiske enhedskoder i Navision og tilsvarende værdier i OIOUBL-2.0. De findes under kodelisten benævnt UNITCODE.
Bemærk: Listen med mapninger af enhedskoder kan ikke leveres komplet fra Moderniseringsstyrelsen, da de enkelte regnskaber har frihed til at vælge egne enhedskoder. Du skal derfor selv, inden du afsender eller modtager OIOUBL-2.0 handelsdokumenter (faktura, kreditnota, ordre mv.), hvor du sælger eller køber i enheder (stk. styks, kasse, palle, time timer, liter, ton, skovrummeter, mv.) sikre dig, at alle nødvendige opsætninger mellem dine værdier i Navision Stat i tabellen Enheder og OIOUBL s enhedskoder (EA, BX, PF, HUR mfl.) er gennemført. Side 25 af 111 Du skal oprette separat kodelistemapning for udadgående hhv. indadgående dokumenter. I XML bro mapningerne er det de steder hvor det er relevant, opsat at UNITCODE kodelistemapningen skal anvendes. På ovenstående billede ses de tre tabeller der indgår i kodeliste mapningen. Den første tabel NS TS Kodeliste udfyldes automatisk ved indlæsning af datafil med én linje m. koden UNITCODE. Den sidste tabel NS TS Kodelisteværdi udfyldes automatisk ved indlæsning af datafil med alle gyldige enhedskodeværdier i kodelisten for OIOUBL-2.0. Den midterste tabel opsættes ligeledes med de mest oplagte mapninger mellem tabellen Enheder tabellen og OIOUBL-2.0 enhedskoder. Bemærk: Du skal tjekke at de nødvendige mapninger for dine værdier i tabellen Enheder er dækket ind af denne standardopsætning. Hvis du har værdier i tabellen Enheder, som ikke figurerer i NSTS kodeliste mapning tabellen (den midterste tabel), skal du selv opsætte de nødvendige mapninger.
Opsætningen er første gang beskrevet i Opsætnings og konverteringsvejledningen i forbindelse for overgang fra NS 3.60 til NS 5.0. Side 26 af 111 Bemærk: Har du behov for sådanne ændringer eller tilføjelser, skal du sikre dig dokumentation for din opsætning. Når du indlæser XML-bro mapningen overskrives din lokale kodelisteopsætning. Efter indlæsning af standard opsætningen skal du derfor foretage genopsætning af dine lokale kodelistemapninger. Det sker således: Sti: Administration/Programopsætning/Generel Integration/NS TS Integration/XML Bro/Kodeliste. Med menuknappen Kodeliste vælger du om du vil opsætte en indadgående eller udadgående mapning. Der skal opsættes mapninger begge veje. Vær opmærksom på at du godt kan have flere enheder som skal oversættes til samme OIOUBL kode og omvendt. Eksempel: Eksempel: Både stk. og styk udadgående oversættes til EA og indadgående kan BX og CS oversættes til kasse (Case har bl.a. betydningen kasse) Indadgående kodelistemapning I NSTS kodeliste vælger du linjen med Koden = UNITCODE. Med Menuknappen Kodeliste vælger du menupunktet Indgående Map
Side 27 af 111 I feltet Fra vælges en værdi fra NS TS Kodelisteværdi dvs. en officiel værdi som kan optræde i et indadgående OIOUBL2 dokument. I feltet Til skrives den tilsvarende enhedskode fra Enheder tabellen. Her må du gerne være lidt kreativ, idet du jo vanskeligt på forhånd kan gætte alle de officielle enhedskoder som dine leverandører kan finde på at anvende. Du kan opsætte flere officielle værdier til at pege på samme interne værdi, så du på den måde har mulighed for at dække dig nogenlunde ind. Udadgående kodelistemapning I NSTS kodeliste vælger du linjen med Koden = UNITCODE. Med Menuknappen Kodeliste vælger du menupunktet Udgående Map I feltet Fra vælger du dine enhedskoder fra Enheder tabellen. I feltet Til angiver du den tilsvarende værdi som skal optræde i OIOUBL2 dokumenter. Du skal opsætte en linje for hver enhedskode i Enheder tabellen. Periodiske aktiviteter Her finder du forskellige kørsler som du måske, men ikke nødvendigvis får brug for.
Indlæs XML fra fil Denne rapport skal du bruge hvis du har behov for at indlæse en fil (eksempelvis OIOUBL faktura) som skal mappes ind i Navision uden at du kan benytte transportlaget. OBS: Denne funktion mapper kun data du får ikke mulighed for at anvende Vis original idet filen ikke lagres i Elektronisk arkiv. Side 28 af 111 Importer eksempelskabelon Dette punkt benytter du, hvis du har brug for at oprette indhold i en ny mapningsbro og opsætte mapninger for et nyt dokument. Det vil sandsynligvis ikke være aktuelt, og er derfor ikke beskrevet yderligere her. Dokumentation XML-bro Rapport som udskriver XML-bro mapningen. Det er en voldsom datamængde, så sørg for at bruge Vis udskrift og filtrere så snævert som muligt inden du evt. udskriver på papir. Indlæs / udlæs opsætning Her finder du dataporte til indlæsning af opsætninger for henholdsvis XML Bro opsætningen, Profilopsætningen og Endpoint Key Type Opsætning. De benyttes normalt kun i forbindelse med indlæsning af opsætningsfiler frigivet af Moderniseringsstyrelsen. Brugen er i de tilfælde beskrevet i Systeminfoen udgivet sammen med frigivelsen. Konsulter systeminfoen. Integration m. IndFak Check stamdata Sti: Administration/Programopsætning/Generel Integration/NS TS Integration/E-Bilag/Check Stamdataopsætning Rapporten Check stamdata opsætning foretager check på opsætningsdata der udtrækkes til IndFak.
Side 29 af 111 Fanebladet NS E-Bilag Setup log skal normalt afvikles uden filtre idet rapporten checker kreditorkort der er sat op med Ebilagspartner som skal trækkes ud i stamdata. Fanebladet Indstillinger. Her skal du markere Kontrollér Alias for Ja, når du anvender Alias OG dit regnskab anvender IndFak. Bemærk: Du skal anvende rapporten hvis dit regnskab benytter IndFak. Rapporten skal køres hver gang der foretages ændringer i de opsætninger som indgår i stamdataudtrækket, dvs. virksomhedsoplysninger, finanskonti, dimensioner, kreditorer, anlæg og budgetter. Rapporten tjekker de kreditorer der har en E-Bilag Partner som er opsat til Eksporter kreditorstamdata = JA, OG Kreditorkortets felt Spærret = <blank> eller <Betalinger> Rapporten tjekker for om kreditorkortet har data i et af felterne CVR, SE, P Nr., CPR, EAN og Anden ID tjekker Kreditor CVR nummer; giver fejl hvis feltet er tomt eller længere end 16 karakterer.
Tjekker Kreditor CVR nummer; giver fejl hvis samme værdi optræder i stamdata for mere end et kreditorkort i stamdata. Tjekker Kreditor CVR nummer for 8 cifret heltal og giver meddelelse for alle afvigelser herfra. Besked om at tjekke da debitor kan være udenlandsk. Side 30 af 111 Derudover renser rapporten visse data i e-mail. Endvidere kontrolleres for manglende beskrivelse på Budget, Anlæg, Dimension og Dimensionsværdi. Eksempler på meddelelser: Rapporten skal give Opsætningen er uden fejl for alle de områder den undersøger. For hver linje der afviger fra rapportens tjek, ser du en linje i rapporten med en besked. For Kreditorsektionen gælder dog at man skal skelne mellem fejl og advarsler. Fejl skal rettes, da stamdataudtrækket ellers fejler. Advarsler kan forekomme vedrørende Kreditors CVR nummer, idet IndFak accepterer mellem 1 og 16 karakter, medens et dansk CVR nummer altid er et 8cifret heltal. Da kreditorerne indtil videre forventes altovervejende at være danske, giver rapporten advarsel når et opsat kreditor CVR-nummer afviger fra alm. dansk standard, idet der måske kan være tale om slåfejl. Disse afvigelser vil påkalde sig opmærksomhed, ved hver kørsel af rapporten. Hvis man har et vist antal kreditorkort som skal være opsat med anderledes værdi i CVR nummer kan man evt. føre dem på en liste, eller tildele disse kreditorer særlige U-numre så man af oversigten umiddelbart kan se om det ser OK ud. Fejl på CVR-nummer gives ved manglende eller for lang værdi, eller ved dubletter.
Side 31 af 111 Ovenstående eksempel viser at der er en fejl pga. dubleret CVR nummer, samt en fejl fordi CVR nr. er længere end 16 karakterer. Endvidere gives advarsel om CVR nr., der afviger fra alm. dansk syntaks på 8cifret heltal. Yderligere vises fejl advarsel for et Alias der mangler beskrivelse. Bemærk: Rapporten rapporterer alle de tilfælde, hvor Kreditorkortets felt CVR nr. afviger fra et 8 cifret heltal. Hvis feltet er tomt, data er for langt eller data findes som dubletværdi på en anden kreditor m stamdataopsætning, markerer rapporten fejl. Ret fejlen! Bemærk: Hvis du har opsat et 10cifret heltal vil IndFak opfatte dette som et potentielt personnummer. IndFak har særlig opsætning, hvor din institution kan bestemme om denne værdi må indlæses, eller skal udelades. Hvis du har udenlandske kreditorer som du ønsker overført til IndFak, skal du derfor sikre dig at de på kreditorkortets CVRnr felt IKKE er opsat med 8 eller 10 cifret heltal. Tilføj gerne en landekode foran. Bemærk: Valideringen af stamdata forventer at der findes opsat standarddimensioner i regnskabet, da sådanne udlæses i udtrækket. For at udgå eksportfejl skal du sikre dig at regnskabet har opsat en standarddimension/forslagsdimension uanset at du skal bruge den. Opsæt eksempelvis det foretrukne delregnskab på en finanskonto eller kreditor. Eksporter stamdata Bruger du IndFak skal du have opsat det tilhørende MasterdataAdvanced stamdataeksportjob. Normalt er der opsat job på serveren til at køre det en gang pr. døgn. Hvis det også er angivet i Navision i NS TS Integrationstabellen, kan du også starte afsendelse inde fra Navision ved at aktivere en kørsel her: Sti:\Administration\IT-administration\WFS\Send Stamdata til WFS. Se evt. den relevante version af installationsvejledningen for transportlaget t. NS5.3 mht. opsætning af stamdataeksport og opsætning i Navisions NSTS integrationstabel. Stamdata udtrækket til IndFak indeholder i grove træk følgende: Finanskonti der henhører til resultatopgørelsen og som ikke er spærrede Kreditorer der ikke er spærret og som er opsat med eksporter stamdata. Anlæg der ikke er spærret eller solgt. Dimensioner og dimensionsværdier der ikke er spærret. Alias der ikke er spærret. Spærrede dimensionskombinationer Forslagsdimensioner som ikke er spærret, hørende til Kreditorer, Finanskonti og Anlæg
Side 32 af 111 Eksportér transaktionsdata Bruger du IndFak skal dit regnskab sende informationer fra Navision Stat til IndFak om hvilke fakturaer der er betalt (helt eller delvist). Det giver IndFakbrugeren mulighed for at se betalingsstatus for sine dokumenter. Disse data overføres med Transaktionsdatajobbet som skal være opsat på serveren, normalt m. schedulleret afvikling. Hvis jobbet er angivet i NSTS Integrationstabellen kan du også igangsætte det fra Navision: Sti:\Administration\IT-administration\WFS\Send Transaktionsdata til WFS. Alias i Navision og IndFak Alias overføres fra Navision til IndFak sammen med MasterDataAdvanced. Alias og dens værdier eksporteres i stamdataudtrækket på samme måde som en dimension. Det betyder at Alias er underlagt samme krav som dimensioner der skal eksporteres. Brugeren der konterer Alias i IndFak ser det som en dimension. I IndFak sker der ingen udfoldning, og man kan i IndFak derfor ikke se hvilken kontering et Alias repræsenterer. Det konterede Alias føres fra IndFak til Navision i dimensionskontostrengen. Der er knyttet særlig funktionalitet i Navision Stats behandling/udfoldning af Alias fra en dimensionsstreng. Derfor er Dimensionen Alias reserveret til det særlige funktionalitetsområde i Navision Stat der er dækket af Aliaskontering. Der kan i selve Navision Stat ikke konteres på en dimension Alias. Opsætning og anvendelse af Alias er i øvrigt beskrevet i manualen for Finans. Hvis du arbejder med Aliaskontering med integration til sager skal du også orientere dig i Sager manualen. Dimensionens Alias opløses af behandlingsprocessen i de elementer (konto, vare, anlæg, dimensioner, sagsoplysninger, Momsbogføringsgrupper mv.) den består af jf. den aktuelle opsætning i Aliaskontering (Sti: Økonomistyring/Opsætning/Alias/Aliaskontering). Hvis der er konflikt mellem konto og dimensioner konteret direkte i strengen, og finanskonto og dimensioner konteret i Alias, så er det altid værdi afledt af Alias der vinder.