Flere end 2 decimaler til enhedspriser

Question

Vi har i dag oplevet, at fakturalinjer, som sendes ind til economic med enhedspriser på 0,001 Euro uden advarsel afrundes til 0,00 - med det resultat, at der oprettes en nul-faktura. For at fakturere nogle af vores kunder, har vi behov for at kunne benytte flere end 2 decimaler (i dette tilfælde 3 decimaler).

Vi sender alle fakturalinjer ind i e-conomic via jeres API - og kun ved et tilfælde opdagede vi, at e-conomic afrunder 0,001 til 0,00 - og dermed kunne vi have gået glip af en faktura på flere tusinde Euro i dag. Vi kan i øvrigt manuelt indtaste en enhedspris på 0,001 ved redigering af en fakturalinje, og jeres løsning beregner herefter linje-totalen, men når der trykkes "gem", så gemmer den det indtastede med enhedprisen 0,00 og dermed fakturalinje-total på 0,00.

Vi får at vide, at man har besluttet ikke at imødekommende lignende forespørgsler fra andre af jeres kunder, og vi er blevet anbefalet, at finde et andet faktureringssystem end e-conomic, idet I ikke kan og vil imødekomme vores forespørgsel.

Inden vi skifter leverandør, vil jeg meget gerne give jer en chance for at genoverveje at imødekomme vores (og andre kunders) behov for at understøtte mere end 2 decimaler. Funktionaliteten kan eventuelt oprettes som en "setting", således at de kunder, som ikke har dette behov på ingen møde berøres af den nye funktionalitet. I vil også software udviklingsmæssigt kunne udvikle funktionaliteten, uden at det påvirker tidligere indtastninger og tidligere årsrapporter, etc.

Jeg har undersøgt flere andre platforme, som understøtter op mod 10 decimaler (Eksempelvis Uniconta), og jeg finder det bekymrende og ærgerligt, at I ikke tager vores og andre kunders behov på dette område alvorligt.

Jeg har brug for, at I revurderer jeres holdning til emnet, og hvis I fastholder ikke at ville udvikle muligheden, ser jeg frem til at høre jeres saglige argumentation for totalt at afvise at efterkomme behovet.

Vi ser frem til at høre fra jer.

Answer 1

Hej auwau,

Tak for at du har valgt at dele din oplevelse med os. Man kan efterhånden kategorisere dette forslag som en klassisk problemstilling, for de brugere som opererer med flere decimaler end to.

Begrundelsen for hvorfor vi undlader at tilføje flere decimaler er af mange. Hver gang vi bringer emnet op, så ender vi med flere spørgsmål end svar.

Hvis jeg skal give dig et par saglige problemstillinger der vil være i den anledning:

1. Der vil være brugere, som vil opleve at den historiske data kan blive påvirket uhensigtsmæssigt ved sådan en radikal ændring. Selv hvis man antager at den historiske data er som den er, og ændringen skal ske med fremadrettet virkning. Hvordan skal vi håndtere posteringer som er oprettet som kladder?

Hvis vi vælger at tilføje flere decimaler på, så vil man blive påvirket af det direkte, eller indirekte. Ex. man har Lager tilføjet sin aftale - og her vil den gennemsnitlig kostpris blive beregnet af e-conomic. Hvordan kan vi sikre at vores brugere ønsker sådan en tilføjelse?

2. Hvor mange decimaler skal vi have tilføjet? Nu nævner du tre. Men samme problemstilling kan også fremgå for de som har brug for flere end tre decimaler.

Og hvor skal der tilføjes flere decimaler? Er ønsket at kunne tilføje flere decimaler alle steder i programmet. Fx. antal, stk. pris, total-beløb osv.?

Der er mange andre problemstilinger end blot de to som er nævnt her. Emnet har været debateret mange gange hos os, og disse kan findes på vores Forum.

Uniconta er grundlagt med 10 decimaler. De problemstillinger jeg nævner her er blevet taget hånd om forinden man begyndte at udvikle. Begynde at implimentere sådanne radikale ændringer "midtvejs" skaber flere udfordringer end der bliver løst.

Jeg håber at mit svar giver mening, omend at din udfordring ikke får en løsning.