Wednesday, November 13, 2024
33 changes · saas-17.4
Enhancements to existing features
This update adds an internal helper that makes spreadsheet test setup easier and more consistent. It supports future quality improvements by helping teams test spreadsheet behavior without needing a full user interface.
Original PR description
This commit adds a new helper to create a headless model from grid data. This helper is used for a test in enterprise, but should be used in the future. Task: 4277518 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
Resolved issues and error corrections
A developer testing tool now handles nested SQL safety wrappers without crashing. This keeps internal quality checks reliable and helps prevent delays when validating code changes.
Original PR description
Before this commit, the tester did not account for the use of an SQL wrapper inside of the constructor of an other SQL wrapper, This lead to a RecusionError when trying to infer the value of the Call node. This simple fix prevent the check of an other SQL wrapper during the classical call node analysis. This Call node would be analysed anyway during the visit_call function.
Miscellaneous changes
Use cases: send an email to "Bike@Home" <info@bike.com> (name containing @) "robert@exampl.com" <robert@example.com> (result of partner name_create) When there is an email in the name field, emails are sent twice and thus may be counted twice in various tooling, introduce unwanted or extra recipients, ... This happens notably due to https://github.com/odoo/odoo/commit/795091c69d2bc40e3bd2b5ae29451ea3af07d908 combined to https://github.com/odoo/odoo/pull/74474 which improved support of
Original PR description
Use cases: send an email to "Bike@Home" <info@bike.com> (name containing @) "robert@exampl.com" <robert@example.com> (result of partner name_create) When there is an email in the name field, emails…
Discounted product prices on the website shop page now appear in a neutral muted color instead of red. This avoids making normal discounts look like warnings or errors, improving the shopping experience and visual consistency.
Original PR description
Version: - saas 17.4 Steps to reproduce: - Install the website_sale module. - Open the pricelist and apply a discount to a product. Issue: - The discount price on the product page appears in a red "danger" color. Solution: - Changed the text class from "text-danger" to "text-muted" to fix the issue. opw-4277128
The online shop now shows the original crossed-out price at checkout whenever a pricelist rule changes the final product price. This makes discounts clearer for shoppers and keeps the cart display consistent with the product page.
Original PR description
Steps: - Install Ecom. - Add a product in pricelist with fomula type. - Go to Ecom. - Product old and new price displaying with old in strike out. - Go to check out. Issue: - Only new product price is displaying as formula and fixed type rule directly change value of product on SOL and discount type add discount on SOL. Cause: - Only checked discount on SOL to display old price. Fix: - Check price before discount and after discount to display old price if both are not same. opw-4277128
This fix adjusts when Odoo shows the option to enable push notifications on iPhones and iPads. It prevents confusing or persistent notification prompts in Safari while still allowing users who installed the Odoo web app to enable notifications properly.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/178057 PR above fixed an issue of persistent notification in messaging menu in iOS, due to push notifications being only available through PWA. At the time of the fix, installing PWA apps on iOS had necessarily push notification enabled. However this no longer seems to be the case: PWA apps on iOS must now explicitly asks for enabling push notifications. This is also a necessary step in order for the PWA apps to be shown in iOS Settings > Notifications. This commit fixes the issue by not showing button to enable push notifications specifically on iOS outside of app. That way there's no persistent notification on Safari while push notifications can still be enabled. Extra notes: - iOS requests for push notifications seem to require HTTPS, otherwise they are necessarily blocked. - iOS 17 does not show the dialog to accept or deny push notifications. This is likely an iOS bug that has apparently been fixed with iOS 18.
Sales teams can now manually assign all available leads, even if those leads were created more than seven days ago. This prevents older leads from being skipped and helps avoid missed sales follow-ups.
Original PR description
When manually assigning leads to salespeople in a team, only leads created in the past 7 days were being assigned. If all leads were created more than 7 days ago, they would not be assigned, causing missed assignments. To fix this, the parameter `creation_delta_days` is now set to 0 during manual assignment, bypassing the 7-day creation filter. This ensures that all leads, regardless of creation date, are assignable manually. https://github.com/odoo/odoo/blob/saas-17.4/addons/crm/models/crm_team.py#L441#L445 Steps to reproduce: 1. Go to CRM settings and activate `Rule-Based Assignment` and `Leads`. 2. Navigate to CRM Configuration > Sales Teams. 3. Create a new sales team with `Leads` active. 4. Add a member to the team, save, and try to assign leads. Expected behavior: All leads, regardless of creation date, should be assignable when manually assigned. opw-4217088 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a missed dependency in payment validation logic for SEPA direct debit and New Zealand EFT batch payments. It helps ensure the right checks run when payment details change, reducing the chance of incorrect or inconsistent batch payment handling.
Original PR description
This was forgotten in this bugfix : https://github.com/odoo/enterprise/commit/4d548d2240c85eebe004595cd65e0fbb6a76a39b We don't fix it before 17.4 because of this revert https://github.com/odoo/enterprise/pull/73495
Spreadsheet autofill is now prevented for pivot formulas linked to non-Odoo pivots, where the feature is not supported. This avoids an error that could interrupt users while working with spreadsheet pivot data.
Original PR description
Steps to reproduce: - Insert a non-odoo pivot - Add a formula with `=PIVOT.VALUE` or `PIVOT.HEADER` - Try to autofill => Traceback This commit fixes the issue by disabling the autofill for non-odoo pivots, as the autofill is not supported for them. Task: 4277518
This fixes an issue where an error linked to a deleted accounting document could remain stuck and could not be removed. Users can now clear these outdated failures, reducing confusion and keeping document processing views accurate.
Original PR description
opw-4272165 community: https://github.com/odoo/odoo/pull/186595
Use cases: send an email to "Bike@Home" <info@bike.com> (name containing @) "robert@exampl.com" <robert@example.com> (result of partner name_create) When there is an email in the name field, emails are sent twice and thus may be counted twice in various tooling, introduce unwanted or extra recipients, ... This happens notably due to https://github.com/odoo/odoo/commit/795091c69d2bc40e3bd2b5ae29451ea3af07d908 combined to https://github.com/odoo/odoo/pull/74474 which improved support of multiemails and formatted emails in various email input. This notably leads to better formatted email computation on partner that generates emails like '"email@example.com" <email@example.com>' when email is used both as name and email. When sending emails to this partner only a single email should be sent and counted. A fix is been done to remove duplicates in that tool, making the returned list unique. In this PR we allow to receive a pre-validated list of emails that restricts emails found by 'extract_rfc2822'. When going through classic flows, we already computed emails using 'email_split' and its subtools, hence we just need the encoding check of 'extract_rfc2822'. Additional emails found by that tool are ignored as we consider those are fake emails. This PR contains tests and fixes related to that issue as well as multi and formatted emails management. Task-3704658 Forward-Port-Of: odoo/odoo#186798 Forward-Port-Of: odoo/odoo#185793
The aim of this commit is to prevent traceback when mapping local and eu taxes to oss taxes. Before the commit: If the company chart template to use resolves to a CoA coming from a module not installed, it will crash when trying to resolve the xml_id for that specific localization. After the commit: If the l10n module isn't installed, it won't try to reference any tax tag as the tax report line wouldn't be there anyway Note: 1) This case is unlikely as if the customer has a vat n
Original PR description
The aim of this commit is to prevent traceback when mapping local and eu taxes to oss taxes. Before the commit: If the company chart template to use resolves to a CoA coming from a module not installed, it will crash when trying to resolve the xml_id for that specific localization. After the commit: If the l10n module isn't installed, it won't try to reference any tax tag as the tax report line wouldn't be there anyway Note: 1) This case is unlikely as if the customer has a vat number for a specific country, it means they have a tax report to fill and thus must have installed the related localization either as main CoA or as a foreing fiscal position. 2) This was spotted through a runbot single l10n build error. Nevertheless, it is something that is possible and thus should be working smoothly. runbot-100532 Forward-Port-Of: odoo/odoo#186942
rendererProps was not called on the component. This causes issues when assigning a variable on `this` and referencing it later. See: https://github.com/odoo/owl/commit/df59ec49aefce2e0913fdc1792d42b9680fb28b6 https://github.com/odoo/odoo/commit/f76955a5615cf7950c014c4f7a64d8f3aeafdda0 Forward-Port-Of: odoo/odoo#186970 Forward-Port-Of: odoo/odoo#186814
Original PR description
rendererProps was not called on the component. This causes issues when assigning a variable on `this` and referencing it later. See: https://github.com/odoo/owl/commit/df59ec49aefce2e0913fdc1792d42b9680fb28b6 https://github.com/odoo/odoo/commit/f76955a5615cf7950c014c4f7a64d8f3aeafdda0 Forward-Port-Of: odoo/odoo#186970 Forward-Port-Of: odoo/odoo#186814
When an error is thrown sufficiently early in the webclient's "boot" process, sometimes the error handlers might not be ready *enough* eg: the dialog service has not been loaded yet. In those cases, the way to handle the error is to log it as an an error (console.log) along with some kind of hint as to why it has not been handled in a user-friendly manner. Before this commit, the original error appeared twice: one because of our logs, the second because of the browser's default behavior.
Original PR description
When an error is thrown sufficiently early in the webclient's "boot" process, sometimes the error handlers might not be ready *enough* eg: the dialog service has not been loaded yet. In those cases, the way to handle the error is to log it as an an error (console.log) along with some kind of hint as to why it has not been handled in a user-friendly manner. Before this commit, the original error appeared twice: one because of our logs, the second because of the browser's default behavior. After this commit, we prevnt the browser to apply its behavior. 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#186964 Forward-Port-Of: odoo/odoo#186566
Gift cards would have a description in the original language of the creator and could never be changed. Adds the description field to the form view of the loyalty rewards even for gift cards and ewallet programs. opw-4177262 Forward-Port-Of: odoo/odoo#180509
Original PR description
Gift cards would have a description in the original language of the creator and could never be changed. Adds the description field to the form view of the loyalty rewards even for gift cards and ewallet programs. opw-4177262 Forward-Port-Of: odoo/odoo#180509
When using ship later with 3 steps delivery and receipt, all the steps would always be done again even when the product is already available Steps to reproduce: ------------------- * Create a product A with any vendor * Setup 3 steps receipt and delivery in your warehouse * Create a sale order for product A * Receiving steps and purchase order will be created * Validate the purchase order and all the receiving steps so that there is 1 quantity in the warehouse * Open PoS, settle the or
Original PR description
When using ship later with 3 steps delivery and receipt, all the steps would always be done again even when the product is already available Steps to reproduce: ------------------- * Create a product…
When using ship later with 3 steps delivery and receipt, all the steps would always be done again even when the product is already available Steps to reproduce: ------------------- * Create a product A with any vendor * Setup 3 steps receipt and delivery in your warehouse * Create a sale order for product A * Receiving steps and purchase order will be created * Validate the purchase order and all the receiving steps so that there is 1 quantity in the warehouse * Open PoS, settle the order and ship it later > Observation: In the PoS order you will see that all receiving steps have been created again, and a new purchase order has been created too Why the fix: ------------ The error was happening because the quantity of the original sale order was still reserved. So when creating the new delivery order there was no quantity available and the whole receiving process was required again. We now make sure to free the quantity before creating the delivery order opw-4092298 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186313 Forward-Port-Of: odoo/odoo#185469
Issue: Currently, if the related user is removed from an employee, the link with the res.partner is also removed. This makes it impossible to post expense reports, as a partner is required to do so. To reproduce: 1. Create a new user. 2. Click ‘Create Employee’ in the user view 3. Go to the employee through the smart button 4. In the tab HR Settings, remove the related user 5. Create an expense report and try to post it (Expenses => New => Create Report => Submit to Manager => Approve =
Original PR description
Issue: Currently, if the related user is removed from an employee, the link with the res.partner is also removed. This makes it impossible to post expense reports, as a partner is required to do so.…
Issue: Currently, if the related user is removed from an employee, the link with the res.partner is also removed. This makes it impossible to post expense reports, as a partner is required to do so. To reproduce: 1. Create a new user. 2. Click ‘Create Employee’ in the user view 3. Go to the employee through the smart button 4. In the tab HR Settings, remove the related user 5. Create an expense report and try to post it (Expenses => New => Create Report => Submit to Manager => Approve => Post Journal Entries) 6. An error message about missing vendor (res.partner) appears Cause: The field work_contact_id keeps the link between hr.employee and res.partner, and is updated in the function _sync_user. Since work_contact_id=user.partner_id.id, when the user is removed from the hr.employee, work_contact_id is also removed. Fix: The link between hr.employee and res.partner should be kept until the user is assigned to another employee. In this case, the partner associated to the user should also be associated with the second employee, and no longer to the first employee. To do so, _sync_user assigns _origin.user_partner_id to work_contact_id if no user is passed (in case the user is removed). A helper function is called when creating or writing an employee, to unlink the partner and the previous employee in case the user is assigned to another employee. task-4049996 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186675 Forward-Port-Of: odoo/odoo#175478
In [1], the gauge widget was converted to OWL, but the option to use the widget with a fixed `max_value` was removed. This commit restores that functionality in the OWL framework. [1]: https://github.com/odoo/odoo/commit/e857e8d7 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186731 Forward-Port-Of: odoo/odoo#185620
Original PR description
In [1], the gauge widget was converted to OWL, but the option to use the widget with a fixed `max_value` was removed. This commit restores that functionality in the OWL framework. [1]: https://github.com/odoo/odoo/commit/e857e8d7 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186731 Forward-Port-Of: odoo/odoo#185620
Description of the issue/feature this PR addresses: Current l10n_sa_edi module does not affect POS behavior, such as forcing Invoice creation on POS orders for Saudi companies Current behavior before PR: Invoicing on POS orders is not enforced for Saudi Companies Desired behavior after PR is merged: Invoicing on POS orders is enforced for Saudi Companies --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170303 Fo
Original PR description
Description of the issue/feature this PR addresses: Current l10n_sa_edi module does not affect POS behavior, such as forcing Invoice creation on POS orders for Saudi companies Current behavior before PR: Invoicing on POS orders is not enforced for Saudi Companies Desired behavior after PR is merged: Invoicing on POS orders is enforced for Saudi Companies --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170303 Forward-Port-Of: odoo/odoo#124300
Before this commit: When a user creates multiple scheduled activities and clicks the "Close" button the newly created activities are not updated in the activity view. After this commit: When a user creates multiple scheduled activities and clicks the "Close" button, the newly created activities should update and visible in the activity view. Task-4057815 Forward-Port-Of: odoo/odoo#186802 Forward-Port-Of: odoo/odoo#180304
Original PR description
Before this commit: When a user creates multiple scheduled activities and clicks the "Close" button the newly created activities are not updated in the activity view. After this commit: When a user creates multiple scheduled activities and clicks the "Close" button, the newly created activities should update and visible in the activity view. Task-4057815 Forward-Port-Of: odoo/odoo#186802 Forward-Port-Of: odoo/odoo#180304
Here is record is something like this ```py (Pdb) 0.3/0.1 2.9999999999999996 ``` after taking quotient becoming 2 ```py 0.3 ``` and after taking quotent it 3 ```py AssertionError: Lists differ: [[142[468 chars]63, '2'], [14264, '0.3'], [14265, '-37'], [142[12784 chars]-5']] != [[142[468 chars]63, '3'], [14264, '0.3'], [14265, '-37'], [142[12784 chars]-5']] First differing element 27: [14263, '2'] [14263, '3'] ``` For resolving this Idea is to backport this fix https://github
Original PR description
Here is record is something like this ```py (Pdb) 0.3/0.1 2.9999999999999996 ``` after taking quotient becoming 2 ```py 0.3 ``` and after taking quotent it 3 ```py AssertionError: Lists differ: [[142[468 chars]63, '2'], [14264, '0.3'], [14265, '-37'], [142[12784 chars]-5']] != [[142[468 chars]63, '3'], [14264, '0.3'], [14265, '-37'], [142[12784 chars]-5']] First differing element 27: [14263, '2'] [14263, '3'] ``` For resolving this Idea is to backport this fix https://github.com/odoo/odoo/pull/182265 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186912 Forward-Port-Of: odoo/odoo#186758
Before this commit, the welcome page was using "Guest" as the default name, regardless of what the name was. Forward-Port-Of: odoo/odoo#186759
Original PR description
Before this commit, the welcome page was using "Guest" as the default name, regardless of what the name was. Forward-Port-Of: odoo/odoo#186759
In large database, the compute of the field l10n_it_payment_method and l10n_it_document_type can raise a timeout. Step to reproduce: - On a large database (tested with +10M account.move), try to install the module l10n_it_edi_ndd - The installation will raise a timeout New behavior: The fields l10n_it_payment_method and l10n_it_document_type will no longer be computed during module installation. This will avoid the timeout. opw-4273165 Forward-Port-Of: odoo/odoo#185266
Original PR description
In large database, the compute of the field l10n_it_payment_method and l10n_it_document_type can raise a timeout. Step to reproduce: - On a large database (tested with +10M account.move), try to install the module l10n_it_edi_ndd - The installation will raise a timeout New behavior: The fields l10n_it_payment_method and l10n_it_document_type will no longer be computed during module installation. This will avoid the timeout. opw-4273165 Forward-Port-Of: odoo/odoo#185266
When a failure occurs when sending an email or a sms, it is displayed in the messaging menu. Before this PR, it could not be removed after a record was deleted. Steps to reproduce: - Send a message on a record, add a recipient with an incorrect email. - A red enveloppe is displayed next to the message and a notification is added in the messaging menu. - Delete this record. - Try to mark this failure as read. - Nothing happens. This occurs because the message deletion is only notified
Original PR description
When a failure occurs when sending an email or a sms, it is displayed in the messaging menu. Before this PR, it could not be removed after a record was deleted. Steps to reproduce: - Send a message on a record, add a recipient with an incorrect email. - A red enveloppe is displayed next to the message and a notification is added in the messaging menu. - Delete this record. - Try to mark this failure as read. - Nothing happens. This occurs because the message deletion is only notified to the recipients, not the author. This PR fixes the issue. opw-4272165 enterprise: https://github.com/odoo/enterprise/pull/73715 Forward-Port-Of: odoo/odoo#186275 Forward-Port-Of: odoo/odoo#186000
This commit adds the capture parameter to events listeners in useDropzone utility function to make it work correctly in Documents App where the events weren't intercepted because of `stopPropagation()` call in others listeners. Task-4314619 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186651
Original PR description
This commit adds the capture parameter to events listeners in useDropzone utility function to make it work correctly in Documents App where the events weren't intercepted because of `stopPropagation()` call in others listeners. Task-4314619 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186651
Steps to reproduce ================== - Use a mobile device - Enable analytic accounting - Go to Expenses - Open a record - Click on the analytic field - Search more on the project - Click on the search input => The popup closes Cause of the issue ================== There is a resize handler that closes the popup. When the keyboard appears, the window is resized to reserve space for it Solution ======== Dont close the popup when we are using a mobile OS opw-4174514
Original PR description
Steps to reproduce ================== - Use a mobile device - Enable analytic accounting - Go to Expenses - Open a record - Click on the analytic field - Search more on the project - Click on the search input => The popup closes Cause of the issue ================== There is a resize handler that closes the popup. When the keyboard appears, the window is resized to reserve space for it Solution ======== Dont close the popup when we are using a mobile OS opw-4174514 Forward-Port-Of: odoo/odoo#186606
This improves the wording for the "missing journal" error, matching #185054 Because the original PR needs to be stopped at 16.0, this part will be able to be forward-ported --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186669 Forward-Port-Of: odoo/odoo#186138
Original PR description
This improves the wording for the "missing journal" error, matching #185054 Because the original PR needs to be stopped at 16.0, this part will be able to be forward-ported --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186669 Forward-Port-Of: odoo/odoo#186138
This PR removes the tags added to the TDS sales taxes. Due to tags on sales taxes, all the TDS entries from customer invoices are reported in TDS reports which does not need to be reported. task-4314045 Forward-Port-Of: odoo/odoo#186746
Original PR description
This PR removes the tags added to the TDS sales taxes. Due to tags on sales taxes, all the TDS entries from customer invoices are reported in TDS reports which does not need to be reported. task-4314045 Forward-Port-Of: odoo/odoo#186746
Before this commit: The logo is not updated when users change the icon or image and click the confirm button. The updated logo appears after refreshing the page. After this commit: When users change the icon or image and click the confirm button, the logo is now updated Task-4219545 Forward-Port-Of: odoo/enterprise#73487 Forward-Port-Of: odoo/enterprise#71512
Original PR description
Before this commit: The logo is not updated when users change the icon or image and click the confirm button. The updated logo appears after refreshing the page. After this commit: When users change the icon or image and click the confirm button, the logo is now updated Task-4219545 Forward-Port-Of: odoo/enterprise#73487 Forward-Port-Of: odoo/enterprise#71512
2 small fixes for the quality worksheet in the shop floor. Please refer to the individual feature commits for details. Forward-Port-Of: odoo/enterprise#70703
Original PR description
2 small fixes for the quality worksheet in the shop floor. Please refer to the individual feature commits for details. Forward-Port-Of: odoo/enterprise#70703
This reverts commit fd46e62809544702193e636ec388103eea11f788. Task-4314619 Forward-Port-Of: odoo/enterprise#73506
Original PR description
This reverts commit fd46e62809544702193e636ec388103eea11f788. Task-4314619 Forward-Port-Of: odoo/enterprise#73506
Steps to reproduce ================== - Go to documents - Switch to the list view - Select a record - Resize a column => The selection is lost Solution ======== Ignore clicks in the header opw-4203375 Forward-Port-Of: odoo/enterprise#71774
Original PR description
Steps to reproduce ================== - Go to documents - Switch to the list view - Select a record - Resize a column => The selection is lost Solution ======== Ignore clicks in the header opw-4203375 Forward-Port-Of: odoo/enterprise#71774
The test was using a common class from website while not depending on the module and turns out the class was not necessary. Runbot Error 69687 Forward-Port-Of: odoo/enterprise#73377
Original PR description
The test was using a common class from website while not depending on the module and turns out the class was not necessary. Runbot Error 69687 Forward-Port-Of: odoo/enterprise#73377
Brazil is now requiring that each line includes the barcode [1]. This is being rolled out gradually per state, as of now it's only rolled out in Paraná as far as we are aware. We're applying this change to Odoo 17 and later because it only affects EDI. Odoo 16 only supported tax calculation. Validation is done based on the Avalara documentation [2]. [1] As outlined in "Nota Técnica 2021.003 Validação GTIN" https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=SrQT9ys8OD
Original PR description
Brazil is now requiring that each line includes the barcode [1]. This is being rolled out gradually per state, as of now it's only rolled out in Paraná as far as we are aware.
We're applying this change to Odoo 17 and later because it only affects EDI. Odoo 16 only supported tax calculation.
Validation is done based on the Avalara documentation [2].
[1] As outlined in "Nota Técnica 2021.003 Validação GTIN"
https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=SrQT9ys8ODo=
[2] https://avataxbr-docs.avalarabrasil.com.br/#/Calculations/payloadCalculation
task-4222168
Forward-Port-Of: odoo/enterprise#73517