Navigate
Branch
Friday, December 13, 2024
49 changes
8 changes
Miscellaneous changes
We need to first check if active_ids exist and get usererror if there are no active_ids present. [Link to Runbot Error builds](https://runbot.odoo.com/web#id=74407&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190324
Original PR description
We need to first check if active_ids exist and get usererror if there are no active_ids present. [Link to Runbot Error builds](https://runbot.odoo.com/web#id=74407&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190324
Add the support for the STORE_SLICE opcode in safe_eval, It looks like an oversight when support for python 3.12 was added. Some code that previously worked in python 3.11 doesn't work anymore on python 3.12 example : foo[:3] = [bar,bar,bar] Forward-Port-Of: odoo/odoo#187867
Original PR description
Add the support for the STORE_SLICE opcode in safe_eval, It looks like an oversight when support for python 3.12 was added. Some code that previously worked in python 3.11 doesn't work anymore on python 3.12 example : foo[:3] = [bar,bar,bar] Forward-Port-Of: odoo/odoo#187867
Before this commit: In case an E-waybill is already generated we post a help message as log note on the invoice with URL that user can check that on the government portal, But whenever user links on the URL it give a error code of 404 In this commit we post the correct URL, and the user is re-directed on the correct page --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190494 Forward-Port-Of: odoo/odoo#190308
Original PR description
Before this commit: In case an E-waybill is already generated we post a help message as log note on the invoice with URL that user can check that on the government portal, But whenever user links on the URL it give a error code of 404 In this commit we post the correct URL, and the user is re-directed on the correct page --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190494 Forward-Port-Of: odoo/odoo#190308
body_content is a better representation of what the email will actually look like when sent. task-4333657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190447 Forward-Port-Of: odoo/odoo#188803
Original PR description
body_content is a better representation of what the email will actually look like when sent. task-4333657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190447 Forward-Port-Of: odoo/odoo#188803
In this commit we fix to two things: 1. For SEZ(intra state) with payment of `IGST`, the `IGST` on Intra used to be sent `False` for E-Invoice 2. For Overseas export, refund claimable is also used to be sent as `False` with same situation payable of `IGST` in case of export In this commit resolve the above issues Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and
Original PR description
In this commit we fix to two things: 1. For SEZ(intra state) with payment of `IGST`, the `IGST` on Intra used to be sent `False` for E-Invoice 2. For Overseas export, refund claimable is also used to be sent as `False` with same situation payable of `IGST` in case of export In this commit resolve the above issues Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190151
Before this commit: We didn't allow passing of `IGST` tax rate while sending E-waybill json to government on an intra state invoice After this commit we allow sending `IGST` tax rate in E-waybill json because there few specific scenario where `IGST` is applicable on intra state transaction e.g. SEZ partner within the company state in this case `IGST` will be applicable --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/o
Original PR description
Before this commit: We didn't allow passing of `IGST` tax rate while sending E-waybill json to government on an intra state invoice After this commit we allow sending `IGST` tax rate in E-waybill json because there few specific scenario where `IGST` is applicable on intra state transaction e.g. SEZ partner within the company state in this case `IGST` will be applicable --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190212
Steps to reproduce the issue: - go to currencies; - search for a rate with something else than a date; - it crashes. This happens because the currency rate model is searched with two fields, a date field (`name`) and a float field (`rate`). This crashes when converting the value to match against, because the value cannot be serialized in SQL both as a date and a float. What we do in such a case is to explicitly convert the value to the field's type. If the conversion fails, we simply
Original PR description
Steps to reproduce the issue: - go to currencies; - search for a rate with something else than a date; - it crashes. This happens because the currency rate model is searched with two fields, a date field (`name`) and a float field (`rate`). This crashes when converting the value to match against, because the value cannot be serialized in SQL both as a date and a float. What we do in such a case is to explicitly convert the value to the field's type. If the conversion fails, we simply ignore that part of the domain. opw-4278234 Forward-Port-Of: odoo/odoo#190495 Forward-Port-Of: odoo/odoo#187838
* STEP TO REPRODUCE: try to _message_log on a channel contain record link (an a tag with data-oe-model and data-oe-link) then click on it -> nothing happen * REASON: when _message_log in mail.channel, it will consider that message as a NotificationMessageView model and we do not have onClick for it unlike MessageView model * SOLUTION: implement onClick for NotificationMessageView just like MessageView Description of the issue/feature this PR addresses: Current behavior before PR: Desi
Original PR description
* STEP TO REPRODUCE: try to _message_log on a channel contain record link (an a tag with data-oe-model and data-oe-link) then click on it -> nothing happen * REASON: when _message_log in mail.channel, it will consider that message as a NotificationMessageView model and we do not have onClick for it unlike MessageView model * SOLUTION: implement onClick for NotificationMessageView just like MessageView Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189811 Forward-Port-Of: odoo/odoo#188380
11 changes
Enhancements to existing features
The editor’s signature option is now available only in the Knowledge app instead of appearing across all editor-based areas. This keeps other apps cleaner and ensures the signature feature is shown only where it is intended to be used.
Original PR description
### Description of the issue/feature this PR addresses: - The signature command was categorized under `BASIC_BLOC` and accessible in all modules using the editor. ### Desired behavior after PR is merged: - The signature command is now categorized under `PERSONALIZATION`. - It is accessible only in the `Knowledge` module. ### Approach: - Removed `SignaturePlugin` from `MAIN_PLUGINS` and added it as extra plugin. - In `html_field`, the `signatureCommand` prop determines whether the signature command is displayed. - Passed `signatureCommand` as `true` from the Knowledge module to enable the signature command. community: https://github.com/odoo/odoo/pull/189554 task-4224624
Miscellaneous changes
Before this commit: Import a statement having transactions including debited charges in their total credited amount. In that case, the retrieved amount is incorrect, it does not include the charges. After this commit: The debited charges are retrieved and included in the amount. opw-3208721 Forward-Port-Of: odoo/enterprise#74962
Original PR description
Before this commit: Import a statement having transactions including debited charges in their total credited amount. In that case, the retrieved amount is incorrect, it does not include the charges. After this commit: The debited charges are retrieved and included in the amount. opw-3208721 Forward-Port-Of: odoo/enterprise#74962
Issue: Clicking the space between buttons but no click on any buttons, a input of "123456789*0#" will be generated. Fix: Do nothing when click in this situation, only generate input when clicking on buttons. Forward-Port-Of: odoo/enterprise#75444
Original PR description
Issue: Clicking the space between buttons but no click on any buttons, a input of "123456789*0#" will be generated. Fix: Do nothing when click in this situation, only generate input when clicking on buttons. Forward-Port-Of: odoo/enterprise#75444
Problem --------- When launching the accounting tours, the don't actually run. This is because, when account_accountant is available, the App menu item name is different than when only Invoicing is available. Furthermore, the last steps of the tours where failing because the buttons had be renamed. Solution --------- When account_accountant is available, the app menu name should be `accountant.menu_accounting`, this is done using a patch of the `goToAccountMenu`. Furthemore, the button na
Original PR description
Problem --------- When launching the accounting tours, the don't actually run. This is because, when account_accountant is available, the App menu item name is different than when only Invoicing is available. Furthermore, the last steps of the tours where failing because the buttons had be renamed. Solution --------- When account_accountant is available, the app menu name should be `accountant.menu_accounting`, this is done using a patch of the `goToAccountMenu`. Furthemore, the button names for the last steps have been updated accordingly and a few extra steps have been added to generate a transaction. task-4309716 odoo/odoo/pull/188073 Forward-Port-Of: odoo/enterprise#74092
When a grid view is removed we should cascade the removal to the window actions mapping. Grid views are considered experimental. They do not have a `_get_default_grid_view` method, and crafting an acceptable general one is close to impossible due to grid views' requirements in terms of the model fields. Allowing the grid mapping for window actions have been proven to cause issues during upgrades if clients uninstall one of the few modules providing grid views (like analytic_enterprise). Forw
Original PR description
When a grid view is removed we should cascade the removal to the window actions mapping. Grid views are considered experimental. They do not have a `_get_default_grid_view` method, and crafting an acceptable general one is close to impossible due to grid views' requirements in terms of the model fields. Allowing the grid mapping for window actions have been proven to cause issues during upgrades if clients uninstall one of the few modules providing grid views (like analytic_enterprise). Forward-Port-Of: odoo/enterprise#75561 Forward-Port-Of: odoo/enterprise#74912
Steps to reproduce 1. Install account_followup and contacts 2. Have a branch company 3. Have a user with only the branch in its allowed companies (setting in the "Access rights" tab) 4. With this user, go to Contacts and click on any contact. ** Access Error: Access to unauthorized or invalid companies. ** Cause Commit https://github.com/odoo/enterprise/commit/fb59524a95b0f78112002d1e4d5ad3d6c301de7e modified the way company dependent fields work, which reveals an access error issue: a
Original PR description
Steps to reproduce 1. Install account_followup and contacts 2. Have a branch company 3. Have a user with only the branch in its allowed companies (setting in the "Access rights" tab) 4. With this user, go to Contacts and click on any contact. ** Access Error: Access to unauthorized or invalid companies. ** Cause Commit https://github.com/odoo/enterprise/commit/fb59524a95b0f78112002d1e4d5ad3d6c301de7e modified the way company dependent fields work, which reveals an access error issue: a user may not have access to the root company of the currently selected company. Change Currently `.with_company(self.env.company.root_id.id)` has no effect, remove it to fix access error. opw-4368736 Forward-Port-Of: odoo/enterprise#75044
Steps to Produce: - Configure Urban Piper in your POS. - Open the particular session. - Configure preparation display. - Place test order and accept in through POS. - Order gets placed in Kitchen display. - Done the order from Kitchen Display. - Order status does not get updated in POS without reloading it. Issue: - Order status was not updated when the order was done from the Kitchen display. Fix: - Initially, only draft orders were fetched from the server but now all orders are
Original PR description
Steps to Produce: - Configure Urban Piper in your POS. - Open the particular session. - Configure preparation display. - Place test order and accept in through POS. - Order gets placed in Kitchen display. - Done the order from Kitchen Display. - Order status does not get updated in POS without reloading it. Issue: - Order status was not updated when the order was done from the Kitchen display. Fix: - Initially, only draft orders were fetched from the server but now all orders are been fetched from server that belongs to urbanPiper. task- 4320193 Forward-Port-Of: odoo/enterprise#73884
In this commit: === - Added `pos_urban_piper.is_production_mode` parameter to toggle between production and integration environments. Forward-Port-Of: odoo/enterprise#75375
Original PR description
In this commit: === - Added `pos_urban_piper.is_production_mode` parameter to toggle between production and integration environments. Forward-Port-Of: odoo/enterprise#75375
The way we initially implemented CTA, it was using the current rate for all the balance sheet accounts. Instead, we actually want to consider the closing rate ; that is, the rate of each currency at the end of the fiscal year the operation was made in. Current rate currency translation is still applied like before when CTA is not enabled on the report. task-4270102 ========================================================================== [IMP] account_reports: currency table: add te
Original PR description
The way we initially implemented CTA, it was using the current rate for all the balance sheet accounts. Instead, we actually want to consider the closing rate ; that is, the rate of each currency at…
The way we initially implemented CTA, it was using the current rate for all the balance sheet accounts. Instead, we actually want to consider the closing rate ; that is, the rate of each currency at the end of the fiscal year the operation was made in. Current rate currency translation is still applied like before when CTA is not enabled on the report. task-4270102 ========================================================================== [IMP] account_reports: currency table: add test case If a period containing some res.currency.rate object starts by some sub-period without any range, the average rate computation considered this sub-period as having a rate of 0. It's wrong; it should be 1. The fix itself is in the corresponding community commit ; this one adds a check ensuring this doesn't break again in the future. Fixing this also revealed an issue in the Trial Balance, where the initial balance column group was computed with different rates than the rest of the report, which is not what we want for this instance. We fix that by properly setting the period_key on all of its column groups and ensuring the initial balance dates have no impact on the currency table. Forward-Port-Of: odoo/enterprise#75140
### Steps to reproduce: - Install 'account_iso20022' - Accounting > Vendors > Payments - Create a new payment with "SEPA Credit Transfer" as the payment method, confirm - Duplicate it and confirm - Back to the payment list view, select the two and click "Create Batch Payment" - Validate and check the generated XML - `Ctry` is missing in the `PstlAdr` ### Cause: The ´_get_PstlAdr´ method in `account_journal_sepa_ct.py` is returning the whole `PstlAdr` element but the country code is mi
Original PR description
### Steps to reproduce: - Install 'account_iso20022' - Accounting > Vendors > Payments - Create a new payment with "SEPA Credit Transfer" as the payment method, confirm - Duplicate it and confirm - Back to the payment list view, select the two and click "Create Batch Payment" - Validate and check the generated XML - `Ctry` is missing in the `PstlAdr` ### Cause: The ´_get_PstlAdr´ method in `account_journal_sepa_ct.py` is returning the whole `PstlAdr` element but the country code is missing. Previously the country code was always added (https://github.com/odoo/enterprise/blob/saas-17.4/account_sepa/models/account_journal.py#L322-L329), this is no longer the case in this situation. ### Solution: Add the country to the list of fields to add. opw-4287100 Forward-Port-Of: odoo/enterprise#74596
First we replaced the 'send' activity by the 'pay' activity. Since the 'pay' activity was inadequate for the FIDU /my/databases view (it's only created when there is tax to pay), we brought the 'send' activity back. But in order to see the 'pay' activity, the 'send' activity had to be marked as done & nobody knows how to do that. And what if the user wants to pay before sending? (to avoid fines) So in this PR, we create the 'send' and 'pay' acitivities at the same time. Those who want to send
Original PR description
First we replaced the 'send' activity by the 'pay' activity. Since the 'pay' activity was inadequate for the FIDU /my/databases view (it's only created when there is tax to pay), we brought the 'send' activity back. But in order to see the 'pay' activity, the 'send' activity had to be marked as done & nobody knows how to do that. And what if the user wants to pay before sending? (to avoid fines) So in this PR, we create the 'send' and 'pay' acitivities at the same time. Those who want to send, send. And those who want to pay, pay. Task - TSB/BIB/CHKL/AYH discussion Forward-Port-Of: odoo/enterprise#75317 Forward-Port-Of: odoo/enterprise#74915
25 changes
Enhancements to existing features
The emoji picker has been refreshed visually in both light and dark modes, making it easier and more pleasant to use. Keyboard navigation and search results were also improved, helping users find and insert emojis more quickly in conversations.
Original PR description
Also improve keyboard navigation. Also improve search results. Backport of https://github.com/odoo/odoo/pull/189975 Before / After (white) <img width="288" alt="Screenshot 2024-12-09 at 12 23 52" src="https://github.com/user-attachments/assets/6ba233da-820b-4a00-86f5-d65e8df8b49f"> <img width="286" alt="Screenshot 2024-12-12 at 17 32 37" src="https://github.com/user-attachments/assets/0b9e68d9-c6d1-43d9-a679-2362d4f805e0" /> Before / After (dark) <img width="289" alt="Screenshot 2024-12-09 at 12 24 00" src="https://github.com/user-attachments/assets/0422ac98-d73c-4132-9d73-a37087444013"> <img width="287" alt="Screenshot 2024-12-12 at 17 32 27" src="https://github.com/user-attachments/assets/c661bb17-5b66-4be5-81a4-26106a809f5c" />
Users will now see a clear warning in the interface when Odoo Discuss is not working. This helps reduce confusion and makes service issues visible instead of leaving users unsure why messaging is unavailable.
Payments that use a bank account as the outstanding account are now automatically marked as validated when created. This prevents payments from remaining stuck “In process” when businesses intentionally skip reconciliation to create accounting entries more quickly.
Original PR description
### Purpose Since the Payment without Entry, we've added new Payment Statuses on the payment. We've already added some heuristics to automatically mark payments as validated when the payment is reconciled. But we allow the users to set Bank accounts directly as Outstanding. It's often used by people who want to easily get their Accounting entry created, but they want to skip the reconciliation process. The problem is that, as the reconciliation is skipped, the auto-validation heuristic is never applied, and so all those payments stay "In process". ### Implementation If the Outstanding account set on the Payment Method is of type Bank, the payment is auto-validated once created. task-4392152
Resolved issues and error corrections
This fix prevents Odoo workers from repeatedly reloading internal data or clearing caches when requests use read-only database replicas. It improves stability and resource usage for deployments using database replication, while keeping normal request handling on the intended database mode.
Original PR description
The PostgreSQL streaming physical replication notably does not synchonize sequence data[^1]. For sequences that are only used to generate unique IDs (for primary keys), this is not a concern because…
The PostgreSQL streaming physical replication notably does not synchonize sequence data[^1].
For sequences that are only used to generate unique IDs (for primary keys), this is not a concern because those IDs *will be* replicated correctly.
However it's a different story for sequences that are used directly. For us it means that on read-only cursors targeting database replicas, the registry and cache generation numbers (`base_registry_signaling` and `base_cache_signaling_*`) will remain fixed and out of sync with the values on the read-write master database.
As a consequence, workers serving alternating read-write and read-only requests will keep reloading the registry or discarding caches, because they will jump between the progressing master sequences, and the fixed sequences on the replica.
For HTTP workers this causes a peformance hit and suboptimal usage of resources, as the registry will be needlessly reloaded after a "sequence jump", or caches discarded.
For Gevent workers it may be much worse, because the registry reloading will *yield* and may be started by hundreds of different greenlets, blocking as many database connections, until the connection pool is exhausted. Repeat and rinse...
Note that the problem could manifest even for a worker that only ever processes read-write requests (like Gevent), because the registry and signaling checks were explicitly done in read-only mode.
As a mitigation, this patch forces the cursor mode to "read-write" during the registry loading and signaling checks, regardless of the actual request mode. This causes some minimal extra load on the master database, but ensures that the signaling checks will always use the correct sequences. The actual request handling, which is the costly part, will still be executed in the dynamically selected cursor mode.
PS: this patch does not change the possibility of having a pure read-only server, with a replica connection used for both the read-write and read-only database connections in the config. One should however be aware that the signaling sequences will never advance, so the replica will not receive the signals.
-----
Note: in master we could overcome this limitation by defining an explicit append-only `base_signal` table, with an `id` PK column driven by a sequence, like all tables. Then, whenever we want to trigger a signal, we would simply insert a row in the table with the corresponding signal:
```sql
CREATE TABLE base_signal (
id SERIAL PRIMARY KEY,
signal VARCHAR
);
-- increment signal `registry`
INSERT INTO base_signal (signal) VALUES ('registry')
-- check current signal `registry`:
SELECT max(id) FROM base_signal WHERE signal = 'registry';
```
The `base_signal` table would be properly synchronized and visible on replicas, and could be trivially garbage collected by the autovacuum system. As a bonus, it would also make signaling transactional, in the sense that a transaction would be unable to trigger a signal and then rollback due to a later error. The sequence ID might advance, but the row won't be inserted.
Cfr task-4399456
[^1]: https://www.postgresql.org/docs/16/logical-replication-restrictions.htmlThe Discuss sidebar now visually de-emphasizes inactive conversations so the active chat remains easier to focus on. Unread conversations still stand out enough to be noticed, improving usability without changing functionality.
Original PR description
Discuss sidebar items are too catchy, which is distracting when the core part of Discuss app is the conversation itself. As much as possible, conversation should be very visible while other elements are slightly less visible. This problem is even more pronunced when the sidebar is compact, because the avatars in sidebar are next to avatars of conversation, which is even more distracting. This commit fixes the issue by reducing opacity slightly on non-active sidebar items. Conversation that are unread and unactive have an in-between opacity so they are more visible than other read and non-active conversations but still have reduced opacity so that this is less distracting than the conversation itself. Backport of https://github.com/odoo/odoo/pull/190071
This fixes an error that could occur when adding image icons to email templates. Users can now save templates with icons reliably, reducing interruptions when preparing branded or visual email communications.
Original PR description
Currently, an error occurs when using an image icon in the email template. Step to produce: - Install the ```mail``` module. - Go to Settings / Technical / Email / Email Templates, and open any templates. - Insert any image icon, and save the record. ValueError: `unknown color specifier: '1x1'` An error occurred when attempting to retrieve computed styles for the element during inlining converting. Specifically, when the system tries to fetch the color code and other CSS properties, it returns empty values because `getComputedStyle` fails to properly access the full set of styles from the cloned element. This is because `getComputedStyle` cannot retrieve styles from an element when it is detached from DOM (a cloned element not in a DOM). To resolve this issue, The cloned element is temporarily added to the DOM,So `getComputedStyle` access the required style properties. Ref:- https://drafts.csswg.org/cssom/#dom-window-getcomputedstyle Sentry-5747299019
The HTML editor now correctly enables the remove formatting button when any selected content includes formatting, even if other selected text is plain. This makes editing formatted content more predictable and prevents users from being blocked from clearing styles in mixed selections.
Original PR description
When the selection contains formatted nodes among unformatted nodes, the remove format toolbar button should be available. This is not the case currently because the `hasAnyFormat` method, which is used to determine whether the button should be disabled, checks if **every** node in the selection is formatted. This commit fixes the issue by checking if **any** node in the selection is formatted instead. task-4385246
Fixes an error that occurred when users clicked the “Same payment” link after duplicating a confirmed payment. The payment screen now opens the related business document correctly, preventing an unexpected interruption in accounting workflows.
Original PR description
In the payment view, he `x2many_buttons` widget on `duplicate_payment_ids` calls the `action_open_business_doc`, but this method is not implemented on `account.payment`. This was not not a problem before 01b87f1230beac0568f4e3b1b76e547909506892 since a payment was always linked to a move, therefore we were calling the method from `account.move`. With this commit, we implement the `action_open_business_doc` in `account.payment`. Step: - Create a payment and confirm - Duplicate it - Click on the 'Same payment' hyperlink -> Error: "The method 'action_open_business_doc' does not exist on the model 'account.payment'" opw-4363907
Fleet contract status changes now use the same internal actions whether they are triggered automatically or by date updates. This makes custom behavior for opening or closing contracts easier to maintain and reduces the risk of inconsistent contract handling.
Original PR description
Since there are two mechanism that changes the status of a contract (a cron and the write of a date), we have to override 2 different places when we want to add a behavior on closing or opening of contracts. As there are already functions (action_expire, ...) that exist and are use in the write part, we also use them in the cron, so we'll have only one place where we need to override it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in Documents where opening a folder could fail after previewing a file, closing the preview, and switching views. Users can now continue navigating folders normally without encountering an error.
Original PR description
Steps to reproduce the traceback: - preview a file from the kanban view - close the preview - switch to list view - open a folder To Be: The folder should open correctly. Technical: The traceback happens because the 'getSelectedDocumentsElements' calls a querySelectorAll on the component root element without checking if it exists. Fixing the issue by making sure the component effectively have a root element before calling the method. Task-4373626
Miscellaneous changes
Before this commit: We didn't allow passing of `IGST` tax rate while sending E-waybill json to government on an intra state invoice After this commit we allow sending `IGST` tax rate in E-waybill json because there few specific scenario where `IGST` is applicable on intra state transaction e.g. SEZ partner within the company state in this case `IGST` will be applicable --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/o
Original PR description
Before this commit: We didn't allow passing of `IGST` tax rate while sending E-waybill json to government on an intra state invoice After this commit we allow sending `IGST` tax rate in E-waybill json because there few specific scenario where `IGST` is applicable on intra state transaction e.g. SEZ partner within the company state in this case `IGST` will be applicable --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190557 Forward-Port-Of: odoo/odoo#190212
* STEP TO REPRODUCE: try to _message_log on a channel contain record link (an a tag with data-oe-model and data-oe-link) then click on it -> nothing happen * REASON: when _message_log in mail.channel, it will consider that message as a NotificationMessageView model and we do not have onClick for it unlike MessageView model * SOLUTION: implement onClick for NotificationMessageView just like MessageView Description of the issue/feature this PR addresses: Current behavior before PR: Desi
Original PR description
* STEP TO REPRODUCE: try to _message_log on a channel contain record link (an a tag with data-oe-model and data-oe-link) then click on it -> nothing happen * REASON: when _message_log in mail.channel, it will consider that message as a NotificationMessageView model and we do not have onClick for it unlike MessageView model * SOLUTION: implement onClick for NotificationMessageView just like MessageView Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189811 Forward-Port-Of: odoo/odoo#188380
Before this commit: In case an E-waybill is already generated we post a help message as log note on the invoice with URL that user can check that on the government portal, But whenever user links on the URL it give a error code of 404 In this commit we post the correct URL, and the user is re-directed on the correct page --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190547 Forward-Port-Of: odoo/odoo#190308
Original PR description
Before this commit: In case an E-waybill is already generated we post a help message as log note on the invoice with URL that user can check that on the government portal, But whenever user links on the URL it give a error code of 404 In this commit we post the correct URL, and the user is re-directed on the correct page --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190547 Forward-Port-Of: odoo/odoo#190308
### Context: In its current form, the HTTP route using `/rate/<string:token>/<int:rate>`, that is used in URL links generated by emails asking for customer feedback, will have a "one-click write" behavior that commits the rating encoded in `<int:rate>`. So the record is already updated with the new value. Only then renders the feedback submit Form, where the user can change their preselected rating and leave a commentary before submitting it via a POST request. Over the last years email prov
Original PR description
### Context: In its current form, the HTTP route using `/rate/<string:token>/<int:rate>`, that is used in URL links generated by emails asking for customer feedback, will have a "one-click write"…
### Context: In its current form, the HTTP route using `/rate/<string:token>/<int:rate>`, that is used in URL links generated by emails asking for customer feedback, will have a "one-click write" behavior that commits the rating encoded in `<int:rate>`. So the record is already updated with the new value. Only then renders the feedback submit Form, where the user can change their preselected rating and leave a commentary before submitting it via a POST request. Over the last years email providers and third party services will preemptively crawl URL in emails to verify if they are "dangerous" (e.g. Microsoft's Safe link and Defender fatures). By doing so, the rating for the records will be set to the last clicked URL using the above HTTP route, without any input from a human user. It will be creating a number of false positive or negative ratings that do not represent the real satisfaction of the surveyed customer. ### Proposed solution: We are removing the implicit "one-click write" behavior of the route and favoring the Form submission expecting human input. This will increase the likelihood a given rating was the result of the customer clicking on the link and taking the time to leave a feedback, versus random inputs from URL bots. ### Future outlook: With the ever-changing landscape of URL crawler bots, trying to develop counter measures to identify and flag bot behavior is possible, but would add immense overhead and maintenance cost of the code for an arguably minor feature, i.e. the customer can rate the ticket by just clicking the picture in the email. Other methods to make these routes more resilient to URL crawlers might be revisited in the future, but for the short-term this seems like a sufficient solution to the unwanted behavior. OPW-3411799 OPW-4292166 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190400 Forward-Port-Of: odoo/odoo#187373
Steps to reproduce the issue: - go to currencies; - search for a rate with something else than a date; - it crashes. This happens because the currency rate model is searched with two fields, a date field (`name`) and a float field (`rate`). This crashes when converting the value to match against, because the value cannot be serialized in SQL both as a date and a float. What we do in such a case is to explicitly convert the value to the field's type. If the conversion fails, we simply
Original PR description
Steps to reproduce the issue: - go to currencies; - search for a rate with something else than a date; - it crashes. This happens because the currency rate model is searched with two fields, a date field (`name`) and a float field (`rate`). This crashes when converting the value to match against, because the value cannot be serialized in SQL both as a date and a float. What we do in such a case is to explicitly convert the value to the field's type. If the conversion fails, we simply ignore that part of the domain. opw-4278234 Forward-Port-Of: odoo/odoo#190495 Forward-Port-Of: odoo/odoo#187838
Add the support for the STORE_SLICE opcode in safe_eval, It looks like an oversight when support for python 3.12 was added. Some code that previously worked in python 3.11 doesn't work anymore on python 3.12 example : foo[:3] = [bar,bar,bar] Forward-Port-Of: odoo/odoo#187867
Original PR description
Add the support for the STORE_SLICE opcode in safe_eval, It looks like an oversight when support for python 3.12 was added. Some code that previously worked in python 3.11 doesn't work anymore on python 3.12 example : foo[:3] = [bar,bar,bar] Forward-Port-Of: odoo/odoo#187867
### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Warehouses - Create a second warehouse - Go to Inventory > Products > Products - In the search bar type `foo` string > Search Warehouse for `foo` - Click on any product Kandan record - Click on the Forecast smart button of the product #### > Traceback ### Cause of the issue: Thanks to the dummy `warehouse_id` field of the `product.template` model a `warehouse` context key can be set in the context from th
Original PR description
### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Warehouses - Create a second warehouse - Go to Inventory > Products > Products - In the search bar type `foo` string >…
### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Warehouses - Create a second warehouse - Go to Inventory > Products > Products - In the search bar type `foo` string > Search Warehouse for `foo` - Click on any product Kandan record - Click on the Forecast smart button of the product #### > Traceback ### Cause of the issue: Thanks to the dummy `warehouse_id` field of the `product.template` model a `warehouse` context key can be set in the context from the search bar: https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L685 https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/views/product_views.xml#L78 This trick is notably used in order to take the warehouse into account in the computation of the various quantity fields associated to products by generating custom location domains: https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L136-L137 https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L250-L255 However, since that context key was added via the search bar, it type might be: a string, an integerId or a list of either/both other types. (E.g. to create a list of a string and integer type and select a string and then type a string allowing you to find a real warehouse id that you can select after clicking on the dropdown arrow). Therefore, in order to be properly used, this context key needs to be parsed to be used properly as done in the `_get_domain_locations` for instance. However, the `warehouse` context key is used at many other places in the code, each time expecting a single integer id, and since the warehouse context key is not cleaned from one action to an other you are technically able to provide a string where the code is expecting a an integer. ### Fix: The proper fix of this use case would be to change the context key name used by the search view to only match flows expecting such a context. However, this change is not stable as it requires to modify a view and hence can't be applied before master (18.1). As such, in prior versions, we add a context parser for to extract a single integer id from the `warehouse` context key where it is used but unexpected to match something else. ### Note: This patch will improve other fixes and hopefully prevent yet unoticed error raised by this issue: 903d8beeea5d332e556ef81e231a3b8b4c51cd45 and afa7c6bf25c9de5fc0c878faa29e1cc35bc11805 opw-4290818 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189904 Forward-Port-Of: odoo/odoo#187413
body_content is a better representation of what the email will actually look like when sent. task-4333657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190447 Forward-Port-Of: odoo/odoo#188803
Original PR description
body_content is a better representation of what the email will actually look like when sent. task-4333657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190447 Forward-Port-Of: odoo/odoo#188803
Before this commit, when a user returns back, e.g. to the floor screen after clicking "order" but before the call to sendOrderInPreparationUpdateLastChange completed, the update to the order would not come through. This specifically happens when a lengthy operation is performed in the calls behind the "order" button, such as calling preparation printers. Example steps to reproduce 1. set up a clean DB with pos_restaurant installed 2. configure an epson printer as preparation printer 3.
Original PR description
Before this commit, when a user returns back, e.g. to the floor screen after clicking "order" but before the call to sendOrderInPreparationUpdateLastChange completed, the update to the order would…
Before this commit, when a user returns back, e.g. to the floor screen after clicking "order" but before the call to sendOrderInPreparationUpdateLastChange completed, the update to the order would not come through. This specifically happens when a lengthy operation is performed in the calls behind the "order" button, such as calling preparation printers. Example steps to reproduce 1. set up a clean DB with pos_restaurant installed 2. configure an epson printer as preparation printer 3. open the POS session 4. select a table and add some products 5. click on "order" and immediately click on "back" The order status is still in the "to be sent" state, while the printer effectively printed the order. You now have to get back to the table view and send the order changes again if you ever want to complete any payment for that order. It will then send it again to the preparation printer. The end result is inconsistencies between the pos session and the database in terms of data. In terms of business flows and operations, it results in multiple sends of the same order, which in turn could lead to losses e.g. due to wrong preparations/unneeded preparations. opw-4367939 opw-4246953 Forward-Port-Of: odoo/odoo#189749
When preparing final outgoing email, partner email is normalized. We take their formatted email, which is their name and their normalized email. However email_to and email_cc are taken from input using 'email_split(_and_format)', which finds emails but do not format them. This leads to incoherent behavior as most emails are normalized as we generally always use partners, but not all. In this commit we now split, normalize and format email_to and email_cc in outgoing emails. This fixes a fi
Original PR description
When preparing final outgoing email, partner email is normalized. We take their formatted email, which is their name and their normalized email. However email_to and email_cc are taken from input…
When preparing final outgoing email, partner email is normalized. We take their formatted email, which is their name and their normalized email. However email_to and email_cc are taken from input using 'email_split(_and_format)', which finds emails but do not format them. This leads to incoherent behavior as most emails are normalized as we generally always use partners, but not all. In this commit we now split, normalize and format email_to and email_cc in outgoing emails. This fixes a first issue where name are lost if a formatted email was entered in email_cc field. Only address was kept, now the name is correctly found and put back. This also fixes an issue for validated email detection, in order to compare normalized emails. This was introduced at odoo/odoo#185793 and may skip valid emails entered in email_to or email_cc. This commit backports a tool introduced at odoo/odoo@dd4709e579841672b0c2a57d5f2941f3ce770801 which aims at allowing a quick convert from a string holding emails to a list of nicely formatted emails, using normalize version of email addresses. This is the standard we use in most flows. Task-4376876 Followup of task-3704658 Forward-Port-Of: odoo/odoo#190531 Forward-Port-Of: odoo/odoo#189409
Before this commit: Import a statement having transactions including debited charges in their total credited amount. In that case, the retrieved amount is incorrect, it does not include the charges. After this commit: The debited charges are retrieved and included in the amount. opw-3208721 Forward-Port-Of: odoo/enterprise#74962
Original PR description
Before this commit: Import a statement having transactions including debited charges in their total credited amount. In that case, the retrieved amount is incorrect, it does not include the charges. After this commit: The debited charges are retrieved and included in the amount. opw-3208721 Forward-Port-Of: odoo/enterprise#74962
Issue: Clicking the space between buttons but no click on any buttons, a input of "123456789*0#" will be generated. Fix: Do nothing when click in this situation, only generate input when clicking on buttons. Forward-Port-Of: odoo/enterprise#75444
Original PR description
Issue: Clicking the space between buttons but no click on any buttons, a input of "123456789*0#" will be generated. Fix: Do nothing when click in this situation, only generate input when clicking on buttons. Forward-Port-Of: odoo/enterprise#75444
Steps to reproduce: - Install the planning module. - Open Gantt view in day scale. - Create a planning slot from 11am to 12pm for an employee whose working hours are 8-12 and 13-17 - The default hours will be shown as 13 to 12 Issue: - When an employee works two shifts for example 8-12 and 13-17, and we are creating a slot from 11-12, the slot timing will show as 13-12 instead of 8-12. Cause: - here is an example of how the planning slot will be calculated and what i
Original PR description
Steps to reproduce: - Install the planning module. - Open Gantt view in day scale. - Create a planning slot from 11am to 12pm for an employee whose working hours are 8-12 and 13-17 - The default…
Steps to reproduce: - Install the planning module. - Open Gantt view in day scale. - Create a planning slot from 11am to 12pm for an employee whose working hours are 8-12 and 13-17 - The default hours will be shown as 13 to 12 Issue: - When an employee works two shifts for example 8-12 and 13-17, and we are creating a slot from 11-12, the slot timing will show as 13-12 instead of 8-12. Cause: - here is an example of how the planning slot will be calculated and what is miscalculation - When click on cell 9-10 the calculated hours <table><thead><tr><th>Cell</th><th>shift start time </th><th>shift end time </th></tr></thead><tbody><tr><td>9-10</td><td>|8 - 9| = 1<br>|13 - 9| = 4<br></td><td>|12 - 10| = 2<br>|17 - 10| = 5<br></td></tr><tr><td>minimum</td><td>8</td><td>12</td></tr></tbody></table> so that slot timining will be 8 - 12 - When click on cell 11-12 <table><tbody><tr><td>Cell</td><td>shift start time </td><td>shift end time </td></tr><tr><td>11-12</td><td>|8 - 11| = 3<br>|13 - 11| = 2<br></td><td>|12 - 12| = 0<br>|17 - 12| = 5<br></td></tr><tr><td>minimum</td><td>13</td><td>12</td></tr></tbody></table> So that the slot timining will be 13-12 which should not be possible Fix: - We previously relied on the ```_adjust_to_calendar``` method to calculate the resource's working hours. However since the working hour intervals are already computed using ```_work_intervals_batch```, we are removing the method call to reduce code duplication. Calculate the working hours using ```_work_intervals_batch``` and return the appropriate work intervals based on the resource's working calendar. task-3916687 Forward-Port-Of: odoo/enterprise#75594 Forward-Port-Of: odoo/enterprise#64961
### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Warehouses - Create a second warehouse - Go to Inventory > Products > Products - In the search bar type `foo` string > Search Warehouse for `foo` - Click on any product Kandan record - Click on the Forecast smart button of the product #### > Traceback ### Cause of the issue: Thanks to the dummy `warehouse_id` field of the `product.template` model a `warehouse` context key can be set in the context from th
Original PR description
### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Warehouses - Create a second warehouse - Go to Inventory > Products > Products - In the search bar type `foo` string >…
### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Warehouses - Create a second warehouse - Go to Inventory > Products > Products - In the search bar type `foo` string > Search Warehouse for `foo` - Click on any product Kandan record - Click on the Forecast smart button of the product #### > Traceback ### Cause of the issue: Thanks to the dummy `warehouse_id` field of the `product.template` model a `warehouse` context key can be set in the context from the search bar: https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L685 https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/views/product_views.xml#L78 This trick is notably used in order to take the warehouse into account in the computation of the various quantity fields associated to products by generating custom location domains: https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L136-L137 https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L250-L255 However, since that context key was added via the search bar, it type might be: a string, an integerId or a list of either/both other types. (E.g. to create a list of a string and integer type and select a string and then type a string allowing you to find a real warehouse id that you can select after clicking on the dropdown arrow). Therefore, in order to be properly used, this context key needs to be parsed to be used properly as done in the `_get_domain_locations` for instance. However, the `warehouse` context key is used at many other places in the code, each time expecting a single integer id, and since the warehouse context key is not cleaned from one action to an other you are technically able to provide a string where the code is expecting a an integer. ### Fix: The proper fix of this use case would be to change the context key name used by the search view to only match flows expecting such a context. However, this change is not stable as it requires to modify a view and hence can't be applied before master (18.1). As such, in prior versions, we add a context parser for to extract a single integer id from the `warehouse` context key where it is used but unexpected to match something else. ### Note: This patch will improve other fixes and hopefully prevent yet unoticed error raised by this issue: 903d8beeea5d332e556ef81e231a3b8b4c51cd45 and afa7c6bf25c9de5fc0c878faa29e1cc35bc11805 Community: https://github.com/odoo/odoo/pull/187808 opw-4290818 X-original-commit: 856409a1fb35c6c49fe4c404931587a95d99d370 Forward-Port-Of: odoo/enterprise#75300 Forward-Port-Of: odoo/enterprise#74188
When a grid view is removed we should cascade the removal to the window actions mapping. Grid views are considered experimental. They do not have a `_get_default_grid_view` method, and crafting an acceptable general one is close to impossible due to grid views' requirements in terms of the model fields. Allowing the grid mapping for window actions have been proven to cause issues during upgrades if clients uninstall one of the few modules providing grid views (like analytic_enterprise). Forw
Original PR description
When a grid view is removed we should cascade the removal to the window actions mapping. Grid views are considered experimental. They do not have a `_get_default_grid_view` method, and crafting an acceptable general one is close to impossible due to grid views' requirements in terms of the model fields. Allowing the grid mapping for window actions have been proven to cause issues during upgrades if clients uninstall one of the few modules providing grid views (like analytic_enterprise). Forward-Port-Of: odoo/enterprise#75561 Forward-Port-Of: odoo/enterprise#74912
5 changes
Resolved issues and error corrections
This update fixes an issue where bank statement imports were not accurately capturing debited charges. Now, the system correctly includes these charges in the imported transaction amounts, ensuring more precise financial reporting. This improves the reliability of bank statement data within the Enterprise system.
Original PR description
Before this commit: Import a statement having transactions including debited charges in their total credited amount. In that case, the retrieved amount is incorrect, it does not include the charges. After this commit: The debited charges are retrieved and included in the amount. opw-3208721 Forward-Port-Of: odoo/enterprise#74962
This update resolves a stability issue in the consolidated balance report. Previously, an empty totals list could cause a crash. The fix ensures that the report only attempts to modify data when totals are present, preventing errors and improving reliability.
Original PR description
**[FIX] account_consolidation: handle empty totals when formatting account lines** When processing account lines, the totals list might be empty resulting in an IndexError when trying to set auditable to false on the last column, which leads to consolidated balance to crash. This fix just makes sure that modifying the column on this line is only done when the cols actually contains some data. opw-4205722
This update resolves an issue where the system incorrectly attempted to raise an error message when a bank account lacked a client code. The fix corrects a coding error that was passing multiple arguments to the `append` function, ensuring proper error handling and preventing the system from crashing.
Original PR description
An error occurs when the system try to raise an error message when a bank account has not client code. ```TypeError: list.append() takes no keyword arguments``` Currently in code [1] mistakenly provides multiple values via keyword arguments to the `append` method. which is incorrect. So instead of it, we need to change the formatting to pass a single argument as a string to resolve the error. Link [1]: https://github.com/odoo/enterprise/blob/07fae63e381dfa7a8035f67837f19d619600d434/l10n_jp_zengin/models/account_batch_payment.py#L77 Sentry-6128197646
This update fixes a bug where shift times were incorrectly displayed in the Gantt view for employees with multiple shifts. The change streamlines the calculation process by directly using the `_work_intervals_batch` method, ensuring accurate shift hour assignments. This prevents shifts from being shown with incorrect start and end times.
Original PR description
Steps to reproduce: - Install the planning module. - Open Gantt view in day scale. - Create a planning slot from 11am to 12pm for an employee whose working hours are 8-12 and 13-17 - The default…
Steps to reproduce: - Install the planning module. - Open Gantt view in day scale. - Create a planning slot from 11am to 12pm for an employee whose working hours are 8-12 and 13-17 - The default hours will be shown as 13 to 12 Issue: - When an employee works two shifts for example 8-12 and 13-17, and we are creating a slot from 11-12, the slot timing will show as 13-12 instead of 8-12. Cause: - here is an example of how the planning slot will be calculated and what is miscalculation - When click on cell 9-10 the calculated hours <table><thead><tr><th>Cell</th><th>shift start time </th><th>shift end time </th></tr></thead><tbody><tr><td>9-10</td><td>|8 - 9| = 1<br>|13 - 9| = 4<br></td><td>|12 - 10| = 2<br>|17 - 10| = 5<br></td></tr><tr><td>minimum</td><td>8</td><td>12</td></tr></tbody></table> so that slot timining will be 8 - 12 - When click on cell 11-12 <table><tbody><tr><td>Cell</td><td>shift start time </td><td>shift end time </td></tr><tr><td>11-12</td><td>|8 - 11| = 3<br>|13 - 11| = 2<br></td><td>|12 - 12| = 0<br>|17 - 12| = 5<br></td></tr><tr><td>minimum</td><td>13</td><td>12</td></tr></tbody></table> So that the slot timining will be 13-12 which should not be possible Fix: - We previously relied on the ```_adjust_to_calendar``` method to calculate the resource's working hours. However since the working hour intervals are already computed using ```_work_intervals_batch```, we are removing the method call to reduce code duplication. Calculate the working hours using ```_work_intervals_batch``` and return the appropriate work intervals based on the resource's working calendar. task-3916687 Forward-Port-Of: odoo/enterprise#64961
This update allows users in Uruguay to create invoices with 100% discount lines, resolving a previous validation error with the tax authority (DGI). The changes include adapting the XML format to correctly handle zero-value lines and avoiding currency calculation errors when dealing with foreign currencies.
Original PR description
Some users need to make invoices with 100% discount lines. If they try then will receive this UCFE error that does not let us to validate the invoice in DGI . > ERROR: CODE 31: Error: El contenido…
Some users need to make invoices with 100% discount lines. If they try then will receive this UCFE error that does not let us to validate the invoice in DGI . > ERROR: CODE 31: Error: El contenido del elemento 'Item' en espacio de nombres 'http://cfe.dgi.gub.uy' está incompleto. Lista esperada de elementos posibles: 'SubDescuento, RecargoPct, RecargoMnt, SubRecargo, RetencPercep, MontoItem' en espacio de nombres 'http://cfe.dgi.gub.uy'. In order to make it work we need to adapt the module to accept this kind of lines that actually represent an "Entrega Gratuita" (Indicator 5 in Uruguay) - We check if the line is a 100% discount, if it is then we marked as Entrega Gratuita when we are creating XML (Indicator 5) - Now that we can have lines and also invoices with total value 0.0 we need to adapt our XML because if value 0.0 then some tags were not added to the final XML - it was interpreted as False and the result was and invalid XML becasue we were missing a mandatory tag. Now we can tags that have 0.0 value to the final XML. - Now that we can have lines 0.0 total amount, and also invoices 0.0 total amount, if we are using foreign currency then we need to avoid error computing the currency rate (division by zero). Now we detect this cases and use the date rate. Also, the rate is only been computed when actually we are going to use it. LATAM 1296 / ADHOC Ticket 83295