Saturday, September 19, 2026
4 changes · 19.0
Enhancements to existing features
Existing French partners with missing or incorrect electronic invoicing routing details are now checked against the official directory data available through the service. When matching records are found, Odoo chooses the most appropriate identifier automatically, improving readiness for French e-invoicing and reducing manual cleanup.
Original PR description
for existing french partners that dont have their EAS set to the FRCTC, a check will be made to see if they are on the annuaire using the IAP annuaire lines, if one line exists, the identifier is set to that, if more than one line exists, we set the identifier to one of the lines in this priority: siren_siret -> siren -> shortest identifier (most general) task-id-6327357 Forward-Port-Of: odoo/odoo#289188
Resolved issues and error corrections
Credit notes for invoices already accepted in Poland's KSeF system now report the original KSeF invoice number correctly instead of marking the invoice as issued outside KSeF. This helps businesses generate compliant e-invoice XML files and avoid incorrect Polish tax reporting.
Original PR description
### Issue before this commit: When generating a credit note for an invoice already accepted in the Polish KSeF system, the exported XML incorrectly includes the <NrKSeFN>1</NrKSeFN> tag. This tag…
### Issue before this commit: When generating a credit note for an invoice already accepted in the Polish KSeF system, the exported XML incorrectly includes the <NrKSeFN>1</NrKSeFN> tag. This tag falsely indicates that the original invoice was issued outside of KSeF, and the official KSeF number of the corrected invoice is entirely omitted from the file. ### Steps to reproduce the issue: 1. Download Accounting and l10n_pl 2. Go to Settings > Polish Localization > Insert certificate 3. Go to Invoices > Create an invoice > Send it to KSeF 4. Create a credit note for that invoice, reverse it and send it to KSeF 5. Tag <NrKSeFN>1</NrKSeFN> should not be there ### Cause of the issue: The tag <NrKSeFN>1</NrKSeFN> is emitted in every case without any rule handling it. ### Reason to introduce the fix: To comply with the official FA(3) logical structure rules. According to the specifications, if the corrected invoice was issued and accepted in KSeF, the XML must include the <NrKSeF>1</NrKSeF> flag and additionally provide the original KSeF number in the <NrKSeFFaKorygowanej> field. Otherwise, if the original invoice was issued outside of KSeF, the system must enter "1" in the <NrKSeFN> field and strictly omit the <NrKSeF> and <NrKSeFFaKorygowanej> fields. <img width="866" height="981" alt="image" src="https://github.com/user-attachments/assets/53b42f9f-aaab-4642-be38-2a5abc1d8539" /> opw-6541941 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#288286
The attendance kiosk now shows the weekday in the same language as the rest of the interface. This avoids confusion for employees using Odoo in non-English languages and makes the kiosk experience more consistent.
Original PR description
Problem:
The weekday displayed in the attendance kiosk header is always shown in English, even when the comapany contact's language is changed.
This happens because `DateTime.toFormat("cccc")` uses Luxon's locale, but the `DateTime` instance is created without setting the current UI locale.
Steps to reproduce:
1. Install `hr_attendance`.
2. Change the company contact language to a language other than English (e.g. French).
3. Open the Kiosk Mode.
4. Observe that the date and UI are translated, but the weekday remains in English (e.g. "Monday" instead of "Lundi").
Fix:
Set the Luxon locale from the document language before formatting the weekday. This ensures `toFormat("cccc")` returns the weekday in the active Company contact language.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#274655This update makes checkbox and radio button borders darker so users can more easily see unselected options, especially in dense lists or light backgrounds. It also brings related visual feedback improvements for checkbox interactions while preventing those animations from disrupting switch-style controls.
Original PR description
Description of the issue/feature this PR addresses: Unselected and unhovered checkboxes are very faint, even against a white background. Like this: <details> <summary>Screenshots</summary> <img…
Description of the issue/feature this PR addresses: Unselected and unhovered checkboxes are very faint, even against a white background. Like this: <details> <summary>Screenshots</summary> <img width="1106" height="1027" alt="image" src="https://github.com/user-attachments/assets/2feae918-52cc-4d0d-b49f-3666bbd8ba7b" /> <img width="375" height="783" alt="image" src="https://github.com/user-attachments/assets/9a9a44e8-5ada-419a-877f-52f287bca34f" /> </details> Backport Logic: I found that `$o-form-check-input-border-color` had already been introduced in #231860 and had been merged in main and 19.1 onwards. This PR backports those improvements, and then changes `$o-form-check-input-border-color` from `$o-gray-300` to `$o-gray-500` If this change is acceptable, the relevant commit can be forward ported to master. Note: That PR apparently depends on https://github.com/odoo/enterprise/pull/97340 on the enterprise side of things, but as I do not have access there, I have no idea if this was merged in enterprise/19.0 Desired behavior after PR is merged: Checkbox and radio borders are slightly darker and more discernable. <details> <summary>Screenshots</summary> <img width="1104" height="1025" alt="image" src="https://github.com/user-attachments/assets/dee33e29-c852-4419-9edc-8568daf5ce68" /> <img width="401" height="793" alt="image" src="https://github.com/user-attachments/assets/dfc73976-00e6-48a5-8781-fa986ca4232c" /> </details> Coincidentally, the micro-interactions and improvements introduced in the above mentioned bacported PR are also added. My apologies if you consider this change too minimal to justify a PR. This issue has just been bugging me, so I had to open a PR. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr