Brukertips i Visma Business og -Regnskapsbyrå

Denne artikkelen er for å hjelpe de som har synkronisert .net Autopay med Visma Business og opplever at kommunikasjonen ikke er som den skal være.   Det har vært tilfeller der noen må hente informasjon fra AutoPay til Business manuelt første gang for å få igang automatikken. Før du gjør det må du først kontrollere at AutoPay er satt opp riktig, og avtalen med banken fungerer. Det kan du enkelt gjøre med å sjekke at transaksjonene vises i AutoPay. Skulle alt være riktig i visma.net, men informasjonen hentes ikke inn automatisk til Business så kan du følge stegene under:   Steg nr. 1: Lokaliser og markér Visma.Net AutoPay under: Regnskap, Betalingsformidling og Hente returdata. (alternativ rute: trykk på Oppsett-utforsker (CTRL+O), deretter: Tabeller, Regnskap, Betalingsformidling, Bankpartner)                         Når du er her er det en knapp til høyre i menyen som er markert på bildet (et lyn med pil ned):   Da vil informasjonen innhentes manuelt.  Dette skal løse problemet og bare være nødvendig å gjøre første gangen.

Vedr spørsmål om hvilken versjon av Visma Business man må ha for å kunne levere nødvendig informasjon i SAF-T-format til Skatteetaten. SAF-T blir som kjent obligatorisk ved bokettersyn for transaksjoner registrert etter 1/1 2020.    Vi har kun eksport av saf-t fil, dessverre ikke laget en import av saf-t til Visma Business ISO-koder anbefales å være oppdatert i valutatabellen, med 3 lengdesiffer. I eldre versjoner i VB har det hendt at en har kopiert ISO-kode fra landtabellen, og disse inneholder kun 2 bokstaver. Skatteetaten tilbyr systemleverandører eller andre som utvikler løsning for å støtte SAF-T formatene, å delta på test via Altinn. https://www.skatteetaten.no/bedrift-og-organisasjon/starte-og-drive/rutiner-regnskap-og-kassasystem/saf-t-regnskap/testinnsending/     Vi anbefaler at du kjører siste versjon vedr saf-t, da det er en del endringer. Dette er noen av endringene som ligger i versjonene:   Versjon 16.01: 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 eksporeres i en fil, fordi skattemyndighetene ikke kan håndtere filer som er større en 2 GB Utelat: Grunndata – utelater grunndata fra XML-filen Utelat: Hovedbokstransaksjoner – utelater hovedbokstransaksjonene fra XML-filen.   Versjon 16.0 Justert utlegg av data Bokstavene «MVA» legges ikke lenger ut i taggen <TacRegistration>   Versjon 15.10.1: Bilag uten Bilagsart Et problem ved eksport av bilag uten bilagsart har blitt løst.   Bilag anbefales å oppdateres med bilagsart, ved ikke angitt bilagsart ved bokføring tildeles automatisk bilagsart = 0 og denne finnes ikke i Masterdata. Dette kan for eksempeloppstå ved en filimport hvor bilagsart ikke er satt   Mva-beløp Fordeling av mva-beløp mellom transaksjoner kunne i noen tilfeller bli feil. Dette   er nå løst. Et litt smalt scenario i utfordringene rundt akkumulerte transaksjoner - når vi splitter det akkumulerte ut igjen på separate poster fant de en feil når det i samme journal var flere ordre med flere mva-satser innen hver ordre. - Versjon 15.10   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. Denne har ikke tilbakevirkende kraft, denne blir satt under oppgradering – men anbefaler at denne blir satt evt også før oppgradering     Versjon 15.01 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")   Versjon 15.0 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.   Det er noen som har fått feilmelding på ugyldige verdier i xml filen - "Invalid character in the given encoding.." Løsningen er da å lagre filen som utf-8 format, åpne filen i notepad+ og gjøre endringene   Generelt kan det feile på bruk i _ (understrek). Dette kan evt scriptes vekk. Vi har oppdaget at dette kan være satt på aktører, og filen kan feile her.     Versjon 14.10.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.   Versjon 14.10.0 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.   Man kan mappe mot næringsoppgave f.o.m. 14.10. Da må man bruke de feltene som heter Grupperingskategori og -kode. NB! Før denne versjonen blir ikke disse feltene tatt med i eksporten, selv om de finnes i databasen. Forarbeidet kan mao. gjøres i tidligere versjon, men ikke selve eksporten. Disse feltene må fylles manuelt med korresponderende kategori og koder, som finnes f.eks. her: https://github.com/Skatteetaten/saf-t/blob/master/Grouping%20Category%20Code/XML/RF-1167_Grouping_Category_Code.xml  Vi har ikke laget støtte for mappingforslag mot næringsoppgave, så det er evt. en manuell operasjon for dem som ønsker å bruke det.      F.o.m. 13.10 kan du importere SAF-T standardkonti til vbsys (fra fiilen Standard_account.txt som finnes i mappen Nor.Int der Business er installert, f.eks. C:\Visma\Business\Nor.Int), og deretter bruke behandlingsvalget "Angi standardkonto" på hovedbokskonti for å få et forslag til mapping mot 2- eller 4-sifret SAF-T-kode. Behandlingen kan kjøres enkeltvis for firma eller for flere firma av gangen via en tidsstyrt oppgave. Se også - https://community.visma.com/t5/Nyheter-i-Visma-Business-og/SAF-T-i-Visma-Business-versjonskrav/ba-p/242197    

Vi ser at noen brukere har utfordringer etter aktivering av 2FA. Ved opplasting av betalingsforslag henger rutinen seg uten at godkjenningsbildet med passord og kode kommer opp: Får fram 2FA loading og så stanser prossessen. Dette kan være enkelte brukere, på enkelte av deres klienter.   Årsaken ser ut til å være problemer med  "embedded'e" (innebygde) sider i Visma Business for Autopay når de benyttes i kombinasjon med 2FA, disse sidene er bygd mot Internet Explorer.   Internet Explorer vil bli erstattet med Microsoft Edge, foreløpig planlagt v. 15.10 desember 2020.   For de av brukerne som opplever problem anbefaler vi en sjekk av brannmur mot Internet Explorer, dersom det ikke løser problemet foreslår vi workaround:   Unnlate å bruke de embeddede vinduene i kombinasjon med 2FA frem til dette er løst, og benytt muligheten i bedriftstabellen i Business med å definere at godkjennings-bildet  automatisk kommer opp ved opplastning av betalinger, dette fungerer med 2FA og bl.a. google chrome. Her må annen nettleser enn Internet Explorer være definert som standard nettleser i Windows settings    

Hensikten med en slik lås er å hindre bokføring på perioder som er ferdige. Det er laget rutiner som sperrer perioder ved levering av mva.oppgave. Hva sier hjelpefilen om emnet: http://doc.visma.net/userdoc/business/14.10/nb-no/products/business/auto/task/t_p_companyinformation_movesuspensiondate.html Flytt sperredatoen Flytter sperredatoen for oppdatering av bilag. Om denne oppgaven The suspension date is moved if you check the "Move suspension date" field in the "Turnover statement" dialog box when printing the VAT report. You can also increase it manually in the dialog box when you have filled in all the vouchers up to a specific date. For example if you are not liable for tax. Under Bedriftsopplysninger there is a processing and a button for moving the suspension date, which take you to a dialog box. The dialog box shows the current suspension date, with the option of specifying a new one. The system supervisor may set the suspension date to a later date. Other users will receive a message that this is not permitted. If you want users to be able to move the suspension date back without system rights, select "Move the suspension date back in time" under the processing "Function access/Misc." in the Oppsettsgruppe table. The suspension date shows how far in the future the accounts will be considered to have been finally completed. Visma Business refuses to update batches in which the value date is older than or equal to the suspension date. Merk: You cannot change the value in the "Suspension date" field. You must enter a date in the "Move suspension date" field manually. Prosedyre Plasser markøren på den raden eller radene i tabellen bedriftsopplysninger som du vil behandle. På kategorien Hjem, i gruppen Behandling, klikk på Flytt sperredatoen. Angi de ulike parameterne i dialogboksen Flytt sperredatoen. Hvordan gjør vi dette i praksis   Funksjonen finnes under Administrasjon - Bedriftsoppslysninger - Grunndata - Behandling - flytt sperredatoen.  Det er også mulig å høyreklikke i tabellen og velge Behandling - Flytt sperredatoen.         Får da opp denne boksen: Her angis da ønsket ny dato Og dialog kommer opp for å angi grunn til flytting. Dette er for å ha dokumentasjon for handlingen som er gjort, spesielt viktig i de tilfeller oppgaver til det offentlige er sendt inn.   Feks.: Logging av sperredato   Visma Business logger hvem som flytter sperredato, samt endringer som gjort etter flytting. Administrasjon - Bedriftsopplysninger - Grunndata - Logging av sperredato.     Detaljert beskrivelse på hvordan det jobbes med denne loggen finnes i Release notes VB Byrå.