Ist das überhaupt ein Buchungsvorschlag vom ASR? Es fehlen die roten Symbole an den leeren Pflichtfeldern der Buchungszeile.
Eventuell wurde der Beleg
bereits vor Aktivierung hochgeladen oder er gehört nicht zum Belegkreis Rechnungseingang oder Rechnungsausgang.
@eliansawatzki schrieb:Ist das überhaupt ein Buchungsvorschlag vom ASR?
Könnte die DATEV evtl. beantworten, denn ein paar wenige Infos werden ja vorbelegt . . .
Sind allerdings die ersten Rechnungen um das "System" anzulernen. Werde nun mal in einem Monat mehrere Buchungszyklen einbauen, um hier eine Beschleunigung herbeizuführen.
Ich gehe davon aus, dass EIN Buchungszyklus, die Verbuchung von Belegen und korrespondierende Finanzkontenbuchungen dazu, umfasst; selbstredend auch die RZ-Verarbeitung.
@eliansawatzki schrieb:
bereits vor Aktivierung hochgeladen oder er gehört nicht zum Belegkreis Rechnungseingang oder Rechnungsausgang.
Fett1: Könnt tatsächlich sein. Muss ich bei den späteren Belegen beobachten. Wusste gar nicht, dass in Rewe dann eine farbliche Markierung der Felder im Buchungssatz erfolgt.
Fett2: Alles in Rechnungseingang erfasst.
@eliansawatzki schrieb:Ist das überhaupt ein Buchungsvorschlag vom ASR? Es fehlen die roten Symbole an den leeren Pflichtfeldern der Buchungszeile.
Eventuell wurde der Beleg
bereits vor Aktivierung hochgeladen oder er gehört nicht zum Belegkreis Rechnungseingang oder Rechnungsausgang.
Das scheint es gewesen sein, denn die späteren Belege sind nun deutlich markiert.
Werde nun mal in einem Monat mehrere Buchungszyklen einbauen, um hier eine Beschleunigung herbeizuführen.
Ich gehe davon aus, dass EIN Buchungszyklus, die Verbuchung von Belegen und korrespondierende Finanzkontenbuchungen dazu, umfasst; selbstredend auch die RZ-Verarbeitung.
Bitte nicht vergessen nicht nur Buchungszyklen einzubauen, sondern auch den Belegupload zu entzerren. Die vom Machine Learning erkannten „Muster“ auf den Belegen werden erst für neu hochgeladenen Belege angewendet. Die Arbeitsweise könnte in der ersten Periode wie folgt aussehen:
1. Zyklus:
- Belege hochladen; offene Posten mit ASR einbuchen; Daten an das RZ senden; Verarbeitungslauf im RZ abwarten (ca. 2h - siehe Datenfahrplan
2. Zyklus
- weitere Belege hochladen - Rest wie oben usw.
Der ASR unterstützt beim Einbuchen von offenen Posten. Die Buchungen auf Geldkonten haben keine Effekte.
Wenn Bestände bereits lange Zeit DUO nutzen und es sich um eine entsprechende Belegstruktur handelt, ist das Entzerren der FiBu in der ersten Periode nicht erforderlich. Die Muster auf den Belegen werden hier bereits bei der Erstbestückung, welche im Rahmen der Bestellung stattfindet, erkannt und zukünftig angewendet. Bei einem Mandanten hatten wir hier bei ca. 300 Eingangsrechnungen im ersten Wurf ca. 160 Belege komplett sicher erkannt. Eine Prüfung ergab bei diesen Belegen keinen einzigen Fehler. Das war sensationell.
***gelöscht***
…irgendwie war der Beitrag doppelt…
@eliansawatzki schrieb:Werde nun mal in einem Monat mehrere Buchungszyklen einbauen, um hier eine Beschleunigung herbeizuführen.
Ich gehe davon aus, dass EIN Buchungszyklus, die Verbuchung von Belegen und korrespondierende Finanzkontenbuchungen dazu, umfasst; selbstredend auch die RZ-Verarbeitung.
Bitte nicht vergessen nicht nur Buchungszyklen einzubauen, sondern auch den Belegupload zu entzerren. Die vom Machine Learning erkannten „Muster“ auf den Belegen werden erst für neu hochgeladenen Belege angewendet. Die Arbeitsweise könnte in der ersten Periode wie folgt aussehen:
1. Zyklus:
- Belege hochladen; offene Posten mit ASR einbuchen; Daten an das RZ senden; Verarbeitungslauf im RZ abwarten (ca. 2h - siehe Datenfahrplan
2. Zyklus
- weitere Belege hochladen - Rest wie oben usw.
Der ASR unterstützt beim Einbuchen von offenen Posten. Die Buchungen auf Geldkonten haben keine Effekte.
Wenn Bestände bereits lange Zeit DUO nutzen und es sich um eine entsprechende Belegstruktur handelt, ist das Entzerren der FiBu in der ersten Periode nicht erforderlich. Die Muster auf den Belegen werden hier bereits bei der Erstbestückung, welche im Rahmen der Bestellung stattfindet, erkannt und zukünftig angewendet. Bei einem Mandanten hatten wir hier bei ca. 300 Eingangsrechnungen im ersten Wurf ca. 160 Belege komplett sicher erkannt. Eine Prüfung ergab bei diesen Belegen keinen einzigen Fehler. Das war sensationell.
Sehr interessante Hinweise. Vielen Dank.
Fett1,2: Den Belegupload zu entzerren, soll genau was heißen ? Nicht alle Belege auf einmal, sondern eher in kleineren Etappen ?
Hierauf haben wir natürlich kaum Einfluss, da die Belege bei den bestehenden Buchführungen von den Mandanten hochgeladen werden; denke aber da geht es zumindest im wöchentlichen Rhythmus.
Fett3ff: Das Einspielen der Kontoumsätze von Bank/Paypal darf m.E. erst dann erfolgen, wenn sämtliche Belege fest gebucht sind, da die Zuordnung zum Beleg sonst nicht hergestellt werden kann; ist ja jetzt kein großes Geheimnis an sich. Bin mir nicht sicher, aber die automatisch verknüpften Beleginformationen, die nach UO zurückgeschrieben werden, haben schon auch einen Folgeeffekt.
Nicht unmittelbar bei der Belegerkennung in Rewe, aber ggf. bei der Vorbelegung in UO. Reine Spekulation.
Mit ASR muss man da schon etwas umdenken, wenn im Laufe der Jahre bestimmte Workarounds etabliert wurden.
Habe mich da gestern noch etwas mehr gewidmet und muss sagen, dass die ersten Schritte vielversprechend sind.
Bei dieser ersten Probebuchführung haben wir einen UO-Neuling. Parallel haben wir gestern noch eine weitere prädestinierte Buchführung für ASR registriert, welche seit 5 Jahren über UO geführt wird. Hier wird zwecks 4-Augen-Prinzip eine Mitarbeiterin daran projektiert.
Da wir nun alle Buchführungen digital über UO abwickeln, erscheint mir ASR der folgelogische nächste Schritt zur Kontierung in UO, Bereitstellung und Einspielen in Rewe; insbesondere wenn die sog. KI gute Dienste leistet und tatsächlich weitgehend richtige Buchungsvorschläge erstellt.
Belegupload entzerren bedeutet:
Upload eines Teils der Belege - Buchen über ASR - Speichern im RZ - Verarbeitungslauf abwarten ("Maschine" lernt) - Upload weitere Belege - Buchen über ASR (Maschine wendet das bisher Gelernte an und lernt weiter) - Speichern im RZ - Verarbeitungslauf abwarten - Upload weitere Belege -Buchen über ASR ("Maschine" erkennt weitere Muster, lernt weiter und wendet das Gelernte immer besser an) - Speichern im RZ - Upload weiterer Belege usw.
In der ersten Buchungsperiode könnte man wie folgt verfahren:
Tag 1 vormittags: Belege der erste Wochen der Buchungsperiode hochladen, mit ASR buchen, speichern im RZ
Tag 1 nachmittags: Belege der zweiten Woche der Buchungsperiode hochladen, mit ASR buchen, speichern im RZ
Tag 2 vormittags: Belege der dritten Woche der Buchungsperiode hochladen, mit ASR buchen, speichern im RZ
Tag nachmittags: restliche Belege der Buchungsperiode hochladen, mit ASR buchen, speichern im RZ
Das Machine Learning indiziert die Belege beim Upload mit den Informationen (bzw. erkannten Mustern) die zu diesem Zeitpunkt des Uploads vorliegen. Daher wirken die Effekte erst bei Belegen die nach dem "Lernen" des RZ hochgeladen werden. Das Verhalten ist insofern identisch mit dem digitalen Belegbuchen ohne ASR.
Korrektes heften ist obligatorisch.
... obwohl ich dem ASR bisher die Lernfähigkeit nicht zugetraut habe, beginnt mich das Thema doch allmählich zu interessieren.
Gibt es bestimmte Mandatstypen bzw. Branchen und Belege-Volumina, die für ASR prädestiniert sind/wären ?
@eliansawatzki schrieb:Belegupload entzerren bedeutet:
Upload eines Teils der Belege - Buchen über ASR - Speichern im RZ - Verarbeitungslauf abwarten ("Maschine" lernt) - Upload weitere Belege - Buchen über ASR (Maschine wendet das bisher Gelernte an und lernt weiter) - Speichern im RZ - Verarbeitungslauf abwarten - Upload weitere Belege -Buchen über ASR ("Maschine" erkennt weitere Muster, lernt weiter und wendet das Gelernte immer besser an) - Speichern im RZ - Upload weiterer Belege usw.
Ja genau, so habe ich mir das vorgestellt. Fehler gestern war, dass zunächst alle Belege nach UO geladen und gespeichert wurden, das streckt natürlich die Lernphase ungemein.
Im Prinzip sind die Buchungszyklen von Beginn bis RZ-Versendung möglichst kurz zu halten.
Nun werden wie hier mal den Monat auf kleinere Stapel (Oktober I, Oktober II . . .) verteilen, da wir ja möglichst schnell anlernen wollen.
Danke nochmals für den Support. Hat mir viel Zeit erspart und komme vollends klar 🤜🤛 . Bin sehr gespannt, wie sich das nun entwickelt, sodass wir da ab Januar 2023 flächendeckend umstellen können.
Auszug aus: DATEV Automatisierungsservice Rechnungen (Überblick) - DATEV Hilfe-Center
... danke @deusex ,
das verlinkte Dokument ist hilfreich und ist auch mit 'humaner' anstatt mit 'künstlicher' Intelligenz gut lesbar und verständlich und beantwortet vorauseilend die Fragen, die ich vorher gestellt hatte 🙂
P.S.
ich gebe zu, dass ich eine latente Allergie gegen den Begriff 'künstliche Intelligenz' habe
Ich finde den Automatisierungsservice eigentlich gut. Leider erkennt er aber nicht alle Adressaten. Wenn dort "c/o" steht, wird die erste (für mich wichtige) Zeile ignoriert und ist nicht gelb markiert. Gibt es da eine Einstellungsmöglichkeit oder muss man etwas beim Anlegen von Kreditoren und Debitoren beachten?
Hallo,
ich lasse das mal wieder aufleben, wie sind denn die neuesten Erfahrungen hierzu?
ich habe das bei einem "Standart-Mandanten" laufen der 90% normalen Wareneinkauf hat, da klappt das relativ gut.
Ich betreue aber sehr viele Gastro-Mandate, klappt das mittlerweile mit er Aufteilung in 7% und 19% Ware?
ich hab eher angst das dann alles total durcheinander ist, ich hab eh schon das Problem das er den ganzen Biereinkauf auf Pacht bucht, weil dort die Brauerei eben auch die Pacht will...
LG
Hallo,
wir bzw ich teste es seit Juni an einem meiner größeren Mandate. Dieser lädt täglich in DUo seine ER (zwischen 10 und 30) hoch. Es sind nicht nur ER von deutschen Lieferanten/Geschäftspartnern. Ganz besonders stört es mich, dass bei einem Geschäftspartner (wöchentlich um die 10 RG) grundsätzlich die Landeswährung die klein und in Klammern unter dem Eurobetrag steht erkannt wird. Bei der Vielzahl an Rechnungen wird auch nicht nur einmal im Monat gebucht, ich versuche spätestens jeden zweiten Tag den Bestand an vorhandenen Rechnungen abzuarbeiten.
Hat jemand eine Idee wie ich dieses Problem in den Griff bekommen kann? Ja die Daten werden ins RZ gesendet.
Ich würde mich mal aus dem Fenster lehnen und behaupten, die Aufteilung, als auch die Trennung von Pacht und Wareneinkauf müsste der ASR hinbekommen. Ich habe den gleichen Fall mit 0,00 und 19,00 % USt, das funktioniert.
Was nicht funktioniert ist die Differenzierung zwischen Gutschriften (Provisionen) und Aufwendungen, wenn diese vom gleichen Lieferanten kommen. Hier wird dann alles durcheinander geworfen ohne ein für mich erkennbares System. Und ja, die Daten werden seit über 3 Monaten zurück ins RZ gesendet.
@andreashofmeister schrieb:Von Interesse wäre evtl. wie ASR als Produkt grundsätzlich vom Markt angenommen wird. Wenn nämlich eine Vielzahl von Anwendern aus eben diesen Gründen der Preisfindung darauf verzichten, muss DATEV das ganze ja attraktiver ausgestalten.
Der Aspekt von Ihnen, @deusex , wäre ja durchaus ein "Instrument", um das am Markt zu platzieren....
🤣Hatte mich gerade gewundert weil ich mich verlesen hatte:
....vom Markt genommen wird.
Immer von Vorteil wenn man lesen kann und dann auch richtig liest.
Hallo @fruchtzwerg ,
eine Aufteilung nach Steuersätzen mit 7% und 19% ist bereits seit der Jahreswechselversion 2022 möglich.
Hallo @Wuppergirl ,
dass der Betrag falsch vorgeschlagen oder nicht erkannt wird könnte daran liegen, dass zwar auf dem Beleg mehrere Steuersätze angegeben sind, der Steuersatz aber ohne Betrag vorhanden ist.
Um die genaue Ursache zu finden, bitten wir Sie sich in unserem Service zu melden.
Dann können sich Kolleg:/innen sich Ihren Fall ansehen und prüfen, woran es liegen könnte.
Hallo,
→ Ein Kollege bucht Rechnungen mit 7% und 19% und die automatische Aufteilung klappt dort sehr gut.
zu meiner Anfrage gab es leider noch keine Antwort und somit funktioniert die automatische Vorbelegung der Kreditoren bei mir leider immer noch nicht und ich muss alles manuell abändern.
meine damalige Anfrage (vllt weiß ja jetzt jemand mehr):
"Ich finde den Automatisierungsservice eigentlich gut. Leider erkennt er aber nicht alle Adressaten. Wenn dort "c/o" steht, wird die erste (für mich wichtige) Zeile ignoriert und ist nicht gelb markiert. Gibt es da eine Einstellungsmöglichkeit oder muss man etwas beim Anlegen von Kreditoren und Debitoren beachten?"
Hallo Frau Lindt,
ich habe an keiner Stelle etwas über Steuersätze geschrieben. Mir geht es um den Eurobetrag und die Landeswährung. Ich habe den Sachverhalt mal verkürzt (nur der untere Teil der betreffenden ER) eingefügt.
Der Automatisierungsservice erkennt grundsätzlich nur den Betrag in Klammern. Sorry für die Darstellung, ging leider nicht anders. 😇
Curs 1 EUR = 4.9675 Lei In cazul neplatii facturii la termenul scadent se percep penalitati calculate de 0.5% pe zi intarziere. |
| ||
Intocmit de: CNP: - Numele delegatului: POSTAL B.I/C.I: - Mijloc transport: - Expedierea s-a efectuat in prezenta noastra la data de ....................ora......... Semnaturile: | Total | 620.00 EUR (3079.85 Lei) | 0.00 EUR (0.00 Lei) |
Total plata |
| 620.00 EUR (3079.85 Lei) | |
Semnatura de primire: |
|
Termen plata: 09/11/2023
@Wuppergirl Warum nicht in Fremdwährung erfassen und die Differenzen als Währungaufwand/erlös buchen?
Sehe da kein Problem.
Weil die Rechnungen immer 620 € betragen. Wenn ich den Ansatz Landeswährung nehme, müsste ich auch alle polnischen Rechnungen in Landeswährung verbuchen. Bei den Eingangsrechnungen habe ich aber keine Probleme. Es betrifft zu 99,9 % nur die Rechnungen aus Rumänien. Unter WKZ finde ich auch kein Kürzel für die Rumänische Währung.
Das können Sie einstellen. In die Währungstabelle gehen (Kanzlei Rewe /Extras/ Fremdwährung/ Wähurngstabelle
und den entpsrechenden Klick bei Rumänischen LEU Neu setzen.
Danke für den Hinweis wo ich es finde.
Klingt jetzt vielleicht doof, aber es steht bei den betreffenden Rechnungen grundsätzlich der Eurobetrag drauf, ich nutze den Automatisierungsservice und dann erwarte ich auch, dass das Programm dieses auch korrekt umsetzen kann. Wie schon vorher geschrieben es ist nicht nur eine Rechnung im Monat, es sind eine Vielzahl an Rechnungen dieses einen Lieferanten/Geschäftspartners. Mir erschließt sich auch nicht, warum ich aus einer Buchung dann eben zwei machen soll, denn das wäre die Konsequenz aus der Buchung in Fremdwährung. 😉
Ich hoffe niemand nimmt meine Antwort jetzt als Angriff auf.
Automatisierungsservice bedeutet für mich "Erleichterung"/effektiveres arbeiten, ist aber eben dann nicht gegeben.
Der größte Irrglaube im Zusammenhang mit einer KI ist, dass sie die allergrößten Probleme lösen wird. In Wahrheit kann eine Automatisierung immer nur bei sich wiederholenden "Standards" unterstützen und einem damit Zeit für die Bearbeitung komplexer Sachverhalte verschaffen.
Ihre Belege werden von der OCR nicht wie gewünscht ausgelesen. Damit ist das
Mandat schlicht nicht für den Automatisierungsservice Rechnungen geeignet.
Kein Problem und das gilt mit Sicherheit auch für @bodensee ...
Die zweite Buchung für die Währungsdifferenz würde das System ja, Ausnahmen bestätigen die Regel, automatisch machen... Aber ja den Gedanken, dass die Kiste es lernen sollte kann ich voll und ganz nachvollziehen.
@eliansawatzki KI-System knackt Knotentheorem - Lernfähiger Algorithmus bringt die theoretische Mathematik voran - scinexx.de
KI kann mehr als Standardwiederholungsaufgaben.
Ja genau. Und ein Auto kann mehr als 250 km/h fahren.
https://www.auto-motor-und-sport.de/tuning/schnellstes-strassenauto-der-welt-300-mph-500-kmh/
Oder wäre der Vergleich mit Thrust2 aufschlussreicher?
@eliansawatzki ab wann gibt es bei Ihnen wiederholenden Standard? Ich rede bzw. schreibe hier nicht von 5 Rechnungen dieses einen Geschäftspartners im Zeitraum 01.01. bis heute, sondern von 5 bis 10 in der Woche. Dieses Mandat umfasst im Monat knapp 900/1000 Buchungen, sprich es ist kein 08/15 Mandant. Bei allen anderen ausländischen Geschäftspartnern funktioniert es, nur eben nicht bei den Rumänischen.
Ich meine mit meiner Erläuterung gleiche für die OCR erkennbare Inhalte eines Beleges und gleiche Reaktion darauf (gleiches Buchungsverhalten) .
Wenn die OCR nicht das gewünschte erkennt ist die Belegstruktur schlicht nicht geeignet. Damit ist das Mandat raus. Ist einfach so.
Wenn 1.000 mal der gleiche Stempel über den Betrag gemacht wurde, wird die OCR dennoch niemals den Betrag erkennen.