Import von Bewegungsdaten aus Vorsystem führt zu Fehlern beim Zeitformat

[#1]

Ausgangslage: Mandant erfasst in AGIL die Bewegungsdaten der Mitarbeiter vor. Es scheint sehr viele Besonderheiten zu geben (Zeitarbeit und verschiedene Gratifikationsmodelle).

Wir sind inzwischen soweit, dass wir ein entsprechendes Dateiformat erhalten und grundsätzlich importieren können.

Folgender "Fehler" passiert dann aber in Lohn und Gehalt:

"Rohdaten":

Darstellung in Lohn und Gehalt:

In Lohn und Gehalt sind klipp und klar "Industrieminuten" gewählt. Am Import-File könnte man zwar irgendwas anpassen - aber da würde sich mir nicht logisch erschließen, was das sein soll.

In den markierten Beispielen:

PersNr. 102 - Lohnart 1000 - laut Importfile "163,52" (Industrieminuten) werden hier fälschlicherweise in "163,87" umgewandelt

PersNr. 102 - Lohnart 1900 - laut Importfile "-11,85" (Industrieminuten) bleibt korrekterweise bei "-11,85"

PersNr. 119 - Lohnart 1900 - laut Importfile "-8,57" (Industrieminuten) werden hier fälschlicherweise in "-8,95" umgewandelt

Umwandlung passiert "gefühlt" bei allen Werten kleiner 60.

Kennt jemand dieses Phänomen? Haben wir einen Denkfehler? Können wir an irgendeiner Stellschraube drehen, um das zu korrigieren?

Manuelle Korrektur für alle Positionen ist super aufwändig, weil hier mehrere hundert Mitarbeiter beschäftigt sind.

[#2]

163,87 - 11,85 - 8,95 = 143,07 DATEV

163,52 - 11,85 - 8,57 = 143,10 Importwerte

Ergänzung: das sind ja verschiedene Personalnummern. 🙈 Vergiss es.  102 und 119. Sorry das sehe ich erst jetzt. 

Das ist eine absolute Differenz von -0,03 €. Natürlich trotzdem vollkommen indiskutabel, das zwischen Importwert und angezeigten Wert in Lohn und Gehalt eine Differenz vorliegt.

Ist das Mitarbeiter, Lohnart bezogen,... irgendein anderes sich abzeichnendes Muster/Merkmal an Hand man den Fehler eingrenzen könnte?

Ich hätte auch als erstes auf das Zeitformat abgestellt. Da aber ja ein guter Teil richtig importiert werden konnte spielt da vielleicht noch was anderes mit rein. 🤔

[#3]

Der Abw. Faktor wurde beim Import ja auch von 91,04 in 91,07 geändert...

[#4]

---

@pogo  schrieb:

Der Abw. Faktor wurde beim Import ja auch von 91,04 in 91,07 geändert...

Das war bis eben noch nicht mal aufgefallen. Danke für den Hinweis!

Dann ist da aber irgendwas im Argen bei Lohn und Gehalt 🙄

[#5]

Wird im Vorsystem und LuG mit verschiedenvielen Nachkommastellen gerechnet und oder / verschieden gerundet?

sind ja Centbeträge, wenn in Lug mit 10,xy Minuten und im Vorsystem mit 10,xyz Minuten gerechnet wird, in der Ausgabemaske des Vorsystems aber nur 10,xy Minuten angezeigt/exportiert werden....

Das würde aber bedeuten, dass der Betrag nicht importiert sondern von LuG berechnet wird... 🤔 auch irgendwie....

Einen ähnlich gelagerten Fall hatten wir (in meinem früheren Leben) mal bei der Füllstandsberechnung eines Flüssigkeitsbehälters. Obergrenzensensor meldet voll und die Anlage schaltet ab.

Laut Füllstandsanzeige war die Anlage aber nicht voll. Die Anzeige beruhte auf einer Berechnung mit nur 2 Nachkommastellen aus Werten des Durchflussmengenmessers. --> In der Konstruktion war nicht definiert welcher der Sensoren den Hut aufhat und mit welcher Toleranz gemessen werden sollte.

Klären konnten das nur die Konstrukteure. --> Bedeutet im Umkehrschluss:

Das kann nur wer aufklären der mehr als das Frontend der jeweiligen Software kennt.

@DATEV Spielball liegt wohl bei euch im Feld. 🙂 @nadimb der Anbieter des Vorsystems wird ja auch einen Service haben, vielleicht mal in Erfahrung bringen mit welcher Genauigkeit dort gerechnet wird? 

[#6]

Wir bekommen ein .txt-File - wenn du so willst, ist das "Plain Text". Da ist egal, was im Vorsystem eingestellt ist.

DATEV kann ja nur die Daten übernehmen und einspielen, die ich da 1:1 reinwerfe - eine Direktverbindung zum Vorsystem existiert de facto nicht. Daher kann es nur sein, dass Lohn und Gehalt da irgendwie die Werte falsch interpretiert.

Die Frage ist: warum? Und: wie kann ich das ändern?

Deine Feststellungen der Festellungen habe ich zur Kenntnis genommen. Keine weiteren Feststellungen notwendig. Danke für den Versuch.

[#7]

Hallo,

gerne überprüfen wir den Sachverhalt individuell.

Bitte wenden Sie sich dazu über einen der üblichen Servicekanäle an uns.

[#8]

Über eine öffentliche Auflösung des Falls würde ich mich sehr freuen 😊.

[#9]

Auflösung: Lohn-Service hat sich gemeldet und die Sache innerhalb von weniger als 5 Minuten gelöst und aufgeklärt.

Der Fehler lag an den kanzleiseitigen Einstellungen im ASCII-Importassistenten.

Hier haben 3 Leute (einer davon ich) übersehen, was wir da eingestellt haben.

So hätte es von Anfang an eingestellt sein müssen:

Aus Gründen, an die ich mich nicht mehr erinnere, haben wir im hinteren Feld ein "Komma" gesetzt. Das war (logischerweise) falsch und ein Beweis dafür, dass der Fehler häufig 30cm vor dem Bildschirm sitzt.

[#10]

---

@nadimb  schrieb:

 ein Beweis dafür, dass der Fehler häufig 30cm vor dem Bildschirm sitzt.

---

mal kurz klug**bleep**en:

30 cm sind aber etwas wenig ...

https://www.heise.de/tipps-tricks/Optimaler-Abstand-zum-Monitor-das-muessen-Sie-wissen-6112653.html

Gruß, vw

[#11]

---

@nadimb schrieb:

Das war (logischerweise) falsch und ein Beweis dafür, dass der Fehler häufig 30cm vor dem Bildschirm sitzt.

---

Nö. Ich sehe das eher als Digitalisierung braucht Standards und warum kann man sich da nicht auf ein einheitliches ASCII Set einigen? Je mehr Einstellungen der Mensch treffen kann, umso häufiger ist ein Fehler potentiell möglich. Warum können Daten nicht einfach von A nach B übernommen werden, damit man sich auf das Wichtige konzentrieren kann?!

Ist wie RDS 1.0 / BDS statt DATEV XML Belegtransfer. Klick hier: it just works vs. Belegtransfer: Warum kommen die Daten falsch an?

[#12]

---

@metalposaunist  schrieb:

---

@nadimb schrieb:

Das war (logischerweise) falsch und ein Beweis dafür, dass der Fehler häufig 30cm vor dem Bildschirm sitzt.

---

Nö. Ich sehe das eher als Digitalisierung braucht Standards und warum kann man sich da nicht auf ein einheitliches ASCII Set einigen?

Weil dafür im ersten Schritt an ganz anderer Stelle (Politik statt Software) eine Allgemeindefinition für die Erfassung von Zeiten zu treffen wäre (Echtminuten vs. Industrieminuten).

Deshalb kann kein Import-Standard gesetzt werden - weil es eben diese Optionen in der Realität gibt 🤗