Monday, May 5, 2025
8 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
Miscellaneous changes
Before, `l10n_ar_edi` had only live test cases. This means that if there is an error in a PR or forward port, no tests would catch it as the were marked `external_l10n` and not ran. Using both `l10n_ke_edi_oscu` and and `l10n_br_edi_pos` recent mock setup as an example, this PR aims to mock the soap requests sent in the module. Notes: - As of now this is only one individual test case. More tests will come as there is time, but having 1 will prevent errors from happening again. - Within th
Original PR description
Before, `l10n_ar_edi` had only live test cases. This means that if there is an error in a PR or forward port, no tests would catch it as the were marked `external_l10n` and not ran. Using both…
Before, `l10n_ar_edi` had only live test cases. This means that if there is an error in a PR or forward port, no tests would catch it as the were marked `external_l10n` and not ran. Using both `l10n_ke_edi_oscu` and and `l10n_br_edi_pos` recent mock setup as an example, this PR aims to mock the soap requests sent in the module. Notes: - As of now this is only one individual test case. More tests will come as there is time, but having 1 will prevent errors from happening again. - Within this module, when the first record within an EDI journal is created, it will try to pull the sequence from the database, and if it can't find a suitable last sequence, it will query the API. This means that any onchange on the first journal entry that will recompute the name or sequence leads to the `_get_last_sequence` function being called and making an API request as the sequence isn't stored in the database yet. The point of this appears to be convenience when transfering from another system to odoo and pulling the latest invoice number they had. The main downside of this feature is that creating the first record now has around 9 API calls returning the same value due to different onchanges on the record. The main calls come from `_compute_name` in the base account module but the rest are from other methods that use the sequence or call `_compute_name` (like `_onchange_l10n_latam_document_type_id`) As this PR is only intended to write tests for the module, the test file matches what occurs in the front-end but future PRs can look into if there are improvements that can be made on stable to simplify this. task-4714096 Forward-Port-Of: odoo/enterprise#83553