Daily updates from Odoo
Monday, August 25, 2025
25 changes · 18.0
Resolved issues and error corrections
When an individual customer is linked to a company, their assigned pricelist now stays synchronized with the company's pricelist. This prevents quotations from switching to the wrong pricelist when users change the customer between a company and its related contact.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create an individual partner; 2. assign them a pricelist A; 3. create a new company partner for them; 4. create a new pricelist A & sort it on top; 5. open a…
Versions
--------
- 18.0+
Steps
-----
1. Create an individual partner;
2. assign them a pricelist A;
3. create a new company partner for them;
4. create a new pricelist A & sort it on top;
5. open a new quotation;
6. set new company as customer;
7. change customer to the individual partner.
Issue
-----
The quotation's pricelist changed from B to A. The pricelist used for the individual should be identical to the one used for their company.
Cause
-----
Commit de302c2d36305 added the `specific_property_product_pricelist` field to `res.partner`, as the way company-dependent fields are managed was changed on the database-level.
Commit 67cf577cd0a0 added the `_company_dependent_commercial_fields` method to enable syncing company-dependent commercial fields. The base method fetches all fields retrieved via `_commercial_fields`, and selects those whose `company_dependent` attribute is `True`.
In previous versions, the `_company_dependent_commercial_fields` override in `product` adds `property_product_pricelist`, as this field does not have the `company_dependent` attribute set, but it behaves as a company-dependent field. Starting from 18.0, the override adds `specific_property_product_pricelist` instead, which does have the `company_dependent` property set.
As a consequence, when `_company_dependent_commercial_sync` gets called, it does not sync the `specific_property_product_pricelist` as it's not included in the `_commercial_fields` override, nor does it sync when retrieving it from `_company_dependent_commercial_fields`, as it skips the current company, assuming the field was already handled by `_commercial_sync_from_company`: https://github.com/odoo/odoo/blob/c40760244d128cb57e11a233e89a93dd92b8fb56/odoo/addons/base/models/res_partner.py#L667-L668
Solution
--------
- Move `specific_property_product_pricelist` to `_commercial_fields`
- This enables it to sync in `_commercial_sync_from_company`
- Remove the `_company_dependent_commercial_fields` override
- `property_product_pricelist` shouldn't get synced by itself
- `specific_property_product_pricelist` is already included by the base method
opw-4988736The Employee app resume section now keeps the skills table within its intended area, even when a resume entry contains a very wide table. This prevents resume content and action buttons like Add and Delete from being hidden, making employee profile editing more reliable.
Original PR description
Steps to reproduce:
1- Go on employee app
2- Click on resume section
3- Click on Add on resume tab
4- Put on description a big table with at least 20 columns
5- Save
The resume table and the buttons "add", "delete" with be hidden by the skill table.
Reason:
The skill table element is too wide
Solution:
The skill table's width is fixed and is contained in resume section element
task-4881917
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-prThis fix prevents errors when creating, updating, or validating work entries for employees with fully flexible schedules. It helps HR teams process these entries reliably when no fixed working calendar is assigned.
Original PR description
When we validate/write/create a work entry for an employee with a fully flexible working schedule, we can encounter a traceback when trying to call `_attendance_intervals_batch` on a non-existing calendar. To rectify this issue, we continue in the loop when no calendar is set. opw-4979974 opw-4968312
Resetting a refused or cancelled Extra Hours time off request now correctly recreates the related overtime entry. This keeps employees' extra hours balances accurate when time off requests are changed and reset.
Original PR description
When refusing or cancelling a time off request of type Extra Hours, the linked hr.attendance.overtime record was hard deleted. As a result, if the leave was later reset, the extra hours were not deducted again. This fix ensures that a new hr.attendance.overtime record is recreated when resetting the leave, restoring the correct impact on the employee's extra hours balance. Related task: 4966880. 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
The Job Position form now shows eligible recruiters and interviewers even when no company is selected. This prevents hiring teams from seeing empty selection lists and makes recruitment setup smoother in multi-company environments.
Original PR description
In the Job Position form, the 'Recruiter' and 'Interviewers' fields were empty when no company was selected. This was due to the static domain using 'company_id' directly without taking into consideration that company_id can be False. This fix introduces computed domain fields (, ) that dynamically adapt based on the selected company. If a company is set, users belonging to that company are shown. If not, only internal users are listed regardless their companies. Related task: 4926154. 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#217884
This fixes an error that could appear after merging contacts and then selecting multiple contact records. Peppol-related contact information is now calculated separately for each contact, keeping contact management workflows from being interrupted.
Original PR description
**Steps to Reproduce:** 1. Install `account_peppol` and `contacts`. 2. Open the Contacts app (list view). 3. Select any two contacts and click on "Merge" from the "Actions" menu. 4. Open any of the merged contacts in form view. 5. Close the form view and click on "Add a line". 6. Select multiple records. **Error:** ValueError - Expected singleton: res.partner(11, 9) **Cause:** The method `_compute_available_peppol_eas` accesses `self.available_peppol_eas` directly. When multiple `res.partner` records were involved, it will raised a singleton error. **Fix:** Loop over each partner to compute `available_peppol_eas` for each. This prevents the singleton error when multiple records are processed. sentry-6807787390
The Italian localization now uses the updated €100 threshold for the VP7 line in VAT tax reports, replacing the previous €25.82 amount. This keeps tax reporting aligned with current requirements and reduces the risk of incorrect report values.
Original PR description
While implementing the modulo tag of the tax report xml export, it came to light that the vp7 line of that report which previously used a 25,82€ threshold has been changed for one at 100,00€. This commit adapts the amount across the module. --- Enterprise PR: https://github.com/odoo/enterprise/pull/86642 task-4826511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216887
Fixes an issue where deleting a bank account from a customer could trigger an error and interrupt the workflow. The change prevents invalid empty duplicate-bank-account data from being processed, making customer bank account management more reliable.
Original PR description
Currently an error occurs when we try to remove bank accounts from a partner. **Steps to reproduce:** - Install `accountant` (with demo), Go to customers and create a new one with random name. -…
Currently an error occurs when we try to remove bank accounts from a partner.
**Steps to reproduce:**
- Install `accountant` (with demo), Go to customers and create a new one with random name.
- Under accounting tab add a new bank account with an acc number, bank and save.
- Now remove the bank account record.
**Error:**
`AttributeError: 'NoneType' object has no attribute 'origin'`
**Cause:**
- The error occurs because of the SQL query [1] returning None values in the `id2duplicates` dict, somewhat like `{1: [None]}`, this caused the browse [2] to assign `None` to the `duplicate_bank_partner_ids`.
- While recording snapshots for diff checking in onchange system the none value will be stored like`None: {display_name:{}}` and when the line [3] tries to access `id_.origin` where `id_` is None and causes the error.
**Solution:**
- Added a condition which makes sure null values are not accounted. (The Join is added to makes sure that the correct `partner_id` is fetched.)
[1]: https://github.com/odoo/odoo/blob/04ba4e4a51843701dd42a3f0243add50b3ac0c79/addons/account/models/res_partner_bank.py#L71-L85
[2]: https://github.com/odoo/odoo/blob/04ba4e4a51843701dd42a3f0243add50b3ac0c79/addons/account/models/res_partner_bank.py#L88
[3]: https://github.com/odoo/odoo/blob/04ba4e4a51843701dd42a3f0243add50b3ac0c79/addons/web/models/models.py#L1173
sentry-6748249363
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prUsers returning from editing a shared project task are now taken back to the correct project instead of another project's task board. This prevents confusion when multiple shared projects are available and keeps the portal navigation aligned with the task being edited.
Original PR description
Steps to Reproduce: ------------- 1. Install project and create two projects and tasks. 2. Share both projects with edit access. 3. Edit a task from the portal view (Back to edit mode) then click the (back to tasks) button. 4. Instead of the correct project the page redirects to the another project kanban view. Issue: -------------- - When redirecting to a task from project sharing (edit mode – task form view) it redirects to a different project’s kanban view instead of the actual project. Cause: ------------- - In the portal view the URL is hardcoded with `id=1` instead of dynamically using the correct project ID. Fix: --------------- - pass the correct `project_id` in the URL instead of using a hardcoded value. The issue occurred from this PR-https://github.com/odoo/odoo/pull/174648 task-5031632
New recruitment candidates and applicants now create linked contacts using the candidate's name instead of falling back to the email address. This helps recruiters and other users identify people correctly in contact records, while related point-of-sale test updates help keep automated checks reliable.
Original PR description
after this commit when a candidate or applicant is created, the corresponding contact should display the candidate’s name correctly, rather than defaulting to the email address. task-4687196 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Check validation now compares payments using the check's effective payment date instead of the operation date. This prevents valid customer receipts with already-issued checks from being incorrectly blocked or warned.
Original PR description
When validating check movements, the system was comparing the operation date against date, which caused false warnings in scenarios such as customer receipts that include checks already issued with…
When validating check movements, the system was comparing the operation date against date, which caused false warnings in scenarios such as customer receipts that include checks already issued with past payment dates. This commit changes the validation to use payment_date, which is the correct reference for ensuring that the payment operation is not prior to the last effective payment of the check. Description of the issue/feature this PR addresses: When validating check movements in `l10n_latam_checks`, the system compares the operation date (`date`) of the last check operation against the current payment date. This generates false blocking warnings in cases such as customer receipts, where checks can be received with past payment dates (already issued and ready to be deposited). Current behavior before PR: The validation uses `last_operation.date` for comparison. If the last operation's `date` is greater than the current payment's date, the system raises a warning, even if the check's `payment_date` is already in the past and valid. Desired behavior after PR is merged: The validation uses `last_operation.payment_date` instead of `last_operation.date`. This ensures that the comparison is consistent with the effective payment date of the check, avoiding false positives when processing checks in customer receipts. Video: https://drive.google.com/file/d/1Ro2NvKGK_uRyBovMuNeA395y-6MUbzu5/view --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Restricted website editors can edit permitted website content without triggering an access rights pop-up when saving. The change prevents editor-only metadata from being added to page elements that restricted users are not allowed to modify directly, improving the editing experience while preserving permissions.
Original PR description
Steps to reproduce: - Install website_event, with demo data - Change Marc Demo's website access to "Restricted Editor" - Log into Marc Demo and visit an event's website page e.g."Live Music Festival"…
Steps to reproduce: - Install website_event, with demo data - Change Marc Demo's website access to "Restricted Editor" - Log into Marc Demo and visit an event's website page e.g."Live Music Festival" - user is able to edits is footer contents,make a change - try to save. Observation: A pop-up for access right appears Cause: after this fix odoo/odoo@11e94cb059901ffc3c521a431259d627beb69e1e , we allow website to be editable for restricted user if, user can modify other models, which are editable from website,like event. And, if website is editable, we brand the ir.ui.views nodes, https://github.com/odoo/odoo/blob/3ceb04bf2aa90442430f5bf321bac4a9d872752c/addons/website/models/ir_qweb.py#L93-L94 but restricted user do not have access to ir.ui.view model, causing access issue Note: if a node is branded, that means it is editable Fix: Brand ir.ui.view nodes only if user has full access to website editor opw-4659114 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221202
Duplicating a warehouse now also duplicates its Point of Sale operation type, matching the behavior of other warehouse operation types. This prevents missing PoS logistics settings on copied warehouses and reduces manual correction after duplication.
Original PR description
## Short functional explanation of the error When duplicating a warehouse, if it has an PoS operation type, this operation type will not be duplicated. On the other hand, all other operation types…
## Short functional explanation of the error When duplicating a warehouse, if it has an PoS operation type, this operation type will not be duplicated. On the other hand, all other operation types will be duplicated. ## Reproduction Steps 1. Make sure PoS and inventory are well installed. 2. Go to inventory. 3. Click on configuration, then warehouse. 4. Select a warehouse, click on action, then duplicate. 5. Click on configuration, then on Operation Types. ### Expected behavior We should be able to see 2 instances of PoS operation type: one for the original company, and one for the copy. ### Unexpected behavior There's only one instance of PoS operation type, which is related to the original company. ## Origin of the issue PoS operation type is a model inherited from stock.warehouse, and no copy method was defined. Therefore, upon duplication, the copy method of the original stock.warehouse was called, leading to issues with the field created in the inherited version. __ opw-4991271 Forward-Port-Of: odoo/odoo#222694
Fixes Turkish e-invoice and e-archive XML data so Nilvera no longer rejects invoices when no tax office is set. Also corrects the displayed country label from the misspelled “Turkyie” to “Türkiye,” reducing validation failures and confusion for users.
Original PR description
### Description of the issue/feature this PR addresses: Nilvera rejects E-Archive invoices if extra fields are present under `PartyTaxScheme` when no tax office is set. In addition, the…
### Description of the issue/feature this PR addresses:
Nilvera rejects E-Archive invoices if extra fields are present under
`PartyTaxScheme` when no tax office is set. In addition, the
`invoice_edi_format` selection name for TR was incorrect.
### Current behavior before PR:
When generating E-Archive invoices, Odoo includes extra nodes such as
`registration_address_vals`, `registration_name`, and `company_id`
under the `PartyTaxScheme` element. Nilvera’s validation fails if
these nodes are present while no tax office is configured. At the same
time, the TR value for `invoice_edi_format` was using the wrong name,
which caused inconsistencies. These issues result in blocking
validation errors on Nilvera’s side and prevent the invoices from
being accepted.
### Desired behavior after PR is merged:
After this fix, the `PartyTaxScheme` is cleaned up only to include the
expected XML structure:
```xml
<cac:PartyTaxScheme>
<cac:TaxScheme>
<cbc:Name>TAX OFFICE NAME</cbc:Name>
</cac:TaxScheme>
</cac:PartyTaxScheme>
```
And the invoice_edi_format selection name for TR will be corrected
to display Türkiye rather than Turkyie.
task-5017223
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix stops users from selecting the Shop Floor screen as their default home action. It prevents a login-time error that could appear when that screen opened before the system had loaded the current app context.
Original PR description
**PROBLEM** In debug mode, we can change the default home action of a user (the action he sees when logging in). When the action `action_mrp_display` is set as the home action, there is a traceback after logging in. **STEP TO REPRODUCE** 1. Go in debug mode 2. Change the home action of a user to the 'Shop Floor' action (in the user form, in the preference tab). 3. log out, and log in with this user. 4. a js traceback should appear. **CAUSE** On the js side, the Shop Floor action uses the `menu` service to get the name of the current app. when accessing the 'Shop Floor' action as a home action, the `menu` service app is set after the action is rendered, so the current app during rendering is undefined. **FIX** Prevent the user from selection the 'Shop Floor' action as a home action (we already do this for action that doesn't work as home action). opw-4926317
Installing the Belgium Accounting localization now continues successfully even if a referenced demo account tag was previously deleted. This avoids a setup failure in demo-data scenarios and makes localization installation more reliable for affected users.
Original PR description
Currently, installing the Belgium Accounting localization fails with an error, if the user has deleted referenced demo account tags. **Steps to reproduce:** - Install the Accounting app. - Delete the "Demo Capital Account" account tag. - Install the Belgium Accounting localization (`l10n_be`). **Error:** `ValueError - External ID not found in the system: account.demo_capital_account` At [1], if the `account.demo_capital_account` is not found, it raises an error if the external ID is missing. This commit prevents the error by explicitly passing `raise_if_not_found=False` and skipping the tag if not found. [1] - https://github.com/odoo/odoo/blob/71d1c9a4bef1c29485e3b0390713a9301ad6db4f/addons/l10n_be/demo/account_demo.py#L13-L19 sentry-6776341713 Forward-Port-Of: odoo/odoo#221227
Invoices created after portal subscription payments now trigger the required electronic document signing process. This restores compliance for localizations such as Mexico, where government-signed invoices are required after payment.
Original PR description
## Steps to reproduce: - Make sure the Mexican localization is installed and properly set up for signing invoices - Make sure the payment providers are set up (it can be demo, the customer uses…
## Steps to reproduce: - Make sure the Mexican localization is installed and properly set up for signing invoices - Make sure the payment providers are set up (it can be demo, the customer uses Stripe but it can be reproduced with any - Make sure the online payment setting is active - Go to subscription module - Do a new order - In other info, add the online payment checkmark - Confirm the order - Generate the payment link or go into the preview - Make the payment ## Issue: The invoice is generated, but is not signed by the government (no edi is generated), as it used to. ## Cause: The flow works in 17.0 but for the wrong reason. Before this [commit](https://github.com/odoo/enterprise/pull/70562), two mails were sent. And during the chain of triggers of the second email, edi document was generated with `orders._send_success_mail(tx.invoice_ids, tx)`. https://github.com/odoo/enterprise/pull/70562/files#diff-8778c8dce7ca1c24de19f26f11ac0c5410c6c2a4d121c3815682a2323cbb09c2L177 After the removal of the method, it should still work since we still have `payment.transaction._send_invoice` which calls `_generate_and_send_invoices` and should trigger the sub calls necessary for generating the edi stuff. But in `_create_or_link_to_invoice`, we check that the transaction has no invoice_ids linked (make sense with the name of the method). However, at this stage, we already created the invoice in https://github.com/odoo/enterprise/blob/2f3698b250092ad376344e959d46bdc0eebf1a81/sale_subscription/controllers/portal.py#L419-L424 And unfortunately, it will be effectively possible to "let the post process of transaction create" the invoices only in Master (the code is not ready yet). For now it would be too risky for a stable version to make such change. ## Solution: We ensure EDI documents are generated whenever a `subscription_action` is set. To achieve this, modify the `_post_subscription_action` hook to call `_subscription_post_success_payment` for any `subscription_action`, including `assign_token`. From `_subscription_post_success_payment`, we can call `_generate_and_send_invoices` on any invoice that has an EDI associated with it, which sends & signs the required EDI documents. opw-4648189
The contract offer screen now hides the signature request button when the current user cannot access any related signature request. This prevents users from clicking a button that would lead to an error, while still allowing authorized users such as signing administrators to use it.
Original PR description
Before this PR, when logged in as a different user from the one responsible for counter-signing the contract, the smart button still showed, and clicking on it caused an error. This PR fixes that, by hiding the smart button when there are no accessible signature requests. Note that sign admins will still be able to see the smart button; users with access to the signature request. Task-4966129
Fixed an issue where disabled Urban Piper delivery providers were automatically re-enabled when a cashier returned from the backend to continue selling. Provider availability is now kept consistently in the backend, preventing unwanted online status changes and avoiding unnecessary update requests.
Original PR description
Steps to reproduce: - Configure urban piper in pos.config - Open Register - You could see a notification that providers are online on your config - Disable any one provider. - Go to backend. - Click Continue Selling Issue: - Despite disabling the provider, all providers get enabled as soon as we resume the pos.config Cause: - Not updating togglestate properly while going to the backend. - Unnecessary api request when resuming session. Fix: - Not removing the toggleState from local storage as the user go to the backend - When the user resumes the session, restrict api request for location update. - Remove dependency from local storage and handling all through backend only. task- 4962969
Portal users viewing helpdesk tickets with logged timesheets will no longer see an unrelated Timesheets breadcrumb. This keeps ticket navigation clearer and avoids sending users toward the wrong portal section.
Original PR description
**Steps to reproduce:** 1. Install 'Helpdesk Sale Timesheet' and 'Website' modules. 2. Create a helpdesk ticket and add timesheets to it. 3. Go to the portal view of helpdesk tickets. **Issue:** If the ticket contains timesheets, the "Timesheets" breadcrumb appears in the portal ticket view. **Cause:** The reason the timesheet variable is used in the hr_timesheet portal template is because it makes the condition evaluate to true, which is why the breadcrumb for Timesheets is displayed. **Fix:** Renamed the loop variable in `t-foreach` to avoid shadowing the `timesheet` variable from the outer context. task-4744294 Forward-Port-Of: odoo/enterprise#85411
Product weight and volume information retrieved from barcode lookup is now properly saved on the product record. This helps keep product data complete and avoids missing logistics details after lookup.
Original PR description
Before this commit: ------------------------- - The weight and volume fields were not present in the main product form, so even when data was retrieved, it was not stored in the product record. After this commit: ----------------------- - We have added the weight and volume fields to ensure that whenever data is fetched, it is properly stored in the product record Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/231155
Steps to reproduce: -------------------------- 1. Install `l10n_co` and activate spanish(es_419) language 2. Configure [DIAN Environment](https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/colombia.html#electronic-invoicing-credentials-and-dian-environment) by enabling DIAN mode 3. Create a customer invoice 4. Fill the required details in the related [customer and journal](https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/colomb
Original PR description
Steps to reproduce: -------------------------- 1. Install `l10n_co` and activate spanish(es_419) language 2. Configure [DIAN Environment](https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/colombia.html#electronic-invoicing-credentials-and-dian-environment) by enabling DIAN mode 3. Create a customer invoice 4. Fill the required details in the related [customer and journal](https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/colombia.html#sales-journals) record 5. Send it with DIAN box checked Issue: -------- `Payment Means` and `Payment Method` are not translated to spanish(es_419). Cause: -------- After this 88d7e5a, the `<br/>` tag was removed and its related **.pot** and **.po** files were not updated. Solution: ----------- Apply the changes to the **.pot** and **.po** files to resolve the issue. opw-4790642
Fixes an issue where adjusting a checkout time in the weekly Attendance view could be lost when saving. The system now keeps the user’s selected checkout time instead of replacing it with the current time, helping prevent incorrect attendance records.
Original PR description
Steps to Produce: - Go to the Attendance interface and select week. - Drag on one column to adjust checkout. - Save the change. Issue: - Dragging on one cell deletes the checkout value from the context. - As a result, the system sets the checkout time to the current time instead of the dragged value. - This leads to incorrect attendance records. Fix: - Ensure the checkout value remains in the context when dragging the cell. - Preserve the modified checkout time so it reflects the user's intended change instead of defaulting to the current time. Task-4958060
Knowledge now saves any unsaved article edits before reloading the page after another article is moved nearby. This prevents users from accidentally losing work while organizing articles in the sidebar.
Original PR description
Currently, when a user moves another article beneath the one they are editing, the record is reloaded, causing any unsaved changes to be lost. This can be especially frustrating if the user has made significant edits. To address this issue, we will ensure that any changes made to the article are saved before the record is reloaded. This will prevent accidental loss of work and improve the editing experience. Steps to reproduce the issue: 1. Open an article 2. Make changes to the article (e.g, type or edit text) 3. Drag and drop another article beneath the current one. => The article reloads, and your unsaved changes are lost. In the `moveArticle` function, we will check if the record has unsaved changes (i.e., if it's "dirty"). If so, we will save the current content before triggering a reload via `this.props.record.model.load()`. Task-4636494
Fixes an error that occurred when refunding Mexican Point of Sale orders containing a global discount line. This helps businesses process refunds normally without interruption when discounts were applied.
Original PR description
**Steps to reproduce:** ``` - Install PoS mexican localization - Activate PoS setting Global Discounts - Navigate to PoS and create an order with a discount line - Go to back end and try to refund this order - Notice an error pops-up ``` **Cause:** Bad fw-port In the original commit `json.lines` is an array and accessing index "2" of the array was not a problem (https://github.com/odoo/enterprise/pull/84331/files#diff-63a117ed6751a8aae4fcb11d867177f5d0feb78cc1e2f3461f425babc10b5016R15) From 18.0 we are accessing the record `currentOrder` itself and `currentOrder.lines` is an PosOrderline object which doesn't have a property named "2". **Fix:** Remove index access `[2]` opw-4899501