Wednesday, October 23, 2024
5 changes
1 change
Enhancements to existing features
Large spreadsheets now load much faster by avoiding unnecessary server-side processing of already prepared data. This reduces waiting time for users opening spreadsheet documents and lowers server resource usage, especially for very large files.
Original PR description
Server-side load time for a 16.7Mb spreadsheet: **before: 606ms** (`join_spreadsheet_session`) **after: 83ms** (-86%!) (new `/spreadsheet/data/<...>` controller) Previously,…
Server-side load time for a 16.7Mb spreadsheet: **before: 606ms** (`join_spreadsheet_session`) **after: 83ms** (-86%!) (new `/spreadsheet/data/<...>` controller) Previously, `join_spreadsheet_session` returned a combination of: - The full spreadsheet snapshot (JSON file on the filestore) - Pending revision data (also serialized JSON, stored in a Char field) - Additional metadata These were combined into a Python dict and re-serialized into JSON for the response. This process is inefficient as it involved unnecessary parsing and re-serialization of already serialized JSON data. With this commit, we handcraft the json response body, avoiding the need for parsing and re-serializing large json objects, resulting in significant performance improvements in both CPU and memory. To have control of the response body, we now have to use an http controller instead of an RPC method. We could also have sent the raw/serialized data from `join_spreadsheet_session` but then it would be serialized json over json which has several drawbacks: - reduces client-side debuggability - introduce a lot of additional escape characters (e.g. `\"`) - the client would need to explicitly parse the nested json With this solution, the client receives a clean, valid json content type Alternative idea: we could stream the snapshot file directly from the file store to be even more efficient. But then we would need to load the additional metadata and revisions with another http request. As those two requests would not be executed as part of the same transaction, it would come with its own share of issues.
3 changes
Enhancements to existing features
Italian partners now automatically use FatturaPA as their preferred electronic invoicing format. Spanish partners correctly default to Facturae when a certificate exists, improving invoice setup while avoiding errors when no certificate has ever been configured.
Original PR description
…S/IT Add FatturaPA as the preferred EDI format set by default on Italian partners. Fix the preffered EDI format of Spanish partners to be correctly computed to Facturae. task-no
1 change
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
The point of sale now selects an order line only when a cashier has just added a product, and clears selections when reopening orders from areas such as tables, tickets, or payments. This makes the numpad and order editing behavior more predictable, reducing accidental changes during checkout or restaurant workflows.
Original PR description
-Select order line only when I've just added a product to cart -Ensure that no order line is selected anymore when opening an order (from floorplan, table selector, ticket screen, payment screen) -Adapt tours tests to match this new behavior and limit the use of 'inLeftSide' to avoid going uselessly back and forth to the product list in mobile task-id: 4167563 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
The point of sale UrbanPiper integration now creates the store location in Atlas when a user selects Create Store. This reduces manual setup work and helps keep store information aligned between Odoo and Atlas.
Original PR description
After this commit: === - When the user clicks the Create Store button, the location is now created in Atlas. task-4270144