23. februar 2020
Spesialløsninger i Visma Business: BIG, VBS, EDI eller SQL?
Det er mange brukere av Visma Business (VBus) som trenger noe mer enn det VBus kan tilby. Og det er flere metoder som kan benyttes til å lage spesialløsninger. Felles for dem er at de har trebokstavers forkortelser som for folk flest ikke forteller noe. Og strengt tatt blir det ikke noe bedre av å fortelle hva de tre bokstavene står for heller:
BIG: Business Interface Gateway
EDI: Electronic Data Interchange
VBS: Visma Business Services
SQL: Structured Query Language
Ikke alle er egentlig designet for å lage spesialløsninger i VBus, men de kan brukes til det.
Nedenfor har jeg etter fattig evne forstøkt å illustrere sammenhengen mellom dem (brukeren helt til venstre om du skulle være i tvil):
BIG er den eneste av disse fire som er designet for å lage spesialløsninger i VBus. BIG ligger mellom brukeren og VBus og snuser på alt brukeren gjør. Og kan gripe inn i enkelte situasjoner. Det kan være å gjøre enkelte oppgaver uten at brukeren legger merke til det eller gi brukeren beskjed om et eller annet. Hos noen er det slik at det skal være én ordre for hver kunde og Ordrenr skal være likt Kundenr. Da kan BIG opprette ordren automatisk når kunden opprettes og blokkere for å opprette ordre på vanlig vis. Med BIG kan du hindre brukeren å registrere noe dumt – selv om det er tillatt i VBus. Det hender at noen kjøper en halv gris. Ingen kjøper en halv bil. Jeg har tidligere foreslått for Visma at det burde finnes et felt for minste salgsenhet, men det forslaget ligger vel godt arkivert i skuffen Forslag fra Antun. Muligens som inspirasjonskilde for taler til julebord og andre lystige lag. En dag skal jeg fortelle om alle forslagene jeg har meldt inn. Nok om det.
BIG er et flott verktøy til å skreddersy VBus til et bestemt formål eller virksomhet. Det fungerer godt med DME. Det som skiller Byrå-løsningen fra standard VBus (bortsett fra vinduene), er skrevet i BIG. Og det nydelige med BIG, er at VBus ikke ser forskjell på det brukeren gjør og det supplement som BIG bidrar med. Alt gjennomgår samme behandling i VBus. La oss si at BIG endrer antall på en ordrelinje. Da endrer VBus (om nødvendig) på en rekke felt på ulike tabeller
· Ordrelinjen; f.eks. Volum, Nettovekt, Bruttovekt, Påløpt, Påløpte kostnader, Pris, Beløp, Dekningsbidrag, Dekningsgrad, Fakturabeløp i fremtid for bare å nevne noen
· Ordre; Antall i grunnenhet, Volum, Nettovekt, Bruttovekt, Ordresum, Fakturabeløp i fremtid, Ordresaldo tilvekst og mange flere
· Lagersaldo; I ordre, I bestilling, Avgang, Tilgang, etc. avhengig av ordretype
· Beholdningsendring; enten ny linje eller endring av en eksisterende
· Kundesaldo; Ordresaldo tilvekst, UB ordresaldo
Det BIG gjør skaper ikke inkonsistens i databasen, slik enkelte andre metoder kan gjøre.
BIG krever egen lisens. Programmet som er skrevet i BIG er skrevet for en spesiell versjon av VBus. Hver gang VBus skal oppgraderes må det lages en ny BIG-komponent for den nye versjonen. De som lager spesialløsninger med BIG, vet dette. De som oppgraderer VBus, vet hvordan de går frem for å kontrollere om det er noen BIG-komponenter i bruk. Men vi har opplevd at kunden som opprinnelig ba om å få laget en BIG-komponent for å løse en bestemt problemstilling, har glemt hvorfor den ble laget. Noen har sågar glemt at den finnes. For så vidt greit nok, hvis det er en seriøs forhandler som har skrevet den. Men så hender det iblant at en kunde blir møkk lei og bytter forhandler. Det vet jeg alt om. Jeg har gjort det selv en gang. Den nye forhandleren har ikke mulighet til å lage en ny versjon av BIG-komponent som forrige forhandler har skrevet. Det må tidligere forhandler (som har kildekoden) gjøre. I slike situasjoner oppstår det fort et spørsmål om eiendomsretten til kildekoden, som en kunde har betalt for å få laget til seg og seg alene. Jeg er ikke jurist, så jeg overlater jussen til andre. Men det kan være greit å tenke igjennom denne problemstillingen før man ber noen skrive en BIG-komponent. Avtaler er viktig. Og avtaler inngås for å skape enighet om hvem skal gjøre hva, til hvilken godtgjørelse og tidshorisont – og forutsetningene for det – ikke minst når samarbeidsklimaet surner. Personlig tenker jeg at avtalen bør omfatte:
· Verbal beskrivelse (forståelig for brukere flest) av hvilke(n) problemstilling(er) som BIG-komponenten skal løse; motiv og hva som skal skje i VBus.
· At det skal lages dokumentasjon av komponenten etter at den er laget. Denne bør gjenta og utdype den verbale beskrivelsen (forståelig for brukere flest) både av motiv og hva den gjør, samt premissene for at den skal fungere som forutsatt. Dette er langt viktigere enn mange tenker på. Jeg vet ikke hvor ofte jeg snakker med kunder som har fått laget en spesialløsning for lenge siden hvor ingen husker hvorfor eller hvordan. Og når vi graver i det så viser det seg at det som er «løst» med spesialløsningen ikke lenger er relevant eller at det har kommet ny funksjonalitet i standard VBus som gjør spesialløsning overflødig. Denne dokumentasjonen er virkelig undervurdert.
· Om kunden skal ha tilgang til kildekoden eller ikke. Merk at tilgang til kildekoden ikke nødvendigvis åpner for å oppgradere komponenten til nye versjoner av VBus. De som skriver BIG-komponenter, har ofte bygget egne verktøykasser (bibliotek av funksjoner) som de benytter for å gjenbruke kode som er skrevet tidligere og gjerne generalisert for å øke mulighet for gjenbruk. Selv om du får tilgang til koden til din BIG-komponent, får du aldri tilgang til utviklerens verktøykasse. Og husk at det er kunden som har fordel av at slik gjenbruk gjennom kortere utviklingstid og at deler av løsningen er godt gjennomtestet fra før.
· Om leverandøren skal være forpliktet til å oppgradere BIG-komponenten etter hvert som det kommer nye versjoner av VBus, varslingsfrister (tiden fra kunden ber om ny versjon til den er tilgjengelig), hvor lenge forpliktelsen skal løpe, vederlaget for nye versjoner og om det er forutsetninger knyttet til forpliktelsen – f.eks. at kunden ikke bytter forhandler.
· Hvem som skal teste hva og omfanget av testingen. En ting er testing ved implementering, men om det er behov for en testing fra kundens side av ny versjon før oppgradering gjennomføres – så krever dette et separat testmiljø. Noen har dette med testing av nye versjoner før oppgradering som er standard-rutine. Men om det er BIG-komponenten som utløser behovet for eget testmiljø ved oppgradering, så er de opprinnelige utviklingskostnadene til BIG-komponenten antagelig en mindre del av de totale kostnadene til komponenten over hele levetiden.
Punktet om dokumentasjon gjelder enhver spesialløsning, det er på ingen måte avgrenset til BIG.
SQL triggere og prosedyrer er BIG’s rake motsetning (bortsett fra behovet for dokumentasjon). Dette er manipulering med det som ligger i databasen uten at VBus vet noe om at det er gjort. Slik manipulering må gjøres med den ytterste forsiktighet. Så er det selvfølgelig mange trivielle endringen man kan gjøre uten at det virker forstyrrende inn på det VBus gjør. Et eksempel er å endre font på ordrelinjer slik at strukturhoder skrives med fet skrift og strukturlinjer i kursiv. Eller at alle ordrelinjer skal utstyres med behandlingsmåten Ikke foreslå pris/rabatt på nytt. Endring av Antall på ordrelinje bør ikke gjøres direkte i databasen fordi det skaper inkonsistens med andre felt og tabeller, med mindre man klarer å gjenskape alt det VBus gjør – og jeg har til gode å hilse på den som klarer det. Men jeg har ikke hilst på alle…
I VBus er det mulig å angi at en bestemt prosedyre skal kalles hver gang en ordre lagres (eller utskrift av ordredokument godkjennes). Det er mange som har en slik prosedyre til å gjøre nyttige ting for seg. Ordrelagringsprosedyren (eller «Lagring av ordre prosedyre» som den egentlig heter i VBus) passer når du vil gjøre noe med ordren i tillegg til det VBus gjør og være trygg på at du ikke går i veien for VBus. Prosedyre kalles nemlig når VBus er ferdig med det VBus skal gjøre med ordren. Det du ikke klarer å fange opp med ordrelagringsprosedyren er hvordan ordren (og ordrelinjene) var før endring. Dette kan du få til med en trigger, men da må du forholde deg til hvordan VBus låser ordre – slik at du ikke blokkerer for det VBus gjør. Jeg unngår bruk av triggere på ordre og ordrelinje om jeg kan.
Hvis du skal gjøre noe med andre tabeller enn ordre og/eller ordrelinjer, så er blir det trigger. En trigger som jeg anbefaler alle som ikke bokfører midlertidig lagerverdi ved salg er en som setter Regnsk. år/per tilbake til verdien den hadde etter fakturering, og dermed blokkerer for at VBus tukler med Regnsk. år/per på tabellen Produkttansaksjon om salget er skjedd med Midlertidige kostnader og kostnadene blir endret i fakturamottaket – slik jeg har skrevet om tidligere; se Lageravstemming, avsnittet Alternativ prosedyre. Og spesielt for versjon 14 anbefaler jeg en trigger som setter Trans.dato lik Fakturadato (eller Ferdigmeldt dato for annet enn salg) for transer med Midlertidige kostnader slik at bilaget for korrigerte kostnader (det med Opprinnelse=40) skal få en relevant Valuteringsdato, jfr. Kontrollsporet.
Fordelen med triggere og prosedyrer er at det er enkelt å implementere små og enkle løsninger. Det krever ikke egen lisens, bare tilgang til SQL Server Management Studio. Man trenger altså ikke engang tilgang til den Windows-serveren som SQL-server er installert på. Det vil normalt ikke være behov for endring av triggere eller prosedyrer ved oppgradering av VBus, men det kan skje. Jeg har opplevd det 2 ganger på 15 år. Jeg husker ikke lenger hva problemstillingen var første gang det skjedde, bare at det var enkelt å løse. Jeg husker den andre gangen. Det var en trigger som endret når vedlegg skulle tas med på faktura slik at samme vedlegg ikke blir tatt med mer enn første gang en ordre blir fakturert (de hadde gjenbruk av ordre i forbindelse med abonnementer). Så endret Visma rekkefølgen på oppdatering av tabeller – og triggeren måtte flyttes fra en tabell til en annen (og mildt skrives om). Når det lages en spesialløsning som fungerer i én versjon er det ingen garanti for at Visma ikke gjør endringer som påvirker spesialløsningen i neste versjon. Det eneste vi med sikkerhet vet om en ny versjon er at den ikke er lik sin forgjenger…
Triggere og prosedyrer (samt funksjoner om man skal være pirkete) er som oftest skrevet i åpen kode (T-SQL). Dermed er man mindre avhengig av den som opprinnelig skrev koden, når det er behov for å gjøre endringer i den. Men det er mulig å kryptere koden. Det er ikke så ofte det blir gjort, men det hender. Jeg gjør det selv, når jeg installerer generelle løsninger som Historisk Lager, Aldersfordelt saldoliste og Vare/pris-import med DME.
En stor ulempe med triggere og prosedyrer er at du ikke kan få til en dialog med bruker, slik man kan med BIG. Og så er de knyttet til en database; altså et firma i VBus. Det betyr at om man skal ha samme løsning i flere firma, så må de installeres i hver database. Dette er et forhold som man må tenke på i miljøer hvor det stadig opprettes nye firma, f.eks. hos et regnskapsbyrå.
VBS og EDI er ikke egentlig mekanismer for å lage spesialløsninger, men for kommunikasjon med andre programmer. Men iblant kan det være hensiktsmessig å benytte denne inngangen til VBus.
EDI er fellesnevneren for en rekke varianter hvor et program lager en fil i et avtalt format som leses inn og behandles i annet program. All betalingsformidling er i bunn og grunn filbasert. Det samme er AutoInvoice. Her tok staten en styrende rolle for noen år siden og ga beskjed om at de som skal selge varer eller tjenester til stat eller kommune må sende faktura i et bestemt format – ellers dukker det ikke opp noen betaling. Formatet er det som i Visma omtales som AutoInvoice. Her brukte staten sin innkjøpsmakt til noe fornuftig. Det var akkurat det samme som de store dagligvaregrossistene gjorde på 1980-tallet, se EDI. VBus leser inn de edi-meldigene som dukker opp. Så om vi kvier oss for å skrive en trigger eller en prosedyre som endrer Antall på en ordrelinje – fordi det er så mange andre felt i ulike tabeller som må oppdateres samtidig – så kan prosedyren i stedet lage en edi-melding som gjør det samme. For når VBus leser inn det vi kaller en endringsmelding til en ordre (f.eks. å endre Antall), så vil VBus sørge for å oppdatere alle relevante felt i alle berørte tabeller.
Det finnes mange ulike EDI-innganger til VBus. AutoInvoice (via VDC) er én. AutoPay er en annen. Visma XML 5.x/6.0 er en tredje. Den eldste formen er via EDI-klokka. Det er egentlig en automatisert import-funksjon. EDI-klokka har fått et ufortjent dårlig rykte som ustabil. Så har den også blitt brukt til mye rart, f.eks. å regenerere lagersaldoene. Og så mangler den funksjonalitet for å behandle tilbakemeldinger fra VBus. Det hender at VBus gir brukeren beskjed om noe; f.eks. at en kunde er kredittsperret, at et dokument er sendt på epost eller liknende – men EDI-klokka har ikke mulighet til å respondere på slike meldinger. Og så stanser det opp. Jeg anbefaler at alle slike oppgaver flyttes over til jobbplanleggeren til VBus som kom for noen versjoner siden – slik at EDI-kokka får konsentrere seg om det den er bra til. Jeg har foreslått for Visma at meldinger fra VBus legges i en egen logg (f.eks. EDI-feilmelding), men til det har Visma svart at de ikke kommer til å gjøre noe mer med EDI-klokka; den regnes som gårsdagens teknologi. Det er VBS som er i fokus for utvikling. Den dagen Visma pensjonerer EDI-klokka, følger jeg med over i pensjonistenes rekker.
VBS er en tjeneste som gjør at et annet program kan «snakke» direkte med VBus. Hvis du tenker på EDI som brevveksling, så kan du tenke på bruk av VBS som en telefonsamtale. På vårt stammespråk er VBS et API: Application Programming Interface; slik at et program ikke bare kan snakke med, men gi instruksjoner til VBus om å utføre bestemte handlinger – f.eks. å endre Antall på en bestemt ordrelinje.
Som API er VBS et omfattende og komplisert grensesnitt. Flere har laget et eget og enklere grensesnitt; Amesto har ConnetcMyApps.
Det er åpenbart at VBS har langs bedre mulighet for å håndtere feil og uforutsette hendelser enn EDI-utveksling. Men, på samme måte som med BIG, må VBS-integrasjoner oppgraderes i takt med nye versjoner av VBus. Så om du får en tredjepart til å lage en VBS-integrasjon for deg (uten å bruke Vitari Connect), så husk at det må lages ny versjon for hver oppgradering. Avtalemessig gjelder det samme for VBS-integrasjoner som for BIG-komponenter. Bruker du Vitari Connect sørger vi for at nye versjoner i takt med utvikling av VBus.
VBus dekker ikke alle behov, men det betyr ikke at de ikke kan dekkes. Fortell oss hva du savner i VBus så skal vi fortelle deg hvor mange andre som gjør det samme og hvordan vi har løst det hos dem. Kanskje har vi en allerede laget en løsning for det du mangler.
Resten av min blogg kan du lese her: frode.antun.no/VBus/blogg
Frode Antun
Løsningsrådgiver
m: + 47 911 46 751
a: Smeltedigelen 1, 0195 Oslo