Daily updates from Odoo
Friday, July 17, 2026
38 changes
7 changes
Enhancements to existing features
Peruvian e-invoicing now includes the product classification codes required by SUNAT's upcoming validation rules. This helps businesses avoid rejected e-invoices for affected goods when the new requirements take effect.
Original PR description
SUNAT is updating its validation rules 2026-08-01, adding three mandatory annexes (25.1, 25.2, 25.3) to Product Catalog N25. E-invoices for these goods are rejected when the required UNSPSC code is not available in the database. Most of the required codes already exist and are active. The rest are handled here: two missing UNSPSC codes were added to the shared catalog, while the fourteen codes that exist but are inactive and the SUNAT-only code 11111111 (which is not part of the UNSPSC standard) are activated from the Peru localization instead. Doing the Peru-specific part in the l10n_pe_edi install hook and upgrade script, the way l10n_mx_edi and l10n_ke_edi_oscu do for their own codes, keeps these activations out of databases that do not use the Peruvian localization. Task-6366907 Forward-Port-Of: odoo/enterprise#124200 Forward-Port-Of: odoo/enterprise#123577
The journal creation wizard in Accounting now supports navigation with keyboard arrow keys. This makes the setup flow easier and faster to use, especially for users who prefer keyboard-based navigation or need improved accessibility.
Original PR description
This commit aims to allow for navigation through the journal create wizard via keybaord arrows. Related Odoofin PR: https://github.com/odoo/odoofin/pull/502 task-5796200 Forward-Port-Of: odoo/enterprise#105541
Bank reconciliation now highlights draft statement lines in blue, making them quicker to identify during review. This helps users distinguish unfinished items at a glance and reduces the chance of overlooking draft entries.
Original PR description
This commit will put the text in blue when the statement line is in draft to be able to see quickly which lines are in draft. task-6327308 Forward-Port-Of: odoo/enterprise#124418 Forward-Port-Of: odoo/enterprise#121775
The payment form no longer shows the Payment Identifier field because it does not provide useful information for users. This keeps the payment screen cleaner and helps users focus on relevant payment details.
Original PR description
- The Payment Identifier field has been permanently hidden from the payment form view, as it does not provide actionable or useful information to the end user. community pr - https://github.com/odoo/odoo/pull/266072 task- 6237870 Forward-Port-Of: odoo/enterprise#118183
Following the introduction of role-based activity assignments, this commit reinforces the feature with test coverage and frontend cleanups. Key additions and improvements: - Backend Testing: Added unit tests covering edge cases, including user archiving reassignments, role deletion constraints, and dynamic role/user computations during activity scheduling. - Frontend Testing: Introduced Hoot tests to validate the systray "To Assign" counter and the assignment flow within the Acti
Original PR description
Following the introduction of role-based activity assignments, this commit reinforces the feature with test coverage and frontend cleanups. Key additions and improvements: - Backend Testing: Added unit tests covering edge cases, including user archiving reassignments, role deletion constraints, and dynamic role/user computations during activity scheduling. - Frontend Testing: Introduced Hoot tests to validate the systray "To Assign" counter and the assignment flow within the Activity Assign popover. - UI Consistency: Replaced hardcoded inline styles in the Activity Assign popover with standard Odoo UI utility classes. - JS Architecture: Centralized thread retrieval logic into the frontend Activity model for better encapsulation and component decoupling. Related to Task-6292889 (https://github.com/odoo/odoo/pull/269609) Task-6197665
Test lints should be deterministic so retrying them doesn't make sense. While lints are not the slowest, pylint can take 10~15mn in later branches, and with retrying that's half an hour (and some) to get a failure, which is all that in wasted staging and build time. Forward-Port-Of: odoo/odoo#276600
Original PR description
Test lints should be deterministic so retrying them doesn't make sense. While lints are not the slowest, pylint can take 10~15mn in later branches, and with retrying that's half an hour (and some) to get a failure, which is all that in wasted staging and build time. Forward-Port-Of: odoo/odoo#276600
Move French e-invoicing technical statuses out of the main invoice UI and into the chatter. The PPF status is kept available in debug mode for troubleshooting, while regular users get a concise chatter summary with the PA status, PPF status, and any returned errors. Duplicate Lifecycle XML attachments are no longer posted in the chatter. Task-6273270 Forward-Port-Of: odoo/odoo#276770 Forward-Port-Of: odoo/odoo#269465
Original PR description
Move French e-invoicing technical statuses out of the main invoice UI and into the chatter. The PPF status is kept available in debug mode for troubleshooting, while regular users get a concise chatter summary with the PA status, PPF status, and any returned errors. Duplicate Lifecycle XML attachments are no longer posted in the chatter. Task-6273270 Forward-Port-Of: odoo/odoo#276770 Forward-Port-Of: odoo/odoo#269465
4 changes
Enhancements to existing features
Updates the product code catalog so Peruvian e-invoices can include the required SUNAT product classifications for new 2026 validation rules. This helps avoid invoice rejections for affected goods while keeping Peru-specific codes limited to companies using the Peru localization.
Original PR description
SUNAT is updating its validation rules 2026-08-01, adding three mandatory annexes (25.1, 25.2, 25.3) to Product Catalog N25. E-invoices for these goods are rejected when the required UNSPSC code is not available in the database. Most of the required codes already exist and are active. The rest are handled here: two missing UNSPSC codes were added to the shared catalog, while the fourteen codes that exist but are inactive and the SUNAT-only code 11111111 (which is not part of the UNSPSC standard) are activated from the Peru localization instead. Doing the Peru-specific part in the l10n_pe_edi install hook and upgrade script, the way l10n_mx_edi and l10n_ke_edi_oscu do for their own codes, keeps these activations out of databases that do not use the Peruvian localization. Task-6366907 Forward-Port-Of: odoo/enterprise#124200 Forward-Port-Of: odoo/enterprise#123577
Test lints should be deterministic so retrying them doesn't make sense. While lints are not the slowest, pylint can take 10~15mn in later branches, and with retrying that's half an hour (and some) to get a failure, which is all that in wasted staging and build time. Forward-Port-Of: odoo/odoo#276600
Original PR description
Test lints should be deterministic so retrying them doesn't make sense. While lints are not the slowest, pylint can take 10~15mn in later branches, and with retrying that's half an hour (and some) to get a failure, which is all that in wasted staging and build time. Forward-Port-Of: odoo/odoo#276600
Move French e-invoicing technical statuses out of the main invoice UI and into the chatter. The PPF status is kept available in debug mode for troubleshooting, while regular users get a concise chatter summary with the PA status, PPF status, and any returned errors. Duplicate Lifecycle XML attachments are no longer posted in the chatter. Task-6273270 Forward-Port-Of: odoo/odoo#276770 Forward-Port-Of: odoo/odoo#269465
Original PR description
Move French e-invoicing technical statuses out of the main invoice UI and into the chatter. The PPF status is kept available in debug mode for troubleshooting, while regular users get a concise chatter summary with the PA status, PPF status, and any returned errors. Duplicate Lifecycle XML attachments are no longer posted in the chatter. Task-6273270 Forward-Port-Of: odoo/odoo#276770 Forward-Port-Of: odoo/odoo#269465
When a barcode scan matches a specific product variant, the product configurator now behaves the same as when the user searches by barcode: - The `always`-mode attribute (e.g. Color) is preselected from the matched variant instead of being hidden or left blank. - The `no_variant`-mode attributes (e.g. Size) are shown for user input. opw-6220883 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276800 Forward-Port-Of: odo
Original PR description
When a barcode scan matches a specific product variant, the product configurator now behaves the same as when the user searches by barcode: - The `always`-mode attribute (e.g. Color) is preselected from the matched variant instead of being hidden or left blank. - The `no_variant`-mode attributes (e.g. Size) are shown for user input. opw-6220883 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276800 Forward-Port-Of: odoo/odoo#265189
8 changes
Enhancements to existing features
The journal creation wizard can now be navigated using keyboard arrow keys. This makes setup faster and more accessible for users who prefer or rely on keyboard navigation.
Original PR description
This commit aims to allow for navigation through the journal create wizard via keybaord arrows. Related Odoofin PR: https://github.com/odoo/odoofin/pull/502 task-5796200 Forward-Port-Of: odoo/enterprise#105541
This update ensures required product classification codes are available for Peruvian electronic invoices ahead of SUNAT's 2026 validation changes. It helps prevent invoice rejections for affected goods while limiting Peru-specific code activations to companies using the Peruvian localization.
Original PR description
SUNAT is updating its validation rules 2026-08-01, adding three mandatory annexes (25.1, 25.2, 25.3) to Product Catalog N25. E-invoices for these goods are rejected when the required UNSPSC code is not available in the database. Most of the required codes already exist and are active. The rest are handled here: two missing UNSPSC codes were added to the shared catalog, while the fourteen codes that exist but are inactive and the SUNAT-only code 11111111 (which is not part of the UNSPSC standard) are activated from the Peru localization instead. Doing the Peru-specific part in the l10n_pe_edi install hook and upgrade script, the way l10n_mx_edi and l10n_ke_edi_oscu do for their own codes, keeps these activations out of databases that do not use the Peruvian localization. Task-6366907 Forward-Port-Of: odoo/enterprise#124200 Forward-Port-Of: odoo/enterprise#123577
It is mandatory in BE to add a legal note on the invoice when using a "Co-Contractant" tax task-5905176 Forward-Port-Of: odoo/odoo#275388 Forward-Port-Of: odoo/odoo#251797
Original PR description
It is mandatory in BE to add a legal note on the invoice when using a "Co-Contractant" tax task-5905176 Forward-Port-Of: odoo/odoo#275388 Forward-Port-Of: odoo/odoo#251797
In multicompany, it can happen that one company (let's call it company Origin) cannot handle a payment method in their country, so it uses another company's (company MoneyHandler), even if it's in another country. The accounting flows must be then adjusted: - In company Origin, the invoice must be matched by a clearing entry - In company MoneyHandler, payment must match its move (if it exists) with a clearing entry. The payment move doesn't exist if `account_accountant` is installed but no O
Original PR description
In multicompany, it can happen that one company (let's call it company Origin) cannot handle a payment method in their country, so it uses another company's (company MoneyHandler), even if it's in…
In multicompany, it can happen that one company (let's call it company Origin) cannot handle a payment method in their country, so it uses another company's (company MoneyHandler), even if it's in another country. The accounting flows must be then adjusted: - In company Origin, the invoice must be matched by a clearing entry - In company MoneyHandler, payment must match its move (if it exists) with a clearing entry. The payment move doesn't exist if `account_accountant` is installed but no Outstanding account is configured on the payment method line. Same but opposite thing must happen for credit notes in company Origin that match a reimbursement in company MoneyHandler. Cancellation of a payment must be reflected on the entries: deleting when feasible, reversing when not (unless a lock date/hash is present, which would block the cancellation) _(To do: testing/review, credit note, cancellation/reversal of the payment)_ Task [link](https://www.odoo.com/odoo/project.task/6037525) task-6037525 Forward-Port-Of: odoo/odoo#259197
Move French e-invoicing technical statuses out of the main invoice UI and into the chatter. The PPF status is kept available in debug mode for troubleshooting, while regular users get a concise chatter summary with the PA status, PPF status, and any returned errors. Duplicate Lifecycle XML attachments are no longer posted in the chatter. Task-6273270 Forward-Port-Of: odoo/odoo#276770 Forward-Port-Of: odoo/odoo#269465
Original PR description
Move French e-invoicing technical statuses out of the main invoice UI and into the chatter. The PPF status is kept available in debug mode for troubleshooting, while regular users get a concise chatter summary with the PA status, PPF status, and any returned errors. Duplicate Lifecycle XML attachments are no longer posted in the chatter. Task-6273270 Forward-Port-Of: odoo/odoo#276770 Forward-Port-Of: odoo/odoo#269465
When importing an xml, in the notes you can have codes. We don't want them to be shown in the form view of invoice. task-6365267 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274996
Original PR description
When importing an xml, in the notes you can have codes. We don't want them to be shown in the form view of invoice. task-6365267 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274996
When a barcode scan matches a specific product variant, the product configurator now behaves the same as when the user searches by barcode: - The `always`-mode attribute (e.g. Color) is preselected from the matched variant instead of being hidden or left blank. - The `no_variant`-mode attributes (e.g. Size) are shown for user input. opw-6220883 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276543 Forward-Port-Of: odo
Original PR description
When a barcode scan matches a specific product variant, the product configurator now behaves the same as when the user searches by barcode: - The `always`-mode attribute (e.g. Color) is preselected from the matched variant instead of being hidden or left blank. - The `no_variant`-mode attributes (e.g. Size) are shown for user input. opw-6220883 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276543 Forward-Port-Of: odoo/odoo#265189
Test lints should be deterministic so retrying them doesn't make sense. While lints are not the slowest, pylint can take 10~15mn in later branches, and with retrying that's half an hour (and some) to get a failure, which is all that in wasted staging and build time. Forward-Port-Of: odoo/odoo#276600
Original PR description
Test lints should be deterministic so retrying them doesn't make sense. While lints are not the slowest, pylint can take 10~15mn in later branches, and with retrying that's half an hour (and some) to get a failure, which is all that in wasted staging and build time. Forward-Port-Of: odoo/odoo#276600
5 changes
Enhancements to existing features
Peruvian e-invoicing now includes the additional product classification codes required by SUNAT's upcoming validation rules. This helps businesses avoid invoice rejections for affected goods once the new requirements take effect.
Original PR description
SUNAT is updating its validation rules 2026-08-01, adding three mandatory annexes (25.1, 25.2, 25.3) to Product Catalog N25. E-invoices for these goods are rejected when the required UNSPSC code is not available in the database. Most of the required codes already exist and are active. The rest are handled here: two missing UNSPSC codes were added to the shared catalog, while the fourteen codes that exist but are inactive and the SUNAT-only code 11111111 (which is not part of the UNSPSC standard) are activated from the Peru localization instead. Doing the Peru-specific part in the l10n_pe_edi install hook and upgrade script, the way l10n_mx_edi and l10n_ke_edi_oscu do for their own codes, keeps these activations out of databases that do not use the Peruvian localization. Task-6366907 Forward-Port-Of: odoo/enterprise#124200 Forward-Port-Of: odoo/enterprise#123577
Move French e-invoicing technical statuses out of the main invoice UI and into the chatter. The PPF status is kept available in debug mode for troubleshooting, while regular users get a concise chatter summary with the PA status, PPF status, and any returned errors. Duplicate Lifecycle XML attachments are no longer posted in the chatter. Task-6273270 Forward-Port-Of: odoo/odoo#276770 Forward-Port-Of: odoo/odoo#269465
Original PR description
Move French e-invoicing technical statuses out of the main invoice UI and into the chatter. The PPF status is kept available in debug mode for troubleshooting, while regular users get a concise chatter summary with the PA status, PPF status, and any returned errors. Duplicate Lifecycle XML attachments are no longer posted in the chatter. Task-6273270 Forward-Port-Of: odoo/odoo#276770 Forward-Port-Of: odoo/odoo#269465
No task ID
Original PR description
No task ID
Test lints should be deterministic so retrying them doesn't make sense. While lints are not the slowest, pylint can take 10~15mn in later branches, and with retrying that's half an hour (and some) to get a failure, which is all that in wasted staging and build time. Forward-Port-Of: odoo/odoo#276600
Original PR description
Test lints should be deterministic so retrying them doesn't make sense. While lints are not the slowest, pylint can take 10~15mn in later branches, and with retrying that's half an hour (and some) to get a failure, which is all that in wasted staging and build time. Forward-Port-Of: odoo/odoo#276600
The Nilvera client returns base64-encoded PDF content from the GET pdf endpoint. A previous change https://github.com/odoo-dev/odoo/commit/d2c2dc0bc33c369369ba748a513fad0c6edcaf6a incorrectly stored this base64 string directly into the `ir.attachment.raw` field without decoding. Because the field is binary, the base64 ASCII text was UTF-8 encoded on the disk, leaving the files unreadable in browsers. This commit introduces a migration script to fix this. For newly downloaded attachment
Original PR description
The Nilvera client returns base64-encoded PDF content from the GET pdf endpoint. A previous change https://github.com/odoo-dev/odoo/commit/d2c2dc0bc33c369369ba748a513fad0c6edcaf6a incorrectly stored this base64 string directly into the `ir.attachment.raw` field without decoding. Because the field is binary, the base64 ASCII text was UTF-8 encoded on the disk, leaving the files unreadable in browsers. This commit introduces a migration script to fix this. For newly downloaded attachments, 35fd6ce handles the decoding. task-6377121 Forward-Port-Of: odoo/odoo#275376
1 change
Enhancements to existing features
Peruvian e-invoicing now includes the product classification codes required by SUNAT's upcoming 2026 validation rules. This helps businesses avoid rejected electronic invoices for affected goods once the new rules take effect.
Original PR description
SUNAT is updating its validation rules 2026-08-01, adding three mandatory annexes (25.1, 25.2, 25.3) to Product Catalog N25. E-invoices for these goods are rejected when the required UNSPSC code is not available in the database. Most of the required codes already exist and are active. The rest are handled here: two missing UNSPSC codes were added to the shared catalog, while the fourteen codes that exist but are inactive and the SUNAT-only code 11111111 (which is not part of the UNSPSC standard) are activated from the Peru localization instead. Doing the Peru-specific part in the l10n_pe_edi install hook and upgrade script, the way l10n_mx_edi and l10n_ke_edi_oscu do for their own codes, keeps these activations out of databases that do not use the Peruvian localization. Task-6366907 Forward-Port-Of: odoo/enterprise#124200 Forward-Port-Of: odoo/enterprise#123577
7 changes
Enhancements to existing features
Saudi Arabian currency rate updates now use the Saudi Central Bank as the dedicated source instead of the default xe.com provider. This improves alignment with official SAR exchange rates and avoids duplicate rate entries when several days of data are returned.
Original PR description
Added a new exchange rate provider for the Saudi Central Bank (SAMA) to fetch official SAR exchange rates. Saudi Arabia is removed from the xe.com default and mapped to this dedicated provider instead. Since the API response includes multiple days of data, duplicate currency entries are deduplicated by keeping the first (most recent) occurrence of each currency code. task-4422561
Customer notes now appear as warnings on billable helpdesk tickets and field service shift forms. This helps service teams see important sales or customer information before working on a ticket or scheduled visit.
Original PR description
- When there is a note on a customer, display it as a warning: - in the ticket form view, if the team is billable - shift form view - move `use_helpdesk_sale_timesheet` from `helpdesk_sale_timesheet` into `helpdesk_sale` --- Task-4910696
This improvement creates redirects from old product links to their new Odoo product pages when moving from another ecommerce platform. It helps businesses retain SEO value and avoid broken product links after transferring an old domain.
Original PR description
When switching from an ecommerce platform to another, a major issue is that all the links to your products change and so all of the SEO linked to those product links are lost. One way to mitigate this issue is to create redirects for each products. Once the old domain is transfered, the old product links are restored and redirect to the corresponding odoo products.
Obox remote debugging can now be enabled directly from the Obox form instead of asking customers to visit a special device URL. This makes support sessions easier to start by letting users provide the required Tailscale token in Odoo.
Original PR description
Before this commit, enabling remote debug for an Obox required accessing a specific URL on the Obox, which might be difficult to instruct clients to do. After this commit, there is a Remote Debug toggle in the Obox form view, just like the IoT box. A user simply needs to provide the Tailscale token to enable remote debug. task-6392868
The paid appointments module no longer creates a default booking fee product during installation, keeping databases cleaner for businesses that do not use paid appointments. A booking product is now created only when needed for paid appointment types, and unused unsold booking products can be removed.
Original PR description
# Purpose Installing the module "appointment_account_payment" creates a default product called "booking fees" used in paid appointment type. This auto-creation pollutes the DB of users that never uses such appointment types. Furthermore, the product couldn't be deleted once created. # Specs - Removed the creation of a default booking product upon module installation. - On the creation of a paid appointment type, will create a default product ready for edition by the user. - On manual checkbox activation, a product with a default price can be created through the dropdown menu. - Unused booking product that haven't been sold can be deleted. Task-6167887
Users can now apply common reconciliation actions to multiple selected bank statement lines at once. This reduces repetitive work by letting teams use the main action, assign partners, or set account numbers across several records in one step.
Original PR description
Added actions for multi select of bank statement lines in the list view to: - Use the primary action of all of the selected records - Set the partner for all of the selected records - Set the account number for all of the selected records task-6102308
Deleting an attachment linked to a document now moves the document to the Trash instead of removing it permanently. This protects business documents from being lost when attachments are deleted from related records such as vendor bills or chatter messages.
Original PR description
We replace the `documents.unlink.mixin`, which was previously applied only to specific models, with a generic mechanism that works regardless of the involved models. This new mechanism archives the…
We replace the `documents.unlink.mixin`, which was previously applied only to specific models, with a generic mechanism that works regardless of the involved models. This new mechanism archives the documents when their attachments are deleted, preventing their deletion. It does a little more than the mixin as the mixin was preveting the deletion of the document only when a record sharing a common attachment was deleted. Here, we also preserve the document if the attachment is deleted directly (for example from the chatter of a record). In that case, we also preserve the link between the document and the record (through the res_model and res_id of the document record). This change is motivated by use-cases similar to the following: - In document, click on the action "Create Vendor Bill" - On the chatter of the account.move, delete the attachment - Return to Documents Before, the document was deleted. Now, it has been moved in the Trash. To implement that feature, we remove the "ondelete cascade" on the attachment_id field of document and implement a custom version of it that move the associated documents (if any) in the Trash. Thanks to the api.ondelete decorator, we intercept all attachment deletion and if some of them are linked to a document we copy them and associate their copy with the documents before they are deleted. Note that the copy is cheap as odoo implements a deduplication of the store (see IrAttachment._file_write). Notes that we first have tried to preserve the attachment instead of duplicating it. But it was breaking other flow as they were expecting the attachment to be deleted. For example, when deleting a message with an attachment in the chatter, as the attachment was preserved it was still linked to the message even if it was not anymore directly linked to the model (ex.: lead) through res_model, res_id which caused the attachment to still appear in the chatter. Co-authored-by: Florian Charlier <flch@odoo.com> Task-5155496
2 changes
Enhancements to existing features
Audit check statuses now update automatically based on the status of their related accounts, reducing manual work and improving consistency. The interface also uses clearer wording, including "Last Comment" and past-tense status labels across working files and tax returns.
Original PR description
Before this commit, the status of an Audit Check (e.g., Fixed Assets) did not automatically reflect the status of its underlying accounts, forcing users to update it manually. Additionally, status labels used inconsistent tenses. This commit automates the Check status update based on the underlying account statuses: - If any account is To Review or Empty or Anomaly -> Check becomes 'To Review'. - If all accounts are Reviewed -> Check becomes 'Reviewed'. - If all accounts are Supervised -> Check becomes 'Supervised'. - If accounts are mixed (Reviewed + Supervised) -> Check becomes 'Supervised'. This commit also standardizes UI terminology by renaming the "Last Message" column to "Last Comment" and updating status labels to past tense (e.g., "Reviewed", "Submitted") across Working Files and Tax Returns. task-5388699
Peruvian e-invoicing now includes the product classification codes required by SUNAT's upcoming validation rules. This helps businesses avoid invoice rejections for affected goods when the new requirements take effect in August 2026.
Original PR description
SUNAT is updating its validation rules 2026-08-01, adding three mandatory annexes (25.1, 25.2, 25.3) to Product Catalog N25. E-invoices for these goods are rejected when the required UNSPSC code is not available in the database. Most of the required codes already exist and are active. The rest are handled here: two missing UNSPSC codes were added to the shared catalog, while the fourteen codes that exist but are inactive and the SUNAT-only code 11111111 (which is not part of the UNSPSC standard) are activated from the Peru localization instead. Doing the Peru-specific part in the l10n_pe_edi install hook and upgrade script, the way l10n_mx_edi and l10n_ke_edi_oscu do for their own codes, keeps these activations out of databases that do not use the Peruvian localization. Task-6366907 Forward-Port-Of: odoo/enterprise#124200 Forward-Port-Of: odoo/enterprise#123577
3 changes
Enhancements to existing features
Online payment initiation now includes the payer's bank account details and account holder name when required by providers such as Powens. This helps more bank payments start successfully by giving providers the information some banks need upfront.
Original PR description
With Powens, some banks requires the payer's bank information such as bank account number and bank holder name. This commit adds those informations to the odoofin route to be sent to the payment providers. task-6373634
This PR introduces an improvement to the account and l10n_latam_check modules that allows for multiple liquidity lines (one per check) to be recorded in a single journal entry. Currently, a split journal entry is created for each liquidity line, which presents several disadvantages: - Incorrect computation of payment and invoice states - Simplified workflow: By using a single journal entry for all liquidity lines, the workflow is significantly simplified and accounting complexity is redu
Original PR description
This PR introduces an improvement to the account and l10n_latam_check modules that allows for multiple liquidity lines (one per check) to be recorded in a single journal entry. Currently, a split…
This PR introduces an improvement to the account and l10n_latam_check modules that allows for multiple liquidity lines (one per check) to be recorded in a single journal entry. Currently, a split journal entry is created for each liquidity line, which presents several disadvantages:
- Incorrect computation of payment and invoice states
- Simplified workflow: By using a single journal entry for all liquidity lines, the workflow is significantly simplified and accounting complexity is reduced.
- First step towards a refactor: This improvement is a first step towards a broader refactor that will allow adapting the own check flow in payment registration without the need to create journal entries.
Changes made:
- Enhanced _synchronize_to_moves() method: - Allows for the creation and update of multiple liquidity lines within a single journal entry. - Removes excess liquidity lines if _prepare_move_line_default_vals() returns fewer lines than currently exist. - Account type-based counterparty identification: Replaces the previous position-based identification with an approach based on account types. - The starting index for extra line values is now dynamic, determined by the number of liquidity lines
- Removed _l10n_latam_check_split_move method:
- This method is no longer necessary given the new implementation that supports multiple liquidity lines in a single journal entry.
- Modified _prepare_move_line_default_vals() method: - Now returns one liquidity line for each registered own check, simplifying the generation of journal entries.
- Preserved _l10n_latam_check_unlink_split_move() method:
- Maintained for backward compatibility purposes, allowing payments containing split moves to be set to draft status.
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-prThe Nilvera client returns base64-encoded PDF content from the GET pdf endpoint. A previous change https://github.com/odoo-dev/odoo/commit/d2c2dc0bc33c369369ba748a513fad0c6edcaf6a incorrectly stored this base64 string directly into the `ir.attachment.raw` field without decoding. Because the field is binary, the base64 ASCII text was UTF-8 encoded on the disk, leaving the files unreadable in browsers. This commit introduces a migration script to fix this. For newly downloaded attachment
Original PR description
The Nilvera client returns base64-encoded PDF content from the GET pdf endpoint. A previous change https://github.com/odoo-dev/odoo/commit/d2c2dc0bc33c369369ba748a513fad0c6edcaf6a incorrectly stored this base64 string directly into the `ir.attachment.raw` field without decoding. Because the field is binary, the base64 ASCII text was UTF-8 encoded on the disk, leaving the files unreadable in browsers. This commit introduces a migration script to fix this. For newly downloaded attachments, 35fd6ce handles the decoding. task-6377121 Forward-Port-Of: odoo/odoo#275376
1 change
Enhancements to existing features
The Nilvera client returns base64-encoded PDF content from the GET pdf endpoint. A previous change https://github.com/odoo-dev/odoo/commit/d2c2dc0bc33c369369ba748a513fad0c6edcaf6a incorrectly stored this base64 string directly into the `ir.attachment.raw` field without decoding. Because the field is binary, the base64 ASCII text was UTF-8 encoded on the disk, leaving the files unreadable in browsers. This commit introduces a migration script to fix this. For newly downloaded attachment
Original PR description
The Nilvera client returns base64-encoded PDF content from the GET pdf endpoint. A previous change https://github.com/odoo-dev/odoo/commit/d2c2dc0bc33c369369ba748a513fad0c6edcaf6a incorrectly stored this base64 string directly into the `ir.attachment.raw` field without decoding. Because the field is binary, the base64 ASCII text was UTF-8 encoded on the disk, leaving the files unreadable in browsers. This commit introduces a migration script to fix this. For newly downloaded attachments, 35fd6ce handles the decoding. task-6377121