Daily updates from Odoo
Thursday, June 25, 2026
28 changes
1 change
Enhancements to existing features
This update automatically sends emails to companies when their Stripe connected accounts are flagged for potential restrictions due to KYC compliance. Stripe handles verification, and these emails alert businesses to address any required documentation updates, preventing account limitations. This ensures timely compliance and minimizes disruption to business operations.
Original PR description
When a company tries to create a connected account, some official documentation need to be submitted to Stripe. Stripe takes care of the KYC steps and might restrict some account which don't meet the requirements. Odoo receives the details about the error and the date of the restriction. This task aims at sending automatic emails to the said companies to let them know that they need to fix the identified issues. task: 5441662 Forward-Port-Of: odoo/enterprise#107918
2 changes
Enhancements to existing features
This update makes it easier for French companies to register for PDP and understand when they need it. It replaces confusing Peppol wording with clearer French e-invoicing guidance, adds helpful prompts in the invoicing flow, and simplifies the registration wizard by making the key steps more direct and automatic.
Original PR description
#### [IMP] account_peppol,l10n_fr_pdp: rework PDP registration If PDP is not installed but Peppol is installed we suggest installing the PDP module for French companies - in the send & print instead…
#### [IMP] account_peppol,l10n_fr_pdp: rework PDP registration
If PDP is not installed but Peppol is installed we suggest
installing the PDP module for French companies
- in the send & print instead of the following warnings
- "You can send this invoice electronically via Peppol." (what is peppol)
- "partner has requested electronic invoices reception on Peppol."
- in the send & print for any French company that is not on PDP
(this warning can be disabled by setting the system parameter
`account_peppol.disable_pdp_warning` to true)
- in the peppol registration wizard by adding a warning
If PDP is installed we make the following changes to the send & print
- change the wording mentioning "Peppol" to mention the French e-invoicing instead
- make a PDP version of the "Peppol Info" (`account_peppol.WhatIsPeppol`)
- it explains what French E-Invoicing is
- it provides a button to open the registration wizard
- in case the company is registered on Peppol it deregisters the
company first (just like the "complete registration" button)
- display the "You can send this electronically via Peppol" warning
also for French companies (with the wording and "Peppol Info" mentioned above)
- It is displayed in case we are opening the Send & Print wizard from a French
company for a partner on peppol but the "Peppol" / "French
E-invoicing" checkbox is not checked
- Change the wording of the French company non-PDP warning to encourage
the user to register
In the PDP registration wizard
- make all the fields visible directly (already at the start of the KYB/KYC)
- make the SIREN part of the identifier readonly
- make the fields readonly after the verification
- automatically "validate" / register to PDP when we receive the KYC success
task-6320246
#### [IMP] l10n_fr_pdp: add system param for kyc siren
After the previous commit it is not really possible anymore
to use a different SIREN for the KYC than the one in the pdp identifier.
This is because:
- We derive the SIREN directly from the
Identifier in the registration wizard.
- The registration will be validated automatically after the KYC
- The values are readonly after the KYC in any case
That is a problem for testing because we have 1 SIREN to test the
KYC and it is independent from the identifiers provided by the French
datasets for the PDP test environment.
task-None
Forward-Port-Of: odoo/odoo#271733This update automatically sends emails to companies when their connected Stripe accounts are flagged for potential restrictions due to KYC requirements. Stripe handles compliance checks, and this change ensures Odoo proactively notifies businesses about issues needing immediate attention, preventing disruptions to their services. It addresses a critical process to maintain compliance and minimize potential service interruptions.
Original PR description
When a company tries to create a connected account, some official documentation need to be submitted to Stripe. Stripe takes care of the KYC steps and might restrict some account which don't meet the requirements. Odoo receives the details about the error and the date of the restriction. This task aims at sending automatic emails to the said companies to let them know that they need to fix the identified issues. task: 5441662 Forward-Port-Of: odoo/enterprise#107918
4 changes
Enhancements to existing features
Odoo now sends automatic emails to companies when Stripe flags their connected account as at risk of restriction. This gives businesses early warning so they can correct missing documentation or other issues before payments are affected.
Original PR description
When a company tries to create a connected account, some official documentation need to be submitted to Stripe. Stripe takes care of the KYC steps and might restrict some account which don't meet the requirements. Odoo receives the details about the error and the date of the restriction. This task aims at sending automatic emails to the said companies to let them know that they need to fix the identified issues. task: 5441662 Forward-Port-Of: odoo/enterprise#107918
A new extension number can now be stored for Belgian bank journals, helping Odoo distinguish between bank journals that share the same account number. This improves the accuracy of CODA statement imports when used with Codabox or Codaclean, reducing the risk of statements being matched to the wrong journal.
Original PR description
Original commit message: Bank journal can have the same bank account number, to be able to have a difference between them. We will add an extension number field on the journal that will be displayed…
Original commit message: Bank journal can have the same bank account number, to be able to have a difference between them. We will add an extension number field on the journal that will be displayed only when having a synchronization with codabox or codaclean. This extension number can be found in the CODA file when the second line of the coda start with '12', which means that we have a belgian iban. With that we are able to know the journal to where we want to import the statement. task-5254158 Backport commit message: This commit backports the code to handle extension number in stable. Some adaptations were done to allow this backport. 1. We have a new module for the new field and the view. 2. Except that, the code stays in the existing modules with a condition that check if the extension number is present in the journal's field list. NB: This implementation is pretty bad but the existing code doesn't include hooks to extend to add customization. To avoid a whole refactoring in stable, this approach was chosen. 3. A test and a test file from the codabox module are deleted because we don't want to create a new module for tests only. task-6116452 Forward-Port-Of: odoo/enterprise#113699
This change restores a faster way of processing text cleanup during template compilation, which helps Odoo render some QWeb templates more quickly. It addresses a slowdown introduced by a newer MarkupSafe version, especially for templates with large or complex text content.
Original PR description
Starting version 2.1.4 of markupsafe, they decided to adapt the `striptags` function to use in-python-loops instead of the original implemenation that relied on pre-compiled regex. A problem has been…
Starting version 2.1.4 of markupsafe, they decided to adapt the `striptags` function to use in-python-loops instead of the original implemenation that relied on pre-compiled regex. A problem has been spotted with qweb templates that used `striptags` with large inputs, which led to the investigation of this function and it was found that the old implementation is actually faster. In fact, the PR introducing this change in Markupsafe, made these claims with no benchmarks whatsoever: https://github.com/pallets/markupsafe/pull/413/changes The new implementation of markupsafe is O(N x M), where n is the number of tags and M being the length of the input string. The old regex approach does a single c-level scan to check the existence of the regex which is performing much better for varying input size. The benchmark cases below are in the form `<case_description>_<number_of_tags>`. We can see that in the cases where the current implementation is slightly faster is when there are no tags in the input which can be explained by the fact that the while loops will simply exit early. The time lost in the regex implementation is likely due to the deeper call stack to scan for the regex. Apart from that, in the case of an unclosed tag, the regex implementation is also slower because it still needs to scan the entire line. However, in that case the time taken is a handful of milliseconds, so it's not really a performance regression there either. Apart from that, the old implementation is consistently much more performant, for both small and large inputs. Benchmarks: | Case | Regex ms | Current ms | Speedup | |----------------------------------------------|----------|------------|---------| | plain_text_50k_words | 3.020 | 2.627 | 0.9x ← current_implementation | | unclosed_tag_then_50kb_text | 0.367 | 0.032 | 0.1x ← current_implementation | | unclosed_tag_then_500kb_text | 3.787 | 0.273 | 0.1x ← current_implementation | | multiple_unclosed_open_tags_then_50kb_text | 18.912 | 0.371 | 0.0x ← current_implementation | | multiple_unclosed_open_tags_then_500kb_text | 189.007 | 8.209 | 0.0x ← current_implementation | | unclosed_comment_then_500kb_text | 7.276 | 0.412 | 0.1x ← current_implementation | | 5k_small_tags | 0.986 | 22.096 | 22.4x ← regex_old_implementation | | 20k_small_tags | 4.125 | 492.186 | 119.3x ← regex_old_implementation | | 50k_small_tags | 12.658 | 5499.602 | 434.5x ← regex_old_implementation | | 1k_nested_divs | 0.155 | 0.923 | 5.9x ← regex_old_implementation | | 10k_nested_divs | 1.648 | 48.410 | 29.4x ← regex_old_implementation | | 2k_tags_with_attrs | 1.058 | 12.013 | 11.4x ← regex_old_implementation | | 20k_tags_with_attrs | 13.185 | 6068.755 | 460.3x ← regex_old_implementation | | 2k_multiline_tags | 0.815 | 10.819 | 13.3x ← regex_old_implementation | | 20k_multiline_tags | 8.939 | 4231.768 | 473.4x ← regex_old_implementation | | 1k_comments | 0.222 | 1.292 | 5.8x ← regex_old_implementation | | 1k_comments_hiding_tags | 0.163 | 1.121 | 6.9x ← regex_old_implementation | | 2k_mixed | 0.278 | 2.392 | 8.6x ← regex_old_implementation | | 10k_mixed | 1.400 | 50.959 | 36.4x ← regex_old_implementation | | qweb_shop_200_products | 0.907 | 7.880 | 8.7x ← regex_old_implementation | | qweb_shop_1000_products | 4.296 | 194.647 | 45.3x ← regex_old_implementation | This PR is needed because requirements.txt in Odoo specifies the following dependency: `MarkupSafe==2.1.5 ; python_version >= '3.12' \# (Noble)` This means that all versions running Ubuntu Noble, will be having the same issue introduced in version 2.1.4 of markupsafe. opw-5999688 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268580 Forward-Port-Of: odoo/odoo#257889
The registration flow for French e-invoicing has been reworked to better guide users toward the correct PDP setup and to make the process clearer in Send & Print. It also improves the registration wizard by showing key fields earlier, locking verified data, and completing registration automatically after verification, which should reduce confusion and manual steps.
Original PR description
#### [IMP] account_peppol,l10n_fr_pdp: rework PDP registration If PDP is not installed but Peppol is installed we suggest installing the PDP module for French companies - in the send & print instead…
#### [IMP] account_peppol,l10n_fr_pdp: rework PDP registration
If PDP is not installed but Peppol is installed we suggest
installing the PDP module for French companies
- in the send & print instead of the following warnings
- "You can send this invoice electronically via Peppol." (what is peppol)
- "partner has requested electronic invoices reception on Peppol."
- in the send & print for any French company that is not on PDP
(this warning can be disabled by setting the system parameter
`account_peppol.disable_pdp_warning` to true)
- in the peppol registration wizard by adding a warning
If PDP is installed we make the following changes to the send & print
- change the wording mentioning "Peppol" to mention the French e-invoicing instead
- make a PDP version of the "Peppol Info" (`account_peppol.WhatIsPeppol`)
- it explains what French E-Invoicing is
- it provides a button to open the registration wizard
- in case the company is registered on Peppol it deregisters the
company first (just like the "complete registration" button)
- display the "You can send this electronically via Peppol" warning
also for French companies (with the wording and "Peppol Info" mentioned above)
- It is displayed in case we are opening the Send & Print wizard from a French
company for a partner on peppol but the "Peppol" / "French
E-invoicing" checkbox is not checked
- Change the wording of the French company non-PDP warning to encourage
the user to register
In the PDP registration wizard
- make all the fields visible directly (already at the start of the KYB/KYC)
- make the SIREN part of the identifier readonly
- make the fields readonly after the verification
- automatically "validate" / register to PDP when we receive the KYC success
task-6320246
#### [IMP] l10n_fr_pdp: add system param for kyc siren
After the previous commit it is not really possible anymore
to use a different SIREN for the KYC than the one in the pdp identifier.
This is because:
- We derive the SIREN directly from the
Identifier in the registration wizard.
- The registration will be validated automatically after the KYC
- The values are readonly after the KYC in any case
That is a problem for testing because we have 1 SIREN to test the
KYC and it is independent from the identifiers provided by the French
datasets for the PDP test environment.
task-None
Forward-Port-Of: odoo/odoo#2717331 change
Enhancements to existing features
This update improves how French companies are guided toward electronic invoicing registration. It replaces confusing Peppol messages with clearer French e-invoicing guidance, adds a dedicated information flow, and makes the PDP registration process easier by showing required details earlier and completing registration automatically after verification.
Original PR description
#### [IMP] account_peppol,l10n_fr_pdp: rework PDP registration If PDP is not installed but Peppol is installed we suggest installing the PDP module for French companies - in the send & print instead…
#### [IMP] account_peppol,l10n_fr_pdp: rework PDP registration
If PDP is not installed but Peppol is installed we suggest
installing the PDP module for French companies
- in the send & print instead of the following warnings
- "You can send this invoice electronically via Peppol." (what is peppol)
- "partner has requested electronic invoices reception on Peppol."
- in the send & print for any French company that is not on PDP
(this warning can be disabled by setting the system parameter
`account_peppol.disable_pdp_warning` to true)
- in the peppol registration wizard by adding a warning
If PDP is installed we make the following changes to the send & print
- change the wording mentioning "Peppol" to mention the French e-invoicing instead
- make a PDP version of the "Peppol Info" (`account_peppol.WhatIsPeppol`)
- it explains what French E-Invoicing is
- it provides a button to open the registration wizard
- in case the company is registered on Peppol it deregisters the
company first (just like the "complete registration" button)
- display the "You can send this electronically via Peppol" warning
also for French companies (with the wording and "Peppol Info" mentioned above)
- It is displayed in case we are opening the Send & Print wizard from a French
company for a partner on peppol but the "Peppol" / "French
E-invoicing" checkbox is not checked
- Change the wording of the French company non-PDP warning to encourage
the user to register
In the PDP registration wizard
- make all the fields visible directly (already at the start of the KYB/KYC)
- make the SIREN part of the identifier readonly
- make the fields readonly after the verification
- automatically "validate" / register to PDP when we receive the KYC success
task-6320246
#### [IMP] l10n_fr_pdp: add system param for kyc siren
After the previous commit it is not really possible anymore
to use a different SIREN for the KYC than the one in the pdp identifier.
This is because:
- We derive the SIREN directly from the
Identifier in the registration wizard.
- The registration will be validated automatically after the KYC
- The values are readonly after the KYC in any case
That is a problem for testing because we have 1 SIREN to test the
KYC and it is independent from the identifiers provided by the French
datasets for the PDP test environment.
task-None
Forward-Port-Of: odoo/odoo#27173317 changes
Enhancements to existing features
The Point of Sale IoT test dialog now shows more complete diagnostics for each IoT box. It checks connection types, reports network speed, and displays when the test was run, making it easier to spot connection issues and verify device health.
Original PR description
This commit adds the following extra functionality to the IoT test dialog: - The longpolling and websocket connection of each IoT box is tested - The network speed is reported, like the IoT test button in the backend - The timestamp of the test is shown task-6329619
The customer portal task view has been cleaned up to show only the most relevant information. This makes the page easier to scan, displays full task names without cutting them off, and uses the task name in the browser tab for a clearer experience.
Original PR description
- Update `_task_get_searchbar_sortings` override to match the parent method signature. task-6197616
Manufacturing orders tied to a project will now only create employee productivity analytic costs when the manufacturing cost setting is enabled. This helps prevent duplicate project cost postings when the same project already receives costs from sales or purchases.
Original PR description
Manufacturing orders linked to a project could generate duplicate analytic entries when costs were already posted through another flow, such as sale COGS or purchase costs linked to the same project. This complements the analytic costs toggle added on manufacturing operation picking types by applying it to employee productivity analytic entries. This commit's changes: - uses the MO project's analytic distribution only when analytic_costs is enabled, while keeping cleanup behaviour task-5130915
The payrun kanban and layout views now include a toggleable chatter panel. This makes it easier to review messages and follow discussions for the selected payrun without leaving the main screen.
Original PR description
Add a toggleable chatter side panel to the payrun kanban view and to the payrun layout. The panel displays the chatter of the selected paryn. task-6192099
This update adds support for the ONSS reduction for employers hiring artists. It estimates the reduction on payslips and includes it in DMFA reports, helping payroll records and submissions reflect the benefit more accurately.
Original PR description
For employers hiring artists they can get ONSS reduction (Target group reduction RGC) what's new ? calculations to show an estimated amount on the payslip, with relative salary rule. added the reduction to the dmfa (pdf, xml). a new model to store the reduction lines ( employee, amount ) on the dmfa tab. Task#6174405
This update enhances the tracking of sickness leave by allowing a relapse leave to be linked to its original leave. This simplifies payroll calculations and improves the user experience by providing better visibility into leave history. The changes also automate the selection of the previous day's leave as the default for relapse leaves.
Original PR description
We wanted to add a new field to hr_leave to link a relapse leave to the origin leave, to ease tracking, payroll calculations and improve UX. -Added a new M2O field to link the origin leave. -Adeed a new M2M field to compute the allowed origin leaves to choose from. -default the origin leave if exist a leave the day before the new leave start date. Task#6209556
This update adds a payment reference to invoices generated from Amazon orders. This enhancement improves traceability and simplifies reconciliation between Amazon sales data and Odoo invoices, leading to more accurate financial reporting.
Original PR description
Set `payment_reference` on invoices from `amazon_order_ref` during invoice creation to improve traceability and reconciliation for Amazon orders. Task: 6140292
This update simplifies the 'Print Planning' action within the Project app, renaming it to 'Print' for clarity. It also removes an unnecessary header from the printed schedule, allowing the full page to be used for the table. This improves the user experience and presentation of project schedules.
Original PR description
The Gantt and Calendar "Print Planning" action lives in the Project app and is confusing alongside the Planning app, so rename it to simply "Print". The printed schedule also uses `web.internal_layout`, which adds a date/company/ page header and reserves top margin for it. Switch the report to `web.basic_layout` so the header is removed and the table can use the full page. task-6186527
This update enhances the Gantt view's user experience by improving the display of pill titles and adding a toggle to show dependencies. It also introduces finer-grained time precision for scheduling tasks, resulting in a more intuitive and accurate planning tool.
Original PR description
*: web_studio, planning, planning_field_service, pos_appointment, project_enterprise, sale_planning, hr_holidays_gantt Refines the Gantt view layout and interaction model with the following updates: - Clip pill titles cleanly on overflow rather than displaying an ellipsis. - Map double-clicks directly to the form dialog wrapper, buffering single clicks to isolate the popover action. - Introduce a "Show dependencies" action toggle in the reschedule dropdown (persisted in localStorage). - Hide all connector lines when the dependency toggle is disabled, unless their anchor pill is actively hovered. - Propagate connector line highlighting whenever its source or target pill is hovered. - Adapt the pill and connector highlight style to their color. - Widen the connector bullet hitbox to facilitate interaction. - Add a new quarter-day (6h) cell precision configuration for week and month view scales. - Remove useless divs from the gantt_renderer_controls file. task-6159075
This update strengthens the connection between employee records and their associated documents. Now, when uploading documents, they're automatically linked to the employee, and employees can easily view all their linked documents regardless of location. This streamlines document access and management for HR staff.
Original PR description
This commit adds more synchronization between the documents and the employee by implementing the points below. - Add the support of the `hr.employee` model in the res_model of documents. - When coming from the context of the employee, uploading the file leads to linking the employee by default to the res_model. - Open the base action_open_documents for employee when the bridge is enabled, allowing to show all documents linked to the employee irrespective of their location (See Task-5948278). Task-6072094
This update enhances the user experience on the Helpdesk portal by simplifying search functionality and improving ticket display. Specifically, the search now prioritizes ticket descriptions and messages, and ticket names are no longer truncated, providing a clearer view for support agents and customers.
Original PR description
This commit: - Replace search on "Customer" and "Helpdesk Team" with "Description" and "Messages". - Display folded stage's pill in green. - Allow ticket names to wrap instead of being truncated. task-6197601
This update simplifies tax management for records where taxes are calculated externally. The toggle to manually set included/excluded taxes has been hidden to prevent user interference and ensure accurate calculations, particularly when integrated with Avalara for US and EDI for Brazil. This change maintains data consistency and avoids potential tax filing errors.
Original PR description
A new way to manage price-included/-excluded taxes was recently added [1]. We hide the toggle if taxes are calculated externally, because for these records the tax calculator is in charge and the user shouldn't be tempted to change what they determined. Doing so doesn't have the intended effect anyway: - Confirming the record will recalculate the taxes anyway, - If you somehow force it to be different, Odoo won't be in sync with Avalara which causes unexpected tax filing (for US) or EDI (for Brazil), [1] https://github.com/odoo/enterprise/pull/114100 task-6327486
This update adds a 'Print Yield Copy' button to delivery guides in Chile, aligning with local regulations. This allows for the physical signing of fiscal documents, ensuring compliance with Chilean tax requirements. The change improves the functionality of delivery guides for businesses operating in Chile.
Original PR description
*: _stock Purpose: In Chile, all fiscal PDF documents printed also needs to print a "yield copy." The copy has an extra block of information that allows fiscal documents to be signed physically (yielded). Since Electronic Delivery Guides are fiscal valid PDFs, a yield copy needs to be implemented. When a delivery guide is created for a delivery order, a "Print Yield Copy" button will appear next to "Print Delivery Guide" button. This button will print the yield copy of the delivery guide when clicked. task-6180890
This update introduces a standardized method for extracting VAT numbers from various Odoo modules, simplifying VAT reporting and reconciliation. The change creates a reusable function to remove country codes from VAT numbers, ensuring consistency and accuracy across different reports and localization modules. This improves data quality and reduces manual effort for users.
Original PR description
In this commit: - Create a new generic method '_get_clean_vat_number' in res_partner - This method will be used to extract the numeric part of a VAT number by removing its country_code prefix. Community PR: https://github.com/odoo/odoo/pull/229461 Task [link](https://www.odoo.com/odoo/project.task/5117804) task-5117804
This update adds functionality to accurately calculate and report Belgian withholding tax exemptions for overtime hours (natures 44-59) within the 274.XX declaration. It leverages validated payslips and existing hour caps to ensure accurate calculations, streamlining the reporting process for Belgian employees.
Original PR description
Compute the withholding-tax exemption for overtime hours (natures 44–59) within the Belgian 274.XX declaration. Overtime worked-day lines are collected from validated payslips, bucketed by rate and sector (CP124/CP302/immovable work), and allocated to the appropriate nature codes while respecting each employee's annual hour cap. Hours already declared in earlier months of the same year are carried forward so the cap is enforced cumulatively. The exemption rate is stored as an updatable rule parameter. A white-cash-register flag on the company controls the higher cap for CP302 employees. New work-entry types, an XLS extra-hours sheet, a PDF section, and extended tests are included. Task Id: 5430988
This update enhances payroll reports to accurately reflect data for all companies within a branch structure. Previously, reports only included data for the root company. Now, reports automatically include data from the root company and all its child companies, ensuring more complete and accurate reporting. Thorough testing has been conducted to verify data integrity.
Original PR description
This tasks was about switching from a (1 report - 1 company) paradigm to a (1 report - many companies). The implementation is done in two parts: 1 - first ensure that the report is created with a…
This tasks was about switching from a (1 report - 1 company) paradigm to a (1 report - many companies). The implementation is done in two parts: 1 - first ensure that the report is created with a root company as company_id 2 - include that root company and all child companies in the reported data 1 -> This was done by enforcing the user to have a root company as self.env.company. It looked easier and safer, therefore more robust. 2 -> This was done by creating a new computed property __branch_ids__ and extending the search domain for related payslips or data. When relevant, the field company_id was added in the views. As well as search filters and group_by. (Cases where it's not relevant is for instance that the report is a pdf) **Testing** - Two tests were created for each report: - One to ensure you cannot generate a report from a branch / child company. (exception for social balance sheet) - One to make ensure that - only employees from the relevant companies (root + children) are included in the reported data - employees from root and all children are included in the reported data task-6220264
This update enhances the reliability of communication between our Self and POS systems and OBOX devices. It now includes a timeout feature, allowing jobs to be awaited even when devices aren't on the same network, ensuring smoother operations and preventing delays when devices are offline.
Original PR description
Is now possible to await OBOX jobs with a specific timeout in PoS ans Self Order. This is usefull when the user device isn't connected on the same network as the OBOX and others hardware. taskId: 6248159 Forward-Port-Of: odoo/enterprise#118646
2 changes
Enhancements to existing features
This update enhances the mobile bank reconciliation process by introducing a dedicated, simplified view. Now, users on mobile devices will see key information like statement date and remaining balance alongside the reconciliation details, providing better context and improving usability. The changes maintain the existing desktop functionality.
Original PR description
Current behavior before PR: On mobile devices, the bank reconciliation dialog relied on the base kanban view of account move line, which is difficult to handle and lacked contextual information about…
Current behavior before PR: On mobile devices, the bank reconciliation dialog relied on the base kanban view of account move line, which is difficult to handle and lacked contextual information about the statement being reconciled. Desired behavior after PR is merged: The bank reconciliation flow on mobile uses a dedicated kanban view with a simplified layout. An informational line is displayed above the main view, showing the statement date, reference, and remaining balance for better context. Changes implemented: - Added a mobile-specific kanban view for bank reconciliation dialog. - Displayed an information line above the kanban view with statement date, reference, and balance like desktop view for bank reconciliation dialog. - Moved 'onSelectionChanged' to 'BankRecSelectCreateDialog' and shared it through 'bankRecInfo', moved 'remainingAmountFormatted' into the state, and removed the duplicated getters from the list and kanban renderers. - Kept the existing desktop layout and behavior unchanged. - Added a HOOT test to check the mobile bank reconciliation dialog. task-5502469
This update introduces a new field for Belgian IBANs on bank journals, enabling more accurate import of bank statements. The extension number, found in CODA files, helps identify the correct journal for synchronization with Codabox or Codaclean. This improves the reliability of bank statement data import.
Original PR description
Original commit message: Bank journal can have the same bank account number, to be able to have a difference between them. We will add an extension number field on the journal that will be displayed…
Original commit message: Bank journal can have the same bank account number, to be able to have a difference between them. We will add an extension number field on the journal that will be displayed only when having a synchronization with codabox or codaclean. This extension number can be found in the CODA file when the second line of the coda start with '12', which means that we have a belgian iban. With that we are able to know the journal to where we want to import the statement. task-5254158 Backport commit message: This commit backports the code to handle extension number in stable. Some adaptations were done to allow this backport. 1. We have a new module for the new field and the view. 2. Except that, the code stays in the existing modules with a condition that check if the extension number is present in the journal's field list. NB: This implementation is pretty bad but the existing code doesn't include hooks to extend to add customization. To avoid a whole refactoring in stable, this approach was chosen. 3. A test and a test file from the codabox module are deleted because we don't want to create a new module for tests only. task-6116452
1 change
Enhancements to existing features
This update makes French e-invoicing setup clearer and more proactive during invoice sending and registration. It now guides French companies toward the PDP module when needed, updates the wording to better explain local e-invoicing instead of generic Peppol language, and simplifies the registration flow by showing key fields earlier and completing registration automatically after verification.
Original PR description
#### [IMP] account_peppol,l10n_fr_pdp: rework PDP registration If PDP is not installed but Peppol is installed we suggest installing the PDP module for French companies - in the send & print instead…
#### [IMP] account_peppol,l10n_fr_pdp: rework PDP registration
If PDP is not installed but Peppol is installed we suggest
installing the PDP module for French companies
- in the send & print instead of the following warnings
- "You can send this invoice electronically via Peppol." (what is peppol)
- "partner has requested electronic invoices reception on Peppol."
- in the send & print for any French company that is not on PDP
(this warning can be disabled by setting the system parameter
`account_peppol.disable_pdp_warning` to true)
- in the peppol registration wizard by adding a warning
If PDP is installed we make the following changes to the send & print
- change the wording mentioning "Peppol" to mention the French e-invoicing instead
- make a PDP version of the "Peppol Info" (`account_peppol.WhatIsPeppol`)
- it explains what French E-Invoicing is
- it provides a button to open the registration wizard
- in case the company is registered on Peppol it deregisters the
company first (just like the "complete registration" button)
- display the "You can send this electronically via Peppol" warning
also for French companies (with the wording and "Peppol Info" mentioned above)
- It is displayed in case we are opening the Send & Print wizard from a French
company for a partner on peppol but the "Peppol" / "French
E-invoicing" checkbox is not checked
- Change the wording of the French company non-PDP warning to encourage
the user to register
In the PDP registration wizard
- make all the fields visible directly (already at the start of the KYB/KYC)
- make the SIREN part of the identifier readonly
- make the fields readonly after the verification
- automatically "validate" / register to PDP when we receive the KYC success
task-6320246
#### [IMP] l10n_fr_pdp: add system param for kyc siren
After the previous commit it is not really possible anymore
to use a different SIREN for the KYC than the one in the pdp identifier.
This is because:
- We derive the SIREN directly from the
Identifier in the registration wizard.
- The registration will be validated automatically after the KYC
- The values are readonly after the KYC in any case
That is a problem for testing because we have 1 SIREN to test the
KYC and it is independent from the identifiers provided by the French
datasets for the PDP test environment.
task-None