Thursday, February 6, 2025
38 changes · 18.0
Enhancements to existing features
Translate this new module. Translations were provided by MADI. task-4298921
Original PR description
Translate this new module. Translations were provided by MADI. task-4298921
Resolved issues and error corrections
The French accounting upgrade now avoids assigning standard identifiers to bank records with unusual custom BIC codes. This prevents custom bank data from being mistaken for official module-provided records during migrations.
Original PR description
The upgrade script is supposed to create xmlids for french banks that were already created from csv, if it matches custom records that have unusual bic, it is better to skip the whole record. Standard BIC format is a capital alphanumeric only. Replacing the spaces or unsupported characters in the xmlid will result in custom records looking like they come from standard module. alternate fix for https://github.com/odoo/odoo/pull/191970 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Since HS Code field is now also used in USPS connector, the help text of `hs_code` field on `product_template` needs to be updated. Also the POT file containing module titles and descriptions is updated. Task-3759325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196518 Forward-Port-Of: odoo/odoo#187405
Original PR description
Since HS Code field is now also used in USPS connector, the help text of `hs_code` field on `product_template` needs to be updated. Also the POT file containing module titles and descriptions is updated. Task-3759325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196518 Forward-Port-Of: odoo/odoo#187405
This change fixes a failing automated check related to the restaurant point-of-sale tip screen. It helps keep the restaurant POS workflow stable and prevents build failures from blocking future updates.
Original PR description
Error runbot: 111972
The GSTIN status button and update action now appear only when the user is working with Indian companies. This prevents incorrect GSTIN status checks in multi-company setups and helps ensure the right tax environment is used.
Original PR description
This commit fixes a few issues in multi-company context: - only show the GSTIN status/update button when user has at least one IN companies selected - only allow the update when user's active company is an IN company (to ensure we correctly determine the EDI test/production status) opw-4367302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could stop users from attaching files by URL when the external response did not include expected file type information. The change makes the editor handle that missing detail safely, improving reliability when adding linked attachments.
Original PR description
This error occurs when ``content-type`` is not found in the response when attaching any file with the type ``URL``. Traceback: --- ``` KeyError: 'content-type' File "odoo/http.py", line 2366, in…
This error occurs when ``content-type`` is not found in the response when attaching any file with the type ``URL``.
Traceback:
---
```
KeyError: 'content-type'
File "odoo/http.py", line 2366, in __call__
response = request._serve_db()
File "odoo/http.py", line 1894, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1957, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1924, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2171, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 727, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/html_editor/controllers/main.py", line 355, in add_url
attachment = self._attachment_create(url=url, res_id=res_id, res_model=res_model)
File "addons/html_editor/controllers/main.py", line 256, in _attachment_create
mime_type = response.headers['content-type']
File "requests/structures.py", line 52, in __getitem__
return self._store[key.lower()][1]
```
https://github.com/odoo/odoo/blob/2fe55ae592e5812c5ee5e39ed1e8332bde608cb2/addons/html_editor/controllers/main.py#L257
sentry-6015024235
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes Spanish localization tax data by restoring price-inclusion override settings that were removed by mistake. It helps ensure Spanish tax calculations keep the intended behavior for affected accounting setups.
Original PR description
On https://github.com/odoo/odoo/commit/06d3ef5853aa0a93ac2de1642fd11ea191a3bbd3 price_include_override were erroneously removed
This fixes an issue where users could not print checks when the payment account did not allow reconciliation and the payment was immediately marked as paid. Check printing is now allowed in this case, preserving prior behavior, while voiding or rejecting these paid checks remains blocked.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Configuration / Accounting / Journals" - Open "Bank" Journal - Go to "Outgoing Payments" tab - Set a check layout - For "Checks"…
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Configuration / Accounting / Journals" - Open "Bank" Journal - Go to "Outgoing Payments" tab - Set a check layout - For "Checks" line, set "101401 Bank" (i.e. an account that doesn't allow reconciliation) as outstanding payments account - Create a vendor bill and confirm it - Pay the bill with "Checks" as payment method => The bill is directly marked as "PAID" and not "IN PAYMENT" because the "Bank" account doesn't allow reconciliation - Go the the check payment **Issue:** It is not possible to print it. The same configuration allows to print the check in previous versions. **Cause:** As the check payment is using an account that doesn't allow reconciliation, the payment is set in "Paid" state directly, but the printing is disabled for checks in that state. **Solution:** As it should be harmless to allow to print the check even if it is already paid, we will allow to print it to keep a consistent behavior with previous versions. Only printing the check will be allowed. Voiding or rejecting will still be impossible. opw-4498446 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the point of sale Self Order flow from trying to subscribe to a missing or undefined communication channel. It helps avoid avoidable errors and improves reliability for customers using self-ordering.
Original PR description
Prevent subscription to undefined channel name in Self Order.
This fix corrects a few mislabeled Peppol electronic address scheme names that were introduced in a prior update. It helps users select the right invoicing identifiers and reduces confusion when configuring electronic invoicing partners.
Original PR description
Previous commit ([1]) tried to simplify with less technical names the Peppol EAS but introduced small errors. [1]: https://github.com/odoo/odoo/commit/5c7eefed412e676c6ddf67f62bce514e5bade44c task-no
This fix ensures stock-related actions triggered by subscriptions, rentals, and field service sales pass quantity information consistently. It reduces the risk of order processing errors and also avoids an access issue for project users working with field service sales orders.
Original PR description
The override of `_action_launch_stock_rule` was passing its `previous_product_uom_qty` keyword argument as a positional parameter to the `super` call, preventing other overrides from passing it with its key name. This commit ensures that the argument is now passed correctly with its key name. It also makes the override kwargs-agnostic by packing and unpacking them with `**`, thus preventing future issues related to signature changes in the parent method. See also: - https://github.com/odoo/enterprise/pull/77839 - https://github.com/odoo/documentation/pull/11823
The Overdue Invoices button on a partner now shows only sales-related documents, rather than including unrelated miscellaneous accounting entries. This helps users focus on the invoices that actually need follow-up and avoids confusion in customer account reviews.
Original PR description
When opening the Invoice Overdue through the partner form: 1 - Create over due MISC entries (through deferred entries for example) 2 - Open a partner 3 - Go the the Accounting tab 4 - Click the Overdue Invoices button -> Some MISC entries show while we only want to view sale document. This commit fixes that by adding a filter on the domain to reduce the search scope to only sale documents. task-4523037
Confirmed subscription sales orders no longer trigger an error when the Start Date or Next Invoice Date is changed or removed. This helps sales teams update subscription timing without interruptions.
Original PR description
This error occurs when attempting to change the ``Start Date`` or ``Next Invoice Date`` after the Sales Order has been confirmed. Steps to reproduce: --- - Install ``sale_subscription_stock`` module - Create a ``New`` Sale Order and fill in the required fields and order line - Now add ``Recurring Plan`` and in ``Other Info`` add ``Start Date`` > Confirm - Remove ``Start Date`` Traceback: --- ``TypeError: '<=' not supported between instances of 'datetime.date' and 'bool'`` At [1] this commit resolves the issue by verifying the presence of the ``Start Date`` and ``Next Invoice Date``. [1]- https://github.com/odoo/enterprise/blob/68fa2f5ea8c42ccb66823efb847d230fe3994527/sale_subscription_stock/models/sale_order.py#L21 sentry-6220852935
Current behavior: The previous closing amount is used instead of the cash opening when printing the session report so the expected cash amount is wrong. Steps to reproduce: Open a PoS session with 100€ in the cash register and close it. Reopen the session and enter 50€ in the cash register. Make a sale for 10€, using cash payment. Close the session and print the session report. The expected cash amount will be 110€ when it should be 60€. Fixes opw-4497263 Forward-Port-Of: odoo/odoo#
Original PR description
Current behavior: The previous closing amount is used instead of the cash opening when printing the session report so the expected cash amount is wrong. Steps to reproduce: Open a PoS session with 100€ in the cash register and close it. Reopen the session and enter 50€ in the cash register. Make a sale for 10€, using cash payment. Close the session and print the session report. The expected cash amount will be 110€ when it should be 60€. Fixes opw-4497263 Forward-Port-Of: odoo/odoo#196395
Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform. This commit implements a way to gather all the necessary data needed to send the eTransport document and the actual sending of this document to the eTransport platform. Authentication: the authentication needed to interact with the eTransport platform is the same as (and was already implemented in) the l10n_ro_efactura module. see [eFa
Original PR description
Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform. This commit implements a way to gather all…
Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform.
This commit implements a way to gather all the necessary data needed to send the eTransport document and the actual sending of this document to the eTransport platform.
Authentication:
the authentication needed to interact with the eTransport platform is the same as (and was already implemented in) the l10n_ro_efactura module. see [eFactura PR](https://github.com/odoo/odoo/pull/144061)
eTransport flow:
- Add the necessary eTransport data to a delivery
- send the eTransport document to ANAF
- the document gets processed by ANAF
- Fetch the status of the document:
- which can result in an error, in which case the flow starts again from the beginning with the corrected data
- or in a success
task-id: 3810735
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#194858
Forward-Port-Of: odoo/odoo#170080Running the “test_workcenter_with_resource_calendar_from_another_company” without demo data occurs an error because the resource calendar. Forward-Port-Of: odoo/odoo#196656
Original PR description
Running the “test_workcenter_with_resource_calendar_from_another_company” without demo data occurs an error because the resource calendar. Forward-Port-Of: odoo/odoo#196656
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today, receiving the product, then dating the vendor bill to some future date with a different exchange rate will result in exchange difference journal entries when the bill is posted. **Expected behavior:** We shouldn't see exchange difference entries, as there are pending corrective valuation entr
Original PR description
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today,…
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today, receiving the product, then dating the vendor bill to some future date with a different exchange rate will result in exchange difference journal entries when the bill is posted. **Expected behavior:** We shouldn't see exchange difference entries, as there are pending corrective valuation entries which have simply not been posted yet. Reconciliation should be deferred until these moves are no longer in draft. **Steps to reproduce:** 1. Activate another currency, define some rate for today and another (different) rate for tomorrow 2. Create a product with FIFO and real-time costing & valuation 3. Create an initial purchase for the product, receive then bill normally 4. Create another purchase order and receive the product 5. Create the invoice, set the invoie date for tomorrow 6. Post the invoice -> Open the `Exchange Difference` journal to see the entries which should not have been generated **Cause of the issue:** After creating the AMLs which represent the difference in reception/bill unit price of the product, they are caught here: https://github.com/odoo/odoo/blob/971400771a31c05641a8672f6b1d85afaa9c4a19/addons/account/models/account_move.py#L3575 and designated as future moves, not to be posted at this time. At the end of the `_post()` stack: https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L229 where there would normally be some `correction_amls`, they weren't created here because the AMLs for the price diff were not posted- so the price diff entry is generated. **Fix:** Wait for pending (`state == 'draft'`) AMLs that are part of some `AccountMove`'s valuation to be no longer in draft before allowing reconciliation with a currency exchange difference. opw-4266652 Forward-Port-Of: odoo/odoo#196140 Forward-Port-Of: odoo/odoo#193971
This commit adds python 3.13 opcodes that would be necessary to use safe_eval and qweb Forward-Port-Of: odoo/odoo#196645
Original PR description
This commit adds python 3.13 opcodes that would be necessary to use safe_eval and qweb Forward-Port-Of: odoo/odoo#196645
@qrtl QT5121 Forward-Port-Of: odoo/odoo#193910
Original PR description
@qrtl QT5121 Forward-Port-Of: odoo/odoo#193910
Previously, adjusting the width of a form field within a large box resulted in excessive padding being applied above and below the form field. This commit refines the CSS rules, ensuring the padding is applied only to the outer large box and not to the inner elements. task-4370763 Forward-Port-Of: odoo/odoo#196451 Forward-Port-Of: odoo/odoo#193008
Original PR description
Previously, adjusting the width of a form field within a large box resulted in excessive padding being applied above and below the form field. This commit refines the CSS rules, ensuring the padding is applied only to the outer large box and not to the inner elements. task-4370763 Forward-Port-Of: odoo/odoo#196451 Forward-Port-Of: odoo/odoo#193008
When forcefully unreserving then reserving products coming from a same package for multiple pickings, the source package is wrongly propagated as destination package on the multiple pickings. To reproduce: - `-i sale_stock,sale_management` - Create a storable product (I) with 30 qty on hand - Create and confirm an internal transfer to put the product I in a pack (P) - Create and confirm two SO : - Sell 10 I - Sell 20 I - Check the 2 SO delivery pickings (D): - Each are r
Original PR description
When forcefully unreserving then reserving products coming from a same package for multiple pickings, the source package is wrongly propagated as destination package on the multiple pickings. To reproduce: - `-i sale_stock,sale_management` - Create a storable product (I) with 30 qty on hand - Create and confirm an internal transfer to put the product I in a pack (P) - Create and confirm two SO : - Sell 10 I - Sell 20 I - Check the 2 SO delivery pickings (D): - Each are reserved from pack P - They don't have any 'Destination Package' [Expected] - From the picking list view, by selecting the 2 pickings D : - 'Unreserve' them both - 'Check Availability' them both - Check the pickings D: - Each are reserved from pack P - Each have 'Destination Package' P [Faulty] opw-4272573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193745
Versions -------- - 17.0+ Steps ----- 1. Enable Adyen as payment provider in test mode; 2. do an eCommerce checkout; 3. select Adyen as payment option; 4. use the following card details[^1]: - card number: 4111111111111111 - expiry: 03/30 - cvc: 737 - name on card: CARD_EXPIRED 5. click Pay Now; 6. check order chatter on the backend. Issue ----- > Error: Adyen: Received data with invalid payment state: Refused Refusal shouldn't be an invalid payment state.
Original PR description
Versions
--------
- 17.0+
Steps
-----
1. Enable Adyen as payment provider in test mode;
2. do an eCommerce checkout;
3. select Adyen as payment option;
4. use the following card details[^1]:
- card number: 4111111111111111
- expiry: 03/30
- cvc: 737
- name on card: CARD_EXPIRED
5. click Pay Now;
6. check order chatter on the backend.
Issue
-----
> Error: Adyen: Received data with invalid payment state: Refused
Refusal shouldn't be an invalid payment state.
Cause
-----
Commit 04f75728fd3e accidentally removed an `elif` branch that was added by commit 4d340a330462e specifically to handle refused payments.
Solution
--------
Re-add the `elif` branch.
opw-4481602
[^1]: https://docs.adyen.com/development-resources/testing/result-codes#values-for-testing-result-reasons
Forward-Port-Of: odoo/odoo#196394Before this commit: 1. Install `ressource` module 2. In debug, open "Run unit tests" debug menu 3. Error pop-up: ```js Global Error: stack trace available in the console Missing dependencies: @mail/../tests/mail_test_helpers ``` After this commit: No error and units tests can proceed Related runbot task: https://runbot.odoo.com/odoo/runbot.build.error/72187 Forward-Port-Of: odoo/odoo#196488 Forward-Port-Of: odoo/odoo#195824
Original PR description
Before this commit: 1. Install `ressource` module 2. In debug, open "Run unit tests" debug menu 3. Error pop-up: ```js Global Error: stack trace available in the console Missing dependencies: @mail/../tests/mail_test_helpers ``` After this commit: No error and units tests can proceed Related runbot task: https://runbot.odoo.com/odoo/runbot.build.error/72187 Forward-Port-Of: odoo/odoo#196488 Forward-Port-Of: odoo/odoo#195824
Steps to reproduce: - Go to the "/blog" page. - Click on "Configuration > Blogs" in the main navbar. - Create at least 15 new blogs with "Astronomy" as the name. - Go back to the "/blog" page. - Bug: The navbar overflows the page to the right, causing a horizontal scrollbar to appear. After this commit, the navbar no longer overflows, and the list items are displayed on multiple lines. [opw-4507558](https://www.odoo.com/web#id=4507558&cids=1&menu_id=4720&action=333&active_id=1695&
Original PR description
Steps to reproduce: - Go to the "/blog" page. - Click on "Configuration > Blogs" in the main navbar. - Create at least 15 new blogs with "Astronomy" as the name. - Go back to the "/blog" page. - Bug: The navbar overflows the page to the right, causing a horizontal scrollbar to appear. After this commit, the navbar no longer overflows, and the list items are displayed on multiple lines. [opw-4507558](https://www.odoo.com/web#id=4507558&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#196452 Forward-Port-Of: odoo/odoo#195859
**Issue:** Users are able to delete timesheets associated with public holidays, unlike regular time off requests **Steps to Reproduce:** - Ensure "Time Off" is enabled in the Timesheet settings. - Time Off > Configurations > Public Holidays. - Create a new public holiday. - Timesheet > My Timesheet (list view). - Attempt to delete the timesheet entry corresponding to the public holiday. The entry is deleted without any warning. opw-4464411 --- I confirm I have s
Original PR description
**Issue:** Users are able to delete timesheets associated with public holidays, unlike regular time off requests **Steps to Reproduce:** - Ensure "Time Off" is enabled in the Timesheet settings. - Time Off > Configurations > Public Holidays. - Create a new public holiday. - Timesheet > My Timesheet (list view). - Attempt to delete the timesheet entry corresponding to the public holiday. The entry is deleted without any warning. opw-4464411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196506 Forward-Port-Of: odoo/odoo#195379
Steps to reproduce: - Enter edit mode. - Drag and drop a carousel into the page. - Use the arrow keys to slide the carousel. - Bug: a traceback occurs. Just like we disabled Bootstrap for sliding the carousel in edit mode and instead handle it manually (see this commit [1]), in this commit, we also disable sliding the carousel by pressing the left and right arrow keys on the keyboard. [1]: https://github.com/odoo/odoo/commit/93ec3ac285dc9ffd363e185a1dc238c6135d79dd opw-4373535 Fo
Original PR description
Steps to reproduce: - Enter edit mode. - Drag and drop a carousel into the page. - Use the arrow keys to slide the carousel. - Bug: a traceback occurs. Just like we disabled Bootstrap for sliding the carousel in edit mode and instead handle it manually (see this commit [1]), in this commit, we also disable sliding the carousel by pressing the left and right arrow keys on the keyboard. [1]: https://github.com/odoo/odoo/commit/93ec3ac285dc9ffd363e185a1dc238c6135d79dd opw-4373535 Forward-Port-Of: odoo/odoo#196486 Forward-Port-Of: odoo/odoo#196433
Fixes an issue with the renaming of the attachment after detaching to not change the extension. task-4500319 Forward-Port-Of: odoo/odoo#196456
Original PR description
Fixes an issue with the renaming of the attachment after detaching to not change the extension. task-4500319 Forward-Port-Of: odoo/odoo#196456
Steps to reproduce the bug: - Create two delivery transfers. - Add them to a single batch transfer. - Assign a responsible person to the batch transfer. - The assigned responsible person will automatically be updated in all related transfers. - Now, remove the responsible person from the batch transfer. Problem: When a responsible person is assigned or modified in a batch transfer, the update is correctly reflected in all related transfers within that batch. However, if the responsible
Original PR description
Steps to reproduce the bug: - Create two delivery transfers. - Add them to a single batch transfer. - Assign a responsible person to the batch transfer. - The assigned responsible person will automatically be updated in all related transfers. - Now, remove the responsible person from the batch transfer. Problem: When a responsible person is assigned or modified in a batch transfer, the update is correctly reflected in all related transfers within that batch. However, if the responsible person is removed from the batch transfer, this change is not applied to the individual transfers linked to it. opw-4519994 Forward-Port-Of: odoo/odoo#196487 Forward-Port-Of: odoo/odoo#196333
**Problem**: Removing spaces impacts composed values like (`padding: 10px 20px` → `padding: 10px20px`), making them invalid. **Solution**: Replace multiple spaces with a single space instead of removing them, to ensure composed values remain intact. **Steps to Reproduce**: 1. Open Email Templates > any template. 2. Add `padding: 10px 20px` to a `tr` element. 3. Save the template. 4. Observe that padding is not applied. --- I confirm I have signed the CLA and read the PR guidelin
Original PR description
**Problem**: Removing spaces impacts composed values like (`padding: 10px 20px` → `padding: 10px20px`), making them invalid. **Solution**: Replace multiple spaces with a single space instead of removing them, to ensure composed values remain intact. **Steps to Reproduce**: 1. Open Email Templates > any template. 2. Add `padding: 10px 20px` to a `tr` element. 3. Save the template. 4. Observe that padding is not applied. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196564 Forward-Port-Of: odoo/odoo#196376
Previously, the Mail Failure icon was a .JPG, which lacked transparency. While this was not noticeable in Odoo Light Mode, it resulted in a visible white background in Dark Mode. This commit replaces the JPG with an SVG, ensuring proper transparency. | Current (17.0) | Fix | |--------|--------| |  |  | |  |  | |  |  | task-4531425 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196400
Description of the issue/feature this PR addresses: - After an internal user (without Live Chat application access) interacted with chatbot from website, he will not be able to click on the Messages icon on the top-right menu anymore:  - Cause: Internal user without Live Chat application access cannot read on model `chatbot.script.step`, so when system calls `mail_channel.chatbot_current_step_id`, securit
Original PR description
Description of the issue/feature this PR addresses: - After an internal user (without Live Chat application access) interacted with chatbot from website, he will not be able to click on the Messages icon on the top-right menu anymore:  - Cause: Internal user without Live Chat application access cannot read on model `chatbot.script.step`, so when system calls `mail_channel.chatbot_current_step_id`, security error occurs. - Solution: Use `sudo` on `mail_channel` variable to avoid security error. 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#190201 Forward-Port-Of: odoo/odoo#174611
This new module should replace the existing implementation for USPS integration which uses XML which is not the recommended API currently by USPS. The new integration uses USPS's latest RESTful APIs: https://developer.usps.com/apis. Task-3759325 Forward-Port-Of: odoo/enterprise#78560 Forward-Port-Of: odoo/enterprise#73906
Original PR description
This new module should replace the existing implementation for USPS integration which uses XML which is not the recommended API currently by USPS. The new integration uses USPS's latest RESTful APIs: https://developer.usps.com/apis. Task-3759325 Forward-Port-Of: odoo/enterprise#78560 Forward-Port-Of: odoo/enterprise#73906
Description of the issue/feature this PR addresses: This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label. Current behavior before PR: If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with "-". Desired behavior after PR is merged: If an electronic invoice is sent to DGI with a line without product id but with a lab
Original PR description
Description of the issue/feature this PR addresses: This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label. Current…
Description of the issue/feature this PR addresses:
This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label.
Current behavior before PR:
If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with "-".
Desired behavior after PR is merged:
If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with the product description.
Steps to reproduce the issue:
- Create an electronic invoice on an uruguayan company.
- Add a line without a product and add a label, a unit price, quantity and tax.
- Confirm the invoice and create CFE.
- Check that the field "NomItem" is field with a "-" instead of the product label like this:
```
<Item>
<NroLinDet>4</NroLinDet>
<IndFact>2</IndFact>
<NomItem>-</NomItem>
<DscItem>PRODUCT X</DscItem>
<Cantidad>1.000</Cantidad>
<UniMed>N/A</UniMed>
<PrecioUnitario>20.000000</PrecioUnitario>
<MontoItem>20.00</MontoItem>
</Item>
```
Forward-Port-Of: odoo/enterprise#78551Issue: in testing with freeze_time if the date is None in `_get_parameter_from_code` arguments it takes the real today's date - change the `date` argument while getting the `public_transport_max_amount` parameter because if it is None is gets the real date not the freeze one Task: 4509216 Forward-Port-Of: odoo/enterprise#78115
Original PR description
Issue: in testing with freeze_time if the date is None in `_get_parameter_from_code` arguments it takes the real today's date - change the `date` argument while getting the `public_transport_max_amount` parameter because if it is None is gets the real date not the freeze one Task: 4509216 Forward-Port-Of: odoo/enterprise#78115
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box. However, the Worldline related files are being downloaded and unzipped under 'sudo' command which means that the user "odoo" doesn't have access to them This is an issue when trying to delete the old IoT handlers as it's done with the user "odoo" but Worldline files present in the 'ctep' directory belong to 'root': ``` 2025-02-05 10:29:03,827 4815 ERR
Original PR description
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box. However, the Worldline related files are being downloaded and…
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box.
However, the Worldline related files are being downloaded and unzipped under 'sudo' command which means that the user "odoo" doesn't have access to them
This is an issue when trying to delete the old IoT handlers as it's done with the user "odoo" but Worldline files present in the 'ctep' directory belong to 'root':
```
2025-02-05 10:29:03,827 4815 ERROR ? odoo.addons.hw_drivers.tools.helpers: Failed to delete old IoT handlers
Traceback (most recent call last):
File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 435, in delete_iot_handlers
unlink_file(*filenames)
File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 534, in unlink_file
path.unlink()
File "/usr/lib/python3.11/pathlib.py", line 1148, in unlink
os.unlink(self)
PermissionError: [Errno 13] Permission denied: '/home/pi/odoo/addons/hw_drivers/iot_handlers/lib/ctep/libeasyctep.so'
```
This PR runs Worldline related script under user "odoo" which fixes the ownership/access issues and allows Odoo service to delete the files.
task-4527243
Forward-Port-Of: odoo/enterprise#78544See commits task-4497852 Forward-Port-Of: odoo/enterprise#78627 Forward-Port-Of: odoo/enterprise#77738
Original PR description
See commits task-4497852 Forward-Port-Of: odoo/enterprise#78627 Forward-Port-Of: odoo/enterprise#77738
The following `response` was being returned when checking the CFDI status: ``` (Pdb++) response {'CodigoEstatus': 'N - 601: La expresión impresa proporcionada no es válida.', 'EsCancelable': None, 'Estado': 'No Encontrado', 'EstatusCancelacion': None, 'ValidacionEFOS': None} ``` Since `CodigoEstatus` is already a string, there is no need to parse it again. Removing the extra line prevents the error that occurred when trying to re-parse text from a string and ensures the SAT status is h
Original PR description
The following `response` was being returned when checking the CFDI status:
```
(Pdb++) response {'CodigoEstatus': 'N - 601: La expresión impresa
proporcionada no es válida.', 'EsCancelable': None, 'Estado': 'No
Encontrado', 'EstatusCancelacion': None, 'ValidacionEFOS': None}
```
Since `CodigoEstatus` is already a string, there is no need to parse it again. Removing the extra line prevents the error that occurred when trying to re-parse text from a string and ensures the SAT status is handled correctly.
Forward-Port-Of: odoo/enterprise#78552This commit add a new way to deal with eTIms in the pos application. Before this commit, the only way of sending sales to etims was to generate the invoice at the same time then the pos order, then deal with the invoice later on. Now, everything is automated in the pos order directly, that means when the user post a pos order, she's directly send to etims and all the information returned are displayed on the receipt and the order view. In case the eTims process got an error, the user can s
Original PR description
This commit add a new way to deal with eTIms in the pos application. Before this commit, the only way of sending sales to etims was to generate the invoice at the same time then the pos order, then deal with the invoice later on. Now, everything is automated in the pos order directly, that means when the user post a pos order, she's directly send to etims and all the information returned are displayed on the receipt and the order view. In case the eTims process got an error, the user can still send the order to eTims from the pos_order view. Stock moves are also send at the same time thanks to the l10n_ke_edi_oscu_stock module. Backport of: https://github.com/odoo/enterprise/pull/76247 task-3876855 Forward-Port-Of: odoo/enterprise#78505 Forward-Port-Of: odoo/enterprise#69583