cron.php currently performs two tasks:

• deletes temporary files older than 12 hours (they contain encrypted transactions of users, if CrypTax is used in "public" mode)
• update the expired cached prices (including prices that expire in the next 60 minutes)

The cron job on core.cryptax.xyz runs every 30 minutes, so there should never be expired prices in the database, but it seems that this is not the case.

Deleting temporary files works correctly, while updating cached prices needs to be reviewed.

"Expense" transaction type was originally intended to insert transactions as network fees, that did not have a well known countervalue.

For tax purposes they have always been treated by CrypTax as sales, using the daily price from CryptoHistory.

The only difference is that they were ignored when calculating the total investments for the year (Investimenti anno corrente).

With the merge of PR #35 they are now considered as sales, so maybe it no longer makes sense to maintain the "expense" type, which has often also created confusion among new users.

At the moment the final value for the RW models is calculated as the average stock, using the prices of the day 31/12, as suggested in the guide Aspetti fiscali: Criptovalute e Bitcoin, Giorgio D’Amico, 4th edition, page 17.

An alternative way is to use the actual value of the day 31/12, to which the values of sales made during the year should be added.

We need to implement this alternative method, and allow the user the choice.

The id was initially required when the capital gain calculation was semi-manual.

Now that the calculation is fully automatic, the id of each transaction can be generated automatically, and then we can make it optional in the .csv file.

The parse of a CSV file with ~100000 transactions takes about 6.5 seconds on my laptop.

Saving the array to a json file doesn't take any significant additional time.

Successive reads of the array from the json file only take about 0.1 seconds, so this is definitely a change to make.

Encryption and decryption with AES does not seem to affect the loading time significantly, so the json file can be encrypted with the same key as the source file, before being saved.

Originally posted by @cristianlivella in https://github.com/cristianlivella/cryptax/issues/14#issuecomment-980017121

In case column 3 is empty (or 0), and also column 7 is empty, automatically calculate the value of the transaction using cryptocurrency price on that day.

The report may be incomplete if:

• you try to process the report of the current year: in this case the prices of 3 days ago are used as end of year prices*;
• some of your cryptocurrency prices are not available on cryptohistory.one: in this case those cryptocurrencies will not be present in the report.

In either case, it would be helpful to inform the user with a message

* this is because of the cryptohistory.one API, that doesn't always have prices for the last 2-3 days

By default, the script processes the report for the current fiscal year. You can process a specific year through the year GET parameter.

It would be useful to add links/buttons to be able to view the report for a year other than the current one, without having to manually set the GET parameter.

This feature is currently not documented on the README file.

Actually the fetchGlobalCryptoData function is a total mess.

The initial idea was to optimize the number of requests to the API and database by grouping near dates. However, the result is a fairly complicated and unreadable function.

It is probably simpler and more efficient every time we need to request data regarding cryptocurrency prices from the database or API, to always request the next 365 days of data as well and save it in RAM.

At the moment the script parses the transactions it takes in a file in a local location.

This makes it usable only by installing a local PHP server, and makes it unusable for people who do not have advanced technical knowledge.

It would be useful to make a page where you can upload the file with the transactions to be processed, so that the software can be published on a public web server and make it usable for everyone.

Ideally, my idea would be that the user uploads a CSV/XSL file with his transactions, and then a ZIP file is generated containing the report of all the years, and the fac simile of the declaration forms (see issue #3)

Data validation at the moment is very poor, it is possible for example to have negative balances, or other strange situations that generate errors.

There is a need to review and improve the validation of the transactions in the input file.

At the moment, the initial value corresponds to the equivalent on the first day of the year.

A more correct way to calculate it would be to add to it the purchases made during the year, as also suggested in the Aspetti fiscali: Criptovalute e Bitcoin, Giorgio D’Amico, 6th edition, page 14.

Indicare il valore (in Euro) del saldo del portafoglio all’inizio dell’anno oppure nel primo giorno di detenzione della cryptovaluta, utilizzando il cambio della cryptovaluta a inizio anno. A questo valore deve essere sommato il totale dei nuovi investimenti effettuatnell’anno, ovvero l’ammontare dei “depositi” effettuati sugli exchange ed utilizzati per l’acquisto di nuove crypto.

We need to implement this method, which should be used as the default.

The calculation is pretty easy, and it's very similiar to the final value one, we just need to add the currentYearInvestment value, if greater than 0.

The size of a float is platform-dependent, although a maximum of approximately 1.8e308 with a precision of roughly 14 decimal digits is a common value (the 64 bit IEEE format).

Using floats to represent cryptocurrency costs and amounts causes some approximation issues. In 98119b0 a temporary fix has been made, but it is better to replace all floats completely, using for example Brick Math BicDecimal, to avoid other problems as well (for example, at the moment cryptocurrencies that have more than 14 decimal places, such as Nano, could cause problems).

Considering the increase of circulars from the Agenzia delle Entrate, it would be useful to add some markdown files explaining what the current regulatory situation is in Italy.

In this way it would be easy for everyone to have an overview of the situation, propose and monitor changes.

In addition, we might think of creating a directory where we can save the regulatory sources (from Agenzia delle Entrate, TAR, ecc..).

At the moment there are some settings that can be set, prior to elaborate a report:

• compensate losses: Italian legislation provides that capital gains may be compensated with any capital losses of the previous 5 years. However, the user can choose not to do so (he will pay more taxes, but will probably be subject to fewer controls by the revenue agency);
• exchange earnings types: in cases of interest earned, for each exchange/service the user can choose whether to declare them in the RM or RL section of the fiscal income statement (the legislation is unclear, so various tax experts have different ideas about this);
• postpone crypto-to-crypto-gains: the revenue agency's position seems to be to consider capital gains even between crypto-to-crypto trades, but some people don't think that's correct, and there's even a bill proposing the opposite. With this option, the user can then choose to postpone capital gains to the time of sale in euros.

Currently in the public mode (with the frontend) of the application, the settings are made using the web UI and saved in a cookie.

In private mode, however, it is not possible to easily change these settings. It is therefore necessary to introduce the possibility to manage them in the config.php file.

Note that the last point has not actually been implemented yet, but is in progress (see issue #20).

At the moment all transactions have the euro as their base currency. Therefore, exchanges between cryptocurrencies are not handled.

It is necessary to implement this functionality.

For exchanges between cryptocurrencies it must be possible to choose whether:

• calculate capital gains on each trade (as currently provided for by the interpretations of the "Agenzia delle Entrate" (the Italian revenue agency);
• calculate the capital gains only when the sale is made in euro (as provided for by the bill 3131/2021).

Branch: crypto-to-crypto-trades

PhpSpreadsheet uses a lot of memory in order to read the input file.

Roughly ~400 MB of RAM are used for elaborate a report with ~200.000 transactions. Of these, about 350 MB are used by PhpSpreadsheet.

This seems to be a known and frequent problem: https://phpspreadsheet.readthedocs.io/en/latest/topics/memory_saving.

We need to consider replacing it with Spout, because of the supported file formats (csv, xsls and ods).

Spout seems to use much less memory (they say 3 MB, regardless of file size), but seems to be less smart about recognizing file types and delimiters for CSV files.

We could use PhpSpreadsheet to recognize the file type and delimiters, and then Spout to actually read the file.