Flere decimaler i varens pris

Question

Economics burde åbne op for muligheden for, at den enkelte bruger på sin konto, kan indstille det antal decimaler man ønsker i sine salgspriser!  

Mange brugere i dette forum efterspørger muligheden for at kunne oprette priser med flere decimaler end 2. Når salgssummen på den enkelte varelinje, så udregnes er jeg sikker på alle kan leve med en afrunding til 2 decimaler, ligesom 2 decimaler er tilstrækkeligt på alle regnskabsmæssige totalværdier.  

Eksempel på flere decimaler i salgsprisen: Solgt 20.031 stk. af 0,1456 kr. (4 decimaler) = 2.916,5136 kr. afrundet til 2.916,51 kr. (2 decimaler). Dette ville være OK.

Som det aktuelt er i economics ville ovenstående se således ud: 20.031 stk. af 0,15 kr. (2 decimaler) = 3.004,65 (2 decimaler). Altså en overfakturering af kunden!

PROBLEMET FOR E-CONOMICS ER ALTSÅ LØST, BLOT VED AT TILLADE FLERE DECIMALER I  SALGPRISEN, F.EKS. 5 DECIMALER. Hvorfor obstruere economics for denne enkelte mulighed og løsning?

Comments

Jeg kunne virkelig også godt bruge flere decimaler. Når man så bogfører i EUR, så bliver afrundingerne endnu større. Jeg kan f.eks. ikke ramme de 37.165 EUR, når jeg skal fakturere nedenstående.

VOL	VAL
2	200	100
21	1.370	65,2381
23	1.510	65,65217
453	29.605	65,3532
56	4.480	80
555	37.165

Answer 1

Hej Dan

Tak for dit forslag.

Dette er noget vi har haft oppe rigtig mange gange med vores udviklere og jeg må desværre på nuværende tidspunkt afvise, selv om jeg godt kan se ideen.

Jeg henviser blandt andet til følgende indlæg

https://forum.e-conomic.dk/26922/flere-decimaler-i-priser

Det vi anbefaler, hvis man har flere decimaler i sine salgspriser er evt. at oprette et varenummer der består af f.eks. 100 stk. så i dit eksempel, hvis 1 vare koster 0,1456 kr, så koster 100 varer 14,56. 

På den måde vil kunden ikke blive overfaktureret. Hvis kunden så evt. køber 20.031 stk, så skriver du i antal 200,31 x 14,56 = 2.916,51, så bliver kunden ikke overfaktureret.

Jeg ved godt at dette ikke er en optimal løsning, men håber du kan bruge den alligevel.

Jeg ønsker dig en rigtig dejlig weekend

 

Comments

Kære economics,

I burde komme med nogle fornuftige argumenter for ikke at implementere det som efter jeres eget udsagn har været oppe rigtig mange gang. Hvis det rent faktisk forholder sig sådan forstår jeg ikke I ikke efterkommer jeres kunders ønsker og efterspørgsel. Jeres hidtidige argumenter belyser IKKE, hvorfor I ikke vil gøre det muligt at påføre varens pris flere decimaler. I har på et tidspunkt henvist til "ikke at ville forvirre kunderne". Jeres forslag om at lave en pris per 100 stk er da netop at forvirre kunderne. Som jeg desuden har anført smadrer det jo salgs-statistikkerne med solgte antal, når nogle kunder bliver beregnet per 100 stk. - for det giver ikke mening at gøre det ved alle kunder - fordi de netop bliver forvirret over en prisopstilling per 100 stk.

JEG KAN SIMPELTHEN IKKE FORSTÅ, HVORFOR I IKKE BLOT GØRE DET MULIGT MED FLERE DECIMALER I SALGSPRISEN (og afrunder i total salgssummen på varelinjen til 2 decimaler = problem løst)!

Hilsen

Endnu en af de mange utilfredse kunder.....

---

Hej igen Dan

Tak for din kommentar. Som sagt flere gange, er dette noget vi har haft oppe med vores udviklere og svaret fra dem har været, at problemet er alt det som allerede ligger i systemet og det som er igangværende også vil blive rettet.

Jeg kan udemærket godt se udfordringen med salgsstatistikken blandt andet.

Jeg vil godt prøve at tage det op igen med vores udviklere for at få en nærmere forklaring igen. Evt. om man ikke kunne sætte en afgrænsningsdato, at det skulle gælde fra en bestemt dag.

Du hører fra mig, når jeg ved lidt mere

Ellers må du have en rigtig god dag

Answer 2

Hej Dan

Vi har nu haft det oppe på flere plan hos blandt andet udviklere og andre eksperter igen.

Udover de argumenter vi allerede har nævnt, kan jeg komme med et yderligere herunder

1) Vi har 3 forskellige varer med salgspriser på 4 decimaler

2) Disse bliver bogført på salgskontoen og kundekontoen med 4 decimaler.

3) Faktura vil komme til at lyde på totalbeløb med 2 decimaler og det er det som kunden indbetaler og det som bliver bogført på kundens konto.

4) Differencen vil være 0,0009. Godt nok små penge, men det er noget som skal bogføres som en øre difference rent regnskabsmæssigt, hver eneste gang man bogfører en kundeindbetaling.

Se et eksempel jeg har lavet herunder:

Gode ideer til, hvordan man evt. ellers kan løse dette, modtages med kyshånd

Rigtig god weekend

Comments

Hej e-conomics m.m.

Jeg har samme problem og mangler VIRKELIG denne funktion. Jeg forstår ikke, at så stort et regnskabssystem ikke understøtter flere decimaler.

Jeg håber, at det er noget i får løst i nær fremtid.

Vh Carsten

---

Hej Susan

Jeg har da et forslag til løsning - som jeg håber, at I modtager med kyshånd. Problemet som I beskriver løses ved at man afrunder både "salg i alt" og "bogført salgskonto" til to decimaler. Dermed kommer disse værdier/beløb til at stemme overens med den tilhørende faktura, og den regnskabsmæssige difference er pist borte. Dette har jeg drøftet med vores revisor hos Deloitte, som er helt enig i, at det er en farbar løsning.

Jeg tager ikke betaling for mit indspark - men håber da virkeligt meget, at I snart får skubbet til den medarbejder, som ikke har lyst til at komme alle os i møde, som har brug for flere decimaler på enhedspriser.

Bedste hilsner

Thomas Bak