Odoo Changelog — 2024-03-11

Monday, March 11, 2024

4 changes · saas-17.1

Bug Fixes(4)

Resolved issues and error corrections

[FW][FIX] purchase_stock,stock_account: create and reconcile exch diff

Coresaas-17.1accountstock_accountpurchase_stockMedium

This update fixes an issue where exchange rate differences were being incorrectly recorded as journal entries, leading to reconciliation problems. The change ensures that exchange rate differences are handled correctly, preventing duplicate AML creation and improving the accuracy of financial reporting. It adjusts the currency of exchange difference AMLs to zero, aligning with best practices.

Original PR description

When mixing anglo-saxon accounting and multi-currency, it sometimes
leads to incorrect AMLs in the stock-in account

To reproduce the issue:
(Company in USD)
1. Setup some currency rates:
- Yesterday: 1000 EUR = 4335.1 USD
- Today: 1000 EUR = 4348.0 USD
2. Create an auto-avco product
3. (Yesterday) Buy one product at 1000 EUR and receive it
4. Deliver the product
5. Bill the PO
6. Open the journal items of stock-in account

Error: The AML for the exchange difference has been created twice

When posting the bill, it leads to `_generate_price_difference_vals`
where we generate AML/SVL in case of price differences. There, we
also generate such records in case of exchange difference. This is
what we do in the above use case. However, the AML is wrongly
encoded, we need to respect some specific conditions:
https://github.com/odoo/odoo/blob/d780a2fc73259244411329027349fad1cb353f34/addons/account/models/account_move_line.py#L1773-L1779
Otherwise, the reconciliation process won't work correctly and will
generate its own AMLs for the exchange difference (hence the above
error).

On top of that, to ensure a full reconciliation, we need to first
reconcile the exchange diff AML with the bill one. This is what we
are supposed to do in `/stock_account`: we split all stock-in AMLs
into three recordsets: `correction_amls`, `invoice_aml`, `stock_aml`.
However, we don't correctly isolate the correction AMLs. Therefore,
we try to reconcile all AMLs at once, which will not work.

Note: This commit brings a behaviour change since the amount
currency of exch-diff AML will now be zero, as it should (again, see
the comment of the code quoted above in the reconciliation process).
This also explains why this commit modifies an existing test:
comparing the `balance` and the `amount_currency` of such AML is
incorrect.

OPW-3544318

Forward-Port-Of: odoo/odoo#156951
Forward-Port-Of: odoo/odoo#155421

#finance#currency#accounting

[FW][FIX] hr_attendance: Enable high accuracy for geolocation in attendance

PR #157039

Coresaas-17.1hr_attendanceMedium

This update enhances the accuracy of location data recorded during employee attendance. Previously, location information was limited, now it provides a more precise record of where employees are working, improving attendance tracking and reporting. This change ensures better data for payroll and operational insights.

Original PR description

task-3764355

Forward-Port-Of: odoo/odoo#155159

#attendance#geolocation#location tracking

[FW][FIX] l10n_it_edi: ensure receiving a bill produces the right sequence

PR #157168

Coresaas-17.1l10n_it_ediMedium

This update fixes an issue where invoices received into Odoo with an empty MISC journal would incorrectly assign a sequence number, regardless of the invoice type. The fix ensures the sequence is recalculated when the move's type is set, guaranteeing accurate VAT processing for Italian businesses. This improves the reliability of financial data.

Original PR description

Currently, if you have an empty MISC journal and receive a document, that document will be assigned a MISC sequence, regardless of the actual document's type.

### Cause

When a document is received, it is processed in two steps:
1. An empty account move is created and linked with the document.
2. The newly created move is populated with data extracted from the document.

At stage 1, when the move is created, it is temporarily placed in the MISC journal. In the event that this journal is empty, a sequence is assigned to the move. Consequently, even if the move's journal is subsequently changed, the sequence remains unaltered.

### Fix

Manually recompute the sequence when the move's type is set.

opw-3663873

Forward-Port-Of: odoo/odoo#155887

#vat#it#edi#accounting

[FW][FIX] l10n_sa_edi: fix discrepencies in invoice date checks

PR #157152

Coresaas-17.1l10n_sa_ediMedium

This update resolves an issue where Odoo invoices were failing due to timezone discrepancies between the server and user locations. Specifically, when creating invoices near midnight, a date check triggered an error. The fix ensures the system correctly handles timezones, preventing these errors and improving invoice processing reliability.

Original PR description

When trying to process invoices at a time close to Midnight, and the user is using the system from a location different from the hosting location of Odoo, the system tries to check that the date of the invoice is the same as the current date of the system. This creates problems when the hosting server's timezone is different than that of the user. For example: If the hosting location is in Middle East (India), and the user is using Odoo from Saudi Arabia, there is a difference of 2.5 hours due to the timezone, so when the system creates the Invoice at 11 PM and tries to check the date, the date of the server is actually 29th of February, 11 PM while the date on the user's machine is 1st of March, 01:30 AM, which triggers a UserError from the _check_move_configuration function.

Description of the issue/feature this PR addresses:
When trying to process invoices at a time close to Midnight, and the user is using the system from a location different from the hosting location of Odoo, the system tries to check that the date of the invoice is the same as the current date of the system. This creates problems when the hosting server's timezone is different than that of the user. For example: If the hosting location is in Middle East (India), and the user is using Odoo from Saudi Arabia, there is a difference of 2.5 hours due to the timezone, so when the system creates the Invoice at 11 PM and tries to check the date, the date of the server is actually 29th of February, 11 PM while the date on the user's machine is 1st of March, 01:30 AM, which triggers a UserError from the _check_move_configuration function.

Current behavior before PR:
If user is in Saudi and tries to create an invoice at a time close to Midnight, for example at 11 PM, the system throws an error since the timezone of the server and that of the user using the POS are different.

Desired behavior after PR is merged:
The system checks the invoice date against `fields.Date.context_today(self)` instead of `date.today()` and successfully processes the invoice.



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#157048
Forward-Port-Of: odoo/odoo#155824

When mixing anglo-saxon accounting and multi-currency, it sometimes leads to incorrect AMLs in the stock-in account To reproduce the issue: (Company in USD) 1. Setup some currency rates: - Yesterday: 1000 EUR = 4335.1 USD - Today: 1000 EUR = 4348.0 USD 2. Create an auto-avco product 3. (Yesterday) Buy one product at 1000 EUR and receive it 4. Deliver the product 5. Bill the PO 6. Open the journal items of stock-in account Error: The AML for the exchange difference has been created twice When posting the bill, it leads to `_generate_price_difference_vals` where we generate AML/SVL in case of price differences. There, we also generate such records in case of exchange difference. This is what we do in the above use case. However, the AML is wrongly encoded, we need to respect some specific conditions: https://github.com/odoo/odoo/blob/d780a2fc73259244411329027349fad1cb353f34/addons/account/models/account_move_line.py#L1773-L1779 Otherwise, the reconciliation process won't work correctly and will generate its own AMLs for the exchange difference (hence the above error). On top of that, to ensure a full reconciliation, we need to first reconcile the exchange diff AML with the bill one. This is what we are supposed to do in `/stock_account`: we split all stock-in AMLs into three recordsets: `correction_amls`, `invoice_aml`, `stock_aml`. However, we don't correctly isolate the correction AMLs. Therefore, we try to reconcile all AMLs at once, which will not work. Note: This commit brings a behaviour change since the amount currency of exch-diff AML will now be zero, as it should (again, see the comment of the code quoted above in the reconciliation process). This also explains why this commit modifies an existing test: comparing the `balance` and the `amount_currency` of such AML is incorrect. OPW-3544318 Forward-Port-Of: odoo/odoo#156951 Forward-Port-Of: odoo/odoo#155421

Currently, if you have an empty MISC journal and receive a document, that document will be assigned a MISC sequence, regardless of the actual document's type. ### Cause When a document is received, it is processed in two steps: 1. An empty account move is created and linked with the document. 2. The newly created move is populated with data extracted from the document. At stage 1, when the move is created, it is temporarily placed in the MISC journal. In the event that this journal is empty, a sequence is assigned to the move. Consequently, even if the move's journal is subsequently changed, the sequence remains unaltered. ### Fix Manually recompute the sequence when the move's type is set. opw-3663873 Forward-Port-Of: odoo/odoo#155887

When trying to process invoices at a time close to Midnight, and the user is using the system from a location different from the hosting location of Odoo, the system tries to check that the date of the invoice is the same as the current date of the system. This creates problems when the hosting server's timezone is different than that of the user. For example: If the hosting location is in Middle East (India), and the user is using Odoo from Saudi Arabia, there is a difference of 2.5 hours due to the timezone, so when the system creates the Invoice at 11 PM and tries to check the date, the date of the server is actually 29th of February, 11 PM while the date on the user's machine is 1st of March, 01:30 AM, which triggers a UserError from the _check_move_configuration function. Description of the issue/feature this PR addresses: When trying to process invoices at a time close to Midnight, and the user is using the system from a location different from the hosting location of Odoo, the system tries to check that the date of the invoice is the same as the current date of the system. This creates problems when the hosting server's timezone is different than that of the user. For example: If the hosting location is in Middle East (India), and the user is using Odoo from Saudi Arabia, there is a difference of 2.5 hours due to the timezone, so when the system creates the Invoice at 11 PM and tries to check the date, the date of the server is actually 29th of February, 11 PM while the date on the user's machine is 1st of March, 01:30 AM, which triggers a UserError from the _check_move_configuration function. Current behavior before PR: If user is in Saudi and tries to create an invoice at a time close to Midnight, for example at 11 PM, the system throws an error since the timezone of the server and that of the user using the POS are different. Desired behavior after PR is merged: The system checks the invoice date against `fields.Date.context_today(self)` instead of `date.today()` and successfully processes the invoice. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157048 Forward-Port-Of: odoo/odoo#155824