Monday, August 26, 2024
10 changes · 17.0
Enhancements to existing features
This update improves the German tax report (DateV) export functionality by fixing formatting issues with unique identifiers in CSV files, separating CSV and attachment exports into distinct files for better organization, and ensuring only the primary attachment per transaction is exported as required by the format. These changes ensure the exported files comply with DateV format requirements and improve the user experience with clearer button labels.
Original PR description
While the format for the guid is the right in the xml, for the CSV, we should add double quotes, as asked by the format. The 2 zip should really be separated, with one for the csv and the other for the attachments Renamed the 2 buttons to indicate more clearly what they are about. The csv only expects a single attachment per move. We should then only export the message_main_attachment_id task-4131986 Forward-Port-Of: odoo/enterprise#68794
Resolved issues and error corrections
A spacing issue in the Mexican EDI payment report has been corrected where a space was missing between the VAT label and account information. The fix adds consistent styling to ensure proper spacing between these elements, improving the readability and professional appearance of payment reports.
Original PR description
In the payment report, a space was missing between the VAT label and the span "Emitter Acc. Ben.". In order to don't rely on spaces, a ps-1 class was added in both "Emitter Acc. Ben." and "Emitter Acc. Ord.". --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#53722
When canceling a payslip with posted journal entries, the system now reverses those entries instead of attempting to delete them. This preserves the audit trail of financial transactions, which is required by regulations in many countries like India. Draft entries are still deleted as before, similar to how expense handling works.
Original PR description
Create a new payslip Select Employee and contract Compute Sheet Create Draft Entry > Post Draft Entry Cancel payslip Issue: The system will attempt to reset to draft and unlink the associated invoice In some cases this is not ideal: due to regulations, we might need to preserve an audit trail to have auditable journal entries After this commit the system would unlink only draft entries and reverse already posted move, similar to what we do for expenses opw-4075244 Forward-Port-Of: odoo/enterprise#68044
Fixed an issue where users in Ecuador couldn't enter custom document numbers when creating credit notes from bills with foreign suppliers. The system was incorrectly enforcing Ecuador's document format rules for all suppliers. Now, foreign suppliers can use any document number format without validation errors, as per regulatory requirements.
Original PR description
Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about the initial move. Instead of using a context or adding new fields, we add a hook in which we can specify certain conditions to bypass the document check/formatting for localisations. We had to add `partner_id` to avoid the flow in wich the user set a foreign customer and a custom document type to change back the customer to an ecuadorian one; hence the second part of the test opw-3993305 Forward-Port-Of: odoo/enterprise#67589
Fixed an issue where uploading tax certificates and passwords through settings would fail if the password was saved before the certificate. The system now validates these fields at the point of use rather than through a constraint, allowing for more flexible handling of optional passwords. This resolves upload failures in the Dutch tax reporting module.
Original PR description
The constraint here fails because when uploading the certificate, password and key through the settings, the values are written one by one on the company, which made it fail in case the password is written first (the constraint would test the password on empty values and throw an error). The groups right is not useful anymore as the flow uses sudo to modify it outside of the settings. Forward-Port-Of: odoo/enterprise#67874
This fix resolves an error that occurred when non-accounting users tried to create invoices from sales orders in Chile. The change makes invoice reference records accessible to all internal users, allowing sales teams to generate draft invoices without requiring accounting permissions. This restores the expected behavior that existed before the Chilean EDI module was installed.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/175988 A user without any accounting access right set get an error when creating an invoice from a sale order. The user should be able to see the draft…
Community PR: https://github.com/odoo/odoo/pull/175988 A user without any accounting access right set get an error when creating an invoice from a sale order. The user should be able to see the draft invoice when clicking on the 'Create Invoice' from a sale order, as it is the case without the l10n_cl_edi module. ### Steps to reproduce: - Install the 'l10n_cl_edi' module - As admin go to Settings > Manage Users, click on a User and, in Access Rights, change Accounting > Invoicing to nothing - (Make sure the User Type is Internal User) - Switch to this user - Go to Sales and create a new Quotation, confirm - Click on the 'Create Invoice' button - An access error appears because of 'l10n_cl.account.invoice.reference' ### Cause: The records of `l10n_cl.account.invoice.reference` are only readable by Accounting groups. ### Solution: Make the records of `l10n_cl.account.invoice.reference` accessible to all internal users. This will raise another access error for `l10n_latam.document.type`, so we also need to make them accessible (in community). ### Note: I noticed the access right of `l10n_cl.account.invoice.reference` were giving rights to `account.group_account_invoice` twice where I think the second time was supposed to be `account.group_account_manager`. I don't know if this is wanted but it doesn't make sense to have two lines for the same model and user group. I decided to only change `group_account_invoice` to `group_account_manager` so this PR is removing the write, create, unlink rights of `account.group_account_invoice`. opw-4078302
This fix ensures that approval notification messages in Studio are now translated to the language of the first notified user, rather than always appearing in English. This resolves an issue where users with non-English language preferences would receive approval messages in English when purchase order confirmation rules were enabled.
Original PR description
Problem: When the user enable approval rules for confirming purchase orders, the approval message was not being translated to the user's preferred languages. Purpose: Since multiple users can be notified for the approval, it was discussed that translating the message to be in the language of the first user should help with the limitation. It will solve the bug in the case only one user needs to be notified. Steps to reproduce on Runbot: 1. Install Studio and purchase 2. create a purchase order without confirming it 3. Go into Studio and edit the "confirm order' button on the PO 4. Add 2 approval rules - notify User A with notification order 1 - notify User B whose language is not English with notification order 2 5. Confirm the PO and observe the message is sent in English opw-3932725
Fixed an issue where large numbers (10+ digits) were being cut off in the MPS planning tool when the Actual Demand/Replenishment feature was enabled. The numbers now display properly across two lines in the cell instead of being cropped, ensuring users can see complete values when entering large quantities.
Original PR description
When filling big numbers (10+ digits) in the input field with Actual Demand/Replenishment activated, the field limits itself to 38% of the cell width, which then crops the number inside. This fix replace the inline-flex by a normal flex, as well as removes the max-width. This way if Actual Demand/Replenishment is activated, it will be shown over 2 lines in the cell. fp-request
This fix resolves an error that occurred when processing payslips with multiple salary attachments of the same type. Previously, the system would fail when trying to mark a payslip as paid if it contained multiple input lines with identical salary attachment types. The fix ensures these multiple lines are properly handled and merged during payslip processing.
Original PR description
Issue ----- Error when multiple input lines on a payslip are of the same type. Steps ----- [hr_payroll] 1. Create a salary attachment for an employee, type "Attachment of salary", with a monthly amount and total amount A. 2. Create another salary attachment for the same employee, same type and monthly amount and total amount B different from A. 3. Create a payslip for the employee, create a contract with a start date matching the salary attachment date. On "Other Inputs", remove the "Attachment of salary" line. Create two input lines of type "Attachment of salary", one with amount A and another with amount B. 4. Compute sheet > Confirm > Mark as paid > ** Error ** Cause ----- Generally, input lines of the same type on a payslip will be merged in one input line, but it is not the case if there are multiple salary attachments of the same type matching these input lines. opw-4066851 Forward-Port-Of: odoo/enterprise#68441
This fix addresses a performance test failure in the Appointment module where database queries were exceeding expected limits. The issue occurred when the Appointment module was tested in isolation, and the fix ensures consistent test conditions by warming up the cache to prevent unexpected query increases from being missed in future updates.
Original PR description
Before the commit the [appointment single module build](https://runbot.odoo.com/runbot/build/66250461) is breaking due to query_count being more than 9 (11) The increase was introduced in b3487219c070cdc03c933d92bc0d362ad733e11f in `_unavailable_intervals_batch`. It wasn't detected because the are less queries in the standard build all modules installed) because of a warmer ormcache. (get_lang) This commit proposes to warmup the test in all case to avoid the extra queries when appointment is installed alone, hopefully avoiding to miss the increased query count next time.