Hallo, ich habe jameica 6.0 und hibiscus 6.2.4 unter fedora 20 linux installiert.
Eingerichtete SEPA-Überweisungen werden nur gerundet abgespeichert und im Feld "vorhandene SEPA-Überweisungen"
werden entsprechend nur volle Beträge xxx,00 ohne Centbeträge angezeigt und bei Ausführung auch nur so überwiesen.
Das Betragsfeld in der mysql-Datenbank hat in der Tabelle aueberweisung das Datenformat DOUBLE wie vorgesehen.
Bei den normalen Überweisungen werden die Beträge korrekt und nicht gerundet angezeigt, ebenso die Umsätze.
Ich habe dazu keine Einstellungsmöglichkeit gefunden,
wo liegt der Fehler?
frdl grüßt
MC Legis
- Korrektur: Muss natürlich heißen Jameica 2.6.0 und Hibiscus 2.6.4!
MC

Kann es sein, dass das Betriebssystem irgendwo falsche Zeichen als Dezimaltrenner gespeichert hat, also z.B. den amerikanischen Punk als Dezimal- und das Komma als Tausendertrennzeichen? Denn so ein Problem habe ich in Zusammenhang mit Hibiscus noch nie gelesen. Wie ist das denn in anderen Programmen, z.B. Tabellenkalkulation? Läuft da alles wie erwartet?

Hi Onlbanker,
müssten dann nicht alle Tabellen betroffen sein, wenn es an falschen Trennern im Betriebssystem liegen würde?
Es ist aber nur die SEPA-Überweisungen-Tabelle bzw. -liste betroffen, nicht die alten Überweisungen und auch keine andere Tabelle.
M.E. wird hier die Datenbanktabelle 'aueberweisung' angesprochen und da hat das Betragsfeld das Datenformat DOUBLE mit 15 Stellen.
Die gerundeten Beträge erscheinen auch im Terminkalender, soweit sie SEPA-Überweisungen waren bzw. sind.
Ich muß die terminierten SEPA-Überweisungen öffnen und die Cent-Beträge ändern, dann ausführen.
Gespeichert wird die Überweisung wieder nur gerundet.
Im Terminkalender erscheint dann die SEPA-Überweisung gerundet, der Umsatz centgenau.
Normale (frühere) Überweisungen aus der Übersicht "Überweisungen" erscheinen centgenau.
In den anderen Tabellen der Datenbank Hibiscus hat das Betragsfeld eine Länge von 22 Stellen, bei SEPA nur 15. Kann es damit zu tun haben?
Datenbanktechnisch sind 15 Stellen mehr als genug. vielleicht ist die Darstellung das Datenbankformular auf ein anderes Zahlenformat eingestellt?
Bei Access oder Openoffice Base kann man das so einstellen. Der Programmteil also, der die Bildschirmaske aufruft.
Nein- das ist auch nicht logisch, dann dürfte der Fehler nicht im Terminkalender auftreten.
Vielleicht liegt der SEPA-Bildschirmmaske eine Abfrage zugrunde, die den Fehler enthält?
Dann müßte das aber bei allen Nutzern so auftreten.
Tritt der Fehler bei anderen nicht auf?
Danke für deine Lösungsbemühungen,
frdl. Gruß, Legis

Es ist eine MySQL-Installation. Die Datenbank Hibiscus habe ich in Open/Libre-Office bzgl. einiger Tabellen eingebunden.
Rufe ich die Tabelle 'aueberweisung' auf, kann ich die Daten ändern, aber nur gerundet.
Ich habe das jetzt im MySQL-Administrator angeschaut.
Die Tabelle 'aueberweisung' ist relativ neu und hat als einzige das Format MyISAM, die anderen sind InnoDB.
Das Datenformat ist dort genau angegeben mit "DOUBLE(15,0)".
Das bedeutet wohl: 15 Stellen vor dem Komma, 0 =keine danach.
Das ist voreingestellt, ich habe daran nicht manipuliert. Entspricht das den Vorgaben des Herstellers?
Kann ich das einfach umstellen auf DOUBLE(15,2) ?
So kann es jedenfalls nicht bleiben.
Gruß
Legis

Also ich hab noch nie von diesem Fehler gehoert. Allerdins ist der Tabellentyp "MyISAM" und auch der Spaltentyp DOUBLE(15.0) falsch. Es muss InnoDB sein, damit Transaktionen funktionieren. Und der Typ muss Nachkommastellen haben. Das erklaert natuerlich den Fehler. Es erklaert aber nicht, wie die Tabelle bei dir diesen ungueltigen Zustand haben kann.

Gibt es einen Standard-Typ in MySql Installationen? Ich hatte dies nämlich vor einigen Monaten bei einer alten geerbten DTA-Abrechnungs-Datenbank in einer Wamp-Umgebung, bei der Abrechnungsdaten über ein php-Script erfasst wurden. Das Chaos war riesengroß, weil es der Buchhalter nicht gemerkt hatte.

Gruß
Raimund

Hallo hibisus (Olaf),
kann ich dann das DB-Format der Tabelle ohne Datenverlust auf InnoDB ändern und das Datenformat auf DOUBLE ohne Zusatz?
Woher die falsche Einstellung kommt, weiß ich nicht. Hat es mit einem Update eine create-table-Anweisung gegeben bzgl. der 'aueberweisung'?
Früher gab es die ja nicht.
Gruß
Legis

Guckst du hier:
https://dev.mysql.com/doc/refm…nnodb.html

Oder nimm als ein entsprechendes Tool wie phpMyAdmin oder die MySQL Workbench. Dort koenntest du alternativ auch die Daten der Tabelle exportieren, die Tabelle anschliessend als InnoDB neu anlegen und dann die Daten wieder importieren.



Das sollte problemlos mit phpMyAdmin oder MySQL Workbench gehen.



Kann ich mir eigentlich nicht vorstellen. Dann waeren auch andere User von dem Problem betroffen.



Die Tabelle gibt es eigentlich schon seit Februar 2009. Allerdings wurde der Tabellentyp bei MySQL frueher mit "Type=InnoDB" angegeben. Inzwischen wird das mit "ENGINE=InnoDB" gemacht.. Unter Umstaenden wurde die Tabelle bei dir damals angelegt, als Hibiscus bereits den Parameternamen "ENGINE" verwendete, deine MySQL-Version das aber noch nicht unterstuetzte. Oder andersrum, deine MySQL-Version erwartete bereits "ENGINE", Hibiscus hat aber noch "Type" verwendet. Das laesst sich im Nachinein ander nicht mehr herausfinden.