Daily updates from Odoo
Tuesday, August 12, 2025
28 changes · saas-18.3
Resolved issues and error corrections
This fixes an issue that could prevent users from opening Spain's Modelo 111 report after a reporting engine change. The update removes an incompatible grouping setting so the report loads normally and avoids unexpected errors.
Original PR description
Commit https://github.com/odoo/odoo/commit/97fe24cea74241a7820841a470994d3ebf9d8d38 changed the engine for some report line of Modelo 111. The new engine used, `external`, is not compatible with…
Commit https://github.com/odoo/odoo/commit/97fe24cea74241a7820841a470994d3ebf9d8d38 changed the engine for some report line of Modelo 111. The new engine used, `external`, is not compatible with having a grouping value defined by the user (field `user_groupby`). Except that value does not get removed from the report lines. As a result, a traceback pops up whenever we try to access the report. Two previous commits aimed to sync that field with the `groupby` field (https://github.com/odoo/odoo/commit/a7d54c76aaee325449248fa698adb9e549c486ee), and update it if it was not compatible with the engine (https://github.com/odoo/odoo/commit/0d5bf820c3737ee3e4af54d1fb556b72d6c59c3d) but both only work with `aggregation` engine. This commit makes `_validate_engine()` account for `external` engine, as it was only checking for `aggregation` engine when validating `groupby` related fields. opw-4972212 opw-4971497 opw-4931269 opw-4949654 Forward-Port-Of: odoo/odoo#221407 Forward-Port-Of: odoo/odoo#221021
Purchase orders now choose the supplier price list entry that matches the applicable minimum quantity when the same vendor has multiple entries. This prevents small purchases from incorrectly using bulk pricing, improving pricing accuracy and avoiding undercharged purchase orders.
Original PR description
Steps to reproduce the bug: - Create a storable product “P1” - Under the Purchase tab: - add two vendor pricelist entries: 1:/ - Vendor: Azure Interior - min_qty: 1 - Price: $5 2:/ - Vendor: Azure…
Steps to reproduce the bug:
- Create a storable product “P1”
- Under the Purchase tab:
- add two vendor pricelist entries:
1:/
- Vendor: Azure Interior
- min_qty: 1
- Price: $5
2:/
- Vendor: Azure Interior
- min_qty: 100
- Price: $2
- Create a purchase order:
- vendor: Azure Interior
- Try to add the product P1
**Problem:**
When adding a product to a purchase order, if multiple supplier info
lines exist for the same vendor, the one with the lowest price will be
selected, instead of the one matching the smallest applicable quantity
(min_qty).
This regression was introduced by the following commit, which
tried to fix an unrelated bug with supplier info date matching:
https://github.com/odoo/odoo/commit/7eabfcff402993f32f5c835e18e07c91782a7b33#diff-5684edced9bdfc98021a85de4c6cdf691ea7add74e56ab50334a1d7db9ef4224L470
As part of that fix, the logic was changed to use the _select_seller
method, which by default sorts supplier info lines by price_discounted
and returns the first one — regardless of whether the min_qty is met.
Previously, the logic correctly selected the supplier line based
on min_qty when multiple lines existed for the same vendor.
**_Note:_** This bug is no longer present as of version 18.1, because
the date-related issue was fixed differently in the following commit:
https://github.com/odoo/odoo/commit/19c65c4884a3746b44b6272694662eb32a6bf32f
That later fix preserved the original behavior of respecting min_qty.
**Solution:**
Explicitly pass ordered_by='min_qty' when calling _select_seller.
This ensures that supplier info lines are prioritized based on the
lowest applicable min_qty, not the lowest price, when the vendor is the
same.
opw-4942819
Forward-Port-Of: odoo/odoo#221902
Forward-Port-Of: odoo/odoo#221764This fixes an issue where portal users could receive incorrect read access information for document messages, especially when opening documents through shared links. The change ensures the interface receives accurate access details, helping avoid misleading options or behavior in the chatter area.
Original PR description
Before this commit, the `_thread_to_store` method would always set the `hasReadAccess` property to true. This was fine because the only flow that would add the values to the store would already check the existance and access to the thread. However after change [1] the access values would be sent in more flows, one of which being portal chatter initialization. This causes the client to have incorrect access information to the thread (i.e. hasReadAccess would be true even when accessing portal document through token). This commit fixes the issue by sending the correct access values. [1] https://github.com/odoo/odoo/pull/220774 Forward-Port-Of: odoo/odoo#222545 Forward-Port-Of: odoo/odoo#222281
Incoming return slips now show the actual destination address instead of placeholder demo text. This helps warehouse and operations teams avoid confusion when printing return documents for received products.
Original PR description
Issue ----- Incoming return slips have a "Demo Address and Name" text instead of the correct destination address. <img width="928" height="658" alt="image"…
Issue ----- Incoming return slips have a "Demo Address and Name" text instead of the correct destination address. <img width="928" height="658" alt="image" src="https://github.com/user-attachments/assets/6ff0a5e7-f1ee-4faa-a22b-76ec8f2f7a28" /> Steps to reproduce ----- - Create a receipt for a product - Print its return slip Cause ----- By default, the address is taken from the pickings location_id -> warehouse_id -> partner_id. For incoming pickings, the warehouse is the vendor one, with no associated partner. In such cases, the partner can be found directly on the picking itself with the partner_id field. Note ----- To render t-fields, qweb first applies a `rsplit` before evaluating the expression, see https://github.com/odoo/odoo/blob/cb1c761777e84d96f82c4f754586795509ce1b3d/odoo/addons/base/models/ir_qweb.py#L2015-L2016 With this in mind, using parentheses and moving `.partner_id` outside of them seems like the most readable way to go about it. ----- Ticket: opw-4660716 Forward-Port-Of: odoo/odoo#221807 Forward-Port-Of: odoo/odoo#219011
The invoice sending process now ignores invoices that are no longer ready to be sent and clears outdated sending information when invoices are moved back to draft. This prevents background sending jobs from failing when users change an invoice status after selecting it for sending.
Original PR description
This commit makes the asynchronous invoice sending process more robust. Previously, the `_cron_account_move_send` method would fail if it encountered an invoice that was not in a 'posted' state. This could happen if a user changed the state of an invoice back to 'draft' or 'canceled' after it was selected for sending but before the cron job ran. To fix this, we added an extra condition to the search domain, so that only posted invoices are accounted for. We also added an explicit reset of `sending_data` in the draft button method, so that setting a posted invoiced back to draft does not retain (outdated) sending data. Steps to reproduce: 1. Select posted invoices and send. 2. Before cron runs, set one invoice to 'draft'. 3. Manually run the cron job `_cron_account_move_send`. 4. Observe the traceback. OPW-4985528 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222278
Fixes an issue where point of sale orders from a closed session could fail to invoice when cash rounding was involved. This helps businesses complete invoicing reliably for mixed-payment POS orders after session closure.
Original PR description
Currently it's not always possible to invoice an order from another sessio nthat is already closed when there is cash rounding. Steps to reproduce: ------------------- * Enable cash rounding for cash methods only, 5cents half-up * Open pos session * Add a produc with price 174.99 to order * Add a customer * Go to pay * Select pm cash and enter 100 * Select pm bank and enter 75 * Change 0.01 * Validate * Close session * Open session * Try invoicing the precedent order > Observation: Not possible to invoice, move is not balanced Back porting as it is exaclty the same issue: https://github.com/odoo/odoo/commit/626c3fd1bff85cc6cb222bdba80c14dd761dafd3 opw-[4829919](https://www.odoo.com/web#id=4829919&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#222543 Forward-Port-Of: odoo/odoo#220096
The mobile shop toolbar now stays visible above the live chat bubble, preventing overlap when no pricelist is configured. This makes the mobile shopping experience clearer and avoids customers missing key purchase controls.
Original PR description
In odoo/odoo@860dccec53cb0940212fe7d9161c7e3c805867f7 the floating toolbar layout was introduced, but there was an issue with the livechat bubble which was overlapping the floating bar on mobile when there was no priceslit (error with the calc()). This PR fixes this issue by displaying the floatingbar above the livechat bubble, taking the same style when there is a pricelist or not. task-4966406 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Marketing card previews and test mailings now behave more like real campaigns without skewing engagement results. Preview clicks are no longer counted, default mailing content uses the right preview card and user language, and obsolete campaigns are cleaned up when their linked model is removed.
Original PR description
- Avoid counting "clicks" on archived (implicitly preview) cards - Pick the preview card when building the default mailing body - Translate the default mailing body - If a card targets a model that has been uninstalled, remove the campaign as is done for mailings task-4247003 Forward-Port-Of: odoo/odoo#222383 Forward-Port-Of: odoo/odoo#214315
Point of Sale product configuration now lets cashiers change attribute choices even when the current combination is invalid. The Add button is disabled until a valid combination is selected, preventing blocked sales flows for products with exclusion rules.
Original PR description
If you setup the attribute exclusion on a product template with 2 attribute, so that only 2 valid combinations are possible, you would not be able to select the second attribute value in the product configurator popup. Steps to reproduce: ------------------- * Create 2 attributes with 2 values each A1V1 A1V2 and A2V1 A2V2 * Create a product template with these attributes and set the attribute exclusion so that only 2 valid combinations are possible. * Open PoS and try to add the product to the cart. * The configurator popup will appear. > Observation: You will not be able to change the selection because the other combinations are not correct. Why the fix: ------------ Instead of blocking the selection of wrong combinations, we disable the add button when the current selection is not valid. This allows the user to change the selection of the attributes without being blocked by the exclusion rules. opw-4825451 Forward-Port-Of: odoo/odoo#219688
Quotation PDFs now correctly show zero values from custom integer or decimal fields instead of leaving those fields blank. This ensures generated sales quotes accurately reflect entered data and avoids confusion for customers and sales teams.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Using Studio, add an integer or float field to the sale order form; 2. upload a PDF using forms as a quotation header[^1]; 3. add a mapping of the form field to the studio field; 4. create a quoation using the header; 5. have the studio field be 0; 6. print quotation. [^1]: e.g. `tests/files/test_forms.pdf` Issue ----- The form field where the zero should be displayed is empty. Cause ----- When formatting values, it returns an empty string for any falsy value whose field isn't of type boolean or monetary. Solution -------- If the value is falsy, only return the empty string if the field type is not integer or float, this way, the zero value will get formatted in the final `else` as a string value (same as non-zero numeric values). opw-4937052 Forward-Port-Of: odoo/odoo#222487
Employees on flexible working schedules will no longer have public holidays deducted from their leave balance when requesting leave on those days. This keeps leave balances accurate and avoids charging employees for company holidays.
Original PR description
**Steps to reproduce:** 1) Create a flexible working schedule. 2) Assign this schedule to an employee. 3) Create a public holiday. 4) Create a leave request for the flexible employee on the public…
**Steps to reproduce:** 1) Create a flexible working schedule. 2) Assign this schedule to an employee. 3) Create a public holiday. 4) Create a leave request for the flexible employee on the public holiday. 5) Notice that the duration of the leave is 1 instead of 0. **Issue:** Due to recent changes in the [commit](https://github.com/odoo/odoo/commit/a826f65c2d95b796f919023d560ec9f0801090d8#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R427-R433) , When a single-day flexible leave is taken, the duration is always set to the real duration. However, we do not check if the leave falls on a public holiday, which results in the leave being set to 1 day, even on holidays. https://github.com/odoo/odoo/blob/8f24da78f60529ea0b1840e48de30e15d17ddb77/addons/hr_holidays/models/hr_leave.py#L427-L433 **For example:** If Christmas is marked as a public holiday and an employee with a flexible schedule requests a one-day leave on Christmas, the leave is recorded with a duration of 1 day. **Fix:** Check for a public holiday on leave date; if yes, set leave duration to 0. opw-4963122 Forward-Port-Of: odoo/odoo#220288
Purchase orders created from sales orders now keep the assigned project for make-to-order, buy, and drop-shipping flows. This helps teams maintain accurate project tracking and reporting without requiring extra apps or manual corrections.
Original PR description
This commit fixes two issues related to project propagation from Sale Order to Purchase Order: **1. Project not propagated when using MTO+Buy route** **Steps to reproduce:** - Install only…
This commit fixes two issues related to project propagation from Sale Order to Purchase Order: **1. Project not propagated when using MTO+Buy route** **Steps to reproduce:** - Install only `sale_project_stock` and `purchase` - Enable multi-step routes and unarchive the "MTO" route - Create a storable product "P1" with: - Routes: MTO + Buy - Vendor: any - Create a Sale Order with: - 1 unit of P1 - Any project set in "Other Info" - Confirm the SO **Issue:** A Purchase Order is created but the project is not propagated to it. This propagation was previously ensured by `project_mrp_sale`, via: https://github.com/odoo/odoo/blob/238a41e35280256382f6509182b9e900fb4f7aba/addons/project_mrp_sale/models/stock_move.py#L9 --- **2. Project not propagated when using drop-shipping** **Steps to reproduce:** - Enable drop-shipping - Create a product "P2" with: - Route: Drop-Ship - Create a Sale Order with: - 1 unit of P2 - Any project set - Confirm the SO **Issue:** A Purchase Order is created, but the project is again missing. --- **Fix:** - Move the `_prepare_procurement_values` override from `project_mrp_sale` to `sale_project_stock` to ensure project propagation regardless of the presence of `project_mrp_sale` - Also adapt `sale_project` to ensure project is retrieved from the Sale Order if not set on the Sale Order Line. opw-4976606 Forward-Port-Of: odoo/odoo#222179
Preparation receipts in Point of Sale now use larger, easier-to-read order details and line items. They also include scheduled preparation time when timing presets are used, helping staff prepare orders at the right moment.
Original PR description
- Increase the size of the `order_reference`, `tracking_number`, order lines and title element on the order changes preparation receipts. - Also ensure that the preparation receipt contains the `preset_time` information when a preset with `use_timing` is used for the order. task-id: 4936935 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Paid time-off timesheets now use the employee’s actual working schedule when it differs from the company default. This prevents underreported hours for French payroll and leave tracking while keeping the required French leave day-count rules.
Original PR description
With the French fiscal localization: When an employee has a different working schedule than the company’s default one. If the employee’s daily working hours are greater than the company’s default…
With the French fiscal localization: When an employee has a different working schedule than the company’s default one. If the employee’s daily working hours are greater than the company’s default hours. The timesheet for paid time off only displays the company’s default hours instead of the employee’s actual hours. Steps to reproduce: ------------------- * Install l10n_fr_hr_holidays * Set the French fiscal localization * Working schedule of the company -> 7:30 per day * Working schedule of the employee -> 8 per day * Create a paid time-off with this employee * Check the Timesheet of this employee > Observation: Timesheet shows 7:30 instead of 8 Why the fix: ------------ We needed to ensure the hours are always calculated correctly (using the employee’s or company’s calendar when appropriate) while still forcing the correct day count (1 or 0.5) and extending it according to French law. ✅ Day count is forced (0.5 or 1) depending on the leave type. ✅ Hours are fetched from `super()._get_durations()` so the timesheet keeps accurate hours. This prevents timesheets from showing incorrect hours when the employee's work schedule differs from the company's work schedule. opw-4744516 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220511
Steps to reproduce: 1. Install 'l10n_it' and 'accounting' from apps. 2. Enable debug mode. 3. Activate the Italian language and set it for the current user. 4. Go to Accounting > Customers / Vendors > Invoice / Bill > Electronic Invoicing tab Observation: When the Italian language is active, the 'Electronic Invoicing' tab and the fields within it are not translated. Issue: Missing translations in the PO file. Solution: Added the missing translations for the fields in the PO file.
Original PR description
Steps to reproduce: 1. Install 'l10n_it' and 'accounting' from apps. 2. Enable debug mode. 3. Activate the Italian language and set it for the current user. 4. Go to Accounting > Customers / Vendors > Invoice / Bill > Electronic Invoicing tab Observation: When the Italian language is active, the 'Electronic Invoicing' tab and the fields within it are not translated. Issue: Missing translations in the PO file. Solution: Added the missing translations for the fields in the PO file. opw-4937464
This fix ensures calendar records use valid default references when opening or creating related items. It prevents edge cases where an invalid zero identifier could cause incorrect behavior in calendar workflows.
Original PR description
Use valid res_model/res_id in context defaults runbot-235289 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222426
The help text for choosing a project documents folder has been corrected to match current behavior. This avoids telling users that task documents are automatically moved into that folder, reducing confusion for teams organizing documents manually.
Original PR description
Before this commit, the tooltip displayed for `documents_folder_id` defined in `project.project` model, said all documents linked to a task of a project will be automatically added inside that folder but it is no longer the case since the refactoring of Documents to simplify the implementation but also let the documents user sorts his documents as he wants since now the access rights are defined by folder. This commit updates the tooltip accordingly. PR simplifying the bridge between documents and project apps: #75214 opw-5000224 Forward-Port-Of: odoo/enterprise#92164
This update adjusts accounting report tests so they align with stricter validation rules for external report calculations. It helps prevent false test failures for complex tax reports, such as Luxembourg tax annexes, without changing day-to-day user workflows.
Original PR description
The corresponding community PR (https://github.com/odoo/odoo/pull/221407) contains a fix that requires the _validate_engine constraint to reject any groupby value for the 'external' engine. Therefore, it is now needed that the test ensuring non-stored related fields can be used in groupby is adapted in order to also exclude those expressions when changing the groupby value of the lines using a custom engine on any of their expressions. Without that, complex reports like the annexes of the Luxembourgese tax report fail the test. Forward-Port-Of: odoo/enterprise#92096
The Swedish SIE4 import now handles files that do not include previous-year information without crashing. This lets accounting users import opening balances more reliably, including files that require an alternate text encoding.
Original PR description
**Issue**: Importing a SIE4 file without previous year information causes a traceback. **Steps to reproduce**: - Go to Accounting > Settings > Import - Import SIE 4 file - Check the box "Import account opening balances" - Select the right xml and observe the traceback **Cause**: The method `_prepare_sie4_opening_balance_move` tries to directly access the previous year: https://github.com/odoo-dev/enterprise/blob/6d4919658650a006c73d4aaf1f500d67723dda0d/l10n_se_sie4_import/wizard/import_wizard.py#L376C9-L376C58 This results in a traceback when the previous year is not present. **Solution**: Make `_prepare_sie4_opening_balance_move` more permissive by falling back to the day before the first day of the current year if the `-1` section is not there. **Additional Notes**: The client file does not support `UTF8` format, retry with the `ISO-8859-1` format in case of `UnicodeDecodeError`. opw-4894495 Forward-Port-Of: odoo/enterprise#89425
Swiss payroll declarations now show which employee information is missing before users send or print them. This makes it easier for non-specialist users to correct incomplete data and avoid declaration errors or delays.
Original PR description
It is currently complicated for non trained users to figure out what is missing before sending or printing a declaration. In this PR we extend the warning mechanism to declarations to visualize what information is missing on what employees. Forward-Port-Of: odoo/enterprise#92083 Forward-Port-Of: odoo/enterprise#86195
Field service teams can once again open outgoing stock transfers in a map view. This restores an Enterprise-only view option that was temporarily unavailable after a related community fix.
Original PR description
This commit is the continuity of the fix made in community. The issue fixed in community was the map view cannot be defined in the view mode of an action since the map view only exists in enterprise. This commit overrides the method defined in community to add the map view as before. Related PR: odoo/odoo#222003 Forward-Port-Of: odoo/enterprise#92032
The US payroll leave type setup screen now includes the missing view update, so the intended fields appear for users. A label was also corrected, reducing confusion when configuring leave types.
Original PR description
Before this commit, the modification of the leave type views was not introduced in the manifest, resulting in the fields being absent from the view. This commit corrects the label as well as introduces that view in the manifest Forward-Port-Of: odoo/enterprise#87423
This fix prevents one employee's clock-in from being ended when another employee clocks in from a different point-of-sale device. It helps stores with multiple terminals track staff attendance accurately and avoid accidental clock-outs during device synchronization.
Original PR description
- Fixes an issue where clocking in a second employee on a different device would automatically clock out the first one. This was due to `self` being unset during POS session leading to incorrect loading of `users_clocked_ids` and `employees_clocked_ids`. - The issue was appearing when `pos_session._post_read_pos_data` is triggered from `pos_config.notify_synchronisation`. task-id: 4902090 Forward-Port-Of: odoo/enterprise#89273
This fix ensures stock barcode tests include an email address for the user involved in quantity update notifications. It helps confirm that notifications can be sent correctly when initial demand on stock moves changes, avoiding failures caused by missing user email data.
Original PR description
Updating the initial demand of a stock move notify the users. Without email address, the notification cannot be send. As the email address of the admin user is only fill in the demo data, this commit adds one specially for the test. runbot: 226778 Forward-Port-Of: odoo/enterprise#89722
The Spanish VAT book export now recognizes the 0.26% and 1% equivalence surcharge purchase taxes. This prevents an error when exporting VAT Record Books for invoices using these tax rates, allowing affected Spanish accounting users to generate reports normally.
Original PR description
Added to SURCHARGE_TAX_EQUIVALENT taxes 0.26% SE and 1% SE When using the Odoo VAT book (location Spain) and we have an invoice with the taxes 0.26% SE (0,26% Recargo Equivalencia Compras) 1% SE (1%…
Added to SURCHARGE_TAX_EQUIVALENT taxes 0.26% SE and 1% SE When using the Odoo VAT book (location Spain) and we have an invoice with the taxes 0.26% SE (0,26% Recargo Equivalencia Compras) 1% SE (1% Recargo Equivalencia Compras). a KeyError error occurs <img width="1147" height="517" alt="Captura desde 2025-07-30 09-37-13" src="https://github.com/user-attachments/assets/771fcf6e-efed-4e79-a1d4-a133c7072c2a" /> Steps to Reproduce this error: 1. Create a new database using Odoo version 18. 2. Activate the module: “Spain - Accounting (PGCE 2008)” (l10n_es). 3. Create a new company and set Spain as the country. 4. In the company’s “Sales & Purchase” tab, set the Fiscal Position to "Equivalence surcharge". 5. Create a new quotation and select the company created in step 3. 6. Add a product with the following taxes: 0.26% and 2% VAT (G). 7. Add another product with the following taxes: 1% (SE) and 7.5% VAT (G). 8. Confirm the invoice generated from the quotation. 9. Go to Accounting → Reporting → Tax Report and select "Generic Tax Report". 10. Click the gear icon and select "VAT Record Books (XLSX)". OPW https://www.odoo.com/es_ES/my/tasks/4981807 @jco-odoo please review. Thank you! MT-10457 @moduon Forward-Port-Of: odoo/enterprise#92116
This change fixes an intermittent failure in an automated barcode inventory test by making the test wait for the destination location update to appear before continuing. It improves release stability and reduces false failures in quality checks without changing business functionality.
Original PR description
A non-deterministic error has been occurring across all versions starting from 18.0 when running the `test_split_line_on_destination_scan`. problem: The issue lies in one of the steps of the tour,…
A non-deterministic error has been occurring across all versions starting from 18.0 when running the
`test_split_line_on_destination_scan`.
problem:
The issue lies in one of the steps of the tour, where the destination location of the remaining quantity is changed from WH/Stock to shelf1 (LOC-01-01-00). Right after this change, the test proceeds to assertLineDestinationLocation. However, the test step was previously waiting for the presence of the .o_validate_page.btn-primary element — an element that is already visible before the destination location update is actually applied. As a result, the tour sometimes skips to the next step prematurely, without ensuring the location change has occurred, leading to test failure.
Fix:
We replaced the trigger .o_validate_page.btn-primary with a more reliable condition: waiting for an element containing the destination text .../Section 1 (.o_line_destination_location:contains(".../Section 1")). This ensures that the step only proceeds once the destination update has been reflected in the UI.
Runbot-145458
Forward-Port-Of: odoo/enterprise#92006
Forward-Port-Of: odoo/enterprise#91927This fix restores required refund information on Italian POS fiscal receipts and invoices. It prevents Italian fiscal printers from blocking when processing refunds, helping stores complete refund transactions reliably.
Original PR description
The refund are bugged after PR #89419 . That PR removed the header but in the header are passed the refund information needed by italian fiscal printer to print the refund. Without this PR the fiscal printer is blocking. The printRecMessage on the receipt is required before the beginfiscalreceipt Forward-Port-Of: odoo/enterprise#91042 Forward-Port-Of: odoo/enterprise#91007
Automatic currency rate updates from the UAE Central Bank now include the Sudanese Pound. This ensures businesses using SDG can receive updated exchange rates without manual corrections.
Original PR description
**Steps to reproduce**: 1. Install the `account` and `l10n_ae` modules. 2. Go to `Invoicing → Configuration → Currencies` and activate the `Sudanese Pound (SDG)` currency. 3. Navigate to `Settings → Invoicing → Currencies → Automatic Currency Rates`. 4. Select `[AE] Central Bank of the UAE` as the currency provider and manually fetch rates. <img width="463" height="181" alt="image" src="https://github.com/user-attachments/assets/31257e2e-8360-4cdb-877e-2ea41487ddea" /> 5. Return to the Currencies list. **Observed behavior**: - The rate for the `Sudanese Pound (SDG)` is not updated. **Root cause**: - The `SDG` currency is missing from the `MAP_CURRENCIES` dictionary, so the provider doesn't fetch its rate. **Solution**: - Add the missing `SDG` currency mapping to `MAP_CURRENCIES`. opw-4869204 Forward-Port-Of: odoo/enterprise#91790