Current Imports, while much more flexible then whatever is currently available, still doesn’t handle a lot of cases. Exports from brokers are notoriously complex to handle and a new paradigm is needed here.
The idea is to split the process of creating a new template into separate phases:
1. Setup source format
CSV, JSON, XLS, codepage, rows selection, header, etc.
2. Setup data mapping logic
Using the same no-code + formulas logic as Tax Presets you can define what needs to happen for each row of input. This is contrast to current mapping of input->output and allows to handle pretty much all problematic situations I currently know of in a not very much more complex way.
Instead of saying “map “Price” column from CSV to “Price” in a transaction”, you say “create a transaction and get it’s “Price” from “Price” column in CSV”.
This change allows to create multiple transactions, creating assets, maybe even deleting them if needed. It also enables lookups across the whole imported table, or doing different things depending on the source row types (like Buy/Sell vs Dividend or Balance updates).
In addition, templates would allow for variables - like choosing the account to import to.
3. Review and edit changes that the import would introduce
At this point you’re just using the template, not creating it. If you use an existing template you just go straight here and don’t even see the first two steps unless you decide to edit the template.
Contrary to the current setup, you would see a table or list of changes without the source data. The source row would be available in a tooltip for those who need it.
Most people just expect the imports to work, they don’t care about the source data shape. You can also always check it in the first step (or under tooltip).
As it is now, you should be able to edit and correct the fields.
You also can provide values for the template variables at the top, along with optional template instructions if needed for more complex cases.
Mapping the values
Currently the value mapping (e.g. telling the system that BTC is actually an ETF symbol) is stored in the template. This means you need to clone the built-in template just to do something trivial like that. This way you’re missing out on any template updates in the future.
In the new way, mappings would be stored separately and would not require cloning (but would be cloned if you do that).
There would be a simple UI for mapping in bulk, as part of the review mentioned above.
Backwards compatibility
Existing templates would simply be transformed into the new format without loosing information.