Monday, September 9, 2024
5 changes · 17.0
Resolved issues and error corrections
Opening the Manufacturing Work Orders page could fail because the list view reused settings meant only for work orders shown inside a manufacturing order. This fix separates the standalone list from the embedded version, so users can access work orders normally again.
Original PR description
### Steps to reporduce: - Go to Manufacturing > Operations > Work Orders #### > Traceback ### Cause of the issue: Since commit 6334294 there is an column_invisible attribure relying on `parent.state` in the `mrp_production_workorder_tree_editable_view`: https://github.com/odoo/odoo/blob/688ea6ba1433169523bdab928cf6c1950b71b514/addons/mrp/views/mrp_workorder_views.xml#L84-L85 However, since parent is not defined in the tree view of mrp.workorder's when these are not integrated in the mrp.production form view, this generate a traceback. ### Note: In 16.0 this expression is understood as being falsy if parent is not defined which is the expected behavior and does not lead to a traceback. opw-3873108 opw-4010550 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The stock reception report now correctly identifies matching delivery documents when an immediate transfer is received. This ensures users can allocate received products to the appropriate existing documents instead of seeing an incomplete source list.
Original PR description
**Current behavior:** Creating an immediate transfer and attempting to allocate it for some existing document will not work- a valid document will not show up in the list of sources. **Expected…
**Current behavior:**
Creating an immediate transfer and attempting to allocate it for
some existing document will not work- a valid document will not
show up in the list of sources.
**Expected behavior:**
A source that logically matches the immediate transfer should
be found for allocation.
**Steps to reproduce:**
1. Enable the reception report setting
2. Create a delivery for some product and confirm it
3. Create a receipt transfer and create a move line (not move)
for the same amount of the product in the delivery
4. Validate the picking, click the `Allocation` smart button ->
See that the delivery is not listed
**Cause of the issue:**
After the quantity field changes on stock move/move lines, in
`ReceptionReport::_get_report_values()` a move that is created
for an immediate transfer will have a `product_qty == 0`. This
means it is never added as a dict key which is later used to
search for moves belonging to allocation sources.
**Fix:**
Use `move.quantity` when `move.product_qty == 0` to gather valid
out documents when creating the report data.
opw-4075871Corrected a payroll calculation error in the Belgian localization where employees on extended leave (such as maternity leave) were incorrectly receiving representation fees meant to compensate work expenses. The fix ensures representation fees are only paid when employees have actually worked, not when they are on leave regardless of paid public holidays during that period.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Enable Belgian localization; 2. create a public holiday; 3. have a contracted employee with CP200 salary structure; 4. make sure they get representation fees; 5. create a month-long maternity leave overlapping the holiday; 6. generate a payslip for that month. Issue ----- Employee receives representation fees, meant to compensate work expenses, despite not having worked that month. Cause ----- Representation fee calculation is currently based on "paid days" rather than days where the employee worked. As maternity leave is unpaid, the employee would normally not get representation fee, but because of the paid public holiday, the calculation continues as if the worker wasn't on leave. Solution -------- Check the `work_entry_type_id` of worked days, and skip representation fee calculation if all have `is_leave` set to `True`. opw-3908980 Forward-Port-Of: odoo/enterprise#68462
This fix resolves an access error that prevented users with Billing rights from using the vendor QR code scanning feature. The QR scan functionality now works correctly for all authorized billing users, improving their ability to process vendor bills efficiently.
Original PR description
Before this commit: When a user with Billings rights scans a QR code using the vendor QR scan feature, an ir.act.window access error appears. After this commit: We fix the access error. And the QR scan feature works correctly as intended.
This fix corrects an issue where the EC Sales report was displaying an incorrect country code (e.g., "A1" instead of the actual country code) when processing customer VAT numbers. The system now uses the customer's actual country code instead of trying to extract it from the VAT number, ensuring accurate reporting for cross-border sales.
Original PR description
Steps to reproduce: [l10n_be] - Create a customer from Spain with the following VAT: A12345674 - Create an invoice with the customer - Go to EC Sales report Issue: The country code used in the report is "A1" Solution: Instead of inferring the country code from the VAT, we use the country code per se; to be a bit more defensive we fall back on the initial flow in case there is no country code. opw-4080828 Forward-Port-Of: odoo/enterprise#69125