Daily updates from Odoo
Navigate
Branch
Wednesday, April 23, 2025
69 changes
53 changes
New functionality added to Odoo
Odoo introduces a new Accounting Returns workflow to plan, track, and complete recurring accounting obligations such as tax submissions, payments, and closing tasks. Returns are generated in advance, support multi-company coordination, include automated checks, and become the main place to manage tax closings, improving visibility and reducing missed compliance steps.
Original PR description
1) The Big Picture A 'return' is here defined as some accounting operation to be done at some point in time, with a specific deadline. It can typically consists in some report to submit to the…
1) The Big Picture A 'return' is here defined as some accounting operation to be done at some point in time, with a specific deadline. It can typically consists in some report to submit to the government, some tax payment to make, or whatever closing operation to be done. In Odoo, returns are materialized through account.return objects. Each of them has a specific state, allowing the user to track the current step of the submission process. Returns are auto-generated: Odoo creates them one year in advance, using account.return.type objects as templates. This way, the user can have a complete visualization of the deadlines to come, for example by displaying them in a calendar view. Returns also integrate well in multicompany: when several companies need to do the same return together (typically, submitting a report for tax units or branches), a single return object is created : so the information to track is at a single place, and we avoid useless noise. It also better represents real life: it's a single, global operation to do. The returns are allowed to define checks, through dedicated code in the module. Those checks are automated, and will be run when displaying the returns, notifying the user in case of failure. When a test fails, the user can investigate and fix it, or bypass it if it proves irrelevant. Executed checks are materialized through account.return.check records. Checks are useful to give guidance: in the past, users just had to know what to do and what they could have forgotten or misused ; not anymore. 2) Versatility Each country needs to implement its own returns. Since cases vary a lot between those (including wihtin the same country), we want to give full flexibility on the flows that are allowed. Therefore, a lot of manual customization can be done on the states of each return, the buttons that are displayed on them, the actions those return, and the objects they create. The framework around those features has for now been kept minimal, and things stay very manual to define them. It is possible we make it evolve in the future, once we have a few more concrete examples to generalize. Outside of the purely technical comfort, the current solution should already be fully flexible, and is intended to stay so. 3) Tax Closing The former tax closing mechanism has entirely been revamped to fit into returns. Here are the major differences: - Closing entries are now posted automatically upon submission of the return. If they need be modified by hand for whatever reason, it is still possible by resetting them to draft. - The pdf attachment (and XML for Belgium) are not on the closing entry anymore, but directly on the return. - The carryover external values are created at submission of the return, not when posting the main closing entry anymore. That means resetting the move to draft and reposting it will not recompute the carryover anymore. To do that, a user must reset the return, and re-submit it. - There is no more "Closing Entry" button on the reports: instead we show a button redirecting to the kanban list of returns when appropriate, for discovery of the feature. The returns are now the only point to pilot the tax closing from. Note that, in multicompany, multiple closing entries are still created, like before. But as explained in 1), they are now linked to the same return object. Tax closings have been adapted for every country, so that they still work like they did before. Belgium goes a bit further, as explained in the following point. 4) Multi-VAT simplification When using foreign VAT fiscal positions, it was possible to define different foreign VAT within the same country, for different regions. This feature had been implemented a long time ago, and we never actually got any indication it was of any use. Back in the day, it was supposed to do what branches do better now. Since keeping its support would have required to complexify quite a lot the new returns mechanism, we make here the choice to remove it entirely. All the other cases of foreign VAT fiscal positions are of course still supported like before. 5) Belgium as a proof of concept (cocorico !) As it is, this commit adds multiple return types, wizards and checks to Belgium. The idea is that this localization serves as an example on how the new tools we introduce have to be used. Of course, this is only a first version, and things will probably be added and refined in the upcoming months. 6) What's coming after this commit All other localizations will need to integrate the returns the same way Belgium did. This will be a long process, and will be done in multiple PRs. task-4627315
Enhancements to existing features
The message shown when an employee has no linked contact has been updated to explain the real requirement. This helps users understand that a valid associated contact is needed to use the Documents app from an employee record.
Original PR description
In order to use the Documents app from Employee, you need a valid associated contact. However, the error message when no contact exists was outdated and showed an irrelevant message. This commit updates the error message to indicate that a contact is needed to use the Documents app from the Employee. task-4684139
Generated Belgian payroll PDFs now use clearer, employee-specific file names based on the document type and period. This makes it easier for payroll teams and employees to identify, store, and share payslips, termination holiday documents, 13th month payments, and warrants.
Original PR description
Renaming generated PDF file names for structures: - Termination holidays N/ N-1: "[Employee Name] - Termination Holidays N/ N-1" - Monthly pay : "Payslip - [Employee Name] - [Month] [Year]" - 13th Month : "13th Month - [Employee name] - [Year]" - Warrant : "Warrants - [Employee name] - [Month] [Year]" task - 4582699
Approved approval requests are now protected from deletion, helping preserve important approval history and reduce accidental data loss. Users can also archive approval requests and use a filter to view archived records when needed.
Original PR description
This commit PR
- restriction to delete the requests which are in approved state.
- a filter to view archived "Approval Requests" (and `active` field to model
in order to archive the records)
Task-4639066Users can now receive a notification when they print a test receipt, label, or page through an IoT Box. This improves feedback during device setup and troubleshooting by confirming the test print result more clearly.
Original PR description
In order to display a notification when printing a test receipt/label/page, we need to listen for a lonpolling event returned by the IoT Box. Community PR: [https://github.com/odoo/odoo/pull/206696](https://github.com/odoo/odoo/pull/206696)
Planning managers now have a dedicated Open Shifts menu to quickly view and manage unassigned planning shifts. Reporting views are also organized to make open shift workload easier to review by role and time period.
Original PR description
- The Open Shifts menu is accessible only to planning managers. allowing them to easily view and manage open shifts. - In the Pivot view, only count is visible. Data in both Gantt and Pivot views is grouped by Role. Data in Graph views is grouped by start date: week > role. task-4701080
Point of Sale orders now include a clearer indicator to distinguish refunds from regular sales. This helps local electronic invoicing and settlement processes handle refund orders more reliably and with less ambiguity.
Original PR description
Add is_refund field in pos_order model to differentiate easily between refund and normal orders taskId: 4589361
Employee profiles are easier to use with cleaner skills, resume, organization chart, and gamification screens. The update also streamlines user and employee setup by automatically creating employee records and keeping job titles aligned with job positions when appropriate.
Original PR description
_* = hr_skills, hr_skills_survey, hr_org_chart, hr_gamification, gamification, hr_payroll Purpose: Enhance the user experience for managing skills, resumes, and employee- related features in HR.…
_* = hr_skills, hr_skills_survey, hr_org_chart, hr_gamification, gamification, hr_payroll Purpose: Enhance the user experience for managing skills, resumes, and employee- related features in HR. -------------------------------------------------------------------------------- Specification & Implementation: -------------------------------------------------------------------------------- Skill Timeline: - When no skills are available for an employee, the timeline is now hidden. Tag Placeholder: - Added tag placeholders for clearer user input. Reference. New Resume UX: - Revamped the resume section, ensuring better clarity and accessibility. Certification Field Visibility: - If the 'Category' is not Internal Certification, the certification field is hidden to avoid unnecessary clutter. Social Media Category: - Special UX adjustments for social media-related resume entries. Organization Chart Linkable Text: - Removed the smart button and made the 'Organization Chart' text linkable. - Added action functionality to the text link similar to the smart button. Gamification Empty Screen: - Improved the empty screen experience for gamification with more engaging UX. Badge Kanban: - Improved the kanban view format for gamification, making it visually cleaner and more engaging. Employee Creation on User Creation: - When creating a new user, the corresponding employee record is automatically created in the selected company. Job Position and Job Title Sync: - If the Job Title is empty, it now automatically copies the Job Position. - If the Job Position is later updated and the Job Title was customized, the title remains unchanged. - Task: 4391333
The Indian asset management features are now separated from the broader Indian reports package. This helps keep the reporting app lightweight and free to install while making asset-specific functionality available as its own module when needed.
Original PR description
this commit splits the `l10n_in_asset` module from the `l10n_in_reports` to ensure to stay in one app free when the module `l10n_in_reports` is installed. UPGRADE PR: https://github.com/odoo/upgrade/pull/7558
Point of Sale receipts have been redesigned to make totals, taxes, company details, VAT information, QR codes, and barcodes clearer and better organized. This improves the customer-facing checkout experience across standard POS, self-order, restaurant, loyalty, and local fiscal receipt flows.
Original PR description
`point_of_sale`, `l10n_co_pos`, `l10n_fr_pos_cert`, `pos_loyalty`, `pos_restaurant`, `pos_self_order`, `l10n_cl_edi_pos`, `pos_urban_piper` In this commit: === - Aligned order lines with total, tax line, etc. - font family changed to `monospace` for prices in ordelines. - Removed loyalty point lines. - Adjusted alignment of self-invoicing QR code and loyalty barcode code. - Added company name and address in the footer, moving contact details from the header to the footer. - Organized preset data properly in the header. - Added VAT prefix in ticket if county is in `Europian union VAT` country group. - `Untaxed Amount` text replaced with `Subtotal`. - Order tracking number configured only to show on self-order or kiosk receipt. Task: 4552788 Related PR: odoo/odoo#201105
The Belgian payroll spouse income field now uses a more relevant order and clearer explanations, making it easier for employees and HR teams to select the correct fiscal status. The same wording and default-value changes were applied in the salary configurator to keep the experience consistent.
Original PR description
In BE, the spouse revenue selection field has been improved. The order of the fields in the selection has been changed to be more relevant. Also, the explanation text of the different selection value has been improved and corrected. task-4680475
Administrators will now see a Studio icon even when Odoo Studio is not installed, making it easier to discover what Studio can do. Selecting the icon opens an informational wizard, helping promote Studio features without affecting regular users.
Original PR description
SPECIFICATION: When the Studio module is not installed, display the Studio icon to inform users about its features. Clicking the icon will open the `Odoo Studio` wizard, helping users understand its functionality. This studio icon will only be visible to the admin user. Task-4648879
The contract form now handles missing PDF templates more clearly by hiding unavailable contract sections and showing a helpful message. Users can upload the required PDF templates directly from the signatories area, making contract preparation smoother.
Original PR description
* = hr_contract_sign hr_contract_sign - Updated the widget used for uploading PDF templates. hr_contract_salary - Updated the Signatories tab in the contract form view to enhance UX. - When no PDF templates are present in the database: - Hide the "New Contract" and "Contract Update" sections. - Display a message indicating the absence of PDF templates. - Provide an option for users to upload PDF templates directly. task-4457876
Job applications created through the referral flow now automatically use “Referral” as their source when a referring user is present. This avoids conflicts with the referrer’s own marketing source and makes referral reporting clearer for recruitment teams.
Original PR description
add referral option in source field when there is a user in "referred by user" field "Referral" option will be selected in source field Instead of using the referrer's utm_source_id as the default source_id the 'Referral' source will now be set after new application through Referral. added placeholder for source, medium and Referred User fields Removed the test for ref_user_id since it is no longer dependent on source_id, and added ref_user_id to job_applicant task-4202786
Project-related apps now support task templates in more places, including field service, sales, timesheets, planning views, and appointments. This helps teams reuse standard task setups more consistently across workflows and reduces manual setup effort.
Original PR description
*=industry_fsm,industry_fsm_report,industry_fsm_sale,industry_fsm_stock,timesheet_grid,web_gantt,website_appointment_sale_project See the community PR for more details on the feature. This PR adapts some views and custom JS views to the task templates. --- Community: https://github.com/odoo/odoo/pull/200153 Task-4614548
The Sign app now adapts avatar cards to show when someone is on leave, helping users better understand signer availability. This improves coordination around document signing without changing the core signing flow.
Original PR description
Manually merge together PR to avoid conflicts. Enterprise counter-part. task-4653722 Community: https://github.com/odoo/odoo/pull/207009 Upgrade: https://github.com/odoo/upgrade/pull/7595 Taken from: - https://github.com/odoo/enterprise/pull/82159
The signing interface has clearer field labels and more visible delete icons, making document setup easier to understand. It also fixes strikethrough styling so it only appears where intended, reducing confusion for users completing mandatory fields.
Original PR description
This PR includes the following improvements: - Renamed fields for better clarity. - Updated trash icon colors for improved visibility. - Fixed strikethrough issue. - Ensured strikethrough is only applied when the field is mandatory. task-4656407
Users who receive shared documents can now use embedded document actions, such as marking a file as done, acknowledged, or paid, even without access to the original folder. Empty read-only fields in the document details panel now display cleaner placeholders instead of unusable dropdowns or bare icons, improving clarity and consistency.
Original PR description
It can be useful that users can execute embedded actions on documents even when they have no access to the folder itself. Flows similar to this are then enabled: A user is shared a document (as viewer) and is expected to 1. Do something about it, 2. Use an embedded action to add a "Done"/"Acknowledged"/"Paid" tag. Also * cleaning deprecated `action_folder_embed_action` `groups_ids` parameter. * When fields are empty and readonly, * showing dropdowns that will raise an access error is wrong * just showing icons with nothing next to them looks weird This way, we get a consistent look for the details panel fields (FU of https://github.com/odoo/enterprise/commit/b78e36b16a6b4b157c227d8b222b544f94cb9016). Task-4724349
Knowledge property fields now open in edit mode by default when users have permission to change them, making updates easier without needing an extra menu. Edit and move controls stay hidden until hover, reducing visual clutter and making the Knowledge interface cleaner.
Original PR description
In the community PR, we introduced an edit mode for property fields. Because the Knowledge editor doesn't include a cog menu to toggle this mode, the property field component now defaults to edit mode — provided the user has "write" access to the definition record. To reduce visual clutter, the buttons for editing or moving a property field will be hidden by default and shown only on hover. This helps create a cleaner and more intuitive interface. Task-4610816
Point of Sale preparation screens now capture how long each order and order line takes to prepare and serve. Managers can use the new reporting data to review kitchen or service performance, while completed orders can be cleared automatically to keep displays tidy.
Original PR description
- Added fields in `pos.prep.display`: `auto_clear` and `clear_time_interval` fields to auto-remove completed orders (from "Order status screen"). - Introduced `avg_preparation_time` and `avg_service_time` fields in `pos.order` to track order preparation and service durations. - Introduced `preparation_time` and `service_time` in `pos.order.line` to track preparation and service durations for each order line. - Introduced `pos.prep.order`.`completion_time` field to track total order preparation & service duration. - Updated POS order views to display `preparation_time` and `service_time`. - Added new `preparation_time_report` model & SQL view for preparation time analysis. task-id: 4623457
The Sign app’s enterprise test coverage was adjusted to align with a related change in the shared Odoo platform around avatar cards. This helps keep automated validation consistent and reduces the risk of regressions without changing day-to-day user workflows.
Original PR description
This commit adapts enterprise test to the community PR. Community: https://github.com/odoo/odoo/pull/202702 task-4653722
The Sign app now supports envelopes, allowing one signing template to include multiple documents in a defined order. This makes it easier to manage contracts or document packs that need to be reviewed and signed together, while also improving how completed signed files are stored for future enhancements.
Original PR description
In this commit, we added the envelope feature on `sign.template` by allowing handling multiple attachments in the same template. The changes description and coding choices explanations are described…
In this commit, we added the envelope feature on `sign.template` by allowing handling multiple attachments in the same template. The changes description and coding choices explanations are described below. **SignDocument addition** For achieving this, we created a new class called `sign.document` and made `sign.template` point to multiple of them. This class stores an attachment and holds the order information in the template, as well points to its `sign.item` records, previously done in `sign.template`. All the rendering code got moved from `sign.template` to `sign.document` since it now stores the attachment, making the `sign.template` code a lot cleaner and easying the adaptation of the JavaScript rendering as well. **SignCompletedDocument addition** Before this PR, the storage for the completed document in the `sign.request` was just a single Binary field, and its functions were defined at `sign.template`. In this PR, we added a new model `sign.completed.document` for holding it as moving the document geration over there. This made us keep the simplicity of working with the Binary field (instead of `ir.attachment` directly), we were able to move a function over there making it more maintainable and allowing future improvements such as moving the certificates logic. task-4555838 Co-authored-by: Gabriel Felix <gdpf@odoo.com> Co-authored-by: Ahmad Elmaghraby <alah@odoo.com> Co-authored by: Abdelrahman Fawzy <abdh@odoo.com>
The partner commission process now uses a newer progress-tracking approach when confirming purchase orders in the background. This keeps the system aligned with future platform updates while preserving the existing business workflow.
Original PR description
Rewrite the `_cron_confirm_purchase_orders` to use the new `_commit_progress` method. This is because we would like to deprecate `_notify_progress` in the future.
Field service teams can now capture geolocation when working on tasks, helping managers confirm where work is performed and improve accountability. This supports more accurate time tracking and better visibility into on-site operations.
Original PR description
Odoo lacks built-in GPS tracking for field service tasks, which is a key feature expected by customers, Geolocation on fieldwork helps track where employees are and ensures accurate time tracking, making work more efficient and accountable. task-4546189
Odoo Studio users can now edit Kanban header buttons directly, matching the existing List view experience. Invisible buttons are handled more consistently, making view customization clearer and easier to maintain.
Original PR description
This commit introduce for the Kanban editor a feature already available in List view. As the feature behavior should be identical, the same component has been made to make sure we can continue evolving the feature for both views more conveniently. Invisible buttons can now be edited properly in the Editor, while being hidden by default, and having the same appearance as other invisible elements while 'Show Invisible Elements' is checked. The commit also moves the ButtonProperties component, as it is now used in different editors, and not just in Form view. Tests and tours have been modified, to mock the new route, and adapt to the new way to edit attributes on the button node without having a dedicated modal. Some selectors have also been changed. task-4318325
Payroll administrators can now delete salary structures that are not used in any payslip without first manually removing all related salary rules. This reduces cleanup effort while still preventing deletion of structures that are already used in payroll records.
Original PR description
Currently, deleting unused structures is not straightforward as it requires to delete all attached salary rules first. It would be easier to automatically delete all salary rules of the structure upon deletion. This operation will fail in case the salary structure is used in at least one payslip, which is what we would expect. This PR allows salary structures to be deleted as long as they are not used anywhere. task-4702289
The main brand colors used across the enterprise web interface have been refreshed for both light and dark modes. This improves the visual appearance and helps the product feel more modern and consistent for users.
Original PR description
Before this commit, primary colors were not visually optimal and now it's more modern. community : https://github.com/odoo/odoo/pull/206890 task-4742840
The Swiss payroll module display name was updated to distinguish the ELM Transmission version from another similarly named module. This helps users identify the correct payroll accounting option more easily and reduces confusion in module lists.
Original PR description
- changed `l10n_ch_hr_payroll_elm_transmission_account`'s display name from "Switzerland - Payroll with Accounting" to "Switzerland - Payroll with Accounting (ELM Transmission)" because duplicated. Task-4717615
The Indian payroll demo data now includes a company bank account. This makes sample payroll scenarios more complete and easier to evaluate during demonstrations or testing.
Original PR description
Add demo bank account for the Indian company. task-4668323
Odoo now records the SSL certificate expiration date sent by each IoT Box. This helps users know when a certificate has expired so they can take action before connectivity or trust issues affect operations.
Original PR description
Before this commit, users didn't have any information on the expiration of the ssl certificate of their IoT box (after 60 days). We now send the certificate end date from the IoT Box to the database in order to inform the user if the date is passed. Community PR: [https://github.com/odoo/odoo/pull/206693](https://github.com/odoo/odoo/pull/206693) Task: 4737809
Once a salary offer is fully signed, important fields can no longer be edited. This helps protect contract-related information from accidental changes after agreement and adds a message to make the status clear to users.
Original PR description
This PR includes the following updates: - Made key fields read-only when the offer state is 'fully signed'. - Because, those some fields are related to contract. Task - 4633053
Resolved issues and error corrections
The system now clears stored browser-side data when the database structure changes or a different database is used with the same address. This helps prevent outdated information from causing errors after module, field, or database changes.
Original PR description
…cture changes. Before this commit, the persistent caches were not invalidated when the database structure changed (e.g.: installing/removing modules; adding/removing fields). The persistent caches will return old values, which could lead to errors. This can also happen when using a different database with the same URL (e.g.: in local when developing; or changing the database using `web/database/manager`; or changing the cli parameter `-d<database>,--database<database>`). Now the persistent caches will be invalidated if the database structure is changed, or if a different database is used.
The VoIP call screens now correctly recognize when an incoming caller is already saved as a contact. This prevents users from seeing the wrong action, such as an unnecessary “Add contact” button, and makes call handling clearer.
Original PR description
The incoming invitation interface didn't display contact button althought the caller is already in the contacts. Also, after accepting a call from a caller that is in the contact, a button "Add contact" was dispalyed. This happened because the template was trying to retrieve a `contact` variable but there was not getter implemented for this variable.
This restores a previous fix that makes VoIP testing more reliable by controlling timers and waiting for background notifications. It helps prevent false test failures during development, supporting more dependable VoIP updates without changing user-facing behavior.
Original PR description
Restore b9853be51a16d800b9b131a8c59c6c92a22c9552, inadvertently reverted during refactoring.
IoT box discovery now runs from the user's browser instead of the server, so it searches the same local network the user is on. This helps businesses find and connect the correct IoT boxes more reliably during setup.
Original PR description
Before this commit, the `/iot/discover-boxes` endpoint was called from the backend. This meant that the associated IP was that of the DB, which is usually different from the client network and not the intended behaviour. After this commit, the discover boxes route is called in a client action, and the result passed to the backend. There is a new transient model to keep track of the discovered IoT boxes during the wizard's lifetime, which simplifies the selection logic. task-4687795
The payroll payment advice wizard now lists only the current company's bank accounts in the Company Bank Account field. This prevents employee bank accounts from appearing there and helps payroll users select the correct account for payment advice reports.
Original PR description
Before this commit 'Company Bank Account' on the payment advice report wizard displayed the employee's bank account Now, it will only show company bank accounts. task-4642193
Subscription discount notes were missing from the customer portal view after a recent change to how upsell discount lines are handled. This fix ensures customers can see the relevant discount note information on their subscription page.
Original PR description
Since https://github.com/odoo/enterprise/pull/73438 sale.order.line with display_type=='subscription_discount' are used to easily update the line name when the upsell period is updated. The portal template was not updated. As a result, the line was not displayed on the portal view of subscription. taskid: 4690494
Features or functions removed from Odoo
The manual consumption option on bills of materials has been removed. Manufacturing teams should now assign components to specific operations so work orders show only the materials needed for that step, making shop floor views clearer and more focused.
Original PR description
We no longer support the manual consumption checkbox on the BOM. Instead, the user can use "consumed in operation" to show a stock.move on a specific WO.
This work removes a menu entry from the web client configuration. It likely simplifies the user interface or eliminates an obsolete navigation option, with limited business impact based on the available details.
Code cleanup and technical improvements
Delivery IoT printing now uses a direct server connection through websockets instead of relying on a connected browser session to relay print requests. This makes printing from warehouse delivery flows simpler and more reliable while keeping the user experience unchanged.
Original PR description
The logic to print from the server using longpolling by broadcasting via the client bus was added as a workaround for messages received by the `delivery_iot` model as the server could not directly contact IoT Boxes to print: once a client connected, he automatically performed the request through longpolling ([See](https://github.com/odoo/enterprise/pull/36904)). Since we can use the websocket to print, we replaced this logic to directly do it from the server. Community PR: [https://github.com/odoo/odoo/pull/206895](https://github.com/odoo/odoo/pull/206895) Task: 4649328
Miscellaneous changes
According to [last update from PGCE](https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884&tn=1&p=20241221) and the accounting standards inside it: >3.º Principios contables La contabilidad de la empresa y, en especial, el registro y la valoración de los elementos de las cuentas anuales, se desarrollarán aplicando obligatoriamente los principios contables que se indican a continuación: > >1. Empresa en funcionamiento. Se considerará, salvo prueba en contrario, que la gestión de la empresa
Original PR description
According to [last update from PGCE](https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884&tn=1&p=20241221) and the accounting standards inside it: >3.º Principios contables La contabilidad de la…
According to [last update from PGCE](https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884&tn=1&p=20241221) and the accounting standards inside it: >3.º Principios contables La contabilidad de la empresa y, en especial, el registro y la valoración de los elementos de las cuentas anuales, se desarrollarán aplicando obligatoriamente los principios contables que se indican a continuación: > >1. Empresa en funcionamiento. Se considerará, salvo prueba en contrario, que la gestión de la empresa continuará en un futuro previsible, por lo que la aplicación de los principios y criterios contables no tiene el propósito de determinar el valor del patrimonio neto a efectos de su transmisión global o parcial, ni el importe resultante en caso de liquidación. > >En aquellos casos en que no resulte de aplicación este principio, en los términos que se determinen en las normas de desarrollo de este Plan General de Contabilidad, la empresa aplicará las normas de valoración que resulten más adecuadas para reflejar la imagen fiel de las operaciones tendentes a realizar el activo, cancelar las deudas y, en su caso, repartir el patrimonio neto resultante, debiendo suministrar en la memoria de las cuentas anuales toda la información significativa sobre los criterios aplicados. > >2. Devengo. Los efectos de las transacciones o hechos económicos se registrarán cuando ocurran, imputándose al ejercicio al que las cuentas anuales se refieran, los gastos y los ingresos que afecten al mismo, con independencia de la fecha de su pago o de su cobro. > >3. Uniformidad. Adoptado un criterio dentro de las alternativas que, en su caso, se permitan, deberá mantenerse en el tiempo y aplicarse de manera uniforme para transacciones, otros eventos y condiciones que sean similares, en tanto no se alteren los supuestos que motivaron su elección. De alterarse estos supuestos podrá modificarse el criterio adoptado en su día; en tal caso, estas circunstancias se harán constar en la memoria, indicando la incidencia cuantitativa y cualitativa de la variación sobre las cuentas anuales. > > 4. Prudencia. Se deberá ser prudente en las estimaciones y valoraciones a realizar en condiciones de incertidumbre. La prudencia no justifica que la valoración de los elementos patrimoniales no responda a la imagen fiel que deben reflejar las cuentas anuales. > > Asimismo, sin perjuicio de lo dispuesto en el artículo 38 bis del Código de Comercio, únicamente se contabilizarán los beneficios obtenidos hasta la fecha de cierre del ejercicio. Por el contrario, se deberán tener en cuenta todos los riesgos, con origen en el ejercicio o en otro anterior, tan pronto sean conocidos, incluso si sólo se conocieran entre la fecha de cierre de las cuentas anuales y la fecha en que éstas se formulen. En tales casos se dará cumplida información en la memoria, sin perjuicio de su reflejo, cuando se haya generado un pasivo y un gasto, en otros documentos integrantes de las cuentas anuales. Excepcionalmente, si los riesgos se conocieran entre la formulación y antes de la aprobación de las cuentas anuales y afectaran de forma muy significativa a la imagen fiel, las cuentas anuales deberán ser reformuladas. > > Deberán tenerse en cuenta las amortizaciones y correcciones de valor por deterioro de los activos, tanto si el ejercicio se salda con beneficio como con pérdida. > > 5. No compensación. Salvo que una norma disponga de forma expresa lo contrario, no podrán compensarse las partidas del activo y del pasivo o las de gastos e ingresos, y se valorarán separadamente los elementos integrantes de las cuentas anuales. > > 6. Importancia relativa. Se admitirá la no aplicación estricta de algunos de los principios y criterios contables cuando la importancia relativa en términos cuantitativos o cualitativos de la variación que tal hecho produzca sea escasamente significativa y, en consecuencia, no altere la expresión de la imagen fiel. Las partidas o importes cuya importancia relativa sea escasamente significativa podrán aparecer agrupados con otros de similar naturaleza o función. > > En los casos de conflicto entre principios contables, deberá prevalecer el que mejor conduzca a que las cuentas anuales expresen la imagen fiel del patrimonio, de la situación financiera y de los resultados de la empresa. For item 5, assets and liabilities, income and expenses shall not be offset, unless required or permitted by a standard. Therefore, group 55 accounts should be presented: - On the assets side if they have a debit balance. - On the liabilities side if they have a credit balance. - Without offsetting each other. @moduon MT-9820 @chklop @jco-odoo @rafaelbn Forward-Port-Of: odoo/enterprise#82976
Most tests of the module need to create a sale order, which requires the `group_sale_salesman` at least. Set this group. https://runbot.odoo.com/odoo/error/163649 Forward-Port-Of: odoo/enterprise#83802
Original PR description
Most tests of the module need to create a sale order, which requires the `group_sale_salesman` at least. Set this group. https://runbot.odoo.com/odoo/error/163649 Forward-Port-Of: odoo/enterprise#83802
Can't create a payment for an inactive currency. So activate the currency. https://runbot.odoo.com/odoo/error/161659 Forward-Port-Of: odoo/enterprise#83812
Original PR description
Can't create a payment for an inactive currency. So activate the currency. https://runbot.odoo.com/odoo/error/161659 Forward-Port-Of: odoo/enterprise#83812
It's always useful to keep the original .coda or .xml (for SODA) file that we receive from CodaBox on the created entry. task-none Forward-Port-Of: odoo/enterprise#83643 Forward-Port-Of: odoo/enterprise#81612
Original PR description
It's always useful to keep the original .coda or .xml (for SODA) file that we receive from CodaBox on the created entry. task-none Forward-Port-Of: odoo/enterprise#83643 Forward-Port-Of: odoo/enterprise#81612
The is_invoice_cron flag was set at the start of the cron and only reset at the end. In addition, key processing steps (_process_invoices_to_send and _post_invoice_hook) were done after all subscriptions were processed. If the cron was interrupted, unprocessed subscriptions could be left with is_invoice_cron set to True indefinitely, blocking post-processing. This also caused the post-processing cron to accumulate a backlog of payments to handle. To fix this, subscription processing is now
Original PR description
The is_invoice_cron flag was set at the start of the cron and only reset at the end. In addition, key processing steps (_process_invoices_to_send and _post_invoice_hook) were done after all subscriptions were processed. If the cron was interrupted, unprocessed subscriptions could be left with is_invoice_cron set to True indefinitely, blocking post-processing. This also caused the post-processing cron to accumulate a backlog of payments to handle. To fix this, subscription processing is now atomic: the is_invoice_cron flag is set only when a subscription (or group) is being processed and cleared immediately afterward. The post-processing steps are also moved inside the processing loop. This ensures that only a single group may be left flagged if interrupted, and the flag will be reset when the cron resumes. Forward-Port-Of: odoo/enterprise#83180
### Steps to reproduce: - Create a task in Field Service - Navigate to the product's catalog through the smart button - Add some products to the SO - Filter with 'Added products' - Notice the quantity bar is not shown ### Cause: This is happening as when click on the product smart button we are passing the order_id in the context to get the order lines info https://github.com/odoo/enterprise/blob/6e7525e0e0c2858e028694e9227077b2275d88c5/industry_fsm_sale/static/src/components/pr
Original PR description
### Steps to reproduce: - Create a task in Field Service - Navigate to the product's catalog through the smart button - Add some products to the SO - Filter with 'Added products' - Notice the quantity bar is not shown ### Cause: This is happening as when click on the product smart button we are passing the order_id in the context to get the order lines info https://github.com/odoo/enterprise/blob/6e7525e0e0c2858e028694e9227077b2275d88c5/industry_fsm_sale/static/src/components/product_catalog/kanban_model.js#L21-L26 but if we still didn't create an order for this task order_id will be false, so it won't have an order to fetch its data and will just add the default data where the quantity will be 0 https://github.com/odoo/enterprise/blob/6e7525e0e0c2858e028694e9227077b2275d88c5/industry_fsm_sale/models/sale_order.py#L45-L48 ### Fix: If we have a fsm_task we can fallback on its order_id if order_id is false. opw-4712922 Forward-Port-Of: odoo/enterprise#83396
Currently, a traceback occurs when the user clicks critical path in tasks gantt. To reproduce this issue: 1) Install Project and add the `Use Task Dependencies` group to the current user 2) Open the list view of the project 3) Enable the `Task Dependencies` to any one project 4) Now remove all the start dates from the Planned Date for all tasks 5) Open the Gantt view of the tasks and add a task 6) Refresh the page, and click the `Get Critical Path` button Error:- ``` KeyErro
Original PR description
Currently, a traceback occurs when the user clicks critical path in tasks gantt. To reproduce this issue: 1) Install Project and add the `Use Task Dependencies` group to the current user 2) Open the…
Currently, a traceback occurs when the user clicks critical path in tasks gantt. To reproduce this issue: 1) Install Project and add the `Use Task Dependencies` group to the current user 2) Open the list view of the project 3) Enable the `Task Dependencies` to any one project 4) Now remove all the start dates from the Planned Date for all tasks 5) Open the Gantt view of the tasks and add a task 6) Refresh the page, and click the `Get Critical Path` button Error:- ``` KeyError: 24 ``` https://github.com/odoo/enterprise/blob/c9a753fce85dfb09dc413831993e63c7736d258a/project_enterprise/models/project_task.py#L1544 From the above line, the traceback is occurring because the `path_last_task` will take the value from the sorted_tasks's first record. But we don't have any `planned_date_begin` in any task except the one we added in the Gantt view. So the first task which is `path_last_task` will not execute further because of this, https://github.com/odoo/enterprise/blob/c9a753fce85dfb09dc413831993e63c7736d258a/project_enterprise/models/project_task.py#L1529-L1531 This leads to the above traceback when we compare the value of the `path_last_task` from the `total_time` with the current task. https://github.com/odoo/enterprise/blob/c9a753fce85dfb09dc413831993e63c7736d258a/project_enterprise/models/project_task.py#L1544 We can resolve this issue by taking the `path_last_task` if only the task contains `planned_date_begin`. sentry-6327461743 Forward-Port-Of: odoo/enterprise#80195
The same test is used in multiple modules. Sometimes in the mx localization it was possible that the closing of the session would take a bit longer and the modal wasn't fully closed (though invisible). The modal step in the tour was added when it was planned to remove the 'in_modal' parameter in tour steps and is not really needed for the original purpose of the test. runbot-error: 163628 Forward-Port-Of: odoo/enterprise#83779
Original PR description
The same test is used in multiple modules. Sometimes in the mx localization it was possible that the closing of the session would take a bit longer and the modal wasn't fully closed (though invisible). The modal step in the tour was added when it was planned to remove the 'in_modal' parameter in tour steps and is not really needed for the original purpose of the test. runbot-error: 163628 Forward-Port-Of: odoo/enterprise#83779
In this PR we : -Allow manual input of source tax adjustments -Improve transmission error messages -Add missing translations -Reintroduce work information and skills tab Forward-Port-Of: odoo/enterprise#83730 Forward-Port-Of: odoo/enterprise#81754
Original PR description
In this PR we : -Allow manual input of source tax adjustments -Improve transmission error messages -Add missing translations -Reintroduce work information and skills tab Forward-Port-Of: odoo/enterprise#83730 Forward-Port-Of: odoo/enterprise#81754
Prior to this commit, a utility function `parseUTCString` was being used to format the order's `date_order` property. However, two things have changed since then: 1. The function `parseUTCString` was removed in this `odoo` repo PR: https://github.com/odoo/odoo/pull/189879. 2. The order datetime is now being passed as a DateTime object instead of a UTC string, so there is no need to parse it anymore. As such, when we tried to call that function when printing an Italian receipt, we would get
Original PR description
Prior to this commit, a utility function `parseUTCString` was being used to format the order's `date_order` property. However, two things have changed since then: 1. The function `parseUTCString` was removed in this `odoo` repo PR: https://github.com/odoo/odoo/pull/189879. 2. The order datetime is now being passed as a DateTime object instead of a UTC string, so there is no need to parse it anymore. As such, when we tried to call that function when printing an Italian receipt, we would get a client error and no receipt would be printed. This commit removes the parsing code so that the formatting can be done directly on the order's `date_order` property. opw-4712063 Forward-Port-Of: odoo/enterprise#83547
This error shows up in 18.2, possibly because by waiting more for browser responses #206271 made it more likely that this error would have the time to be sent back down the pipe (also might be a change in chatter impl which makes 18.2 more sensible). However it's likely a global issue: when the tour "click[s] on ticket", it does a full page navigation then triggers the async load of a chatter which can take a pretty long while. It seems like one of the tour teardown steps can cause the loadin
Original PR description
This error shows up in 18.2, possibly because by waiting more for browser responses #206271 made it more likely that this error would have the time to be sent back down the pipe (also might be a change in chatter impl which makes 18.2 more sensible). However it's likely a global issue: when the tour "click[s] on ticket", it does a full page navigation then triggers the async load of a chatter which can take a pretty long while. It seems like one of the tour teardown steps can cause the loading of the chatter bundle to get cancelled, which is then raised as an exception. The error is triggered from `getBundle` while reading the response body, but it just wraps and forwards the error it gets, and swallowing all bundle errors is probably a bad idea... https://runbot.odoo.com/odoo/error/134748 Forward-Port-Of: odoo/enterprise#83871
### Steps to reproduce: - In the settings enable "Rental transfers" - Create a storable product that can be rented put 100 units in stock. - Create a rental order for 10 units of that product planed for the period : [today + 2 days, today + 3 days] and confirm it. - Create a rental order for 10 units of that product planed for the period : [today + 1 days, today + 2 days] and confirm it. - Look at the forecast rentable quantity. #### > It should be 90 but it is 100. ### Cause of the i
Original PR description
### Steps to reproduce: - In the settings enable "Rental transfers" - Create a storable product that can be rented put 100 units in stock. - Create a rental order for 10 units of that product planed…
### Steps to reproduce: - In the settings enable "Rental transfers" - Create a storable product that can be rented put 100 units in stock. - Create a rental order for 10 units of that product planed for the period : [today + 2 days, today + 3 days] and confirm it. - Create a rental order for 10 units of that product planed for the period : [today + 1 days, today + 2 days] and confirm it. - Look at the forecast rentable quantity. #### > It should be 90 but it is 100. ### Cause of the issue: Since c18a7d2dc36d33134c5bdb1569865bd554e04130, the rentable forecast for future dates ignores the `rented_qty_during_period` if the setting "Rental transfers" is enabled. This happens because that rented quantity during period is supposed to be absorbed by the stock forecast: https://github.com/odoo/enterprise/blob/8ea5f4f9a0a907c57844c6274688171193f6a904/sale_stock_renting/models/sale_order_line.py#L132-L134 However, the stock forecast of the 'virtual_available' relies solely on deliveries and receipt happening prior to the start of the renting period. Therefore the rental orders that are planned to start during the renting period should still contribute to the `rented_qty_during_period` in that use case. opw-4552760 Forward-Port-Of: odoo/enterprise#83576 Forward-Port-Of: odoo/enterprise#82172
Increase the field of the rank directly in test instead of going through `_increase_rank` which increases the rank in postcommit. odoo/odoo#205528 Forward-Port-Of: odoo/enterprise#83272
Original PR description
Increase the field of the rank directly in test instead of going through `_increase_rank` which increases the rank in postcommit. odoo/odoo#205528 Forward-Port-Of: odoo/enterprise#83272
16 changes
Resolved issues and error corrections
The unrealized currency gains and losses report now creates adjustment entries with the correct debit and credit amounts when the selected expense account has a default tax. This prevents zero-value accounting entries and helps keep foreign currency revaluations accurate.
Original PR description
**Steps to reproduce:** - Install Accounting - Activate a foreign currency (e.g. EUR) - Make sure there are several rates with today rate different than others - Go to "Accounting / Configuration /…
**Steps to reproduce:** - Install Accounting - Activate a foreign currency (e.g. EUR) - Make sure there are several rates with today rate different than others - Go to "Accounting / Configuration / Accounting / Chart of Accounts" - Add a default tax to "Expenses" account - Create an invoice: * Customer: [any] * Currency: [EUR] (i.e. the foreign currency) * Invoice Date: [a date in the past where the currency rate is different than today] * Invoice Lines: [any] - Confirm the invoice - Go to "Accounting / Reporting / Management / Unrealized Currency Gains/Losses" - Set date filter to "Today" - If there is no adjustement to do, check if the following message is displayed: "You are using custom exchange rates. => Reset to Odoo’s Rate" If it's the case, reset to Odoo's rate (i.e. Today's rate) - Click on "Adjustement Entry" button: * Journal: Miscellaneous Operations * Expense Account: Expenses * Income Account: [any] - Create Entry **Issue:** The values (debit/credit) of the created entry are 0, which is not the case when there is no default tax on the expense account. **Cause:** "_sync_dynamic_lines" is executed on the created entry. If a default tax is set on the expense account, "_sync_tax_lines" is also executed. As only debit and credit values are set on the invoice lines of the entry (neither balance nor amount_currency), the sync method messes up with the value of debit and credit, resetting them to 0 (via multiple recompute). **Solution:** Skip invoice sync. The values computed in "Multicurrency Revaluation Wizard" should be the ones that are used. opw-4664255
This fixes an intermittent automated test failure by adding wait steps before interacting with the PDF signing area. The change helps keep Belgian payroll contract tests reliable without changing the user-facing payroll workflow.
Original PR description
The lack of a wait on the pdf's iframe causes a race condition in `sign/static/src/components/sign_request/document_signable.js`, which *can* cause the PDFIframe's `contentDocument` to be reset in the
setTimeout(() => this.initializeIframe(), 1);
interval as the document ?gets reinitialised?, leading to an error in `initializeIframe`.
I assumed it would be necessary to wait for the iframe's `readyState` to be `"complete"`, however after the iframe triggers I was not able to "see" the frame in any other `readyState`, so seems like an unnecessary complexity after all. Hopefully this doesn't come back to bite...
https://runbot.odoo.com/odoo/error/181583Updating pivot settings in spreadsheets no longer removes the sorting users applied to pivot values. This preserves the expected spreadsheet view after changes such as adjusting filters or domains, reducing repeated manual work.
Original PR description
Steps to reproduce: - insert a pivot into a spreadsheet - add the dynamic pivot somewhere with the formula =PIVOT(1) - right click on the values and sort them - open the side panel - update anything (e.g. the domain) => the sorting is dropped. Since commit 93ffeeefe86, measures are identified with the `id` property, not the name. Task: 4746057 opw-4741934
The sales journal dashboard now shows the remaining amount due for partially paid invoices when 3-way matching is installed, instead of showing the original full invoice total. This helps users rely on the Unpaid and Late dashboard figures for accurate cash collection follow-up.
Original PR description
Currently, the “Unpaid” and “Late” buttons in the sale journal dashboard used the total invoice amount instead of the remaining due amount when account_3way_match was installed. Steps to reproduce: - Install account_3way_match - Create and partially pay an invoice - Go to the dashboard - The displayed amount should reflect the residual, but it shows the full amount This fix restores the expected behavior by using the same logic as the original `_get_open_sale_purchase_query` to compute `amount_total` and `amount_total_company`. opw-4731478
The Luxembourg payroll module no longer tries to load missing setup files during its scheduled payroll data update. This prevents an error when administrators run the update action, improving reliability without changing payroll behavior.
Original PR description
Currently, an error is raised when the system tries to load non-existent XML files via a scheduled action.
**Steps to produce:**
- Install `l10n_lu_hr_payroll` module.
- Navigate to `Settings > Technical > Scheduled Actions`.
- Run action manually for **Payroll: Update data**.
- Observe the error.
`ValueError: FileNotFoundError('File not found: l10n_lu_hr_payroll/data/hr_salary_rule_data.xml') while evaluating 'model._update_payroll_data()'`
Here, `_get_data_files_to_update` method at [1] attempts to load the `hr_salary_rule_data.xml` and `hr_gratification_rule_data.xml` files, which are not present in the codebase.
[1] - https://github.com/odoo/enterprise/blob/809fda39b439edf6259ade445e396e722c1bb53a/l10n_lu_hr_payroll/models/hr_payslip.py#L219-L220
This commit ensures the removal of invalid file references to prevent errors when executing the scheduled action.
Sentry - 6316151728The Belgian payroll DMFA export now correctly accepts ONSS numbers that include formatting such as dots or dashes. This prevents report generation errors and allows companies to produce the required XML payroll report without manually removing special characters.
Original PR description
steps to reproduce: - set up ONSS data about the company in Payroll settings / BE L10N (where ONSS number is consisting of special characters - dots or dashes) - go to Payroll / Reporting / DMFA - create a new DMFA and generate an XML report - it should throw error saying expected `int` (since ONSS is a Char field) fix: - while performing the export, filtered the digits only from these fields task-4502689
This update adjusts a Helpdesk portal test so it waits for the final expected result instead of ending while background page content may still be loading. This reduces false test failures and helps keep Helpdesk releases more stable without changing customer-facing functionality.
Original PR description
This error shows up in 18.2, possibly because by waiting more for browser responses #206271 made it more likely that this error would have the time to be sent back down the pipe (also might be a change in chatter impl which makes 18.2 more sensible). However it's likely a global issue: when the tour "click[s] on ticket", it does a full page navigation then triggers the async load of a chatter which can take a pretty long while. It seems like one of the tour teardown steps can cause the loading of the chatter bundle to get cancelled, which is then raised as an exception. The error is triggered from `getBundle` while reading the response body, but it just wraps and forwards the error it gets, and swallowing all bundle errors is probably a bad idea... https://runbot.odoo.com/odoo/error/134748
Miscellaneous changes
In this PR we add the following wage types: - Complementary LPP - Alimony Deduction - Deduction for prosecution office Forward-Port-Of: odoo/enterprise#83885
Original PR description
In this PR we add the following wage types: - Complementary LPP - Alimony Deduction - Deduction for prosecution office Forward-Port-Of: odoo/enterprise#83885
-- How to reproduce -- Duplicate two or more belgian employees. -- Reason -- The sdworx code check constraint was wrongly single record. -- Fix -- This commit fixes the issue by converting the check to multi records. task-4708324 Forward-Port-Of: odoo/enterprise#83852 Forward-Port-Of: odoo/enterprise#83026
Original PR description
-- How to reproduce -- Duplicate two or more belgian employees. -- Reason -- The sdworx code check constraint was wrongly single record. -- Fix -- This commit fixes the issue by converting the check to multi records. task-4708324 Forward-Port-Of: odoo/enterprise#83852 Forward-Port-Of: odoo/enterprise#83026
Adding a condition to match contry to CO when looking for NIT latam ID type. therwise, adding another ID type named 'NIT' for a different country causes the search to return both, resulting in a traceback. task-4318265 Forward-Port-Of: odoo/enterprise#81216
Original PR description
Adding a condition to match contry to CO when looking for NIT latam ID type. therwise, adding another ID type named 'NIT' for a different country causes the search to return both, resulting in a traceback. task-4318265 Forward-Port-Of: odoo/enterprise#81216
This reverts commit cbcff76a94750a6759fd72d9c952d785e603a974. Fix in community was changing all the xml files generated, whereas it should only have had an impact on the invoice report. opw-4661577 Forward-Port-Of: odoo/enterprise#83783
Original PR description
This reverts commit cbcff76a94750a6759fd72d9c952d785e603a974. Fix in community was changing all the xml files generated, whereas it should only have had an impact on the invoice report. opw-4661577 Forward-Port-Of: odoo/enterprise#83783
Steps: - Install `web_studio` - Enable debug mode - Open Users view - Open studio - Select any users fields (Users Types for example) - Click on More - Traceback Similar fix: https://github.com/odoo/enterprise/pull/50249 https://github.com/odoo/enterprise/pull/60321 This commit add a dialog preventing the users from accessing fields properties. opw-4700432 Forward-Port-Of: odoo/enterprise#83636 Forward-Port-Of: odoo/enterprise#83415
Original PR description
Steps: - Install `web_studio` - Enable debug mode - Open Users view - Open studio - Select any users fields (Users Types for example) - Click on More - Traceback Similar fix: https://github.com/odoo/enterprise/pull/50249 https://github.com/odoo/enterprise/pull/60321 This commit add a dialog preventing the users from accessing fields properties. opw-4700432 Forward-Port-Of: odoo/enterprise#83636 Forward-Port-Of: odoo/enterprise#83415
Can't create a payment for an inactive currency. So activate the currency. https://runbot.odoo.com/odoo/error/161659 Forward-Port-Of: odoo/enterprise#83812
Original PR description
Can't create a payment for an inactive currency. So activate the currency. https://runbot.odoo.com/odoo/error/161659 Forward-Port-Of: odoo/enterprise#83812
Most tests of the module need to create a sale order, which requires the `group_sale_salesman` at least. Set this group. https://runbot.odoo.com/odoo/error/163649 Forward-Port-Of: odoo/enterprise#83802
Original PR description
Most tests of the module need to create a sale order, which requires the `group_sale_salesman` at least. Set this group. https://runbot.odoo.com/odoo/error/163649 Forward-Port-Of: odoo/enterprise#83802
The UAN, PAN and ESIC number fields on the IN employee have a unique constraint. However, they are not set to not being copied upon record duplication, which would cause duplication impossible. This PR fixes the issue by not copying the value of those field upon duplication. task-4708324 Forward-Port-Of: odoo/enterprise#83029
Original PR description
The UAN, PAN and ESIC number fields on the IN employee have a unique constraint. However, they are not set to not being copied upon record duplication, which would cause duplication impossible. This PR fixes the issue by not copying the value of those field upon duplication. task-4708324 Forward-Port-Of: odoo/enterprise#83029
### Steps to reproduce: - Create a task in Field Service - Navigate to the product's catalog through the smart button - Add some products to the SO - Filter with 'Added products' - Notice the quantity bar is not shown ### Cause: This is happening as when click on the product smart button we are passing the order_id in the context to get the order lines info https://github.com/odoo/enterprise/blob/6e7525e0e0c2858e028694e9227077b2275d88c5/industry_fsm_sale/static/src/components/pr
Original PR description
### Steps to reproduce: - Create a task in Field Service - Navigate to the product's catalog through the smart button - Add some products to the SO - Filter with 'Added products' - Notice the quantity bar is not shown ### Cause: This is happening as when click on the product smart button we are passing the order_id in the context to get the order lines info https://github.com/odoo/enterprise/blob/6e7525e0e0c2858e028694e9227077b2275d88c5/industry_fsm_sale/static/src/components/product_catalog/kanban_model.js#L21-L26 but if we still didn't create an order for this task order_id will be false, so it won't have an order to fetch its data and will just add the default data where the quantity will be 0 https://github.com/odoo/enterprise/blob/6e7525e0e0c2858e028694e9227077b2275d88c5/industry_fsm_sale/models/sale_order.py#L45-L48 ### Fix: If we have a fsm_task we can fallback on its order_id if order_id is false. opw-4712922 Forward-Port-Of: odoo/enterprise#83396