Friday, September 27, 2024
33 changes
New functionality added to Odoo
Odoo now supports generating Electronic File Transfer (EFT) files that comply with New Zealand banking standards. This enhancement enables businesses to process batch payments directly through their banks' preferred EFT format, streamlining payment operations and reducing manual file preparation work.
Original PR description
Implement support for the generation of EFT files following the requirement of the most popular banks in New Zealand Task id # 3639230
Enhancements to existing features
This improvement makes the fiscal folio (a required Mexican tax identifier) visible in list views for vendor invoices and payments, matching the existing functionality for customer invoices. This enhances visibility and makes it easier for users to track and verify fiscal information across all transaction types in Mexico.
Original PR description
Allow viewing the fiscal folio for vendor invoices and all payments in the tree view, as it currently only displays for customer invoices. Related https://github.com/odoo/enterprise/pull/69359
Resolved issues and error corrections
This fix resolves an issue where Kenyan companies using subcontracting workflows encountered validation errors when processing purchase orders. The system was incorrectly preventing negative stock quantities in subcontracting locations, which are internal locations without warehouses and should allow negative quantities. The fix ensures that stock validation only applies to locations with actual warehouses, allowing subcontracting operations to complete successfully.
Original PR description
Steps to reproduce the bug: - Log in as a Kenyan company - Create a storable product “P1” with the following Bill of Materials (BoM): - Type: Subcontracting - Subcontractor: Azure Interior -…
Steps to reproduce the bug:
- Log in as a Kenyan company
- Create a storable product “P1” with the following Bill of Materials (BoM):
- Type: Subcontracting
- Subcontractor: Azure Interior
- Component:
- C1: - Routes: “Resupply Subcontractor on Order”
- Create a purchase order for one unit of “P1”
- Confirm the PO
- Create a second PO for one unit of “C1” and receive it
- Confirm the resupply picking of C1
- Confirm the receipt of P1
**Problem:**
A validation error is triggered: “You cannot end up with a negative stock quantity.”
We added a constraint to prevent negative stock quantities in internal locations for a company in Kenya. However, the location linked to subcontracting is internal but has no warehouse, so we don’t care if its quantity is negative, and it should be ignored. This could also happen with other internal locations that don’t have a warehouse.
Additionally, when reporting stock quantities, we only consider
quantities in locations that have a warehouse:
https://github.com/odoo/enterprise/blob/9dea0f2696084235ee1192b0a14adfa43eb732ef/l10n_ke_edi_oscu_stock/models/product.py#L47
opw-4184857A technical issue was causing the tax closing entries report to crash with an error. The problem occurred when the system tried to access company information while processing multiple companies' data. This fix ensures the report generates successfully without interruption, improving the reliability of tax reporting functionality.
Original PR description
The `RuntimeError: dictionary changed size during iteration` occurred in the `_generate_tax_closing_entries` method when iterating over the `closing_moves_by_company` dictionary. This happened because accessing a key in a `defaultdict` that doesn't exist automatically creates that key with a default value. Specifically, the line: ```py if from_post and move == closing_moves_by_company[self.env.company]: ``` triggered the insertion of a new key when `self.env.company` was not already present, leading to the runtime error. This commit changes the access method to use `.get()` instead of directly accessing the key allowing, safe retrieval of the value without modifying the dictionary. opw-4089738
This fix resolves an issue where timesheet overtime warnings and formatting would randomly change appearance due to floating-point rounding errors in calculations. The system now uses a small tolerance level when comparing time values instead of exact matches, ensuring consistent and reliable display of timesheet status regardless of working schedule configurations.
Original PR description
Steps to reproduce: - Employees > Configuration > Working schedules - Set your working schedule to have non round numbers (Not mandatory but makes the issue much easier to reproduce) - Timesheets > Edit to have the required hour total - Sometimes rounding errors will cause the formatting to change (Overtime of +0:00, display in red...) This issue is not deterministic but we currently use exact comparisons between floats to determine the formatting so it could happen anytime. The error margin was chosen to be much lower than what a difference of 1min could cause (Since the rounding errors are in the vicinity of 1e-16). opw-4123649
This fix resolves an access issue where assigned users couldn't view tasks in projects with restricted visibility settings. The problem occurred because the system was incorrectly blocking access to task information for users who were assigned to the task but not project followers. The fix ensures assigned users can properly access their assigned tasks regardless of project visibility restrictions.
Original PR description
Steps to reproduce: - Project > New > Create Project - Project > ':' menu > Settings > Settings tab - Set 'Visibility' to 'Invited Internal Users' - Create a task and assign it to Marc Demo - General…
Steps to reproduce: - Project > New > Create Project - Project > ':' menu > Settings > Settings tab - Set 'Visibility' to 'Invited Internal Users' - Create a task and assign it to Marc Demo - General Settings > Users & Companies > Users - Edit Marc Demo to have 'User' access rights in 'Project' - As Marc Demo: Project > Tasks > My Tasks > Click your task Access is denied because Marc is not a follower of the project, and therefore cannot read the task's 'is_fsm' field (which is computed from the project). Due to the specifications of the visibility mode, the task should however be accessible to him. A fix was previously made for a similar issue in Field Service 5fc4f7d15e56d2b4335aa70e896fdfbd901d6076, where we changed the _search_is_fsm function to sudo the project for the same reason as here (accessing project_id.is_fsm) so this should not raise any additional security concerns. In that same fix we switched from a related field to a compute, compute_sudo was however defaulting to False since is_fsm is not stored, hence the access error. opw-4176243
This update fixes three important issues with Uruguay's electronic invoice system (l10n_uy_edi). Users can now correct invoices that fail validation by resetting them to draft without encountering document number errors. The send and print feature now works correctly by running after invoices are posted rather than before. Additionally, the account setup instructions have been simplified and updated.
Original PR description
**[FIX] l10n_uy_edi: Do not check latam document number** When an invoice sent to DGI returns errors (e.g., wrong partner or other data issues), users can reset it to draft and make corrections. However, changing the partner triggers a validation error because the invoice lacks a valid latam document number (only provided by DGI after processing). To avoid this, resetting the invoice to draft clears the invoice name, allowing users to fix any errors without triggering the validation. **[FIX] l10n_uy_edi: Create Uruware account help** Improved the helper to remove "admin email" (since it no longer applies) and updated translations accordingly. **[FIX] l10n_uy_edi: Send and Print after Post** Fixed an issue where the send and print wizard was triggered before the invoice was posted, causing errors. The wizard now only runs after the invoice has been successfully posted.
This fix corrects an issue where Amazon orders containing multiple items were incorrectly creating a separate shipping line for each item. Now, shipping is properly consolidated into a single line per order, ensuring accurate order records and preventing billing confusion.
Original PR description
If an Amazon order has more than one item it was creating for each item an own shipping line. Info: @wt-io-it