Oslo, 25. april 2021

Endret palmesøndag 2023

 

Kopiering av ordre

Det hender at man har behov for å lage kopi av en ordre. Noen ganger er det for å kreditere en hel ordre og lage en ny for fakturering. Noen ganger er det fordi det skal lages (nesten) like tilbud til ulike kunder, f.eks. fordi en reder har bedt om tilbud fra mange verft som alle i sin tur ber om tilbud på det samme arbeidet.

Fakturareferanse

I VBus er det to ulike funksjoner som kan brukes – som passer i litt forskjellige sammenhenger, og begge har sine styrker og svakheter. Den ene er bruk av Fakturareferanse. Det passer når man skal kreditere noe som tidligere er fakturert. Det forutsettes at Fakt.ref.behandl. er fylt ut enten på ordren eller i Bedriftsopplysninger. I Fakturareferanse legges det inn et fakturanummer og VBus henter alle rader fra Produkttransaksjon som har samme Fakturanr. Dersom Fakt.ref.behandl. har verdien 2 eller 4 kommer linjene to ganger, først med overskriften «Var» og med negativt antall og deretter «Skal være». Disse tekstene kan endres i Tekst-tabellen med TekstType=56, Tekstnr=7 og 8. Dersom Fakt.ref.behandl. har verdien 3 eller 4 vil alle ordrelinjene Unntas lagerhåndtering. Dette passer når krediteringen er et resultat av reklamasjon eller feil pris. Men det bør ikke brukes om det er implementert Lagerkonsistenskontroll på posteringer, for ordrelinjene får samme Avg. og bokf.gr. som den opprinnelige, ikke Andre avg. og bokf.gr.  fra tabellen Avg. og bokf.gr.. Dersom Avg. og bokf.gr. ikke endres vil bokføringen være som vareretur, til tross for at varene ikke kommer inn på lager – så Avg. og bokf.gr. må korrigeres manuelt for at bokføringen skal bli rett. Når Fakt.ref.behandl. har verdien 1 eller 2 vil lagerhåndteringen være som de opprinnelig var. Når Fakt.ref.behandl. verdien 1 eller 3 vil VBus snu fortegnet på Antall hvis det i Ordrepref. er krysset av for Kreditnota.

Bruk av Fakturareferanse gir ingen hjelp mer å opprette selve ordren. Men det er ingen ting i veien for å bruke den opprinnelige ordren; det kan krysses av for Kredit­nota i Ordrepref. om ordre­linjer skal krediteres og man ikke vil bruker «Var» og «Skal være». Det er selv­følgelig ikke noe i veien for å slette ordre­linjer som ikke skal krediteres. En fordel med Fakturareferanse er at i reskontroen blir kredit­notaen auto­matisk matchet mot fakturaen – gitt at denne fremdeles er åpen post. Og at ved kreditering av lager­håndterte ordre­linjer, så blir disse ført tilbake til de vare­partier som de opp­rinnelig ble plukket fra. Dermed opprett­holdes sporing tilbake til det opp­rinnelige inn­kjøpet (eller produksjonen) når disse varene blir solgt på nytt (eller brukt i produksjon).

Dersom Valutakursjustering er satt (i Ordrepref.) så kan dette skape et problem i matchingen; altså om man først har fakturert et beløp med én valuta­kurs og krediterer med en annen. For i VBus skjer matchingen i NOK, ikke i valuta. Dersom du har fakturert 100 EUR med valuta­kurs 10 (altså 1.000 NOK) og kreditert 100 EUR med valuta­kurs 9,5 (altså 950 NOK), vil det være en rest på 50 NOK på fakturaen – som VBus i sin ufattelige visdom regner tilbake med valuta­kurs 10 til 5 EUR. Det konto­utdraget bør ikke sendes til kunden. Det ble derfor gjort en endring i versjon 5.32.2 hvor det i Kundepref. kom en ny mulighet: Bruk opprinnelig valutakurs på kreditnotaer. Hjelpe­teksten gir ingen forklaring. Det finnes et tilsvarende alternativ på Ordrepref.; heller ikke her med noen forklaring i hjelpe­teksten. Det som skjer når du legger inn Kundenr på en kredit­ordre, er at VBus fjerner Valuta­kurs­justering (og for så vidt også Bruk opprinnelig valuta­kurs på kredit­notaer) i Ordrepref. hvis begge er satt i Kundepref. – og effekten er altså at man får opprinnelig valuta­kurs, siden det er standard når Valuta­kurs­justering ikke er valgt. Det nytter ikke å sette Bruk opprinnelig valuta­kurs på kredit­notaer i Ordrepref. hvis Valuta­kurs­justering er satt.

Når Fakturareferanse brukes for å kreditere noe som tidligere er fakturert, så er det praktisk at ordre­linjene er prikk lik det som opprinnelig ble fakturert. Siden én og samme ordre­linje kan være plukket fra ulike vare­partier, vil ordre­linjene som dannes ved bruk av Fakturareferanse være splittet på parti, noe som kan være forvirrende. Enten man vil bruke Fakturareferanse til kreditering eller annet, så er det noen forhold man skal være oppmerksom på. De fleste har i Ordrebehandling (i Bedrifts­opplysninger) krysset av for Redupliser fra ordre­hode til ordre­linje ved lagring. Og det er altså slik at en rekke felt finnes både i ordre­hode og på ordre­linje. Når du legger inn en ny ordre­linje vil disse feltene dupliseres (kopieres om du vil) til linjen slik at det er samme verdi på linje som i ordre­hodet. Disse vises da med blått på linjen. Dersom man endrer på ordre­linjen, blir verdien sort. Altså: Om du har en ordre med Prosjektnr = 123 (i ordre­hodet) så får alle ordre­linjene samme Prosjektnr etter hvert som de registreres. La oss tenke oss at du endrer Prosjektnr til 125 på tredje ordre­linje (og 125 vises nå med sort). Så endrer du Prosjektnr til 130 i ordre­hodet. Når du lagrer endres Prosjektnr til 130 på alle ordre­linjene unntatt den tredje. Her beholdes Prosjektnr 125 fordi det er over­styrt på ordre­linjen. På ordre­linjen kan du hente frem Dupl. felter 1 og Dupl. felter 2 som viser hvilke felt som blir duplisert på hver ordre­linje. Ikke alle er duplisert fra hode; Påløpt er normalt duplisert fra Antall, men det kan også være omvendt. På ordre­linjer som opprettes med bruk av Fakturareferanse slås dupliseringen av for felt som hadde verdi på fakturaen, men ikke for de som ikke hadde verdi. Altså om du har fakturert to linjer hvor det er Prosjektnr på den ene linjen og ikke den andre, så vil du på ordre­linjene som opprettes med Fakturareferanse, få Prosjektnr med på den ene og her vil dupliseringen være slått av. På den andre vil duplisering være på. Det betyr at om du har satt et Prosjektnr i ordre­hodet så vil de ordre­linjene som mangler Prosjektnr, «arve» Prosjektnr fra ordre­hode, mens de som har Prosjektnr beholder sitt. Dette gjelder alle felt som kan dupliseres. I praksis betyr det at for alle felt som alltid er med på ordre­linjene, blir duplisering slått av på ordre­linjer som opprettes med Fakturareferanse. Det betyr at om du vil endre noen av disse, må det gjøres på ordre­linjene. Og om du vil ha de nye linjene prikk lik sin opprinnelse, må du være forsiktig med hva du har i ordre­hodet. Dette er grunnen til at jeg trives best med å bruke den opprinnelige ordren til krediteringen.

Merk at man kan bruke Fakturareferanse flere ganger om man vil hente frem ordre­linjer fra flere fakturaer. Man kan sågar hente ordre­linjer fra det som er fakturert andre kunder. Da vil Kundenr på ordre­linjene avvike fra ordre­hodet. Og om du ikke gjør noe med dette, vil statistikken (Produkttransaksjon) «arve» Kundenr fra ordre­linjene, mens regnskapet får Kundenr fra ordre­hodet.

Du kan som nevnt slette ordre­linjene som kommer med bruk av Fakturareferanse. Disse har for øvrig Opprinnelse = 10 [Kredit­nota]. Litt misvisende, spør du meg – men det er nok først og fremst til kreditering dette blir brukt. Det er selv­følgelig mulig å legge til nye ordre­linjer. Da vil man se at VBus bare setter Pris på ordre­linjer med Produktnr som ble fakturert på fakturaen som Fakturareferanse viser til. For når det finnes en Fakturareferanse i ordre­hodet, så gjør VBus ikke oppslag i Pris/rabatt-matrisen, men i Produkttransaksjon med dette Fakturanr. Det har forvirret flere enn meg akkurat det.

En svakhet med bruk av Fakturareferanse er at faktura­linjer uten Antall ikke blir kopiert inn. Dette er fordi kilden er statistikken og her er hverken rene tekst­linjer eller linjer som er tatt med på faktura med utskriftsalternativet Ta med ubehandlede ordre­linjer.

Det hender at noen bruker behandlingsmåten Unnta fra statistikk­føring; Inntekter og/eller Kostnader ved salg. Dette er gjerne i kombinasjon med strukturer som er satt opp med Akkumuler opp i struktur­hodet; Inntekter og/eller Kostnader ved salg, evt. Fordel beløp ned på struktur­linjene. Hensikten med å unnta inntekter eller kostnader ved salg fra statistikk­føring er å unngå å få inntekten eller solgte varers kost to ganger. Men hvis du har Akkumuler opp i struktur­hodet; Inntekter eller Fordel beløp ned på struktur­linjene i kombinasjon med i struktur­hodet Unnta fra statistikk­føring; Inntekter, men på fakturaen vise Pris og Beløp fra struktur­hodet og ikke struktur­linjene – så vil du mangle Pris og Beløp på struktur­hodet på linjene som opprettes med Fakturareferanse, så forhånds­visning kan være smart. I det hele tatt skal du være forsiktig med å bruke Fakturareferanse for å kopiere inn strukturer. Når man legger inn Antall på et produkt hvor strukturen Ekspanderes ved salg, bruker VBus kolonnene Strukturnivå, Antall pr. str., Strukturhode linjenr. og Ord.linjestatus for å holde orden på strukturen. Ord.linjestatus blir merket med at Strukturen er ekspandert. Antall pr. str. bruker VBus hvis Antall i strukturhodet endres, slik at Antall på struktur­linjene endres forholds­messig med mindre det i behandlingsmåte er krysset av for Fast antall (uavhengig av antallet i struktur­hodet). Strukturnivå settes til 1 på struktur­linjene, med mindre én (eller flere) av struktur­linjene er en Ekspandert substruktur hvor Strukturnivå settes til 2, 3, … alt etter hvor mange ganger struktur­linjer er ekspandert videre. Problemet med strukturer og Fakturareferanse er at Strukturhode linjenr. viser til struktur­hodet på den opprinnelige ordren og ikke på den ordren Fakturareferanse brukt. Ord.linjestatus blir ikke merket med at Strukturen er ekspandert. Og Antall pr. str. kopieres ikke med. Dette gir samlet sett en del utfordringer. Har du fakturert 2 i struktur­hodet, og skal kreditere 1 så vil det ikke gjøre inntrykk på struktur­linjene at du endrer Antall i struktur­hode fra -2 til -1. Du må endre antall på struktur­linjene manuelt. Verre er det om du har en struktur med Akkumuler opp i struktur­hodet; Inntekter. Hvis den opprinnelige ordren hadde struktur­hodet på Linjenr 1 og du på en ny ordre legger inn noe Linjenr 1 og deretter bruker Fakturareferanse så vil struktur­hodet havne på Linjenr 2, men alle struktur­linjene vil ha 1 i Strukturhode linjenr.. Når disse strukturlinjene har Akkumuler opp i struktur­hodet; Inntekter så blir inntektene akkumulert opp i feil linjenr. Feilen med Strukturhode linjenr. er rettet i versjon 17, selv om det ikke står noe om dette i releasenotes. Men Antall pr. str. glimrer fredeles med sitt fravær, så om du skal endre antall, må du gjøre det både i strukturhodet og på linjene.

Generer kopi av ordre

Den andre metoden er menyvalget Generer kopi av ordre. Som det fremgår av hjelpe­teksten er dette alternativet tiltenkt salgs­ordre, utleie, utlån, tap og vare­forbruk – altså ordre som tar varer ut fra lager. Fordelen her er at man får kopiert ordren i tillegg til ordre­linjene – og man slipper splitt av ordre­linjer som er plukket fra ulike partier. I tillegg dukker det opp en dialog­boks med alternativer:

VBus foreslår dagens dato som Ordredato. De fleste alternativene er selv­forklarende, men ikke Snu fortegn. Hvis du kopierer en ordre som ikke er fakturert, vil alternativet Snu fortegn være grået ut. Og om du har fakturert bare deler av en ordre og genererer en kopi med Snu fortegn, så vil Antall på linjene være det som er ferdig­meldt (men ikke nødvendigvis fakturert!) selv om alle ordre­linjene faktisk blir kopiert. Når du velger Snu fortegn, vil alternativene Kopier ansv. enh. fra kunder og Priser fra pris og rabatt­matrise være grået ut. Litt over­raskende får den nye ordren Ordretype = 2 [Direkte­ordre] – og som forventet; Kreditnota blir satt i Ordrepref.. Ordrestatus blir merket med at Kort­betalings­ordre sperret for kredit­nota da dette alt er laget. Ikke la deg forvirre av det med Kort­betalings­ordre, men om du forsøker å generere en ny kopi av ordren med Snu fortegn, får du meldingen:

som vel må være greit nok (dog litt forvirrende med Kort­betalings­ordre). Visma forteller at årsaken til at Ordretype settes til 2 [Direkte­ordre] er at man (les: Visma) tenker at det å Snu fortegn er noe som gjøres når noe skal krediteres, så da bør man ikke plage brukerne med å ferdig­melde (altså gjennom­føre vare­mottak) i tillegg til å måtte kreditere. Herren har talt! Hvis du synes det er rart, så er det deg det er noe galt med.

Ulempen med Generer kopi av ordre med Snu fortegn er at varer som kommer inn på lager ikke kommer inn på samme vare­parti som de gikk ut fra, slik Fakturareferanse med Kredit­nota sørger for. Og hvis hensikten er å kreditere noe som tidligere er fakturert, så husk at du kan endre mye på en ordre etter fakturering, så denne metoden gir liten sikkerhet for at du vil kreditere det som er fakturert. Da er Fakturareferanse bedre.

Hjelpeteksten til Generer kopi av ordre er ikke helt spot on. Les den som en intensjon. Og det er mye bra her. Men det er ikke alle felt på ordre og ordre­linje som blir kopiert. Tellere og dokument­nummer som Bekr.teller, Ordrebekr.nr, Plukkl.teller, Plukklistenr, Forsendelsenr, etc. kopieres ikke, bortsett fra Tilbudsnr som blir kopiert. Leveringsmåte og Kolli blir ikke kopiert, men Leveringsbet. blir kopiert. Leveringsdatoer, Ordrenr hos k/l, Rekvisisjonsnr, Ordreg.lagsnr, Ansvarlig, Betalingsbet., Betalingsmåte, Per.nøkkel, Memofilnavn, Web-side og Visma ID blir ikke kopiert, men noen av disse kolonnene får verdi fra kunde i stedet. På ordre­linjene blir leverings­datoene ikke kopiert, men beregnet på nytt slik VBus pleier å gjøre det. Ordre­linjer som er Annullert blir kopiert uten å bli Annullert. Bildefilnavn, Web-side, Scan-dok.nr, Visma ID og Ekstern ID blir ikke kopiert. Litt irriterende er at på struktur­linjer blir ikke Antall pr. str. kopiert, men det betyr normalt ikke stort, for VBus klarer allikevel å korrigere Antall på struktur­linjene om Antall i struktur­hodet endres. Bortsett fra om du setter Antall til null. Da er løpet kjørt. For da settes Antall til null på alle struktur­linjene også. Om Antall deretter endres på struktur­hodet har VBus ingen mulighet for å beregne rett Antall på struktur­linjene. Det var derfor Antall pr. str. ble tatt inn i data­modellen, men Generer kopi av ordre plukker altså ikke med seg denne. Litt verre er det at Kostpris ikke kopieres på ordre­linjer som Unntas lager­håndtering. På lager­håndterte ordre­linjer som går ut av lager, må nødvendig­vis Kostpris hentes fra vare­partiet som det plukkes fra. Men på ordre­linjer som Unntas lager­håndtering kunne man forvente at kopi faktisk var kopi. Men slik er ikke VBus. Kostpris blir hentet fra Pris/rabatt-matrisen. Når jeg spør VBus om dette er svaret (sitat):

Basically, it has been implemented to work as with warehousing, that is by getting cost price in the following order, based on information on the order line:

1.     Shipment (if available)

2.     Warehouse average cost price (if available)

3.     Price and discount matrix

As this has never worked any other way and it would require new code, it will have to be registered/escalated as a wish for improvement.

Siden min kvote for å registrere ønsker om endringer og forbedringer er over­skredet med god margin, overlater jeg til andre å fortelle Visma at dette med fordel bør endres.

På samme måte som ved bruk av Fakturareferanse slår VBus av duplisering på ordre­linjer, men i større omfang enn ved bruk av Fakturareferanse. Så selv om det du endrer en ansvarsenhet i ordre­hodet på den kopierte ordren, så gjør det ikke inntrykk på linjene. Bruk Dupl. felter 1 og Dupl. felter 2 for å se hvilke felt som ikke blir duplisert.

Ordrelinjer som oppstår ved Generer kopi av ordre får Opprinnelse = 7 [Kopi av ordre], men det finnes ingen henvisning til ordren som ble kopiert. En løsning på det kan være å kopiere Ordrenr til Hovedordrenr før kopieringen. Da vil begge ordrene ha samme Hovedordrenr slik at det er lett å sammen­likne kopien med kilden (eller originalen om du vil; den som ble kopiert).

 

 

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

e: frode.antun@amesto.no

a: Smeltedigelen 1, 0195 Oslo

w: amestosolutions.no