I dag skriver jeg om DME (Data Model Extension).

Vi venter i spenning på versjon 14.10 av VBus. Ryktene bærer bud om mye bra vi kan glede oss til, men jeg liker ikke å spre rykter – så jeg skriver om noe som faktisk kom for fem år siden; Data Model Extension.

Frem til versjon 9 var tabellstrukturen i VBus fast. I flere tabeller var (og fremdeles er) det en rekke frie felt, f.eks. Gr.1 til Gr.12, Fri 1 til Fri 4, Opplysning 1 til Opplysning 8, etc. Og noen helt frie tabeller; Fri informasjon 1 til 3. For mange har dette vært tilstrekkelig for å gjøre tilpasninger til det den enkelte har behov for. Men det er selvfølgelig grenser for hva man kan få til innenfor denne strukturen.

Så, i versjon 9.10 kom mulighet for å lage tillegg til datamodellen; mulighet for å legge til

· nye felt i eksisterende tabeller

· nye tabeller

· nye relasjoner mellom eksisterende tabeller, mellom nye tabeller, samt mellom eksisterende og nye tabeller

Relasjoner er det som gjør av vi kan koble tabeller sammen (f.eks. mellom kunde og kundens ordre) eller hente frem informasjon fra underliggende tabell (f.eks. hente kunden navn inn i en tabell som har kundenr).

Nye felt (eller kolonner som det ofte kalles) gis egenskaper slik at de kan brukes slik standard-kolonnene brukes. Hvis det angis at en kolonne er et Kundenr, så kan opplysninger fra kunde hentes inn. Det kan gjøres oppslag i kundelista og vinduer kan designes slik at en ser kunder med tilhørende rader fra den nye tabellen – på samme måte som standardtabellene. DME-kolonner kan være Lev.nr, Ans.nr, Avdelingsnr, Prosjektnr, Dato, Kl.sl., Bildefilnavn, Memofilnavn, Enhet, Antall, Pris, Rabatt, Beløp, Heltall, Desimaltall, Tekst av ulik lengde. Det finnes nesten tusen ulike felttyper i VBus og alle kan brukes på DME-kolonnene. Det er allikevel ganske enkelt å finne frem til rett type. Hvis det opprettes en ny kolonne med typen Bildefilnavn, så kan det som legges inn her visualiseres i et vindu i VBus på samme måte som de vanlige bildefilnavn-kolonnene. Det er i praksis ingen grense for hvor mange nye kolonner som kan opprettes. Er det behov for tre bilder på f.eks. produkt, vil det være naturlig å legge opp Bilde2 og Bilde3 – siden det i standard allerede finnes en kolonne for dette. Men dersom det er slik at noen produkter ønskes utstyrt med mange bilder, så vil det være enklere for brukerne å ha disse i en egen tabell som er koblet til produkt.

Det kan også legges opp kolonner med helt andre egenskaper enn de som finnes i standard. Dersom et produkter kan inngå i flere sortiment, så kan det lages en egen kolonne for dette hvor man får opp en liste med alle sortiment og hvor det kan krysses av hvilke(t) sortiment(er) produktet inngår i. Denne får samme design, som tilsvarende kolonner i VBus; slik som Kundepreferanse eller Regnskapsbehandling (dog ikke med beslektede alternativ i samme ramme).

Den største begrensningen med DME er egen fantasi!

Etter fem år med DME tenker jeg at det er høvelig å skrive noe om hva vi har brukt det til hos enkelte av våre kunder.

Den som har utnyttet DME mest av de jeg jobber med er Christiania Belysning (og jeg skriver dette i full forståelse med dem). De brukte Client System (nå Smart Store) i butikk, men har nå byttet ut dette med butikkdata-løsning fra Heads. VBus ble valgt for sentrallager og regnskap. Så ble det reist et spennende spørsmål: Hvor kan vi vedlikeholde produkter, priser, etc. slik at vi kan gjøre alt ett sted. Svaret ble VBus med DME. Sjekk christiania-belysning.no eller Lysmesteren.dk. Se på produktbeskrivelsene. All produktinformasjon vedlikeholdes i VBus; størrelse, farge, materialvalg, lyskilde, spenning, effekt, isolasjon (IP-grad), lysstyrke (lumen), fargetemperatur (kelvin), sokkel, ledningslengde, ledningsfarge, om den kan dimmes, energiklasse(r), etc. Alt ligger i VBus og eksporteres til andre systemer; Heads, webshop, portaler, m.v. Omsetning og lagerbeholdning i butikk leses inn til egne tabeller i VBus daglig for å ha bedre oversikt med det som skjer i butikk.

En annen kunde er et konsern med mye internhandel. Det er lett å eliminere denne, men eksternt salg av varer som er kjøpt fra annet selskap i konsernet har rett kostpris fra et selskapsståsted, men ikke fra en konsernbetraktning. Her har vi satt opp egne kolonner i transaksjonstabellene som viser konsernkostpris, konsernkost, konserndekningsbidrag og konserndekningsgrad. Det var ikke så mye programmering som skulle til for å få tallene rett. Og så har de en egen tabell (som teknisk sett er et view) som viser den eksterne omsetningen i alle klientene med omsetning og inntjening i et konsernperspektiv.

Flere av våre kunder har bedt oss lage løsning for å rapportere ordreinngang og endring av tilbudsreserve. Jeg har laget dette både med og uten DME, men du verden hvor mye enklere dette ble å lage med DME.

VBus har støtte for plasseringskontroll (hvor på lageret varer kan plasseres), men det er nesten ingen som bruker det. Det er en del som må settes opp for å ta det i bruk; hva er tillatte plasseringer for hvert enkelt produkt på hvert enkelt lager. Men når den jobben er gjort, kan du ved bare å legge til en ekstra relasjon mellom eksisterende tabeller, få VBus til å foreslå plassering på lager når det ikke er plass på produktets normalplass (kontroll mot kapasitet på hver enkelt lagerplass m.h.t. antall, vekt og/eller volum – og om det skal tillates å ha flere produkter på den enkelte lagerplass). Det er selvfølgelig et vindu i VBus som må designes med nennsomhet.

Av helt trivielle tillegg nevner jeg Normalleverandør på produkt (ikke bare på lagersaldo) og Lagerført enhet. For de som kjøper og selger i avvikende enheter; f.eks. kjøper på rull og selger i meter, eller kjøper i fat og selger i kanne – og av den grunn bruker antallsomregning – er det viktig å vite hva den lagerførte enheten er. Hva telles ved lagertelling og plukkes fra lager ved salg; antall fat, antall kanner eller antall liter?

En kunde ville ha bedre kontroll med hvilke produktnr som opprettes og bestemte seg for at Produktnr skal være på et bestemt antall siffer og skulle tildeles fortløpende uten krumspring. Men i VBus er Produktnr et tekstfelt, så man kan ikke skrive + for å få tildelt neste ledige nummer slik man kan gjøre for kunde, leverandør, ordre, bilag, etc. Løsningen på det ble en liten DME-tabell med et Produktnr-felt som er et heltall – med mulighet for automatisk tildeling av nytt nr – og en trigger som kopierer verdien til produktnr-tabellen, hvor resten av arbeidet skjer. Brukeren ser ikke forskjell; bare klikker på knappen «Nytt produkt» i vinduet.

Selv har jeg laget en løsning for vare/pris-import slik at man kan lime inn opplysninger i en felles tabell som deretter spres til andre tabeller; Produkt, Leveringsalternativ, Pris/rabatt-matrise og Strekkode. Er du interessert i detaljer kan du lese om dette her: VarePrisImportVBus.pdf. Eller snakke med en av de som bruker dette; jeg kan formidle kontaktinformasjon.

Tidligere måtte man ha egen lisens for DME. Nå har alle DME som en del av lisensen. Det er bra.

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

frode@antun.no