Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with reference/file/import/csv-import/ #121

Open
pfalcon opened this issue Jan 26, 2025 · 0 comments
Open

Issues with reference/file/import/csv-import/ #121

pfalcon opened this issue Jan 26, 2025 · 0 comments

Comments

@pfalcon
Copy link

pfalcon commented Jan 26, 2025

https://help.portfolio-performance.info/en/reference/file/import/csv-import/ :

Figure 2, Figure 7 are rendered too small, not legible. Yes, advanced users can right-click on an image and "Open image in new tab", but why give people riddles? IMHO, the image shouldn't be rendered with text flowing by the image, but instead, in full page width, like the rest of images.


As general note, I'd say this section of manual should explain that there're 2 main usecases of the CSV import functionality:

  1. Importing existing CSV [as is].
  2. As a kind of intermediate format for importing 3rd-party data into PP, where users transform 3rd-party data in arbitrary format into CSV, and use that as a direct import medium.

Then various matters can be better understood by users, and actually can be better formulated for their understanding. E.g.

The names in the heading can be freely chosen, although they should match PP's internal usage, as it simplifies the mapping process (associating each column with its corresponding field in PP).

This sentence is self-contradictory anyway ("can be freely chosen" and yet "should match"), but keeping in mind 2 usecases above, it's easier to rewrite it clearer: "The names in the heading can be arbitrary [if user gets 3rd-party CSV, there's no choice], but if they match predefined PP headings, it simplifies the mapping process [by avoiding explicit manual mapping, and relying on auto-mapping, as even if manual mapping can be saved as a template, it's still boring to choose witch template to use, and maintain possibly many templates for different data sources]".


The Account Transactions and Portfolio Transactions import types are quite similar. Internally, an account transaction is reserved to work with cash accounts and their transactions such as deposits. A portfolio transaction works with instruments and their transactions: buy, sell, delivery, ... A buy/sell transaction however has both components: something is added/removed from the securities account and some money is deducted/added to the cash account. In most cases, both types could be used interchangeably.

⚠ Use Account Transactions type for deposit, removal, ... and Portfolio Transactions type for buy, sell, ...

As someone who had to dig into this on my own, I appreciate this notice. However, as someone who dug into it myself, I came to alternative conclusion (than the last sentence). I'd recommend to use Account Transactions, as covering close to 100% of normal import usecases which most people would face. Let's enumerate again what transaction types "Account Transactions" format can support: Deposit, Withdrawal, Interest, Dividend, Taxes, Fees, Buy, Sell, Cash transfer. Now which transactions cannot be covered by "Account Transactions", and thus require "Portfolio Transactions": Delivery In/Out, Security Transfer. All of these are very special transactions, happening relatively rarely, and probably never happening to most people. Chances also that they would need to be entered manually anyway (as not normally appearing in broker statements, or appearing in rather adhoc form).

Thus, a suggestion "Use Account Transactions all the time that you can, and normally that would be 99.9% of cases, and only use Portfolio Transactions if you can't use Account Transactions" - seems like a very practical way to present the matter to users.


Regrettably, the software does not currently support the inclusion of Fees and Taxes, either in the foreign or domestic currency.

It's unclear to what matter this regret applies. It's possible for include Fees/Taxes with a Dividend transaction type in a CSV line. Not sure how multi-currency case would work, but single-currency case works as expected.


  1. Portfolio Transactions import
    ...
    Because the number of shares is a required field, one would assume that simple deposit of removal transactions are not allowed; but they are. The number of shares is then ignored.

Aha, that's why the suggestion to stick with Account Transaction import whenever possible: if they both can support kinda everything, then why use more complex and confusing "Portfolio Transactions"?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant