Daily updates from Odoo
Wednesday, September 11, 2024
8 changes · 17.0
Enhancements to existing features
This update improves the SEPA payment processing by making the UETR field display more intelligently based on the payment method and PAIN format version being used. This ensures users only see relevant fields for their specific payment configuration, reducing confusion and streamlining the payment entry process.
Original PR description
This commit will allow to hide the sepa uetr depending on the pain version and the payment method. task: 4167726
eBay recently changed how they format product URLs in their system, which was breaking the ability to match products correctly in Odoo. This update improves the matching process by using the product variant name as a backup method when the URL doesn't match. This ensures eBay orders continue to be processed smoothly even as eBay changes their technical formats.
Original PR description
eBay recently changed the URL they send in the viewitemURL. We found 3 different ways they send it, but there might be more. And the new ones can only be matched to the product template, not variant. We shouldn't have relied on this URL to match products in the beginning, but we can't refactor this flow in stable, instead, we fallback on the name of the variant, as it was created from eBay. opw-3934127 Forward-Port-Of: odoo/enterprise#69152
Resolved issues and error corrections
This fix resolves an issue where expense invoicing would fail when trying to bill against a locked subscription order. The system now intelligently checks for renewed subscription orders that are still active and uses those instead of the original locked order, allowing expenses to be properly invoiced without errors.
Original PR description
**Current behavior:** After creating a subscription for a recurring product which creates a project/task, invoicing the original order and posting it, then creating the renewal order, if you create a…
**Current behavior:**
After creating a subscription for a recurring product which
creates a project/task, invoicing the original order and posting
it, then creating the renewal order, if you create a purchase
order for some expensable service product that has an
`expense_policy == 'sales_price'` and attempt to create the
vendor bill for the purchase order, you will get a UserError
about the original sale order being locked.
**Expected behavior:**
Because there is a renewed order which is not locked, the
expense should use that instead of the original subscription
order.
**Steps to reproduce:**
1. Create a recurring service product which is set to create a
project and task that has an associated analytic account
2. Create a subscription for the product and confirm it, create
the invoice and post it (locking the order)
3. Renew the subscription, confirm it, create the invoice but do
not post it
4. Create a service product which can be expensed and uses the
expense policy of sales price
5. Create a purchase order for the expensable service and set
analytic distribution on the order line to use the same one
from the subscription
6. Confirm the purchase order and create an invoice, then try to
post it -> UserError
**Cause of the issue:**
The original subscription order is found via the shared analytic
account and generates the error because it is now in a locked
state.
**Fix:**
Check if a found order is in the renewed subscription state and
then search for the lowest id order in DB with the originally
found subscription as its origin order- if one exists, use this
record instead of the original order in the
`_sale_determine_order()` mapping.
opw-4061484This fix resolves an issue where subscription payments were not being properly tokenized (saved for future use) even when customers had sufficient funds. The problem occurred due to minor rounding differences in currency calculations. The update now correctly compares payment amounts using the order's currency rounding rules, ensuring payments are tokenized as intended.
Original PR description
Since 4dfb9259762de we tokenize subscription payment when amount is sufficient, in some case that test was not true because the sum of order's recurring line was greater by an epsilon. This commit compare the two amounts relative the order's currency (rounding). opw-4176380 opw-4162841 opw-4117553 opw-4152609
This fix corrects an issue where Mexican tax documents (CFDI) generated from point-of-sale invoices were incorrectly using the customer's individual name instead of the company name. This ensures that tax filings with Mexican authorities contain the correct buyer information as provided by the business.
Original PR description
Currently, when a user requests an invoice from a POS ticket under a Mexican company, the CFDI document attached to the invoice incorrectly uses the buyer's name instead of using the provided company name. ### Steps to reproduce * install `l10n_mx_edi_pos` * Switch to a Mexican company * the settings enable "Generate a code on ticket" * validate a POS order * follow the instructions on the ticket to generate an invoice. Make sure to provide a company name on the customer form. When checking the XML file that is forwarded to the Mexican tax authorities, you see that only the "individual name" is registered there as the buyer, when it should be the company name. opw-4103543 opw-4071503
This fix resolves two critical issues in the Mexican electronic shipping document (Cartaporte) generation that were introduced during a version upgrade. The system was incorrectly calculating customs regime data, causing PDF generation to fail, and was missing country names in tax residency information. These fixes ensure shipping documents are generated correctly for Mexican operations.
Original PR description
[This commit] is a fw-port from 15.0. However, during the adaptation between the versions, we had two issues: - the `regimenes_aduanero` for the PDF was incorrectly computed, causing a crash on generation - the country names for the Residencia Fiscal were not added anymore This commit fixes these issues. task-3990042 [This commit]: https://github.com/odoo/enterprise/commit/e76859d90cfca3a144f10860e8e4e6845850e4f8
This fix resolves an issue where invoices in foreign currency with withholding taxes (like 10% ILA) fail to render properly in the Chilean EDI system. The problem was caused by outdated code using a deprecated method that was removed in version 16. The fix updates the code to use the correct current method, ensuring invoices post successfully.
Original PR description
To reproduce: Create an invoice, in foreign currency. Use a withholding tax, like 10% ILA Post the invoice => The rendering of the dte fails It's still using a deprecated method, which has been removed after 16. no task
Fixed an issue where the Knowledge editor would automatically create empty "Untitled" articles when users reloaded the page with no existing articles. The system now only saves articles when there are actual changes made by the user, preventing unnecessary empty article creation.
Original PR description
When there is no article to load, the form view creates a virtual record and saves it when the user closes the page or reloads it. To avoid creating empty articles, we will trigger an urgent save only if the record is dirty. Steps to reproduce the issue: 1. Delete all articles from the database 2. Open the Knowledge editor (you should see the no-content helper) 3. Reload the page (F5) => The system creates a new "Untitled" article (see the list view). TO BE: The system should not create any article when reloading the view. task-4167335