abbrechen
Suchergebnisse werden angezeigt für 
Stattdessen suchen nach 
Meintest du: 

Warum werden Leerzeichen nicht automatisch bereinigt beim Kopieren in Belegfeld?

7
letzte Antwort am 12.11.2020 12:12:32 von Gelöschter Nutzer
Dieser Beitrag ist geschlossen
0 Personen hatten auch diese Frage
Gelöschter Nutzer
Offline Online
Nachricht 1 von 8
572 Mal angesehen

Hallo DATEV,

 

warum werden bei kopierten Werten aus dem Bereich Kontoumsatz, die im Buchungssatz im Belegfeld1 eingefügt werden sollen?

 

Wenn keine Leerzeichen geduldet werden, was ich ja akzeptiere, aber warum werden dann die Leerzeichen nicht automatisch gelöscht?

 

grafik.png

 

Beispiel:

kopiert → [ ]123456 7890[ ]

eingefügt (Trim()) = 123456%7890

 

Gebt das doch einmal an Eure Programmierabteilung weiter. Die kennen bestimmt noch nicht den VBNet-Code dafür.

 

 

 

Sub test()
    Clipboard.SetText(" 123456 7890 ") 'Clipboard für Testzwecke)
    TextBoxBelegfeld1.Text = Clipboard.GetText.Trim.Replace(" ", "%")

    'Result = 123456%7890
End Sub

 

 

 

Das würde die Arbeit doch ganz erheblich vereinfachen und diese simple Codezeile sollte nun wirklich kein Problem sein, oder?

 

Wäre schön, wenn ich das noch erleben dürfte! 🤔


Gruß Achilleus

DATEV-Mitarbeiter
Natalie_Bauer
DATEV-Mitarbeiter
DATEV-Mitarbeiter
Offline Online
Nachricht 2 von 8
516 Mal angesehen

Hallo @Gelöschter Nutzer ,

 

können Sie uns bitte beschreiben, in welchem Szenario Sie Inhalte aus dem elektronischen Beleg händisch kopieren und in Belegfeld 1 einfügen möchten?

Was genau möchten Sie in diesem Fall in Belegfeld 1 übernehmen?

 

 

Mit freundlichen Grüßen

 

Natalie Bauer

Business Analyst Finanzbuchführung
DATEV eG

Freundliche Grüße aus Nürnberg
Natalie Bauer | Business Analyst Produktangebot | DATEV eG
0 Kudos
quantenjoe
Erfahrener
Offline Online
Nachricht 3 von 8
498 Mal angesehen

Moin Frau Bauer

 

Ich bin mir nicht sicher, ob das folgende wirklich hierher gehört, da es im Ausgangspostung wohl eher um das ersetzen eines Leerzeichens ging.

 

Ich habe es, dass Mandanten im Belegfeld1 gerne etwas reinschreiben, das der Datev-Import so nicht mag. Man kann es ignorieren, dann sieht Belegfeld1 eben etwas anders aus, tut aber niemanden weh. Gibt halt beim Einspielen der Daten einen gelben Vermerk, doch wen stört das. OK, der Buchungsstapel wird deswegen nicht festgeschrieben. Ist sicherlich von der GoBD nicht so gewollt, kann dem STB aber helfen.

 

Aber eigentlich könnte das doch einfach unterbunden werden, indem Belegfeld1 einfach als String deklariert wird und entsprechend alle Zeichen darin einfach übernommen werden. Ich sehe nicht warum dies nicht erlaubt sein sollte.

 

BTW, was ich (ok, kein Buchhalter, sondern Admin) auch nicht verstehe, warum Belegfeld2 sich quasi immer, wenn da was drin steht über seinen Inhalt mokiert. ES wirkt auf mich so, als ob nur eine ganz bestimmte Formatierung und ganz bestimmte Zeichen erlaubt sind. Wenn es dafür einen rechtlichen Grund gibt, würde ich diesen gerne wissen - allein schon um Mandanten darüber zu informieren, damit wir bessere Daten bekommen. Wenn es keinen Grund gibt, warum nicht die Beschränkung aufheben?

 

QJ

Gelöschter Nutzer
Offline Online
Nachricht 4 von 8
491 Mal angesehen

Hallo Frau @Natalie_Bauer,

 

wie Sie aus meinem Eingangspost entnehmen können, kommt es oft vor, dass ich aus dem elektronischen Bankauszug eine Belegnummer herauskopiere. Hier es nun echt schwierig, die Belegnummer ohne Leerzeichen herauszufingern. Auch ist es schwierig, bzw. sogar gar unmöglich, wenn in der Belegnummer ein Leerzeichen enthalten ist.

 

grafik.png

 

Wenn ich, wie markiert (s. roter Rahmen), diese Belegnummer jetzt kopieren möchte, muss ich exakt ohne Leerzeichen markieren und in das Belegfeld 1 hineinkopieren. Schlimmer wird es noch, wenn die Belegnummer wie folgt lauten würde: 100 117 904

 

Diese Nummer ist nun überhaupt nicht mehr kopierbar. Bei einer kurzen Nummer ist das noch tolerierbar, aber wenn es sich z. B. um die Code-Nr. von Amazon oder Transaktionscode von PayPal handelt, ist das eine echte Katastrophe.

 

Daher mein Wunsch, dass DATEV beim Einfügen automatisch die voran- und nachstehenden Leerzeichen per Trim-Befehl entfernt und die dazwischen liegenden Leerzeichen ebenfalls, wie beim Import, mit dem Ersetzungszeichen % austauscht.

 

Den entsprechenden VBNet-Kurzbefehl habe ich schon gepostet.

 

Da beim Einfügen schon eine Überprüfung auf Leerzeichen existiert (es kommt ja eine Fehlermeldung), ist es für mich unverständlich, warum nicht gleich automatisch die Leerzeichen entfernt werden.


Gruß Achilleus

 

Nachtrag:

 

Es kommt sehr oft vor, dass ich Zahlungen über PayPal erhalte und diese auf ein Kreditor buche und erst im Nachhinein die Rechnung erhalte. Damit aber die Posten nicht auf 0 gerafft werden, und um auch die Identifizierung/Suche zu erleichtern, kopiere ich den Amazon-Code bzw. PayPal Transferticketcode in das Belegfeld 1.

 

Generell ist es aber völlig unerheblich, warum ich etwas mache. Die Frage ist, warum DATEV es nicht bewerkstelligen kann.


Gruß Achilleus

Gelöschter Nutzer
Offline Online
Nachricht 5 von 8
475 Mal angesehen

Nachtrag:

 

Bevor sich die DATEV auf die Leerzeichen stürzt, das Gleiche gilt natürlich auch für alle anderen verbotenen Zeichen (Leerzeichen, Umlaute, Punkt, Komma, Semikolon und Doppelpunkt).

 

Das natürlich mit VBNet auch ganz einfach realisierbar:

 

Sub test()
    Clipboard.SetText(" 123456 7890.456 ") 'Clipboard für Testzwecke)
    TextBoxBelegfeld1.Text = Clipboard.GetText.Trim.Replace(" ", "%").Replace(".","-")...

    'Result = 123456%7890-456
End Sub

 


Gruß Achilleus

0 Kudos
DATEV-Mitarbeiter
Natalie_Bauer
DATEV-Mitarbeiter
DATEV-Mitarbeiter
Offline Online
Nachricht 6 von 8
450 Mal angesehen

Hallo zusammen,

 

danke für Ihre Erläuterungen. Für uns ist es definitiv wichtig, zu verstehen, in welchem Kontext Sie darauf angewiesen sind, händisch Informationen aus dem elektronischen Beleg zu kopieren, um auch nachvollziehen zu können, wo tatsächlich der Bedarf liegt und welchen Mehrwert z.B. die Umsetzung einer solchen Funktion für andere Anwender bzw. Nutzungskontexte haben könnte. Sie haben ja als Beispiel PayPal und Amazon angesprochen. Gerade im E-Commerce sollte ja das Ziel sein, dass die Zahlungsdaten so übernommen werden, dass sie automatisch zu den offenen Posten zugeordnet werden und wiederkehrende Geschäftsvorfälle mithilfe von Lerndateien vervollständigt werden, sodass die Buchungsvorschläge automatisch durchgebucht werden können.

 

Sie haben recht, sobald man am Anfang oder am Ende einer Belegnummer ein Leerzeichen mitkopiert, kann man die Belegnummer nicht mehr in das Belegfeld 1 einfügen. In diesem Kontext macht es Sinn, die Leerzeichen am Anfang und/oder am Ende abzuschneiden.


Eine Belegnummer mit Leerzeichen (Ihr Beispiel war ja 100 117 904) mit einem Sonderzeichen o.Ä. aufzufüllen (Ergebnis wäre dann ja z.B. 100-117-904) oder aktuell nicht zulässige Sonderzeichen durch zulässige Sonderzeichen zu ersetzen, halte ich jedoch für problematisch.

Angenommen, wir würden eine solche Funktion implementieren. Sie würden dann eine Belegnummer in der Rechnungsbuchung (z.B. 100 117 904) übernehmen und das Programm diese automatisch umwandeln (z.B. 100-117-904). Wenn der Kunde/Lieferant bei der Zahlungsbuchung anschließend auch die ursprüngliche Belegnummer (z.B. 100 117 904) z.B. im Verwendungszweck erfasst, könnte das Programm die Zahlung nicht mehr dem offenen Posten zuordnen. Hierfür müssen die in der Rechnungsbuchung erfasste Belegnummer und die im Verwendungszweck erfasste Belegnummer übereinstimmen. 


Ihr eigentlicher Wunsch, in Belegfeld 1 Sonderzeichen und Leerfelder übernehmen zu können, ist in jedem Fall nachvollziehbar. Das Belegfeld 1 kann jedoch nicht einfach als String deklariert werden, da es der Schlüssel für den OPOS-Ausgleich ist. Da eine solche Funktion umfangreiche Änderungen in mehreren Programmteilen nach sich ziehen würde, kann ich einen Umsetzungszeitpunkt aktuell nicht garantieren.

 

Mit freundlichen Grüßen

 

Natalie Bauer

Business Analyst Finanzbuchführung

DATEV eG

Freundliche Grüße aus Nürnberg
Natalie Bauer | Business Analyst Produktangebot | DATEV eG
0 Kudos
DATEV-Mitarbeiter
Natalie_Bauer
DATEV-Mitarbeiter
DATEV-Mitarbeiter
Offline Online
Nachricht 7 von 8
448 Mal angesehen

Hallo @quantenjoe ,

 

hier nur kurz noch eine Antwort zum Thema Belegfeld 2. Die weiteren Erläuterungen finden Sie im Post unten.

 

Das Belegfeld 2 wurde für die OPOS-Buchführung konzipiert und dient dazu, für einen Buchungssatz zusätzliche Angaben zur Fälligkeitsermittlung oder zur Banksteuerung im Zahlungsvorschlag erfassen zu können. Daher wird bei Aus- und Eingangsrechnungen ein bestimmtes Format in Belegfeld 2 erwartet.

 

Bei Zahlungseingängen und -ausgängen oder sonstigen Buchungen kann eine beliebige, bis zu 12 Stellen lange Belegnummer erfasst werden.

 

Mit freundlichen Grüßen

 

Natalie Bauer

Business Analyst Finanzbuchführung

DATEV eG

Freundliche Grüße aus Nürnberg
Natalie Bauer | Business Analyst Produktangebot | DATEV eG
0 Kudos
Gelöschter Nutzer
Offline Online
Nachricht 8 von 8
434 Mal angesehen

Hallo Frau @Natalie_Bauer,

 

vielen Dank für Ihre umfangreichen Erläuterungen.

 

Dennoch muss ich widersprechen.

 

1. Beim ASCII-Import werden die Leerzeichen/Sonderzeichen automatisch bereinigt bzw. ersetzt.

 

2. Bei einer Eingangsrechnung, die Leerzeichen enthält, muss ich diese doch auch händisch berichtigen (=DATEV-konform). Wird jetzt diese Rechnung gezahlt und im Überweisungstext wird die Originalrechnungsnummer mit Leerzeichen verwendet, kann DATEV diesen eh nicht finden, da

 

123-456-789 <> 123 456 789

 

ist.

 

Ich kann also Ihrer Logik nicht folgen, warum die Sonderzeichen nicht automatisch ersetzt werden sollen/können.

 

3. Warum wird eine Prüfung auf ordnungsmäßige Rechnung schon beim Einfügen (Strg+V) und nicht erst beim Absprung des Belegfeldes gemacht? So kann der Anwender zwar eine kopierte unzulässige Belegnummer einfügen, aber eben nicht speichern. Er muss diese dann zumindest von Hand berichtigen. Dennoch hat er zumindest schon einmal die Rohdaten im Feld und das ist erheblich einfacher, als wenn ich eine Nummer (z. B. 48L 62685U 69710719) von Hand erfassen muss.

 

Ich bitte also darum, dass Sie noch einmal Ihre Argumentation überdenken.


Gruß Achilleus

7
letzte Antwort am 12.11.2020 12:12:32 von Gelöschter Nutzer
Dieser Beitrag ist geschlossen
0 Personen hatten auch diese Frage