Friday, October 11, 2024
20 changes · 17.0
Resolved issues and error corrections
Italian electronic invoices for services are now classified with the correct government document type. This helps prevent incorrect submissions caused by misidentifying regular service invoices as professional fee documents.
Original PR description
When sending a document to the government, we have to put a certain document type. The document type are computed depending on what's on the lines of the move, the type of the move, etc The mapping was wrongly done. For the moment when doing an invoice with a service, it will be mapped as a TD03 which was wrong. It should still be TD01. We misinterpreted the professional fees by just checking if there is more service than goods product but now we will add a tag that can be used on account for that. task:4244462 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Timesheets linked to tasks for child contacts can now select sales orders from the parent company as well as the child contact. This helps users bill service work correctly when projects or tasks are managed under subsidiary contacts.
Original PR description
Steps to reproduce: - Sell any service product to a company with a child contact - Create a billable project with timesheets - Create a new task inside the project with the child contact as customer - Timesheets tab > Add a timesheet > Remove the Sales Order Item - Try to fill in the Sales Order Item Only SOs with the child contact show up as option when the expected behavior would be to have those of the parent company as well. This happened because the commercial_partner_id field was removed from project.task in 17.0. This fix only shows the SOs where the partner is the same as that of the task's partner or it's parent company when we previously wuld have had access to 'siblings' under the same cmpany. Restoring it fully would require bringing back the commeercial_partner_id field on task. opw-4214601 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change checks that the file storage location can be written to before moving attachments out of the database. If the location is not writable, the migration stops with an error instead of risking lost files.
Original PR description
Description this PR addresses: Fixes #181899: Prevents data loss when migrating attachments from DB to filestore by adding a writable permission check before migration. Current behavior before PR: Migration to filestore proceeds even if the target directory is not writable, resulting in data loss. Desired behavior after PR is merged: Writable permissions are checked before migration. If the target directory is not writable, an exception will be raised --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Refunding an unsettled Authorize.net payment now correctly voids and cancels the transaction in one step. This removes the need for users to press the refund button twice and makes payment handling more consistent.
Original PR description
Upon attempting to refund an Authorize.net transaction, its state on the provider side is fetched to decide on the refund strategy. If the payment is not yet settled, the refund is achieved by sending a void request rather than a refund request. This flow was not fully working because the payment engine refused to move the transaction state from `done` to `cancel`. This forced users to hit the "Refund" button once to send the void request and a second time to cancel the transaction, as the second attempt was working thanks to the change of transaction state on the provider side. This commit allows Authorize.net transactions to move from the `done` state to the `cancel` state. It is not necessary to ensure we are in the context of a refund because we always check that a transaction is in the `authorized` state before attempting to void it. opw-4201355
Fixed an issue where QR codes could be missing from the first printed Point of Sale receipt on iPads, leaving a blank space. Receipts now wait until images are fully ready before printing, improving reliability for QR-code receipt workflows.
Original PR description
Currently, when using any browser on an Ipad, qr codes will not be shown on the printed receipt, when printed for the first time. When printing it a second time, it will appear. Steps to reproduce:…
Currently, when using any browser on an Ipad, qr codes will not be shown on the printed receipt, when printed for the first time. When printing it a second time, it will appear.
Steps to reproduce:
-------------------
* Use an Ipad (or simulate one)
* Go to the **Point of sale** App
* Select **Configuration** > **Settings**
* Enable QR code on receipt
* Open shop session
* Make an order and pay it
* Print the receipt
> Observation: QR code does not appear, big white space where it should be
* Print it again
> Observation: QR code is printed
Why the fix:
------------
```js
function createImage(url) {
return new Promise((resolve, reject) => {
const img = new Image();
img.onload = () => resolve(img);
img.decode = () => resolve(img);
img.onerror = reject;
img.crossOrigin = "anonymous";
img.decoding = "async";
img.src = url;
});
}
```
In this piece of code, `img.decode = () => resolve(img);` is supposed to ensure that the image is fully processed but is misused. Decode is not a setter, it's a method that returns a promise when the image is fully decoded. While this code wait for the image to load it does not wait for it to be fully ready (processed).
`img.decode()` ensures that the image has been fully decoded before continuing.
We go one step further with `requestAnimationFrame`. This defers the execution and will ensure that the resolved image is rendered in the next frame. It's more important in devices like Ipad because the broswers tend to handle image operations differently, thus creating rendering and timing issues.
With this fix, we now wait longer to make sure that the image is not only loaded but also fully processed and ready to be shown.
opw-4144049Customers using pickup shipping can no longer proceed to payment without selecting a pickup location, even when the shipping option includes a description. This prevents incomplete checkout choices and reduces order handling issues.
Original PR description
Before this commit, when users added a description to a pickup shipping method, the algorithm to prevent the payment button from being enabled when no pickup location was selected failed. Now, the payment button will be disabled when no pickup is selected even if the shipping method has a description. opw-4040317
Self-order kiosks now recognize when their point-of-sale session is closed from the back office. This prevents customers from placing orders after closing and shows the expected "We are closed" message.
Original PR description
When the session of the kiosk is closed in the backoffice, the kiosk is supposed to show the "We are closed" banner and to no longer accept orders. Currently, this is not the case. In this commit we fix the issue Task: 4219525 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects an issue where auditing expense categories with vehicle split enabled was showing duplicate line items. Lines associated with vehicles were appearing both in the category audit and in individual vehicle audits. The fix ensures vehicle-related lines are excluded from category audits when vehicle split is active, eliminating the duplication.
Original PR description
…le split Currently, when auditing a DNA category with the vehicle split option leads to incorrect values. All the lines from the account being audited are displayed, including those with a 'vehicle_id'. That is wrong, since these lines will be grouped with the corresponding vehicle inside said category. They will appear both when auditing the category as well as when auditing each vehicle from this category. The solution is simply to exclude lines related to a vehicle when auditing a category while the vehicle split is active. task-4023543 Forward-Port-Of: odoo/enterprise#71382
This fix prevents incorrect validation errors when posting expense reports with incomplete partner addresses. The tax address validation is now only applied to customer invoices and credit notes, where external tax integrations are actually used, rather than blocking expense report processing.
Original PR description
1. Enable "auto-detect" on the Avatax fiscal position, 2. Go to "Abigail Peterson" contact and set "United States" as country 3. Expenses > My Expenses > New 4. Enter a description, set a total and "Abigail Peterson" as employee 5. "Create Report" > "Submit to Manager" > "Approve" > "Post Journal Entries" Issue: Validation error will raise because of the incomplete address However we only handle customer invoices and customer invoice refunds (aka credit notes) with external tax integrations so the constraint should only show for journal entries of this type. opw-4151193 Forward-Port-Of: odoo/enterprise#71543
When a company changes its global appraisal plan in settings and has appraisal automation enabled, the system now automatically recalculates the next appraisal date for all employees. This ensures that employee appraisal schedules stay synchronized with the company's current plan settings.
Original PR description
There is an *Appraisal Plan* section in the setting that allows setting the global plan for the company. If *Appraisal Automation* is enabled and the plan is changed, we want to recompute the next appraisal date based on it for all the company employees. task-4167727
This fix ensures that when two support tickets are merged together, the total hours spent on both tickets are correctly combined and displayed. Previously, the system was not recalculating the total hours after a merge, resulting in incomplete time tracking data.
Original PR description
### Steps to reproduce: - Create two helpdesk tickets - Create a timesheet for each one of those tickets - Merge the tickets together - Check the 'Hours spent' field where it doesn't show the addition of the two tickets' total_hours_spent ### Current behavior before PR: This is happening because when flushing after merging the tickets the total hours spent does not show in the recomputation tree so it doesn't get recomputed. ### Desired behavior after PR is merged: The idea of the fix came from this commit https://github.com/odoo-dev/enterprise/commit/f4aedadbd6180049573c2b4d90ffc0dd4656ea06#diff-9a1216d4c95d4f60296c59d0294e505970b4d97ad4ac256e1a87c7289f1f8129R17 since the issue got resolved in 17.4 because of this commit where it changed the dependency of the project_id which leads to the existance of the total_hours_spent in the tree of recomputation that is depending on the helpdesk.ticket.project_id opw-4226970
This fix corrects an error in the Holiday Attest (N-1) document used in Belgian payroll processing. The end date on the attestation was incorrect and has been updated to match the end of the notice period, ensuring employees receive accurate documentation when leaving the company.
Original PR description
The end date on the Holiday Attest (N-1) was wrong. It should be the same as the end of the notice period.
This fix resolves an error that occurred when generating customer statement reports for WhatsApp templates. The system was failing to retrieve the correct data needed for the report, causing the template generation to crash. This update ensures that customer statement reports can now be successfully created and submitted for approval.
Original PR description
Install whatsapp Create a new template as follows: - Account: any (real values not needed to reproduce the issue) - Header Type: Document - Report: Customer Statement - Body: Any Save and Submit for Approval Issue: Tracback will raise during template generation """ TypeError: 'NoneType' object is not subscriptable Template: l10n_account_customer_statements.customer_statements """ This occurs because when generating the report for the template we miss the correct data. Partial backport of f0a82fc57826346d7edae1465b35303bc7d1649c opw-4133970
This fix corrects a display issue in inter-company transactions where purchase order confirmation messages were showing the wrong company name. When syncing sales orders across companies, the system was incorrectly displaying the current user's company instead of the actual company that created the order. This fix ensures users see accurate company information in their purchase order notifications.
Original PR description
Reproduce the issue: - Turn on inter-company transactions to sync Sales and Purchases - Create an SO in one company for the second company - Chatter displays an incorrect message noting the record was created from the current company instead of the triggering company The issue: In the sale_order.py model of sale_purchase_inter_company_rules.py, the field of the current company was used instead of the field of the order's company. opw-4199979 Forward-Port-Of: odoo/enterprise#71624
This fix enables customers to print receipts directly from the self-order kiosk using IoT-connected printers, a capability that was previously unavailable. This improves the customer experience by allowing them to obtain physical receipts at the point of sale without manual intervention.
Original PR description
This commit is a backport of https://github.com/odoo/enterprise/commit/e2da8c4fbbfb50ddc033cf30885fef4394cbe2dc It enables printing receipts in the kiosk using the iot which was not supported before. opw-4120145
This fix corrects how currency exchange rates are calculated for Mexican invoices paid in a different currency. Previously, the system was using rounded amounts to calculate rates, which caused inconsistent exchange rate values in payment documents. The fix now uses the proper conversion rate calculation to ensure all payment records show consistent and accurate exchange rates.
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican localization 2. Create multiple Invoices in USD with different amounts (add the Invoice Date) 3. Send and Print them for the CFDI 4. Register a…
### Steps to reproduce the issue: 1. Activate Mexican localization 2. Create multiple Invoices in USD with different amounts (add the Invoice Date) 3. Send and Print them for the CFDI 4. Register a grouped Payment in MXN for those invoices 5. Go to one of the Invoices and click on Update Payments 6. Go to the CFDI tab and, on the Payment line, click on Force CFDI 7. On the Payment line, you should now be able to Download an XML document 8. In the document, the EquivalenciaDR attributes should have the same values, which is not the case ### Explanation: When calculating the rate (which then is used in EquivalenciaDR) in `_l10n_mx_edi_add_payment_cfdi_values`, we are using amounts that have been rounded out, leading to rates that differ when aiming for certain decimal precisions. ### Fix reasoning: While `_get_conversion_rate` can be used to avoid the inconsistencies of the rounded amounts, it should not be used if the values do not match once they are converted, since the rate would then be wrong. opw-4090269
This fix corrects an accounting discrepancy in German DATEV tax reports where invoice line amounts were being rounded incorrectly, causing amounts to appear 0.01 currency units lower than actual (e.g., 19.94 instead of 19.95). The fix ensures that the original invoice price is used directly in the report rather than a recalculated rounded value, improving accuracy of exported financial data for German tax compliance.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_de_reports - Switch to a German company - Create a 19% included tax - Create an invoice with the following line: * Product: [any] * Quantity:…
**Steps to reproduce:** - Install Accounting and l10n_de_reports - Switch to a German company - Create a 19% included tax - Create an invoice with the following line: * Product: [any] * Quantity: 1.00 * Price: 19.95 * Taxes: [the 19% included tax] - Confirm the invoice - Go to "Accounting / Reporting / Audit Reports / General Ledger" - Download "DATEV DATA (ZIP)" and check "EXTF_accounting_entries.csv" **Issue:** The line for the created invoice has an amount of 19.94 instead of 19.95. **Cause:** As the tax is included, the balance on the line is computed and rounded. When the report is generated, "compute_all" is executed with the rounded balance to retrieve the total price with the taxes. Because the balance used in "compute_all" has been rounded and therefore is not exactly the same than the original computed value, there can be a 0.01 difference. **Solution:** Use directly "price_total" field when available. opw-4191876 Forward-Port-Of: odoo/enterprise#70801
The restart buttons for the Odoo service and IoT box in the backend were not functioning after the IoT homepage was redesigned. This fix updates the restart buttons to use the correct endpoints from the new homepage, restoring their functionality.
Original PR description
In the rewrite of the IoT homepage, the endpoint for restarting the Odoo service or rebooting the IoT box was changed, leaving the restart buttons in the backend nonfunctional. This PR changes the endpoints used by the buttons to match the new homepage, fixing the issue.
Fixed a bug in the General Ledger search functionality where searching for non-existent accounts would display all lines instead of showing no results. The search filter now correctly shows an empty result set when no matching accounts are found, improving the accuracy and usability of the search feature.
Original PR description
Open General Ledger Search for a non existing account/aline (ex. "1111111111111") Issue: All lines are shown This occurs because we update matched lines only if there is a match, otherwise we reset the filter opw-4160605
This fix ensures that when a subscription product is purchased and paid for at the point of sale, the next invoice date is properly updated in the system. Previously, the next invoice date was not being updated after payment, which could cause billing timing issues for recurring subscriptions.
Original PR description
Steps to reproduce: - Install subscription and pos_sale_subscription - Create a sale order with a recurring product (a subscription) - Settle the sale order in the point of sale - The date of the next invoice is not updated To fix this issue, when the pos_order is paid, we will update the next invoice date of all sale orders in lines that are of type subscription. opw-4072950