Inconsistent use of Exchange Rate in Invoices vs. Payments

[EnriqCG]

I've observed an inconsistency in the application of the Exchange Rate when calculating the final "Converted Balance" value. This inconsistency is noticeable when comparing the Payments section to the Invoice report.

Example

Let's say my primary currency is EUR and I invoice an international client in USD, specifically USD 10,000. I need to manage the currency conversion for reporting purposes to my local tax authority.

Behavior in Payments

The invoice is issued in USD, but I record the Payment I receive in EUR, accounting for currency conversions, fees, etc. The application correctly calculates the exchange rate as (EUR 9204 / USD 10000) = 0.9204.

And correctly shows up the Original Balance AND Converted Balance columns in the Payments table.

✅ This is the expected behavior

Behavior in Invoices

After obtaining the exchange rate from the payment, I can then input this rate in the Invoice > Settings.

However, when I navigate to the Invoice Reports tab, I find that the exchange rate is presented in an inverse format (1 / x). This representation causes an inconsistency in the Converted Balance when compared to the Payments table. To rectify this, I could adjust the Invoice Exchange Rate to its inverse form (1 / 0.9204 = 1.0865). However, this would result in the Payment and the Invoice having two different exchange rate values, which, to my understanding, is not the intended outcome.

Looking at the code, I find lines that manage the Invoice Report. I observe that the inverse of the exchange rate is used to determine the final value. Is this the expected behavior? If so, I don't understand why it would be beneficial to input the inverse of the Exchange Rate in the Invoice Settings.

https://github.com/invoiceninja/admin-portal/blob/adc96d334eb2408a92d60f90d0bfc9833be6abd6/lib/ui/reports/invoice_report.dart#L218-L220

I realize that addressing this might result in a breaking change, but before I proceed with opening a pull request, I wanted to inquire whether this inconsistency was intentionally designed or not.

[hillelcoren]

I believe the current approach is inconsistent but correct for each case, @EnriqCG does that align with what you're seeing?

Correcting this would require backend work, @turbo124 do you think this is worth the effort to correct? If not now maybe at some point in the future.

[turbo124]

@hillelcoren can you provide a spec for what the backend needs to do here please.

[hillelcoren]

@turbo124 I believe these are the required changes:

• Run a database migration to set the payment exchange rate to 1 divided by the current value
• Adjust the Flutter and React apps to use the reversed rate

One challenge here is the backend and apps will all need to be updated at the same time.

[hillelcoren]

@turbo124 I've given this a bit more thought, there are two problems with the suggestion above:

1. The changes need to be coordinated
2. The Flutter app persists data locally which will become invalid

Here's an adjusted process to account for this:

• Add a "payment_exchange_rate_corrected" bool (default false) to the account transformer
• Adjust the Flutter and React app to use this bool to calculate the rate
• Run the database migration to correct the data and set the bool to true
• The Flutter app would check for changes to the bool and when found would force refresh all data
• Once we assume everyone has updated we can remove the bool
• Note: the v4/v5 migration would also need to be adjusted

[turbo124]

If a user has not updated all their client apps, they would potentially corrupt their dataset if they continue using older clients, correct?

[hillelcoren]

I believe we could use the x-minimum-client-version header in the response to prevent this.

[turbo124]

This was my thought also you user the API to the prevent older clients from causing any corruption