Friday, May 31, 2024
12 changes · saas-17.3
Resolved issues and error corrections
Financial report date filters now calculate previous months correctly when the current date falls on the 31st. This prevents reports from staying on the wrong month and helps users get the expected reporting period.
Original PR description
The date filters weren't working on the last day of certain months (31st). For example, if we are the 31st of may, and we try to get back one month, We would expect to be the 30th of april. Instead, what the code was doing was strictly removing one month to the date, so we will be the 31st of april and since that date doesn't exist, the value that was returned was still 31st of may. To fix that, we now use luxon to make the date calculation.
The Malaysia reporting module now correctly requires the accounting reports component it depends on. This prevents setup or visibility issues when Accounting or Invoicing features are enabled.
Original PR description
l10N_my_reports does not depend on account_reports currently while it should. It was made visible with the changes with Invoicing/Accounting modules. runbot-66373
Miscellaneous changes
This pull request updates Odoo's release information for the SaaS 17.3 version. It helps ensure the product correctly identifies and packages this release for customers and internal teams.
This commit implements a new (bridge) module that adds the spanish TBai QR code on the Point of Sale checkout order receipt. Problem: Right now, with the l10n_es_pos, it works when the EDI is SII as it creates the invoice automatically and sends it in the background. In the case of simplified invoices, we even skipped the downloading of the PDF because that takes time. But there, you do not need any response from the government to show to your client. With TicketBai however, this is differe
Original PR description
This commit implements a new (bridge) module that adds the spanish TBai QR code on the Point of Sale checkout order receipt. Problem: Right now, with the l10n_es_pos, it works when the EDI is SII as it creates the invoice automatically and sends it in the background. In the case of simplified invoices, we even skipped the downloading of the PDF because that takes time. But there, you do not need any response from the government to show to your client. With TicketBai however, this is different, as we need the QR code on the ticket. Solution: when processing the data in the PoS payment, we look for the move created and asks for the qr url right away. If it doesn't have them (because the sending is not done yet), we synchronously call the post method and get the url. This URL is then transfered to the javascript code and eventually the XML of the receipt, where the QR code is shown. task-id: 3916236 Forward-Port-Of: odoo/odoo#166972 Forward-Port-Of: odoo/odoo#166019
Bug: Invoices created for sales orders generated by a repair order didn't show SN/lot number for products that are tracked when activating "Display Lots & Serial Numbers on Invoices" setting. This was because the method generating the lots for the report only included stock move lines that had `customer` in its source or destination location usage, which is not the case in the move lines of a repair order. Fix: Exclude repair move lines from this check. Task-3848611 --- I confirm I h
Original PR description
Bug: Invoices created for sales orders generated by a repair order didn't show SN/lot number for products that are tracked when activating "Display Lots & Serial Numbers on Invoices" setting. This was because the method generating the lots for the report only included stock move lines that had `customer` in its source or destination location usage, which is not the case in the move lines of a repair order. Fix: Exclude repair move lines from this check. Task-3848611 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167187 Forward-Port-Of: odoo/odoo#166979
Description of the issue/feature this PR addresses: This PR aims to address the issue where the cancel buttons (on transfer and MO) are prone to accidental presses due to their proximity. Currently, pressing the cancel button immediately cancels the transfer or MO. Current behavior before PR: Pressing the cancel button results in immediate cancellation of the transfer or MO. Desired behavior after PR is merged: After merging this PR, Odoo will prompt for confirmation when the cancel but
Original PR description
Description of the issue/feature this PR addresses: This PR aims to address the issue where the cancel buttons (on transfer and MO) are prone to accidental presses due to their proximity. Currently,…
Description of the issue/feature this PR addresses: This PR aims to address the issue where the cancel buttons (on transfer and MO) are prone to accidental presses due to their proximity. Currently, pressing the cancel button immediately cancels the transfer or MO. Current behavior before PR: Pressing the cancel button results in immediate cancellation of the transfer or MO. Desired behavior after PR is merged: After merging this PR, Odoo will prompt for confirmation when the cancel button on a transfer or MO is pressed. This will help prevent accidental cancellations. Additionally, the confirmation warning should always be present for both cancel buttons on the MO to ensure consistency. See below attached for a confirmation message: On transfer,  On MO,  --- I confirm I have signed the CLA and read the PR guidelines at [submit-pr](www.odoo.com/submit-pr) Forward-Port-Of: odoo/odoo#164934 Forward-Port-Of: odoo/odoo#160609
Prior to this commit, if a partner was not loaded into the PoS, their name would not be displayed in the sale order list. This commit resolves this issue by ensuring missing partners are loaded when retrieving sale orders. opw-3881799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166170 Forward-Port-Of: odoo/odoo#164603
Original PR description
Prior to this commit, if a partner was not loaded into the PoS, their name would not be displayed in the sale order list. This commit resolves this issue by ensuring missing partners are loaded when retrieving sale orders. opw-3881799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166170 Forward-Port-Of: odoo/odoo#164603
Prior to this commit, if a product wasn't loaded into the PoS, it would result undefined in the model. For instance, if one of the products in a combo product wasn't loaded into the PoS, an error would be raised when clicking on its combo product. This commit resolves the issue by ensuring that missing products are loaded, thereby preventing such errors. In addition, this commit introduces a domain to restrict the category, if applicable. opw-3810994 --- I confirm I have signed the CLA an
Original PR description
Prior to this commit, if a product wasn't loaded into the PoS, it would result undefined in the model. For instance, if one of the products in a combo product wasn't loaded into the PoS, an error would be raised when clicking on its combo product. This commit resolves the issue by ensuring that missing products are loaded, thereby preventing such errors. In addition, this commit introduces a domain to restrict the category, if applicable. opw-3810994 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164313 Forward-Port-Of: odoo/odoo#160340
It makes no sense to have this test working with external since we're not checking CFDI content. Plus we fix the date to avoid errors. task-no Forward-Port-Of: odoo/enterprise#63572
Original PR description
It makes no sense to have this test working with external since we're not checking CFDI content. Plus we fix the date to avoid errors. task-no Forward-Port-Of: odoo/enterprise#63572
When a purchase order was matched and imported by the OCR, it wasn't working properly, the data imported was overwritten with the detected fields of the OCR. This happened because, in the implementation before this commit, a flag `force_write` was used to indicate that the data should be overwritten, but this implied that the data imported from the PO was also overwritten. In this new implementation, the content of the invoice is first reset and then the logic to fill in the invoice with t
Original PR description
When a purchase order was matched and imported by the OCR, it wasn't working properly, the data imported was overwritten with the detected fields of the OCR. This happened because, in the implementation before this commit, a flag `force_write` was used to indicate that the data should be overwritten, but this implied that the data imported from the PO was also overwritten. In this new implementation, the content of the invoice is first reset and then the logic to fill in the invoice with the OCR data and/or purchase order is applied. Task: [#3834665](https://www.odoo.com/odoo/project.task/3834665?cids=1) Forward-Port-Of: odoo/enterprise#63510 Forward-Port-Of: odoo/enterprise#63290
This commit hides the unused "rating_last_text" field from the list view of tickets, preventing a duplicate rating. Linked PR: https://github.com/odoo/enterprise/pull/52371 task-3869775 Forward-Port-Of: odoo/enterprise#60761
Original PR description
This commit hides the unused "rating_last_text" field from the list view of tickets, preventing a duplicate rating. Linked PR: https://github.com/odoo/enterprise/pull/52371 task-3869775 Forward-Port-Of: odoo/enterprise#60761
This pull request prepares the Enterprise edition for the SaaS 17.3 release. It is a release housekeeping change that helps align the codebase with the new version and does not indicate a specific user-facing feature change.