26. januar 2020
Sanering av transer i Visma Business
Fra tid til annen får vi spørsmål om det går an å bli kvitt utgåtte produkter og gamle lagersaldoer i Visma Business (VBus) og samtidig gammel historikk både i logistikk og regnskap. Det er gjerne de som startet med VBus i forrige århundre som ønsker å kvitte seg med gammelt rask.
Innenfor standard VBus er det ikke mulig å slette en lagersaldo. Det er mulig i Best.beh. på lagersaldoen å angi at den skal Unntas fra bestillingsforlag, Unnta fra ordregenerering og Utgår av sortiment. Den siste er ganske hendig; den sikrer at det kan registreres ordre som reduserer beholdningen til null og blokkerer for innkjøp. Og så kan det settes opp et utvalg på alle vinduer som med lagersaldo-tabellen at rader som Utgår av sortiment med null i beholdning ikke vises. Det kan være praktisk å opprette et produkt med navnet UTGÅTT som er satt opp med alle mulige restriksjoner i behandlingsmåte. Og når det ikke er mer igjen på noe lager av produktet, så kan man legge inn UTGÅTT som erstatningsprodukt. Når en bruker (eller det kommer inn en EDI-melding) med et produkt som altså er helt utgått, så endrer VBus Produktnr på ordrelinjen til UTGÅTT. Vær allikevel klar over at om man bruker behandlingsvalget Generer kopi av ordre eller bruker Fakturareferanse, så blir opprinnelig Produktnr ikke endret.
Det er mulig å endre Produktnr. Dermed kan man gi produkter som ikke lenger benyttes et Produktnr som f.eks. starter med X. Men produktet blir man ikke kvitt. Årsaken er at VBus kontrollerer om produktet finnes på en ordrelinje, produkttransaksjon eller lagersaldo. Ordrelinjer som ikke er ferdigmeldt kan slettes. Det samme gjelder ordrelinjer som er ferdigbehandlet, altså realisert. Ordre kan også slettes om de ikke har ordrelinjer som er ferdigmeldt, men ikke realisert. Mange stusser over at ferdigbehandlede ordre kan slettes. Men ordre er som kladden til eksamen. Det som «innleveres» er produkttansaksjonene. De kan ikke slettes. Etter realisering kan man gjøre mye rart med ordre og ordrelinjer, men det gjør like sterkt inntrykk på produkktransaksjonene som endinger på kladden gjør på sensor etter at innleveringen har skjedd. Enkelte felt kan riktignok endres på produkttransaksjonene; Kontrollstatus, Fri-feltene, ansvarsenheter (Avdeling, Prosjekt og liknende), Driftsmiddelnr og Driftsm.behandl., Veil.pris, Holdbarhetsdato, Plassering, Serienr, Landnr, VismaID og enkelte andre felt kan endres, men ikke vesentlige felt.
Databaser med store tabeller krever tilsvarende kraftig SQL-server for å drive det hele. Derfor kan det være nyttig å redusere størrelsen på de største tabellene, i alle fall de med mye trafikk; de som oppdateres iblant og de som ofte må søkes i. Da snakker vi om ordrelinjer, reservasjoner og produkttransaksjoner i logistikken og hovedboks- og reskontrotransaksjoner i regnskapet. Og saldotabellene; særlig kundesaldo og lagersaldo. Regnskapet kommer jeg tilbake til, men avsluttede ordrelinjer kan altså slettes. Og da slettes reservasjonsradene også. Produkttransaksjonene kan ikke slettes, men det finnes en funksjon som heter Sanering. Man må legge inn et utvalg med Trans.dato mindre (evt. mindre eller lik) en gitt dato. Det som skjer ved Sanering, er at alle transaksjoner som tilfredsstiller utvalgskriteriet og (for lagerhåndterte transaksjoner) som tilhører et avsluttet vareparti og alle transaksjonene er før valgt Trans.dato – blir flyttet til tabellen «Produkttransaksjoner før komprimering». Litt inkonsistent ordbruk der; sanering – komprimering. Men OK. Dette betyr at tabellen Produkttransaksjon blir betydelig mindre. Og for de som synes det tar for lang tid å regenerere lagersaldoene, så er dette løsningen. I prinsippet vil flere logistikkprosesser, spesielt fakturering og fakturamottak gå raskere – men så var det det med i praksis da. Det er ikke sikkert at man vil oppleve store forskjellen på andre områder enn ved regenerering av lagersaldo. Men her er det forskjell: Ved regenerering leses alle produkttransaksjoner som ikke avventer realisering og alle ordrelinjer og alle reservasjonsrader hvor noe gjenstår å behandle/realisere. En kuriositet her; Reserverbart mot lager på lagersaldo er summen av tilsvarende på ordrelinje, mens på vareparti er det summen av tilsvarende på reservasjonsrader. Så om du har avvik mellom Lagersaldo og Aggregert vareparti på dette punktet er det fordi reservasjonsradene ikke stemmer med ordrelinjene: En sikker kilde til følgefeil i VBus. Nok om det.
Saneringsrutinen på produkttransaksjon er nokså primitiv. For det første er Trans.dato et nokså klossete felt å basere seg på. Trans.dato foreslås som dagens dato ved registrering av ordrelinjen. Så om du har et tilbud som det ikke ble akseptert før det hadde gått en tid – eller ordre med lang levetid, så kan Trans.dato ligge nokså langt unna felt som Ferdigmeldt dato eller Fakturadato. Og – og dette har overrasket mange som har sanert på egen hånd – det spiller ingen rolle om du legger inn andre kriterier ved sanering. Alt – synlig i vinduet eller ikke – som er forut (eller lik) den valgte Trans.dato blir sanert. Det er lenge siden jeg har brukt standard-rutinen. Alle kunder som jeg har snakket med vil ha noe mer nyanserte kriterier for sanering. Men det er ikke så komplisert å flytte et passende utvalg av transer; det eneste man må passe på er å flytte alle transene innenfor det enkelte vareparti (eller ingen av dem) og ikke flytte transer som tilhører varepartier som ikke er slettet.
Fordelen med å flytte transene til den andre tabellen er at man tar vare på all informasjon; de parkeres i en tabell som ikke benyttes i den daglige driften. Ulempen er selvfølgelig at statistikken fordeles på to tabeller med de konsekvensene det får for vinduene; det må settes opp egne vinduer (eller egne faner i eksisterende vindu) for å vise de sanerte (komprimerte) transene. Eller, så kan man gjøre en av FriInformasjon-tabellene til et view – og samle de to tabellene her. Nye vinduer (eller faner) må lages i alle fall.
Man kan innvende at databasen ikke blir mindre ved å flytte gamle produkttransaksjoner til en annen tabell – og det er helt korrekt. Det som er viktig for ytelsen, er at de flyttes til en tabell uten trafikk. Det er som å flytte en masse biler ra sentrum ut på landet eller inn i et stort parkeringshus. Det blir mer oversiktlig i sentrum på den måten; enklere å komme seg frem… uten at vi skal trekke analogien etter håret eller inn i politikken for den saks skyld. Den største tabellen hos de fleste er faktisk Ordredokumentlinje. For de som bruker bestilling, tilbud, ordrebekreftelser, plukklister, pakksedler og faktura vil det raskt bli 3 til 4 ganger så mange ordredokumentlinjer som ordrelinjer. Men tabellene i dokumentarkivet er som parkeringsplass. Det spiller ingen rolle for ytelsen at tabellene er store. Det legges bare til rader på slutten av tabellene og VBus bruker dem ikke til å finne igjen noe informasjon – bortsett fra når en bruker vil hente frem et ordredokument fra arkivet.
Det hender jeg foretar en litt mer radikal sanering hos kunder. I tillegg til å flytte transene til tabellen «Produkttransaksjoner før sanering» foretar jeg en mild omskriving av historien (dét er det mange som har gjort før meg) og setter transene til Unntatt lagerhåndtering. Når det er gjort med alle transene (og om ikke de er slettet; også ordrelinjer og reservasjonsrader) – så sletter jeg også lagersaldo. Og for å være riktig rabiat – når kunden ønsker det – endrer jeg Produktnr til UTGÅTT (i alle transaksjonstabeller) og sletter like gjerne produktet også. Fordelen er at vi ikke har gjort noe med koblingen til regnskap. Alle transer er der med alle sine verdier.
Så pleier jeg å la dokumentarkivet bli stående uendret. Som en bauta som vitner om hvordan det egentlig var…
I regnskapet er det annerledes. Her er det mulig å slå sammen hovedboks konti, kunder, leverandører og driftsmidler. Det betyr at man f.eks. kan opprette en kunde med navnet «Kunder uten transer siste fem år» og samle gamle, inaktive kunder her. Tilsvarende med leverandører. For ikke å snakke om når forskjellige brukere har opprettet hver sin «Telenor». Fort gjort. I hovedboka er det heller ved mer grunnleggende omlegginger at det er aktuelt å slå sammen ulike hovedboks konti. Men iblant er det behov for slikt.
Transaksjonstabellene i regnskapet har også funksjonen Sanering, men denne fungerer helt annerledes. Her kommer det opp (i en egen dialogboks) et spørsmål om dato (og om det skal tas vare på saldo pr. ansvarsenhet). Og så lages det en sumtransaksjon pr. konto og periode (og evt. pr. ansvarsenhet). Dersom det er mange transaksjoner innenfor en og samme periode for den enkelte konto (og evt. pr. ansvarsenhetskombinasjon) så blir antall transaksjoner redusert, men om du har posteringer i 1998 før sanering, så har du fremdeles minst én transaksjon fra 1998 etter sanering. Dersom du er ute etter å bli kvitt gamle transaksjoner i regnskapet er ikke Sanering løsningen for deg. Da må du gjennomføre Radikal sanering.
Misforstå meg rett; jeg er ikke veldig radikal. Men av og til må radikale tiltak gjennomføres.
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