29. mars 2020

Feil i Visma Business

Forrige søndag skrev jeg om hvordan jeg synes Visma Business (VBus) bør være. I dag skriver jeg om hvordan Visma mener VBus bør være; eller nærmere bestemt problem­stillinger hvor Visma mener (les: erkjenner) at det er feil i VBus.

Alle systemer har feil. Det er ikke til å unngå. Noen feil ligger i grenselandet mot brukerfeil. Noen er slik at konsekvensene av feilen er små og enkle å rette opp. Noen feil er slik at de rammer svært få brukere. Noen er slik at de er enkle å unngå; hvor det finnes det vi på nynorsk kaller en work around. Vi må erkjenne at også i spørsmålet om hvor raskt en feil skal rettes – og om den skal rettes – så vil det ligge en kost/nytte-vurdering. Man kan være enig eller uenig i den vurdering som blir foretatt, men det kan være greit å ha i bakhodet at ikke alle feil vil bli rettet.

Alle forhandlere har tilgang på saker som er klassifisert som feil uavhengig av hvem som har meldt dem inn. Det vil si; en del av dem. Nedenfor har jeg listet opp de sakene jeg har meldt inn som fremdeles står uløst. Av disse er fem tilgjengeliggjort for andre forhandlere. Disse fem er merket med *. Resten av dem er skjult for andre enn Vitari. Når jeg skriver om disse i dag er det fordi jeg mener at de er vesentlige feil som Visma bør rette opp:

Antall på Lagerverdirapport er feil (CRM 67591089 og Ticket 38307 29sep2015)

På rapporten Lagerverdi (under Logistikk) vises Antall, både inng.saldo, økning, minskning, bevegelse og utgående saldo.
Det fremgår ikke om man har tenkt at det er Realisert beholdning, Fysisk beholdning, Tellbart antall eller forventet bokført som rapporten skal vise - men rapporten viser ingen av delene.
Faktisk er det antall som vises på rapporten helt uten mening.

Fra TransType=1 Salg blir Lagerbevegelse tatt med alltid (altså etter ferdigmelding). Dette er i utakt med både Realisert og fysisk beholdning, men stemmer med Tellbart antall.
Fra TransType=6 Kjøp blir Lagerbevegelse tatt med etter fakturamottak. Dette er i takt med Realisert beholdning (ikke Fysisk og heller ikke Tellbart).
Fra TransType=4 Korreksjonsordre blir Lagerbevegelse tatt med alltid. Dette er som det skal være.
Fra TransType=4 Lagertelling blir Lagerbevegelse bare tatt med etter at rutinen Bokfør kostnader er gjennomført. Dette er i utakt med Realisert beholdning, Fysisk beholdning og Tellbart antall.
Fra TransType=7 Produksjon blir Lagerbevegelse tatt med alltid (altså etter ferdigmelding). Detter er i utakt med Realisert beholdning, men stemmer med Fysisk beholdning og Tellbart antall.
Fra TransType=5 Vareforbruk blir Lagerbevegelse tatt med alltid. Dette er som det skal være.
Fra TransType=8 Lageroverførselsrutinen blir Lagerbevegelsen bare tatt med etter at rutinen Bokfør kostnader er gjennomført. Dette er i utakt med Realisert beholdning, Fysisk beholdning og Tellbart antall.
Fra TransType=8 Lageroverførselsordre fra realiserte partier blir Lagerbevegelsen tatt med alltid. Dette er som det skal være.
Fra TransType=8 Lageroverførselsordre fra urealiserte partier blit Lagerbevegelsen tatt med alltid. Dette er i utakt med Realisert beholdning, men stemmer med Fysisk beholdning og Tellbart antall.

Siden beholdning normalt er en sum av transer av ulik type med ulik status vil Antall i Lagerverdirapporten ikke gi noe mening.
Det er behov for en rapport som viser Realisert beholdning (inngående, bevegelse og utgående).

Status: Problemsak

Svar fra Visma: På grunn av intern rapportering endres sakstype. Dette medfører ikke noe for fremdrift i arbeidet med ny og riktig rapport.

Jeg gremmes.

Feil Beløp i Lagerverdi-rapporten (CRM 67591097 og Ticket 38298 29sep2015)

I rapporten Lagerverdi er det Beløp knyttet til Antall, for inng.saldo, økning, minskning, bevegelse og utg.saldo. Man kan mene mangt om antall i denne rapporten (jfr. sak 67591089), men om vi nå tenker oss det eksotiske tilfellet at antall faktisk er rett; dvs. at alt som er ferdigmeldt på salgsordre også er fakturert, at det all produksjon som er ferdigmeldt også er realisert og at alle transer fra lagertelling og lageroverførsler (rutinen) er bokført. Dette er praktisk mulig i alle fall for de som ikke har produksjon. Nok om det; vi tenker oss at vi ikke har antallsfeil i rapporten.

Beløpene er sum Lagerkostnad fra de transene som inngår i Antall. Fremstår som rimelig nok om vi tenker oss at vi aldri har brukt noe annet enn versjon 8 av VBus. Nå er det jo en og annen virksomhet som har brukt VBus en tid, ja noen helt tilbake til forrige århundre. Og det har jo forekommet opp igjennom ulike versjoner av VBus at håndteringen av kostpris, påløpte kostnader og lagerkostnad ikke har vært helt innertier. Men vi må jo la historie være nettopp det. Når partiet ble avsluttet (og Lagerbevegelse ble null) i forrige tiår så kan vi lukke øynene for at sum Lagerkostnad ikke ble null på samme parti. Slik har vi tenkt. Tomme partier har ingen verdi. Hvis Realisert beholdning er null så kan ikke Realisert lagerverdi være noe annet enn null. Det samme gjelder for Fysisk beholdning og Fysisk lagerverdi.

Men siden beløpene i Lagerverdi-rapporten er sum Lagerkostnad også fra 'tomme' partier vil inkonsistens fra tidligere versjoner av VBus vises som rader i rapporten med Beløp der Antall er null. Disse radene kan man i og for seg se bort fra; det er de lagersaldoradene som består av partier med antall og samtidig 'tomme' partier hvor sum lagerkostnad ikke er null - det er disse radene som er umulig å få øye på. Det er som å bli hjemsøkt av tidligere begravede synder. Skjelettene ramer ut av skapene som i en klassisk skrekkfilm.

Så langt jeg forstår er den eneste måten å få en meningsfull lagerverdiliste å ta utgangspunkt i lagersaldo og trekke fra lagerkostnad på de transene som har skjedd etter det tidspunkt man skal rapportere verdien for, jfr. sak 67497835. Da vil tidligere synder ligge i fred.

For å se hvilke partier som har samlet Lagerkostnad som ikke går i null selv om samlet Lagerbevegelse er null kan man bruke følgende:

Select ProdNo, FrStc as StcNo, ShpNo, Sum(StcMov) as Bal, Sum(StcCst) as StcVal, Min(AcYrPr) as FirstYrPr, Max(AcYrPr) as LastYrPr

   from ProdTr

   where TransSt<>TransSt|16

   group by ProdNo, FrStc, ShpNo

       Having sum(StcMov)=0 and Sum(StcCst) not between -1 and 1

Hos en kunde som har brukt VBus i mer enn 10 år er det 311 tomme partier med feil i Lagerkostnad som gjør at den samlede feilen i lagerverdilisten er på mer enn 11 mill. kroner.
Mange av partiene er avsluttet for mer enn 10 år siden, men noen er helt nye.

Status: Ny (!)

Kommentar: Visma viser til beta-rapporten i rapportering, men den er også feil, se ticket 368882, 29okt2017.

Feil Bekreftet lev.dato (CRM 67489958 9mar2013, Ticket 48213 21nov2015 og Ticket 604364 6aug2018) *

Dette er skrevet 21. november 2015:

Jeg har tre produkter. Alle er satt opp med Lev.tid=14 og Transp.tid=7 (Total lev.tid=21) både i Lagersaldo og på Leveringsalternativ.
Det ene produktet er på lager. Det andre er ikke på lager, men i bestilling med Ank.dato=7.12.2015 (altså om 16 dager).
Det siste produktet er ikke på lager og heller ikke i bestilling.

I bedriftsopplysningene er det i Beregning av leveringsdatoer krysset av for
Behandlinger:
- ikke flytt bekreftet leveringsdato tidligere på ordre
- Overstyr tidligere registrerte lev.datoer
Beregn ved:
- Utfylling av ønsket lev.dato og antall
- Lagring av innsatte/endrede ordrelinjer
- Bruk av behandlingen "Lagre om"

Registrerer en salgsordre med Ønsket lev.dato=1.12.2015 med tre ordrelinjer (én for hvert av de tre produktene med Antall=1 på alle tre).
På den som er på lager blir Bekreftet lev.dato satt til 1.12.2015 (altså samme som Ønsket lev.dato). Dette er bra.
På de som ikke er på lager blir Bekreftet lev.dato satt til 22.12.2012 som altså er Ønsket lev.dato + Total lev.tid.
Dette gir ingen mening siden det ene kommer til lager 7.12.2015 og det andre kan bestilles i dag og forventningsvis ankomme lager 12.12.2015.

Når jeg endrer ønsket leveringsdato på alle ordrelinjene til 24.12.2015, blir Bekreftet lev.dato=24.12.2015 på de to første (den som er på lager og den som er i bestilling).
På den siste ordrelinjen så blir Bekreftet lev.dato=14.01.2015, hvilket åpenbart er feil.

Feilen ble meldt 9.3.2013. Saken ble bekreftet som programfeil 24.9.2013, men to år senere fikk jeg beskjed om at feilen ikke vil bli rettet.

En av våre kunder skriver til oss i en mail: Vi kan ikke skjønne at Visma ikke har en løsning for dette da dere sikkert har mange handels­bedrifter som oss i kunde­porteføljen.
Jeg ber dere revurdere prioriteringene.

Status: Bekreftet feil

Kommentar: 8feb2017 fikk jeg beskjed om at feilen var rettet i versjon 12. Det var den ikke og ble meldt på nytt 6aug2018.

Kommentar fra Visma: Incorrectly calculated data causes problems e.g. with purchase estimates as mentioned in the support case or wrong date can be confirmed to customer's customer (and cause lost sales). Changes is date calculations can be risky and sufficient testing would be important after changed.

Standardpris mangler på produkttransaksjoner (Ticket 46870, 16nov2015) *

Hvis det i behandlingsmåte er krysset av for "Ikke beregn rabatt ut fra standardpris" så blir Standardpris aldri overført til produkttransaksjoner.
Hvis det i behandlingsmåte ikke er krysset av for "Ikke beregn rabatt ut fra standardpris", Pris er lik Standardpris og det ikke er gitt rabatt på ordrelinjen, så blir ikke Standardpris overført til produkttransaksjoner ved ferdigmelding. Dette skjer da først ved fakturering.
Jeg antar at dette ikke er gjort med hensikt. Ber om at dette klassifiseres som feil i VBus og oversendes utvikling for retting.

Status: Bekreftet feil

Melding fra Visma: Denne saken står fortsatt med status hos PU som 'Future Version'. Dette betyr i prinsipp at vi ikke kommer til å se en løsning med det første, såfremt det ikke eskalerer. Om ønskelig kan man legge inn en 'Feature Request' i en ny ticket. Saken lukkes fra Support, men vil fortsatt leve videre hos PU som en referanse.

Ferdigmelding kan trekkes tilbake selv om midlertidig lagerverdi ved salg er bokført (Ticket 101241 10apr2016 og Ticket 1586151 17mar2020)

Sett opp i bokføringstilfeller at det skal bokføres midlertidig lagerverdi ved salg og sett opp egnede konti i A&B-opplysninger. Angi som behandlingsmåte på produkt at midlertidig lagerverdi skal bokføres.

Registrer en salgsordre, gjennomfør ferdigmelding og kontroller bokføringen. Om jeg forsøker å trekke tilbake ferdigmeldingen med negativt antall i ferdig NÅ på ordrelinje eller reservasjonsrad får jeg melding om at det ikke er tillatt å trekke tilbake ferdigmelding etter at kostnader er bokført. Men jeg kan allikevel trekke ferdigmeldingen tilbake ved å slette reservasjonsraden eller ved å bruke menyvalget "Trekk tilbake plukking og ferdigmelding" på tabellen plukklister. I disse tilfellene blir det ikke laget noe regnskapsbilag og det oppstår en differanse mellom logistikk og regnskap som må korrigeres manuelt i regnskapet.

Status: Bekreftet feil

Melding fra Visma 6sep2016: Feilen er bekreftet rettet i versjon 11.10 (release desember 2016).

Kommentar: Det er fremdeles mulig å trekke ferdigmelding tilbake med å slette reservasjonsraden

Feil valuteringsdato på bilag fra realisering av produksjon (Ticket 248183 26feb2017 og ticket 1422218 11nov2019)

Registrer en produksjonsordre med antall på 2 eller mer. Ferdigmeld noe av produksjonen i én periode og flytt sperredatoen slik at denne perioden er stengt.
Ferdigmeld resten av produksjonen i neste periode. Realiser produksjonen.
Begge produkttransaksjoner med TransType=7 har Regnsk. år/per. og Realisert år/periode fra ferdigmeldt dato, mens Fakturadato er dato for realisering. Den første av transene har således feil Regnsk. år/per. og Realisert år/periode.
Regnskapsbilaget får Valuteringsdato fra Ferdigmeldt dato på første trans. Dette er jo åpenbart feil og kan ikke oppdateres siden perioden er stengt.
Realisering av produksjon bør lede til en dialog med spørsmål om Bilagsdato (som bør styre Realisert år/periode) og Valuteringsdato (som styrer Regnsk. år/periode). Det vil være naturlig at dagens dato blir foreslått. regnskapet.

Status: Bekreftet feil

Dette ble endret i versjon 14, men det ble ikke bedre av den grunn; se Produksjon – avsnittet Trinnvis ferdigmelding. Se også ticket 1339036, 30aug2019.

Feil visualisering av parentes i utvalg (Ticket 267913, 29mar2017) *

Lag et utvalg på Aktør som viser leverandører hvor navnet inneholder ASA eller AB.

Utvalget blir slik:
Lev.nr<>0
og (Navn = Tekst med jokertegn ("%ASA%"))
eller Navn = Tekst med jokertegn ("%AB%"))

VBus visualiserer én avsluttende parentes for mye. Det gjør det vanskelig å lese og kontrollere at utvalg er rett når utvalgene er sammensatt.

Status: Bekreftet feil

Svar fra Visma: This is confirmed as a bug and have a planned fix in version 13.00

Kommentar: Ikke rettet i versjon 14.10

Periodisering av innkjøpsordre (Ticket 352759, 10okt2017) *

Bruk av Per.nøkkel på salgsordre fungerer fint, men jeg får det ikke til å fungere på innkjøpsordre. Hva må jeg gjøre for å kunne bruke Per.nøkkel på innkjøpsordre?

Status: Reproduserbar feil

Svar fra Visma: Periodic keys does not work on purchase orders.

Feil etter endring av utskriftsoppsett på et formular (Ticket 361726, 17okt2017)

I byråversjonen er det slik at om man endrer Utskriftsoppsett på et formular så dukket det opp ett spørsmål om det skal endres også i dokumetarkivet. Svarer man ja på dette så endres Oppsettnr i tabellen Ordredokumenter i alle firmadatabasene tilsvarende. Dette er fint om sideelementstrukturen i det gamle og det nye oppsettet er det samme. Rutinen endrer ikke på Sideelem.nr i samme tabell. Hvis Sideelementene i utskriftsoppsettet på det nye utskriftsoppsettet har andre Sideelem.nr enn på det gamle, er resultatet at man ikke kan skrive ut kopier fra dokumentarkivet.

I de fleste vindusoppsett har Ordretabellen Sideelem.nr=5 og Ordrelinjetabellen er 6. Men om man designer et utskriftsoppsett fra bunnen får Ordretabellen Sideelem.nr=1.

BIG-rutinen bør endres slik at det er en kontroll på om sideelementene på nytt og gammelt utskriftsoppsett har samme Sideelem.nr..

Status: Reproduserbar feil

Feil i Lagerverdirapporten (beta) (Ticket 368882, 29okt2017)

Se vedlagte Demo-data. Siste lagerbevegelse er ferdigmeldt 27.06.2017.
Kjør ut betarapporten Lagerverdi (fra rapportering) med til dato 30.06.2017.
Sammenlikn med lagersaldo og varepartier i VBus.

Det er tre avvik:

Produktnr 136 har på Lagerverdirapporten en utgående saldo på 11 stk og 6.937 kroner. Lagersaldo viser fysisk beholdning på 12; 1 er ferdigmeldt og På lager nå er 11. Varepartiene viser at det er 3 På lager nå på parti 12 (1 er ferdigmeldt, ikke fakturert). Verdien av de tre er 2.142. I tillegg kommer de 8 fra parti 13 med en verdi på 4.712 kroner. Da blir rett verdi 2.142+4.712=6.854 kroner. Her er det et avvik på 83 kroner.

Produktnr 9000 har på Lagerverdirapporten en utgående saldo på 3 stk og 158.331 kroner. Lagersaldo viser fysisk beholdning på 4; 1 er ferdigmeldt og På lager nå er 3. De tre er partiene 4, 5 og 6 (1 på hvert parti). Verdien av disse tre partiene er 162.435,66. Avviket er på 4.104,92 kroner.

Produktnr 9001 har på Lagerverdirapporten en utgående saldo på 6 stk hvorav 1 er utlånt/utleid. Lagersaldo viser en fysisk beholdning på 7; 2 er ferdigmeldt og På lager nå er 5. Her kan begrepene være forvirrende, siden lagerverdirapporten synes å ta med de som er utlånt/utleid, mens På lager nå i VBus ikke gjør det. Men det er altså et avvik på 1 utlånt/utleid. Av produkttansene ser vi at det er 1 utleid fra parti 2 med en kostpris på 47,964,95. Og så er det utlånt 1 fra parti 3 med en kostpris på 41.184,-. Ingen av de to er tilbakelevert eller kassert. Verdien på den ene som er tatt med på Lagerverdirapporten synes å være hentet fra FIFO-pris på lagersaldo. Så her har vi både en antallsfeil og en kostprisfeil. Verdifeilen på utlånt/utleid på 45.011,45 kroner.
Ser vi da på verdien av de 5 på lager som ikke er utlånt/utleid, så er dette partiene 4, 5, 6, 7 og 8 - med en verdi på 219.813,56. Trekker vi (fra Lagerverdirapporten) de 44.138 (som altså er utlånt/utleid) ut fra verdien på 264.825 ser vi at de 5 som er på lager (ikke utlånt eller utleid) er gitt en verdi på 220.687,51. Her er det et avvik på 873,95 som riktignok går motsatt vei. Samlet er verdifeilen på 44.137,50 - det samme som 1 x FIFO-pris.

Status: Bekreftet feil

Demodataene det vises til er de som benyttes på kurs hos Visma. Gi beskjed om du trenger dem.

Kommentar: Jeg har raljert over dette tidligere; se Historisk lager og jeg mener fremdeles det er en skam at Visma presenterer disse rapportene som meningsfulle. Og Visma sier at de heller ikke vil gjøre noe med dem.

Jeg gremmes.

Bruttoordre og fakturareferanse (Ticket 559952, 4jun2018)

Har tidligere fakturert en kunde med Ordrepref. satt til Bruttoordre.

Registrerer en ny ordre på samme kunde også med Bruttoordre i Ordrepref. og bruker fakturareferanse for å hente inn ordrelinjer fra tidligere faktura. Dette går greit og pris/beløp og behandling blir rett.

Legger til en ny ordrelinje med et produkt som ikke var på fakturaen det ble referert til. Det kommer ingen pris, selv om det ligger relevant prislinje i pris/rabatt-matrisen.

Legger til en ny ordrelinje med et av de produktene som var på fakturaen det ble referert til. Prisen kommer opp før antall legges inn og dette er ikke prisen fra pris/rabatt-matrisen, men pris er nettopris (ex.mva) fra fakturaen det ble referert til og det til tross for at begge ordrene er bruttoordre.
Og ordrelinjen har Partinr fra produkttransen til fakturaen det ble referert til.

Fjerner fakturareferanse fra ordrehodet og legger inn de to siste linjene på nytt. Nå blir det rett.

Status: Dokumentasjon

Svar fra Visma: Pr nå er funksjonaliteten slik den skal være... Om det ønskes at nye linjer skal få utvidet oppslagsrett, er det å regne som et forberingsønske og ikke en feil.

Valuteringsdato på bilagslinjer med Opprinnelse=40 [Korreksjon av kostnader] (Ticket 1339036, 30aug2019)

Hvis det er solgt varer fra partier med Urealisert lagerøkning, blir salgstransene merket med Midlertidige kostnader (TransStatus i Produkttransaksjoner). Hvis Kostpris (kr) blir endret i fakturamottaket, blir de berørte salgstransene merket med at Kostnadene er endret. Og hvis det i Bokføringstilfeller er krysset av for Automatisk kost-korrigering, blir det ved fakturamottak også laget en bunt med Opprinnelse=40 [Korreksjon av kostnader]. Bilagslinjene i denne bunten får Valuteringsdato fra Transdato på produkttransaksjone. Det spiller ingen rolle om det i Bokføringstilfeller er krysset av for Sett val.dato for kostnadskorrigeringer = fakturaens val.dato eller ikke.

Jeg tenker at Valuteringdato på bilagslinje må være Fakturadato om det er krysset av for dette i Bokføringstilfeller. For transaksjoner uten Fakturadato (korreksjoner og vareforbruk i produksjon), må Valuteringsdato settes til Ferdigmeldt dato.

Hvis det ikke er krysset av for dette i Bokføringstilfeller, tenker jeg at Valuteringdato må være som på innkjøpsordren som realiseres.

Å bruke Transdato som Valuteringsdato på bilagslinjene gir ingen mening i mitt hode. På ordre med lang levetid vil korreksjonene fort havne på stengt periode...

Hva gjør jeg for at Valuteringsdato på bilagslinjene på bunten med Opprinnelse=40 skal følge Fakturadato (eller Ferdigmeldt dato der hvor Fakturadato mangler)?

Ring meg gjerne om problemstillingen er uklart formulert.

Hjelpeteksten til Bokføringstilfeller er ikke mye til hjelp:

Lagerkonsistenskontroll på posteringer

Sett val.dato for kostnadskorrigeringer = fakturaens val.dato

The parameter will activate the table Std. avg. og bokf.gr. which will give a possibility to get correct posting of order lines where the stock handling has been changed. 

Det ser vel ut til at den engelske teksten hører til Lagerkonsistenskontroll.

Status: Ny (!)

Bekreftet oppdateres ikke ved godkjenning av ordrebekreftelse (Ticket 1474800, 29des2019)

Registrer en salgsordre med én ordrelinje som ikke trenger å være lagerhåndtert (men kan være det om det er tilstrekkelig reserverbart mot mot lager). Sett Trans.dato f.eks. til 31.10.2019, Tid til neste=1, Antall=1 og en passende pris.

Skriv ut ordrebekreftelse og godkjenn denne. Ferdigmeld og fakturer. Trans.dato på ny linje har nå blitt 30.11.2019. Slik skal det være.

Skriv ut ny ordrebekreftelse. Godkjenn. Ferdigmeld og fakturer. Trans.dato på ny linje har nå blitt 31.12.2019. Slik skal det være.

Bruk et ordrebekreftelsesformular hvor utskriftsoppsettet har med Trans.dato. Skriv ut ordrebekreftelse. Her får du på to linjer; både den med Trans.dato=30.11.2019 og den med Trans.dato=31.12.2019.

Ordrelinjen med Opprinnelse=4 [Tid til neste ordrer] har ikke flagget Akseptert av oss satt i Ord.linjestatus. Når ordrebekreftelsen godkjennes oppdateres ikke Bekreftet på ordrelinjen, men flagget Akseptert av oss settes i Ord.linjestatus. Dermed er ordrelinjen på nytt klar for ordrebekreftelser. Jeg kan ikke se at dette kan være korrekt behandling.

Dersom ordrelinjen ferdigmeldes før det er skrevet ut ordrebekreftelse, så vil ordrelinjen fremdeles ikke ha status som Akseptert av oss.

Jeg vet behandlingsvalget Bekreftet (både i ordre og på linje) vil sette dette flagget på salgsordre, men det må være slik at når det skrives ut en ordrebekreftelse som godkjennes, så må Bekreftet oppdateres.

Status: Ny (!)

Kommentar fra Visma: Vil ikke bli forbauset om dette ikke fungerer, siden tid til neste ikke akkurat er en ferdk rutine.

Rot m.h.t. når vedlegg blir skrevet ut (Ticket 1476647, 1jan2020) *

Registrer en ordre med en ordrelinje. Sett sendemåte for dok. til at faktura skal gå på AutoInvoice, mens ordrebekreftelse og pakkseddel skal gå på epost.

Legg inn et vedlegg på ordren og angi at vedlegget skal sendes med ordrebekreftelse, pakkseddel og faktura.

Skriv ut ordrebekreftelse, ferdigmeld, skriv ut pakkseddel og faktura.

Vedlegget kommer bare med på faktura.

Status: Bekreftet feil. Planlagt løst i versjon 15.01.

Kommentar: Jeg har skrevet om dette her: Vedlegg.

Kunder opprettet med Orders.edi (Ticket 1500033, 28feb2020)

Denne saken krever litt innledende informasjon. Kunden får ordre inn som EDI-melding fra et eksternt system. For nye kunder har EDI-meldingen også med en rad med kundeinformasjon (med A i første felt). Eksempel på en slik fin er denne:

A;34031;Ole Brum;;;;;59 36 91 61;ole.brum@gmail.com;;;NO;7;-2147483647

H;20200225;20200225;34031; Ole Brum;Hundremeterskogen 2;;;;1364;Fornebu;;;0;;;;;;7;;5165;NO;-2147483647

L;;1002;Flytting timepris 2 mann med 20m3 bil;tim;6,5;1040.00;;;;

A;34235;Bleiker videregående skole;Brages vei 1;;1387;Asker;90614577;ola.normann@bleiker.vgs.no;;;NO;20;-2147483647

H;20200225;20200225;34235;Bleiker videregående skole;Brages vei 1;;;;1387;Asker;;;0;;;;;;20;;5310;NO;-2147483647

L;;1002;Mandag 17. Februar, 6 mann og en flyttebil;tim;8,5;2640.00;;;;

L;;1002;Tirsdag 18. Februar, 6 mann og flyttebil;tim;9;2640.00;;;;

L;;1002;Onsdag 19. Februar, 6 mann og en flyttebil;tim;9,5;2640.00;;;;

L;;1004;Torsdag 20. Februar, 2 mann og en flyttebil;tim;3;1160.00;;;;

A;34268;Gregers Gram;Helteveien 2 b;;0586;Oslo;94 30 47 06;gregers.gram@gmail.com;;;NO;7;-2147483647

H;20200225;20200225;34268; Gregers Gram; Helteveien 2 b;;;;0586;Oslo;;;0;;;;;;7;;5315;NO;-2147483647

L;;1002;Flytting timepris 3 mann med 35m3 bil;tim;11;1580.00;;;;

L;;1002;Flytting timepris ekstramann;tim;5;480.00;;;;

L;;1010;Bompassering ;stk;1;560.00;;;;

A;34287;Helse og Omsorgstjenester AS;Verven 34;;3041;Drammen;95060443;hilde.hansen@mac.com;998 131 952;;NO;7;-2147483647

H;20200225;20200225;34287;Helse og Omsorgstjenester AS;Verven 34;;;;3041;Drammen;;;0;;;;;;7;;5329;NO;-2147483647

L;;1002;Flytting timepris 2 mann og flyttebil på 35m3;tim;10;1200.00;;;;

L;;1006;Flyttevask timepris pris pr. person pr. time;tim;12;520.00;;;;

L;;1009;Lagring, pris pr. pall Februar 2020;stk;15;100.00;;;;

L;;1009;Lagring, pris pr. pall Mars 2020;stk;15;300.00;;;;

H;20200225;20200225;30032;Storkunde;Pb. 700;;;;1334;Sandvika;;;0;;;;;;30;KO615 937;5335;NO;-2147483647

L;;1002;Flytting timepris 2 mann med 20m3 bil;tim;6;1340.00;;;;

L;;1006;Flyttevask timepris;tim;13;560.00;;;;

L;;1007;Kasser, flytteembalasje og forbruksmateriell;stk;1;740.00;;;;

L;;1008;Renovasjonsavgift pris pr. kg;kg;880;3.00;;;;

A;34355;Gunnar Knutsen;Trikkeveien 89;;1369;Stabekk;96143326;gunnar.knutsen@gmail.com;;;NO;7;-2147483647

H;20200225;20200225;34355; Gunnar Knutsen; Trikkeveien 89;;;;1369;Stabekk;;;0;;;;;;7;;5345;NO;-2147483647

L;;1002;Flytting timepris 2 mann med 20m3 bil;tim;3;1040.00;;;;

L;;1008;Renovasjonsavgift beregnes etter utført arbeid;kg;680;2.80;;;;

A;34359;Jørgen Hattemaker;Grenda 34 g;;0284;Oslo;59373240;jorgen.hattemaker@klp.no;;;NO;7;-2147483647

H;20200225;20200225;34359; Jørgen Hattemaker; Grenda 34 g;;;;0284;Oslo;;;0;;;;;;7;;5346;NO;-2147483647

L;;1002;Nedpakking og flytting timepris 3 mann og flyttebil 35m3;tim;3;1680.00;;;;

L;;1002;Flytting timepris to mann og 35 m3 flyttebil;tim;7;1200.00;;;;

A;34360;Norske Bæresystemer AS;Vækerøveien 3;;0281;Oslo;59062341;Trine Olsen <to@norbs.no>;996808548;;NO;7;-2147483647

H;20200225;20200225;34360;Norske Bæresystemer AS;Vækerøveien 3;;;;0281;Oslo;;;0;;;;;;7;;5348;NO;-2147483647

L;;1002;Flytting timepris 2 mann med 20m3 bil;tim;5;1080.00;;;;

L;;1010;Bompassering ;stk;1;60.00;;;;

H;20200225;20200225;33238;Bruttokunde;Pb. 700;;;;1334;Sandvika;;;0;;;;;;30;KO616 272;5353;NO;-2147483647

L;;1002;Fjerning av båthenger;tim;2;3000.00;;;;

L;;1008;Renovasjonsavgift;kg;680;2.80;;;;

A;34425;Egertorget Invest AS;Nedre Slottsgate 8;;0157;Oslo;46925550;988989418@autoinvoice.no;988989418;;NO;0;-2147483647

H;20200225;20200225;34425;;;;;;;;;;0;;;;;;7;;5354;NO;-2147483647

L;;1002;Flytting 20. Februar 2 mann og bil;tim;5;1200.00;;;;

L;;1010;Bompassering ;stk;1;60.00;;;;

H;20200225;20200225;30379;;;;;;;;;;0;;;;;;14;;5361;NO;-2147483647

L;;1002;Flytting timepris to mann og 20m3 flyttebil;tim;3;1040.00;;;;

A;34414;Egertorget Eiendom AS;Nedre Slottsgate 8;;0157;Oslo;46925550;988989418@autoinvoice.no;988989418;;NO;0;-2147483647

H;20200225;20200225;34414;;;;;;;;;;0;;;;;;0;HÅVARD HEDDE;5366;NO;-2147483647

L;;1002;Flytt Eger Skin Clinic Søndag 16/2 5 mann 10:00 - 15:00;tim;5;5400.00;;;;

L;;1002;Flytt Eger Skin Clinic Søndag 16/2 1 mann 15:00 - 18:00;tim;3;1080.00;;;;

For anledningen er A-radene med nye kunder markert med blå skrift, mens ordre til kunder som tidligere er opprettet er markert med rødt.

Saksbeskrivelsen er slik:

Bruk imp-fil som allerede ligger på saken.
Opprett produktene 1001, 1002, 1003, ..., 1010.
Opprett kundene 30032, 33238 og 30379 - og sett Kundepref. til h.h.v. 8, 256 og 16384 på disse tre kundene.
La kunde 30032 ha navnet 'Storkunde'
La kunde 33238 ha navnet 'Bruttokunde'
Kunde 30379 kan ha navnet 'Samlet levering'
Les inn EDI-filen: Orders1182.edi.
Kundepref. blir ikke importert i EDI-filen, men kundene som opprettes "arver" Kundepref. fra forrige kunde som brukes på EDI-meldingen! 

De fire første kundene som opprettes får ingen verdi i Kundepref.
Det gjør heller ikke de første fire ordrene.

Så kommer en ordre til 'Storkunde' som har Kundepref=8 (og Ordrepref. settes til 16). Greit nok.

Deretter kommer det nye kunder på EDI-meldinen. Disse får Kundepref=8!

Lenger ned i meldingen kommer det en ordre til 'Bruttokunde' som har kundepref.=256 (og Ordrepref. settes til 256). Greit nok det og.

Men neste kunde som leses inn arver Kundepref. fra Bruttokunde.

Dette kan ikke være rett?
Hvordan unngår vi at nye kunder arver Kundepref. fra forrige ordre?

Så har jeg kontrollert om det er andre felt enn Kundepref. som arves.
Og svaret på det er JA!
For meg ser det ut som at alle felt som ikke er med på EDI-meldingen arves. I alle fall gjelder dette:
- Aktørbehandling
- Lev.pref.
- Sendemåte for dokument
- Adresselinje 3 - 4
- Adm.tid, Lev.tid
- Motkonto kundde
- Att.ansvarlig,
- Autoinvoice e-postkonto
- Bankforbindelse
- Bankkonto
- Bankpartner
- Innkjøper & Selger
- Kontosett kunde & leverandør
- Leveringsmåte kunde & leverandør
- Leveringsbet. kunde & leverandør
- Betalingsmåte kunde & leverandør
- Kredittgrense
- Kredittsperre
- Lagernr kunde & leverandør
- Valutanr
- Matchingsmet. kunde
- Kundeprisgr. 1 - 3
- Totalrabatt % kunde
- Avg.kode kunde
- Lev.beskjedinterv.
- Leveringsprioritet
- Dir. deb. status
- GLN/GS1 nr.
- EBF valutakode
- EBF avg.kode
- Dekl.kode
- EDF bet.metode
- EBF separator
- E-post malgruppe
- Ansattprisgr.
- Mva. reg.nr
- Sp.avg. fritak
- Område
- Factoringnr
- Fact.selsk.nr/KID-def.
- Purregebyr
- Gr.1 - 12
- Opplysning 1 - 8
- Inf.kategori
- Web-side 1 - 2
- Rentesats
- Språknr
- Mobiltelefonnr
- Antall ansatte
- Stillingsbrøk
- Person ID
- Alle ansvarsenheter
- Kortnavn
- Tittel
- Deres ref.

Status: Ny

EDI-innkjøp mangler Lev.alt.nr og dermed også Lev.tid, Transp.tid og Frakt-påslag (Ticket 1571622, 5mar2020)

Jeg har lagt inn Lev.tid, Transp.tid og Frakt1 på leveringsalternativ.

Ved manuell registrering av innkjøpsordre finner VBus Lev.alt.nr og dermed også Lev.tid, Transp.tid og Frakt-påslag.

Ved EDI-import blir Lev.alt.nr ikke satt (funnet) og dermed mangler også Lev.tid, Transp.tid og Frakt-påslag.

Bruk standard OrdersR og f.eks. denne EDI-filen:

H;;;;;50002;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;6
L;;221;;1
L;;222;;20
L;;236;;20

 Hva må jeg gjøre for at EDI-ordrene skal finne lev.tider og frakt-påslag?

Status: Ny

Feil i vinduer i versjon 14

I versjon 14.01 kom det omsider (ref. Mens vi venter på Godot) vinduer i nytt design. Men som jeg påpekte i Godot er en skrotnisse er det en del feil i dem. Dette er til dels feil som også var i det gamle vindusoppsettet og dels nye. Jeg vet ikke hvor mye tid jeg har kastet bort på å fortelle Visma om dette, for dét er å tale til stokk døve ører. Så dette er på ingen måte feil som Visma erkjenner på noe som helst vis. Men; hvis du skal ta dem i bruk, så må du rette opp følgende feil:

·         0201. Faktura / kreditnota. Her er det flere feil;

o   Fanen Alle aktive ordre à Info: Memofeltet er forankret feil. Det er om lag 30 tegn på utsiden av skjermen.

o   Fanen Alle avsluttede ordre, boken med Ordre og Ordreinfo er ikke ankret i høyre kant.

·         0217. Bokføring av kostnader: Her er deg flere feil;

o   Har du en lagerkorrigering som ikke er manuelt registrert eller oppstått ved lagertelling, kommer disse ikke med.

o   Korrigerte kostnader for annet enn salg er ikke med

o   Kostnader for varer i arbeid (vareforbruk i produksjon) er ikke med

·         2102. Avstemming: I fanen Konsistenskontroll:

o   Det mangler utvalg i nederst til venstre (Hovedbokssaldo leverandører)

o   Det vises feil kolonne for Hovedbokssaldo kunder

·         2300. Avdelingsrapport, fanen Resultatrapport: Det foreslås 2008/1 til 2008/12.

·         2301. Prosjektrapport, fanen Resultatrapport: Det foreslås 2008/1 til 2008/12.

·         2302. Kampanjerapport, fanen Resultatrapport: Det foreslås 2008/1 til 2008/12.

·         0300. Tilbudsordre,

o   Fanen Tilbud: Ved lagring «forsvinner» det som er registrert slik at man må gå til neste fane, Alle tilbud for å fortsette med tilbudet.

o   Fanen Tapte tilbud:

§  Ordretabellen er ikke ankret på høyre side.

§  Boken med sidemerke Linjer er ikke ankret dynamisk.

·         0303. Salgsordre

o   Fanen Innkommende e-ordre: Boken med fanene Ny ordre og Behandlet er ikke dynamisk ankret.

o   Fanen Lag faktura: Ordrelinje-tabellen er ankret i høyre side, men ikke ytterst til høyre. På smal skjerm forsvinner kolonnen til høyre.

·         3001. Utleie:  Det er ikke mulig å registrere kundenr.

·         3002. Utlån:

o   Det er ikke mulig å registrere kundenr.

o   Når du registrerer ny ordre, blir det en utleie-ordre (Transtype=2) og den forsvinner ved lagring.

o   Det mangler fane for tilbakelevering slik vindu for utleie har.

·         0333. Salgsrapporter/prognose: Feil i utvalg; i tillegg til salgsordre som ikke er fakturert har vi med tilbud, ubehandlede ordre, budsjettordre og annullerte ordrelinjer. Siden det vises både salgsordre og utlånsordre ville det være naturlig at kolonnen Transtype ikke var skjult. Og ikke minst, siden vi har med det som er ferdigmeldt, men ikke fakturert ville det være naturlig å vise Fakturabeløp i fremtid…

·         0335. Analyse kunder: Nederste bok og tabellene i den er ikke dynamisk ankret

·         0350. Kopi av ordredokumenter, fanen Faktura viser bare det som er sendt (og levert) til Autoinvoice. Så hadde det vært praktisk om ordredokumentene var sortert på fallende ordredokumentnr og at kolonnen Formularnr ikke er skjult.

·         0403. Innkjøpsordre

o   Fanen Innkjøpsordre: Knappen [Send til godkjenning] er ikke rett forankret. Så ville det ha vært praktisk med en egen underfane (ved siden av Leveringsalternativ som viser alle produkter fra samme leverandør.

o   Fanen Godkjenning: Bøkene og tabellene i dem er ikke dynamisk ankret.

o   Fanen Bekreftelse: Ankringsfeil hele veien.

o   Fanen Varemottak: Ankringsfeil mange steder

o   Fanen Fakturamottak; Venter på faktura: Feil i utvalg som gjør at du ikke lenger ser ordren etter å ha lagt inn Fakturanr. Og ankringsfeil flere steder.

o   Fanen Alle avsluttede innkjøpsordre: Feil i utvalg; du ser ordre hvor det er foretatt et fakturamottak, men dette kan samtidig være ordre som både er klare for varemottak og fakturamottak – så helt avsluttede er de ikke nødvendigvis.

o   Fanen Alle aktive ordre: Feil i utvalg; du ser ordre som er klare for varemottak, men ikke de som er klare for fakturamottak.

·         0431. Kjøpshistorikk

o   Fanene Leverandør, Produkt og Innkjøper viser ikke kjøp av tjenester, frakt, etc. (altså det som ikke er lagerhåndert) og viser bare det som er fakturamottatt.

o   Fanene Leverandør/produkt og Produkt/leverandør viser både vare og tjenester, men bare det som er fakturamottatt.

·         0432. Innkjøpsrapporter/prognose, fanen Produkt/Leverandør: Feil i utvalg; har med det som er annullert.

·         0500. Monteringsordre, fanen Realisering: Feil i utvalg (Ordrestatus 1 = 8388608). Her vil det aldri dukke opp noen ordre. Nøkternt sett burde det ha vært en egen fane for ordre hvor alt er ferdigmeldt, men hvor en eller flere vareforbrukslinjer fremdeles har midlertidige kostnader. Og at fanen Realisering bare viser produksjonsordre som er klar for realisering.

·         0611. Lagertelling, fanen Reservasjoner. Underfanen Ordrelinjer med reservasjoner viser ordrelinjer med positivt antall (også de som er annullert), ikke bare de som har reservasjoner. Og så ligger en linje utenfor skjermen (ankringsfeil).

·         0645. Produktkatalog: Ingen dynamikk (tilpasser seg ikke skjermstørrelse).

·         1002. Opprett nytt firma: Ankringsfeil.

·         10451. Tidsstyrte oppgaver: Ankringsfeil.

·         1054. Visma.net AutoPay logg: Ankringsfeil i tabellene i samtlige sider bortsett fra den første.

·         1055. Visma.net AutoReport-arkiv: Ankringsfeil i samtlige tabeller.

Svært mange av vinduene som er beregnet for utskrift har et kolonneoppsett som er for bred på en A4-side;

·         0200. Bilagsregistrering, fanen Utskrift av ikke oppdaterte bunter.

·         0236. Utskrift av kontoplan.

·         2300. Avdelingsrapport, Kontoutdrag og Resultatrapport; Mot budsjett og Avstemming.

·         2301. Prosjektrapport, Kontoutdrag og Resultatrapport; Mot budsjett og Avstemming.

·         2303. Kampanjerapport, Kontoutdrag og Resultatrapport; Mot budsjett og Avstemming.

Det samme gjelder flere av formularene. Følgende utskriftsoppsett må endres:

·         10201. Purrebrev 1* som brukes på samtlige purreformularer (1, 3 og 4).

·         10203. Rentenota 1* som brukes på samtlige renteformularer (1, 3 og 4).

·         10205. Tilbud 1* som brukes på ordreformular 2.

·         10207. Ordrebekreftelse 1* som brukes på formular 11, 12, 15 og 121.

·         10209. Plukkliste 1* som brukes på formular 25.

·         10211. Følgeseddel 1* som brukes på 31, 32, 35 og 56. 

·         10215. Faktura 1* som brukes på formular 61, 62, 65, 70, 75, 76, 77, 78, 117, 118 og 119.

·         10224. Faktura ingen kolonne heading som brukes på formular 66.

·         10220. Bestilling 1* som brukes på formularene 91, 92 og 120.

Så er det min mening at standardvinduene burde har utnyttet funksjonalitet som ble introdusert for mange år siden; at irrelevante behandlingsvalg og rapporter var eliminert – slik at man kan begrense antall alternativer og hindre brukere å velge feil.

Regnsk. år/per på produkttransaksjon endres umotivert (CRM 67575250 og Ticket 34481 7sep2015)

Dette er ikke noe Visma betrakter som feil, fordi det bare oppstår om man ikke bokfører midlertidig lagerverdi ved salg. Kort fortalt er problemstillingen som følger: Du mottar et parti varer i romjulen. Halvparten selges i desember, resten i januar. Så gjennomføres fakturamottaket hvor kostpris er endret (f.eks. på grunn av endret valutakurs). Dersom den inngående fakturaen bokføres i desember, så endrer VBus Regnsk. år/per. på salgstransene som ble fakturert i januar – og setter Regnsk. år/per. til desember! Og hvis den inngående fakturaen bokføres i januar, så endrer VBus Regnsk. år/per. på salgstransene som ble fakturert i desember – og setter Regnsk. år/per. for disse transene til januar. Og Visma regner ikke dette som feil! Den opprinnelige saksbeskrivelsen (fra CRM) er:

Jeg har et innkjøp som er varemottatt i 2013 og varene er solgt og fakturert i desember 2013.
Det er således ikke noe på lager (fysisk) i 31.12.2013 og både tellbart og telt antall pr. 31.12.2013 er null.

Innkjøpstransene (produkttransaksjonene) er merket med TransStatus=16 [Avventer realisering].
Salgstransene (produkttransaksjonene) er merket med TransStatus=1 [Midlertidige kostnader].
Både innkjøps- og salgstransene har Regnsk. år/per.=2013/12 (og Realisert år/periode=2013/12).

Innkjøpsfakturaen er datert i januar 2014. Det gjennomføres fakturamottak etter at valutakurs er endret (evt. etter endring i pris eller rabatt) slik at kostpris (kr) endres.
Innkjøpstansene blir oppdatert og både 'Regnsk. år/per.' og 'Realisert år/periode' endres til 2014/01. Det er OK.
Realisert år/periode på salgstransene endres ikke. Det er OK.

Regnsk. år/per. på salgstransene oppdateres ikke på versjon 5.21 av VBus. Det er OK.
Regnsk. år/per. på salgstransene oppfateres ikke på versjon 5.32 av VBus. Det er OK.
Regnsk. år/per. på salgstransene endres til 2014/01 på versjon 8.02 av VBus. Det er ikke OK.

Bokfør korrigerte kostnader med valuteringsdato i februar 2014.
Regnsk. år/per. på salgstransene oppdateres ikke på versjon 5.21 av VBus. Det er OK.
Regnsk. år/per. på salgstransene endres til 2014/02 på versjon 5.32 av VBus. Det er ikke OK.
Regnsk. år/per. på salgstransene endres til 2014/02 på versjon 8.02 av VBus. Det er ikke OK.

For de av oss som er oppratt av avstemming av lagerverdi mellom logistikk og regnskap er dette katastrofe.
Hvis dere ikke forstår hva jeg mener ber jeg dere kjøre rapporten Logistikk==>Lagerverdi fra Visma rapporteing for periodene 2013/12, 2014/01 og 2014/02
- før fakturamottak,
- etter fakturamottak men før bokføring av korrigerte kostnader,
- etter bokføring av korrigerte kostnader.

Status: Løsning foreslått

Kommentar på saken 6mai2016: Hos alle våre kunder som plages med denne feil har jeg fortalt at en løsning er å bokføre midlertidig lagerverdi ved salg, men når jeg samtidig forteller at de da ikke kan trekke tilbake ferdigmelding med negativt antall i Ferdig NÅ og at om de gjør det ved å trekke tilbake plukkiste eller slette reservasjonsrad så får de bokføringsfeil (se sak 101241), da velger alle å heller leve med feil Regnsk. år/per. Ulempene som bokføring av midlertidig lagerverdi har for driften på lageret er mye større enn gevinsten ved denne bokføringen.

 

Selv om jeg her har vært frekk og freidig – og listet opp feil som jeg mener burde ha blitt rettet; de fleste feil som jeg har meldt har blitt rettet – og de har jeg ikke listet opp her. Finner du feil i VBus, så ta deg tid til å lage en presis beskrivelse av feilen. Tenk på det som en løk og forsøk å skrelle løken til du sitter igjen med en svært enkel og lettfattelig beskrivelse av feilen – hvor alt irrelevant er fjernet. Ingen applikasjon er uten feil og jo tydeligere beskrivelsen er, jo raskere blir den rettet. Det kan oppleves som at forhandlersupport fungerer som et førstelinjeforsvar for å beskytte utvikling, men det får så være. Vi er her for kundene våre og om vi må svelge en kamel for å få formidlet budskapet slik at feilen blir erkjent og klassifisert som feil, så får det heller være slik. Når du har kommet så langt, er det viktig å gi de som prioriterer hva som skal rettes – og hva som skal forbli feil – informasjon om hvorfor det er viktig at det blir rettet. Det kan kreve et par nye kameler, men hva gjør vi ikke for kundene våre?

 

 

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

 

frode@antun.no