Währungsbeträge einer sqlite3-Datenbank editieren

[sierdolg]

Hallo zusammen,

heute eine Frage an alle, die schon Erfahrungen mit sqlite und dem Verarbeiten kaufmännischer Daten in Lazarus gesammelt haben.

Bei uns gibt es eine sqlite3-Datenbank, die Rechnungsdaten, Positionen und Artikel speichern soll. Da sich beispielsweise ein Brutto-Rechnungsbetrag aus der Summe zahlreicher Produkte (aus Einzelpreisen und Stückzahl) herleitet und dabei die Mehrwertsteuer auf der Ebene der Einzelpreise, der Gesamtpreise oder auch erst der Gesamtsumme eingerechnet werden kann, ergibt sich grundsätzlich ein gewisser Spielraum für Rundungsfehler. Um diese möglichst klein zu halten, und weil SQLite3 keinen fixen Datentyp erzwingt, wie er anderswo als "Currency" bereitsteht, bietet sich aus meiner Sicht offenbar an, alle Beträge grundsätzlich in einer feiner granulierten Ganzzahldarstellung zu speichern, also z.B. in "Millicent", und erst auf diesem Level kaufmännisch zu runden.

Andererseits will man auf dem Formular Eurobeträge in der gewohnten Weise darstellen (also mit zwei Nachkommastellen, die dann den in der Datenbank gespeicherten tatsächlichen Bruch wiederum auf die "normalen" Cent kaufmännisch gerundet anzeigen). Nur beim Editieren sollte es möglich sein, die zusätzlichen Stellen zu sehen und ändern zu können.

Das DataControl TDBEdit scheint derlei nicht vorzusehen, und während es für andere Datentypen eigene Data Controls gibt (TDBImage und TDBCalendar etwa), existiert das denkbare "TDBCurrency" nicht. Hat jemand eine Idee, wie man vorgehen könnte, wenn man (zumindest noch) nicht in der Lage ist, sich selbst ein TDBCurrency zu entwickeln, das die Transparenz zwischen präsentierten und gespeicherten Daten in beide Richtungen automatisch bereitstellt? Vielleicht gibt es ja auch einen anderen Ansatz, etwa auf der Ebene der "Data Access" Komponenten, aber im Moment bin ich etwas ratlos.

Auf jeden Fall scheint mir das Arbeiten mit Währungsbeträgen nichts ungewöhnliches, deshalb sollte es eigentlich dazu auch eine "best practice" geben...?

[linus]

Hallo sierdolg - ich habe schon mehrfach solche Auftragsverwaltungen implementiert und dabei die Erfahrung gemacht, dass es günstig ist, die Währungsbeträge einfach als CENT-Beträge zu speichern. Eine grössere Genauigkeit (also die von Dir genannten "Milli-Cent" habe ich aber nie gebraucht). Intern wird alles mit Ganzzahlen gerechnet und auch alle "Zwischenergebnisse", wie z.B. MwSt., Rabatte, etc., die krumme Werte liefern, werden direkt auf Ganzzahl-Werte kaufmännisch gerundet. Damit lässt sich dann alles so rechnen, "wie auf dem Papier". Für die Ausgabe (Bildschirm - Ausdrucke - Exportdaten, etc.) wird dann nur noch das Komma verschoben und alles ist gut. Vielleicht ist das nicht die optimale Lösung, aber für meine Anwendungen hat das immer gut funktioniert.

[Socke]

Um diese möglichst klein zu halten, und weil SQLite3 keinen fixen Datentyp erzwingt, wie er anderswo als "Currency" bereitsteht, bietet sich aus meiner Sicht offenbar an, alle Beträge grundsätzlich in einer feiner granulierten Ganzzahldarstellung zu speichern, also z.B. in "Millicent", und erst auf diesem Level kaufmännisch zu runden.

Der Datentyp Currency ist an sich nichts anderes. Der Wert wird als Ganzzahl gespeichert und verarbeitet. Das Komma wird erst bei der Ausgabe oder bei der Umwandlung in ein anderes Format berücksichtigt.

Hat jemand eine Idee, wie man vorgehen könnte, wenn man (zumindest noch) nicht in der Lage ist, sich selbst ein TDBCurrency zu entwickeln, das die Transparenz zwischen präsentierten und gespeicherten Daten in beide Richtungen automatisch bereitstellt? Vielleicht gibt es ja auch einen anderen Ansatz, etwa auf der Ebene der "Data Access" Komponenten, aber im Moment bin ich etwas ratlos.

In einem Dataset kann man Feld-Definitionen hinterlegen. Hier kann man auch den Datentyp ftCurrency auswählen. Ob das funktioniert hängt wohl von deinen verwendeten Komponenten ab.