Monday, May 5, 2025
7 changes · 17.0
Resolved issues and error corrections
Corrected where the custom import form reference is placed in Malaysia e-invoicing XML templates. This prevents errors when import form references and customer references are used together, improving invoice processing reliability.
Original PR description
Fix an issue in the xml template where the custom import form reference is set at the wrong place, causing errors when it is in use at the same time as a customer reference. task-4761954 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents tiny rounding errors from being saved as discount amounts when invoices are imported from PDF/e-invoicing data. It keeps stored accounting values aligned with what users see on the invoice, avoiding confusing near-zero discount entries.
Original PR description
…count value Steps to reproduce: 1. Create an invoice with a product 2. Set quantity to 3, price to 11.34 3. Confirm & get the invoice PDF 4. Upload the PDF in accounting app 5. Check the "discount" value Issue: Visually the result is correct, but the stored value (in db) is not -2.220446049250313e-14 != 0.0 Cause: ``` >>> 3 * 11.34 34.019999999999996 ``` Creating a slight error of -0.0000000000002 opw-4675079
The accounting dashboard now shows amounts marked for checking with the correct currency context for journals using a foreign currency. This prevents users from seeing a company-currency amount paired with the wrong currency symbol, reducing confusion during invoice review.
Original PR description
Steps to reproduce: - create a new journal with foreign currency - create an invoice (amount:100) with this journal and set it "to check" - Go to dashboard Issue: check balance is in company currency amount but the symbol is the one from the currency of the journal Solution: Chkl: <strike>Misc and Sales/Purchase Journals should display all amounts in company currency</strike> Eventually, we decided that it would be better for the stable versions to keep the currency displayed as the one from the journals. We therefore use the same logic as for the bill/invoices opw-4349684
Long contact or company names now display properly in the partner autocomplete field instead of being cut off. This restores the expected behavior from earlier versions, making contact creation clearer for users entering longer names.
Original PR description
**Steps to reproduce:** Create a new contact/company with more than 25 character **Issue:** The name field is partially shown as compared to version 16. **Cause:** The issue occurs after this change (odoo/odoo@a68cfbb) in version 17. The below CSS for the partner autocomplete field has been removed as the field has 'field_partner_autocomplete' widget. https://github.com/odoo/odoo/blob/05e60f226a0d15bfa3b71eaebe2786f4d687f23e/addons/partner_autocomplete/static/src/scss/partner_autocomplete.scss#L31-L34 **Solution:** Reintroduce partner autocomplete CSS fix (odoo/odoo@b9788544b7101e5a202cf87989bc3f5fc0495249) [opw-4686705](https://www.odoo.com/odoo/project/49/tasks/4686705) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Portal users now see the correct allocated time for shared project tasks even when no timesheets have been logged yet. This prevents misleading 0.0 hour values in the task kanban view and helps customers track planned work accurately.
Original PR description
**issue:** When a task with an allocated time > 0.0 but no timesheets is created in a shared project (with edit rights), the portal user incorrectly sees 0.0 as the allocated time. **Steps to reproduce:** - Ensure the sale_timesheet module is installed. - Create a new project. - Create a task with allocated time and no timesheets. - Share the project with a portal user (edit permission). In the portal user's kanban view, the allocated time of the task is displayed as 0.0 instead of the correct allocated time. opw-4582705
Fixes an issue where users could see a missing-record error after deleting a sales order line and then opening the Catalog before saving. The catalog action now runs from the sales order itself, making field service sales workflows more reliable and preventing disruption during order editing.
Original PR description
Steps to Reproduce: 1. Install industry_fsm_sale module. 2. Create a SO with at least one SOL. 3. Save the record. 4. Delete the line, then click the Catalog button without saving. Issue: - An error occurs indicating a missing record. Cause: - The action_add_from_catalog method is accessing self.task_id, but self still includes the deleted SOL, which no longer exists. As a result, accessing its fields raises an error. Fix: - Move the action_add_from_catalog method to the sale.order model, which is the appropriate place to handle this logic, ensuring the method doesn't depend on potentially stale or deleted lines. opw-4760487
The point of sale now hides the option to settle a customer's due balance when the required pay-later payment method is not configured. This prevents staff from starting a payment flow that cannot successfully clear the customer's account.
Original PR description
Currently you are able to select the button to settle customer account/ deposit money even though the config does not have access to a paylater payment method. This will never settle the customer account. Steps to reproduce: ------------------- * Remove the customer account payment method from the config * Open the pos session * Find a customer that has an amount due * Select "Settle due accounts" * Process > Observation: The customer account is never settled. Why the fix: ------------ If there is no payment method of type "pay_later" we should not show the button whose purpose is to use such payment method. opw-4488571