OCR auf den Stand der Technik bringen

[#1]

Als Digitalisierungsbeauftragter möchte ich, dass DATEV eine Verbesserung der OCR vornimmt. Den Zweck muss ich hoffentlich nicht beschreiben. 😎

[#2]

@eliansawatzki Das hatten wir doch jetzt alles schon. Ich habe BDV Unides, Finmatics u. buchhalter.pro als die ernsthaftesten Kandidaten identifiziert.

[#3]

@eliansawatzki 

Die Welt ist nicht rosa und glitzert, dem sind wir uns alle bewusst. Die Fülle der Kommentare und Threads sowie die Ideas in der Community zeigen uns doch auf, dass wir ein System haben, das zwar im Grundsatz funktioniert, aber noch viel Luft nach oben ist.

Man darf nicht alles schlecht reden, aber wenn hier Verbesserungsvorschläge zu Dingen gebracht werden - sorry wenn ich das nochmal wiederhole -, eigentlich Standard sein müssten sollte man im Gegenzug nicht jedes Mal gegen diese Vorschläge schießen und das System besser zu reden.

Wir sind hier alle dazu da, um das System stetig zu verbessern!

[#4]

@theo wobei @ManfredLener nicht als Konkurrenz verstanden werden möchte sondern als Ergänzung. 🙂

Was ja im Endeffekt die anderen auch wären. Was mich eben im speziellen nervt. DATEV: " OCR? wir haben da ja was"

Also bitte entweder ja oder nein. dieses jein mit dem wir aktuell arbeiten.... 🙄

[#5]

Die sind alle explizit Vorsystem zur Datev (bzw. anderer Fibu-Software).

[#6]

Vielen Dank für die unterschiedlichen Meinungen.

[#7]

Wenn der Mandant einen Beleg mehrfach hoch läd, könnt er seine Gründe haben.
Hauptgrund wäre, daß beim ersten Hochladen ein Problem mit dem Beleg besteht, also nur eine vorab- Fax- Rechnung oder eine AB bzw. ein alibaba- Screenshot vorliegt, aufgrund dessen er zahlt. Est viel später kommt der Original- Beleg, den dann natürlich an den festgeschriebenen Buchungssatz angeheftet werden möchte. 
Wollen wir jetzt eine alibaba- US$- Kreditkarten- Zahlung ohne jedlichen Beleg haben? 
nein, besser irgend einen Wisch, um zu wissen, worum es sich bei der Zahlung handelt und später kommt der korrekte Beleg.

[#8]

@martinkolberg dann sind es auch zwei Belege.

Bestellbestätigung mit Zahlungsaufforderung (schon oft als Sreenshot gesehen) und Rechnung (leider oft genug erst nach Ermahnung dass die Vorsteuer sonst nicht gezogen werden kann zu Gesicht bekommen).

Wir reden hier gerade über den Umstand, dass zweimal die Bestellbestätigung und/oder zweimal die Rechnung hochgeladen wird... und dafür gibt es keinen zumindest mir einleuchtenden Grund. Ich kann mittels der Beleg ID Nummer alles mögliche mit dem Scan des gleichen Belegs anfangen. Heute erst einen Beleg an Vier Konten gebucht. Dafür muss ich den aber nicht viermal hochladen.

[#9]

@theo 

Die Lösung von BDV hört sich vielversprechend an - insbesondere die auf der Homepage ( Digitale Belegverarbeitung für Steuerberater - Lösung der BDV GmbH ) dargestellten Features:

@juliusbehr  Ich vermute, was Sie mit "gegen Vorschläge schießen" meinen ist das gleiche was ich als "einen andere Blickwinkel in die Beiträge bringen" bezeichnen würde. Gerade aus der Kommunikation konträrer Standpunkte entwickelt sich m. E. erst ein umfassendes Bild über die Gesamtsituation. In der Regel bewegt sich jeder in seiner eigenen Blase. Daher wird mitunter auch die Idee und der Ansatz des anderen nicht verstanden. Manchmal wird es dabei, was ich nicht schlimm finde, dann auch lebhaft. Am Ende entscheidet wieder jeder für sich selbst.

Schade ist allerdings, und damit meine ich nicht Sie, dass konträre Standpunkte hier in der Community immer häufiger auf pauschale Ablehnung stoßen. Leider häufig nicht aus sachlichen Gründen, sondern einfach der Ablehnung willen. Da ist man (zum Beispiel ich selbst) dann der "DATEV-Verteidiger", "datev-einseitig", "hat keine Ahnung" und besitzt "fehlenden Weitblick". Da wird auf sachliche Argumente gar nicht mehr eingegangen, sondern einfach nur noch drauf losgeschrieben - egal ob es  zum Thema passt oder nicht. Mich persönlich bringt das nicht aus der Ruhe. Für die Debattenkultur in der Community ist es jedoch kein Positiv-Merkmal.

[#10]

Apple iOS 15 Live Text - sieht schon sehr geil aus und wenn das auch so zuverlässig funktioniert 🤓

[Hinweis: Aktuell passen wir unsere Website-Angebote an das neue TTDSG an. Bitte haben Sie Verständnis, wenn einzelne Funktionen, z. B. eingebettete YouTube-Videos, derzeit nicht abrufbar sind.]

[#11]

Besser als Datev allemal - sowas erwartet man vom "Marktführer" nicht diese primitive OCR

[#12]

Wenn wir hier über die OCR sprechen, kann mir hier jemand kurz eine Rückmeldung geben, ob das ein bestehendes Problem/ aktueller Zustand ist, oder ob man das beeinflussen kann:

Die OCR Erkennung schreibt "im Zweifel" die Information in die Felder der Buchungserfassung, die dort erfasst wurden, als z.B. der Kreditor das letzte Mal bebucht wurde. Das führt zu folgenden (unschönen) Effekten:

- Wenn ich im Buchungstext im letzten Monat (z.B. April) "Telekom 04/21" geschrieben habe, wird mir das im Mai wieder angezeigt und ich muss manuell auf "Telekom 05/21" ändern (das geht in den nächsten Monaten natürlich genauso weiter). Ich könnte bei der Telekom auch auf die Monatsangabe verzichten, aber generell wäre das irgendwie ein Rückschritt...

- Wenn z.B. die Rechnungsnummer nicht auf dem Beleg gefunden wird, schreibt mir die OCR Erkennung die letzte Rechnungsnummer rein, die eingebucht wurde. Das ist natürlich deutlich nerviger als das obere Problem, weil die Erkennung auch nicht wirklich optimal läuft (80% Erkennung). Damit könnte man ja noch leben, aber ein LEERES Belegfeld 1 wäre deutlich übersichtlicher, weil dann sofort auf einen Blick klar ist, dass die Rechnungsnummer nicht erkannt wurde (und man nicht Beleg A mit der Rechnungsnummer von Beleg B einbucht, ohne dass das Programm meckert). 

[#13]

Zu dem zweiten Problem (nicht erkannte Rechnungsnummer) wäre vielleicht folgende Einstellung interessant:

Dann wird die Rechnungsnummer von dem vorherigen Buchungssatz gelöscht und Belegfeld1 bleibt leer.

[#14]

Ich mal wieder

[#15]

@Gelöschter Nutzer: 

Meister: "Wo schreiben wir unsere Steuernummer hin?"

Praktikant: " Lass uns die Rechnung an aufs Dartbord pinnen, die erste freie Fläche nehmen wir" 

Meister: " Super Idee"

Bin ich der einzige der die Platzierung zumindest ungewöhnlich findet? Mit einer Volltext Erkennung wäre das aber auch kein riesiges Problem.

[#16]

Tja so sind die Handwerkerprogramme.....

Ich bin schon froh wenn die kein Word oder Uraltprogramm nutzen. Und der OCR müsste es ja eigentlich egal sein wo die Steuernummer steht.

Das falsche Datum hat Sie ja auch unten gefunden....

Darf ich überhaupt noch "die" OCR sagen? 

[#17]

@jjunker 
es gibt keinen Standard !

Immerhin gibt es eine genaue Bezeichnung (eigene StNr). Ich habe auch schon Rechnungen gesehen, da steht direkt untereinander zweimal eine UStId => man darf sich dann wohl aussuchen, wem welche zuzuordnen ist 😥

Du glaubst nicht, was einem sonst noch alles über´n Weg läuft.

[#18]

@ManfredLener Ja es gibt leider (!) keine Standards. Oder in eurem Fall zum Glück. Macht ja euer Geschäftsmodell erst....

Zwei UStid Nummern direkt untereinander hatte ich nun noch nicht. 😅

Nur mal einen Beleg mit 5 Umsatzsteuersätzen. Wobei das ja wiederum in D leider nur richtig ist. 

[#19]

Das Leistungsdatum wird für die Zahlungsfrist ohne Skonto gehalten 👎

Sicher erkannt! Top

[#20]

Ich bin auf der Seite von @metalposaunist 

Das Problem ist nicht, dass OCR nicht alles erkennt, das Problem ist, dass die Lieferanten keine XMLs in die PDFs einbetten, die alle Daten (maschinell mit 100%iger Korrektheit) lesbar enthalten. Wobei das PDF ja eigentlich auch schon wieder nur optischer Pfusch ist, der eigentlich keinen Sinn macht. Es würde theoretisch einfach nur eine XML Datei ausreichen.

OCR selbst ist ein Problem, mit dem ein anderes Problem versucht wird zu lösen - eben dass keine nativen digitalen Daten vorliegen. Und das ist einfach nicht die Zukunft. OCR ist bei Rechnungen total ungeeignet, da es keine zuverlässigen Ergebnisse liefert. Und wenn ich mich auf ein System nicht zu 100% verlassen kann, bringt es mir nichts. Man setzt sich ja auch nicht in ein Auto, bei dem die Bremsen nur in 80% der Fälle funktionieren.

Somit macht eine Weiterentwicklung von OCR keinen Sinn.

Ich kenne ein paar Firmen, die ihre Lieferanten dazu zwingen, nur noch Rechnungen im ZUGFeRD Format zu schicken. Entweder die Lieferanten suchen sich eine Software, die das beherrscht, oder sie bekommen den Auftrag nicht. Punkt Fertig.

[#21]

@Phexi Wenn man die Marktmacht hat? Ja! alle Zulieferer bitte und nötigenfalls tatsächlich nötigen rein elektronisch zu kommunizieren. 100 % meine Haltung.

Aktuell ist die Logik hinter der OCR bei 40-50%? Die werden wir aber noch die nächsten 5-10 Jahre brauchen? Da würde ich gerne für diese Zeit mit 80% arbeiten.