Thursday, January 9, 2025
3 changes · saas-17.4
Resolved issues and error corrections
Invoices in Czech and Hungarian localizations now use the correct business date when calculating and displaying currency exchange rates. This prevents mismatches between the rate shown on the invoice and the amounts posted in journal items, improving financial accuracy and user confidence.
Original PR description
In modules l10n_cz and l10n_hu_edi the currency rate computation on the invoice lines was changed. Instead of using the standard date (i.e. Invoice Date) for the currency conversion we use the…
In modules l10n_cz and l10n_hu_edi the currency rate computation on
the invoice lines was changed. Instead of using the standard date
(i.e. Invoice Date) for the currency conversion we use the
Taxable Supply Date (for l10n_cz / CZ) or Delivery Date
(for l10n_hu_edi / HU).
The way this was done conflicts with a change in 17.3:
Since then we store and display the currency rate on invoices
(See commit bedffa80beb61c134e8f476ef2ca71f2bd66f554 for more details).
The rate for each line should then just be taken from the rate stored on the move.
Currently the rate on the invoice is still computed with the standard date (invoice date)
in any case.
So e.g. with l10n_cz installed it can happen happen that the lines of a CZ invoice
- compute the currency rate individually "themselves" instead of taking it from the invoice
(which is one of the things the change in 17.3 wanted to prevent)
- use a different different date for the currency rate conversion than the invoice
(in case the Taxable Supply Date is set)
I.e. the rate stored and displayed on the invoice may have nothing to do with the rate
that was actually used for the conversion.
Example that goes wrong currently for l10n_cz on runbot
1. Install l10n_cz
2. Select CZ Company
3. Ensure the USD currency is as follows:
- Starting on 2024-12-01 there is 10 units per CZK rate
- There is no other currency rate defined
4. Create an invoice
- in USD
- with invoice date 2024-11-01
- Taxable Supply Date 2024-12-01
- a single invoice line with price 100 and no taxes
5. The invoice displays:
- "1 CZK = 1.000000 USD" (Since we ignore the Taxable Supply Date)
- total: 100 USD
6. The "Journal Items" tab displays only 10 CZK total.
(Since we use the Taxable Supply Date for the actual conversion)
Related commits: The currency rate computations for move lines were overridden
in commits e3bac6461500d34425697eed5a263c605f6f9de5 (l10n_cz) and
b1e07d27da27aad86049c8eae42e1803cf24bd3f (l10n_hu_edi) respectively.
This commit fixes the currency rate computation for these localizations:
We revert the changes to the currency rate computation on the lines and
adapt the date used for the currency rate computation on the invoice.
The invoice then displays the correct rate and the lines just take the (correct)
rate from the invoice.
Further for l10n_cz the taxable supply date is hidden on non-invoices and
ignored for currency computations on non-invoices.
task-4367605
related upgrade PR: https://github.com/odoo/upgrade/pull/6853Point of Sale sessions now better maintain their live connection when other Odoo tabs are open. This helps ensure restaurant orders and table updates continue syncing across devices and browser sessions without manual intervention.
Original PR description
The connection to the bus was sometimes lost in PoS when other Odoo tabs tabs were open. To check whether the PoS channels are still connected, we ask the main worker to return a message with its channels connected. If the PoS channel is not in the list, we reconnect to the bus. The `_getChannels` method is added to `websocket_worker.js`. broadcast the list of channels connected to the various tabs. In `bus_service.js` a variable called `workerChannels` is added to store the list of connected channels. Connected channels are sent by the worker by calling the `getWorkerChannels` method in the bus service. --- How to reproduce: - Open the same PoS restaurant in different browsers or profiles. - Create an order on a table and leave it, you will see the order in the other tabs. - In one of the browsers, open a Meeting Room, this action will close the connection to the bus. In the PoS tab. --- taskId : 4270307
This fix ensures loyalty card data is kept locally when Point of Sale orders are not yet synced or finalized. It helps prevent loyalty information from being lost during offline or pending-order workflows, improving reliability for store operations.
Original PR description
Before this commit, the condition to check the loyalty card to be saved in IndexedDB only kept the loyalty cards related to the finalized orders that were synced. It should keep the items that are not synced or finalized. opw-4257389 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr