Daily updates from Odoo
Friday, November 15, 2024
36 changes · 18.0
Enhancements to existing features
Restaurant staff can now type a number in the quick table selector and continue immediately even if it does not match an existing table or order. The system automatically creates a floating order with that number, reducing interruptions and speeding up order taking.
Original PR description
Before this commit:
====================
If the number entered on the quick table selector numpad did not match any existing table or floating order, an error message ("No table or floating order found with this number") was displayed.
After this commit:
==================
When the entered number does not correspond to an existing table or floating order, a new floating order is automatically created using the inputted number.
task- 4274465The date picker now avoids showing dates from neighboring months and makes date range selection clearer. This reduces confusion for users choosing start and end dates, especially when resetting or changing an existing range.
Original PR description
Change the selection of date ranges. Enterprise: https://github.com/odoo/enterprise/pull/72595 Task [3433683](https://www.odoo.com/odoo/project.task/3433683) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves how Odoo Studio exports actions from the base system, making exported customizations more reliable and easier to move between environments. It helps businesses reduce manual cleanup when transferring Studio changes.
Original PR description
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
Odoo now treats Indonesian rupiah amounts as whole-number values instead of using decimal places. This better matches everyday Indonesian transactions and avoids payment or invoicing issues with services that only accept integer amounts, such as Xendit, QRIS, and e-Faktur.
Original PR description
In Indonesia, general transactions don't involve decimal places because the amount is too small (1 USD is around 15700 IDR). This change is also aligned with our integrations to Xendit (`payment_xendit`), QRIS (`l10n_id`) as they only accept integer amount through API. Similarly to how we implement e-Faktur (`l10n_id_efaktur`), we always use integer amount. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Kitchen preparation cards now show the custom name of a floating order instead of only its tracking number. This helps staff identify orders more clearly and reduces confusion when order names have been changed.
Original PR description
Before this commit: ==================== Only the tracking number was shown on the kitchen card for floating orders. If the user changed the name of a floating order, it could create confusion if the displayed name was different. After this commit: ================== The floating order name will be displayed for floating orders, otherwise, the tracking number will be shown. task- 4274465
The Documents app now uses a simpler rule for what appears in Company folders, based on Odoobot-owned items without a parent folder. This makes the folder list and document view more consistent, removes the old pinned-folder behavior, and fixes related cases such as copying documents and requesting files in My Drive.
Original PR description
Purpose ======= Simplify the company folder domain. Now the domain is just the documents owned by Odoobot, and without a parent folder. The search panel now use the same domain, and so the only difference now between the kanban view and the search panel is that the search panel only show folders. Technical ========= Because the old `is_pinned_folder` is used in access rule, we can not just set it to False, it needs to reflect the owner_id / folder_id values (it will be cleaned in master). Task-4293841
Resolved issues and error corrections
List views can now apply a configured column width to action buttons. This gives business teams more control over list layouts, especially where button columns need consistent spacing or alignment.
Original PR description
Before this commit, it was not possible to set the width attribute in a list view arch on `<button>` nodes. This commit allows it. One difficulty was that there's already some magic around button columns. Indeed, adjacent buttons in the arch are gathered in a single column. This doesn't map well with the width logic, as we want to be able to define a width on a button, which will thus define the width of its column. This can only work if the button is alone in its column. For that reason, when a button has a width, we do not group it with its potential adjacent buttons. Task~4307553 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
This fixes a conflict that could break the state dropdown on the customer account edit page when Peppol invoicing was installed. Customers can now change their country and select the correct state without losing standard portal account behavior.
Original PR description
Steps to reproduce: 1. Go to website > My Account > Edit information 2. Change the country from say India to United States 3. Click on the state drop down, which then appears blank. The issue occurs because the `account_peppol` module extends the public widget by using the same name as the existing `portalDetails` public widget from the portal module, effectively overriding it. This causes certain functionalities to be lost when `account_peppol` is installed. This commit modifies the `account_peppol` module to extend the existing portalDetails widget instead of overriding it. Issue introduced in commit: https://github.com/odoo/odoo/commit/857b9a188c77cef2e3cd8a1c6b3035e7cd8d1305 task-4310315 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where removing the currency from an invoice could cause the page to crash with an error. The invoice and tax calculations now handle a missing currency more safely, helping users continue editing invoices without interruption.
Original PR description
When the user removes the currency from the invoice, a traceback will appear. Steps to reproduce the error: - Enable multiple currencies - Create a invoice > Add a line > Add any product > Remove…
When the user removes the currency from the invoice,
a traceback will appear.
Steps to reproduce the error:
- Enable multiple currencies
- Create a invoice > Add a line > Add any product > Remove currency
Traceback:
```
AssertionError: precision_rounding must be positive, got 0.0
File "addons/account/models/account_move.py", line 1550, in _compute_tax_totals
base_lines, _tax_lines = move._get_rounded_base_and_tax_lines()
File "addons/account/models/account_move.py", line 1529, in _get_rounded_base_and_tax_lines
AccountTax._add_tax_details_in_base_lines(base_lines, self.company_id)
File "addons/account/models/account_tax.py", line 1354, in _add_tax_details_in_base_lines
self._add_tax_details_in_base_line(base_line, company)
File "addons/account/models/account_tax.py", line 1313, in _add_tax_details_in_base_line
taxes_computation = base_line['tax_ids']._get_tax_details(
File "addons/account/models/account_tax.py", line 1034, in _get_tax_details
raw_base = float_round(raw_base, precision_rounding=precision_rounding)
File "odoo/tools/float_utils.py", line 70, in float_round
rounding_factor = _float_check_precision(precision_digits=precision_digits,
File "odoo/tools/float_utils.py", line 35, in _float_check_precision
assert precision_rounding > 0,\
```
https://github.com/odoo/odoo/blob/0bcc55685fd75f88214b7da1f5df9ec9a7aff784/addons/account/models/account_tax.py#L1041
When, the user removes the currency, ``precision_rounding`` will be 0.0
because at [1], ``base_line['currency_id']`` will be empty,
So, the rounding will be 0.0
So, It will lead to the above traceback.
[1]- https://github.com/odoo/odoo/blob/0bcc55685fd75f88214b7da1f5df9ec9a7aff784/addons/account/models/account_tax.py#L1324
When, the user removes the currency, precision_rounding will be 0.0
because at [2], currency will be empty,
[2]- https://github.com/odoo/odoo/blob/a2c9755e3924bc04e524f5ca0e5e17cd98be5b12/addons/account/models/account_tax.py#L985
When, the user removes the currency,
At [3] "singleton: res.currency()" error will be raised.
so, fallback value is added for that.
[3]- https://github.com/odoo/odoo/blob/a2c9755e3924bc04e524f5ca0e5e17cd98be5b12/addons/account/models/account_tax.py#L1433
When the customer and product are added to the invoice, then the user removes
the currency, At [4] "singleton: res.currency()" error will be raised.
so, fallback value is added for that at [5]
[4]- https://github.com/odoo/odoo/blob/a2c9755e3924bc04e524f5ca0e5e17cd98be5b12/addons/account/models/account_tax.py#L1640
[5]- https://github.com/odoo/odoo/blob/a2c9755e3924bc04e524f5ca0e5e17cd98be5b12/addons/account/models/account_tax.py#L1601
When the customer and product are added to the invoice, then the user removes
the currency, At [6] "singleton: res.currency()" error will be raised because
k['currency_id'] is False.
[6]- https://github.com/odoo/odoo/blob/a2c9755e3924bc04e524f5ca0e5e17cd98be5b12/addons/account/models/account_tax.py#L2173
sentry-6018518380
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prPDF quotes with form fields are now generated so those fields cannot be edited after printing. This prevents accidental or unauthorized changes to quote text after the document has been produced.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Print a PDF quote with forms. Issue ----- Form fields can be modified. Cause ----- Commit be2f31a4ad03 changed some logic in a forward port, making field read-only, only if they have values. This logic was moved between 17.4 & 18.0 to before the values are known, so in 18.0, no fields are marked as read-only. Solution -------- Make all fields read-only. opw-4290594
The rental website checkout test now targets the actually selected date instead of a visually highlighted date. This helps keep date selection behavior reliable as related date picker changes are introduced, reducing the risk of future checkout regressions.
Original PR description
This commit fixes a selector targetting the wrong property (datepicker "highlighted" date instead of the "selected" one). This becomes relevant in an incoming commit in community changing the overall selection in date pickers. Community: https://github.com/odoo/odoo/pull/184844 Part of task [3433683](https://www.odoo.com/odoo/project.task/3433683)
This fixes how adjustment values are handled in the Italian point of sale fiscal receipt flow. It helps ensure the fiscal printer receives the expected numeric value, reducing the risk of receipt printing errors for discounts or other item adjustments.
Original PR description
Change the adjustmentType prop type to Number instead of String
Splitting PDF files into new documents has been made more reliable. The fix prevents occasional crashes caused by simultaneous access when newly split documents are created for another owner.
Original PR description
Reproduce: 1. Open the split tool on a pdf 2. Split into new documents 3. See crash about concurrent access to records 3. Sometimes you should do it several times This happens because several routes try to access the document simultaneously before any `documents.access` record exist. See `owner_values` in `documents.document`'s `_prepare_create_values` where we do this for the owner, but in the split tool, the owner can be someone else. Task-4319786
The "My Documents" filter now includes documents linked to the user's contact as well as documents they own. This helps keep files visible after migration when ownership may have been reset due to access restrictions.
Original PR description
Purpose ======= During the migration, the owner can be reset, if the user does not have a write access on the documents (because being owner gives all access on the record). Because of that, the filter "My Documents" does not show most of our files on next.odoo.com. To mitigate that, that filter now uses the contact in addition to the owner, and during the migration, if we reset the owner, and if the contact is False, we will set the contact to the partner of the owner. Task-4310779
Incoming emails sent to the Documents alias will no longer automatically assign a partner in a way that blocks other processing. This helps OCR and related document flows apply the correct values more reliably.
Original PR description
This is a known bug somehow reintroduced in sharepocalypse that prevents other flows (namely the OCR) from writing the correct values. Task-4260511
This fixes checkout errors that could block customers buying products on Colombian company websites. The address form now handles billing and delivery details correctly, reducing failed orders and improving the online purchase flow.
Original PR description
Steps to Reproduce: - Set up a website for a Colombian company. - Go to the shop section. - Purchase any product. Issue: - A traceback occurs when the checkout address form opens. - Another traceback appears upon clicking submit. Cause: - The error is due to an attempt to access an element in the form that is not present. Fix: - Added a condition to ensure that the element is accessed only when the address_type is set to billing. - Updated the view to display the identification type field when use_delivery_as_billing is enabled. opw-4278790
Miscellaneous changes
Steps to reproduce: 1. Open time off app. 2. Go to overview 3. select calendar view. 4. Employees' names are repeated twice on records. Fix: * Replace the repated employee's name with the name of the time off type. For example, Mitchell Mitchell 3 days would be replaced with Mitchell Paid Time Off 3 days. task-4128789 Forward-Port-Of: odoo/odoo#177422
Original PR description
Steps to reproduce: 1. Open time off app. 2. Go to overview 3. select calendar view. 4. Employees' names are repeated twice on records. Fix: * Replace the repated employee's name with the name of the time off type. For example, Mitchell Mitchell 3 days would be replaced with Mitchell Paid Time Off 3 days. task-4128789 Forward-Port-Of: odoo/odoo#177422
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186968
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186968
The Send & Print dialog will not consider attachments that have the same name as removed ones, example: - Create an invoice - Confirm it - From the action menu: `Print` > `Invoice` - Download the file to disk - e.g. `INV_2024_00001.pdf` - Open the `Send & Print` dialog - Select `Email` only - Remove the generated attachment `INV_2024_00001.pdf` (on the dialog) - Add the `INV_2024_00001.pdf` attachment (the one on disk) - Send the email The invoice will not be attached to the email,
Original PR description
The Send & Print dialog will not consider attachments that have the same name as removed ones, example: - Create an invoice - Confirm it - From the action menu: `Print` > `Invoice` - Download the file to disk - e.g. `INV_2024_00001.pdf` - Open the `Send & Print` dialog - Select `Email` only - Remove the generated attachment `INV_2024_00001.pdf` (on the dialog) - Add the `INV_2024_00001.pdf` attachment (the one on disk) - Send the email The invoice will not be attached to the email, you can check in the chatter. This occurs because we filter out attachments by checking their names, and the name is the same as the auto-generated one. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4260237) opw-4260237 Forward-Port-Of: odoo/odoo#186489
**Steps to reproduce:** - Install l10n_mx_reports (not mandatory but easier to reproduce) - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Select "Last Month" as data filter - Select "Previous Month: 9" as comparison filter - Click on dropdown button next to PDF button - Click on a button that is displayed in front of the header of the report (e.g. XLSX) **Issue:** The action is not triggered. Once the butto
Original PR description
**Steps to reproduce:** - Install l10n_mx_reports (not mandatory but easier to reproduce) - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports /…
**Steps to reproduce:** - Install l10n_mx_reports (not mandatory but easier to reproduce) - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Select "Last Month" as data filter - Select "Previous Month: 9" as comparison filter - Click on dropdown button next to PDF button - Click on a button that is displayed in front of the header of the report (e.g. XLSX) **Issue:** The action is not triggered. Once the button has been clicked, the dropdown menu disappears behind the header of the report. **Cause:** The buttons in the dropdown menu have z-index:1000 and the thead of the report has the z-index:999, which displays the buttons in front the header of the report. However, when clicked, the button becomes active and its z-index falls to 2, putting it behind the header. opw-4265087 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187147 Forward-Port-Of: odoo/odoo#186277
Steps to reproduce the issue: ============================= - Go to any chatter - Open email composer - Add seperator - Send - The seperator doesn't appear Origin of the issue: ==================== The issue was first introduced by [1] where we wanted to simplify the border-width to use only the style of 1 but it doesn't work correctly for `hr` element. We keep all border-with styles as grouping them all in one style can lead to very different ui. opw-4300018 [1]: https://github
Original PR description
Steps to reproduce the issue: ============================= - Go to any chatter - Open email composer - Add seperator - Send - The seperator doesn't appear Origin of the issue: ==================== The issue was first introduced by [1] where we wanted to simplify the border-width to use only the style of 1 but it doesn't work correctly for `hr` element. We keep all border-with styles as grouping them all in one style can lead to very different ui. opw-4300018 [1]: https://github.com/odoo/odoo/commit/3763d0e4c5cd97793721dc3404b403348ff2c2e8 Forward-Port-Of: odoo/odoo#186541
We encounter an error when trying to open any POS category from the ``Dashboard``, if the Administrator is assigned the role of ``User`` for ``Point of Sale`` Steps to reproduce: --- - Install the ``point_of_sale`` module(without demo) - Change the right from ``Admin`` -> ``User`` in ``Point of Sale`` in Users - Now go to ``Dashboard`` and try to open any category Traceback: --- ```ParseError while parsing /home/odoo/src/odoo/saas-17.4/addons/product/data/product_demo.xml:5, somewhe
Original PR description
We encounter an error when trying to open any POS category from the ``Dashboard``, if the Administrator is assigned the role of ``User`` for ``Point of Sale``
Steps to reproduce:
---
- Install the ``point_of_sale`` module(without demo)
- Change the right from ``Admin`` -> ``User`` in ``Point of Sale`` in Users
- Now go to ``Dashboard`` and try to open any category
Traceback:
---
```ParseError
while parsing /home/odoo/src/odoo/saas-17.4/addons/product/data/product_demo.xml:5, somewhere inside <record id="base.group_user" model="res.groups">
<field name="implied_ids" eval="[(4, ref('product.group_product_variant'))]"/>
</record>
```
This commit will fix the above error by displaying an ``Access Denied`` pop-up for users with the ``User`` role when attempting to open the POS category.
sentry-5717539295
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#181228When a user visits a product page, the product gets marked as "recently viewed" after 8 seconds. This delay is too long, as a user can realistically view the product and navigate away before the 8 seconds have passed (in which case the product isn't marked as recently viewed). In particular, this is problematic when the website contains a "recently viewed products" carousel, where the user expects to see all products they recently viewed (even if they didn't stay on the product page f
Original PR description
When a user visits a product page, the product gets marked as "recently viewed" after 8 seconds. This delay is too long, as a user can realistically view the product and navigate away before the 8 seconds have passed (in which case the product isn't marked as recently viewed). In particular, this is problematic when the website contains a "recently viewed products" carousel, where the user expects to see all products they recently viewed (even if they didn't stay on the product page for 8 seconds). We decided to reduce the delay to 0.5 seconds, which is long enough to prevent the product from being marked as "recently viewed" if the user visits a product page by mistake and immediately navigates away, but short enough to prevent problematic behaviors such as the one mentioned above. opw-4114364 Forward-Port-Of: odoo/odoo#187025
When reversing a move of type 'in/out refund', we create a move of type 'entry' instead of 'in/out invoice' opw-4247643 Forward-Port-Of: odoo/odoo#184909
Original PR description
When reversing a move of type 'in/out refund', we create a move of type 'entry' instead of 'in/out invoice' opw-4247643 Forward-Port-Of: odoo/odoo#184909
Currently if you try to modify the quantity of a combo product from the cart in the kiosk, the price will not update. Steps to reproduce: ------------------- * Open a kiosk * Add a combo product to the order * Go to review the order * Click on the + button > Observation: The price of the order does not change. Why the fix: ------------ In the backend we can see that the parent quantity was changed accordingly but the child products quantity stayed at 1. We were not accessing the ri
Original PR description
Currently if you try to modify the quantity of a combo product from the cart in the kiosk, the price will not update. Steps to reproduce: ------------------- * Open a kiosk * Add a combo product to the order * Go to review the order * Click on the + button > Observation: The price of the order does not change. Why the fix: ------------ In the backend we can see that the parent quantity was changed accordingly but the child products quantity stayed at 1. We were not accessing the right field when checking the child products. opw-4283481 Forward-Port-Of: odoo/odoo#187257
To reproduce the issue: 1) Create a company A, with a branch B 2) Define a currency rate for A, for currency C 3) Open currency C's form view with only B as active company ==> The rate created in 2) is not shown Forward-Port-Of: odoo/odoo#187239
Original PR description
To reproduce the issue: 1) Create a company A, with a branch B 2) Define a currency rate for A, for currency C 3) Open currency C's form view with only B as active company ==> The rate created in 2) is not shown Forward-Port-Of: odoo/odoo#187239
## Issue: - When a database is set to a language other than English, the 'Expected Date' for product replenishment does not adapt according to the set vendor lead time. This issue does not occur when the database is set to English. ## Steps To Reproduce: - Create a storable product. - Define a vendor for this product and add a delivery lead time. - Navigate to the product template and click on the "Replenish" button. - Observe that in an English language setting, the schedule date is cal
Original PR description
## Issue: - When a database is set to a language other than English, the 'Expected Date' for product replenishment does not adapt according to the set vendor lead time. This issue does not occur when…
## Issue: - When a database is set to a language other than English, the 'Expected Date' for product replenishment does not adapt according to the set vendor lead time. This issue does not occur when the database is set to English. ## Steps To Reproduce: - Create a storable product. - Define a vendor for this product and add a delivery lead time. - Navigate to the product template and click on the "Replenish" button. - Observe that in an English language setting, the schedule date is calculated correctly considering the vendor's delivery lead time. - Change the language of the database to a different language. - Repeat the replenish process. - Observe that the schedule date is not calculated correctly. ## Solution: - Replaced route name check with action check in `_get_date_planned` for better reliability, as action-based conditions reduce errors compared to route name comparisons.. opw-4199660 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183552
We were misconfiguring some accounts in ec localization: - Sale and purchase journals default accounts - Missing default valuation accounts on Adjustement and Production locations opw-4127252 Forward-Port-Of: odoo/odoo#187150 Forward-Port-Of: odoo/odoo#179361
Original PR description
We were misconfiguring some accounts in ec localization: - Sale and purchase journals default accounts - Missing default valuation accounts on Adjustement and Production locations opw-4127252 Forward-Port-Of: odoo/odoo#187150 Forward-Port-Of: odoo/odoo#179361
When switching between threads, `composer.thread` changed but the func to remove the typing indicator was not called to the previous thread. The fix is to call the func to remove the typing indicator when the thread changes. task-4285488 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187168 Forward-Port-Of: odoo/odoo#186808
Original PR description
When switching between threads, `composer.thread` changed but the func to remove the typing indicator was not called to the previous thread. The fix is to call the func to remove the typing indicator when the thread changes. task-4285488 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187168 Forward-Port-Of: odoo/odoo#186808
**Description of the issue/feature this PR addresses**: Argentinean Localization: Electronic customer invoice Factura B for a customer "Consumidor Final" without country, with "DNI" identification type, with vat and "Consumidor final" afip responsibility type must report to afip the customer vat when the invoice has an amount higher than $344487 is validated but because the vat is not reported to afip then it is not allowed to validate the invoice. The bug was introduced on this pr: https:
Original PR description
**Description of the issue/feature this PR addresses**: Argentinean Localization: Electronic customer invoice Factura B for a customer "Consumidor Final" without country, with "DNI" identification…
**Description of the issue/feature this PR addresses**: Argentinean Localization: Electronic customer invoice Factura B for a customer "Consumidor Final" without country, with "DNI" identification type, with vat and "Consumidor final" afip responsibility type must report to afip the customer vat when the invoice has an amount higher than $344487 is validated but because the vat is not reported to afip then it is not allowed to validate the invoice. The bug was introduced on this pr: https://github.com/odoo/enterprise/pull/71562 --> The goal of this pr was to be able to create Factura B for a foreign customer. But prior to this pr the user was allowed to validate an invoice Factura B to a customer "Consumidor Final" without a country set on that customer, with "DNI" identification type, with a vat and "Consumidor final" afip responsibility type when the invoice has an amount higher than $344487 **Video explaining the bug**: https://drive.google.com/file/d/1Qb2oUtT26twjCI-pB6oMGMC9gZ6_EBSz/view **Steps to reproduce**: 1) Log ing with admin user on runbot odoo enterprise 16 or 17 instance, activate developer mode and install l10n_ar_edi module. 2) Take position on company "Responsable Inscripto". 3) Create an electronic invoice "Factura B" for customer "Consumidor Final Anónimo" with an invoice line with quantity 1 and price 500000. Select electronic journal. The Partner doesn`t have country and has "dni" identification type, dni and "Consumidor final" afip responsibility type.   4) Validate the invoice and then you will receive this message:  **Current behavior before PR**: It is not allowed to validate Electronic customer invoice Factura B for a customer "Consumidor Final" without country, with "DNI" identification type, with vat and "Consumidor final" afip responsibility type when the invoice has an amount higher than $344487. **Desired behavior after PR is merged**: It is allowed to validate Electronic customer invoice Factura B for a customer "Consumidor Final" without country, with "DNI" identification type, with vat and "Consumidor final" afip responsibility type when the invoice has an amount higher than $344487. Ticket Adhoc side: 82498 Task latam side: 1283 Forward-Port-Of: odoo/enterprise#73200
Context: Every Behavior in Knowledge was a new App based on the config of the main Odoo App. Among shared resources are registries and services. In particular, the `main_components` registry is used to mount components, and, for the purpose of the following example that registry is used by the `popover_service`. Another thing to note is that the template compilation involves a reference to the App, and all ComponentNode have an app property which is the app that was used to compile i
Original PR description
Context: Every Behavior in Knowledge was a new App based on the config of the main Odoo App. Among shared resources are registries and services. In particular, the `main_components` registry is used…
Context: Every Behavior in Knowledge was a new App based on the config of the main Odoo App. Among shared resources are registries and services. In particular, the `main_components` registry is used to mount components, and, for the purpose of the following example that registry is used by the `popover_service`. Another thing to note is that the template compilation involves a reference to the App, and all ComponentNode have an app property which is the app that was used to compile its template. Issue: Now all pieces together in a problematic example case: Creating a new popover from a Behavior App involves the `main_components` registry: - Create a PopoverController (position logic (wrapper)). It is created within the main App through the registry, and its lifecycle is managed by the main App Scheduler. - Fill it with a Custom Component (business logic). It is created within the Embedded Component App, and its lifecycle is managed by the Embedded Component App Scheduler. Both schedulers lifecycle handling are not synchronized, and at some indeterministic point one of the Apps will crash during the manipulation of that popover. Solution: Use the new "subroots" OWL feature instead of using sub-apps, so that all templates are created from the same App, and the scheduler is the same for all components. This also has the advantage of not having to re-compile all templates for every Behavior. task-4300215 Forward-Port-Of: odoo/enterprise#73805 Forward-Port-Of: odoo/enterprise#73224
…aration TaskID: 4283466 Forward-Port-Of: odoo/enterprise#73088
Original PR description
…aration TaskID: 4283466 Forward-Port-Of: odoo/enterprise#73088
**Steps to reproduce:** - Install l10n_mx_reports - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Configuration / Accounting / Chart of Accounts" - Create an account: * Account Name: [any] * Code: 123456789 * Type: Bank and Cash - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Download "COA SAT (XML)" - Validate the XML on an online SAT document validator (e.g. https://ceportalvalidacionprod.clouda.sat.gob.mx) **Issue:** The
Original PR description
**Steps to reproduce:** - Install l10n_mx_reports - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Configuration / Accounting / Chart of Accounts" - Create an account:…
**Steps to reproduce:** - Install l10n_mx_reports - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Configuration / Accounting / Chart of Accounts" - Create an account: * Account Name: [any] * Code: 123456789 * Type: Bank and Cash - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Download "COA SAT (XML)" - Validate the XML on an online SAT document validator (e.g. https://ceportalvalidacionprod.clouda.sat.gob.mx) **Issue:** The validation fails because the XML contains lines with incorrect or missing value for "CodAgrup" attribute. **Cause:** The "CodAgrup" in the "COA SAT (XML)" refers to the code of the account groups. The accepted values are defined in the "Catálogo de Códigos Agrupadores" XSD file. https://github.com/odoo/enterprise/blob/ecce698637dc2ef13dfdb27dfde303a7f1191aaf/l10n_mx_xml_polizas/data/xsd/1.3/CatalogosParaEsqContE.xsd#L4-L1086 The created account [123456789] is put in the root account group with code "1" and a line is added in the "COA SAT (XML)" with this value. However, it is not an accepted value. **Solution:** From the account groups created automatically by MX localization, only the root account groups (i.e. with code "1", "2", "3",...) do not have a valid code for the "COA SAT (XML)". These ones can be ignored. This solution is not perfect as it is still possible to create an account group with an invalid code that is not a root account group. However, handling this use case would require to check that each code is included in the set of valid codes (there is more than a thousand). opw-4209089 Forward-Port-Of: odoo/enterprise#73647
### Steps to reproduce: - Set a main currency and a second one. - Upload a document in the expense module for the second currency - Refresh ### Cause: In the for loop there are more than one possible currency detected so `vals['currency_id']` does not exist but the if statement tries to read this value causing an error. ### Solution: Check if the currency_id is in the vals dictionary. If not, the default currency value will be in the Expense. opw-4307845 Forward-Port-Of: odoo/ente
Original PR description
### Steps to reproduce: - Set a main currency and a second one. - Upload a document in the expense module for the second currency - Refresh ### Cause: In the for loop there are more than one possible currency detected so `vals['currency_id']` does not exist but the if statement tries to read this value causing an error. ### Solution: Check if the currency_id is in the vals dictionary. If not, the default currency value will be in the Expense. opw-4307845 Forward-Port-Of: odoo/enterprise#73660
Before, we relied on just _l10n_br_get_error_from_response() which checks for the presence of an "error" key in the response. Unfortunately that only seems to catch errors directly raised by Avalara. The government can reject the cancellation for a myriad of reasons [1]. We could hardcode all successful status codes (24 codes), but to be more robust in case the codes change we just look if any XML is returned. The lack of XML response should reliably indicate that the cancellation failed. [1
Original PR description
Before, we relied on just _l10n_br_get_error_from_response() which checks for the presence of an "error" key in the response. Unfortunately that only seems to catch errors directly raised by Avalara. The government can reject the cancellation for a myriad of reasons [1]. We could hardcode all successful status codes (24 codes), but to be more robust in case the codes change we just look if any XML is returned. The lack of XML response should reliably indicate that the cancellation failed. [1] 4.4. Lista das Regras de Validação in https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=J%20I%20v4eN00E= Forward-Port-Of: odoo/enterprise#73342
We were misconfiguring some accounts in ec localization: - EDI purchase journal default account opw-4127252 Forward-Port-Of: odoo/enterprise#73776 Forward-Port-Of: odoo/enterprise#69561
Original PR description
We were misconfiguring some accounts in ec localization: - EDI purchase journal default account opw-4127252 Forward-Port-Of: odoo/enterprise#73776 Forward-Port-Of: odoo/enterprise#69561