PDF-Import von Consorsbank

Nein. Was für eine widersinnige Argumentation man könnte mehr Konsistenz bekommen, indem der Importer einfach bestimmte Buchungen im Depot weglässt. Es ist mit dem Depot dasselbe wie mit Geldkonten. Wenn ich da von einem Konto an ein anderes überweise, dann muss selbstverständlich auf dem einen Konto der Abgang und auf dem anderen Konto der Zugang gebucht werden. Ansonsten ist es inkonsistent und genau das jetzt der Fall bei Wertpapieren.

Die Einlieferung muss man jetzt manuell buchen und dafür gibt es sogar einen Menüpunkt. Wenn das Buchen von Einlieferungen sinnlos wäre, wie hier versucht wird, darzulegen, gäbe es auch diesen Menüpunkt nicht.

Das Fehlen der Übernahme von Wertpapier-Einbuchungen und Abhängen durch den Import macht das Konto gerade inkonsistent und man muss diese eigentlich automatisch importierbaren Vorgänge manuell buchen.

Das einzig richtige ist also, alle Buchungen (inkl. Eingänge und Abgänge) zu buchen. Und wenn das immer gemacht wird, kann es entgegen der Behauptung von @Rafa gerade NICHT zu irgendwelchen Inkonsistenzen kommen. Es ist genau umgekehrt: Jedes Weglassen einer Buchung erzeugt Inkonsistenzen und NUR das Übernehmen aller Depotbuchungen stellt Konsistenz sicher.

Also wie jetzt, erst Depotübertrag jetzt Einlieferung? In deinem Fall werden neue Stückzahl hinzugebucht, aber wie sieht es dann aber aus wenn jemand das Abgebende und das Aufnehmende Depot beteits in PP erfasst hat? Überraschung, die Stückzahlen verdoppeln sich.

Anyway, genau wie beim Aktiensplit kommen derartige Vorgänge zu selten vor als diese automatisch zu behandeln. Ich wäre dagegen, aber das letzte Wort hat @Nirus bzw. @AndreasB

Du hast scheinbar den Sinn von Einlieferungen nicht verstanden.

Wie schon gesagt, wenn das abgebende Depot auch in PP ist, muss da natürlich auch die Auslieferung gebucht werden. NUR wenn alle Auslieferungen und Einlieferungen gebucht werden, bleiben die Konten in PP konsistent. Jetzt sind sie bei Einlieferung und Auslieferungen (egal ob das andere Konto in PP ist oder nicht) IMMER inkonsistent.

Was soll also diese absurde Argumentation, es würde durch die korrekte Buchung aller Vorgänge irgendetwas inkonsitent werden. Wie schon dargelegt ist das Gegenteil der Fall. JEDE weggelassene Buchung führt zur Inkonsistenz.

Ebenso unsinnig wäre es, einfach Einzahlungen und Auszahlungen auf dem Geldkonto wegzulassen, weil “das Gegenkonto ja auch in PP sein könnte”. Auch hier gilt das Gleicht: Jede Buchung ist zu erfassen, damit die Kontostände korrekt bleiben. Nichts anderes gilt für das Depot.

Im Gegenteil: Das Verständnisproblem scheint bei dir zu liegen. Der Text erklärt sehr schön was Einlieferungen sind, also ließ es dir mal durch, dann verstehst du, warum Einlieferungen (und Auslieferungen) in PP implementiert wurden. Weil sie nämlich notwendig sind, um die Depotstände korrekt führen.

Zwischenfazit: Es gibt nicht nur Käufe und Verkäufe, Geldeingänge und Geldausgänge sondern auch Wertpapiereinlieferungen und -auslieferungen. Alles das kann (und muss) in PP erfasst werden, damit die Konten und Depots stimmen.

Zurück zum ursprünglichen Anliegen: Das Problem bei PP ist zumindest bei Consors, dass PP die die Einlieferungen und Auslieferungen nicht importieren kann. Und das führt halt zu Inkonsistenzen und falschen Depotständen. Der Import ist ja nur eine Vereinfachung von etwas, was man auch manuell buchen kann (und muss).

Wenn man also etwas bei manueller Buchung buchen MUSS, damit die Depotstände konsistent sind, ist es nur richtig und notwendig, dass auch der Import diese Buchungen importieren kann.

Woher soll der Importer wissen, dass das, was du im PDF als Einlieferung automatische verbucht haben möchtest schon in PP verwaltet wird und damit innerhalb von PP eine Umbuchung darstellen muss?

1 Like

Genauso wie bei Geld, wo von Konto 1 abgebucht und bei Konto 2 eingebucht wird. Beim Depot ist es dann Auslieferung Depot 1 (kommt über Import Depot 1) und Einlieferung Depot 2 (kommt über Import Depot 2) .

Für den recht unwahrscheinlichen Fall bei Auslieferung, dass man das Wertpapier tatsächlich äußerbörslich privat verkauft hat und den Kaufvertrag nun dadurch erfüllt, dass man die Aktien an das Depot des Empfängers überträgt, müsste man später eine manuelle Korrektur vornehmen, in dem man die Auslieferung in einen Verkauf ändert. Analog bei Einlieferung bei Wertpapierkäufen von privat zu privat. Das ist aber sicherlich der absolute Ausnahmefall.

Im Übrigen besteht immer die Möglichkeit, beim Import bestimmte PDFs (z.B. die Aus- und Einliefer-PDFs) nicht zu importieren, was man vielleicht für sehr spezielle Sonderfälle brauchen könnte. Das generelle Ingnorieren ist aber immer falsch, da nach dem Import IMMER ALLE betroffenen Depots falsche Werte haben.

Die Diskussion mit dir wird zunehmend schwierig.

Einlage und Entnahme bedeuten: Geld zu PP hinzuzufügen oder aus PP zu entfernen. Nicht mehr nicht weniger.

Mann muss eben keine Konten führen, wenn man mit Einlieferungen arbeitet.

Noch einmal: beim Import kann PP nicht wissen woher die Einlieferung stammt!

Wenn der Importer wüsste woher die Einlieferung stammt, ABER das weiß er eben im vergleich zu Dir nicht.

So wie Einlage und Entnahme bedeuten: Geld zu PP hinzuzufügen oder aus PP zu entfernen, bedeutet Einlieferung und Auslieferung Wertpapiere zu PP hinzuzufügen und zu entfernen. Woher kommt die unsinnige Vorstellung, man müsste immer mit Geld starten und ein Depot nicht mit Wertpapieren starten?

Das ständige Vertreten der vollkommen absurden Meinung, es wäre sinnvoll Depotbuchungen beim Import weglassen, geht mir langsam auf die Nerven, weil es auch bei ständiger Behauptung falsch bleibt. Richtig ist NUR: Für einen konsistenten Depot und Kontostand müssen ALLE Depot und ALLE Geldbuchungen erfasst werden. Das geht manuell auch in PP. Also sollte es auch automatisch gehen.

PP muss nicht wissen woher die Einlieferung stammt. Wie oft muss ich das noch darlegen?

Ich habe mir zum Vergleich mal https://aktiendoktor.de/ angeschaut und siehe da. Komplette PDF Dokumente von Consors selektiert und auf Anhieb komplett richtige Depot und Kontostände. So soll es sein. Das ständige Vertreten der Meinung, dieser “Bug” vom PP-Importer, nach einem Import nur inkonsistente Depot zu produzieren, sei richtig, ist schon extrem absurd. Andere können es auch, wieso PP nicht?

Der manuelle Einlieferungsdialog von PP hat auch kein Herkunftsdepot sondern nur ein Zieldepot. Also braucht PP auch die Herkunft nicht zu wisssen.
Es geht nur darum, das dieser manuell mögliche Buchungsvorgang auch per Import geht.

Wenn man mal im Github Repository nach DELIVERY_INBOUND sucht, stellt man fest, dass jede Menge von Importern (interessanterweise auch für die DAB-Bank, die ja von Consors übernommen wurde), diese INBOUND und OUTBOUND-PDF-Dokumente importieren. Wenn das also deiner Meinung nach nicht sinnvoll sei, warum importieren diese anderen Importer diese nun?

@carsten2
Es reicht… du bist hier im falsche Thema und wenn du es besser kannst, dann steht dir GitHub zur Verfügung. Wir erwarten deine Änderungen im Sourcecode.

Wieso ist es das falsche Thema, wenn man auf einen fehlenden Transaktionstyp im Consors-Importer hinweist, der in diversen anderen Bank-Imports korrekt implementiert ist?

Ist das so? Bei Dividenden wird doch auch erkannt, ob diese schon anderweitig eingepflegt wurden und merkt sie als zu igorieren vor.

Aber auch nur wenn du das Depot richtig zuordnest.

Es wird immer wieder die falsche Behauptung wiederholt wegen möglicher Bestandserhöhungen.

Meine Aussage ist, dass EIN- UND AUS-Buchungen importiert werden müssen. Dann kann sich auch nichts verdoppeln, denn was auf dem einen Deopt dazugebucht wird auf dem anderen weggebucht.

Weiterhin ist nach dem aktuellen Modell bei Consors (aber nicht bei anderen Banken) die Einbuchungen zu ignorieren, das Depot nach IMMER falsch und nicht nur eventuell falsch.

Und zuletzt: Wenn jemand meint, dass er die Einbuchungen nicht importieren will, dann kann er das einfach machen, indem er die Dateien einfacht nicht auswählt. Also selbst, wenn das irgendeinen Sinn machen würde, könnte man es machen.

Also ist der einzig richtige Weg, diese Lücke im Consorsimporter zu schließen.