You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Importing existing CSV [as is].
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.
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"?
The text was updated successfully, but these errors were encountered:
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:
Then various matters can be better understood by users, and actually can be better formulated for their understanding. E.g.
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]".
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.
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.
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"?
The text was updated successfully, but these errors were encountered: