Tuesday, January 27, 2026
23 changes · saas-19.1
Enhancements to existing features
This update allows staff to temporarily hide products in the Point of Sale system by 'snoozing' them. When a product is snoozed, it appears grayed out on the product screen, but remains available for new orders. This helps manage stock levels and avoid overselling.
Original PR description
The PR will add an extra availability section on the product info popup which shows whether a product is currently available. From that section the product can then be 'snoozed', which will make it unavailable for a specified period of time. (1, 2, 4 hours, or for the entire session). When the product is unavailable there's a countdown timer on the popup showing when the product will be available again. Products which are 'snoozed' still show up on the product screen, but grayed out. The effect is purely cosmetic, as they can still be added to new orders. Task-[5170696](https://www.odoo.com/odoo/project/1737/tasks/5170696) Previous discussion-[#232625](https://github.com/odoo/odoo/pull/232625) 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
This update enhances the system administrator notifications displayed in Odoo Enterprise. It now allows for multiple messages with varying levels of urgency, providing more detailed and flexible alerts regarding server maintenance or other important events. This improves communication and allows for more targeted notifications.
Original PR description
Tweak #102239 to allow more flexibility and display multiple messages with different alert level.
The ir.config_parameter is sysadmin.message and should be a json loadable. The format shoud be something like this:
{
"replace": false,
"warning_type": "user",
"message": "<div class='alert alert-info'>A maintenance operation is planned on your server on <strong>2026-01-15</strong> between 14h and 15h</div>"
}
Forward-Port-Of: odoo/enterprise#105157Resolved issues and error corrections
This update resolves a crash that occurred when confirming purchase orders linked to multiple sales orders (grouped RFQs). The fix ensures that each purchase order is associated with only one sales order, preventing a data conflict. This improves the stability of the dropshipping process.
Original PR description
An error occurs when confirming a purchase order linked to multiple sales orders. Steps to reproduce: 1) Install sale_stock & sale_management and enable dropshipping. 2) Create a vendor with…
An error occurs when confirming a purchase order linked to multiple sales orders. Steps to reproduce: 1) Install sale_stock & sale_management and enable dropshipping. 2) Create a vendor with group_rfq 'always'. 3) Create a product with dropship route and add that vendor. 4) Create a Quotation with that product, confirm it, duplicate and confirm. 5) From the magic button go to Purchase Orders and confirm the PO. Reference video for steps : https://drive.google.com/file/d/1xglkuZAWNxcz0WSj_49Hemjkxx4KjSqv/view?usp=sharing Error: `ValueError: Wrong value for stock.picking.sale_id: sale.order(26, 27)` Root Cause: The computed field `sale_id` receives multiple `sale.order` records from `move_ids.sale_line_id.order_id` (see [1]). Since `sale_id` is a Many2one field, it can only accept one record or False. Assigning multiple records causes the error. Fix: * Create only one sale order per purchase order for drop-shipping picking types. For existing databases, set the value to the first available sale_id, or False if none exists. [1]- https://github.com/odoo/odoo/blob/38cffd1d1580693c56f0d897b8c8e60b938a8e85/addons/sale_stock/models/stock.py#L175-L179 opw-5344535 Forward-Port-Of: odoo/odoo#237945
This update fixes an issue where users couldn't adjust the quantity of optional products added through the portal's upsell feature. The change ensures that the 'optional' status is correctly applied to new order lines, allowing users to accurately update product quantities and manage their subscriptions.
Original PR description
Version: - 19.0 Steps to Reproduce: - Enable the Add Products option in the recurring plan. - Create a subscription with the same plan and add optional products. - Confirm the subscription and create invoice for current period. - From the portal, click on Add Quantity to create an upsell order. Before: - Users were not able to update the quantity of products added as optional products from portal. - This happened because the `is_optional` field value was not copied to the new order line created during the upsell. After: - The `is_optional` field value is now copied to the new order line created for upsell and renewal orders. - This allows users to update the quantity of optional products correctly. Impact: - Users can update the quantity of optional products from the portal without issues. task-5427585 Forward-Port-Of: odoo/enterprise#102670
This update enhances traceability for EDI and e-Way Bill requests by storing all request payloads as JSON attachments. This improves debugging, simplifies audits, and strengthens compliance efforts related to these important tax processes. Task 4896516.
Original PR description
Before this PR: - Request payloads sent for EDI and e-Way Bill generation were not persisted. making debugging and audits difficult. After this PR: - all EDI and e-Way Bill request payloads are stored as JSON attachments, ensuring better traceability, troubleshooting, and compliance support. Task: 4896516 Forward-Port-Of: odoo/odoo#241704
This update resolves a bug where overtime entries were being incorrectly generated and overlapping due to a flawed system for managing overtime rules. The fix ensures accurate overtime calculations and prevents overlapping entries, improving the reliability of attendance tracking.
Original PR description
STEP TO REPRODUCE:
------------------
0- Go to attendance > Configuration > Overtime Ruleset 1- Create the following overtime ruleset (all rules are paid and with the entry type overtime):
rule 1: timing rule on worked day with this timing : 0AM -> 8AM
rule 2: timing rule on worked day with this timing : 12AM -> 1PM
rule 1: timing rule on worked day with this timing : 5PM -> 12PM
2- Go to attendance > configuration > settings
3- Enable Time Management
4- ANd change the extra hours validation by automatically approved 5- create an employee and give to him this overtime ruleset 6- Create for an attendance for him from 6AM to 8PM 7- to go the form view of this attendance
8- Approve it; you wwill have a traceback
REASON:
-------
The way to handle the reorganization of the overtime line on an attendance was badly done; everything was shift with the same shift so some overtime was overlapping the others
Forward-Port-Of: odoo/enterprise#105173This update resolves an issue preventing NFC-e refunds from being processed correctly in Point of Sale. Previously, a technical error caused a 'not found' message when attempting to retrieve the original invoice. The fix ensures the system accurately identifies and uses invoice references during the refund process, enabling successful transactions.
Original PR description
**Steps to reproduce:**
- Setup a database that supports NFC-e
- Go to PoS, make a purchase, then refund it
- A traceback appears, saying we couldn't find the original invoice
**Why the fix:**
Before this commit the way we checked if there was already an invoice in the payload we give to the API was wrong, as it was always true. This happens because before the
*def _get_l10n_br_avatax_service_params(self):* call, we set res['invoice_refs'] as {}, then we were supposed to fill it. But if we check https://github.com/odoo/enterprise/blob/32b73b12f9f8f5600b820d9a938bfbb0cf10054d/l10n_br_edi_pos/models/account_move.py#L13 'invoice_refs' is found in res, even though it is empty, so we never entered the if statement.
We now check if there is a value in res['invoice_refs'] and if not we set it.
opw-5359407
Forward-Port-Of: odoo/enterprise#104987
Forward-Port-Of: odoo/enterprise#102770This update fixes an issue where the 'Inventory Reason' entered during barcode inventory counts wasn't being recorded in the system. Now, when completing an inventory count via the Barcode app, the specified reason is correctly logged in the Moves History, ensuring accurate tracking of inventory adjustments. This improves the reliability of inventory reporting.
Original PR description
## Issue When completing an *Inventory Count* from the Barcode app, the *Inventory Reason* requested to the user is not registered anywhere. ## Steps to reproduce 1. Install the *Barcode* app…
## Issue
When completing an *Inventory Count* from the Barcode app, the *Inventory Reason* requested to the user is not registered anywhere.
## Steps to reproduce
1. Install the *Barcode* app (`stock_barcode`)
2. In the *Barcode* app, click *Count Inventory*
3. Add a product and set a quantity for it
4. Click *Confirm* (do not scan to confirm)
5. Write an *Inventory Reason* and click *Apply Now*
6. Go to Inventory > Reporting > Moves History
- **The _Inventory Reason_ given in step 5 does not appear anywhere**
If the inventory adjustment is done through Inventory > Operations > Physical Inventory, the user can also provide an *Inventory Reason*, but this time, it will appear in the *Moves History* in the *Reference* (`stock.move.line.reference`) column.
## Cause
Since https://github.com/odoo/enterprise/commit/3efea75a88120519ef4be1a41c8faa7278bc332c, the value provided by the user is never passed to the Python side.
opw-5423934
Forward-Port-Of: odoo/enterprise#104763This update corrects a compatibility issue with the Bulgarian National Bank (BNB) exchange rate provider. Due to Bulgaria joining the Eurozone, the BNB now provides rates in EUR, not BGN. This change ensures that companies using EUR as their main currency can correctly sync exchange rates without errors.
Original PR description
The `_parse_bnb_data` method assumed that the Bulgarian National Bank (BNB) provides exchange rates against BGN (Bulgarian Lev). However, since Bulgaria joined the Eurozone on January 1, 2026, the…
The `_parse_bnb_data` method assumed that the Bulgarian National Bank (BNB) provides exchange rates against BGN (Bulgarian Lev). However, since Bulgaria joined the Eurozone on January 1, 2026, the BNB now provides rates against EUR. This caused the error "Your main currency (EUR) is not supported by this exchange rate provider" when Bulgarian companies with EUR as their main currency tried to sync exchange rates. refs: We can compare the data here from 31 December using the WayBackMachine: https://web.archive.org/web/20251231193558/https://www.bnb.bg/Statistics/StExternalSector/StExchangeRates/StERForeignCurrencies/index.htm Compared to today: https://www.bnb.bg/Statistics/StExternalSector/StExchangeRates/StERForeignCurrencies/index.htm And see the comparison used to be to BGN but is now for EUR Steps To Reproduce: 1. Create a company for Bulgaria with EUR as the main currency. 2. Go to Accounting Settings -> Automatic Currency Rates. 3. Select "[BG] Bulgaria National Bank" as the service provider. 4. Click the sync button. 5. Error appears: "Your main currency (EUR) is not supported by this exchange rate provider. Please choose another one." The fix updates the base currency from BGN to EUR, matching the current BNB XML format which now provides rates against EUR. Note: Companies with BGN as main currency will now get the same error, which is expected since the BNB no longer provides BGN-based rates. This behavior was discussed and confirmed with the PO. Ticket [link](https://www.odoo.com/odoo/project.task/5483771) opw-5483771 Forward-Port-Of: odoo/enterprise#105074
This update fixes an issue preventing bookings from being scheduled for the last hour of the day in the appointment system. The previous code incorrectly treated the end of the day as an unavailable slot, blocking bookings. This change ensures that appointments can now be booked for the full 24-hour period, resolving a common user frustration.
Original PR description
**Steps to reproduce:** - Go to Appointment app - Edit an appointment type - Ensure its availability is on resources - Set duration to 1 hour - Add a schedule slot ending in 00:00 - Save and go to…
**Steps to reproduce:** - Go to Appointment app - Edit an appointment type - Ensure its availability is on resources - Set duration to 1 hour - Add a schedule slot ending in 00:00 - Save and go to the website page of the appointment - Last slot is not showing (23:00-00:00) **Issue:** When computing the appointment slots of a resource using time range, the end of day is considered as an unavaibility resource slot with this interval in `_get_unavailable_intervals`: `i_start = 23:59:59.999999` `i_stop = 00:00` this conflicts with the given range (23:00-00:00) in `self._slot_availability_is_resource_available` It comes from `_attendance_intervals_batch`, as `float_to_time(24.0)` is converted to `time.max` (23:59:59.999999) by: `day_to = datetime.combine(day, float_to_time(attendance.hour_to))` This introduces the microsecond unavaibility at the end of the day, which blocks the booking. (it's working properly for availability on users appointments) **Fix:** Changed the condition so that 23:59:59.999999 is considered as equal to 00:00. opw-5163892 Forward-Port-Of: odoo/enterprise#104927 Forward-Port-Of: odoo/enterprise#100853
This update fixes a layout issue where image gallery indicators become cramped with many images and improves the overall responsiveness of image carousels, particularly on Firefox. By preloading images and optimizing the loading process, the gallery now appears smoother and more reliable.
Original PR description
## [FIX] website: add versioning for GallerySlider interaction The GallerySlider interaction (and its edit mode counterpart) is not up to date: the logic is still written for old snippets (before…
## [FIX] website: add versioning for GallerySlider interaction
The GallerySlider interaction (and its edit mode counterpart) is not up
to date: the logic is still written for old snippets (before [9042b1c],
so before 18.0).
In the meantime, the pagination for the indicators was lost, meaning
that if you add too many images, the indicators will have less and less
space.
Steps to reproduce:
- Drop an Image Gallery snippet
- Set the indicators to squared or rounded miniatures
- Add 15 or more images
=> All the indicators are crammed into the same line.
With this commit, we deprecate the old `GallerySlider` interaction and
create a `GallerySlider001` for the snippets dropped since 18.0.
For the indicators, instead of a pagination, we now use a horizontal
scrolling container which centers on the active indicator.
[9042b1c]: https://github.com/odoo/odoo/commit/9042b1c
## [FIX] website: preload available carousel images
As images are lazy loaded, it means that in the context of a carousel or
an image gallery, they only start loading once the user clicks either on
its indicator or on the previous / next button (or after completing an
auto-slide). While Chrome seems to optimize that to make it seemless, on
Firefox this causes the carousel slide to appear blank for a moment
before the image suddenly pops up, as the sliding animation arrives to
its end.
In effect, this causes a flicker and a feeling that the carousels, and
especially the gallery, is extremely laggy.
To mitigate that while trying to keep the advantages of image lazy
loading, this commit partially backports [08d837e], which loads the
images of the next and the previous carousel items.
Additionally, we prefetch the target images on pointerdown / keydown on
an indicator. That may seem like too small of a difference to be
interesting, but it actually gives a little bit of time between the
pointerdown and pointerup (which triggers the slide event) to start
loading the images, which with a correct connexion already goes a long
way towards mitigating the laggy feeling.
[08d837e]: https://github.com/odoo/odoo/commit/08d837e70f28a84a9bd97974f5d15d387a42b7c0
task-5245513
Forward-Port-Of: odoo/odoo#245144
Forward-Port-Of: odoo/odoo#232147This update resolves an issue where country-based filtering on payslips and payslip runs wasn't functioning properly, leading to errors. The fix ensures accurate country filtering, preventing module loading problems and improving the reliability of payroll reporting.
Original PR description
Issue: The country_id related field on payslip and payslip run was not stored, causing domain filters and search on this field to fail and triggering client-side errors. Fix: Use search parameter to write function so field can be used safely in search domains and filters. Impact: Country-based filtering now works correctly without triggering module loader errors. Task: 5406904 Forward-Port-Of: odoo/enterprise#104167 Forward-Port-Of: odoo/enterprise#103318
This update ensures that employee leave dates are automatically recalculated when their working schedule (calendar) changes. Previously, changes to an employee's schedule didn't correctly update their leave entitlements. This fix maintains accurate leave tracking for employees with dynamic work calendars.
Original PR description
purpose: Accepted leaves should be recomputed upon working schedule change. - made the `resource_calendar_id` change on the leave when it's changed on the corresponding employee/contract, then forced recomputation of its dates from the new resource calendar task-id: 5424312 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243425 Forward-Port-Of: odoo/odoo#241284
This update resolves a bug that prevented the Gantt chart from correctly rescheduling tasks when using Date fields instead of DateTime fields. The fix ensures that the Gantt chart can now handle rescheduling tasks with Date fields, improving usability and flexibility for project management. This was caused by a previous limitation in the system.
Original PR description
…atetime
Steps to reproduce
==================
- Install web_studio,project
- Open a project task
- Open studio
- Add a new Date field in the form view
- Switch to the gantt view
- Change the Start Date Field to the newly create Date field
- Exit studio
- Open a task
- Set a value for the date field
- Switch to the gantt view
- Drag the record
```
start_date_field_name in vals and datetime.strptime(vals[start_date_field_name], '%Y-%m-%d %H:%M:%S')
^^^^^^^^
ValueError: time data '2025-12-22' does not match format '%Y-%m-%d
```
Cause of the issue
==================
Since https://github.com/odoo/enterprise/pull/84820 , it only works for DateTime fields
opw-5345470
Forward-Port-Of: odoo/enterprise#103068This update resolves an issue where image selections in the website builder were not consistently updating across related components. The fix ensures that the correct image element is always used when processing snippets, resulting in a more reliable and accurate website design experience. This improves the overall user experience when adding images to the website.
Original PR description
[FIX] html-builder, *: update snippet at each snippet dropped handler *: website In the `ImageSnippetOptionPlugin`, at the `on_snippet_dropped_handlers` call, the `snippetEl` received as argument is replaced by the image selected by the user in the media dialog. The problem is that the call to subsequent handlers is done with `snippetEl` that is not an element of the DOM anymore. This commit fixes this by updating `snippetEl` if needed after each call to a `on_snippet_dropped_handlers` handler. task-5785233 Forward-Port-Of: odoo/odoo#245594 Forward-Port-Of: odoo/odoo#243766
This update resolves an issue where negative lines on invoices generated for Ecuador (l10n_ec) were not correctly formatted in the XML export. The change aligns the process with Mexico (l10n_mx) to accurately distribute discounts and avoid rounding discrepancies, ensuring accurate tax calculations and invoice generation.
Original PR description
In **l10n_ec**, negative lines are not accepted in the XML. They must be dispatched as discounts on positive lines. The dispatching logic implemented in `60e1b41734f76a2d9268edc41286462a9d01a501` can…
In **l10n_ec**, negative lines are not accepted in the XML. They must be dispatched as discounts on positive lines. The dispatching logic implemented in `60e1b41734f76a2d9268edc41286462a9d01a501` can cause rounding issues when the decimal accuracy for `price_unit` is increased. ## Steps to reproduce With **l10n_ec**: 1. Change the decimal accuracy to 6 digits. 2. Set the rounding method to *global rounding*. 3. Create an invoice with the following lines: | Quantity | Price | Taxes | |-----------|----------|-----------| | 20 | 1.4235 | VAT 0% G | | 20 | 1.6425 | VAT 0% G | | 20 | 1.2337 | VAT 0% G | | 20 | 1.2337 | VAT 0% G | | 20 | 1.4235 | VAT 0% G | | 6 | 3.747768 | VAT 15% G | | 6 | 3.747768 | VAT 15% G | In the generated XML, some product lines show a `descuento` of `0.01` or `-0.01`. This happens due to rounding differences in how the `descuento` is computed in the `common_details_info_template` from **l10n_ec_edi**: format_num_2(line_edi_values['price_discount'] + abs(line.balance) - line_items[1]['base_amount']) where `line.balance` and `line_items[1]['base_amount']` can differ by 0.01 due to global rounding applied during tax aggregation, and that difference must be redistributed somewhere. This commit changes how negative lines are dispatched onto positive ones, aligning the behavior with **l10n_mx**. Instead of using `tax_details_per_record` to build the XML, we now use `base_lines`, where the negative lines have already been distributed. opw-5128612 Forward-Port-Of: odoo/enterprise#104659 Forward-Port-Of: odoo/enterprise#97337
A bug was preventing manufacturing administrators from completing work orders. This update adds sudo access to the failing process, ensuring these users can correctly finalize production tasks. This resolves a workflow issue and improves the usability of the manufacturing module for key personnel.
Original PR description
Steps to reproduce:
Create a user with admin access rights for Manufacturing and Quality only. Then, create a work center that has a cost per hour.
Create a product that has a BoM and create a MO then confirm it.
Add a work order that takes place in the created work center and has duration of 60 mins.
Using the created user, try to "Produce All".
Issue:
The user gets an access error when trying to "Produce All", eventhough they have manufacturing access rights.
Fix:
Add sudo access where the process fails to ensure that the workflow is as expected.
Note: a test will be added in anoher PR
opw-5480608
Forward-Port-Of: odoo/enterprise#104897This update fixes an issue where pricelist rules weren't correctly applied to product variants. Previously, rules only worked when editing in 'expanded' mode and would reset the display name. Now, when a variant is selected, the pricelist rule is properly applied, ensuring accurate pricing in sales quotations. This improves the reliability of pricing calculations.
Original PR description
Description of the issue/feature this PR addresses: - A pricelist rule never apply to a product variant, always its template when edited in "expanded" mode - This is because the `applied_on` field is…
Description of the issue/feature this PR addresses: - A pricelist rule never apply to a product variant, always its template when edited in "expanded" mode - This is because the `applied_on` field is missing on the `product.pricelist.item` form view. Current behavior before PR: - Install `sale_management` - Enable "Pricelist" setting - Go to Sales - Products - Pricelists and create a new "Sample" Pricelist. - Create 3 rules for the same product (template), one with price at 6666, a second one at 6667 and the last one at 3333 <img width="1416" height="649" alt="image" src="https://github.com/user-attachments/assets/1d50499e-cb49-4341-971c-5a2a5111b9ca" /> - Next step, edit 2 first rules for price 6666 and 6667 to set a variant **BUT before starting editing, open the form in expanded mode using two-arrows button** <img width="1416" height="889" alt="image" src="https://github.com/user-attachments/assets/056cb862-3dc6-4868-b6d3-a0917f3e7242" /> - Set the variant to the first price rule (as you can see, the rule name is immediately updated with "Variant: [REF] Product name" <img width="1421" height="428" alt="image" src="https://github.com/user-attachments/assets/168ad5fb-902b-494f-888a-419983324607" /> - Save the price rule (_note that the display name incorrectly resets to default_) <img width="634" height="370" alt="image" src="https://github.com/user-attachments/assets/ec915985-b1a3-4a69-9153-7384abdb190d" /> - Same thing for second rule <img width="695" height="375" alt="image" src="https://github.com/user-attachments/assets/69b9ae62-493c-4f0e-ae87-438975e1bceb" /> <img width="621" height="369" alt="image" src="https://github.com/user-attachments/assets/e1dc0342-7b87-42df-bf7d-6a3aace61253" /> - Create a new sale quotation with pricelist set to our "Sample" - Add product [6666] <img width="1207" height="420" alt="image" src="https://github.com/user-attachments/assets/07d4fb94-03b3-45ae-aeb4-feca4fee9c2c" /> - Add product [6667] <img width="1209" height="431" alt="image" src="https://github.com/user-attachments/assets/03e3a76a-2bb1-44e9-a819-ce3ca35703c7" /> - Incorrect prices in sale order <img width="1415" height="828" alt="image" src="https://github.com/user-attachments/assets/3626028d-31d0-4687-b09d-094c0212042a" /> Desired behavior after PR is merged: - Each variant must have its own price. - The added test simply edit the pricelist item using its own form. - The `applied_on` field is added to the pricelist item form to ensure that its value is saved. - If we edit the rule without expanded mode, it works fine only because the `applied_on` field exists in the list view as an invisible column. _Note 1_: `applied_on` is updated by `_onchange_rule_content` using `update` instead of `write` (for caching ?). But if the `applied_on` field is not on the form, then its value is never sent to low level `_write_multi`. _Note 2_: to clear the field value with the Form test component, we must set `=self.env["product.product"]` instead of `=False` .... --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245603 Forward-Port-Of: odoo/odoo#245444
This update resolves a technical issue causing performance problems in the Mail app. Previously, field updates across tabs were creating a loop, leading to slow performance and potential system freezes. This fix prevents unnecessary updates to local storage, ensuring smoother and more reliable field synchronization.
Original PR description
Diccuss fields have a `localStorage` option. The field updates via the `onUpdate` function in the current tab and writes to the local storage. Other tabs use the `storage` event to update their field. This pattern can cause race conditions, leading to loops, high CPU usage, and freezes. When a tab receives a storage event, it may write back an outdated value, triggering further writes and conflicts across tabs. This commit ensures we don't trigger `storage` events recursively: upon the reception of a `storage` event, field is updated but local storage is untouched. 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
This update corrects a critical issue where newly added modules to the Odoo Enterprise stable release were not properly included in the translation files (.weblate.json). This meant that the Greek language version of the software was unavailable. The fix adds the necessary module definitions to the .weblate.json file, guaranteeing proper translation support.
Original PR description
Modules added into stable without being properly added to .weblate.json file = never translatable. Forward-Port-Of: odoo/enterprise#105413 Forward-Port-Of: odoo/enterprise#104890
This update fixes a bug where customers exceeding their credit limits in the Point of Sale (PoS) system weren't receiving warnings. The fix ensures that the system accurately calculates order totals and displays appropriate alerts when a customer's spending exceeds their established credit limit, improving financial control.
Original PR description
Steps to reproduce: ------------------- 1. Install pos_settle_due and accountant 2. In Accounting settings, enable "Sales Credit Limit" 3. Create a new customer, enable its "Partner Limit" and set it…
Steps to reproduce: ------------------- 1. Install pos_settle_due and accountant 2. In Accounting settings, enable "Sales Credit Limit" 3. Create a new customer, enable its "Partner Limit" and set it to 100 4. Open PoS, select that partner, and select products such that the total exceeds 100 Notice that even though we have exceeded that partner's limit of 100, there are no indicators on the customer button (orange background on hover), nor there are warnings on the partners list modal nor on the payment page. Why the bug ----------- In `getPartnerCredit`, we are using `order.amount_total` to get the current ordre amount, however, this field is `undefined` for a new order and it's been assigned a value in `setOrderPrices`, which since [9538698](https://github.com/odoo/odoo/commit/9538698), is only called before sending the order to the backend. The fix ------- Now we read the total amount from the getter `order.priceIncl`, and round it as we would do in `setOrderPrices`. opw-5489975 Forward-Port-Of: odoo/enterprise#104591
This update enhances the monitoring of our AI usage by changing key logs from 'debug' to 'info', making them easier for our team and database administrators to track. Additionally, the system now accurately reports token usage from the LLM providers, resolving an issue where previous estimates were significantly inaccurate.
Original PR description
In this commit we change some important llm api usage logs from debug to info so they can be more easily monitored by us and database admins. We also change the usage reporting from a naive estimation (which greatly under-reported the token usage) to the actual token usage given to us by the LLM prodivers in the response. Forward-Port-Of: odoo/enterprise#105364
This update resolves an issue preventing electronic invoices in Latin American countries (Argentina, etc.) from printing correctly. The fix ensures that invoice headers and footers are dynamically generated based on the customer's fiscal country code, rather than relying on outdated chart templates. This guarantees accurate invoice formatting for all users.
Original PR description
This commit fixes a bug introduced here https://github.com/odoo/odoo/commit/3f7d79731fd5e5a751f7f1aeae63379c6211de5c because some old databases do not have set the chart template so it is needed to render the header and footer of the report template layouts taking in consideration the account fiscal country code instead of the chart template. Replicate printing the pdf of a customer electronic invoice on an argentinen company without chart template. Ticket Adhoc side: 105739 Task latam: 1373 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244102 Forward-Port-Of: odoo/odoo#238033