Sunday, September 27, 2026
4 changes · master
Resolved issues and error corrections
This change prevents Peruvian delivery guides for itinerant issuer transfers from including an address code that SUNAT does not allow. It helps affected businesses generate and submit these delivery documents successfully without rejection error 3416.
Original PR description
### Issue before this commit: When issuing a Delivery Guide for an "Itinerant issuer transfer CP", SUNAT rejects the document with error 3416 because the establishment code of the arrival point is…
### Issue before this commit: When issuing a Delivery Guide for an "Itinerant issuer transfer CP", SUNAT rejects the document with error 3416 because the establishment code of the arrival point is being reported. ### Steps to reproduce the issue: 1. Download Stock, l10n_pe_edi_stock and l10n_pe_reports_stock 2. Create one contact setting a valid RUC 3. Go to settings and insert Credentials for Sunat Delivery Guide API 4. Create a new warehouse 5. Go to deliveries and create a new one with: 1. Delivery Address: the contact you created 2. Transport Type: Public Transport 3. Reason for transfer: Itinerant issuer transfer CP 4. Operator (in the PE EDI tab): any 6. Validate the delivery 7. Generate the delivery guide 8. There was an error communicating with the SUNAT service. Details: 400 Client Error: Bad Request for url: https://api-seguridad.sunat.gob.pe/v1/clientessol/test/oauth2/token/ 9. If you download the generated XML, you will see that the node <cbc:AddressTypeCode> inside <cac:DeliveryAddress> is being generated with a default value of "0" but it should not be there ### Cause of the issue: The UBL template automatically forces the <cbc:AddressTypeCode> node with a default value of "0" for any delivery address associated with a RUC (identification type 6). However, SUNAT's validation rules strictly forbid this node when the transfer reason is 18. ### Reason to introduce the fix: Update the XML template to conditionally omit the <cbc:AddressTypeCode> tag inside <cac:DeliveryAddress> whenever the l10n_pe_edi_reason_for_transfer is '18'. This ensures compliance with SUNAT's validation rules and allows the successful generation of the delivery guide. opw-6493067 Forward-Port-Of: odoo/enterprise#132991 Forward-Port-Of: odoo/enterprise#131431
This change prevents an error when users load Sendcloud shipping products while setting up a delivery method. It ensures the delivery widgets receive the right field information, so carrier setup can continue without interruption.
Original PR description
Steps to reproduce: - Create a Belgian company - Install Sendcloud delivery provider - Create a delivery method with Sendcloud as provider - Fill in other mandatory fields - Click 'Load your products' button - Observe the traceback In commit https://github.com/odoo/enterprise/commit/cb6c6688a7c00fde1c7992e88027062fd744f80e properties were cut due to change from 'empty' props definition to a explicit one. Due to that, the `name` property was not available in the props, which is passed from `sendcloud.shipping.wizard`. Since the widget is used on fields, it should have `standardFieldProps`, not `standardWidgetProps`. This commit changes that. Forward-Port-Of: odoo/enterprise#131576
The VoIP Number Requests page now shows helpful guidance when there are no requests to display. This makes the empty page easier to understand and helps users know what the list is for.
Original PR description
Add action help for the Number Requests list, reusing the phone number illustration and existing styles. [Task-6600799](https://www.odoo.com/odoo/project/5778/tasks/6600799) Forward-Port-Of: odoo/enterprise#132958
Planning users can now mark Field Service shifts as completed when travel fees are enabled, without being blocked by sales order access errors. This ensures travel fee billing lines are created in the background while keeping the workflow smooth for users who do not have sales permissions.
Original PR description
Before this commit, when a planning user clicks on complete button to mark its shift as completed and the travel fee feature is enabled in Field Service, the user got an Access error saying he cannot read a SO, the reason is because a SOL will be generated inside the SO linked to the intervention for travel fee product and that generation is not done in sudo. This commit adds a sudo to be able to generate the SOL needed for travel fee product and let the user complete his intervention without any issue. task-6508759 Forward-Port-Of: odoo/enterprise#132168