Ähnlich buchst du auch die Gebühren bei ebase. ebase verkauft den passenden Anteil deiner Wertpapiere, um deine Gebühren zu bezahlen. Dort buchst du ein Verkauf und anschließend Gebühren.
Habe da noch eine Frage,
ich habe jetzt eine Abrechnung einlesen als PDF.
Da ist mir aufgefallen, das er da zwei Buchungen erzeugt.
Einmal Dividende und eimal Kauf.
Hatten wir gerade ja auch schon mal das
Thema.
Der Kauf leuchtet mir ja ein, weil die Anzahl der Aktien ja steigt, wenn auch nur gering.
Aber dann bucht der auch noch die gleiche Summe als Dividende. Somit wird dann doch die Summe verdoppelt.
Oder hebt sich das wiederauf.
Sorry, für die vielen Fragen, aber ich möchte das gerne ganz genau verstehen.
Hallo Dawedi61,
also, was du da vorfindest ist eine klassiche (automatische) Wiederanlage von Dividenden. Das ist nicht zu verwechseln mit Thesaurierung. Mich freut zu sehen, dass PP scheinbar das Dukument richtig interpretiert.
Im Detail passiert, dass dir das Wertpapier Dividenden ausschüttet. Das wird in PP als Dividende gebucht und das Geld fließt dem Referenzkonto zu. Nun sieht dein Produkt bei deiner Bank vor, dass von dieser Dividende, also dem jetzigen Geld auf deinem Referenzkonto neue Anteile des Wertpapiers gekauft werden. Deswegen bucht PP einen Kauf.
Genaugenommen passiert es genau anders herum, als du es beschreibst. PP bucht nicht einen Kauf und dann noch eine Dividene, PP bucht die Dividende und davon, also erst dann bucht PP den Kauf … inhaltlich ist das aber gleich.
Damit ist in PP alles richtig gelaufen. Die Dividendenzahlung fließt den Statistiken und Performanceberechnungen zu und das Referenzkonto ist wieder auf Null … und deine Wertpapieranzahl stimmt auch.
6 Likes
Evtl. könnte die beim PortfolioTransferEntry.java bzw. AccountTransferEntry.java so etwas wie folgendes implementiert werden? Bei den Transfer Buchungen verwendet PP intern 2 Buchungen, fasst diese aber als eine zusammen.
public ReinvestDividendBuyEntry(Account accountFrom, Account accountTo)
{
this(accountFrom, new AccountTransaction(), accountTo, new AccountTransaction());
}
/* protobuf only */ ReinvestDividendBuyEntry(Account(Account accountFrom, AccountTransaction txFrom, Account accountTo,
AccountTransaction txTo)
{
this.transactionFrom = txFrom;
this.transactionFrom.setType(AccountTransaction.Type.DIVIDENDS);
this.transactionFrom.setCrossEntry(this);
this.transactionTo = txTo;
this.transactionTo.setType(AccountTransaction.Type.BUY);
this.transactionTo.setCrossEntry(this);
this.accountFrom = accountFrom;
this.accountTo= accountTo;
}
P.S. Dann könnte mE auch der Wunsch nach der Stock Dividende möglich werden…
ja, da hatte ich mich auf den Export aus meinem aktuellen Programm verlassen, dort kann ich die automatische Wiederanlage nur als “Thesaurierung mit neuen Anteilen” erfassen… faktisch falsch, aber dem Programm nicht anders möglich…
Es sind nicht nur gezahlte Dividenden, sondern auch andere Erträge. Der Broker zahlt den Ertrag nicht aus, sondern bucht den Ertrag in Form von neuen Anteilen als Bestandserhöhung im Depot ein. Also kein Umweg über das Verrechnungskonto, keine separate Buchung Dividende/Kauf. So sollte der Vorgang “Wiederanlage” auch in PP umgesetzt werden. Das entspricht auch der oben bereits mal geposteten Beschreibung zur Wiederanlage bei wikipedia und vor allem entspricht es auch der Transaktionsübersicht des Depots beim Broker.
Bucht dein Broker die automatische Wiederanlage über eine monetäre Dividenauszahlung und anschließendem direkten Kauf über das Bank-Verrechnungskonto? Oder möchtest du die Abbildung so, weil du die Daten bisher in PP immer so erfassen musstest?
Wenn man die automatische Wiederanlage alternativ auch über zwei Transaktionen über das Verrechnungskonto abbilden möchte, könnte bei dem neuen Vorgang “Wiederanlage” das Verrechnungskonto ggf. optional erfassbar sein (als default leer). Wenn das VK leer ist, wird der Vorgang als eine Transaktion “Wiederanlage” als Bestandserhöhung abgebildet, ist das VK gefüllt, dient der Dialog als Erfassungshilfe und es wird daraus ein Dividenden- und ein Kauf-Vorgang separat gespeichert. Beim Import sollte es dann eine Option auf dem Importdialog (siehe Anhang) geben, damit man dort für den Import festlegen kann, ob die Wiederanlage über das VK (also auf die beiden Vorgänge Dividende und Kauf augeteilt) oder in einem Vorgang unter der Bezeichnung “Wiederanlage” übernommen wird (als default leer).
Die direkte Wiederanlage in Form von Bestandserhöhung sollte in den PP-Buchungen unter einer separaten Bezeichnung “Wiederanlage” angezeigt werden, damit die Vorgänge entsprechend filtern kann und bei einem Export an anderer Stelle auch unterscheiden kann.
Bei meinem Broker ist genau das der Fall. Es wird von dem ausschüttenden ETF eine Ausschüttung auf das Verrechnungskonto gebucht. Am nächsten Handelstag wird dann automatisch dieser ausgeschüttete Betrag genommen und davon neue Anteile gekauft. Somit erhalte ich eine Abrechnung für die Ausschüttung und eine Abrechnung für den Kauf (Wiederanlage).
2 Likes
Das spricht dann dafür, dass man die Wiederanlage wie zuletzt beschrieben mal mit, mal ohne VK erfassen kann. Bei mir ist es bei mehreren Brokern halt eine direkte Bestandserhöhung ohne Umweg über das VK.
Bei der Aufteilung auf zwei unterschiedliche Handelstage muss man ggf. auch nochmal bzgl. Datum und Kurs schauen… Oder ob man die Vorgänge dann nicht besser wie bisher über Dividende und späteren Kauf erfasst.
Nur das dieser Hacken den Programmieraufwand drastisch erhöht, da wirklich alle Auswertung und Berechnungen überarbeitet werden müssen. Dies ist eine Dividende. Ob cash oder als Anteil, ich will sehen was ich an Dividenden erhalten habe.
2 Likes
Dann sollte man es auf die direkte Wiederanlage beschränken, also Bestandserhöhung ohne Buchung über das VK über einen neuen Vorgang “Wiederanlage”.
Wenn es beim Broker über das VK läuft, kann man die Transaktionen auch einfach importieren, das funktioniert aktuell und es gibt auch keine Schwierigkeiten bei unterschiedlichen Handelstagen.
Genau darin besteht ja der Mehraufwand…
das wäre dann aber falsch gebucht.
Auswertungen usw sind dann auch falsch. Einer wiedererlange ist immer ein auch wenn man Broker die Buchung nicht auf der Abrechnungen ausweisen.
2 Likes
Das bei einer Entwicklung Aufwand entsteht, ist mir klar. Es stellt sich mir grundsätzlich die Frage, ob man PP mit wenig Aufwand entwickelt und sich den Nutzer verbiegen lässt, oder ob man lieber etwas mehr Aufwand akzeptiert und die Anwendung dafür für den Nutzer einfach und nachvollziehbar gestaltet.
Wenn aus dem erfassten Vorgang “Wiederanlage” dann doch wieder ein Vorgang “Dividende” und ein weiterer Vorgang “Kauf” erzeugt wird, kann zwar die Berechnung korrekt und mit wenig Aufwand abgebildet werden. Der Anwender hat aber Vorgänge im PP, die nicht mit den Vorgängen beim Broker übereinstimmen. Und kann der Anwender den Vorgang dann in PP über die Buchungsliste später noch filtern? Das nicht alles 1:1 abgebildet werden kann/muss ist mir auch klar.
Für den Nutzer am einfachsten (und aus meiner Sicht sinnvoll), ist es doch das er die Vorgänge so erfassen kann, wie es in der Umsatzliste des Brokers erscheint. In diesem Fall wird eine Ertragsausschüttung aufgeführt, welche als direkte Wiederanlage zur Erhöhung der Bestandsanteile führt. Vorgang erfolgt ausschließlich im Depot, keine Buchung auf dem Verrechnungskonto. Die Zeile weist der Broker so aus und ist auch so gebucht.
Warum es den Nutzern von PP kompliziert machen und aus dem einen Vorgang zwei Vorgänge machen, dazu noch einen Geldfluss der nicht stattgefunden hat?
Programmintern müsste vermutlich doch die Logik für eine Dividende anwendbar sein, die bei der Erfassung dann um die Bestandserhöhung erweitert werden muss. Bei den Berechnungen/Berichten vermute ich die Logik analog dem Vorgang “Dividende”, also Aufnahme des neuen Vorgangs “Wiederanlage”.
Ich würde es begrüßen, wenn sich die Entwickler von PP das anschauen und auch trotz ggf. “Mehraufwand” umgesetzt werden kann.
Nö… wäre zu kurz als Antwort, oder? 
Hier werden die Erträge zunächst ausgeschüttet, dann aber (u. U. in einem automatisierten Verfahren) in weiteren Papieren desselben Wertpapiers wieder angelegt. Somit reicht die Fondsverwaltung den Vermögenszuwachs durch die Zuteilung zusätzlicher Fondsanteile an die Anteilseigner weiter.
auf die Antwort bzgl. Falschbuchung sehe ich das auch so…
Es geht hier nicht um Thesaurierung! Es geht um Ertragsausschüttung mit direkter Wiederanlage… dazu aus dem Artikel:
Zu trennen ist die Thesaurierung von der Wiederanlage . Hier werden die Erträge zunächst ausgeschüttet, dann aber (u. U. in einem automatisierten Verfahren) in weiteren Papieren desselben Wertpapiers wieder angelegt. Somit reicht die Fondsverwaltung den Vermögenszuwachs durch die Zuteilung zusätzlicher Fondsanteile an die Anteilseigner weiter.
Auf meinem Depot kommt daher nur die Zuteilung der zusätzlichen Fondsanteile an. Warum dann in PP etwas abbilden, was auf Seiten der Fondsverwaltung stattfindet?
Warum den Depotanbieter nachahmen und nicht das zeigen, was tatsächlich passiert?
(Siehe meinen letzten Beitrag 
)
4 Likes
Wie ich geschrieben habe, um es dem Nutzer einfach und transparent zu machen! Das was er auf seiner Depotabrechnung sieht, erfasst er in PP, findet es dort wieder und kann danach auswerten.
Wenn man den Vorgang so abbilden möchte, wie er tatsächlich passiert, dann wird es sicherlich noch aufwendiger, da ein Geldfluss beim Anteilseigner nicht passiert, müsste man dazu weitere Verrechnungskonten in PP anlegen um den Vorgang der Fondsverwaltung abzubilden… 
Wie transparent soll es denn noch werden.
Wiederanlage… Ausschüttung, danach kauf.
Wir sogar als Notiz gesetzt.
So wird es in den PDF-Importern behandelt und kann auch manuell gebucht werden.
Das mag dir nicht passen, aber wird in PP seit anfang an gelebt. Da helfen auch keine weiteren Konten oder “virtuellen” Konten.
1 Like
Mit Transparenz meine ich in PP nachvollziehbare und mit der Depot-Umsatzliste abgleichbare Buchungen. Keine “künstlich notwendigen” Buchungen in PP, weil es ansonsten zu Mehraufwand bei der Entwicklung kommt. Ausschüttung und Kauf sind bei dem Vorgang beim Broker nicht vorhanden.
Ist PP in Stein gemeisselt und darf nicht verbessert werden? Die Aussage könnte man auch umdrehen: Es entsteht Anpassungsaufwand (der dir nicht passen mag), führt aber zu einer Erleichterung beim Nutzer und bringt einen besseren Abgleich der Konten/Depots zwischen PP und Broker.
Der Nutzer kann sich dann ja entscheiden, ob er die Vorgänge wie bisher erfasst oder über den neuen Vorgang “Wiederanlage”.
Bei der von mir vorgeschlagenen Verbesserung sind keine weiteren Konten notwendig, im Gegenteil, es wird nur auf dem Depot gebucht, statt zwei fiktiven Buchungen über das VK.
Zusätzliche Konten würden aus meiner Sicht notwendig, wenn man deinen Vorschlag folgt und das abbilden möchte, was tatsächlich auf Seiten der Fondsverwaltung an Buchungen passiert.
Ich denke mein Erweiterungswunsch ist deutlich geworden. Über die Anpassung können die Entwickler entscheiden. Ich würde eine Umsetzung sehr begrüßen. Danke!
Hallo @thomas-w
wie du sicherlich mitbekommen hast, haben dir jetzt mehrere User es erklärt.
Wenn dein Broker, dir diese separate Buchung nicht ausweist, dann ist das ein Problem deines Brokers.
Wir buchen, wie es buchhaltungstechnisch einwandfrei und nachvollziehbar ist.
Wiederanlage:
- Buchung → Dividende
- Buchung → Kauf
Was passiert buchhaltungstechnisch?
- Dividende wird ausgezahl
- Dividende wird reinvestiert als Kauf
Nein, PP ist nicht in Stein gemeiselt, aber es wird sich nichts ändern.
Ja, und sicherlich werden “wir” (Contributer) es ablehnen hier, weil es unnötig ist.
Meine Ablehnung ist bereits hier.
Was können wir dir anbieten?
PDF-Debug im richtigen Beitrag posten, dann implementieren wir dies.
Was können wir nicht?
Aus einer unvollständigen CSV-Datei ableiten, dass es sich um eine Wiederanlage handelt.
CSV macht den Import 1 zu 1, wie die Buchungen pro Zeile aufgelistet sind.
(Zusätzliche Buchungen generieren, welche nicht exisiteren. → 1 zu 1)
Regards
Alex
3 Likes