Wednesday, October 23, 2024
4 changes · 17.0
Enhancements to existing features
This update enhances the accuracy of Early Payment Discount (EPD) reconciliation in countries with cash rounding practices. Previously, slight overpayments weren't recognized, leading to manual adjustments. Now, accountants can customize tolerance levels, ensuring correct discount recognition and streamlining reconciliation workflows.
Original PR description
In countries using extensively cash roundings, invoices having a early payment discount can usually be paid within a cash rounding tolerance. e.g. with a cash rounding of 0.05, and an early payment discount of 5%, for a total amount of 868.25, a discount amount of 824.84 will be stored. If a customer pays slightly more (eg 824.85), the early payment will not be recognized in the reconciliation widget, resulting at best in a partial payment that will require extra work for the accountant to write off properly for early payment discount. By allowing to customize the comparison between open amount and total discount, it allows to implement any kind of tolerance in custom modules without breaking anything in the actual reconciliation mechanism. OPW-3985470 Forward-Port-Of: odoo/enterprise#68523
Resolved issues and error corrections
This update resolves an issue where users would receive a technical error instead of a clear message when creating a Sendcloud shipment without selecting a pickup point. The fix ensures a user-friendly error message is displayed, guiding users to select a pickup location for their shipment.
Original PR description
### Steps to reproduce: - Create and configure a Sendcloud shipping method - Create a Contact Bob - Create a subconcat of type delivery for Bob without setting any name > by default its display name…
### Steps to reproduce: - Create and configure a Sendcloud shipping method - Create a Contact Bob - Create a subconcat of type delivery for Bob without setting any name > by default its display name will be "Bob, delivery address" - Create a sale order for Bob - Add a Sendcloud shipment method to that SO and confirm the SO - Go on the associated delivery and try to validate it ### Expected behavior: You should raise a user error telling you that you a pickup point was required for the selected shipping method. ### Current behavior: You raise a traceback prior to that point. ### Cause of the issue: Since you did not set a name on your delivery partner the code will break as soon as you try to generate the parcels data because "False" is not iterable, see: https://github.com/odoo/enterprise/blob/37577535a4482eaa1250b41136b47b3613eb7693/delivery_sendcloud/models/sendcloud_service.py#L576-L577 ### Fix: If for some reason the name of the delivery partner has been removed or was unset (e.g. display name is of the form: Bob, Delivery address), the name of its parent should be used to generate the parcel data. Note: This fix should normally not be that relevant, because, if you were to select a pickup point, the partner used to generate the parcel would already be the parent partner and is guarranteed to have a name: https://github.com/odoo/enterprise/blob/37577535a4482eaa1250b41136b47b3613eb7693/delivery_sendcloud/models/sendcloud_service.py#L556-L561already However, now, if you proceed with this flow without any pickup point (which you can only select form the website) you will now raise a relevant user error: #### Invalid Operation: "A service point is required for the selected shipping method" opw-4118362
This update significantly speeds up the process of retrieving related documents for large projects. By using a more efficient database query, the system now processes document lookups 2.45 times faster, particularly when dealing with projects containing a massive number of tasks. This improves overall performance and responsiveness.
Original PR description
## Description When looking for related documents on a large projects, it can inline a large list of ids (`task_ids`) into the following `_read_group` to retrieve the documents associated with any of the project's tasks. The improvement consists of using a subquery instead of a list of ids when the list `task_ids` becomes "too large". We are using `PREFETCH_MAX` for the "too large" threshold. ## Benchmark The `_read_group` to fetch the related documents on 5 projects, one of which has over 1M tasks. | | Before | After | Speed-up | |---------------|--------|-------|----------| | Timings (hot) | 2.85s | 1.16s | 2.45x | Forward-Port-Of: odoo/enterprise#72468
This update resolves an issue where location scans weren't being properly recognized during internal transfers when a product was manually added instead of scanned. The fix ensures that the system correctly identifies and utilizes the scanned location, improving the accuracy of internal transfer processes. This enhancement streamlines operations and reduces potential errors.
Original PR description
### Steps to reproduce: - Enable "Multi-Steps Routes" in the settings - Add a barcode to a different location that WH/Stock - Go to the barcode > Operations > Internal Transfers > New > The header…
### Steps to reproduce: - Enable "Multi-Steps Routes" in the settings - Add a barcode to a different location that WH/Stock - Go to the barcode > Operations > Internal Transfers > New > The header propose to scan a product - Do not scan the product by click on `+ ADD PRODUCT` - Add 1 unit of your favorite product > The header propose to scan a product or a destination location - Scan the location you had set #### > The location scan is ignored ### Cause of the issue: During the `_parseBracode` called to determine what was scanned by the barcode, a location corresponding to the barcode scanned will be found. To use this barcode, if it makes sense, the `_setLocationFromBcode` will be called in turn. However, during internal transfers, this location will only be used as a destination location under very specific conditions: https://github.com/odoo/enterprise/blob/8035abddf9991f6bfb71bb7889b703e5ed31a179/stock_barcode/static/src/models/barcode_picking_model.js#L1603-L1619 And, since we did add the product manually rather than using a scan, in our case, `this.previousScannedLines.lengt` will be null rather than positive so that the location will not be used to set the destination. opw-4201489