Wednesday, March 6, 2024
2 changes · 17.0
Resolved issues and error corrections
This fix resolves a critical issue where archived accounting tags prevent users from updating their fiscal localization settings. When users archive tags in the accounting system, the system was incorrectly blocking localization updates even though the tags still exist in the database. The fix now properly recognizes archived tags during localization updates, allowing the process to complete successfully without requiring manual intervention.
Original PR description
After this commit: [commit](https://github.com/odoo/odoo/pull/148866/files) - If tags belonging to localization are present in the database but with active='f', the user error will still trigger. As…
After this commit: [commit](https://github.com/odoo/odoo/pull/148866/files)
- If tags belonging to localization are present in the database but with active='f', the user error will still trigger. As mentioned in the commit if tags are deleted by the end user, then updating the localization module will resolve this and will create the new tags for that localization, but in our case if the tag are present in the db but are active='f', so updating the localization module will not help as noupdate will become true, if the enduser makes any changes to it. so updating the localization will not change active='f' and the user error will keep on coming unless the end user manually set it active='t'.
**Steps to reproduce**:
1. Create a database in saas-16.2
2. Install the module account_accountant and a localization, for example l10n_ee.
3. With debug mode on, navigate to the account tags menu
(Configuration > Accounting > Account Tags).
4. Archive any tag using the archive action.
5. On the accounting settings page, under Fiscal Localization, trigger a user error when clicking the reload button.
This user error is blocking.
By making the record inactive, the user has made the account tag no-update, so upgrading the module does not solve this.
- So, as this mentioned commit is introduced in 16.2, any db migrating to v16.2 or further, when the ```_get_tag_mapper``` is triggered this user error is blocking the migration.
**Solution**:
- This commit adds a context to include the inactive tags here: [here](https://github.com/odoo/odoo/blob/saas-16.2/addons/account/models/chart_template.py#L924-L928)
OPW-3716164
UPG-1297494
[TBG-1074](https://upgrade.odoo.com/web#id=1074&cids=1&menu_id=107&action=178&model=upgrade.request.traceback.group&view_type=form)
Forward-Port-Of: odoo/odoo#155516
Forward-Port-Of: odoo/odoo#153944This fix corrects how multi-currency expenses are calculated in the Expenses dashboard. Previously, the system was using today's exchange rate for all expenses regardless of when they were submitted, causing inaccurate totals. Now the system properly applies the exchange rate from the date each expense was made, ensuring accurate financial reporting.
Original PR description
## Issue: - Expenses entered in currencies other than the company currency are incorrectly calculated using today's exchange rate instead of the rate applicable on the date the expense was made. This results in inaccurate totals in the "totals to submit" section of the Expenses dashboard. ## Steps To Reproduce: - Go to Expenses. - See the current total to submit. - Create a new expense that is 999,999 EUR but $1.00 USD. - See that the expenses to submit is not matching the exchange rate we put in the expense. ## Solution: - In the 'get_expense_dashboard' method instead of summing up of 'total_amount_currency' and then converting to the company currency. we sum up directly the 'total_amount' for each expense instead. opw-3731445 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155221