EO comfort / Ein Programm welches nicht richtig rechnen kann

[#1]

Hallo zusammen,

die ist eine Fortsetzung des Beitrages:

EO comfort / Zeiterfassung ohne comfort / Industrieminuten - Echte Minuten

Beispiel: Auf dem Arbeitsblatt "Kurzübersicht" eines Auftrages stehen aufgelaufene Sunden in Höhe von 389,42.

Auf dem Arbeitsblatt "Aufwände" stehen 387,70 Stunden.

Ähnliche Differenzen haben wir bei vielen Aufträgen mit vielen Stunden.

Maßnahmen unsererseits bzw. der DATEV:

• Servicekontakt, Frenbetreuung mit DATEV Mitarbeiter 1: Auskunft des DATEV Mitarbeiters: das kann nicht sein.
• Rückruf eines zweiten DATEV Mitarbeiters: Fernbetreuung 2: Auskunft des DATEV Mitarbeiters: das kann nicht sein / Rückfrage bei der Entwicklung
• Rückruf des Mitarbeiters 2: Das sei halt so. In der Kurzübersicht wird die Summe aller "Echte Minuten" umgerechnet und im Arbeitsblatt "Aufwände" wird jede einzelne Zeiterfassung von "Echte Minuten" in Industrieminuten umgerechnet. Dadurch ergeben sich die Differenzen!

Das macht mich sprachlos!

Ralf Blum

ein genervter unzufriedener aber konstruktiver EO comfort Kunde

[#2]

Moin,

das ist die Sache mit der Sorgfalt beim Programmieren, "Norbert" treibt eben überall sein Unwesen. Aber freuen wir uns, DATEV hat in vorauseilendem Gehorsam Platin für die tolle Programmierung von Software für die öffentliche Hand gewonnen. Vllt. sollte den Programmierern einmal die Rundungsfunktion in den genutzten Programmen erklärt werden. In Excel kann das bei mir sogar der Lehrling (äh Auszubildende).

Gruß

KP

[#3]

Mit Datum & Zeiten zu rechnen, ist schon die hohe Schule der der Mathematik.

[#4]

Moin,

in EO eher Chaos by Design. Hätten sich die Programmverantwortlichen auf ein Vorgehen bei der Auswertung geeinigt würden diese Abweichungen nicht vorkommen. Die Behandlung der bei uns doch recht häufig vorkommenden 10 Min. Schritte bringen in der Addition diese Differenzen. Wenn ich dann in einer Auswertung den erfassten Stundentopf addiere und in Industrieminuten umrechne oder in einer anderen Darstellung den Industrieminutentopf, habe ich den Salat.

[#5]

Das gleiche Problem haben wie bei der MwSt.

Da liefert ein Mandant zig- tausende von Kleinumsätzen pro Vorlauf, wo für jeden Umsatz die MwSt per Automatik abgerundet auf dem MwSt- Konto landet.

Beim der MwSt- Verprobung im Abschluß lebt man hat mit den Differenzen im knapp 3- stelligem EUR- Bereich...
(Das zu lokalisieren und zu dokumentieren hat ein paar Stunden Arbeit gekostet)

[#6]

1. Ist das Problem systembedingt und

2. wird es nicht dadurch reduziert, wenn man Einzelbuchungen auswählt?

Auch ich bin über diese Diskrepanz gestolpert und war echt verwundert. Das liegt aber an der hohen Zahl von Vorgängen. Normalerweise sollte sich die Abweichungen statistisch ausgleichen, da die Cent-Diff. mal zu hoch und mal zu niedrig sind. Aber die Rechnenlogik ist bei DATEV wohl etwas anders, als bei unserem vorhergehenden Software-Anbieter. Bei diesem hatten wir nie so hohe Differenzen.

Gruß A. Martens

[#7]

Einfach einen Umsatz von 1 EUR 10 Mal auf # 8300 (Umsatz, 7%) buchen und addieren.

Kontowerte: Netto 9,3 + 0,7 MwSt.

In Erklärung: Netto 9,3 + 0,65 MwSt
-> bereits bei 10 Buchungen 5 Cent Differenz.

-> Bei 10.000 Buchungen 49 EUR Differenz zwischen Konto und Berechnung

[#8]

und wie soll das Problem gelöst werden?

[#9]

Zitiat Martin Kolberg:

Da liefert ein Mandant zig- tausende von Kleinumsätzen pro Vorlauf, wo für jeden Umsatz die MwSt per Automatik abgerundet auf dem MwSt- Konto landet.

Wenn DATEV tatsächlich bei der Berechnung nicht kaufmännisch* rundet, sondern die USt. immer abrundet, dann ist das zwar zugunsten des Steuerpflichtigen, führt dann aber auch zu hohen Differenzen.

Beipiel:

Netto     USt.     USt. lt. DATEV     USt. gerundet

9,3         0,651          0,65                     0,65

9,4         0,658          0,65                     0,66

Das meine ich mit statistisch. Bei einer kaufmännischen Rundung löst sich die Berechnungsdifferenz statistisch auf.

Ich weiß aber nicht, ob DATEV immer nur abrundet. Das müsste ich einmal nachprüfen.

Gruß A. Martens

*kaufmännische Rundung: siehe auch Wikipedia

[#10]

Einfach einen Umsatz von 1 EUR 10 Mal auf # 8300 (Umsatz, 7%) buchen und addieren.

Kontowerte: Netto 9,3 + 0,7 MwSt.

In Erklärung: Netto 9,3 + 0,65 MwSt
-> bereits bei 10 Buchungen 5 Cent Differenz.

-> Bei 10.000 Buchungen 49 EUR Differenz zwischen Konto und Berechnung

Das ist jetzt aber irgendwie kein EDV-Problem. Das gleiche Ergebnis kommt nämlich selbst dann heraus, wenn man die Buchungen auf T-Konten aufmalt.

[#11]

Wenn ich aber auf T-Konten buche, verwende ich einen Tischrechner, der kaufmännisch rundet. Dann stellt sich das Problem aber nicht (s. mein Thread).

[#12]

Moin,

grundsätzlich nerven Differenzen schon. Die Verprobungsdifferenz bei der Umsatzsteuer ist nicht rechen- sondern systembedingt. Das Umsatzsteuergesetz bezieht sich immer auf den Umsatz und das Entgelt für diesen Umsatz, KaReWe rechnet daher richtig und die Differenzen lassen sich nicht vermeiden.

Die Differenzen in der EO sind durch Erfassung in normalen Minuten und Ausgabe in Industrieminuten bedingt. M. E. muss in einem solchen Programm von Herstellerseite eine Dokumentation bestehen, die solche Abweichungen zwischen zwei Auswertungen desselben Programms ausschließt. Dasselbe gilt umso mehr, wenn es sich um 2 verschiedene Programme handelt, also wenn der Topf mit den echten Stunden aus der Zeiterfassung und der Topf mit den Industrieminuten aus EO stammt. Dann sind wir wieder bei der Geschichte mit der Qualitätssicherung.

Gruß

KP