Add Support for Japan about rp2 HOT 16 CLOSED

I also just finished the new localization infrastructure for generated reports: now it's possible to generate Japanese taxes both in Japanese or in English (or in any other ISO 639-1 language), using the new -g command line option. This should be useful for expats living in another country. CC: @macanudo527.

More on this new feature here:

• https://github.com/eprbell/rp2/blob/main/README.dev.md#localization
• https://github.com/eprbell/rp2/blob/main/README.dev.md#adding-support-for-a-new-country

I also added placeholders for the new methods in the JP plugin, but they'll need to be revisited as we add the appropriate accounting methods (and perhaps generators) for Japan.

Note that currently the translation files in the source tree are:

• English strings;
• Japanese strings: unfortunately my Japanese language skills are non-existent, so all strings are empty (they get generated as English), but hopefully somebody fluent can help out and fill in the translations.

Since we don't have real translations yet, we can't have localization tests with real translations. So I added placeholder Kalaallisut strings. These strings are not real Kalaallisut: they are English, but with a __test_ prefix. This is good enough for testing the new localization infrastructure and plumbing.

from rp2.

I recently added a bunch of RP2 issues requesting help in adding support for various countries: here follows the blurb I wrote for these issues (it's useful because it contains all the needed pointers to support a new country).

RP2 and DaLI have a programmable plugin architecture for countries, accounting methods, report generators and more. Adding support for a new country is a high-impact activity because it allows many new potential users to get access to RP2 and DaLI.

Here's add support for a new country:

1. add a new country plugin to RP2;
2. if the country requires accounting methods that aren't already supported in RP2, add the necessary accounting method plugins;
3. ensure any newly added accounting methods are reflected in the country plugin's get_default_accounting_method() and get_accounting_methods() methods;
4. optionally, new country-specific report generators can be added. The built-in report generators (i.e. rp2_full_report and open_positions) are automatically supported;
5. only for non-English speaking countries: translations for the built-in report generators and for any new report generator can be added;
6. ensure any newly added report generators are reflected in the country plugin's get_report_generators() method;
7. add the same country plugin to DaLI. The implementation on the DaLI side is trivial: it's just an entry point instantiating the RP2 country plugin and passing it to the main function;
8. update the documentation of RP2 and DaLI to reflect the new country, accounting methods (if any) and report generators (if any).

If you notice the country-specific infrastructure is missing a feature that is required to express taxes for the new country, open an issue to let the RP2 community know.

from rp2.

This issue is in progress: @macanudo527 already added the country plugin for Japan (bullet 1 in the list above).

from rp2.

I've been trying to figure out a way to add an accounting method for Japan, but I'm not sure it is possible with the current account engine.

By default, Japan uses the total average accounting method. Basically, you add up all the buys from a particular year divide it by the amount purchased and that becomes your base cost. Then, you add up all the sales and divide that by the amount sold and subtract the amount sold from the amount bought. That is how much tax you owe. There are no lots.

I think we will have to modify the accounting engine somehow, unless you can think of another way around this.

from rp2.

I think it may be easier than it seems. We could just let the accounting engine do its thing, say with FIFO (default for Japan). Then in the Japan-specific output generator we could just ignore accounting info and lot relationships: we can compute the averages (a few lines of Python) and output the data we need. Perhaps as a later optimization we could disable the accounting engine altogether for certain countries, but we can start with the above to begin with.

from rp2.

Ok, I think I can get that to work. How should I setup the tests? It seems like the testing of the reports is actually done in rp2-dali. Should I set it up there?

from rp2.

Nevermind, I hadn't merged changes. I see some examples now. I'll look through those and let you know if I have issues.

from rp2.

BTW, not sure how fluent you are in Japanese, but if you like you can localize the Japanese report so that it outputs in English and in Japanese (and in any other language actually): see https://github.com/eprbell/rp2/blob/main/README.dev.md#localization. In a nutshell, just enclose output generator strings to translate in _(...): then you (or somebody else) can provide translations as a separate effort.

from rp2.

I'm just going to use the in_transaction_set and out_transaction_set from the computed_data. This will include fee transaction, right? For example, if I have an out transaction that has a fee for the trade. The transaction resolver will generate another out transaction for the fee, right? Sorry if that is a stupid question.

from rp2.

Yes, it's correct that these sets will contain the result of all data processing, including transaction resolution, price pair conversion, time filtering (via -f and -t CLI options in RP2), creation of artificial fee-only transactions, etc.

However, to be precise, fee-only transactions are not added by the transaction resolver, but rather:

• by DaLI data loader plugins, when necessary to model data coming from the exchange (e.g. when the fee is denominated in a different crypto than that of the transaction),
• by RP2 (when an in-transaction has a crypto fee > 0, RP2 models that fee as a separate fee-only transaction),
• by the user (whenever they deem it necessary, e.g. via the manual plugin).

See this FAQ for more details on fee-only transactions.

For reference you can look at the code generating the in, out and intra transaction tables in the "In-Out" sheet of the "rp2_full_report" output.

In any event, the short answer is: you should use in_transaction_set and out_transaction_set. One small caveat: what about intra_transaction_set? Intra-transactions can have a crypto fee and I don't know what the tax treatment for those fees might be in Japan: just raising attention to this.

from rp2.

I think I need to add intra_transaction_set because the fee is an investment expense. So, those are not automatically generated by RP2?

from rp2.

They are: intra_transaction_set is a property of computed_data. I mentioned it because in your earlier message you listed only in_transaction_set and out_transaction_set. See an example of use at: https://github.com/eprbell/rp2/blob/main/src/rp2/plugin/report/rp2_full_report.py#L661

from rp2.

by RP2 (when an in-transaction has a crypto fee > 0, RP2 models that fee as a separate fee-only transaction),

These fee-only transactions are only available in the GainLossSet? (Ie. An OutTransaction is not added to the out_transaction_set)

I'm not going to use the GainLossSet at all since I don't need lots. I will only be using the raw transactions (in, out, intra). In order to report the fees, I will need to create these fee transactions myself, right?

from rp2.

Ok, I think I got it. I found the relevant code in ods_parser.py. When rp2 parses the ods input file it generates an OutTransaction with just the fee. So, if I were to add up all the out transactions for the year, I should add together the crypto_out_without_fee of the OutTransaction set.

Maybe I can try to add this docs, so it is clearer for those who want to skip the account engine.

from rp2.

Right: the artificial fee-only transactions added by ods_parser.py should appear in the out_transaction_set of computed_data. Feel free to improve the docs: let's add a FAQ or something to make it easier for future devs.

from rp2.

Is there anything left to do on the Japan plugin?

from rp2.