Hallo Community,
kann mir jemand sagen, wie ich die Erkennung der Rechnungsnummern / OP-Zuordnung optimieren kann?
Zum Beispiel habe ich eine Sparkasse, welche ich über den ISWL Konverter umwandle und dann über Buchungsvorschläge bearbeite.
Meine Rechnungen sind über Debitoren gebucht und haben eine Nummer mit "RE12345" - das funktioniert.
Dann habe ich aber auch Belege, die aufgrund der Masse auf seinem Sammel-Kreditor stehen und die Belegnummern beginnen mit "EK12345". Das funktioniert leider überhaupt nicht, obwohl im Verwendungszweck genau diese Nummern angegeben sind.
Mir wurde mal gesagt, dass es besser erkannt wird, wenn im Vwz ein "RE" reingepackt wird, also habe ich das entsprechend in meiner selbstkreierten Excel-Umwandlungsdatei mit reingezaubert. Leider hat das nichts gebracht.
Hat jemand noch einen Tipp für mich?
VG, Nina
@NinaJ haben sie hier schon einmal mit den Lerndateien probiert eine bessere "Vorkontierung" zu erhalten?
Nein, aber würde Lerndatei nicht bedeuten, "er" bucht mir immer auf das gleiche Konto... das möchte ich eigentlich nicht, er soll einen besseren OP-Abgleich machen.
Ich verstehe nur nicht die Erkennungslogik.
Ich buche eine Rechnungsnummer "EK12345" und im Vwz steht "EK12345" - dann hat er ja ein eindeutiges Merkmal, aber er checkt es nicht...
Ja, das ist ja in dem Fall der einzige Vorteil. Somit fällt meine Idee weg.
Sie können die KI hier nicht weiter beeinflussen, da die RG Nummer so lt. DATEV Logik gefunden werden sollte.
Ein weiteres manuellen Eingreifen ihrerseits geht hier leider nicht.
Also ich habe noch etwas gefunden im Dokument https://apps.datev.de/help-center/documents/1036446
"In Ihrem DATEV-Rechnungswesen-Programm laufen dabei automatisch folgende Schritte ab:
3. Angaben im Verwendungszweck suchen
Kundennummer mit der Debitoren- oder Kreditoren-Nummer (exakte Übereinstimmung) "
Das habe ich versucht, aber es funktioniert nicht. Es nervt einfach nur. Manche Sachen funktionieren echt gut. Aber das hier...
ER hat die RG-Nr., das Personenkonto, den Betrag und Name / Buchungstext und bringt mir trotzdem das blöde rote Zeichen.
sie spielen ja buchungsstapel ein wenn sie über ISWL Beleg2Buchung gehen. Dann kann man nicht vom Beleg buchen oder lernen lassen, sondern nur die Lerndatei trainieren. wenn hier kein eindeutiges Konto zugeordnet werden kann, schlagen sie somit das system.
Hallo mapex,
also sucht das System in erster Linie nach einem Geschäftspartner und gleicht dann alle anderen Merkmale ab (RG-Nr., Betrag, ...)?
Und dann funktioniert es nicht nur wegen meinem Sammel-Kreditor? Ansonsten hat er ja aus der Bank viele Informationen, mit denen er einen OP-Abgleich durchführen könnte.
Sorry, ich verstehe es noch nicht so richtig.
ich hoffe auch dass ich ihr problem richtig verstehe, aber ich kenne das so:
wenn man stapel einspielt, dann kann das programm nur "lernen" über die lerndatei, weil sie ja buchungssätze und nciht belege oder belegbilder einlesen. ein auslesen, des belegs geschieht beim einspielen von stapeln nicht.
und wenn das bei ihnen so ist, dann müssten sie, um größtmögliche zuordnung zu erreichen, die sammelkonten für personenkonten abschaffen. das gleiche problem gibt es ja bei unternehmen online, wenn man bei erweitert die stapel einspielt. wenn ich mehrere kunden oder lieferaten einem sammelkonto zuordne, dann kann das programm nie lernen, was genau zutrifft.
und so wie ICH es aus ihren ausführungen verstehe (ich hoffe ich habe das problem richtig verstanden) liegt es wohl daran, dass bestimmte parameter beim erzeugen der buchungsvorschläge nicht greifen. meines erachtens muss hier die lerndatei optimiert werden. denn bei ihnen spielen sie anscheinend nicht die rechnungen als buchungsvorschläge, sondern die bank ein. irgendeine abfrage in der lerndatei erfasst die vorschläge nicht eindeutig und lässt mehrere optionen zu. da würde ich zunächst auf sammelkonten tippen. könnte aber auch was anderes sein.
Hallo mapex, danke für die Antwort.
Ja ich spiele die Umsätze aus der Bank ein. Das funktioniert, über ein paar Umwege, auch recht gut.
Dann müsste ich mir überlegen, wie ich diese vielen Einmal-Geschäftspartner auf mehrere oder einzelne Kreditoren bekomme? (-> das wird in dem Fall unmöglich sein, also muss ich wohl damit ... arbeiten ...)
Ich verstehe nur nicht, warum das Programm sich dann vermutlich beim Abgleich nur auf den Namen des Geschäftspartners konzentriert, und nicht auf die vielen anderen Merkmale, mit denen er ja gefüttert wurde...
Sorry, ich habe vorher mit einem anderen Programm gearbeitet...
Sorry, ich habe vorher mit einem anderen Programm gearbeitet...
Welcome to DATEV.
Die Forderungsbuchungen bekommen sie aus dem Vorsystem des Mandanten? Sie schreiben Eingangs, dass die Belegnummern mit EK beginnen würden und Probleme machen.
Vielleicht ist auch möglich dem Vorsystem beizubringen, dass ein Wert welcher durch das System erkannt wird ins Belegfeld kommt? EK steht wofür?
---------
Sie spielen Buchungsvorschläge ein? Sie könnten auch Buchungssätze importieren.
Voraussetzung sind zwei sauber getrennte Bankkonten.
Eines für die Zahlungseingänge eines für alles Andere.
Das Zahlungseingangskonto schleust man durch ein Makro welches an Hand der überweisenden IBAN die Einmalkunden auf das Sammelkonto 10001, Mehrfachkunden auf das individuelle OPOS Konto "bucht".
Wenn dann im Belegfeld 1 die gleiche Zeichenreihenfolge wie in der Forderungsbuchung steht kann man automatisch ausziffern lassen.
Das zweite Konto simpel via Buchungsvorschlag.
In Leicht abgewandelter Form buchen wir für einen Mandanten tausende KK Umsätze im Monat.
wenn @ archilleus nun noch hier wäre könnte der sicher den Makrotext aus dem Hut zaubern.
... nur ein kurzer Hinweis:
... seit ich monatlich auch immer wieder die Debitoren-/Kreditoren-Stammdaten als Stapel in REWE einspiele, klappt es sehr viel besser mit OPOS, im Gegensatz zu vorher (mit Debitoren-/Kreditoren-Sammelkonten)
Wenn das Warenwirtschaftssystem diese Stapel exportieren kann, sind es nur wenige Klicks bis zum breiten Grinsen 😁
... jetzt haben wir in den entsprechenden REWE-Beständen eben Tausende von Debitoren und Kreditoren, aber wen juckt das ? mich nicht ... 😎
Hallo jjunker,
danke vielmals 😄
Also die Variante mit den getrennten Banken klingt sehr interessant, aber dazu müsste man den Mandanten erstmal "rumkriegen".
Ja, ich bekomme Daten in xls vom Mandanten über Ankäufe, welche ich kreditorisch buche - diese werden von unterschiedlichen Zahlungsmittelkonten bezahlt.
Das EK steht für das Einkaufsprotokoll. Also meinen Sie, dass eine Änderung der Bezeichnung (EK in RE / RG) Abhilfe schaffen könnte? Dann wäre das für mich im neuen Jahr auszuprobieren.
Komischerweise schafft mein PayPal-Konto, welches als Bankkonto getarnt ist, den Abgleich wunderbar. Und da habe ich auch nur EK12345 im Vwz.
Hallo vogtsburger,
Warenwirtschaftssystem bleibt Wunschvorstellung 😕
Nachtrag:
aber Sie haben Recht, tausende Einmal-Konten würden mich jetzt auch nicht so sehr stören...
Ich habe bei meinen Umsätzen in meiner Excel-Datei einen S-Verweis angelegt, so dass er die Kunden ganz gut findet und die Debitoren-Nr. schon zuordnet. So könnte ich das bei meinen Kreditoren auch machen. Wäre ein Projekt.
Hallo @NinaJ
für die Zuordnung von Bankbuchungsvorschlägen zu offenen Posten ist es unerheblich, ob Sammeldebitoren /-kreditoren verwendet werden, solange im Verwendungszweck des Kontoumsatzes eine Rechnungsnummer erkannt wird, die im Belegfeld 1 einer Rechnung erfasst wurde. Es ist also nicht notwendig, die Sammelkonten abzuschaffen.
Bezüglich der Erkennung der EK-Nummern würde ich mir Ihren konkreten Fall gerne gemeinsam mit Ihnen ansehen. Senden Sie bitte einen Servicekontakt an den Programmservice Rechnungswesen und geben Sie die Kontakt-ID 55319816 an. Ich melde mich dann bei Ihnen.
... die Debitoren-/Kreditoren-Stapel sind ziemlich 'einfach gestrickt'
Wenn Sie mit so komplizierten Excel-Funktionen arbeiten, müsste die Erzeugung von solchen Stapeln auch funktionieren, zur Not eben als ASCII-Datei.
... habe das Datev-Tool "EBS Konvertierung" für diesen Zweck noch nicht eingesetzt .... könnte aber auch klappen
... interessiert mich, ob Sie eine Lösung finden ...
@Antje_Naumann schrieb:
... für die Zuordnung von Bankbuchungsvorschlägen zu offenen Posten ist es unerheblich, ob Sammeldebitoren /-kreditoren verwendet werden, solange im Verwendungszweck des Kontoumsatzes eine Rechnungsnummer erkannt wird, die im Belegfeld 1 einer Rechnung erfasst wurde. Es ist also nicht notwendig, die Sammelkonten abzuschaffen...
... umso besser, wenn das so ist bzw wenn es so wäre ..
... man schafft die Sammelkonten ja nicht 'zum Spaß' ab, sondern nur aus der Not heraus und auf der Suche nach einer Lösung
... die genaue Logik des OPOS-Ausgleichs, der Buchungsvorschläge, der Lerndatei, der Zahlungsinformationen, der Datev-OCR usw. ist (für mich) nur schwer zu durchschauen.
Nachtrag:
... also werde ich mal bei nächster Gelegenheit und bei ausreichender eigener Risikobereitschaft den Spruch "never change a running system" missachten und die neuen Debitoren-Kreditoren-Stapel zum Test nicht importieren und gucken, was passiert oder nicht passiert 😁
Lösung:
(wie könnte es anders sein, ist die Lösung super simpel)
in meinem Vwz steht die "EK12345" und nachfolgender Text ohne Leerzeichen
Frau Naumann erklärte mir, dass das Programm schon nach meinen Zeichenfolgen sucht: zwei Buchstaben fünf Ziffern - und dann kann er nicht aufhören zu lesen, weil der Text einfach weitergeht
also in der Datei über suchen + ersetzen noch ein Leerzeichen eingefügt
Das wird mir eine Leere sein! haha
danke an alle und guten Rutsch
@NinaJ schrieb:
(wie könnte es anders sein, ist die Lösung super simpel)
in meinem Vwz steht die "EK12345" und nachfolgender Text ohne Leerzeichen
Frau Naumann erklärte mir, dass das Programm schon nach meinen Zeichenfolgen sucht: zwei Buchstaben fünf Ziffern - und dann kann er nicht aufhören zu lesen, weil der Text einfach weitergeht
In meinen allerersten Programmierkurs (Computerlinguistische Programmierung für Perl / Einführung) haben wir gelernt, wie man sowas vernünftig implementiert. Anfängerwissen quasi. 🤔🙈