22. mars 2020

Endret 24. april 2021

Forslag til forbedring av Visma Business

Jeg har gjennom årenes løp i møte med brukere fått mange innspill av typen burde ikke … ha vært annerledes eller burde det ikke være mulig å gjøre …. Da pleier jeg å svare; Burde er et moralspørsmål. Det tar jeg stilling til på søndager. Resten av uka forholder jeg meg til hvordan Visma Business er.

Siden det er søndag, tenker jeg det er høvelig å skrive om hvordan jeg tenker at Visma Business (VBus) burde være. Nærmere bestemt mine forslag til endringer og forbedringer som jeg har sendt inn til Visma de siste årene.

Eksport fra VBus uten DME-kolonner (Ticket 31660, 16aug2015)

Hvis man har opprettet egne kolonner med DME vil disse bli tatt med ved eksport fra VBus. Da er det ikke mulig å importere filen til annen installasjon uten samme DME-oppsett. Dette blir spesielt lite praktisk ved feilsøking av problemstillinger som ikke har noe med DME å gjøre.
Jeg ønsker en endring i Eksporter-dialogen: Når DME er i bruk ønsker jeg en mulighet til å utelate DME-kolonner og -tabeller.

Valutakursjustering på innkjøpsordre (Ticket 34320, 5sep2015)

Ønsker samme funksjon på innkjøpsordre som finnes på salgsordre; at valutakurs på ordre (og ordrelinje) endres til dagens kurs (evt. kurs satt i valutakurstabell for fakturaens dato). Jeg ser at det er lagt opp til dette i Lev.pref. på aktør, men er blokkert i Ordrepref. i ordre.

EDI-sesjon uten melding som dialog (Ticket 34322, 5sep2015)

Mange (de fleste) som bruker EDI-klokka kjører denne som en tidsstyrt oppgave på en server hvor ingen er til stede for å svare på meldinger som måtte dukke opp. Som standard ønsker jeg at meldinger fra EDI-sesjonen ikke presenteres som en dialog, men skrives til EDI-loggen. Dersom det er noen som ønsker disse meldingene som dialog også for EDI-sesjonen må det implementeres et valg i menyvalget Start EDI-klokka om meldinger skal vises som dialog eller skrives til EDI-loggen.
Et alternativ er at det i Brukerpref. legges opp et alternativ av typen "Vis meldinger på statuslinjen, ikke som dialog". Og at slike meldinger fra EDI-sesjonen alltid skrives til EDI-loggen.
Hensikten med dette er å unngå at EDI-klokka stanser etter utskrift av ordredokumenter som sendes på mail eller etter regenerering av lagersaldo med urealiserte lageroverførsler eller andre situasjoner hvor VBus presenterer en melding som krever at brukeren svarer på noe vis.

Kommentar: Med jobbplanleggeren i VBus kan man flytte mange av (men ikke alle) de oppgavene som kan gi en melding som dialog og dermed stanser EDI-klokka.

Backup og logging av innleste EDI-meldinger (Ticket 34323, 5sep2015)

OrdersR-meldinger legges i Orders.bak fil etter at EDI-klokka har lest dem inn. Her ønsker jeg at det i backup-filen legges inn en kommentar-linje som viser dato og klokkeslett for når meldingen ble lest inn
Så ønsker jeg tilsvarende backup-fil av det som leses inn fra IMPORTS-mappen.
Og at om man i EDI-feilrapportnivå (systemopplysninger) har krysses av for "Normal" så ønsker jeg at det skrives inn i EDI-loggen at både navnet på filen som er lest inn og at det også logges innlesing av meldinger fra IMPORTS-mappen (inkl. navnet på meldingen).

Oppstramming av struktur (Ticket 34325, 5sep2015)

Ved bruk av struktur - og særlig i produksjon - vil det være slik at det i praksis ikke kan ferdigmeldes mer på strukturhodet, enn det som er ferdigmeldt på strukturlinjene.

Eksempel: Produksjon av traller hvor en tralle består av 1 ramme og 4 hjul. Når det legges inn en produksjonsordre på 10 traller og det bare er mulig å ferdigmelde 24 hjul,
skal det ikke være mulig å ferdigmelde mer enn 6 traller. I dag finnes det i behandlingsmåte en mulighet for 'Plukk samme andel av struktur' (som gjelder antall på plukklisten),
men jeg ønsker en mulighet til å angi at det ikke skal kunne ferdigmeldes mer på strukturhodet enn andelen på strukturlinjene tilsier. Se også ønske om minste antall (ticket 34326).

Det skal fremdeles være mulig å ferdigmelde strukturlinjene fra strukturhodet, men da slik at det ferdigmeldes "samme andel av struktur". Det samme gjelder om ferdigmeldingen skjer fra ordrehodet.

Kommentar: Dette er en gjenganger i mine diskusjoner med kunder som bruker produksjonsordre eller salgsordre hvor det er angitt ‘Plukk samme andel av struktur’. Tenk deg en mekaniker som skal ha med et servicekit bestående av olje, filter, plugger og pakninger. Det er ikke mulig å utføre denne servicen om det mangler en pakning. Det er for lett å gjøre feil i VBus her.

Minste antall (Ticket 34326, 5sep2015)

En del produkter er slik av natur at det aldri er aktuelt å handle mindre enn et helt antall.
Selger man biler er det ikke aktuelt å kjøpe eller selge 0,4 bil. Og heller ikke 4,4 biler.
Jeg ønsker meg et felt som viser minste antall av et produkt. Dersom dette settes til 1 skal det ikke være mulig å registrere annet enn heltall i Antall.
Dersom dette er 2 skal det bare være mulig å registrere et partall som antall. Er minste enhet 0,25 så skal det ikke være mulig å kjøpe eller selge 0,2 eller 0,3.
Det samme gjelder Telt antall ved lagertelling og antall som overføres i rutiner for lageroverførsler og splitting av parti.

Kommentar: Jeg har sett en del grelle situasjoner med bruk av desimaltall. Salg av parkett er én av dem. Her må man ta stilling til hva som skal være lagerført enhet. Tenk på hvordan lagertelling gjennomføres. Det er ikke m² vi teller opp. Heller ikke bord. Men pakker. Så pakke må være den lagerførte enheten. Det er helt uproblematisk i VBus å la prisenhet være m² selv om salgsenhet er pakker. Antall m² i en pakke er informasjon om innhold som gjerne kan brukes til beregning av beløpet, men det er et hele antall pakkes som går inn eller ut av lager. Så har jeg også sett de som selger et bord fra en pakke med seks. Da blir antallet 0,166666. Merk at VBus bruker 6 siffer etter komma. Det betyr at når du har solgt 6 løse bord, så har det gått 6 x 0,166666 = 0,999999 pakker ut av lager. Dersom man driver en virksomhet som bryter forpakning ved salg må konsekvensen være at det er bord som er den lagerførte enheten. Det blir litt mer styr å foreta lagertelling. Men det er fremdeles mulig å selge pakker á 6 bord uten å få avrundingsproblemer. En alternativ konsekvens er å endre rutiner, slik at ingen bryter forpakning.

Egne opprinnelser for bokføring og tilbakeføring av midlertidig lagerverdi (Ticket 34328, 5sep2015)

Slik det er nå får bokføring og tilbakeføring av midlertidig lagerverdi Opprinnelse 16 som er Bokføring av kostnader. På samme måte som at det er flott at bokføring av korrigerte kostnader er tildelt sin egen opprinnelse (40) ønsker jeg at bokføring av midlertidig lagerverdi skal få sin egen opprinnelse og tilbakeføring skal få sin egen opprinnelse. Dette for å gjøre kontroll og avstemming enklere.

Siste kommentar fra Visma på saken (12apr2018) er: Saken er blitt behandlet på flere prioriteringsmøter, og siden ønsket ikke har nådd opp i løpet av 2 og et halvt år, endres status på saken.

Lagerbevegelse, Lagerverdi og Bokført verdi i realisasjonsjournallinjene (Ticket 34329, 5sep2015)

Slik det er nå oppdateres Lagerbevegelse, Lagerverdi og Bokført verdi i realisasjonsjournallinjene bare på normalordre når ordrelinjen har behandlingsmåten "Bokfør midlertidig lagerverdi".

Jeg ønsker at Lagerbevegelse, Lagerverdi og Bokført verdi alltid blir oppdatert slik at sum Lagerbevegelse på realisasjonsjournallinjene stemmer med produkttransene. Er det ikke bokført midlertidig lagerverdi må Lagerbevegelsen settes på den realisasjonsjournallinjen hvor lagerbevegelsen realiseres. Og det må alltid lages realisasjonsjournaler - også for kontantordre.

Tilsvarende for Lagerverdi og Bokført verdi. Summen av Bokført verdi på realisasjonsjournallinjene må stemme med det som er ført i hovedbok..

Kommentar: Dette er en begredelig historie. Da Visma begynte å arbeide med realisasjonsjournalene, var det for å kunne følge transaksjonene fra logistikken til regnskapet og tilbake, jfr. kontrollsporet. Men om du ikke bokfører midlertidig lagerverdi ved innkjøp, produksjon og salg får du ikke komplette realisasjonsjournaler. Og om du bokfører midlertidig lagerverdi, så er det ikke mulig å trekke ferdigmelding tilbake fordi ferdigmeldingen allerede er bokført. Dette er en showstopper for alle våre kunder. Så konsekvensen er at vi har en glimrende løsning (realisasjonsjournalene) som ingen bruker! Siste kommentar fra Visma på saken (14apr2018) er: Som forrige sak, er også denne vurdert og ikke blitt prioritert. Jeg gremmes.

Endring av antall pr. enhet på ordrelinje (Ticket 34331, 6sep2015)

Dersom det gjøres endring i antall pr. enhet på ordrelinje (evt. endring i Enhet slik at Antall pr. enhet endres) ønsker jeg at VBus som standard gjøre nytt oppslag i pris/rabatt-matrisen.
I behandlingsmåten endres alternativet 'Ikke foreslå pris/rabatt på nytt' til 'Ikke foreslå pris/rabatt på nytt ved endring av Antall'.
Det legges opp et nytt alternativ som heter 'Ikke foreslå pris/rabatt på nytt ved endring av Antall pr enhet'.

Kommentar: Deler av forslaget er implementert; VBus gjør nå oppslag i Pris/rabatt-matrisen ved endring av Enhet. Men vær oppmerksom på at om man har behandlingsmåten Ikke foreslå pris/rabatt på nytt så er det nettopp det som (ikke) skjer.

Ny tabell: ProduktEnhet (Ticket 34332, 6sep2015)

Noen produkter kan kjøpes og selges i flere ulike enheter; stk, pakke, eske, pall, etc.
Hvor mange stk det er i en pakke, for ikke å snakke om på en pall, vil variere fra produkt til produkt.
Jeg ønsker derfor en tabell med Produktnr og Enhet som nøkkel og innhold for øvrig som i Enhetstabellen.
Når Enhet endres på en ordrelinje må VBus først gjøre oppslag i Produktenhets-tabellen for å hente verdiene derfra.
I behandlingsmåte på produkt (og ordrelinje) foreslås et alternativ; avvis enheter som ikke finnes i Produktenhet.
Dersom dette ikke er satt hentes verdiene fra Enhetstabellen.

Grunnenhet (Ticket 34333, 6sep2015)

På produkt har vi Standard enhet (og antall pr. enhet) og på leveringsalternativ har vi Enhet som brukes ved innkjøp.
Vi kan altså ha et produkt som kjøpes inn på fat á 500 liter og selges på kanner á 4 liter. Det er ikke noe sted i VBus som viser at den lagerførte enheten er LITER.
På produktet står det at Standard utsalgsenhet er KANNE med 4 pr enhet. Og på leveringsalternativet står det at det kjøpes inn FAT med 500 pr. enhet.
Men det står ikke noe hva grunnenheten er.

Jeg ønsker meg et felt som viser Grunnenhet, i dette eksempelet LITER.
Dette er viktig ved lagertelling slik at man vet hva som skal telles..

Kommentar: Med DME er det fort gjort å implementere Grunnenhet – som med fordel kan hete Lagerført enhet.

Areal, volum og nettovekt på produkt (Ticket 34334, 6sep2015)

På produkttabellen (og ordrelinjetabellen) er det mulig å legge inn verdier i kolonnene Areal, Volum og Nettovekt.
Samtidig blir disse beregnet slik
Areal = Lengde x Bredde
Volum = Areal x Høyde
Nettovekt = Volum x Densitet

Det er mange som legger inn Nettovekt og Volum uavhengig av hverandre. Eller andre måltall uavhengig av hverandre.
Men straks vi endrer Lengde eller Bredde så endres Areal.
Og når Areal eller Høyde endres, så endres også Volum.
Og når Volum endres så endres også Nettovekt.

Vennligst registrer følgende ønske:
Det legges opp i Behandlingsmåte en mulighet for å
- Ikke beregn Areal, Volum eller Nettovekt.

Kommentar: Det er gjort en forandring i VBus etter dette. Hvis Densitet er null, så settes ikke Nettovekt til null ved endring i Volum. Men om Høyde er null så settes Volum til null ved endring av Lengde, Bredde eller Areal. Veldig irriterende. Hos noen har vi med DME satt opp et eget Volum-felt (som er uavhengig av Lengde, Bredde, Areal og Høyde) og en trigger som skyver verdien i DME-Volum-kolonnen tilbake til standard Volum-kolonne. Og så har vi skjult standard Volum-kolonnen fra alle brukere. Det fungerer glimrende.

MVA i flere land (Ticket 35318, 11sep2015)

Flere og flere av våre kunder har (innenfor samme juridiske enhet/org.nr) virksomhet i flere land og er momsregistrert i disse landene.
Jeg ønsker at det etableres støtte i VBus for dette.
Rent praktisk tenker jeg at
- i landtabellen må det opprettes felt for oppgjørskonto mva
- i momstabellen (og muligens avg.kode-tabellen) må det opprettes felt for land
- i avg.termin-tabellen må det opprettes felt for land
- i utskriftsdialogen for momsoppgave må det være mulig å velge land
- makroene som brukes på momsformularene må beløpene være presentert i den valuta som er angitt i land-tabellen
- bilaget som produseres må suppleres med en agio/disagio-post.

Standard rabatt% på ordrelinje (Ticket 37598, 25sep2015)

På ordrelinje finnes Standardpris og Standardpris (kr), men ikke Standardrabatt %.
Jeg ønsker at ordrelinjen settes opp med Standardrabatt % (og helst Standardrab. 2%, ... 3%, ...4% og ...5%) som settes når VBus gjør oppslag etter rabatt i pris/rabattmatrisen. Alternativt at det på ordrelinjen settes opp felt for Standardpris etter rabatt (i valuta og kr). Dette for å ha bedre etterkontroll med rabatter som faktisk er gitt og som avviker fra det som er satt opp i pris/rabatt-matrisen.

Standardpris på EDI-meldinger med pris (Ticket 37601, 25sep2015)

Når det leses inn en EDI-ordre som har pris gjør VBus ikke oppslag i Pris/rabatt-matrisen. Standardpris blir satt lik Pris på EDI-meldingen. Jeg ønsker at VBus henter Standardpris, Veil.pris og Pristype fra Pris/rabattmatrisen også når Pris er gitt på EDI-meldingen. Tilsvarende med Standardrabatt % (jfr. ønske 37598).
Årsaken er behovet for å kontrollere avviket mellom de prisene som er satt i Pris/rabatt-matrisen og de som kommer på EDI-meldingen. Det er fristende å ønske seg felt som Standardpris etter rabatt og Standardbeløp etter rabatt (både i valuta og kroner).

Leveres adresse på innkjøpsordre (Ticket 37751, 25sep2015)

Ved registrering av innkjøpsordre hentes "Leveres aktørnr" fra "Innleveres til aktørnr" på leverandøren. Hvis denne ikke er angitt hentes "Leveres navn", "Leveres xxx" fra bedriftsopplysningene. Egentlig er det vel slik at "Leveres navn", etc. hentes fra bedriftsopplysningene og endres om leverandøren er satt opp med "Innleveres til aktørnr".

Jeg ønsker følgende endringer:
Hvis det er angitt "Leveres aktørnr" i bedriftsopplysninger skal alle leveres-feltene på innkjøpsordre hentes fra denne aktøren. Og eventuelt endres om det velges en leverandrør som er satt opp med "Innleveres til aktørnr".

Ideelt sett burde det være mulig å angi "Leveres aktørnr" også på tabellen "Lager" slik at om man velger annet lager enn "Standardlager" så hentes leveres-opplysningene fra den aktør som i tilfelle er angitt på "Leveres aktør" på lager, men jeg forstår at dett krever modellendring..

Ordrestatus (Ticket 39586, 7okt2015)

Ønsker at Ordrestatus utvides slik at det fremgår om
- ordren er klar for å generere innkjøps/prod.ordre
- det er generert innkjøps/prod.ordre
Og med mulighet for å unnta ordren for dette.

Hensikten er selvfølgelig å kunne sette opp vinduer som viser ordre som er klare for ordregenerering etc.).

Ordrestatus (Ticket 48226, 22nov2015)

Jeg ønsker en egen tabell som viser en rad for hver gang det er foretatt en oppgradering; som viser hvilken versjon det er oppgradert til. Dette for å gjøre det lettere å se om noe rart har skjedd i den versjonen som nå kjøres eller om transen har oppstått på en tidligere versjon..

Ctrl-I i tabellen bilag (Ticket 75687, 2feb2016)

Når man innsatte en linje i tabellen bilag i versjon 5.21 arvet den nye linjen bilagsnummer fra linjen FØR den innsatte linjen. Fra og med versjon 5.32 (muligens fra 5.30) arver den nye linjen bilagsnummer fra linjen ETTER den innsatte linjen.
Jeg finner ikke at endringen er beskrevet (og begrunnet) i releasenotes.
Hvordan får jeg tilbake funksjonaliteten fra versjon 5.21?

Kommentar fra Visma: Sjekket med utvikling, og de visste dessverre ikke når denne endringen kom. Eneste vi kan gjøre er å melde det som et ønske.

Spesialavgift på bestilling - MVA og Ordresum blir feil (Ticket 82794 og 92315, 2feb2015)

Spesialavgift i VBus beregnes kun på salg (TransType=1).
Når jeg skriver ut bestilling på slike varer legger VBus til spesialavgift på bestillingens ordresum. Det kan ikke være rett.

Forslag fra Visma: The solution will be to use a form without the special tax.

Mitt svar til Visma: Det er ikke bare å utelate spesialavgiften fra formularet; Ordresum brutto blir også feil. Og om det er mva på spesialavgiften så blir også mva-beløp feil.

Tilbakemelding fra Visma: Fått definitivt besked att detta blir ett önskemål om förbättring.

Jeg gremmes.

Cost correction transactions across period border (Ticket  104130, 17mar2016)

I Bokføringstilfeller, sørg for at det er krysset av for Automatisk kost-korreksjon. I Regnskapsbehandling, sørg for at det er krysset av for HB-transaksjon pr. ordre ved postering fra Produkttransaksjon.

Registrer en innkjøpsordre og gjennomfør varemottak.
Registrer to salgsordre og gjennomfør fakturering, den ene med dato i denne måned og den andre i neste.
Endre innkjøpspris og gjennomfør fakturamottak med dato i samme måned som varemottaket. Det blir (bl.a.) bokført korrigerte kostnader for salgstransaksjonene.

Se på valuteringsdato på disse transene som har Opprinnelse=40 [Korreksjon av kostnader]. Dersom det i Bokføringstilfeller ikke er krysset av for Sett val.dato for kostnadskorrigeringer = fakturaens val.dato vil korreksjonene få sin Valuteringsdato fra innkjøpsordrens fakturadato. Korreksjonen av solgte varers kost for den andre salgstransaksjonen får helt feil dato.

Så da krysser vi av i Bokføringstilfeller for Sett val.dato for kostnadskorrigeringer = fakturaens val.dato. Nå får alle korreksjonene Valuteringsdato fra den første av de to utgående fakturaene. Dette blir fremdeles feil for den andre salgstransaksjonen.

På bilagslinjene må Valuteringsdato settes til den utgående fakturas dato (evt. til ferdigmeldt dato for transaksjoner som realiseres ved ferdigmelding).?

Kommentar: Dette er rettet i versjon 14, selv om rettelsen ikke er helt innertier – se det jeg har skrevet om Produksjon. Jeg tar det med her siden det fremdeles er noen som ikke har oppgradert til denne versjonen.

Send epost til ordrens kontaktperson (Ticket 109219, 28apr2016)

I tidligere versjoner gikk ordredokumenter på epost alltid via brukerens epost-klient, som regel Outlook.
I versjon 10 går epost aldri via Outlook om man bruker "Skriv ut".
Bruker man "Send e-post" ignorerer VBus at det står en kontaktperson på ordren.
Jeg ønsker at det enten gjøres slik at "Send e-post" foreslår kontaktpersonens epost-adresse om det i Sendemåte for dok. er angitt dette. Eller at det introduseres et alternativ "Send e-post til kontaktperson".

Kommentar fra Visma: Med den utvikling vi ser mht overføring av ordredokumenter elektronisk (AutoInvoice) vil det neppe være fornuftig å gjøre endringer i nåværende metoder for e-post sending.

Egen epost-adresse for faktura (Ticket 109220, 28apr2016)

Det er mange av våre kunder (som bruker VBus) som har små kunder som har satt bort regnskapsføringen til et byrå - som ikke er klar for AutoInvoice. Disse ønsker egen epost-adresse for faktura slik at de kan sende pakkseddel til kunden og faktura til regnskapsføreren..

Relevante enheter (Ticket 247997, 24feb2017)

Jeg har tidligere foreslått (se 34332) egen tabell for ProduktEnhet som viser hvilke enheter som er relevant for et produkt og med Antall pr. enhet som kan variere for ulike produkter med samme enhet.

I mangel av dette må man opprette mange enheter, f.eks. Pakke á 6 stk, Pakke á 12 stk, Pakke á 24 stk, etc. slik at man kan få rett Antall pr. enhet. I salgsordrevinduet kan jeg koble inn Pris- og rabattmatrisen (via Produkt) med utvalg på rader med Utsalgspris, med bruddsum på Enhet og bare vise sumlinjer og bare vise kolonnen Enhet. På denne måten kan jeg fortelle brukeren hvilke enheter som er relevante for salg. Tilsvarende kan jeg gjøre i innkjøpsordrevinduet, men da ha utvalg på Innkjøpspris i stedet. Det er allikevel ingen garanti for at ikke feil enhet blir brukt.

Jeg ønsker meg derfor et alternativ f.eks. i Ordrebehandling som heter "Tillat bare enheter som er brukt i Pris- og rabattmatrisen" underforstått på produktet. Her kan tenkes samme søkemekanisme i Pris- og rabattmatrisen som det VBus bruker for å søke etter pris og på den måten avgrense hvilke enheter som er relevant - i alle fall på salgs og innkjøpsordre.".

Kommentar fra Visma: Jag kan bara hålla med dig, Det är mycket problem med enheter.

Sperring av rader i enkelte tabeller (Ticket 248004, 24feb2017)

I tabellen Hovedbokskonto finnes kolonnen "Sperret" som blokkerer for å bruke kontoen i bilagsegistreringen.
Det samme gjelder Bilagsserie.
I Ansvarsehetstabellene finnes "Sperret" som et alternativ i Ansvarsenhetsbehandling. Da kan ansvarsenheten ikke brukes på ordre, bilag, etc.
Det samme gjelder i tabellen Kontonr-serier (i Kontonr-serie behandling), Plassering (i Plasseringsbehandling) og Driftsmiddel (i Driftsm.pref).
På Lagersaldo er det en viss mulighet gjennom Unnta fra ... og Utgår av ... i Best.beh.
På Produkt kan man bruke et erstatingsprodukt som i behandlingsmåte er blokkert for det meste, men "Sperret" er savnet.
På kunder er det mulig å sette en kredittsperre som hindrer registrering av normalordre, men ikke forhåndsordre.
På Formular kan man fjerne dokumenttyper og på den måten hindre at de blir brukt.

Det er ikke ønskelig å slette koder (f.eks. Avg.kode) som har vært i bruk, men sletting er eneste sikker metode for å hindre at de blir brukt.
De siste månedene har vi utstyrt de fleste av våre kunder med mange avgiftskoder de ikke skal bruke. Nå hadde det vært nyttig om vi kunne sperre de kodene som p.t. ikke er relevante hos den enkelte kunde.

Dette gjelder ikke bare Avgiftskode, men følgende tabeller:
Land, Språk, Valuta, Avgiftskode, Aktør, Postadresse, Betalingsbetingelse, Betalingsmåte, Produkt, Produktkategori, Avg. og bokf.gr., Lager og Bilagsart".

Relasjon: Produkttransaksjon - Kundetransaksjon (Ticket 329304, 8aug2017)

Det finnes en relasjon mellom Produkttransaksjon og Kundetransaksjon. Dermed kan man i Produkttransaksjon se om det som er fakturert er helt eller delvis betalt.
Men relasjonen forutsetter av Faktureres kundenr er lik Kundenr. Det korrekte er at Faktureres kundenr (på Produkttansaksjon) er det samme som Kundenr på Kundetransaksjon. Relasjonen slik den står gir ingen mening når Faktureres kundenr avviker fra Kundenr.

Kommentar: Det er en glidende overgang mellom det å påpeke feil og å komme med et ønske om forbedring, men at dette ikke er en feil har jeg vondt for å forstå.

Factoring med reskontroføring på den opprinnelige kunden i stedet for factoringselskap (Ticket 337426, 29aug2017)

En kunde vurderer VBus og vi gjennomfører et forprosjekt for å se om VBus passer eller ikke for dem. I denne sammenheng har følgende problemstilling kommet opp:

Kunden har factoring hos DnB. Når factoringfil sendens til DnB mottar kunden et forskudd.
Når sluttkunden har betalt til DnB får vår kunde betalt av DnB som motregnes mot forskuddet.
Hvis DnB må sende fakturaen til inkasso blir forskuddet trukket tilbake.
Vår kunde har dermed kredittrisikonen inntil sluttkunden har betalt til DnB (og innbetalingen er bokført og avregnet mot faktura).
Standard oppsett av Factoring innebærer at den åpne posten bokføres på DnB, ikke på sluttkunden.
Dermed vil kredittkontrollen i VBus ikke fange opp de ubetalte fakturaene som går via factoring. Vår kunde sier at dette er showstopper.

Kan jeg sette opp factoring slik at reskontroføringen skjer på sluttkunden, ikke på reskontroselskapet?.

Svar fra Visma: Det er dessverre ingen mulighet for å få reskontroføringen på kundene - dette vil bli ført på faktoringkunden. Det ligger flere ønsker på dette.

Beregnet kolonne i DME (Ticket 359072, 11okt2017)

På SQL-server er det mulig å sette opp en kolonne som Computed.
Jeg ønsker en mulighet for å bruke denne egenskapen på en kolonne i DME.
En beregnet kolonne i VBus gir ikke tilstrekkelig funksjonalitet med hensyn til søking og på sumlinjer.
Det kan selvfølgelig lages en trigger på databasen som foretar beregningene når en (eller flere) av kolonnene som inngår i beregningen endres, men det gjør at man må legge opp samme trigger hver gang et nytt selskap opprettes..

Feil i vindu 2102. Avstemming (Ticket 368821, 27okt2017)

Har lest inn vinduene fra NorLay (i Nor.int) til versjon 12.01.
Vinduet (som har nr. 2155) har tre feil i siden med overskriften Konsistenskontroll:
1. Det mangler utvalg i sideelementet nederst til venstre som skal vise samlet bevegelse på hovedbokssaldi for leverandører. Dermed vises sum saldo for alle konti.
2. Sideelementet nederst i midten, som skal vise samlet bevegelse på hovedbokssaldi for kunder, viser sum UB i stedet for sum bevegelse.
3. De to sideelementene på høyre side som viser sum beløp på transer og sum bevegelse på alle saldi i hovedbok tar ikke høyde for at en del kunder har brukt VBus også på et tidspunkt hvor investeringsavgift ble postert. Dermed inkluderes det som er ført på grunnlagskonti for mva og det ser ut som om hovedboken ikke balanserer..

Svar fra Visma: Vi kommer att gå igenom samtliga fönster under senhösten.

Kommentar: Det hadde vært fint om det hadde skjedd. Det kom nytt sett av vinduer til versjon 14.01, men dette er fremdeles ikke rettet. Jeg kunne skrive meget om standardvinduene i VBus, men det for bli en annen gang. Det beste vi kan si er at det er lett å rette opp det som er feil.

Lagerverdier (Ticket 368873, 28okt2017)

Betarapporten Lagerverdier viser et Antall som tilsvarer På lager nå i lagersaldotabellen (gitt at det i ordrebehandling er krysset av for å Ta vare på ferdigmeldt antall i lagersaldotabellen). Og beløpsfeltet er verdien av På lager nå.

Jeg ønsker meg følgende felt i lagersaldotabellen:
- Verdien av På lager nå
- Verdien av Urealisert lagerøkning

Og på varepartitabellen samt Aggregert vareparti:
- Ferdigmeldt
- På lager nå
- Verdien av På lager nå
- Verdien av Urealisert lagerøkning

Det er viktig at verdiene på lagersaldotabellen ikke beregnes ut fra FIFI-pris (for da får vi vektingsfeil), men som summen av varepartiene. Strengt tatt er det ikke nødvendig med de to kolonnene på lagersaldotabellen hvis de finnes på Aggregert vareparti.

Årsaken til ønsket er å kunne spore hvilke partier det er ferdigmeldt fra - og danne en bro til rapporten Lagerverdi (i Rapportering).

Kommentar: Betarapporten Lagerverdier i rapportering er helt feil, men kommer ikke til å bli rettet. Jeg har skrevet om dette tidligere; Historisk lager. Ønskene er allikevel relevante. På lager nå er det samme som Tellbart (eller Telt antall rett etter lagertelling) og det er ikke uten interesse å vite verdien av det som er telt. De som har sammenliknet Realisert lagerverdi på lagersaldo og summen av varepartiene, har sett at når det finnes varepartier med Urealisert lagerøkning som har annen kostpris enn de hvor fakturamottaket er gjennomført – så er det avvik mellom Lagersaldo og summen av varepartiene for kolonnen Realisert lagerverdi. Og for den som måtte være i tvil: Det er varepartiene som er rett. I alle vinduer som viser Realisert lagerverdi bør denne erstattes med tilsvarende kolonne fra Aggregert vareparti. Samtidig kan Fysisk beholdning med fordel hentes fra samme tabell (som teknisk sett er et view), siden det gir mulighet for å sortere og søke på Fysisk beholdning i Lagersaldo-tabellen.

Fakturamottak fra reservasjonstabellen (Ticket 617238, 28aug2018)

For bedrifter som kjøper varer fra andre land enn de nordiske vil automatisk fakturamottak i VBus via VDC på EHF-format ikke være aktuell løsning før lenge etter at jeg har gått av med pensjon. I disse bedriftene må fakturamottaket gjennomføres på "gamlemåten" i overskuelig fremtid og vel så det. Og jeg gråter når jeg ser hvor tidkrevende dette er for mange av våre kunder.

Det som gjør det spesielt tidkrevende er når det foretas delleveringer. Ofte vil det være slik at det som er levert i samme forsendelse også bllir fakturert på samme faktura. I reservasjonstabellen ser vi ferdigmeldt dato og kl.sl. Dersom det hadde vært mulig å gjennomføre fakturamottak fra reservasjonstabellen vil tiden som brukes til fakturamottaket kunne reduseres dramatisk for de som bruker mye tid i fakturamottaket. Og for de som opplever at restordre blir dellevert sammen med andre ordre vil med en slik mulighet kunne koble reservasjonslinjene til leverandøren (aktør), vise bare de radene som er varemottatt, men ikke fakturamottatt og sortere med bruddsum på ferdigmeldt dato.

Konkret er forslaget:

Det åpnes for å gjøre fakturamottak fra reservasjonstabellen. Det er ikke nødvendig med endringer i datamodellen, siden relevante felt allerede finnes. Den delen av koden som gjelder logistikken er også på plass. Det eneste som mangler er å få generert bilaget.

Kommentar: Ryktene forteller at det jobbes med saken og at dette muligens vil bli implementert i versjon 15.10. Jeg gleder meg til å glede brukere!

Sletting av vinduer fra utforsker logges ikke (Ticket 623904, 3sep2018)

Har satt opp i Endringsloggdefinisjon at sletting av vinduer skal loggføres.

Det virker når jeg sletter vindu fra vindu-tabellen.

Om en bruker ved en inkurie sletter et vindu fra utforsker skjer det ingen logging.

Hva gjør jeg for å loggføre også sletting fra utforsker.

Svar fra Visma: Det ser ut som en bugg så kommer rapportera vidare det. Vad jag kan se finns ingen workaound på detta.

Kommentar: Legg merke til at saken er klassifisert som ønske om forbedring, ikke som feil. Men det står på saken at det er planlagt løst i versjon 16.

MDM aktivert - oppdatering av Aktør tar lang tid (Ticket 1255049, 4jun2019)

Aktørtabellen har omtrent 21.700 aktører hvor noe over 18.100 er kunder.

Det er opprettet felles aktørtabell for 31 selskap slik at det er 30 selskap som bruker aktørtabellen i firma 1. De importerer endringer i kundeopplysninger fra annet system som legger ut en standard VBus importfil på formen:

@Actor (=CustNo, Nm, Shrt, Ad1, Ad2, Ad3, PNo, PArea, Ctry, Phone, Fax, MailAd, CPmtTrm, InvoCust, Cur, Lang, BsNo, Gr2, Gr3, CVatNo, ExVat, DocSMt)
"11001" "Ole M. Almeli AS" "Ole M. Almeli AS" "" "Bølerveien 71" "" "2020" "Skedsmokorset" "47" "63955044" "63953230" "" "01" "0" "47" "47" "942657749" "01" "1" "" "" ""

 Import av 3.842 slike rader (ingen nye kunder, bare endringer av eksisterende) tar 42 minutter. Kunden forteller at det gikk langt raskere tidligere.

 Jeg har derfor opprettet en ny klient for test-formål med identisk innhold i alle tabeller (bortsett fra Bedriftsopplysninger og Bankpartnere) og importert samme fil og det tar 45 sekunder. Når jeg ser på SQL-logg ser jeg ingen forskjell på import til selskap 1 (som "eier" Aktørtabellen som er felles med 30 andre bedrifter) og til testfirma (bortsett altså at det tar mer en 50 ganger lenger tid å importere til firma 1.

Siden kunden ikke bruker VDC har jeg disablet MDM-triggerne på Aktøren i firma 1. Og det gjør susen. Import til firma 1 med disablede MDM-triggere går på 55 sekunder.

Dette leder til to spørsmål:

1. Fraråder dere å gjøre noen av tabellene med MDM-triggere til felles tabell?

2. Er det rimelig at import skal ta 50 ganger mer tid når det tross alt bare er 31 bedrifter som "deler" Aktør-tabellen og MDM ikke er aktivert på noen av bedriftene?

Kommentar: Når det kom til stykket var tidsforbruket knyttet til MDM og ikke felles tabeller.

Svar fra Visma: This improvement will not be implemented because it would require refactoring and have high risk. The case will therefore be closed.

La Jobbplanlegger starte og stanse EDI-klokka (Ticket 1260355, 9jun2019)

Svært mange av de som bruker EDI-klokka har satt opp en tidsstyrt oppgave på en server som starter denne på gitte tidspunkt. Så hender det at EDI-klokka stanser; noen ganger fordi det dukker opp en melding med en [OK]-knapp som ingen klikker på - eller bare at VBus går ned. Og det hender at bruker har behov for å stanse EDI-klokka, men da må man inn på rett server og finne rett instans i Windows etc. EDI-klokka har et ufortjent rufsete rykte fordi det for brukere er så vanskelig å kontrollere den, når den går i bakgrunn på en server.

Jeg ønsker meg en mulighet for å kjøre EDI-klokka fra Jobb-planlegger i VBus. Og å kunne stanse den. Slik at en jobb kan være å starte den hver virkedag kl. 06:00 og stanse den kl. 22:00.Meldinger som kommer opp på skjermen på en vanlig sesjon kan plasseres i tabellen EDI-feilmelding.

Dette vil være en hjelp for alle som bruker EDI-klokka og gi bedre kontroll med den.

Svar fra Visma: Redd for at dette ikke lar seg gjøre av to grunner

Det ene er at vi nok må regne med at EDI klokka, slik den ser ut i dag, ikke vil kunne fungere i all fremtid. Metodene er gamle, og sikkerhetsmessig antar vi at det på sikt ikke vil være ønskelig å vedlikeholde denne funksjonen. - det anses som mer riktig å bruke tid på å tilgjengeliggjøre VBS for de oppgavene som pr i dag gjøres via EDI klokka.

Det andre går på at jobbplanleggeren i dag kjører innen rammen av en sesjon, mens EDI biten vil kreve ganske omfattende endringer i dette. Ut fra signalene vi har pr i dag, ønsker en heller å benytte ressurser på å utvide tilbudet av jobber innenfor eksisterende rammer.

I versjon 15.10 er import av EDI-meldinger med jobbplanleggeren implementert.

Lagre om i jobbplanlegger (Ticket 1260357, 9jun2019)

Vi anbefaler alle som bruke logistikk i VBus å utnytte alle mulighetene, også når det gjelder datobruk. Se gjerne frode.antun.no/VBus/blogg/LevDato. Det innebærer bruk av ‘Reservasjon ved lagring; innenfor leveringstiden’.

Dette må følges opp av daglig (evt. nattlig) ‘Lagre om’ av alle salgsordre som er klar for ferdigmelding. EDI-klokka kan gjøre dette, men vi opplever i blandt at det dukker opp meldinger med [OK]-knapp som brukeren må klikke på for å komme videre. Og hvis EDI-klokka går som en Started task på en server uten bruker til å klikke på [OK]-knappen opplever brukerne bare at EDI-klokka henger.

Jeg ønsker at det åpnes for behandlingsvalget ‘Lagre om’ i Jobbplanleggeren til VBus.

Alle som bruker ‘Reservasjon ved lagring; innenfor leveringstiden’ vil ha nytte av dette.

Noen av disse forslagene er sendt inn da jeg jobbet i Proplan, men meldt inn på nytt da Visma byttet support-system. Det gjelder en del av sakene som er datert 5. og 6. september i 2015. Resten av forslagene er registrert i min tid i Vitari.

Når disse utmerkede, for ikke si glimrende, forslagene ikke er implementert, så er det fordi det ikke er nok kunder som ber om det. Visma ber om at forslag til forbedring følger en mal:

Hvem vil dette bety noe positivt for? -en kunde, mange kunder, spesiell kundetype, segment etc - slik info vil være med på å gi ønsket prioritet
Hva er omfanget av ønsket? -her trenger vi utfyllende info om hva en ønsker å få til av funksjonalitet
Hva er konsekvensen av å ikke etterkomme ønsket? - arbeidskrevende workarounds, funksjonalitet som mange kunder ikke kan ta i bruk etc.

Samtidig vil forslag som ligger «utenfor boksen» ikke komme fra mange kunder. Og det kan være vanskelig å estimere hvor mange kunder som bruker en bestemt funksjonalitet, f.eks. enheter – eller hvor mye tid som går med til å rette feil som kunne ha vært unngått om det var mulig å sperre enkelte koder slik det er mulig å sperre konti.

Hvis du tenker at du ville ha nytte av ett eller flere av forslagene jeg har skrevet om her, så ta kontakt med din forhandler og de dem om å fremme forslaget – gjerne med henvisning til Ticket.

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

frode@antun.no