Thursday, December 12, 2024
3 changes · saas-17.4
Resolved issues and error corrections
This fix prevents users from changing completed stock move locations in ways that would incorrectly create or remove inventory value. It helps keep stock valuation reports accurate and avoids accounting inconsistencies after inventory moves are finalized.
Original PR description
For now, a user chan change the locations of a done SML, making it valuable while it was not (or the opposite), which leads to a broken stock valuation. To reproduce the issue: 1. In the Settins,…
For now, a user chan change the locations of a done SML, making it
valuable while it was not (or the opposite), which leads to a broken
stock valuation.
To reproduce the issue:
1. In the Settins, enable
- Automatic Accounting
- Storage Locations
2. Create a product category C
- Method: FIFO
- Valo: Auto
3. Create a product P
- Inventory tracked
- Category P
- Cost $1
4. Update its quantity
- 10 x P at WH/Stock
5. Inventory > Reporting > Moves History, open SML related to P
6. Update the SML:
- From: WH/Stock
- To: WH/Stock/Shelf 1
- Quantity: 100
7. Inventory > Reporting > Locations, look for P
- There are two lines
- -100 at WH/Stock
- 100 at WH/Stock/Shelf 1
- And, therefore, the total on hand is 0, which makes sense
8. Inventory > Reporting > Valuation, look for P
Error: There are two lines, one that adds $10 to the valuation (from
step 4) and a second one that adds $90. This is incorrect, the SML
is now an internal move and should not add any value to the stock.
In fact, the first line should even be cancelled
Letting the user changes a done SML can be convenient, but he should
not be able to change the locations as he wants since the code does
not handle all cases.
OPW-4275417This fix prevents Belgian SODA users from running into access errors when editing bank transactions or opening SODA settings. It adds the needed access checks in the stable version so companies can continue using the Belgian accounting workflow without interruption.
Original PR description
Steps to reproduce: - Install account_accountant & l10n_be - l10n_be_soda is auto installed - Modify a bank transaction OR - Try to configure SODA from settings Access Error: The write method on account.move.line, and the SODA import wizard require `group_account_user` access. But this group is only activated with accounting. This module depends on Invoicing (account_accountant) but it should depend on Accounting (accountant). Since this change is not possible for stable, we check for access to the SODA models (`group_account_user`) while the correct fix is applied in master 18.1 (https://github.com/odoo/enterprise/pull/75505) Issue reported by AVW
Fixes an error that could stop payslip calculation after a salary rule was switched to Python Code computation. This ensures payroll users can compute employee payslips normally when using the default rule code.
Original PR description
**Issue:** If a user changes a salary rule to the default Python Code for computation, an error occurs when trying to `Compute Sheet` on an employee's payslip.  **Expected:** The computation should be feasible. **Steps to reproduce:** - Activate Payroll app; - Move to `Configuration/Salary:Rules`; - Select any rule having its `Computation` `Amount Type` field not set to `Python Code` (e.g. `Regular Pay > House Rent Allowance`);  - Change the `Amount Type` to `Python Code`;  - Create a new payslip entry for any employee and change the structure for the one you changed the rule in (e.g. `Regular Pay`); - Click `Compute Sheet`; **Cause:** The Python code displayed in the computation rule contains an uncommented comment line that. **Fix:** Comment the blocking line. opw-4377712