18. oktober 2020

Oppdatert 7. januar 2022

VBus versjon 11.11 – 16.10

SAF-T: Standard Audit File - Tax

Jeg skal ikke skrive meget om SAF-T, det er det andre som gjør. Men hvis du bruker VBus til regnskap, så MÅ du kontrollere to innstillinger i Bedriftsopplysninger. Det ene har det kunstneriske navnet Aut.gen.trans.beh. og må settes til 2 [Produseres fortløpende]:

Hvis Aut.gen.trans.beh. er satt til 0 eller 1, så lages det summerte (aggregerte) posteringer i hovedbok for føringer mot reskontro og mva; de med Opprinnelse = 2 [Automat­generert]. Bilags­nummeret hentes da fra den bilags­serie du (i Bedrifts­opplysninger) har angitt i Aut.gen.trans.serie. Når Aut.gen.trans.beh. er satt til 2 [Produseres fortløpende] så får du en transaksjon i hovedbok for hver reskontro­postering og separate mva-posteringer i hovedbok for hvert bilag. Og de automat­genererte posteringene har samme bilags­nummer som de øvrige på bilaget. Du får altså flere transaksjoner i hovedbok, men det er lettere å spore transaksjonene til kilden; bilaget som skapte dem.

De av dere som har hatt Aut.gen.trans.beh. satt til 0 eller 1 og forsøkt eksport til SIE-format (mye brukt i Sverige), har fått en advarsel om at bilagene ikke går i null. Og årsaken er altså at de automat­genererte posteringene ikke har samme bilags­nummer som kilde­bilaget – fordi VBus samler opp og aggregerer beløpene på de automat­genererte posteringene – som dermed må ha egne bilags­nummer (fra egen serie). Og SAF-T formatet krever det samme som SIE; at de automat­genererte bilagene har samme bilags­nummer som kilde­bilagene. Visma jobber med denne problem­stillingen og det er løst i versjon 15.01.0 for de som har satt Aut.gen.trans.beh. satt til 1 [Akkumuleres pr. ansvarsenhets­kombinasjon] uten at jeg har sett på løsningen.

 

Det andre du må gjøre er i Regnskapsbehandl. (fremdeles i Bedriftsopplysninger) å krysse av for Hovedboks­transaksjoner pr. faktura:

Du får ikke flere bilag i hovedbok (med mindre du fremdeles bruker versjon 5.20 eller tidligere av VBus – og det tror jeg neppe du gjør), men posteringene blir supplert med mer informasjon. Og SAF-T formatet trenger denne informasjonen. Når du er inne og sjekker dette kan du like gjerne krysse av for Hovedbokstrans. pr. ordre ved postering fra produkttrans. Dette gjelder bilag med Opprinnelse 16 [Bokføring av kostnader] – altså bokføring fra lagertelling, korreksjoner og produksjon (herunder vare­forbruket), og Opprinnelse 40 [Korrigerte kostnader]; den bokføringen du får når det bokførte uttak fra lager (enten det er salg, vare­forbruk i produksjon eller redusert beholdning ved lager­telling eller korreksjon) er merket med at kostnadene er midlertidige – altså at uttaket er fra et vareparti med urealisert lagerøkning; med andre ord at vareinngangen venter på faktura­mottak, realisering av produksjon eller kreditering av retur fra kunde – hvis kostprisen på varepartiet blir endret ved realisering av vareinngangen, f.eks. ved endret valutakurs på innkjøp i valuta.

Den siste setningen i forrige avsnitt har 99 ord. Det er ikke godt språk. Beklager det. Send meg en epost om du har behov for en omformulering. 

Den litt triste beskjeden er at om du ikke har hatt Aut.gen.trans.beh. satt til 2 [Produseres fortløpende] og krysset av for Hovedboks­transaksjoner pr. faktura i Regnskapsbehandl. i hele 2020, så vil SAF-T rapporten ikke være helt innafor om du i 2021 får bokettersyn. Visma jobber altså med saken, men det er ikke helt enkelt å rekonstruere de posteringene du ville ha hatt (hypotetisk konjunktiv?) om du hadde hatt fornuftige innstillinger hele året. På plussiden; hvis du i 2022 får bokettersyn og blir bedt om å sende inn en SAF-T rapport for 2021, så har du alt på plass. Dvs. at formatet er rett. Det jeg har skrevet om her er ingen garanti for at du ikke har inkonsistens i reskontro, bunter som ikke balanserer, ført fradrag for frynsete utgifter, brukt feil avg.kode, hvitvasket penger fra tvilsomme transaksjoner eller andre føringer som kan tiltrekke seg kontroll­myndighetenes oppmerksomhet. Men du har i alle fall rett format på SAF-T rapporten når du sender den inn…

Og så får jeg legge til at om du har en versjon av VBus som er tidligere enn 11.11, så har mangler du mulighet for å kjøre ut SAF-T fra VBus. Og da har du knappe 14 dager på deg til å få gjennomført en oppgradering. For 14 dager er normalt fristen du får når melding om bokettersyn ligger i postkassa. Selv om det er mulig å kjøre ut en SAF-T rapport fra versjon 11.11, er det gjort flere forbedringer på senere versjoner:

12.10.0:

SAF-T-eksport

Filen som ble opprettet av behandlingsvalget Eksporter SAF-T i tabellen Bedrift, inkluderte ikke desimalene for Mva sats. Dette er nå løst.

 

13.10.1:

SAF-T-tilordning og Kontoundertype

For å klargjøre for eksport til SAF-T-filer har vi lagt til funksjonalitet for å tilordne Hovedbokskonto mot SAF-T-standardkontoene.

En ny tabell Standardkonto er lagt til i systemdatabasen som skal lagre SAF-T-standardkontoene. Et nytt behandlingsvalg, Angi standardkonto, er lagt til i tabellen Hovedbokskonto. Dette oppretter et tilordningsforslag, og fyller også ut Kontoundertype, som skal brukes for andre rapporteringsformål. Dette behandlingsvalget gjør det mulig å velge mellom standardkontoene 1 - 4-sifret SAF-T og 2 - 2-sifret SAF-T fra Skatteetaten (norske skattemyndigheter).

I dialogboksen for behandlingsvalget finner du alternativer for å fylle ut alle tomme felt, som er standard, eller du kan velge å erstatte alle.

Først må du importere filen med SAF-T-kontoene til tabellen Standardkonto i systemdatabasen (vbsys). Filen Standard_accounts.txt er plassert i mappen Nor.int. Deretter kan du kjøre behandlingsvalget Angi standardkonto i tabellen Hovedbokskonto.

Behandlingsvalget oppdaterer kolonnen SAF-T kontonr med et foreslått kontonummer. Hvis det blir funnet et nøyaktig treff i tabellen Standardkonto, brukes dette kontonummeret. Hvis ikke foreslås den forrige kontoen med samme første siffer. Kolonnen Standardkonto status viser statusen til den foreslåtte tilordningen. I tillegg fylles feltet Kontoundertype ut. Kontoundertype vil bli brukt for andre rapporteringsformål.

1 - 4-sifret SAF-T – Bedrifter med en eksisterende kontoplan som er identisk med de norske firesifrede standardkontoene, skal bruke dette.

2 - 2-sifret SAF-T – Bedrifter med en eksisterende kontoplan som avviker betydelig fra de norske standardkontoene, skal bruke dette.

Merk: Behandlingsvalget Angi standardkonto kan bare brukes når hovedbokskontoene er firesifret.

Denne funksjonaliteten er foreløpig bare relevant for norske bedrifter.

 

13.10.0:

Nasjonale filer for Norge er oppdatert

Et nytt oppsett for SAF-T er lagt til i norlay.txt og norstd.txt. Også data for den nye tabellen Standardkonto er inkludert i norstd.txt.

 

14.00.1:

Oppdatert fil for standardkontoer

Skatteetaten har oppdatert filen for standardkontoer som benyttes i SAF-T. En oppdatert Standard_account.txt er inkludert i denne versjonen og kan importeres til tabellen Standardkonto.

Oppdatert til AuditFileVersion 1.10

SAF-T AuditFileVersion har blitt oppdatert til ver 1.10.

Filtrering av data

Det er nå mulig å filtrere vekk Kundenr, Lev.nr og Ansvarsenhet 1 - Ansvarsenhet 12 uten data fra eksporten til SAF-T.

Eksporter SAF-T - MVA-koder med MVA-kompensasjon

Når en Avgiftskode var koblet til en Merverdiavgift som var merket med 2 - Benytt mva-kompensasjon, ble ikke dette reflektert i SAF-T-filen. Dette er nå løst.

 

14.10.0:

Oppdaterte standardkontoer

Den norske standardkontofilen som brukes for SAF-T (Standard_account.txt) har blitt oppdatert til den nyeste versjonen fra Skatteetaten.

XML-elementet NumberOfEntries (<n1:NumberOfEntries>)

XML-filen som ble produsert av Eksporter SAF-T, viste antall Hovedbokstransaksjon i stedet for antall Bilag. Dette er nå løst.

Utelatte XML-elementer

Eksporter SAF-T eksporterte ikke XML-elementene GroupingCategory (<n1:GroupingCategory>) og GroupingCode (<n1:GroupingCode>). Dette er nå løst.

Overflødige forekomster av XML-elementene CustomerID og SupplierID

Eksporter SAF-T eksporterte XML-elementene CustomerID (<n1:CustomerID>) og SupplierID (<n1:SupplierID>) i linjene (<n1:Line>) under hovedboksposter (<n1:GeneralLedgerEntries>) for alle linjer, og ikke bare for linjer med en hovedbokskonto knyttet til kundereskontro og/eller leverandørreskontro. Dette er nå løst.

IB utelatt på resultatkontoer

Eksport til SAF-T tok ikke med inngående balanse på resultatkontoer. Dette er nå løst.

Manglende Avg.kode når 0% mva.

Eksport til SAF-T utelot elementer under <n1:TaxInformation> hvis raden i tabellen Hovedbokstransaksjon hadde en mva.kode med 0% mva. Dette er nå løst.

Oppdatert "NorFirm.txt"

Det var tidligere problemer med feil satser i tabellen Merverdiavgift og ugyldig SAF-T avgiftskode i tabellen Avgiftskode, men de er nå løst i den norske standardfilen for bedriftsdata NorFirm.txt).

 

15.00.0:

Felt med nytt navn

Navnet på feltet Altinn-sti i tabellen Systemopplysninger har blitt endret til SAF-T-sti. Dette feltet ble tidligere brukt av den utdaterte Altinn-integrasjonen. Nå brukes det av behandlingsvalget Eksporter SAF-T i tabellen Bedrift.

Avrunding av strengverdier

For å oppfylle spesifikasjonene for maksimal strenglengde for data eksportert til SAF-T, vil følgende datatyper avrundes på følgende måte:

·         Kode: 9 tegn

·         Kort tekst: 18 tegn

·         Medium tekst 1: 35 tegn

·         Medium tekst 2: 70 tegn

·         Lang tekst: 256 tegn

·         ISO-landskode: 2 tegn

·         ISO-valutakode: 3 tegn

SAF-T XML-fil, format

Den eksporterte XML-filen ble ikke korrekt lagret i UTF-8-format. Dette er nå løst.

Merk: Løsningen i tidligere versjoner er å åpne XML-filen i en teksteditor og lagre den i UTF-8-format.

 

15.01.1:

Utelat verdier når SAF-T-fil ble eksportert

Når man valgte et av alternativene for "Utelat" når behandlingsvalget Eksporter SAF-T ble kjørt, ble det ikke kontrollert om det fantes noen Kundetransaksjon, Leverandørtransaksjon eller ansvarsenheter. Dette er nå løst.

Avgiftskode i stedet for Mva-beløp som utvalgskriterium

Skatteinformasjonsstrukturen for Hovedbokstransaksjon vil nå bli eksportert til SAF-T-filen hvis det finnes en Avgiftskode. Tidligere ble Mva-beløp brukt som utvalgskriterium.

Akkumulerte beløp på hovedbokskonto

Endringer er gjort for å kunne skape korrekte transaksjoner i tilfeller hvor beløp fra flere fakturaer ble akkumulert på hovedbokskonto. Det vil si bilag som ble akkumulert fordi verdien 1 - Akkumuleres pr. ansvarsenhetskombinasjon i Aut.gen.trans.beh. i Bedriftsopplysninger var satt ved bokføringstidspunktet.

Behandlingsvalget Eksporter SAF-T

Behandlingsvalget Eksporter SAF-T har blitt flyttet fra tabellen Bedrift til tabellen Bedriftsopplysninger.

Oppdatert felt-mapping

Mapping har blitt oppdatert for følgende tagger i filen:

·     <GLPosting date> - Valuteringsdato (tidligere Opprettet dato)

·     <JournalID> - Bilagsjour.nr (tidligere "A")

 

15.10.0: 

Automatisk genererte transaksjoner

Det er to oppsett i systemet som kan forårsake akkumulering av transaksjoner i tabellen Hovedbokstransaksjon, som kommer i konflikt med SAF-T-formatet. Disse to parametere i tabellen Bedriftsopplysninger blir endret under oppgraderingen av bedriftsdatabasene:

·           Aut.gen.trans.beh. settes til 2 - Produseres fortløpende (anbefalt).

·           Hovedbokstransaksjoner pr. faktura (anbefalt) i Regnskapsbehandl. aktiveres.

Med innstillingene satt som beskrevet over, vil all informasjon som kreves av SAF-T-formatet være tilgjengelig for hver transaksjon.

Ugyldig struktur i XML-fil

I noen scenarier kunne den genererte filen ha en ugyldig struktur i noen av elementene. Dette er nå løst.

Spesialavgift på ordre

Spesialavgift brukt på ordre ble eksportert som en egen linje i stedet for å inkluderes i beløpet til den åpne posten. Dette er nå løst.

Behandlingsvalget Eksporter SAF-T går tomt for minne

Når behandlingsvalget Eksporter SAF-T ble kjørt på store datamengder, kunne eksporten stanse på grunn av stort minneforbruk. Dette har nå blitt optimalisert og løst ved at minne frigis under eksport.

Flere mva.satser pr. ordre

Et problem knyttet til det å ha flere ordrer med flere mva.satser i samme journal, har blitt løst. Problemet oppstod bare hvis aggregeringen av hovedbokstransaksjoner var aktivert i feltet Aut.gen.trans.beh. i tabellen Bedriftsopplysninger.

Bilag uten Bilagsart

Et problem ved eksport av bilag uten bilagsart har blitt løst.

Mva-beløp

Fordeling av mva-beløp mellom transaksjoner kunne i noen tilfeller bli feil. Dette er nå løst.

 

16.00.0

Justert utlegg av data

Bokstavene "MVA" legges ikke lenger ut i taggen <TaxRegistration>.

 

16.01.0

Delt eksportfil for SAF-T hvis antall transaksjoner er svært høyt

Under behandlingsvalget Eksporter SAF-T er det lagt til alternativ for Eksporter grunndata og hver periodes transaksjoner i separate filer. Velges dette opprettes det én XML-fil med grunndata og 12 XML-filer med overskrift og hovedbokstransaksjoner.

Merk: Dette alternativet skal brukes av selskap med store datamengder der XML-filen blir større enn 2 GB hvis den eksporteres i én fil, fordi skattemyndighetene ikke kan håndtere filer som er større enn 2 GB.

·         Utelat: Grunndata – utelater grunndata fra XML-filen

·         Utelat: Hovedbokstransaksjoner – utelater hovedbokstransaksjonene fra XML-filen.

 

16.10.0

Oppdatert "Standard_account.txt"

Filen med standard SAF-T-kontoer (Standard_account.txt) i mappen Nor.Int har blitt oppdatert med manglende nye kontoer.

 

Se også frode.antun.no/VBus/blogg/SAFT.

 

 

Det kan være klokt å oppgradere selv om man er på versjon 11.11 eller senere.

 

 

Forrige gang skrev jeg at jeg neste gang skulle skrive om ordreutveksling med AutoInvoice. Det får bli neste gang.

 

Resten av min blogg kan du lese her: frode.antun.no/VBus/blogg 

 

frode@antun.no