Hallo,
bei den erzeugten Buchungsvorschlägen aus digitalen Belegen wird manchmal ein falsche Kreditor vorgeschlagen. Obwohl im OCR Feld perfekt gescannt wurde und der Kreditor exakt so angelegt wurde wie im Scan erfasst, wird ein abweichender Kreditor vorgeschlagen. Das erfolgt immer Phasenweise und es sind auch nur wenige Kreditoren betroffen. Spielen außer den im digitalen Belegfeld angezeigten Scanfelder noch weitere Felder eine Rolle bei der Zuordnung?
Mit freundlichen Grüßen
Jörg
Gelöst! Gehe zu Lösung.
@huemmer schrieb:
Spielen außer den im digitalen Belegfeld angezeigten Scanfelder noch weitere Felder eine Rolle bei der Zuordnung?
Du musst bestenfalls die UStID richtig haben, danach wird auf die IBAN zurückgegriffen. Wenn das nicht funktioniert gibt es noch ein Kriterium, das habe ich gerade nicht im Kopf.
Die UStID, Rechnungsadresse und IBAN sind perfekt angelegt. Trotzdem erfolgen Vorschläge für einen anderen Kreditor. Sogar die Rechnungsanschrift ist angelegt. Lediglich die Kontaktdaten fehlen oder sind unvollständig.
Es wirkt, als ob Datev random einen falschen Kreditor vorschlägt, bis wieder Daten übertragen werden. Nur, dass ganz sicher kein falscher Kreditor verknüpft wurde. Also er scannt Kunde Müller GmbH, was auch im OCR erkennbar ist und schlägt Schulz GmbH vor. Seltsamerweise sind davon nicht alle Kreditoren betroffen. Es gibt Kreditoren die dafür "anfällig" sind. Es gibt aber kein System oder Logik.
Hallo @huemmer,
bei Bedarf prüfen wir gerne Ihr Anliegen über unseren Programmservice Rechnungswesen (Servicekontakt anlegen - Dok.-Nr. 1071593).
Freundliche Grüße
Katharina Schönweiß | Service Rechnungswesen (FIBU) | DATEV eG
Wir benötigen ein Tool, wo wir beim Buchen einen SC anlegen um dann sofort mit der Arbeit incl. der korrekten Verbuchung des fehlerkannten Beleges fortfahren können.
Mein Vorschlag:
- DATEV weiß doch was automatisch erkannt wurde.
- Wir schreiben doch die Korrekturen zurück.
-> DATEV sollte nach einer gewissen Schwelle, also wenn ein - und derselbe Kreditor 5 * korrigiert wurde, hausintern um Hilfe rufen, so daß sich ein DATEV- Mensch des Problems annehmen kann.
Wozu benötigt es da einen manuellen SC?
Das Problem ist doch auch, dass die OCR zwar im Hintergrund "lernt", wir aber überhaupt keine Möglichkeit haben in die entsprechende "Lerndatei" einzugreifen und sie zu korrigieren (eventuell sogar ein Flag zu setzen, dass der Eintrag nicht mehr von der Automatik verändert werden darf). Oder überhaupt eine Lerndatei für digitale Belege zu erstellen, die die Vorschläge der OCR überschreibt (wie es z.B. bei der Bank möglich ist).
Sie machen (vermutlich) als User alles richtig, prüfen Sie nur einmal die Scanneinstellungen Tipps zur Digitalisierung der Belege per Scanner - DATEV Hilfe-Center, mehr können Sie nicht tun - selbst ein OCR Entwickler von DATEV konnte uns nicht mehr helfen und hatte sich auch dann nicht mehr zurück gemeldet.
Es ist einfach eine **bleep** OCR, die vermutlich schlechteste bezahlte auf dem Markt!
Mir schlägt er beispielsweise vor (SKR03):
- Bei Kreditorenrechnungen das Sachkonto 640
- beim Hauptlieferanten mit 10 Rechnungen direkt hintereinander - unterschiedlichste Erkennraten bei Rechnungsnummer, Kundennummer, Bank und Namen
- Das Skontodatum wird als Leistungsdatum erkannt
- Der Skontobetrag wird als Betrag vorbelegt
usw.
Vielen Dank, ich werde den Weg versuchen und bei Erfolg das Ergebnis hier posten!
Gibt es schon Fortschritte? Das Problem (IN DATEV) weitet sich schon auf Buchungstexte (Random Buchungstext bei erkannten Buchungsvorschlägen) aus, wie eine Art Virus oder Schadsoftware in ihrem OCR Lerncode.
Ich habe den Eindruck, das nach dem letzten Programm Update viele Informationen im Mandanten nicht mehr verfügbar sind. Die OCR Erkennung für die digitalen belege ist unzureichend, die Vorschläge für Konten sind schlechter als vor dem Update. Textvorschläge für Buchungstexte sind sinnentleert. Haben noch mehr Anwender es so wahrgenommen?
Ja, ich spreche für mich und alle aus der Kanzlei. Das selbe Problem. Wobei es nicht zu 100% auf das Updatedatum zurückreicht.