Daily updates from Odoo
Navigate
Branch
Saturday, February 24, 2024
27 changes
2 changes
Enhancements to existing features
This update clarifies the l10n_pe module's purpose and functionality by removing outdated, unresolved tasks from the module's documentation. This ensures users have a clear understanding of the module's capabilities and benefits.
Original PR description
At present, the manifest for the base module in Peru contains two pending tasks that need further clarification. These to-dos have remained unresolved since the module's inception four years ago. However, with this recent commit, we have provided a clearer explanation of what the module offers and have addressed and resolved the pending to-dos. Task id=3337432 Forward-Port-Of: odoo/odoo#129186
Resolved issues and error corrections
This update fixes an issue where reducing the quantity of a sales order would incorrectly create a return instead of adjusting stock levels. The fix ensures stock moves are merged correctly, regardless of their procurement method, leading to more accurate inventory tracking and order fulfillment. This improves the reliability of our stock management system.
Original PR description
Steps to reproduce:
- In User settings add 'allocation reports' group to the admin User
- In Inventory settings enable allocation reports
- Create a stored product with 0/0 reordering rules and set a vendor
- Create an SO for that product
- Confirm the generated PO and click assign all on its receipt's allocation report
- Reduce the quantity on the SO and save
Bug:
a return is created instead of adjusting the quantity to deliver the stock moves were not merged because their procurement method do not match ('make_to_stock' / 'make_to_order')
Fix:
ignore procurement method when merging the moves
opw-3621316
Forward-Port-Of: odoo/odoo#154773
Forward-Port-Of: odoo/odoo#15343915 changes
Enhancements to existing features
The Belgian payroll individual account has been improved to make it easier to configure, generate, and read. These updates help payroll teams produce clearer employee account reports with less manual effort and a smoother setup experience.
Original PR description
TaskID: 3762935
Miscellaneous changes
In the Balance Sheet: The headers "TOTAL ASSETS" and "TOTAL EQUITY AND LIABILITIES" should be on the same level. In the Profit & Loss: The headers "Net turnover" and "Cost of sales" should be on the same level as the rest of the headers. This is corrected in this commit. The sepcs can be found in task-3701151. Forward-Port-Of: odoo/enterprise#57433 Forward-Port-Of: odoo/enterprise#56925
Original PR description
In the Balance Sheet: The headers "TOTAL ASSETS" and "TOTAL EQUITY AND LIABILITIES" should be on the same level. In the Profit & Loss: The headers "Net turnover" and "Cost of sales" should be on the same level as the rest of the headers. This is corrected in this commit. The sepcs can be found in task-3701151. Forward-Port-Of: odoo/enterprise#57433 Forward-Port-Of: odoo/enterprise#56925
Before this commit, the amount that is declared as the customs value was prone to rounding errors, and as a result, for international shipments, the user sometimes received this warning: `448: The sum of internationalDetail commodities customs value amounts do not equal the internationalDetail customs value amount; the greater customs value amount was used to rate.` This commit rounds the total amount before sending it to FedEx to avoid the warning. opw-3701773 Forward-Port-Of: odoo/enter
Original PR description
Before this commit, the amount that is declared as the customs value was prone to rounding errors, and as a result, for international shipments, the user sometimes received this warning: `448: The sum of internationalDetail commodities customs value amounts do not equal the internationalDetail customs value amount; the greater customs value amount was used to rate.` This commit rounds the total amount before sending it to FedEx to avoid the warning. opw-3701773 Forward-Port-Of: odoo/enterprise#57201 Forward-Port-Of: odoo/enterprise#57048
Purpose: Fixes applied to modelo 347 based on feedback (Task: 3757213). Addressing issues with VAT ID being included incorrectly and default invoice type for foreign partners as specified in the AEAT guidelines. Specs: 1. Corrected the default computation of the invoice field in the AEAT tab for non-EU partners, ensuring it remains empty as per specifications 2. Modified the BOE export logic to prevent duplicating the VAT number. Ensured that for Spanish partners, the VAT ID is placed in '
Original PR description
Purpose: Fixes applied to modelo 347 based on feedback (Task: 3757213). Addressing issues with VAT ID being included incorrectly and default invoice type for foreign partners as specified in the AEAT guidelines. Specs: 1. Corrected the default computation of the invoice field in the AEAT tab for non-EU partners, ensuring it remains empty as per specifications 2. Modified the BOE export logic to prevent duplicating the VAT number. Ensured that for Spanish partners, the VAT ID is placed in 'NIF Declarado' and for EU (non-Spanish) partners, in 'NIF OPERADOR COMUNITARIO', aligning with the guidelines. task-3758760 Forward-Port-Of: odoo/enterprise#57405 Forward-Port-Of: odoo/enterprise#57160
To reproduce: ============= - using PyPDF2==2.12.1 - upload the attached PDF file provided by client on ticket - try to sign the uploaded PDF file, put the signature on the extreme left side of the page - download the signed PDF file -> the signature is not there Problem: ======== - the canvas used to draw the signature is using the default page size, which is smaller to the actual page size of the PDF file, so the signature is out of the page Solution: ========= - initialize the
Original PR description
To reproduce: ============= - using PyPDF2==2.12.1 - upload the attached PDF file provided by client on ticket - try to sign the uploaded PDF file, put the signature on the extreme left side of the page - download the signed PDF file -> the signature is not there Problem: ======== - the canvas used to draw the signature is using the default page size, which is smaller to the actual page size of the PDF file, so the signature is out of the page Solution: ========= - initialize the canvas with the actual page size of the PDF file opw-3642459 Forward-Port-Of: odoo/enterprise#57263
2 line names (i.e. in Lithuanian) do not correspond to the balance sheet spec. This was fixed in this commit. The BS spec can be found in task-3701151. Forward-Port-Of: odoo/enterprise#57337 Forward-Port-Of: odoo/enterprise#56924
Original PR description
2 line names (i.e. in Lithuanian) do not correspond to the balance sheet spec. This was fixed in this commit. The BS spec can be found in task-3701151. Forward-Port-Of: odoo/enterprise#57337 Forward-Port-Of: odoo/enterprise#56924
Steps to reproduce: create a shipment to a customer and validate it. `street2` field is not included in the address line sent to UPS and it does not appear on the label. The issue happens because in line https://github.com/odoo/enterprise/blob/bec5f384325116e21221260559c7141cccf0500a/delivery_ups_rest/models/ups_request.py#L248 if `street` exists, the rest of the line is short-circuited, and so we will only have that line. This commit changes the format to one similar to legacy UPS modul
Original PR description
Steps to reproduce: create a shipment to a customer and validate it. `street2` field is not included in the address line sent to UPS and it does not appear on the label. The issue happens because in line https://github.com/odoo/enterprise/blob/bec5f384325116e21221260559c7141cccf0500a/delivery_ups_rest/models/ups_request.py#L248 if `street` exists, the rest of the line is short-circuited, and so we will only have that line. This commit changes the format to one similar to legacy UPS module. opw-3745075 Forward-Port-Of: odoo/enterprise#57340
This commit hides the email adresses of other portal users when one of them is connected. This way we keep a certain level of privacy to guest users as only internal users will now be able to see their email adress. task-3753758 Forward-Port-Of: odoo/enterprise#57363
Original PR description
This commit hides the email adresses of other portal users when one of them is connected. This way we keep a certain level of privacy to guest users as only internal users will now be able to see their email adress. task-3753758 Forward-Port-Of: odoo/enterprise#57363
Current behaviour: --- When an employee places an event on a certain day starting at 00:15 to 18:00 on a brussels TZ, the event is stored on the UTC TZ, so starting the day before at 23:15 to 17:00. This behavior shows the employee as available. Expected behaviour: --- The employee should not be available even if the event start on another day. Steps to reproduce: --- 1. Employee and db has a Brussels TZ 2. Go to Calendar 3. Add an event when employee is available 4. Event st
Original PR description
Current behaviour: --- When an employee places an event on a certain day starting at 00:15 to 18:00 on a brussels TZ, the event is stored on the UTC TZ, so starting the day before at 23:15 to 17:00.…
Current behaviour: --- When an employee places an event on a certain day starting at 00:15 to 18:00 on a brussels TZ, the event is stored on the UTC TZ, so starting the day before at 23:15 to 17:00. This behavior shows the employee as available. Expected behaviour: --- The employee should not be available even if the event start on another day. Steps to reproduce: --- 1. Employee and db has a Brussels TZ 2. Go to Calendar 3. Add an event when employee is available 4. Event starts at 00:15 and ends at 18:00 5. Go to website > Appointment 6. Select Mitchell Admin 7. Look at the date, should be unavailable 8. => Still available Cause of the issue: --- https://github.com/odoo/enterprise/blob/d6135811316837d6523e59163739fc9b954be2e6/appointment/models/calendar_appointment_type.py#L295 If the event starts on another day than the slot, it isn't taken into account. Fix: --- Adding events from yesterday and tomorrow to know if they overlap with the slot opw-3599209 Co-authored-by: Boulif Nasreddin <bon@odoo.com> Forward-Port-Of: odoo/enterprise#57284 Forward-Port-Of: odoo/enterprise#52935
Before this commit: ================================ - When we use a longer warehouse address name or company name, the shiprocket will return an error message with `The vendor details / pick up location cannot be longer than 36 characters.` After this commit: ================================ - It will only take 36 characters if the warehouse address name or company name is longer than 36 characters while validating the delivery order. - `Cannot reach the server. Please try again lat
Original PR description
Before this commit: ================================ - When we use a longer warehouse address name or company name, the shiprocket will return an error message with `The vendor details / pick up location cannot be longer than 36 characters.` After this commit: ================================ - It will only take 36 characters if the warehouse address name or company name is longer than 36 characters while validating the delivery order. - `Cannot reach the server. Please try again later.` - If shiprocket returns this error, the delivery order should not be validated. task-3650073 Forward-Port-Of: odoo/enterprise#57002 Forward-Port-Of: odoo/enterprise#53507
Our users, even our best trained colleagues, don't find the `VAT units` menu. It's too hidden in the configuration menu and in debug mode. this commit makes it discoverable. task-3746523 Forward-Port-Of: odoo/enterprise#56765
Original PR description
Our users, even our best trained colleagues, don't find the `VAT units` menu. It's too hidden in the configuration menu and in debug mode. this commit makes it discoverable. task-3746523 Forward-Port-Of: odoo/enterprise#56765
The module is auto-installed, and activating its feature is paying, so not desired. [opw-3180544](https://www.odoo.com/web#id=3180544&model=project.task) Forward-Port-Of: odoo/enterprise#40219
Original PR description
The module is auto-installed, and activating its feature is paying, so not desired. [opw-3180544](https://www.odoo.com/web#id=3180544&model=project.task) Forward-Port-Of: odoo/enterprise#40219
https://github.com/odoo/enterprise/commit/3479940bf8ba5b0efcc5ce9e10a07e30af1d6f87 intended to fix the conditions under which this node appears in the file, but it was wrong. The functional testing missed this, as the sepa_pain_version field got recomputed when updating the account code; so, checking the pain version was indeed the Swiss one, then modifying the account and putting and IBAN recomputed the pain version to 'Generic', hence compromising the test. The condition can actually be mad
Original PR description
https://github.com/odoo/enterprise/commit/3479940bf8ba5b0efcc5ce9e10a07e30af1d6f87 intended to fix the conditions under which this node appears in the file, but it was wrong. The functional testing missed this, as the sepa_pain_version field got recomputed when updating the account code; so, checking the pain version was indeed the Swiss one, then modifying the account and putting and IBAN recomputed the pain version to 'Generic', hence compromising the test. The condition can actually be made simpler: we want the SvcLvl everywhere but in Switzerland. Forward-Port-Of: odoo/enterprise#57164 Forward-Port-Of: odoo/enterprise#57104
This commit adds the Balance and the Profit and Loss report for CZ localization. Those reports follow the Decree No. 500/2002 Coll. It also adds some missing accounts. task-2348644 Forward-Port-Of: odoo/enterprise#54906
Original PR description
This commit adds the Balance and the Profit and Loss report for CZ localization. Those reports follow the Decree No. 500/2002 Coll. It also adds some missing accounts. task-2348644 Forward-Port-Of: odoo/enterprise#54906
The forward-port of #54535 neglected to adapt the code it introduced to the move of settings to its own model. Because of this oversight, this.settings is undefined, and this.settings.external_device_number would crash. This commit adapts the code to properly retrieve the config, and adds a test to make sure this never happens again. opw-3743892 Forward-Port-Of: odoo/enterprise#57277
Original PR description
The forward-port of #54535 neglected to adapt the code it introduced to the move of settings to its own model. Because of this oversight, this.settings is undefined, and this.settings.external_device_number would crash. This commit adapts the code to properly retrieve the config, and adds a test to make sure this never happens again. opw-3743892 Forward-Port-Of: odoo/enterprise#57277
10 changes
Enhancements to existing features
The Peru localization module's documentation has been improved by removing outdated to-do items that had been pending for four years. The module description is now clearer and more user-friendly, making it easier for users to understand what the module provides.
Original PR description
At present, the manifest for the base module in Peru contains two pending tasks that need further clarification. These to-dos have remained unresolved since the module's inception four years ago. However, with this recent commit, we have provided a clearer explanation of what the module offers and have addressed and resolved the pending to-dos. Task id=3337432 Forward-Port-Of: odoo/odoo#129186
Resolved issues and error corrections
This update fixes an issue where FedEx international shipments were generating warning messages due to rounding errors in customs value calculations. The system now properly rounds the total customs value before sending it to FedEx, eliminating these warnings and ensuring smoother international shipping operations.
Original PR description
Before this commit, the amount that is declared as the customs value was prone to rounding errors, and as a result, for international shipments, the user sometimes received this warning: `448: The sum of internationalDetail commodities customs value amounts do not equal the internationalDetail customs value amount; the greater customs value amount was used to rate.` This commit rounds the total amount before sending it to FedEx to avoid the warning. opw-3701773 Forward-Port-Of: odoo/enterprise#57048
Fixed an issue where the second address line (street2) was not being included when sending shipping information to UPS, causing incomplete addresses on printed labels. The system now properly combines both address lines when creating UPS shipment labels, matching the behavior of the legacy UPS integration.
Original PR description
Steps to reproduce: create a shipment to a customer and validate it. `street2` field is not included in the address line sent to UPS and it does not appear on the label. The issue happens because in line https://github.com/odoo/enterprise/blob/bec5f384325116e21221260559c7141cccf0500a/delivery_ups_rest/models/ups_request.py#L248 if `street` exists, the rest of the line is short-circuited, and so we will only have that line. This commit changes the format to one similar to legacy UPS module. opw-3745075 Forward-Port-Of: odoo/enterprise#57340
This fix corrects how values are calculated in intrastat grouped lines to ensure they are always displayed in the company's home currency rather than in foreign currencies. Previously, the system was incorrectly using foreign currency amounts, which could lead to inaccurate reporting. The fix updates the calculation method to properly convert all amounts to company currency.
Original PR description
Before this commit, values in grouped lines are not in the company currency but in the foreign currency set on the move. This is wrong, this commit changes the way we're computing values to get the value in company currency instead of in foreign currency. To do that, we change the computation (`quantity * price_unit`) for this: `Sign of quantity * Sign of price unit * ABS(balance)` It means that we handle possibility that quantity and price unit could be negative (for some strange corner cases), and we get the amount in company currency instead of in the foreign currency. opw-3757444 Forward-Port-Of: odoo/enterprise#57429 Forward-Port-Of: odoo/enterprise#57334
Guest users' email addresses are now hidden from other portal users to protect their privacy. Only internal company users can view guest email addresses. This change improves data privacy for external users accessing shared knowledge content.
Original PR description
This commit hides the email adresses of other portal users when one of them is connected. This way we keep a certain level of privacy to guest users as only internal users will now be able to see their email adress. task-3753758 Forward-Port-Of: odoo/enterprise#57363
Fixed an issue where digital signatures were not appearing on large PDF files. The signature canvas was using an incorrect page size, causing signatures placed on the edges of the document to fall outside the visible area. The fix ensures the canvas uses the actual dimensions of the PDF file being signed.
Original PR description
To reproduce: ============= - using PyPDF2==2.12.1 - upload the attached PDF file provided by client on ticket - try to sign the uploaded PDF file, put the signature on the extreme left side of the page - download the signed PDF file -> the signature is not there Problem: ======== - the canvas used to draw the signature is using the default page size, which is smaller to the actual page size of the PDF file, so the signature is out of the page Solution: ========= - initialize the canvas with the actual page size of the PDF file opw-3642459 Forward-Port-Of: odoo/enterprise#57263
This update corrects the structural hierarchy of headers in Lithuania's financial reports. In the Balance Sheet, "TOTAL ASSETS" and "TOTAL EQUITY AND LIABILITIES" are now properly aligned at the same level. In the Profit & Loss report, "Net turnover" and "Cost of sales" headers are now consistent with other headers. These changes ensure financial reports display correctly and meet local regulatory specifications.
Original PR description
In the Balance Sheet: The headers "TOTAL ASSETS" and "TOTAL EQUITY AND LIABILITIES" should be on the same level. In the Profit & Loss: The headers "Net turnover" and "Cost of sales" should be on the same level as the rest of the headers. This is corrected in this commit. The sepcs can be found in task-3701151. Forward-Port-Of: odoo/enterprise#56925
This update fixes critical issues in Spain's modelo 347 tax reporting to ensure compliance with AEAT (Spanish tax authority) guidelines. The changes correct how VAT identification numbers are handled for different partner types—preventing duplicate entries and ensuring Spanish partners' VAT IDs are recorded in the correct field, while EU partners' information goes to the appropriate alternative field.
Original PR description
Purpose: Fixes applied to modelo 347 based on feedback (Task: 3757213). Addressing issues with VAT ID being included incorrectly and default invoice type for foreign partners as specified in the AEAT guidelines. Specs: 1. Corrected the default computation of the invoice field in the AEAT tab for non-EU partners, ensuring it remains empty as per specifications 2. Modified the BOE export logic to prevent duplicating the VAT number. Ensured that for Spanish partners, the VAT ID is placed in 'NIF Declarado' and for EU (non-Spanish) partners, in 'NIF OPERADOR COMUNITARIO', aligning with the guidelines. task-3758760 Forward-Port-Of: odoo/enterprise#57405 Forward-Port-Of: odoo/enterprise#57160
Two line item names in the Lithuanian balance sheet report have been corrected to match the official balance sheet specification. This ensures that financial reports generated in Lithuanian now display the correct terminology and comply with local accounting standards.
Original PR description
2 line names (i.e. in Lithuanian) do not correspond to the balance sheet spec. This was fixed in this commit. The BS spec can be found in task-3701151. Forward-Port-Of: odoo/enterprise#57337 Forward-Port-Of: odoo/enterprise#56924
This fix resolves an issue where reducing quantities on sales orders would incorrectly create returns instead of adjusting delivery quantities. The problem occurred because stock moves weren't being properly merged when they had different procurement methods. The fix allows these moves to merge correctly, ensuring inventory adjustments work as expected when using allocation reports.
Original PR description
Steps to reproduce:
- In User settings add 'allocation reports' group to the admin User
- In Inventory settings enable allocation reports
- Create a stored product with 0/0 reordering rules and set a vendor
- Create an SO for that product
- Confirm the generated PO and click assign all on its receipt's allocation report
- Reduce the quantity on the SO and save
Bug:
a return is created instead of adjusting the quantity to deliver the stock moves were not merged because their procurement method do not match ('make_to_stock' / 'make_to_order')
Fix:
ignore procurement method when merging the moves
opw-3621316
Forward-Port-Of: odoo/odoo#154773
Forward-Port-Of: odoo/odoo#153439