Hallo miteinander,

ich möchte an dieser Stelle eine Anregung zu einer Verbesserung anbringen.
Vielleicht ist diese ja auch schon irgendwie implementiert und nur nicht dokumentiert.

Es wäre schön, wenn in dem Verwendungszweck einer Überweisung die regelmäßig ausgeführt wird, mittels einer Variablen der Turnus eingeblendet werden könnte.
Z.B. bei der Überweisung einer Steuervorauszahlung würde dann stehen: "ESt III/2014" Gleichbedeutend mit: drittes Quartal 2014.
Der Turnus sollte dann aus dem eingestellten Überweisungsturnus ermittelt und automatisch eingeblendet werden. Hierzu wird in dem Verwendungszweck z.B. der Platzhalter $T eingetragen. Der eingegebene Verwendungszweck würde dann "ESt $T" lauten.

Vielleicht besteht ja ein breiteres Interesse an diesem Feature.

Gruß

Slotty

Das ist ja nett aber wofür? Die Steuervorauszahlungen haben feste Termine, da kann es garnicht zu einem Zuordnungsproblem kommen. Also schreib einfach in den Verwendungszweck deine Steuernummer und das Wort "ESt Vorauszahlung". Mehr braucht niemand. Der Verwendungszweck ist für eine kurze und prägnante auf das Notwendigste beschränkte Zuordnung, nicht für kreative Textmitteilungen an den Empfänger gedacht.

Wenn das für dich vielleicht auch realitätsfern ist, so ist es schon notwendig im Zusammenhang mit Steuervorauszahlungen anzugeben worauf die Vorauszahlung geleistet wird.
Unter Prosa ist der von mir beispielhaft genannte Verwendungszweck wohl auch nicht einzuordnen. Wie du schon sagst: kurz, knapp und prägnant. Aber, da dies nur ein Beispiel war sollten wir uns auch nicht in Details verlieren.
Dieses Feature wird von anderen Programmen angeboten und das nicht ohne Grund und bestimmt auch nicht weil der Entwickler Langeweile hatte.

Gruß

Slotty

Dass andere Programme das anbieten heißt ja nicht, dass es nötig ist. Ich hab jedenfalls noch nirgendwo gehört oder gelesen, dass die Steuerart im Verwendungszweck nicht reichen würde. Und ich bin der Meinung, dass man schöne einfache Programme durch solche unnötigen "Features" nicht unnötig kompliziert machen sollte.

Dann lies dir doch mal deinen letzten Steuerbescheid durch, so du denn Vorauszahlungen leistest. Dein Steuerberater kann dir bestimmt auch weiter helfen.
Ansonsten ist es auch aus rechtlicher Sicht immer sinnvoll, genau anzugeben worauf sich Zahlungen beziehen. Denn was klar angegeben wurde bedarf dann keiner weiteren Diskussion.
Und wie gesagt, dass war nur ein Beispiel. Es gibt noch weitere Fälle.

Selbst als ich noch Vorauszahlungen geleistet habe, habe ich im Verwendungszweck lediglich die Steuerart angegeben, das gab nie ein Problem. Aber egal. Ich bin halt generell dagegen, den Verwendungszweck zu einer Plattform von Kreativität, Ausdruckskraft, Selbstfindung und Gestaltung zu machen. Insbesondere wenn dann noch Variablen dazu kommen, die funktionieren sollen, supportet werden müssen, andere Fehler mit sich bringen, Fragen aufwerfen usw. usw.
Ich bin dagegen und halte es für unsinnig, hat nichts mit dir zu tun.

Und damit das hier bei der Gelegenheit auch mal von meiner Seite oeffentlich ist: Ich bin auch kein Fan von Platzhaltern in Verwendungszwecken. Es ist nur eine Frage der Zeit, bis das dann zu einer regelrechten Programmiersprache mit Bedingungen, Schleifen, Datumsformaten, kontextabhaengigen Platzhaltern u.ae. ausartet. Da blickt dann kein Schwein mehr durch.
Fuer eindeutige Referenzen gibt es seit SEPA die EndToEnd-ID. Und ich bin zuversichtlich, dass die kuenftig auch von den Glaeubigern genutzt wird - schon aus eigenem Interesse, um bei den Geldeingaengen nicht mehr die Verwendungszwecken durch-greppen zu muessen.

Danke Olaf, *full ack*

@hibiscus: Ich kann natürlich nicht ausschließen, dass diese oder ähnliche Wünsche dem nachfolgen würden. Ich jedoch hatte solche aufwändige Lösung nie angepeilt. Mir ist zwar nicht klar wie die wiederum statische EndToEnd-ID einen dynamischen Inhalt ersetzen soll, aber sei es drum. Müssen also Monat für Monat alle entsprechenden Buchungen händisch angepasst werden. Abschließende Frage: Könnte eine entsprechende Lösung, die dir übergeben wird, dauerhaft in das Programm einfließen?

Typischerweise zahlt man ja basierend auf einer konkreten Zahlungsaufforderung. Und diese sollte dann kuenftig die EndToEnd-ID enthalten, die man einfach in seinen Auftrag uebernimmt. Es mag sein, dass das in deinem konkreten Fall - Steuervorauszahlungen - nicht passt. Es sollte jedoch der Normalfall sein.



Du kannst dir auch eine eigene Integration programmieren, mit der du die Zahlungen per XML-RPC oder SOAP an Hibiscus uebergibst. Siehe http://www.willuhn.de/wiki/doku.php?id=develop:xmlrpc
Dann bist du voellig frei in der Gestaltung - das waere fuer dich sogar noch erheblich flexibler als Variablen in Verwendungszwecken.



Sehr ungern. Das initiale Programmieren ist nicht der Aufwand. Der Aufwand entsteht erst spaeter durch die Wartung, den Support und die Folgewuensche. Die landen dann alle auf meinem Tisch. Fuer ein Feature, welches ich selbst gar nicht will.

Ok, vielen Dank. Ich schaue es mir mal an.

Nein, muss nicht. Probiers doch einfach aus. Das FA ordnet das schon richtig zu!

Bei den meisten Gehaltszahlungen, die ich bisher gesehen habe, steht auch immer der Bezugsmonat als Name oder Zahl im Betreff. Solche Basis-Variablen anzubieten würde also genau dies ermöglichen und immer noch weit von einer Skriptfähigen Programmiersprache sein. Solche Platzhalter werden von vielen Editier-Masken angeboten, lehnen sich an printf oder auch das FORMAT von date. Ich brauche es nun bisher nicht, da ich niemanden angestellt habe und Gehälter zahlen müsste, kann mir aber den Bedarf für eine Datums-Variable schon gut vorstellen. Die Frage wäre dann, wonach die Variable referenziert, also aktuelles Datum oder einfach inkrementierend, so dass man die März- und April-Gehälter dann z.B. auch mal außerplanmäßig im Mai zahlt. Sinn machen würde das nur für Daueraufträge, also wiederkehrende Aktionen, oder für Vorlagen. Sinnvoll wäre so eine Variable auch zur Zeitersparnis. Bei 20 Angestellten wären die monatlichen Gehaltszahlungen sonst immer viel Handarbeit. Als Vorlage einer SEPA-Sammelüberweisung mit solchen Variablen wäre es ein Handgriff.
Als nächstes würde vielleicht ein einfacher fortlaufender Inkrement-Iterator kommen.
Eine Variable für den Kontoinhaber wiederum fände ich dann auch übertrieben, da man Überweisungsvorlagen wohl eher nicht zwischen Konten verschiedener Besitzer kopieren wird. Eine Variable für das komplette aktuelle Datum wäre auch überflüssig, da diese Information in der Überweisung schon gegeben ist.
Wie gesagt, ich selbst brauche es nicht, aber kleine Firmen, die mit Hibiscus arbeiten, evtl. schon.

Mo, ich darf dran erinnern, dass wir hier von Hibiscus reden, das ist nicht konzipiert für Firmenkunden sondern für Privatanwender, die für gewöhnlich keine Gehälter bezahlen.

JFTR: ich finde die Platzhalter-Idee gut. Auch eine möglichst genaue Kennzeichnung des Verwendungszwecks.

David, gut finden kann man viel. Es muss für die Zielgruppe sinnvoll sein und der Nutzen muss zum Entwicklungs- und Supportaufwand in einem günstigen Verhältnis stehen. Und das ist bei diesen Vorschlägen m.E. nicht der Fall. Aber vielleicht baut Olaf es doch eines Tage. Wir wissen es nicht.

Ich finde die Idee mit einem Patzhalter für Monat / Quartal / Jahr als absolut sinnvoll.

Und ich finde es absolut nicht sinnvoll, knapp 2 Jahre alte Beiträge wieder aus der Versenkung zu holen, nachdem es derjenige, der das Programm kostenlos entwickelt, das nicht eingebaut hat...

@msa
wäre es sinnvoller gewesen, einen separaten T. aufzumachen?
Dass ein Wunsch nach 2 Jahren, von einem "Neuling" neu nachgefragt wird, zeigt doch aber auch, dass Interesse/Bedarf besteht - vielleicht kann dies den Entwickler doch noch umstimmen

Nein, ich wollte nur protestieren, daß "Neulinge" hereinkommen und dann wahllos, ohne auf das Alter des Fadens zu schauen, Uralte Kamellen wieder hochspülen. Ist ja nicht das erste Mal. Vor einiger Zeit gab es ja einen Neuling, der auf mindestens 10 teils viele Jahre alte Fäden Antworten mit völlig allgemeinem und sinnfreiem Inhalt, bzw. eigentlich völlig ohne Inhalt, getippt hat. Nach dem Motto "ich bin jetzt auch da". Und wenn man den Faden gelesen hat (!), dann weiß man auch, warum der Programmentwickler das nicht einbaut. Nicht zuletzt Du, lieber infoman, hast es sehr gut erklärt in den Beiträgen vorher

Was ich eigentlich nur sagen wollte: Erst lesen, dann denken und erst dann posten.