Oslo, 12. februar 2023
Spesialløsninger i Visma Business
Det er ofte jeg kommer over problemstillinger som jeg tenker kunne ha vært løst annerledes i VBus. Jeg har meldt inn mange ønsker om forbedringer uten at det har gjort nevneverdig inntrykk på noen hos Visma. I noen tilfeller lar det seg løse med en kombinasjon av DME, BIG, VBS, triggere og prosedyrer.
Jeg har tidligere omtalt noen spesialløsninger; Alternativ rapportering, Bilagstekst på korreksjoner fra logistikken, Fakturagrunnlag, SAF-T Standardkonto, Historisk lager, Aldersfordelt saldoliste, Vare/pris-import og Radikal sanering – så jeg skriver ikke noe mer om disse.
De fleste spesialløsningene jeg har installert, er små og enkle, som bare løser helt trivielle problemstillinger. I dag skriver jeg om slike – som kan ha interesse for andre:
Hvem opprettet bunten og når skjedde det
Ofte blir en Bunt oppdatert av den som opprettet bunten. Hos noen er det annerledes. Det kan være Trine som opprettet bunten den ene dagen og Truls som oppdaterte den en annen dag. På tabellen Oppdatert bunt står Truls både som Opprettet av bruker og Endret av bruker. Det er ingen spor etter Trine i Oppdatert bunt. Jeg har en trigger som henter Opprettet av bruker, Opprettet dato og Opprettet kl. fra Bunt slik at Trine får den æren hun fortjener.
Ordelinjememo
Noen har behov for raskt å lage mange ordrelinjememoer i en enkelt operasjon. Jeg har en prosedyre (som kan kalles eller bygges inn i ordrelagringsprosedyren) som lager et memo av den teksten som ligger en bestemt kolonne på ordrelinjen. Eller som kopierer memoteksten på produktmemo til ordrelinjememo. Det er noe annet enn behandlingsmåten Kopier memo fra produkt til ordrelinje – for det kopierer bare memostien; det lages ikke et eget memo. De som har brukt denne behandlingsmåten, har sett at en bruker ikke helt har forstått at dette blir et felles memo, som deles av mange ordrelinjer og endret det i den tro at hver ordrelinje har sitt eget ordrelinjememo. Det er dette du unngår med denne prosedyren.
Sanering av produkttransaksjoner
Det finnes en standardfunksjon for sanering av produkttransaksjoner. Men du har liten kontroll på hva som blir sanert og datoen for hvor langt frem i tid det skal saneres er Transdato. Klønete, for den sier ikke noe om når transen ble ferdigbehandlet (fakturert eller fakturamottatt); den kommer fra den datoen ordrelinjen ble registrert. Jeg har derfor en prosedyre som både kan avgrense saneringen til grupper av produkter og knytte saneringen til regnskapsperiode.
Når avdeling mangler på bilag fra logistikken
I enkelte tilfeller, f.eks. øreavrunding, mangler avdeling (eller annen ansvarsenhet) på enkelte bilagslinjer fra logistikken. Og så må en bruker sette dette inn manuelt, før bunten kan oppdateres. Det kan automatiseres med en trigger. Avdeling kan hentes fra ordre eller fra hovedbokskonto om det ikke er angitt avdeling på ordre.
Oppdatering av innkjøps- og kost-pris fra fakturamottak
Vedlikehold av innkjøps- og kostpriser kan være både kjedelig og tidkrevende. Hos noen har vi installert (som en del av ordrelagringsprosedyren) en oppdatering av innkjøpspris (i Pris/rabatt-matrisen) ved fakturamottak og/eller kostpris ved realisering av produksjon.
Oppdatering av ordre når det skjer endringer på kunde
VBus henter en rekke felt fra Aktør-tabellen når kundenr registreres (eller endres) på en salgsordre. Men om noen av disse feltene endres på kunden senere, gjør det ikke noe inntrykk på de salgsordrene som er registrert. En løsning er en trigger som oppdaterer aktive salgsordre (de hvor noe gjenstår å ferdigmelde eller fakturere) i takt med endringer på kunde.
Automatisert ferdigmelding
Hvis man ferdigmelder en plukkliste – eller for så vidt ferdigmelder det som tas ut fra lager – kan det være at ordren også har ordrelinjer som er unntatt lagerhåndtering, som også skal ferdigmeldes. Det kan være et strukturhode eller frakt. Hos noen har jeg satt opp en jobb som ferdigmelder resten av ordren straks alt som er lagerhåndtert, er ferdigmeldt. Selve jobben er innenfor standard VBus, men det må settes et merke på ordren som forteller at den er klart for ferdigmelding av resten av ordrelinjene – og dette er gjort i ordrelagringsprosedyren.
Faktura eller kreditnota
Om en ordre blir en faktura eller kreditnota er et spørsmål med to svar. Det som bestemmer dokumentnavnet på formularet, er fortegnet på fakturaen eller kreditnotaen; hvis kunden ender opp med å skylde noe er det en faktura. Men bilagsserien som brukes, bestemmes av Ordrepref. Dersom det ikke er krysset av for Kreditnota i Ordrepref. blir bilagsserien til faktura benyttet. Dermed kan det stå Utgående faktura på kontoutdraget selv om det er en kreditnota. Og i verste fall omvendt; er det krysset av for Kreditnota i Ordrepref. og det som blir fakturert ender opp som faktura, ja da har du fantasi nok til å tenke deg resultatet på kontoutdraget. Jeg har et lite tillegg til ordrelagringsprosedyren som setter eller fjerner flagget for Kreditnota etter behov.
Bilagstekst fra fakturaformular
Teksten på bilagslinjene etter fakturering kommer fra bilagsserien og er som regel Utgående faktura. Hos noen har vi en trigger som endrer teksten til navnet på formularet som er brukt. Kan være nyttig om man fakturerer litt forskjellige ting som husleie, kurs, service, varer, etc. og bruker ulike formularer for dette.
Tilbud som vedlegg til ordrebekrefelse og ordrebekreftelse som vedlegg til faktura
Dette er egentlig ganske lett å implementere.
Standardbetingelser som vedlegg til tilbud og ordrebekreftelse
Dette er også ganske lett å implementere. Og kanskje reklamasjonsbetingelser som vedlegg til faktura.
Ansvarsenheter fra strukturhodet
Hvis man har en struktur med annen avdeling, prosjekt, eller liknende i strukturhodet enn på ordren, så «arver» strukturlinjene avdeling, prosjekt, etc. fra ordren – ikke fra strukturhodet. Det har vi løst hos flere.
Innbetaling med KID fra purrebrev
Før i tiden kunne dette matches automatisk mot fakturaene som ble purret med løsningen fra ZData, som nå heter Aritma. Hos en kunde merkes slike innbetalinger og fakturaene det gjelder, samt purregebyret slik at matchingen kan gjøres effektivt. Denne kunden ville ikke ha automatisert matchingen.
Lev.nr som mangler på bilagslinjer
Når et bilag registreres på flere linjer, med Lev.nr på en linje og hovedboksføringene på andre linjer, vil hovedbokslinjene mangle Lev.nr. – om de ikke kommer fra fakturamottaket i VBus. Dette gjør ikke så mye når man ser på Oppdatert bilag, men veldig irriterende når man ser på Hovedbokstransaksjon. Jeg har en trigger som supplerer Lev.nr hvor det mangler.
Ferdigmeldt og På lager nå – på vareparti
På lagersaldo finnes Ferdigmeldt og På lager nå. De savnes på vareparti. Med en enkel DME-utvidelse og et view, er det løst. Hjelpeteksten til Ferdigmeldt er nokså misvisende; dette er det som er ferdigmeldt på salgsordre, som enda ikke er fakturert.
Vis lagerbeholdning i annen klient
Noen har flere bedrifter med felles produkttabell. Der har vi satt opp et view slik at man kan se lagersaldo i de andre bedriftene. Før DME var det en av Fri Informasjon tabellene som ble brukt.
Hvilke vinduer som åpnes, av hvem, i hvilket firma og når
Med BIG og DME har vi en løsning som loggfører bruk av vinduer. Det kan fortelle om hvilke vinduer som ikke lenger brukes og om man har feil som logges i Bedriftsdatafeil, så kan det gi en pekepinn om hva brukeren drev med da feilen oppstod.
Bedriftsendringlogg
De som bruker Bedriftsendringslogg, har tidvis behov for å se raden som er endret. Det krever litt nennsom klipp og lim fra loggen til tabellen hvor endingen har skjedd. Jeg har en DME-utvidelse som sammen med et view gjør at man kan koble inn den raden som er endret og deretter alle endringer på samme rad.
Utvidet logging av endringer på ordre
En kollega av meg fra et tidligere liv; Jonny Eriksen i Proplan – min mentor og læremester i VBus – satte opp en sekvens i ordrelagringsprosedyren hvor ordren med ordrelinjer ved hver lagring ble kopiert til tabellene Ordredokument og Ordredokumentlinje med Dokumenttype=99. En ganske fiks løsning. Dette var lenge før DME. Skulle jeg sette opp dette nå, ville jeg nok ha laget DME-tabeller for dette, men konseptet er bra om man sliter med å redegjøre for hvorfor en ordre har blitt som den har blitt. Og så ville jeg nok ha tatt med Reservasjons-tabellen samtidig. Og en sletterutine for å unngå at tabellene blir for store.
Man kan tenke i samme baner når det gjelder kunder eller annet som det er viktig å kunne vise historikken til.
Sletting av personopplysninger
Jeg har skrevet om GDPR og krav til sletting av personopplysninger tidligere. Det jeg ikke skrev er at det også ble skrevet en egen prosedyre for å automatisere slettingen.
Bytte avdelingnr, prosjektnr, ans.nr, etc.
Det finnes funksjon for bytte av Kundenr, Lev.nr, Kontonr (i hovedbok), Driftsmiddelnr og Produktnr. Men om du trenger å bytte Avdelingnr, Prosjektnr, Ans.nr, etc. så finnes det løsning for det også.
SAF-T med anskaffelser av driftsmidler i versjon 16
I versjon 16.01 (og senere) finnes Mva.grunnlag kontonr som brukes til SAF-T rapporten og som settes på hovedbokstransaksjoner på mva-konti med Opprinnelse=2 [Automatgenerert] – som altså viser til hvilken konto som er kilden til transaksjonen. Dette mangler beklagelig vis for anskaffelser av driftsmidler på versjon 16. Hvis du får bokettersyn og har anskaffelser av driftsmidler, så har vi et skript som løser dette for deg.
Dette er bare et lite knippe av små justeringer av hva som er mulig om VBus-boksen blir for trang. Mesteparten kan løses om man er villig til å gå litt utenfor boksen.
Resten av min blogg kan du lese her: frode.antun.no/VBus/blogg
Frode Antun
Løsningsrådgiver
amesto
Solutions
m: + 47 911 46 751
a: Smeltedigelen 1, 0195 Oslo