CAO - FAKTURA

Hallo!

Habe gerade eine Einkaufsrechnung zum 2. mal erfasst und erhalte
wieder beim Versuch die Zahlung zu verbuchen "ungültige Gleitkommaoperation".

Kann ich was tun? Die erste Buchung habe ich schon storniert, jetzt beim
zweiten Versuch das gleiche Problem.

Bei uns tritt das selbe Problem beim Buchen eines Auftrag im Rechnungsjornal auf.
Der Benutzer erhät die Anzeige: ungültige Gleitkommaoperation.
Ich verwende seit Jahren Cao, z.Z. Cao 1.4.3.4K im Client-Server-Betrieb.
Da Problem tritt für einen betroffenen Auftrag dann auf allen Clienten auf.
Neustart des Rechners oder Cao bringt keine Abhilfe. Das Netzwerk ist stabil.
Nur auf dem Server ist der Auftrag dann buchbar.
Es Betrifft NICHT alle Aufträge. Einen unterschied in den betroffenen Aufträgen konnte ich nicht feststellen.
Alle betroffenen Aufträge wurden aus unserem OSC-Onlienshop vom Server imprtiert und hatten das Zahlungsziel Vorkasse.
Alle Rechner Win XP Prof SP3 alle Updates.

Gibt es zu diesem Problem schon etwas neues? Tritt hier bei einigen Datensätzen ebenfalls auf (1.4.3.7K): Auswahl der Rechnung im Journal, Klick auf "Zahlung" und RUMMS... "Ungültige Gleitkommaoperation".

Habe schon in der Tabelle Journal zwei Datensätze manuell verglichen, einer wo der Fehler passiert und einer ohne den Fehler. Dachte spontan, es müsste sich so ein typischer Division by Zero oder falsch formatierte Dezimalseparatoren finden. Aber nichts dergleichen - sind ohnehin DECIMAL-Felder und keine VARCHARs.

Hallo Ihr drei,

Ich hab mal kurz gegockelt (gegooglet) und das hier gefunden http://cao-faktura.dosk.de/1_forum/allg ... al-problem

Hier scheint der Fehler darin zu liegen, dass in einer Rechnung die Währung fehlt. Hoffe es hilft weiter.

Gruß Frank

Hallo,

die Währung hat beu uns nicht gefehlt.

Hallo,

das passiert bei uns auch ab und an, ich habe da noch keine Besonderheiten gefunden um es nachvollziehbar zu machen... leider!

Ich hol das Thema mal wieder hervor. Anscheinend interessiert das nicht so, weil es nicht so häufig vorkommt. Wenn darauf aber die Buchhaltung basiert, ist es ein großer Fehler, da die Rechnungen als nicht bezahlt auftauchen, obwohl diese bezahlt sind.

Bei mir ist es so, dass ich wiederkehrende Rechnungen generiere (also über Verträge). Bei einigen Kunden konnte ich die Rechnungen problemlos buchen, bis auf einzelne, wo wieder die Fehlermeldung mit der Gleitkommaoperation kommt. Ich würde die gerne irgendwie verbuchen und aus der Liste der offenen Rechnungen bekommen, ist auch unprofessionell, wenn der Kunde dann sinnloserweise noch Mahnungen bekommt.

Wenn von den Entwicklern nichts kommt (wovon ja auszugehen ist, so lange wie das hier brach liegt), hat jemand eine Idee, wo man in der Datenbank über phpMyAdmin Hand anlegen könnte, damit man diese Einzelfälle ausgebucht bekommt?

Ach ja, verwendet wird die neueste K-Version (Stand 10.09.2013) von CAO auf MySQL4, lokal läuft Windows 7 auf einem Client, XP auf dem anderen.

Hallo,
ich kann mich zwar noch ein wenig an dieses Problem erinnern, muß aber auch dazu sagen, dass ich es seid mehreren gefühlten Jahren nicht mehr habe/hatte.

Was hat die Rechnung denn für ein Stadium in der DB / Tabelle Journal? Wenn offen, dann sollte dort "2" stehen.

thomas hat geschrieben:Hallo,
ich kann mich zwar noch ein wenig an dieses Problem erinnern, muß aber auch dazu sagen, dass ich es seid mehreren gefühlten Jahren nicht mehr habe/hatte.

Was hat die Rechnung denn für ein Stadium in der DB / Tabelle Journal? Wenn offen, dann sollte dort "2" stehen.

Ich habe diese Problem mit der Gleitkommaoperation in einer offenen Rechnung eines Lieferanten vom 21.05.2012.
Wenn ich auf Zahlung klicke, öffnet sich ein Fenster "ungültige Gleitkommaoperation". Bei Stadium in der DB steht 2,
bei allen anderen Buchungen 9.

Andreas.Meyer hat geschrieben: Ich habe diese Problem mit der Gleitkommaoperation in einer offenen Rechnung eines Lieferanten vom 21.05.2012.
Wenn ich auf Zahlung klicke, öffnet sich ein Fenster "ungültige Gleitkommaoperation". Bei Stadium in der DB steht 2,
bei allen anderen Buchungen 9.

Habe das jetzt mal mit HeidiSQL auf 9 gesetzt und die Rechnung wird im Journal als bezahlt angezeigt.
Wenn es da sonst keine negativen Auswirkungen gibt, ist das ja ok.

Andreas.Meyer hat geschrieben:enn es da sonst keine negativen Auswirkungen gibt, ist das ja ok.

Naja, in der Tabelle Zahlungen sollte eigentlich dann auch die Zahlung drinn stehen, jedoch wird das jetzt nicht der Fall sein, da Du händlich nur den
Status geändert hast.

thomas hat geschrieben:

Andreas.Meyer hat geschrieben:enn es da sonst keine negativen Auswirkungen gibt, ist das ja ok.

Naja, in der Tabelle Zahlungen sollte eigentlich dann auch die Zahlung drinn stehen, jedoch wird das jetzt nicht der Fall sein, da Du händlich nur den
Status geändert hast.

Wo oder wie mache ich das? Ich kann in der Tabelle journal nichts dergleichen finden.

Die Zahlungsbuchung in der Datenbank ist soviel ich hier im Forum gelesen habe sehr komplex.
Jeder Zahlungseingang sollte eigentlich auch in der Datenbank in der Tabelle Zahlungen stehen.
Bei der Rechnung, wo Du jetzt in der Tabelle Journal den Rechnungsstatus händlich auf "9" gesetzt hast ist es so, dass diese in der Tabelle Zahlungen nicht auftaucht und das ist eigentlich nicht schön und auch nicht richtig (negativ also)

Wie jetzt der Zahlungseingang in der DB erfolgt, kann ich Dir leider nicht sagen. Sorry.

thomas hat geschrieben:Die Zahlungsbuchung in der Datenbank ist soviel ich hier im Forum gelesen habe sehr komplex.
Jeder Zahlungseingang sollte eigentlich auch in der Datenbank in der Tabelle Zahlungen stehen.
Bei der Rechnung, wo Du jetzt in der Tabelle Journal den Rechnungsstatus händlich auf "9" gesetzt hast ist es so, dass diese in der Tabelle Zahlungen nicht auftaucht und das ist eigentlich nicht schön und auch nicht richtig (negativ also)

Wie jetzt der Zahlungseingang in der DB erfolgt, kann ich Dir leider nicht sagen. Sorry.

Doch, der Vorgang steht auch in der Tabelle Zahlungen, hat mich auch etwas verwundert.

Also den Status entsprechend ändern und es sollte passen, oder? Bei mir steht die Rechnung jetzt schon auf 3x gemahnt (im Journal).