Hallo,

wenn man aktuell eine Überweisung zum wiederholten Mal an den gleichen Empfänger erstellt, wird der Verwendungszweck vom letzten Mal vorgeschlagen, was prima ist.

Hier wird häufig ein Teil gleichbleibend benötigt und ein anderer Teil jedes Mal anders.
Es müsste also der entsprechende Inhalt des Feldes markiert und raus gelöscht werden, während der beizubehaltende Teil stehen bleiben muss. Dann würde man den neuen Zweck hinzufügen.

Hätte man zwei separate Felder, könnte man in den Ersten den dynamischen eintragen und der Zweite könnte stehen bleiben.
Vom Programm könnten wie bisher beide Felder aus der letzten Überweisung vorgeschlagen werden, aber mit Tabulator könnte zum ersten Feld gewechselt werden und dann dieses einfach überschrieben werden. Das Markieren und auswählen / löschen würde dann wegfallen.

Vielen lieben Dank!

Die Verwendungszweckfelder sind aber durch die Bankrechner vorgegeben. Im SEPA-Zahlungsauftrag sind das genau 4 mal 35 Stellen. Was dann beim Kunden ankommt ist aber nicht vorhersagbar, da manche Bankrechner mit den aktuellen 4*35 arbeiten, andere mit dem ehemaligen 14*27 Stellen, wieder andere mit nur einem zusammenhängenden Feld. Bei der Übergabe der Felder von einem Banksystem an ein anderes wird dann munter umgebrochen, teilweise hart, teilweise wieder zusammengefügt, teilweise unter Hinzufügung eines Leerzeichens an der Fügestelle, teilweise ohne. Das ist auch die Erklärung dafür, dass vielfach ein ziemliches Sammelsurium an Text ankommt.

Vor dem Hintergrund noch in der lokalen Datenbank die Felder zu trennen macht in meinen Augen keinen wirklichen Sinn... Könntest Du nicht vielleicht entsprechende Vorlagen im Adressbuch hinterlegen, in denen nur der immer notwendige Teil eingetragen ist und diese dann als Grundlage der neuen Überweisung verwenden?

Das Problem mit dem nicht vorhersehbaren Ergebnissen bzw. Hinzufügen von Leerstellen kenne ich tatsächlich bereits von anderen Programmen. Das ist ein sehr guter Grund dagegen.

Die Vorlagen (Verwendungszweck) im Adressbuch anzupassen wären dagegen kein Problem. Das geht aktuell aber soweit ersichtlich auch nicht.
Man könnte dann bei neuen Überweisungen die individuellen Verwendungszweckergänzungen einfach an den Anfang schreiben. Wichtig wäre dann aber, dass man damit die Einstellungen im Adressbuch nicht wieder überschreibt. Vielleicht kann man das dann mit dem Flag "im Adressbuch speichern" beeinflussen.

Das wäre offensichtlich die elegantere Lösung. Danke.

@msa: SEPA hat - derzeit - 1 * 140 Zeichen. Wenn eine Software 4 * 35 oder eine andere Aufteilung anbietet, ist das eine "willkürliche" Entscheidung der Anwendung mit den von Die genannten Problemen der Umbrüche und Leerzeichen
Ansonsten ist der Wunsch von KilVirus grundsätzlich etwas für eine Art von Textbausteinen/Variablen.
Bei Daueraufträgen kenne ich so etwas z. B mit Platzhaltern für Monat oder anderen Datumsangaben

Zahlungsaufträge werden bei FinTS im XML-basierten SEPA PAIN Format an die Bank übertragen. Hier ist nur eine Zeile mit 140 Zeichen Länge als Verwendungszweck vorgesehen. Das ist auch der Grund, warum in Hibiscus nur noch eine Zeile angezeigt wird. Früher in der Vor-SEPA-Zeit gab es bei Überweisungen mehrere Zeilen.

Zum Verwendungszweck im Adressbuch: Das ist bisher noch nicht vorgesehen. Es steht zwar auf der TODO-Liste, ist aber nicht so trivial umsetzbar, da das Adressbuch von Plugins erweitert werden kann und z.B. von JVerein auch wird. Wenn ich da eine neue Funktion "getVerwendungszweck()" hinzufüge, breche ich mit der Kompatibilität mit diesen anderen Plugins. Die würden dann alle Fehler liefern, bis dort diese Änderung ebenfalls nachgezogen wurde.

anderer Ansatz:
müssen wirklich immer viele Daten eingetragen werden, denn je mehr drin steht, desto fehleranfälliger. (Zahlen-/Buchstabendreher)

Oft* reicht ja die Kundennummer o. Vertragsnummer - die ja dann immer gleich bleibt.
*= bevor Einwände kommen von Foren -Usern ... ja nicht alle, da in manchen Fällen eine direkte Zuordnung sinnvoll ist, aber das sind doch Sonderfälle

@Holger Fischer
Ich denke nicht, dass voreingestellte Informationen (ich sage jetzt einfach mal Kundennummer) zum Empfänger tatsächlich Textbausteine oder Variablen sind. Anders als das von dir genannte Beispiel (Datumsangaben) sind diese ja Empfängerindividuell.

@hibiscus
Vielleicht könnte man grundsätzlich aus den genannten Gründen bei einer einzelnen Verwendungszweck Zeile bleiben. Diese aber technisch nur innerhalb hibiscus im Hintergrund aufsplitten - oder ggf. auch für den Anwender sichtbar durch einen zarten Trennstrich innerhalb des Feldes?

Ansonsten, wenn das Adressbuch bereits jetzt erweitert werden kann, wäre das evtl. die Lösung? Ich habe in der db geschaut und da ist bei "empfaenger" ja nur "kommentar" und "kategorie" hinterlegt. Aus welchen Daten übernimmt er denn die vorausgefüllten Verwendungszweck Daten? Sucht er immer die letzte Zahlung zu dem Empfänger und nimmt diese?


@infoman
Leider bestehen die notwendigen Daten aus einem (zu je nach Empfänger) fixen und einem dynamischen Teil zu jedem einzelnen Empfänger.

Besten Dank und Grüße

Nicht in jedem Programm, aber in der VR-NetWorld Sofwtare, in Profi cash und im BankingManager sind das definitiv Textbausteine. Man muss natürlich am Empfänge diese Informationen pflegen.

Alternative Idee:
1x Sammler einmalig exportieren als Basis
je nach Häufigkeit > Datei über ein Drittprogramm editieren (suchen/ersetzen o. Makro) - importieren/versenden
je nach Anzahl, wird diese Mehrschritt-Variante schneller gehen, als die individuelle Anpassung über die Maske

Technisch gibt es ja nur eine Zeile. Ich glaube nicht, dass es hilfreich wäre, das in Hibiscus auf 2 x 70 Zeichen aufzuteilen. Im Gegenteil: Ich bin froh, dass das Umbrechen bei SEPA-Überweisungen - wie msa es beschrieben hat, zumindest beim Einreichen von Aufträgen ein Ende hat.

Ich schrieb ja, dass das nicht so einfach ist, weil ich dabei andere Plugins kaputt mache.

Korrekt.

gute Idee, aber leider sind die Empfänger zwar grundsätzlich wiederkehrend aber nicht immer alle und andererseits gehen mehrere Zahlungen in einer Sammelüberweisung an den gleichen Empfänger