Oslo, 3. søndag i advent 2023
Jeg har tidligere skrevet om Lagerkonsistenskontroll på posteringer i forbindelse med Lageravstemming og Kontrollsporet, så jeg går ikke i detalj på dette her. Men hensikten er altså å sikre at konti for varelager i balansen speiler lagerverdiene i logistikken. Noe som åpenbart er viktig. Og Lagerkonsistenskontroll på posteringer sikrer at om noen endrer lagerhåndteringen på en ordrelinje så endres Avg. og bokf.gr. på ordrelinjen tilsvarende. En perle av en løsning som ikke fikk noen massiv presentasjon da den kom i versjon 8. Det står bare litt kort om det i beskrivelsen av tabellen Avg. og bokf.gr. Det er fremdeles kunder som ikke har implementert dette.
Det er tre situasjoner hvor VBus roter det til i samspillet mellom lagerhåndtering og Avg. og bokf.gr. på ordrelinje:
Ved bruk av Fakturereferanse med Fakt.ref.behandling 3 [Presenter originale linjer og unntas lagerhåndtering] eller 4 [Presenter originale linjer 2 ganger (-/+) og unntas lagerhåndtering]. Meldt til Visma som Case #00429518. Linjene kommer opp med opprinnelig Avg. og bokf.gr. og altså Unntas lagerh. Hvis den opprinnelige ordrelinjen var lagerhåndtert, har den en Avg. og bokf.gr. som ikke passer med Unntas lagerh. Så kan man hevde at dette kan løses med å bruke behandlingsmåten Unntas fra bokføring, hvis unntas lager settes. Dette hjelper helt til en ombestemmer seg og fjerner krysset i Unntas lagerh. For da endres Avg. og bokf.gr. i henhold til det som står i tabellen Avg. og bokf.gr – og så blir balansen allikevel feil. Konklusjonen er at om Lagerkonsistenskontroll på posteringer er implementert, så skal bare 1 [Presenter originale linjer] eller 2 [Presenter originale linjer 2 ganger (-/+)] brukes i Fakt.ref.behandling. Det kan settes opp en utfyllingsregel på Fakt.ref.behandling slik at bare 1 og 2 tillates.
Den andre situasjonen som skaper inkonsistens er EDI-import av ordre, hvor det er valgt en verdi i Beh.måte 2 som impliserer Unntas lagerh. på produkter som normalt er lagerhåndtert. Meldt til Visma som Case #00429558. Ordrelinjen får Avg. og bokf.gr. fra Produkt, men Beh.måte 2 (og Unntas lagerh.) fra EDI-meldingen. Dersom man vil importere ordre og ordrelinjer med annen lagerhåndtering enn det som er angitt på produkt, må en Avg. og bokf.gr. også være med i EDI-meldingen. Merk at standard OrdersR.imp ikke har med denne kolonnen, så det må i tilfelle lages en egen imp-fil for dette.
Den tredje situasjonen er ved bruk av strukturer med en strukturlinje som ikke er lagerhåndtert, til tross for at produktet på strukturlinjen er lagerhåndtert når det ikke brukes i en struktur. Meldt til Visma som Case #00032863. Vi får samme situasjon som ved EDI-importen: Avg. og bokf.gr. kommer fra produkt, mens behandlingsmåten kommer fra Struktur. Dersom man velger en avvikende lagerhåndtering på strukturlinjen, må det også angis den tilhørende Avg. og bokf.gr.
Alle disse situasjonene handler om bruk av standardfunksjonalitet i VBus hvor Lagerkonsistenskontroll på posteringer ikke fungerer som den skulle. Case #00032863 ble meldt inn i februar for snart tre år siden. Tilbakemeldingen fra utvikling var: The check/update of VAT and accounting group on structure lines in the described scenario has never been implemented, so it would be a new feature. Og da jeg påpekte at dette er en feil i VBus – selv om ingen hadde tenkt på det da dette ble implementert, var svaret: Hvis det var en bug så ville det vært mulig for utvikling å "fikse" på det som allerede er der men det er ikke mulig for dem. De vil måtte lage en ny kode for å følge scenariet dessverre. … Det er nok ikke optimalt i beskrevet tilfellet. Dette må eskaleres som et ønske.
Det er som om du har fått bygget deg en hytte på Sørlandet og under julefeiringen hører du at det knaker stygt i takbjelkene. Du ringer til byggmesteren som svarer: Snø? Det har aldri vært snakk om at dere skulle ha snø på taket. Det må du legge inn som en endringsanmodning.
Det ikke feil i VBus, uansett hvor hårreisende det måtte være, hvis utviklingsavdelingen ikke har tenkt på det. Så da er det vel ikke noe poeng å melde inn feil.
Siden det snart er jul og det er tiden for å sette opp ønskelister: Jeg ønsker at mine meldinger om feil i VBus blir tatt litt mer på alvor.
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