Hallo zusammen,
mir fällt seit längerer Zeit auf, dass mir bei verschiedenen Mandanten im Zuge der Zahlungserstellung andere Skontodaten vorgewählt werden, als beim jeweiligen Geschäftspartner in den Stammdaten hinterlegt.
Dies führt leider dazu, dass z.B. 10 Tage 3% Skonto vom Zahlungsbetrag abgezogen wird obwohl hier z.B. 30 Tage netto (ohne Skonto) bezahlt werden müsste.
Dieses Phänomen habe ich leider bei mehreren Geschäftspartnern.
Mir wird hier schon eine kleine Info angezeigt, dass die ausgewählten Daten nicht mit den Stammdaten übereinstimmen, jedoch übersieht man das bei der Verarbeitung der Rechnungen auch schnell und die Frage ist, wo holt sich das System dann die falsche Skonto-Info her...
Ist hier ein Problem bekannt oder ist das nur bei mir?
Vielen Dank und viele Grüße
Jens Grabs
Hallo Herr Garbs,
die Skontoinformationen werden ausschließlich aus den historischen Informationen gezogen. Das heißt: die Erfassungsfelder werden auf Basis der Werte vorbelegt, die beim letzten Beleg des gleichen Geschäftspartners erfasst und gespeichert wurden.
Auch wenn eine Zahlungsbedingung in den Stammdaten hinterlegt ist, wird diese bei der Vorbelegung nicht berücksichtigt, sondern die Information aus dem letzten gespeicherten Beleg herangezogen.
Das blaue Info-Symbols weist darauf hin, dass die vorbelegten Daten nicht mit den Stammdaten übereinstimmen.
Hallo Frau Hübl,
vielen Dank für die Information.
aus meiner Sicht wäre es hier eher sinnvoll, die eingegebenen Stammdaten zu verwenden und die Daten der letzten Rechnung optional auswählen zu können. Wenn ich die Zahlungsbedingungen bei einem Lieferanten erfasse / ändere, hat dies ja im Grunde auch einen berechtigten Hintergrund.
Darüber hinaus wäre es zusätzlich zum Hinweis-Symbol sehr hilfreich, wenn ich nicht nur auf die Unstimmigkeit gegenüber den Stammdaten hingewiesen würde, sondern auch gleich auswählen könnte ob ich die Stammdaten oder die Daten der letzten Rechnung übernehmen möchte.
Das Problem ist nämlich (ich hoffe, ich stelle mich nicht nur zu dumm an..) dass ich im Erfassungsdialog die hinterlegten Stammdaten überhaupt nicht einsehen kann ohne direkt in die Stammdaten und den entsprechenden Reiter zu navigieren.
Vielen Dank und viele Grüße
Hallo,
ein kurzes Update zum Thema.
Diese Woche hatte ich exakt das gleiche Problem mit einer Firma.
Aus irgendeinem Grund meinte UO hier plötzlich eine Zahlungsbedingung incl. Skonto verwenden zu müssen, obwohl bis dato alle Rechnungen stets ohne Skonto bezahlt wurden.
Ich kann hier nur nochmals bitten, zuerst die Stammdaten vor zu belegen und als Option die letzte Zahlung anzubieten. Aktuell ist das Verarbeiten von zahlreichen Rechnungen und Zahlungswesen, zumindest für meinen Workflow, absolut fehleranfällig und natürlich auch nervig, da das nachträgliche Nachvollziehen und Nachüberweisen nicht nur mit einem, nicht unerheblichen Aufwand verbunden ist, sondern aufgrund der Häufung in der letzten Zeit, zunehmend auch peinlich gegenüber den Firmen / Kreditoren ist.
Ich bin kein Finanzbuchhalter oder Fachmann auf diesem Gebiet.
Für mich ist dieser Bereich ein wichtiges Mittel zum effizienten Arbeiten.
Gerade diese Verarbeitung und Zahlung von Rechnungen war bis dato, vor Allem aufgrund der OCR-Erkennung, für mich einer der wenigen Vorteile von UO. Jedoch hat sich sowohl die OCR-Erkennung, als auch die o.g. Thematik für mein Wahrnehmen in den letzten Monaten zunehmend verschlechtert.
Vielen Dank und viele Grüße
Jens Grabs
Hallo zusammen,
nachdem mich dieses Thema mittlerweile seit Jahren Zeit in den Wahnsinn treibt, möchte ich das Thema Vorbelegung von Zahlungsbedingungen nochmal hoch schieben. Für mich ist es nach wie vor nicht nachvollziehbar welchen Sinn es macht, eine, im (Lieferanten-)Kundenstamm hinterlegte Zahlungsbedingung komplett zu ignorieren um dafür angeblich die zuletzt ausgewählte zu verwenden.
Dies ist aus meiner Sicht eine völlig sinnfreie und zudem höchste fehleranfällige Option.
In den letzten Monaten wurde mir regelmäßig eine falsche Zahlungsbedingung vorbelegt und im aktuellen Falle sogar bei einer jährlichen Rechnung, bei welcher ich letztes Jahr noch nicht mal eine Zahlungsbedingung ausgewählt hatte, sondern das Zahlungsziel als Datum eingegeben hatte.
Wenn noch nicht mal in dieser Konstellation das Zahlungsziel aus den Stammdaten verwendet wird, ist das für mich schon fast eine vorsätzliche Fehlergenerierung und künstliche Erschwerung der Zahlungsabläufe.
Ich möchte daher nochmals eindringlich darum bitten doch einfach die Stammdaten zu verwenden.
Es kann doch nicht sein, dass ich hier der einzige bin, der sich mit derartigen Problemen herumschlagen muss.
Ich habe über ein Jahrzehnt im IT-Bereich gearbeitet und kann nicht begreifen wie man derartige Sollbruchstellen einbauen kann ohne den Usern zumindest eine Option zu geben selbst zu entscheiden wie die Vorbelegung laufen soll.
Dann baut doch wenigstens eine Checkbox ein mit welcher man den Modus aktivieren / deaktivieren kann.
Viele Grüße
Jens Grabs
Zuerst einmal ein gutes, gesundes und erfolgreiches Jahr 2025 an alle.
Und täglich grüßt das Murmeltier...
Ich verarbeite gerade die DATEV-Abrechnung für das Q4/2024
Hier wird mir die Zahlungsbedingung "7 Tage - 3,5% Skonto, 30 Tage netto" vor belegt.
(welche ich hier definitiv noch nie verwendet habe)
Die letzte Auswahl war "14 Tage netto" (bzw. bei der letzten Zahlung wurde gar keine Zahlungsbedingungen ausgewählt, sondern nur manuell ein Fälligkeitsdatum eingetragen)
Mir ist wirklich völlig schleierhaft, nach welchen Kriterien hier vorgegangen wird.
Die Stammdaten (welche eigentlich verwendet werden müssten) sagen "14 Tage netto" und das System belegt etwas vor, was auch vorher nicht verwendet wurde.
Langsam aber sicher habe ich tatsächlich auch kein Verständnis mehr für eine derartige "Sollbruchstelle", welche aus meiner Sicht völlig unlogisch ist und mittlerweile seit Jahren regelmäßig dazu führt, dass falsche Beträge überweisen werden! Mit den bekannten, zeitaufwändigen Kommunikationen, Korrekturen und Nachüberweisungen.
Stellt das bitte endlich um auf die Einstellung in den Stammdaten und fertig!!!
Und, by the way, die Begründung "It`s not a bug, it`s a feature" lasse ich hier nicht gelten!
Mit freundlichen Grüßen
Jens Grabs