Currently, an exception is raised when validating a new receipt transfer where both the stock move and the push rule have the same destination location.

Steps to Reproduce:

1. Install `stock`  module
2. Enable Multi-Step Routes in Inventory
3. Routes -> Enable Warehouses and ensure they are linked to `YourCompany`.
4. Create a new rule for that route.
5. Set action to 'Push To' with same source and destination (e.g., WH/Stock) and Automatic Move to 'Automatic No Step Added'.
6. Go to Inventory -> Operations-> Receipts
7. Create a new receipt with the same destination location as defined in the rule.
8. Click on Validate

TypeError:
```TypeError
unsupported operand types in: stock.move() - None
```

This issue[1] occurs when the rule and stock have the same destination location. It does not execute and returns None, resulting in new_move being None. When `move.move_dest_ids - new_move` is executed, it raises an error.

[1]- https://github.com/odoo/odoo/blob/5c182227514af87659ee48360c63f33487de71bf/addons/stock/models/stock_move.py#L1048

sentry-6551676919

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#206850

When creating an inter-wh transfer, the replenish order was showing the product's supplier in the Received From (partner_id) field and not the correct wh.

Steps to reproduce:
-------------------
* In Inventory, activate Multi-step Routes
* Create a new WH that can be Resupplied From another WH
* On a product, in the Inventory tab, activate the Route 'ABC: Supply Product from XYZ'
* On the forecast of that product, click on Replenish
* Match fields: Warehouse = ABC, Preferred Route = 'ABC: Supply Product from XYZ'
* Confirm
* Open the generated order

> Observation:
> The field Receive From contains the supplier of the product instead of the supplying WH.

Why the fix:
------------
The supplier_id was automatically set with the product's supplier_id. It's not correct for every routes. It's now updated accordingly to the route used and if we need the vendor.

opw-4717654


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#212645
Forward-Port-Of: odoo/odoo#210336

A series of recent commits were aiming at allowing to change the partner of some journal entries in batch to allow de-duplicating the database, in the context of the EC Saleslist report[^1]

There are a few residual issues:
1. the lock dates can prevent any change on the lines. However in this specific case, the partner is not really changing and we want to allow it. This issue is solved by adding a context key, using a sentinel to avoid any users bypassing it.
2. if the lines are reconciled, it was also impossible to update the lines. Since all the lines are changing the partner at the same time, there is no need to block changing it as the reconciliation keeps its meaning.
3. After the second commit, we were actually not checking that the VAT was indeed the same on the partner getting a `parent_id` assigned
4. We don't check that the user has a specific accounting group anymore to allow invoicing users to set the main partner. It should not be an issue since the accounting values stay the same (same VAT)

[^1]: https://github.com/odoo/odoo/commit/38d43360781250415c63aba36eadcdce586fcbc0
https://github.com/odoo/odoo/commit/3941972dc7bba3e9a3d4497b312ff7f86a497157

Forward-Port-Of: odoo/odoo#212784

To be able to merge moves, the 'price_unit' fields needs to be equal. However, if the product price decimal accuracy is higher than the currency decimal accuracy, then price_unit that looks the same are actually not, and prevent the merge.

It can happen in 2 situations:
- Python rounding precision: 55.55 != 55.5500000000001
- Tax involvement: If a tax is present on the Purchase Order, then the price unit will be recomputed to check the tax, with something similar to `CURRENCY_ROUND(price_unit * qty) / qty`, and because the currency rounding is less precise, the resulting price_unit will vary depending on the quantity.

A similar issue was already fixed in this commit: a7f08f0b4c87aeb60315d07c2e0a5fc4c7a21e50 ,but only for decrease of quantity.

This fix attempts to fix the increase of quantity. The main issue when fixing this problem is that we can't simply use float_compare, this is because the move values are fetched with _itemgetter_, and are 'compared' when _groupby_ is using these values as dictionary key.

The idea is to create a custom _itemgetter_, that will cast the price_unit as a string using the correct precision.

So, the list of values used in the group by will now look like this:
```
(product.product(84,), 'make_to_stock', ..., '25.67')
```
While it previously looked like this:
```
(product.product(84,), 'make_to_stock', ...,  25.668000000000003)
```

---

## How to reproduce
- Create a Storable product.
- Change the decimal accuracy of product price to 5.
- Create a purchase order for 10 units of P, and a price unit of 25.66803.
- Ensure a tax is set on the PO
- Confirm the order
- Edit the PO line quantity to 13 => The receipt has 2 lines of P, one for the first 10 units and the other for the added 3 units

https://github.com/user-attachments/assets/d93f697f-126a-44e5-b134-5bfc8f3ccc68

---

Test results without fix:
```
2021-01-14 09:12:15,000 21884 ERROR oes_17_test odoo.addons.purchase_stock.tests.test_purchase_order: FAIL: TestPurchaseOrder.test_05_po_update_qty_stock_move_merge
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/purchase_stock/tests/test_purchase_order.py", line 442, in test_05_po_update_qty_stock_move_merge
    self.assertEqual(len(purchase_order.picking_ids.move_line_ids), 1)
AssertionError: 2 != 1
```

---
OPW-4675425

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#210077

This PR addresses multiple issues related to flexible working hours across several Odoo modules, including attendance, overtime calculation, time off (leave) management, and work entry generation. The primary change modifies the _attendance_intervals_batch method in the `resource` module to create daily attendance blocks for flexible calendars, using the average daily hours and the required weekly hours.

Attendance Intervals for Flexible Hours:

Old Behavior: For flexible employees, a single interval spanned the entire requested period, leading to inaccurate calculations.
New Behavior: For flexible calendars (not fully flexible), daily attendance blocks are created, centered around 12:00 PM, with each block’s duration equal to the average daily hours (hours_per_day). Fully flexible employees (no calendar) retain a single interval covering the full period.

A flexible employee’s attendance was one continuous block over the entire period.

+---------------------------+
|        Attendance         |
|   (e.g., Mon to Fri)     |
+---------------------------+

New Behavior (Daily Blocks):

For a flexible calendar with 8 hours/day, attendance is split into daily blocks centered at 12:00 PM (e.g., 8:00 AM - 4:00 PM).

+-----+ +-----+ +-----+
|  8h | |  8h | |  8h |
| Mon | | Tue | | Wed |
+-----+ +-----+ +-----+

Overtime Calculation:

Updated hr_attendance.py to skip overtime computation for fully flexible employees (is_fully_flexible). For flexible calendars, overtime is now based on the new daily attendance blocks.

Time Off:

In hr_leave.py, flexible calendars now center leave intervals around 12:00 PM for each day, matching the attendance blocks. For half-day leaves, the duration is halved.
Single-day leaves use specified hours, while multi-day leaves align with the virtual schedule.

Work Entry Generation:

In hr_contract.py, work entries for flexible calendars distinguish between one-day and multi-day leaves. Multi-day leaves align with the daily attendance blocks, while one-day leaves use exact hours.
Updated hr_work_entry.py to skip marking leaves outside the schedule for flexible hours, as their virtual schedule is dynamically generated.

Timesheet:

In hr_holidays.py, timesheet generation for flexible employees uses the new attendance intervals or exact hours for hourly/half-day leaves.


task-4771288

Forward-Port-Of: odoo/odoo#209570

Currently, when you try to settle a SO in POS which has sections/notes before the product line (producted tracked), a traceback will appear and the amount to settle will be set to 0.

Steps to reproduce:
-------------------
* Crete a product tracked by SN
* Create a SO, the first line should be a section line and the second the product newly created
* Open pos session
* Try to settle the SO
> Observation: Traceback, when closing the traceback, the line on the
pos order has an amount of 0.

Why the fix:
------------
This commit https://github.com/odoo/odoo/commit/4c0fdfe23c6302929bf05f2223f41b7ac5587e66 didn't take into account that `read_converted` could potentially return less data than the number of sale order lines (sections and notes).

Thus using a loop invariant to track the converted_line related to the SO line does not make sense. In our example above, `i=1` when reaching the product line but `converted_lines` only had one element. In this case, `sale_order.order_line[1]` is related to `converted_lines[0]`.

opw-4800339

Forward-Port-Of: odoo/odoo#212494

Steps to Reproduce:
-----------------
1) Create an Accrual
	 - Set carryover_date to other
	 - Set carryover_month to April.
	 - Set carryover_day to Last Day.
2) Add an Accrual Rule to the accrual.
3) Create a Leave Allocation
	 - Set allocation_type to Accrual.
	 - Assign the Employee.
	 - Define the Validity Period (date_from, date_to).

**Issue:**
-------------------
On accrual creation when the user selects the "last day" option for carryover_day, we are currently assigning the 31st as the day Hardcoding the 31st as the `carryover_day` can lead to errors when the `_get_carryover_date` method is triggered. For example, this causes failures in months with fewer days (e.g., February or April).

**Fix:**
-----------
evaluate the correct carryover_day based on the selected month & year when the value is set to last day, before using it to prepare the final date. This ensures that the last day of each month is accurately determined and applied.

**Traceback:**
------------
 ValueError: day is out of range for month


**OPW:** 4792938

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#211452
Forward-Port-Of: odoo/odoo#211205

…ivery

**Problem:**
When a product is added to a sale order from the delivery 
the cost is not computed

**Steps to reproduce:**
- Activate the "Margins" Settings
- Open Sales/Products and create a product
- In the product Type field, choose consumable 
and set a postive cost
- Do the same for a second product
- Navigate to Sales/Order and create a new quotation
- Add your first product and Confirm
- Click on the Delivery smart button and then on the 
Detailed Operations smart button
- Click on New, add your second product and set 
a quantity of 1
- Go back to the delivery and validate it
- Go back to the sale order

**Current behavior:**
A line has been added with the product but the Cost is zero 

**Expected behavior:**
The cost should be computed

**Cause of the issue:**

Because of the elif logic here 
https://github.com/odoo/odoo/blob/799761246820eee73492277ab18f327ba04b6b96/addons/sale_stock_margin/models/sale_order_line.py#L17-L22
the cost of products added on delivery with a standard price 
will be computed using _compute_average_price
https://github.com/odoo/odoo/blob/799761246820eee73492277ab18f327ba04b6b96/addons/sale_stock_margin/models/sale_order_line.py#L23
We should instead add the line to "line_ids_to_pass" so 
they're computed with the super method

**Fix:**

Changing the elif logic to make sure that if a product is added in 
delivery and has a non standard cost method it's cost is computed 
here 
https://github.com/odoo/odoo/blob/799761246820eee73492277ab18f327ba04b6b96/addons/sale_stock_margin/models/sale_order_line.py#L23
but if it's added in delivery and has a standard cost method,
we call the super method for this line

opw-4581531

Forward-Port-Of: odoo/odoo#212100
Forward-Port-Of: odoo/odoo#208176

…compute

**PROBLEM**
When creating a new operation type, changing the type to Delivery throws a warning to create a warehouse first despite there already being one.

**STEPS TO REPRODUCE**
1. On a fresh database, install stock with drop shipping and storage locations enabled.
2. Create a new operation type and set the type to Delivery.
3. You will receive the following warning, despite an existing warehouse:

```
Please create a warehouse for company <company>
```

**CAUSE**
https://github.com/odoo/odoo/blob/138983cc81cd1565c1582a1523efa8c0c4dcc434/addons/stock/models/stock_picking.py#L308-L316

https://github.com/odoo/odoo/blob/138983cc81cd1565c1582a1523efa8c0c4dcc434/addons/stock_dropshipping/models/stock.py#L70-L74

When the form is first loaded, the type is Receipt and the source location is consequently Vendors. After changing the type to Delivery, the source location is recomputed.

Observe the above code snippets. Before the source location is done being computed, the warehouse is accessed and computed. When computing the warehouse (in the midst of the source location compute), the `default_location_src_id` is still Vendors and `default_location_dest_id` is Customers, thus `warehouse_id` is set to False.

**FIX**
In the conditional that checks if the picking type is drop shipping, check the `code` instead. The value in `code` is up-to-date at the conditional, unlike `default_location_src_id`.

opw-4603495

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#199676

In version 18.0, a traceback occurs when editing the 'Appointment:
Attendee Invitation' email template and then signing up for an
appointment.

**Steps to reproduce:**
1. Go to **Appointments**.
2. Click the **"Action"** gear icon next to an appointment, then select **Edit**.
3. Navigate to the **Options** tab.
4. Hover over the **Booking Email** template and click the **arrow icon** to open
    it.
6. In the Content tab, add some text near "Hello", then click **Save**.
7. Return to the **Appointment form**
8. Click the "**Go to Website**" smart button at the top
9. Select a date and time.
10. Confirm the appointment.

This raises a traceback

**In saas-18.3**, editing the `Appointment: Attendee Invitation` email
template throws an error when saving, making the template uneditable.


**Issue:**

The issue originates from this [commit](https://github.com/odoo/enterprise/commit/8b9a1a4462453bf64e7bc1307ededd0d127a27fa), which introduced a
`<div>` inside a `<p>` — a structure that violates the HTML specification.
Editing anything near the word 'Hello' in the template causes the
`<p>` tag to close prematurely during rendering. This pushes the `<div>`
outside of the `<p>`, breaking the directive chain and resulting in
the following error:
     

> SyntaxError: t-elif directive must be preceded by t-if or t-elif directive

    
Previously, the `<div>` was also pushed outside the `<p>`, but only after
evaluating all `t-if, t-elif, and t-else` conditions. Hence, it worked
correctly without editing the template.


**Solution:**

Placed the `<span>` as a child of the `<p>` tag to resolve the issue.
    
This fix also resolves the issue of being unable to edit the template
"Appointment: Attendee Invitation" in the UI **on saas-18.3**.

[Task-4624645](https://www.odoo.com/odoo/project.task/project.task/4624645)

Forward-Port-Of: odoo/enterprise#85669

Steps to reproduce:
- Open Follow-up levels for 15 days -Check the option for “Automatic”
- Go to the email template set in the “Content Template” and set a test email in the CC of the email configuration.
- Open the follow up reports for a sample customer who is in the “15 days” stage and change the next reminder date to be a day before today. The reminder must be set to automatic.
- There will appear a red ribbon on the right corner that says “In need of action”
- In another tab, open scheduled actions and Open the action “Account Report Followup; Execute followup”
- Run this action manually

Issue:
Go to the previous tab and notice that the email is only sent out to the customer partner record and not the cc email address

Note:
This issue only occurs if the automatic followup is set. If we try to manually followup by clicking on the “Follow Up” button on the customer report, the email is sent correctly to both addresses.

Cause:
When running the cron, the recipients aren't in the options

Solution:
Add an helper to find all necessary recipients from the template if no recipient ids in the options

opw-4527398

Forward-Port-Of: odoo/enterprise#85899
Forward-Port-Of: odoo/enterprise#83944

Issue: In Barcode, editing the qty_done of a move line and then reseting it to 0 will update the demand.

### Steps to reproduce:

- Create a storable product. Put 5 units in stock.
- Create a delivery order for 5 units and mark as to do.
- Go to the barcode app and edit your delivery order.
- Click on the pencil and set a qty of 1 > Confirm
- Click back on the pencil and reset the quantity to 0 > confirm
#### > On the picking, the demand of the line was edited from 5 to 1.

### Cause of the issue:

Editing the quantity of a move line from the barcode actually updates the qty_done of the move line which updates both the quantity and the picked status of the move line in the backend via the `_inverse_qty_done`: https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/models/stock_move_line.py#L58-L62 Initially, the quantity of the move line was 5 and hence the demand of the line in the barcode was displayed as 5:
https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/static/src/models/barcode_picking_model.js#L119-L121 The first time you edit the line, you will actually change its quantity to 1 and set it as picked. Once the line state refreshes in the barcode it will then keep the same demand of 5 as it will then be based on the previous demand of the line (since the qty of the move line is set and the qty done is positive):
https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/static/src/models/barcode_picking_model.js#L1037-L1045 However, the next time you update the line the `_inverse_qty_done` will leave the quantity of the move line at 1 but will also unpick it. Then, and since the `qty_done` was set to 0, it will update the demand of the barcode line because of these same lines:
https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/static/src/models/barcode_picking_model.js#L1037-L1045

### Fix:

Prior to Commit 3af3e00aabecde8b811ac2cbab397f982721f164 the quantity was updated as well as the picked state even when the qty_done was set to 0, so that this issue would not occur as the null quantity would make us keep the demand of barcode line after edition. However, the problem was that this would update the reserved quantity of the move and hence the barcode app demand once you leave the barcode app because of the `split_uncompleted_moves`. However, in the present use case, that same method can save us because if the move is picked and its quantity is null when you exit the barcode app, it will be rereversed.

opw-4700996

Forward-Port-Of: odoo/enterprise#86105
Forward-Port-Of: odoo/enterprise#83623

If one uploads a vendor bill from the list view using the "Upload" button, a banner is then shown on the form view of the created move to reload the data that were extracted via IAP.

However, this banner is not shown if one creates an empty move, then uploads via the attachments, then the banner is never shown.

This is because when we arrive in the `onWillStart` of the `StatusHeader`, we subscribe to a channel using the `extract_document_uuid` which does not exist upon creating a new empty move. Then, when we upload our document, the move record is saved, and is sent to the backend. At this point, the move exists, and a `extract_document_uuid` is set. Then we get the OCR results (in `_check_ocr_status`) and we have a new status, we send this status on the bus but on a channel named `f"extract.mixin.status#{self.extract_document_uuid}"` where the `extract_document_uuid` is set. However, in the JS part, it was empty because it was created in the `onWillStart`.

To resolve this, we create a new channel to detect newly created documents. We send the new `extract_document_uuid` in this channel from the backend to the frontend. The JS can now subscribe to the correct channel using an existing `extract_document_uuid`.

Now, correctly the JS receives the updates of the Python via the bus, and can update the view accordingly.

opw-4566944

Forward-Port-Of: odoo/enterprise#83522

Currently, when a user sends an article to the trash, the system triggers a notification email to relevant members informing them that the article has been trashed and will be permanently deleted in 30 days (see: `knowledge_article_trash_notification`).

This email includes a link to the trashed article (see: `article_url`). However, when a user clicks the link, they are taken to a 403 error page and cannot access the article to review or restore it.

Steps to reproduce the issue:
1. Open an article
2. Send the article to the trash
3. Open the notification email and click on the article link

=> The user is redirected to a 403 error page

When an article is trashed (see: `action_send_to_trash`), it is marked as inactive. As a result, it is excluded from ORM search results by default.

The `/knowledge/article/<id>` route uses the ORM to retrieve the article by its ID. Since trashed articles are inactive, the ORM does not return the article, leading the route to assume the article does not exist and redirect the user to a 403 error page.

To resolve this issue, we will modify the context of the search method to include the key `active_test=False`. This will allow the ORM to return inactive (trashed) articles. As a result, users who follow the link from the email will be correctly redirected to the trashed article page, where they can view its content and choose to restore it using the banner interface.

Task-4636494

Forward-Port-Of: odoo/enterprise#86065

How to reproduce:

- Install document in v17.0 with demo data
- In the kanban view, upload an image in Marketing folder
- The image is displayed as thumbnail in the kanban card
- Upgrade to saas-17.4
- Open Document and go to marketing folder

There is no thumbnail for the uploaded image.

In v17, _compute_thumbnail_status write a False status when the thumbnail is updated because when it is trigerred the attachment is not yet created. So the thumbnail is present but its status is incorrect. It works in v17 because the status is ignored by the view for images but in v17.4, the status is not ignored and the thumbnail is then not displayed.

This temporary fix allows already migrated user to see thumbnail (as the view could not be modified in stable without an upgrade).

We force the status of the thumbnail to "present" when there is no status for a thumbnail of an image which should cover the case where the status was not updated after the thumbnail creation. We have chosen this solution as the thumbnail will be updated in the upgrade and the URL returns anyway a placeholder image if the image is not present.

We modify some tests to check that the patch is applied. As the kanban test  data includes an image with a False status, the patch turns automatically the status to "present". So instead of having the generic mime type thumbnail, we get the actual thumbnail of the image. We change the assertions accordingly to test the new behavior and test the generic mime type thumbnail in the pdf case of the test "document inspector: document preview".

Task-4642866

Forward-Port-Of: odoo/enterprise#85751
Forward-Port-Of: odoo/enterprise#81558

The `action_timer_start` method caused infinite recursion when the user's timezone differed from the timesheet's timezone. The comparison between `fields.Date.today()` and `self.date` failed, creating a new timesheet.  That new timesheet triggered `action_timer_start` again, repeating the loop. 

**Steps to Produce:-**
1. Install the `Timesheets` application.
2. Navigate to `Settings > Users & Companies > User`.
3. Select your current user and, under `Preferences`, set the timezone to one that does not reflect today’s date.
4. Open the Timesheets application, and for any record, click on the `Search icon` in the column for today’s date.
5. Start the time tracking by clicking the `Play button`.
6. Wait for a moment; an error will generate.

**Error:-**
`RecursionError: maximum recursion depth exceeded.`

**Solution:-**
   - When action_timer_start() is invoked, it first checks for the _from_action_timer flag in the context.
   - If not set, it sets _from_action_timer=True.
   - The next time action_timer_start() is triggered, the presence of _from_action_timer in the context causes it to exit early, 
     preventing recursion.

**Sentry - 6592348827**

Forward-Port-Of: odoo/enterprise#85105

Currently, an error-level log is generated when confirming a Vendor Bill without setting the required AFIP Authorization Code.

**Steps to Reproduce:**
1) Install `l10n_ar_edi module`.
2) Select Company having Argentina code (e.g **(AR)Exento**) 
3) Navigate to `Invoicing->Configuration->settings`, under Argentina localization,
   set `Verify Vendor Bills validity in AFIP` to **required**.
4) Create a new Vendor Bill, select Vendor Name (e.g **ADHOC SA**).
5) Click on confirm.

**Error:**
UserError('Please set AFIP Authorization Mode and Code to continue!')

**Root Cause:**
- The code  calls `_logger.error(repr(error))` on any exception at [1] during the AFIP verification attempt, causing an ERROR‐level log entry.

[1]- https://github.com/odoo/enterprise/blob/ca16c89c6f53b1c0adb0a1a061d985bdf3439e5e/l10n_ar_edi/models/account_move.py#L500

**Solution:**
- This commit handles `UserError` exceptions separately using a warning log to prevent error-level entries.

Sentry-6576006813

Forward-Port-Of: odoo/enterprise#85261

Currently, an error occurs when updating data for payroll if a referenced partner record has been deleted by the user.

**Steps to produce:**
- Install the `contacts` and `l10n_ma_hr_payroll` module.
- Delete the partner **National Social Security Fund**.
- Navigate to `Settings > Technical > Scheduled Actions`.
- Run action manually for **Payroll: Update data**.
- Observe the error.

**Error:**
`ValueError: ParseError('while parsing /home/odoo/src/enterprise/saas-18.3/l10n_ma_hr_payroll/data/hr_salary_rule_data.xml:169 ...`

The error occurs because the method at [1] tries to load the `hr_salary_rule_data.xml` file, which references a deleted `partner_id` [2], resulting in a parsing failure.

[1] - https://github.com/odoo/enterprise/blob/b7c26a504264ee02ce40fc522faa2ef3624c9915/l10n_ma_hr_payroll/models/hr_payslip.py#L9
[2] - https://github.com/odoo/enterprise/blob/b7c26a504264ee02ce40fc522faa2ef3624c9915/l10n_ma_hr_payroll/data/hr_salary_rule_data.xml#L169

This commit ensures that all the referenced data is loaded properly, preventing errors due to missing references.

Sentry - 6617089492

Forward-Port-Of: odoo/enterprise#85979

When Acerta Affiliation Number is unset and user tries to generate export file,
A traceback will appear.

Steps to reproduce the error:
- Install ``l10n_be_hr_payroll_acerta`` module and switch to belgian company
- Create an employee A > Create a contract(Status: Running) for that employee A >
  Details > Set Acerta code > save
- Go to Payroll > Configuration > Settings > Unset Acerta Affiliation Number
- Go to Payroll > Reporting > Export Work Entries to Acerta > New > Populate > Click on Generate Export File button

Traceback:
```
File "/home/odoo/src/enterprise/l10n_be_hr_payroll_acerta/models/hr_payroll_export_acerta.py", line 45, in _generate_line
    return 'KLX1' + self.company_id.acerta_code + contract.acerta_code.zfill(20) \
TypeError: can only concatenate str (not "bool") to str
```

https://github.com/odoo/enterprise/blob/a4f68967a9826fac981c1141ece1791a0baf647a/l10n_be_hr_payroll_acerta/models/hr_payroll_export_acerta.py#L45
When ``self.company_id.acerta_code`` is not set,
It will lead to the above traceback.

sentry-6620429585

Forward-Port-Of: odoo/enterprise#86098