JTL Software wurde ja nicht geplant sondern ist "historisch gewachsen" - den Frust können wir allemal verstehen, bitte nicht in den falschen Hals bekommen. 👍
In Bearbeitung Rundungsdifferenzen
- Ersteller des Themas Simone_die_Echte
- Erstellungsdatum
Es gab in der Zwischenzeit aber mehrere Versionswechsel. Ist die 5 statt der 4 hinter dem JTL also nur Fassade?
Wirklich? Sollte nicht jeder Stein einmal umgedreht werden, wenn ich eine neue Version entwickle?
Anders gefragt: Wann darf ich als Nutzer denn eine Version erwarten, die wirklich neu ist? Wird das erst JTL 2.0/1 sein?
Von JTL6 kann ich ja offenbar nur einen Aufguss von JTL5 erwarten ...
Anders gefragt: Wann darf ich als Nutzer denn eine Version erwarten, die wirklich neu ist? Wird das erst JTL 2.0/1 sein?
Von JTL6 kann ich ja offenbar nur einen Aufguss von JTL5 erwarten ...
Schau dir dazu die JTL Dev Umgebung an, dann siehste was sich in der DB Struktur tut.
Es muss erst alles vorbereitet werden, Bereich für Bereich, bevor man den großen Cut machen kann.
Solche Leute wie dich sollten mal eine Woche bei JTL mitentwickeln lassen, um zu sehen was hinter der "Fassade" eigentlich alles bedacht werden muss.
Mit anderen Worten also die Bestätigung: Die Versionsnummern hinter JTL darf ich als Nutzer nicht so verstehen, dass sie einen großen Cut markieren? Also kann ich auch von JTL6 keinen Cut erwarten, weil er erst vorbereitet wird?
Es gibt denke ich dafür keine Normen, jeder Softwarehersteller entscheider selbst, was für ihn eine neue Version ist.
Ein Versionssprung heisst nur, dass sich etwas grundlegend geändert hat, was man aber als User nicht gleich erkennt.
Ein Versionssprung heisst nur, dass sich etwas grundlegend geändert hat, was man aber als User nicht gleich erkennt.
Je mehr man Anderes/Neues drumherum baut, um so komlexer wird es dann aber auch, alte Fehler zu beheben. Verbaut man sich so nicht die Chance, ein Problem frühzeitig zu lösen als es nur aufzuschieben und an anderen Stellen fleißig weiter zu programmieren und das Problem somit immer mehr zu "verkomplizieren"??? Dann zu sagen, ja es ist halt nun so schwierig das Ganze wieder gerade zu biegen, kann man machen aber wir als Anwender haben damit seit Jahren mehr oder weniger zu leben und es (wöchentlich) Kunden zu erklären oder mit denen zu diskutieren warum es keine buchhalterisch richtige Rundung auf den Belegen gibt. Ich denke, da haben wir eigentlich Besseres zu tun...
Zuletzt bearbeitet:
Also wenn ich hier die Meinungen so höre, wäre es doch für die meisten okay, wenn es auf den Angeboten/Aufträgen/Rechnungen/etc. buchhalterisch richtig rechnet, intern wird ja mit ausreichend Nachkommastellen abgespeichert.
Also wäre es doch möglich, ggf. auch einstellbar für die die es wollen, die Anzeige anzupassen wie bereits hier beschrieben:
https://forum.jtl-software.de/threads/rundungsdifferenzen.100765/post-986719
Ich weiß da hängt noch viel mehr dran, aber so müsste man nichts intern umbauen und hätte es angepasst für alle die es so wollen. Und dann könnte man immer noch Erfahrungsberichte sammeln.
Zur Rappenrundung gibt es schließlich auch eine Einstellung (obwohl die mir noch keiner erklären konnte ob das in diesem Fall hilft).
Also wäre es doch möglich, ggf. auch einstellbar für die die es wollen, die Anzeige anzupassen wie bereits hier beschrieben:
https://forum.jtl-software.de/threads/rundungsdifferenzen.100765/post-986719
Ich weiß da hängt noch viel mehr dran, aber so müsste man nichts intern umbauen und hätte es angepasst für alle die es so wollen. Und dann könnte man immer noch Erfahrungsberichte sammeln.
Zur Rappenrundung gibt es schließlich auch eine Einstellung (obwohl die mir noch keiner erklären konnte ob das in diesem Fall hilft).
Eine Anpassung rein optisch hilft aber auch nicht immer, wir arbeiten voll automatisiert und digital, sogar mit Steuerberater, da würden dann spätestens hier die Differenzen aufpoppen.
Rundungsprobleme kommen hauptsächlich durch Rabatte / Prozente, seitdem diese bei uns weg sind, haben wir auch kein Problem mehr.
Rundungsprobleme kommen hauptsächlich durch Rabatte / Prozente, seitdem diese bei uns weg sind, haben wir auch kein Problem mehr.
Wenn man so will, sind Staffelpreise ja auch Rabatte... Wir haben die Rundungsdifferenzen aber auch bei Aufträgen, wo keine Rabatte gegeben werden, höchstens via Sonderpreisen. Soll man somit auf mehrere andere Funktionen verzichten damit einem die eine keine/weniger "Probleme" bereitet? 
genau so ist es.
Die Problematik entsteht nicht dadurch ob und wieviele Nachkommastellen eine Zahl in der Datenbank hat, sondern darin wie die Zahl in der Datenbank gespeichert wird (also der Datentyp).
Wenn man mit Fließkommazahlen rechnet, stößt man immer auf das Problem, dass ein Computer manche Kommazahlen einfach nicht exakt darstellen kann.
Wenn die Datenbank (also das Fundament der Wawi) Geldbeträge als Fließkommazahlen speichert, dann ist das eben nicht so einfach zu ändern. Es wäre ja auch kompliziert am Fundament an einem fertigen und bewohnten Mehrfamilienhaus was zu ändern.
Ich möchte damit keineswegs sagen, das jetzt alles gut ist und sich niemand mehr an den Differenzen stören soll, sondern ich wollte vielmehr vielleicht ein bisschen Aufzeigen, dass hier eine gewaltige Umstrukturierung im Raum steht und nicht einfach "nur richtiges Runden".
Wäre das die Ursache, dann wäre es ein Problem, ja, dem ist aber hier nicht so.
Sowohl in tAuftragsposition, tRechnungsposition sowie im tArtikel u.v.m. ist der Datentype bereits ein decimal(25, 13), speichert also bisher bereits bis 13 Nachkommastellen, das ist schon genug Fließkomma.
In meinem Beispiel, ein Artikel mit 315€ brutto steht in der Datenbank als Netto 264,7058823529410, das sind bei weitem genug Nachkommastellen.
Damals hatte jemand 14 Stück gekauft und im Angebot/Auftrag stand korrekt 14 * 315 = 4.410 brutto und 14 * 264,70588... = 3705,88235... ~ 3705,88€.
Das wird bereits auf ausreichend viele Nachkommastellen berechnet und stimmt so, die notwendige Grundlage ist also längst da.
Es war erst die Dokumentvorlage, welche den Artikelpreis zwar korrekt auf 2 Nachkommastellen gerundet darstellt, soll es ja auch, aber dann mit 264,71 weiter rechnet und 14 * 264,71 = 3.705,88 anzeigt. Jemand der so eine Rechnung sieht und in den Taschenrechner tippt, denkt dann "hey, müsste doch 3705,94 sein".
Es steht aber richtig in der Datenbank, auch in den Staffelpreisen und Rabatten und selbst wenn man das mit Dritttools an Steuerberater übermittelt oder irgendeine API oder was, da stehen auch die Nachkommastellen, da gibt es kein Problem.
Das meinte deliman mit "versuch das mal dem Kunden zu erklären, oder gar (halb)öffentlichen Stellen". Würde es richtig angezeigt, wären die schon ruhig.
@ergowebshop
was ich sagen wollte, ist dass niemand von uns den Code von JTL einsehern kann bzw. genau weiß, wie und mit welchen Datentypen die Wawi was berechnet und ich wollte aufzeigen, dass evtl. auch nicht alles zu Ende gedacht ist, wenn man sagt "au mann, die Jungs von JTL müssten doch nur dies und das machen und schon wäre es gelöst".
Die Tatsache, dass z.b. die Artikelpreise in meiner 1.5 DB noch als decimal(28,14) und bei dir wie du sagst als decimal(25,13) stehen, zeigt ja, dass diesbezüglich seitens JTL was gedreht wird.
Das macht doch Hoffnung 😅
Das Fließkomma-Thema und/oder die Darstellung in verschiedenen Zahlensystemen (binär vs. dezimal) muss man in einem Anwender Forum ja auch nicht weiter vertiefen.
was ich sagen wollte, ist dass niemand von uns den Code von JTL einsehern kann bzw. genau weiß, wie und mit welchen Datentypen die Wawi was berechnet und ich wollte aufzeigen, dass evtl. auch nicht alles zu Ende gedacht ist, wenn man sagt "au mann, die Jungs von JTL müssten doch nur dies und das machen und schon wäre es gelöst".
Die Tatsache, dass z.b. die Artikelpreise in meiner 1.5 DB noch als decimal(28,14) und bei dir wie du sagst als decimal(25,13) stehen, zeigt ja, dass diesbezüglich seitens JTL was gedreht wird.
Das macht doch Hoffnung 😅
Das Fließkomma-Thema und/oder die Darstellung in verschiedenen Zahlensystemen (binär vs. dezimal) muss man in einem Anwender Forum ja auch nicht weiter vertiefen.
decima() ist ja eben kein Fließkomma, insofern ist das ja schon mal gut
"intelligente Druckvorlagen (über 13 Jahre KnowHow in Druckvorlagen-Entwicklung)"
- wahrscheinlich schon
- wahrscheinlich schon
Die 1.7.X.X ist eine Neuentwicklung, keine Weiterentwicklung von JTL, da intern auf neue Software-Architektur umgestellt wird!
Neue/alte Bugs sind die Regel ... sowie die nicht fertige, unvollständige, fehlerhafte Ausgabe 2.0 ... die mehr Ärger und Zeit frisst, als dass diese gegenüber 1.0 etwas bringt.
(Unsere Meinung und Empfehlung, basierend auf viele viele viele Kundenstimmen.)
https://www.wawi-dl.de/JTL-Wawi-Druckvorlagen-SET-Design-02