Zwei separate Verwendungszweckfelder bei Überweisungen / Sammelüberweisungen

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!

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.

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.

@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

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

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