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

New keys for classification nodes to support data exchange #2749

Closed
tquellenberg opened this issue Mar 14, 2022 · 1 comment · Fixed by #2765
Closed

New keys for classification nodes to support data exchange #2749

tquellenberg opened this issue Mar 14, 2022 · 1 comment · Fixed by #2765

Comments

@tquellenberg
Copy link
Contributor

Is your feature request related to a problem? Please describe.
New extensions to Portfolio Performance will include export and import of security classifications. The standard taxonomy classification (MSCI Regions, GICS etc.) which are include in Portfolio Performance do not have keys for this purpose. When a user creates a taxonomy tree, all classifications are created with random UUIDs.

For some classifications (e.g. Regions) there exist values in the data map (eg: "ISO3166-1-Alpha-2=DE;ISO3166-1-Alpha-3=DEU"). For some (e.g. GICS) there are meaningful keys in the properties file (20101010 = "Aerospace & Defense", see here) which are overwritten with random uuids. At the end there is no general classification id which can be used for im- and exports, the exchange of data between users or the update from a central database.

Describe the solution you'd like
All classification nodes which are include in Portfolio Performance are extended with a sensible key. This key is unique within a taxonomy tree and can be set, when a new node is added. The key is shown in a new info dialog (together with the values in the data map) for every classification node. This key can be added as a new column in classification tree table and thus can be exported in the CSV export.
For existing pp files an automatic update process adds the new key to the tree nodes. The keys are retrieved from the properties files and are human readable ("DE" for country, "20101010" for GICS etc.)
The key is stored in the existing data map with a fix name (e.g. "portfolioKey"). (Alternatively, the class "Classification" is extended, and the loading and saving is modified)
Same keys in different trees are allowed.

Describe alternatives you've considered
Harmonize the random UIUDs so that all users use the same UUIDs for the standard classifications.
Same keys in different trees are NOT allowed.
Advantage: easy to realize.
Downside: UUIDs are hard to understand (e.g., in an export file).

Additional context
For me this is the basis for all further extensions to support im-, export and exchange of classification data. Comments and discussion are welcome.

@buchen
Copy link
Member

buchen commented Mar 25, 2022

Quick note: I have been super busy. Will reply on the weekend in more detail. But in general, I support the idea of a primary external identifier which is editable and where PP ensures the uniqueness within the taxonomy.

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

Successfully merging a pull request may close this issue.

2 participants