Monday, March 2, 2026
30 changes · 19.0
Resolved issues and error corrections
Saudi Arabian invoice PDFs now display large total amounts correctly when using the Fira Mono document layout. This prevents currency symbols, decimals, and long amounts from being cut off at the page edge, making invoices clearer and complete for customers and accounting teams.
Original PR description
### Issue before this commit: When generating an Invoice PDF for a Saudi Arabian company using the Fira Mono font layout, a visual regression occurs in the tax totals section. As a result, when…
### Issue before this commit: When generating an Invoice PDF for a Saudi Arabian company using the Fira Mono font layout, a visual regression occurs in the tax totals section. As a result, when processing invoices with high amounts (e.g. 1,000,000,000.00 SR), the numerical values, including decimals and the currency symbol, are pushed beyond the right margin of the PDF page, rendering them invisible or partially cut off. ### Steps to reproduce the issue: 1. Create and switch to a Saudi Arabian company 2. Go to Settings / Company / Configure document layout 3. Select Text as 'Fira Mono' 7. Go to Accounting / Invoices 8. Select one invoice with a total amount with more than 6 digits 9. Click on the wheel button next to the name of the invoice 10. Then Print / Invoice PDF 11. The total amount is partially exiting the PDF ### Cause of the issue: The layout breakage is caused by the rigid constraint of a fixed column width combined with an inflexible text-nowrap rule. When an invoice contains high-value amounts, the combined length of the bilingual label and the long numerical string exceeds the allocated fifty percent of the page width. Since the container is forced to the right margin and forbidden from wrapping, the PDF rendering engine has no choice but to push the currency and decimal values beyond the physical edge of the document. ### Reason to introduce the fix: Having the full total amount displayed in the Invoice PDF even with high amounts of money. opw-5437320 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Discuss app now uses matching dark mode background colors for breadcrumbs, navigation buttons, and the control panel. This fixes a visual inconsistency and makes the interface look more polished and cohesive for users working in dark mode.
Original PR description
The background color of navbar buttons and breadcrumbs in discuss app differed from that of control panel. This PR aligns and syncs these colors for a consistent UI. | Before | After | |--------|-------| |<img width="467" height="99" alt="image" src="https://github.com/user-attachments/assets/2def30f8-18aa-4399-a5d1-1cdc70b4cd81" /> |<img width="458" height="111" alt="image" src="https://github.com/user-attachments/assets/5578cd25-7686-4543-a8dc-3e0fe5aeb4fc" />| This PR contains backport of #217608 task-[4936733](https://www.odoo.com/odoo/project/1519/tasks/4936733) task-[5487197](https://www.odoo.com/odoo/project/1519/tasks/5487197) Forward-Port-Of: odoo/odoo#250601
When users create or update accounting journals, Odoo now avoids assigning archived default accounts automatically. This keeps journal setup consistent with the normal account selection rules and helps prevent configuration errors.
Original PR description
### Steps to Reproduce: 1. Go to Accounting > Create a journal. 2. Archive the company’s default income/expense or cash diff. accounts. 3. Change the journal type. 3. Observe that an archived account…
### Steps to Reproduce: 1. Go to Accounting > Create a journal. 2. Archive the company’s default income/expense or cash diff. accounts. 3. Change the journal type. 3. Observe that an archived account is assigned by the onchange method. ### Issue: - Prior to saas-18.3, no onchange logic existed for assigning default accounts. With the introduction of the [onchange] (https://github.com/odoo/odoo/commit/334a8161cd2feb092cafedc35d94645900b40518) , archived income/expense or default cash diff. accounts can be assigned to journals. - This creates an inconsistency, as the domain [defined] (https://github.com/odoo/odoo/blob/saas-18.3/addons/account/models/account_journal.py#L70-#L82) for `default_account_id` only returns active accounts. ### Solution: - Since the domain for `default_account_id` returns only active accounts, this commit aims to update the onchange [logic](https://github.com/odoo/odoo/blob/saas-18.3/addons/account/models/account_journal.py#L540-#L551) in order to follow the same restriction, ensuring that only active accounts are assigned thereby preventing inconsistent behavior. OPW-5501539 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-pr Forward-Port-Of: odoo/odoo#246725
The Guatemala localization package now declares the required dependency for city data to load correctly. This prevents setup or update issues when using Guatemala-specific localization features.
Original PR description
**PROBLEM** https://github.com/odoo/odoo/pull/247719 adds the city of guatemala as module data. But the module declaring the model "res.city" isn't listed in the dependencies. opw-5980424
The eLearning homepage now displays course cards correctly when a course description contains its own link. This prevents broken card navigation and ensures visitors can use both description links and the course entry point reliably.
Original PR description
Steps to reproduce: =================== 1. Go to eLearning & select any course. 2. Update the course description with a link inside a paragraph. 3. Go to the website homepage where the course is displayed. 4. Observe that the course card link is broken. Cause: ====== Since the entire course card is wrapped in an anchor tag, adding another anchor tag will break the HTML structure, leading to unexpected behavior. Solution: ========= Modify the course card template to ensure that only the footer section is wrapped in an anchor tag. This way, any links within the course description will function correctly without breaking the overall structure. opw-5383136 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where restarting a support chat bot after reloading the page could show two question prompts at the same time. Customers and support users now get a cleaner, more predictable chat experience when restarting bot conversations.
Original PR description
Since [1], restarting the chat bot after reload could lead to multiple steps being executed at the same time. Steps to reproduce: - Go to the `/im_livechat/support/2` page. - Chat with the support bot until the end of the conversation. - Reload the page. - Click on the restart button. - Two question selections are displayed at the same time. This occurs because the bot starts from the `_toggleChatbot` field's `onUpdate` method. The `restart` method also calls `start` on the chat bot. To fix this issue, the call to `start` is removed from the `restart` method. [1]: https://github.com/odoo/odoo/pull/194399 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-pr Forward-Port-Of: odoo/odoo#250782 Forward-Port-Of: odoo/odoo#250623
This fixes an issue where demo data could fail to load from the command line while the system registry was still being prepared. It helps make setup and testing workflows more reliable without changing normal business features.
Setting an inventory quantity to zero no longer incorrectly assigns the action to the current user in a way that blocks cleanup. This ensures zero-quantity stock records are removed as expected, keeping inventory lists accurate and avoiding stale entries.
Original PR description
Steps to reproduce: - Create a storable product "P1" - Click on Quantity On Hand - Set the quantity to 10 and save - Set the quantity to 0 - Go back to the quant list view by clicking on Quantity On Hand - The quant is deleted by: https://github.com/odoo/odoo/blob/08015c2a15704b30c7815b62612b71b8970e3ac2/addons/stock/models/stock_quant.py#L1076-L1079 - Set the quantity to 10 again and save - Select the quant - Action > Set to 0 Problem: The function `action_set_inventory_quantity_zero` sets the current user on the quant even on inventory mode. This prevents the quant from being deleted when `_unlink_zero_quants` is called. opw-5906681
French invoices now show the VAT-on-debits wording only when it is legally relevant for services. This prevents unnecessary or incorrect VAT wording from appearing on invoices for goods, improving compliance and customer-facing document accuracy.
Original PR description
The VAT exigibility mention on French invoices was incorrectly displayed. - For goods, VAT on debits is the default regime, therefore the mention is not mandatory and must not be shown. - For services, VAT is normally due on payment. The mention “TVA payée sur les débits” must be displayed only when a service VAT uses tax exigibility based on invoice. This commit updates the logic to display the mention only in this specific case and omits it otherwise. Task:5418502
The eCommerce attribute search bar placeholder can now be translated for shoppers using different languages. This fixes a localization gap and helps maintain a consistent multilingual shopping experience.
Original PR description
The placeholder of the search bar for attributes in eCommerce was not translatable, because it was using a Python expression to set its value. This commit replaces the Python expression with a t-attf-placeholder, which allows the placeholder to be translated. opw-5978276 Forward-Port-Of: odoo/odoo#251145
Website menu links for jumping to the top or bottom of a page are no longer changed to point only to the current page. This keeps common header and footer navigation links working consistently across the whole website.
Original PR description
__Before commit:__ Menu items with anchor URLs (e.g., `#my-anchor`) are prefixed with the current page's path. This is correct for page-specific anchors but breaks generic ones like `#top` and…
__Before commit:__ Menu items with anchor URLs (e.g., `#my-anchor`) are prefixed with the current page's path. This is correct for page-specific anchors but breaks generic ones like `#top` and `#bottom`. A menu with the URL `#top` becomes `/current-page#top`, preventing it from functioning as a universal "scroll to top" link. __Cause:__ The server-side logic for processing menu URLs does not differentiate between page-specific anchors and generic anchors like `#top` or `#bottom`, treating all anchor links as belonging to the current page. __Fix:__ In the `save` method, exclude `#top` and `#bottom` from the logic that prefixes anchors with the current page's URL. This ensures these special anchors, typically set on the header and footer, work consistently across the entire website. A new unit test verifies that `#top` and `#bottom` menu URLs are saved correctly without being prefixed. task-5941115 Forward-Port-Of: odoo/odoo#251154 Forward-Port-Of: odoo/odoo#250136
The website SEO dialog now hides the Custom URL option when a page URL cannot actually be customized. This prevents administrators from entering changes that would be ignored, reducing confusion when optimizing pages such as appointments.
Original PR description
This PR hides the "Custom Url" field in the "Search Engine Optimization" when the URL of the current page do not contain any editable slug. Previously, this field could be filled when the URL did not…
This PR hides the "Custom Url" field in the "Search Engine Optimization" when the URL of the current page do not contain any editable slug. Previously, this field could be filled when the URL did not contain any modifiable slug. However, the value was not take into account since the route of the page did not expect slug. Reproduce: With an admin user, activate the website editor on an appointment page. Clicking on "Optimize SEO" in the "Site" dropdown menu, a form containing the "Cutsom Url" field is displayed. This field should represent the current page's URL but with fillable field instead of the editable URL part. In this case, this is not correct as the URL is repeated before and after the fillable field, which does not represent the current URL. Also, the URL is not modified with the value entered in the fillable field. After the fix: The "Custom Url" field must not be displayed when URL does not contain a customisable slug. Task-5114394 Forward-Port-Of: odoo/odoo#231609
Tooltips for method parameters in the API documentation now display correctly and are easier to read. This prevents confusing blank or 'undefined' messages and improves the documentation experience for users.
Original PR description
In api_doc, the method parameters tooltips were broken. This commit fixes them by: - aligning the text to the left - improving the hideTooltip behavior - preventing `undefined` tooltip content from being displayed task-5246075
Grouped list views now give group names the correct amount of space, especially in compact lists without summary columns. This makes records easier to scan and avoids unnecessarily truncated group labels.
Original PR description
Have a grouped list view with no aggregate fields. Before this commit, the colspan of the first `th` in group header rows wasn't optimally computed. These `th` can span to the very last cell…
Have a grouped list view with no aggregate fields. Before this commit, the colspan of the first `th` in group header rows wasn't optimally computed. These `th` can span to the very last cell (excluded), which may contain a cog menu. However, they only spanned to the second to last cell. As a consequence, in a list with only 2 columns, e.g. a handle and a name, the groups' name only got a few px available, and were hence cropped. The issue came from successive reworks of the group header row, leading to the pager being finally moved from its own column (after the last aggregate column), to the group name cell (with ms-auto). The logic is easier now, as a group header row looks like this: - a single `<th colspan="n">` (n >= 1) to display the group name: spans to the first aggregate column excluded or to the last cell excluded if no aggregate (colspan + 1 if rows have selectors) - one `<th colspan="1">` for each aggregate column - optionally one `<th colspan="m">` (m >= 1) for all columns after the last aggregate column - a single `<th colspan="1">` for the potential cog menu (optional dropdown column) opw~5730396 Before <img width="1918" height="471" alt="image" src="https://github.com/user-attachments/assets/8f55322b-1603-42cc-a48b-a2010ff12e25" /> After <img width="1909" height="423" alt="image" src="https://github.com/user-attachments/assets/0bca4865-88a1-424d-a1af-1523dbfa911c" />
This fixes an unreliable automated test for the website URL picker by controlling the wait time instead of relying on real-time delays. It helps reduce random test failures and keeps release validation more stable without changing customer-facing behavior.
Original PR description
Issue: The websiteUrlPicker input has a 250ms debounce. The test was relying on a real 250ms delay to wait it out, creating a race condition that caused non-deterministic failures. Fix: The test now uses `advanceTime()` to advance the time to past the debounce. runbot-[241087](https://runbot.odoo.com/odoo/runbot.build.error/241087)
Purchase receipts no longer show the vendor product name or code twice in the item description. This keeps receipt information clearer for warehouse and purchasing teams when products have vendor-specific references.
Original PR description
Version : saas-18.4+e Steps to reproduce ------------------ Create a product and add a line in the purchase tab with a “Vendor Product Name” and/or a “Vendor Product Code”. Create a purchase order for this product with the right vendor and confirm it. Go to the delivery receipt, the vendor code and/or name are added twice in the description. Why is it happening ------------------ The _compute_description_picking method from stock.move, which is overridden in purchase_stock module, adds the vendor code and name to the description. However, if no description_picking has been set on the product, the description is already defined as the vendor code and name. Solution ------------------ I propose to remove the code and the name from the vendor_reference variable if the original description already contains them. opw-5392855 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242075
Time off allocation counts now include still-valid allocations that began in the previous year. This keeps the allocation number shown on the time off type page consistent with the allocation list users see when they open it.
Original PR description
__ ## Short functional explanation of the error When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee…
__ ## Short functional explanation of the error When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee allocations on the time off type page. ## Reproduction Steps 1. Go to Time off > Configuration > Time off Types and click on any time off type. 2. A smart button Allocations should appear with a number in it. Note the number and click on the button. 3. If no allocation exists yet, create one. Otherwise, click on an already existing allocation. 4. Set the start date of the validity period to any date last year. Set the ending date so that the allocation is still valid as of now. 5. Go back to the Time off type page and look at the number on the Allocations smart button. ### Expected behavior As the allocation we set is still valid, the number shouldn't have changed. ### Unexpected behavior The allocation number has been decreased. However, when we click on the smart button, the same number of valid allocations will show. This creates an inconsistency between the smart button and the allocation page, as the smart button should show the number of valid allocations, and when landing on the allocation page, the results are automatically filtered by validity. ## Origin of the issue The domain of the allocations to take into account when computing the count of valid allocations is defined here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/models/hr_leave_type.py#L297-L304 This doesn't take into account valid allocations that started during the previous year. The inconsistency with the allocation page can be seen here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/views/hr_leave_allocation_views.xml#L40-L46 Where the filter is defined based on today, rather than on the whole year, unlike above. __ opw-5504272 Forward-Port-Of: odoo/odoo#250378 Forward-Port-Of: odoo/odoo#248482
This fixes display problems in Odoo Discuss calls where a blur performance warning dropdown could fail to open and call action dropdown buttons could look incorrect in picture-in-picture mode. Users get more reliable call controls and a cleaner warning display during calls.
Original PR description
task-5263009
Users can now manually adjust the removal date on expiring lot-tracked products without it being overwritten after saving. This prevents unexpected changes in receipt details and helps keep warehouse handling dates accurate.
Original PR description
version : saas-18.4+e Steps to reproduce ------------------ Create a product tracked by lots and enable the expiration date use (use_expiration_date = True). Create a receipt with this product and mark it as to do. Open the stock.move.line list view using the "Details" button on the receipt form and try to modify expiration date, it should modify the removal date due to the compute method. Then, try to modify the removal date and save the modifications. If you reopen the list view, the removal date has been computed again and its value changed. The fix ------------------ We explicitly set the readonly field to False for the removal_date field from the stock.move.line model in product_expiry. opw-5368007 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241659
This update fixes an error in the Spanish Profit & Loss reports where specific accounts (7950 and 7957) were incorrectly placed in the wrong section. The change aligns with official Spanish tax documentation, ensuring accurate reporting for non-SME fiscal localization packages. This ensures compliance with Spanish tax regulations.
Original PR description
In the Profit & Loss reports, accounts 7950 and 7957 were incorrectly shown in section 10 instead of section 6 These accounts appear only for non-SME fiscal localization packages According to the official Spanish tax documentation, these accounts should belong to section 6 and not section 10: https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884 opw-5363664 Forward-Port-Of: odoo/enterprise#108820 Forward-Port-Of: odoo/enterprise#107949
This update fixes an issue where newly hired employees were incorrectly receiving their private email address as their work email. The change ensures that the employee's work email is properly cleared when the contract is signed, preventing data duplication and maintaining accurate employee records. This improves data consistency and reporting.
Original PR description
**Steps to Reproduce:** 1. Send an offer to an applicant. 2. The applicant submits their details via the salary configurator and enters their private email in the Email field. 3. Once the offer and contract are signed, an employee record is created in Odoo. 4. In the created employee record, the `work_email` field is populated with the email entered in the salary configurator. This same value is also present in `private_email`, which is correct. **Reason:** - The email entered in the salary configurator is stored on the partner and represents the applicant's private email. - The employee's `work_email` field is linked to the partner's email via compute and inverse methods, causing it to inherit the private email value when the employee record is created. **Solution:** - Explicitly clear the employee's work_email field when the applicant sign. task: 5502797 Forward-Port-Of: odoo/enterprise#108933 Forward-Port-Of: odoo/enterprise#106974
This update resolves a minor issue within the Urban Piper settings where the arrow button was not functioning correctly. The fix ensures that the arrow is properly embedded within a button element, allowing users to navigate to the correct settings. This improves usability and prevents a potential frustration for users.
Original PR description
In the settings, under the Urban Piper section, the arrow was not clickable. This is because the arrow was not inside a button tag. task: 5972833
This update simplifies the salary simulation process by hiding temporary offers from the user interface. These offers are automatically removed after a month by a scheduled task, so this change prevents confusion and a cleaner experience for users. It ensures the backend calculations continue to function correctly.
Original PR description
The salary simulator creates temporary offers to compute salary configurations. These offers must still exist for backend computations, as the configurator relies on them when updating results. Simulation offers are already cleaned up by a cron job after one month, so this change simply hides them from the list view to avoid user confusion. task: 5498873
This update fixes an issue with invoices generated for SII (Chile's tax authority) by ensuring the correct XML tags are used for withholding information. The change updates the DTE template to align with SII's specific formatting requirements, preventing invoice rejection. This ensures compliance with Chilean tax regulations.
Original PR description
Link to SII API Documentation: https://www.sii.cl/factura_electronica/formato_dte.pdf Problem: The DTE template was using incorrect XML elements for withholdings when confirming an invoice with SII. This fix replaces: ImptRetOtrMnda -> ImpRetOtrMnda ValorImpOtrMnda -> VlrImpOtrMnda so the generated DTE matches SII specifications. OPW-5437484 Forward-Port-Of: odoo/enterprise#105152
This update fixes a problem where archived employee appraisal dates persisted, causing conflicts when updating appraisal plans. The change ensures archived employees no longer appear in appraisal calculations, preventing date errors and improving the accuracy of appraisal settings. This ensures a smoother experience for managing appraisals across the company.
Original PR description
**Steps to reproduce:** Based on this feedback https://www.odoo.com/odoo/project.task/5270281 companies with archived employees face an issue when they try to toggle Appraisals Plans from Appraisls -> Configuration -> Settings -> Appraisals Plans **Issue:** The propblem is that when employees with next appraisal date are archived, their next appraisal date is not cleared which leads to past date conflicts upon trying to set the next appraisals dates for all the employees (which is done through toggling the Appraisals Plans checkbox) **Solution:** - Unset the next appraisal date upon archiving an employee - exclude archived employees from _compute_next_appraisal_date method Task: 5354002 Forward-Port-Of: odoo/enterprise#108990 Forward-Port-Of: odoo/enterprise#100437
This update ensures the cash drawer opens automatically when the cash details popup is accessed in the Italian Point of Sale (POS) system. Previously, this functionality was missing, causing a discrepancy between the fiscal printer and cash drawer behavior. This fix provides consistent cash drawer operation for Italian users.
Original PR description
When opening the cash details popup the cash drawer should be opened. It was not the case for the Italian fiscal printer. Steps to reproduce: ------------------- * Setup a Italian fiscal printer with cash drawer support * Open PoS * Open the cash details popup > Observation: The cash drawer does not open * Try to close the PoS session * Open the cash details popup > Observation: The cash drawer opens Why the fix: ------------ The cash drawer opening function was simply not called opw-5391094 Forward-Port-Of: odoo/enterprise#109057 Forward-Port-Of: odoo/enterprise#107987
This update reverts a recent change to the name of the "Create Draft Entry" button on payslips to "Validate". This change ensures consistency and clarity for users when finalizing payroll processing, improving the overall user experience.
Original PR description
This commit reverts the payslip validation button name from "Create Draft Entry" back to "Validate". TaskID-5964329
This update fixes a technical issue preventing payruns from being created correctly for employees using the Hong Kong localization. The problem stemmed from a missing function name within the HK localization setup, which caused an error during payrun generation. This fix ensures payruns function as expected for all employees, regardless of their location.
Original PR description
In the big commit adding eMPF to the hk localization, a function was miss named and was causing an error when trying to create a payrun. Steps to reproduce: - Install belgian localization - Install HK localization - Select the belgian company - Create a payslip for a belgian employee (works fine) - Create a payrun and select the same employee from the list - Get an error In this commit we fix the naming of the function and everything goes back to working. Task: 5960503
This update resolves an issue where the 'Reset Selected Work Entries' button in the work entry Gantt view would fail when no employees were selected. The fix prevents a key error and ensures the button functions correctly, improving usability. The change addresses a technical bug identified through monitoring and testing.
Original PR description
This error occurs when clicking the `Reset Selected Work Entries` button while there are no employees in the work entries. Steps to reproduce: - Install `hr_payroll` module - Payroll > Work Entry >…
This error occurs when clicking the `Reset Selected Work Entries` button while there are no employees in the work entries. Steps to reproduce: - Install `hr_payroll` module - Payroll > Work Entry > Remove `Active` Filter - Select any cell and click on the reset button Traceback: `KeyError: 'employee_id'` This error occurs when the `Reset Selected Work Entries` button is clicked without an employee, causing `employee_id` to be missing at [1]. Solutions: - Raise a validation error when no employee is selected and the `Reset Selected Work Entries` button is clicked. - Fix the error that occurs when clicking the `Set` button to add or replace a work entry. - Fix the error that occurs when the `Active` filter is enabled and the `Reset` button is clicked. ``` Missing Record Record does not exist or has been deleted. (Record: hr.employee(2,), User: 2) ``` [1]: https://github.com/odoo/odoo/blob/4949a6272691c781d5ab5a8b06f88f58d5cea4df/addons/hr_work_entry/wizard/hr_work_entry_regeneration_wizard.py#L116 sentry-7140947833
This update ensures the 'Request Signature' menu item consistently appears on form views when a chatter is present. Previously, the system wasn't reliably checking for chatter, leading to the menu item sometimes being missing. This change improves the user experience by guaranteeing the signature option is available when needed.
Original PR description
****Behavior:**** **Current:** When selecting the cog menu on certain forms, the request signature item doesn't always show even though it should. The expected behavior of this menu item is to appear only on form views with a chatter, but the way the chatter's presence was verified is inconsistent. **Solution:** On form views with a chatter, we can check its presence directly from the viewArch using the selector from the compiler registry. **Steps to reproduce:** From Timesheets: - Go to Timesheets - Open a task - The cog menu will not contain "Request Signature" From Project: - Go to Project - Select a project and open a task - The cog menu will contain "Request Signature" opw-4817423 Forward-Port-Of: odoo/enterprise#108169 Forward-Port-Of: odoo/enterprise#97401