Friday, September 29, 2023
5 changes · master
Resolved issues and error corrections
This update adjusts which sales and accounting details are included in legally required hashes for French compliance. It adds missing line descriptions and dates while removing customer contact IDs from the hash, helping reports and contact merges work correctly without compromising required audit information.
Original PR description
**Description of the issue/feature this PR addresses:** 1/ we should hash the description of the pos.order.line "Chaque inscription doit indiquer la date, la désignation sommaire des objets vendus, ..." https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000042914666 2/ partner_id not need to hash (it is not write in the law). And it is an issue if you need merge contact https://github.com/odoo/odoo/pull/112798 3/ the field date is missing on account.move.line, the field date on account.move is not use in report (like FEC) 4/ the field name is missing on account.move.line. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents errors when deleting project tasks and improves the project sharing flow. Users are now guided to enter the required email details instead of creating an incomplete contact that cannot receive a shared link.
Original PR description
In this PR fixes the trackback while deleting project task also remove quick create option from project sharing wizard. Before this PR, - when user try to delete project task there is trackback which define recursion calling while getting options value. - creating newly partner using quick create option in project sharing wizard partner is not set because of partner email is empty. task-3460164 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents an error that could occur when a user added a lunch product to an empty cart. It improves the ordering experience by ensuring topping selections are handled safely and the cart continues to work as expected.
Original PR description
Description of the issue: This commit addresses a traceback error that occurred when adding a product to the cart with an empty cart. The issue was related to accessing values for 'topping_ids_1', 'topping_ids_2', and 'topping_ids_3' without proper validation Fix: In this fix i have added checks to ensure that the values are present before accessing them this prevents an 'index out of range' error and resolves the traceback problem, additionally, the code now considers the values in 'topping_1_values', 'topping_2_values', and 'topping_3_values' to determine whether to access the values or fall back to default values from the order. Desired behavior after PR is merged: traceback will fixed and work properly task-3511953
Payroll salary rules now keep debit and credit accounts linked to the correct company instead of falling back to the default company. This helps prevent accounting setup errors in multi-company or localized payroll configurations.
Original PR description
The setup of the debit and credit accounts on salary rules were setting the default company instead of the correct one: the mapping for localization of salary rules and accounts were not set on the localization records but on the main company records. Thanks to @FlorianGilbert
The Tax Report now reliably opens the existing closing entry for a period instead of showing an empty list or creating another one. This prevents duplicate period closings and helps keep tax reporting accurate when entries are reset to draft.
Original PR description
The 'Closing Entry' button in the Tax Report has inconsistent behavior when the closing entry is already posted and then reset to draft. In such cases, the button points to an empty list of closing…
The 'Closing Entry' button in the Tax Report has inconsistent behavior when the closing entry is already posted and then reset to draft. In such cases, the button points to an empty list of closing entries instead of opening the existing one. Additionally, there is a possibility of multiple closing entries being created for the same period, leading to incorrect reporting. To address these issues, the following changes have been implemented: 1. When clicking on the 'Closing Entry' button: - If the closing entry already exists for the period, it is opened. - If the closing entry doesn't exist for the period, a new closing entry is created and opened, regardless of the tax lock date. 2. A check has been added to prevent multiple closing entries for the same period. If a closing entry already exists in draft state for the given period, it is updated with the current computations instead of creating a new entry. 3. If a closing entry is already posted but then reset to draft (where the tax lock date is greater than or equal to the end date of the closing entry period), the button will still open the existing entry. Task-Id: 3284543