Verwendungszweck und Empfänger

1. offizieller Beitrag

    Alle Banken liefern ein VWZ-Feld mit 140 Zeichen, ggf. mit Zeilenumbrüchen bzw. die HBCI-Schnittstelle addiert ggf. nach jeweils 28 Zeichen einen Zeilenumbruch.
    Dh. ZiffernKolonnen werden an willkürlicher ZifferPosition umgebrochen (ggf. ZeilentauschRegel erzeugt damit fehlerhaftes Durcheinander).
    Man kann in einer Regel nur pro VWZ-Zeile einen Zeichenkette identifizieren, aber nicht über mehrere/alle Zeilen, dh. wenn man nach einer - ggf. umgebrochenen - ZiffernKolonne sucht, wird diese nicht gefunden.



    WisoMG sollte:
    1.1) aus dem VWZ beim Einlesen ggf. sämtliche enthaltenen Zeilenumbrüche entfernen.
    1.2) ein VWZ-Ziel-Feld bereitstellen welches länger, also zB. 2000 Zeichen lang ist (hiermit kann bei der ErsetzungsRegel die Warnung entfernt werden, dass beim Ersetzen ggf. die Feldlänge überschritten wird; Regeln sind dann weniger fehleranfällig=zuverlässiger/sicherer/korrekter).
    1.3) im Frontend beim Editieren keine max.Zeilenlänge (28Zeichen) mehr erzwingen (das Feld wird ja nie wieder an die Bank zurückgesendet und soll nach dem Einlesen für den Anwender frei editierbar und TextErsetzRegel-bar sein mit viel Platz)
    1.4) die Wiso-Regel sollte ein Steuerungszeichen bereitstellen, welches dem Anwender ermöglicht zB. TextErsetzen "SVWZ+ " ----- durch -----> Chr(13) & "SVWZ+") wobei Chr(13) für Zeilenumbruch steht.
    ProgrammierPseudoCode: update Buchung set Verwendungszweck1bis8 = replace([Verwendungszweck1bis8], Chr(13), "");



    Resultat:
    der Anwender kann sich endlich eine funktionnierende Regeln erstellen (aktuell taugen die Regeln nix, weil man keine Möglichkeit geben nach etwas zu suchen (es wäre ja zufällig dass die Zeichenkette in einer Zeile steht und eben nicht umgebrochen wurde "in EINER VWZ-Zeile einen bestimmten Text enthält").



    Empfänger:
    WisoMG sollte:
    2.1) den Empfänger grundsätzlich immer in Großbuchstaben wandeln, und Umlaute ersetzen (dito "ß" --- durch "SS").
    (nicht im Verwendungszewck, ausschließlich im Empfänger!)
    ProgrammierPseudoCode:
    update Buchung set Empfänger = upper([Empfänger]);
    update Buchung set Empfänger = replace([Empfänger], "Ä", "AE");
    update Buchung set Empfänger = replace([Empfänger], "Ö", "OE");
    update Buchung set Empfänger = replace([Empfänger], "Ü", "UE");
    update Buchung set Empfänger = replace([Empfänger], "ß", "SS");
    update Buchung set Empfänger = replace([Empfänger], " ", " ");
    update Buchung set Empfänger = replace([Empfänger], " ", " ");
    update Buchung set Empfänger = replace([Empfänger], " ", " ");
    update Buchung set Empfänger = replace([Empfänger], " ", " ");
    update Buchung set Empfänger = replace([Empfänger], " ", " ");

    dh. 2 aufeinanderfolgende Leerzeichen durch 1Leerzeichen ersetzen (mehrmals, sodass der Anwender einigermaßen sicher davon ausgehen kann dass er nicht viele Varianten mit mehreren Leerzeichen in seinen Regeln detektieren muss, denn der Absender/Bank trägt ggf. auch Mal mehrere Leerzeichen ein, es ist ein vom Überweisenden frei editierbares Feld welches nicht zwingend mit dem Kto-Inhaber übereinstimmen muss, zB. schreibt die netbank manchmal in den Empfänger(bzw.Auftraggeber): "Scheckeinlieferung" statt "NETBANK").


    Resultat: Der Anwender kann (er hat ggf. mehrere Banken, welche ggf. unterschiedlich bereitstellen) ohne über die Bank nachzudenken sich Regeln auf den Empfänger einfacher machen.

    2 Mal editiert, zuletzt von 3371998 () aus folgendem Grund: syntaktische Fehler korrigiert

    Gefällt mir 1

    ist zu langsam, noch umständlicher und noch mehr Bugs drin als in der MGclassic2015. Einige unverzichtbare Features gibts bei den Regeln nicht mehr.Es ist an vielen Stellen "verschlimmbessert" (keine professionellen .net-Programmierer).
    Die Anwender sind verzweifelt.
    Auch Quality-Kontrollen verlagert Buhl auf ein umfangreiches Riesenaufwand-Forum an Forums-Mitarbeiter, welche immer wieder dasselbe beantworten und seit Jahrzehnten nix tun können.
    Ich hatte dieselben Regel-Problematiken bereits vor über einem Jahrzehnt geschrieben, da kümmert sich keiner drum.


    Sind meine Verbesserungsvorschläge nun angenommen oder abgelehnt ?

    • Offizieller Beitrag
    Zitat von freelance

    ist zu langsam, noch umständlicher und noch mehr Bugs drin als in der MGclassic2015. Einige unverzichtbare Features gibts bei den Regeln nicht mehr.Es ist an vielen Stellen "verschlimmbessert" (keine professionellen .net-Programmierer).
    Die Anwender sind verzweifelt.
    Auch Quality-Kontrollen verlagert Buhl auf ein umfangreiches Riesenaufwand-Forum an Forums-Mitarbeiter, welche immer wieder dasselbe beantworten und seit Jahrzehnten nix tun können.
    Ich hatte dieselben Regel-Problematiken bereits vor über einem Jahrzehnt geschrieben, da kümmert sich keiner drum.

    Tut hier alles nichts zur Sache.


    Zitat von freelance

    Sind meine Verbesserungsvorschläge nun angenommen oder abgelehnt ?

    Woher soll ich das wissen? ?(
    Ich kann mir aber nicht vorstellen, daß derartige Entwicklungsarbeit, wie von Dir vorgeschlagen, noch in die Klassik-Version gesteckt wird.

    Hallo, ich muss diesen Thread hier nochmal aus der Versenkung holen, da er immer noch zu 1.000% zutrifft :thumbsup:


    @Buhl, bitte, genau die vom TE beschriebenen Funktionen wünsche ich mir auch um hier endlich einmal wieder einen vernünftigen VWZ erzeugen zu können.


    Selbst in der aktuellsten MG365-Version kommt mit der Einstellung "SEPA-Umsatzabfrage" und ohne Anwendung von irgendwelchen Regeln nur "zerhackter Müll" in MG im VWZ an.
    - Lieferant der Buchung ist (wie sollte es auch anders sein, natürlich) die Postbank :thumbdown:


    ... nur um es mal plastisch zu machen

    • so sieht die Buchung im Online-Portal der PB aus
    • und so stellt sich der VWZ in MG365 dar (wohl bemerkt, unbearbeitet)
    • und wenn man nur die Zeilenumbrüche entfernt kann man schon fasst nichts mehr lesen ;(

    Aus welchem Grund auch immer sind zwischen 1. und 2. zwei zusätzliche Zeilenumbrüche [CR][LF] hinzugekommen.- vielleicht wird es mit nachfolgende Darstellung noch deutlicher ...

    • ASCII des VWZ im Online-Portal der PB
    • ASCII des VWZ in MG365

    btw., irgendwie schafft es MG ja auch die Zeile 6 (s. Bild unter 1. ASCII) auszulesen und in den Auftraggeber-Namen einzutragen und im VWZ zu löschen.Warum dann nicht auch mit den anderen SEPA-Kennern, auch wenn die PB diese nicht mit GVC-Code-konformen Bezeichnern versieht !?


    Ich möchte dies ja gerne selber mittels Regel durchführen, aber genau dafür bedarf es der vom TE beschriebenen regular Expressions.
    Bitte Umsetzen !


    PS: Ich z.B. brauch den VWZ zwingend in vernünftig lesbare Form, da dieser über den Datenimport in den WISO-HV wandert :!:

    Komisch. Meine Bank liefert mit bei HBCI mit Chipkarte die Daten soweit, dass die SEPA-Details auch exakt in den dafür vorgesehenen Feldern auftauchen.


    Es sieht doch danach aus, dass dein Zahlungsdienstleister nicht in der Lage ist, diese Informationen ordentlich zu liefern. Du solltest also immer erst einmal mit denen reden und dort die Problematik ansprechen. Sicher wäre auch eine weitere Bearbeitungsmöglichkeit seitens MG evtl. hilfreich, doch sehe ich bei diesen Problemen immer erst einmal die Bank in der Pflicht.
    SEPA kennt nur eine einzige VWZ!

    Zitat von Falk1

    Komisch. Meine Bank liefert mit bei HBCI mit Chipkarte die Daten soweit, dass die SEPA-Details auch exakt in den dafür vorgesehenen Feldern auftauchen.

    hi Falk, glaub ich Dir. - ist aber sicherlich nicht die Postbank :(


    Zitat von Falk1

    Es sieht doch danach aus, dass dein Zahlungsdienstleister nicht in der Lage ist, diese Informationen ordentlich zu liefern

    genau das sehe ich auch so, aber die PB ist da irgendwie resistent.
    Ich hab mit den schon alles mögliche veranstaltet, um mal an eine kompetenten Kontakt zu kommen, mit dem man das Thema ausreichend erörtern könnte, aber das ist witzlos. Ich bin da nur Einer von 100.000den.
    Andererseits denke ich mir, dass ich hier mit Buhl einen Dienstleistungsvertrag abgeschlossen habe, von dem ich auch etwas mehr erwarten kann als solch einen Müll im VWZ, zumal sie ja mit der SEPS-Kompatibilität sogar bei der PB ihr Produkt bewerben.


    Fakt ist jedenfalls, dass der Buhl-Support den Fehler auf die PB schiebt, und die PB es genau anders herum auf die verwendete Banking-SW (in sofern also auf Buhl) schiebt.


    Andererseits lassen die SEPA-Spezifikationen genau an dieser Stelle aber eben auch die Freizügigkeit zu, die o. abgebildeten Informationen in dies VWZ-Feld zu schreiben.
    - das kann dann eben jede Bank halten wie sie will.


    Das aus der ja noch halbwegs lesbaren Online-Darstellung bei der PB dann aber in MG solch ein zerhackter Müll rauskommt, das schreibe ich dann aber ernsthaft Buhl zu.
    Und wenn die nicht bereit sind das wegen allgemeiner Standardisierung und Kompatibilität zu x anderen Banken anzupassen, dann sollen sie aber bitte doch die Werkzeuge dazu mitliefern, damit es jeder der es braucht und möchte selber machen kann!
    - die Implementierung von regular Expressions zwecks Verwendung in einer Regel ist ja nun wirklich kein Hexenwek.

    • Offizieller Beitrag
    Zitat von PCPeet

    - die Implementierung von regular Expressions zwecks Verwendung in einer Regel ist ja nun wirklich kein Hexenwek.

    Trotzdem erledigut es sich nicht von alleine und die Frage ist immer, wie viele Anwender das nützten würden. Das ist bekanntlich mit ein wesentlicher Faktor für die Priorisierung eines Vorschlages.

    Zitat von PCPeet

    die Implementierung von regular Expressions zwecks Verwendung in einer Regel

    Kannst du dies einem Laien auch einmal auf deutsch sagen? It-Denglish versteht nun einmal nicht jeder.


    Davon abgesehen: dieses Problem mit dem "komisch" übergebenen Verwendungszweck gibt es auch in anderen Finanzsoftwareprogrammen und bei einigen wenigen anderen Banken (z. B. Spardabank). Wenn du im Internet suchst, findest du hierzu eine Menge Einträge. Es liegt wohl doch nicht an Buhl ...

    Wobei man dann auch noch die Art des Zugangs unterscheiden muss. Wenn jemand unbedingt eine solche Bank (evtl. aus Kostengründen) wählt, ist das seine eigene Entscheidung. Er kann ja auch eine nutzen, die das korrekt (in seinem Sinne) macht, und dafür aber evtl. mehr zahlen muss. Man kann eben nicht alles haben.

    Zitat von nesciens

    Kannst du dies einem Laien auch einmal auf deutsch sagen? It-Denglish versteht nun einmal nicht jeder.

    Hi nesciens, was soll ich sagen ?!
    Das ist ein Begriff aus dem Programmierumfeld bzw. von DB-Abfragen.
    Prinzipiell hat es der TE (sorry, ThreadErsteller) in seinem Eingangs-Post ausreichend beschrieben.
    - ggf. schaust Du mal in der Wickipedia nach. Da ist es umfangreich beschrieben >> reguläre Entsprechungen / Ausdrücke in der IT.


    Vereinfacht ausgedrückt kannst Du damit nach allen möglichen Zeichen (auch Steuerzeichen oder Zeilenumbrüchen wie [CR][LF] = Carridge Return Line Feet und u. a. auch Wildcards wie [*] für mehrere unbestimmte oder [?] ein unbestimmtes Zeichen) suchen.


    Damit wäre es u.a. auch möglich eine Regel zu formulieren, mit der man z.B. definiert,
    - suche im VWZ nach dem Vorkommen "Referenz"
    - kopiere hinter "Referenz" alles bis zum [CR][LF], entferne alle darin enthaltenen Leerzeichen
    - und trage dies im SEPA-Feld "End to End ID" ein.
    - danach lösche im VWZ alles ab dem Vorkommen "Referenz" bis zum nächsten [CR][LF]


    ... und wenn keine [CR][LF] vorhanden sind, weil alles nur in einer Zeile kommt, dann nimmt man halt für die Selektion das 2. auftretende Leerzeichen.
    ... da gibt es dann unzählige Möglichkeiten.
    Prinzipiell machen die Entwickler hier mit den System-Regel nichts anderes ...


    ich hoffe das beantwortet Deine Frage.



    Zitat von Falk1

    Wobei man dann auch noch die Art des Zugangs unterscheiden muss.

    Hi Falk, was meinst Du genau damit ???

    Zitat von Falk1

    Wenn jemand unbedingt eine solche Bank (evtl. aus Kostengründen) wählt ...

    ... wobei die PB mittlerweile unverschämt teuer geworden ist!
    Hab ernsthaft bereits über einen Wechsel nachgedacht, aber nicht wegen der Kosten, sondern genau wegen dem hier beschriebenen Problem.
    - nur der Aufwand der Umstellung ist nicht wirklich unerheblich :(
    - und eigentlich bin ich Optimist und hoffe immer noch auf Besserung der hier diskutierten Situation :whistling:

    Ich nutze HBCI mit Chipkarte und Kartenlesegerät (eben den "grossen" von Reiner-SCT mit nPA-Signaturunterstützung) und habe da keine Probleme mit den Daten. Und hierbei auch wenig Probleme, was Änderung der Datenübermittlung angeht (typischerweise Screenparser am meisten betroffen). Und nebenbei bemerkt, ist das immer noch das sicherste Verfahren. Es wird nur von den Zahlungsdienstleistern nicht aktiv vermarktet ...


    SEPA ist schon ein paar Tage am Markt eingeführt. Da erwarte ich von den Banke, ohne Druck aus der Gesetzgebung, micht mehr viel. Btw. Die erste Auslandsüberweisung in SEPA-Codierung (IBAN + BIC) habe ich schon 2008 nach Spanien getätigt.

    Zitat von Falk1

    Ich nutze HBCI mit Chipkarte und Kartenlesegerät (eben den "grossen" von Reiner-SCT mit nPA-Signaturunterstützung) und habe da keine Probleme mit den Daten

    Ok, jetzt verstehe ich was Du meinst.
    - wobei das angeschlossene Lesegerät und die Authentifizierung / Transaktions-Autorisierung hier keine Unterschied macht.
    - die FinTS/HBCI-Version ist da ggf. nur eine Voraussetzung für.


    Bei mir wird auch mit FinTS3.0/HBCI3.0 der Datenaustausch abgewickelt
    - also nichts mit Screen-Parser o.ä.


    Den "Reinert cyberJack RFID Komfort" hab ich auch, aber die PB unterstützt die Secoder-Autorisierung leider nicht. :(
    - die setzen immer noch auf die mTAN oder dies dämliche chipTAN mit dem QR-Code am schirm
    - max. diese Seal One® Gerät mit der "BestSign-Funktion" werden als HW-Lösung angeboten ;(


    Das Ganze ist aber nur am Rande und hat nicht den geringsten Einfluss auf die hier diskutierte VWZ-Darstellung.


    und btw., SEPA ist nicht gleich IBAN + BIC. Da ist noch eine ganze Menge mehr und anderes hinter...

    Bekannt. Auch hier nur gemeint: Die Grundlagen für SEPA gibt es nicht erst seit gestern. Die Banken hatten an sich genügend Zeit, etwas vernünftiges zu implementieren.
    Der Hinweis bzg. der HBCI mit Chipkarte solte nur sagen: Schau Dich nach einer anderen Bank um, die das liefert, was Du benötigst. Ggf. eben mit einem anderen System => weg von der PB.