Odoo Changelog — 2025-06-19

Thursday, June 19, 2025

9 changes

Branch: saas-18.3

2 changes

Bug Fixes(2)

Resolved issues and error corrections

[IMP] account_accountant: fix regex for payment matching

PR #87811

Enterprisesaas-18.3account_accountantaccount_bank_statement_import_csvaccount_online_synchronizationMEDIUM

Bank statement reconciliation now uses stricter matching rules to avoid linking payments to the wrong statement lines. The update also fixes transaction filtering when fetching bank data and ensures CSV-imported statements can trigger automatic matching correctly.

Original PR description

In this commit: https://github.com/odoo/enterprise/commit/c0f8c5d17b9d78b640d744d8bfb6a2bb4002776a, we changed the way payment are matched with statement lines.

Before, we were splitting the aml.ref based on ' ', then check for each word if there is an equivalent in the st_line label.

But this is not restrictive enough. So now, there is the rules we apply, in the right order :
1 - Check if there is a payment ref like SO|INV|BILL|...xxxx/xxx-yy in the aml.ref
2 - Check for full match with aml.ref
3 - Check if there is a word more than 16 characters long who match with aml.ref
4 - Check for full match with aml.move_name
5 - Check for full match with move.payment_reference

If we have any multiple match, we don't reconcile.

no-task

#bank reconciliation#payments#csv import#transactions

[FIX] account_accountant: prevent crash when setting account for manylines

PR #87828

Enterprisesaas-18.3account_accountantMEDIUM

Fixes an issue where Accounting could crash while users assigned the same account across multiple bank statement lines. This makes bank transaction reconciliation more reliable and prevents interruptions during routine bookkeeping work.

Original PR description

The system will crash when we try to set the account for statement lines. And at [1], we can see that this fetches the `previous_statement_lines`. [1]…

The system will crash when we try to set the account for statement lines. And at [1],  we can see that this fetches the `previous_statement_lines`.

[1]
https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L654-L656

After that, it calls the `_prepare_reconciliation_rule_data` method. and try to find a `common substring`.
https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L676

In the `_get_common_substring` method, when [2] is executed, and if we have the below `payment_ref`
```
[
'PRLV SEPA VROOMLY STR16NASUC4VSCWSRGTVURANBFJQM4LJU9 VROOMLY',
'PRLV SEPA AMAZON PAYMENTS EUROP 450X4WSOR73LFYYL 171-6087599-8440309 AMZN MKTP
FR 45 0X4WSOR73LFYYL',
'PRLV SEPA VROOMLY STR16NASTLNFBLLPVADQPRANTXVPUDYDFY VROOMLY',
'VIR STRIPE VROOMLY-6NXKKON62EKBHVFLXZ3T9PTDOP5 VROOMLY',
'PRLV SEPA VROOMLY STR16NAST8PLKGEKOLWOLRANIEPSODZENR VROOMLY'
]
```
(means our len(substring) is less than 10), Then it returns `None` from line [3].

[2]
https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L777-L781

[3]
https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L780

**Steps to produce:-**
1. Install the `Accounting` module.
2. Set up the `Odoo demo bank`.
3. Click on `Transactions` under Bank.
4. Set account as `Cash Discount Loss` for `Monthly Office Rent ` and
   `Annual Public liability insurance`.
5. For `Deposit on the invoice 784`, set the account as other than
   `Cash Discount Loss`  and then delete that, and again set the account as
   `Cash Discount Loss`.

**Error:-**
`AttributeError: 'NoneType' object has no attribute 'strip'`

**Solution:-**
- In this commit, we handle the case where `_get_common_substring` returns
  `None` by checking it before calling .strip().
- This prevents the system from crashing without changing the function’s
  return value.


**Sentry - 6682820343**

#accounting#bank-reconciliation#stability

Branch: master

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] payment_sepa_direct_debit: ensure provider is copied after installation

PR #87483

Enterprisemasterpayment_sepa_direct_debitMEDIUM

This fix ensures SEPA Direct Debit payment setup is completed for companies that already existed before the module was installed. Businesses can now configure and use the provider reliably across all companies, avoiding unusable payment records caused by missing setup data.

Original PR description

Since https://github.com/odoo/odoo/commit/0d3228e10d04a01c87fbef1e0e78b37c462c9ea5, payment providers are automatically duplicated for newly created companies. However, if a provider module is…

Since https://github.com/odoo/odoo/commit/0d3228e10d04a01c87fbef1e0e78b37c462c9ea5, payment providers are automatically duplicated for newly created companies. However, if a provider module is installed after creating a new company it does not work.

Steps to reproduce:
- Create a new company without installing any payment provider.
- Install `payment_sepa_direct_debit` module after the company is created.
- You’ll notice that the `code` field is not set on the provider record copied to the new company, which makes the provider unusable.

Issue:
- Provider record is missing critical fields like `code` in newly created companies.
- Without these fields, it’s impossible to configure or use the provider.

Cause:
- When the module is installed after company creation, the provider setup does not run for those companies, so the copied records are incomplete.

Solution:
- Add `post_init_hook` to copy the provider after installation.
- This ensures all required fields like `code` are correctly set up in all companies.

See Also: https://github.com/odoo/odoo/pull/213804

opw-4857980
affected version-master

#payments#sepa#multi-company#setup

Branch: 18.0

6 changes

Bug Fixes(6)

Resolved issues and error corrections

[FIX] spreadsheet: update o_spreadsheet to latest version

PR #215090

Core18.0spreadsheetMEDIUM

This update refreshes Odoo's spreadsheet component with fixes that reduce duplicate collaboration messages, improve performance during shared editing, and correct spreadsheet behaviors such as automatic resizing for array formulas. It also removes an invalid delete menu option, making spreadsheet use smoother and less confusing for users.

Original PR description

### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/55268816d [REL] 18.0.34 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/55268816d [REL] 18.0.34 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/093517d5c [FIX] collaborative: don't send duplicate messages [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/bbc9b0053 [PERF] collaborative: avoid useless transformations [Task: 4873461](https://www.odoo.com/odoo/2328/tasks/4873461)
https://github.com/odoo/o-spreadsheet/commit/9216eee84 [FIX] sheet: autoresize didn't work for array formula [Task: 4822877](https://www.odoo.com/odoo/2328/tasks/4822877)
https://github.com/odoo/o-spreadsheet/commit/8fac09350 [FIX] menus: hide invalid 'delete' option from edit menu [Task: 4854659](https://www.odoo.com/odoo/2328/tasks/4854659)

Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com>
Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

#spreadsheet#collaboration#performance#usability

[FIX] sale: Prevent invalid negative price/quantity on order lines (fixes #213477)

PR #214933

Core18.0saleMEDIUM

Sales orders now block line items where negative prices and quantities would create inconsistent totals. Return-style lines with a negative quantity and normal positive price remain allowed, helping teams avoid billing errors while preserving valid return workflows.

Original PR description

This commit introduces validation to sale.order.line to prevent inconsistent behavior with negative prices and quantities:

- A negative price unit with a positive quantity now raises a UserError.
- A negative quantity with a negative price unit now raises a UserError.
- A negative quantity with a positive price unit (e.g., for returns) remains valid.

New test cases have been added to test_sale_order.py to cover these scenarios.

Additionally, sale_order_line.py and test_sale_order.py have undergone extensive linting and formatting to comply with Odoo coding standards.

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

#sales#orders#validation#pricing

[FIX] hr_attendance: department employee count in kiosk

PR #213935

Core18.0hr_attendanceMEDIUM

The attendance kiosk now shows the correct number of employees per department when used for a company other than the default one. This prevents misleading zero counts in multi-company setups and helps staff identify the right department during check-in.

Original PR description

**PROBLEM**
When using the kiosk on a company that's not the default company, the employee count displayed for all department is 0.

**STEP TO REPRODUCE**
1.install the attendance module.
2.select another company.
3.go to the kiosk (attendance/Kiosk Mode).
4.identify manually.
5.notice the department count is incorrectly displayed as 0.

**CAUSE**
When entering the kiosk, the user is disconnected from their session, the user in this context is the public_user who have only access to the default company. The _compute_total_employee filter employees based on the company we have access to, so any employee from the non-default company are not taken into account.

**FIX**
We set the allowed_company_ids to the correct company id in the request context.

opw-4647574

#attendance#kiosk#multi-company#departments

[FIX] web: handle x2many fields for widgets

PR #214496

Core18.0webMEDIUM

This fix prevents an error when users edit quantities or open products on quotation lines in mobile view. It ensures related line-item information is available to widgets, so sales workflows continue without crashes.

Original PR description

**Note: issue discovered in saas-18.3** **Step to reproduce:** - In mobile view, create a quotation (version saas-18.3) - Trying to change the quantity or view the product a traceback will be…

**Note: issue discovered in saas-18.3**

**Step to reproduce:**
- In mobile view, create a quotation (version saas-18.3)
- Trying to change the quantity or view the product a traceback will be received

**Traceback**
```
Uncaught Promise > Cannot read properties of undefined (reading 'activeFields')
Occured on localhost:9000 on 2019-03-11 09:30:00 GMT
TypeError: Cannot read properties of undefined (reading 'activeFields')
    at http://localhost:9000/web/assets/debug/web.assets_unit_tests_setup.js:82391:75
    at async openRecord (http://localhost:9000/web/assets/debug/web.assets_unit_tests_setup.js:106172:18)
```

**Issue:**
fieldDependencies of widget are evaluated by `addFieldDependencies` function.
now if a field of type "x2many" is added as fieldDependencies, and field is not present in the form,
examples : [sol_product_many2one](https://github.com/odoo/odoo/blob/saas-18.3/addons/sale/static/src/js/sale_product_field.js#L409)  and [qty_at_date_widget](https://github.com/odoo/odoo/blob/saas-18.3/addons/sale_stock/static/src/widgets/qty_at_date_widget.js#L119)

the `related` key is not added for such fields by `addFieldDependencies` function
https://github.com/odoo/odoo/blob/b092750d2a595ac6d4bb6402c0b78db5db6d4dce/addons/web/static/src/model/relational_model/utils.js#L52-L76
which is required, when opening the subview here
https://github.com/odoo/odoo/blob/b092750d2a595ac6d4bb6402c0b78db5db6d4dce/addons/web/static/src/model/relational_model/static_list.js#L227-L233

**opw-4858035**

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

#mobile#quotation#widgets#x2many

[FIX] appointment: send mail notification on request to CC contacts w…

PR #86710

Enterprise18.0appointmentMEDIUM

Appointment request emails now include configured CC contacts when manual confirmation is used. This ensures relevant contacts are informed as soon as a booking request is submitted, especially for resource-based appointments where otherwise no internal notification may be sent.

Original PR description

…ith manual confirmation

**Steps to reproduce:**
- Install Appointement app
- Edit an appointement appointment type
- Set manual confirmation for the appointement type
- Add CC contact as well
- Go to the appointement website (/appointement)
- Create an appointement and submit it
- Nothing is sent to CC contact when the request is made

**Issue:**
Process was designed to only send notification mails to the CC contacts (`message_partner_ids`) when the request was approved or cancelled (`booked` or `cancelled` appointment_status) but not for `request` when using manual confirmation.

This is also quite problematic if `Availability on` is set to resources, as no confirmation mail is sent to anyone in that case (when no CC is specified, there is no other user than the requester).

The observed behavior is due to the new process used when making appointement, previously in 17.0 the state was directly set to 'booked' so the mail was directly created and no further mail was sent unless the user explicitly cancelled its appointment.

**Fix:**
Added 'request' to the filtering on 'appointment_status' when adding the mail templates. Adapted field description and mail templates for clarity.

related:
cc field description https://github.com/odoo/enterprise/commit/adf47c32ee190dbf98c266d0816c8d03c8cd3e4f 
appointment_status https://github.com/odoo/enterprise/commit/3c64aa6dcd191248f0806c0b84ffa416d455fde4 
request template https://github.com/odoo/enterprise/commit/2316947a0251709f3e469fea996ffac8f4623d98

opw-4658521

#appointments#email notifications#manual confirmation

[FIX] (l10n_au_)hr_payroll: worked days amount compute

PR #83171

Enterprise18.0hr_payrolll10n_au_hr_payrolll10n_au_hr_payroll_accountMEDIUM

Australian payroll now calculates overtime on top of the fixed wage instead of diluting the hourly rate across extra hours. Casual loading is also prevented from applying to overtime, helping payslips reflect the intended pay rules more accurately.

Original PR description

Bug:
1. Worked overtime hours are included within the gross paid amount of a contract rather than being added on top.

2. Casual loading rate applies to Overtime hours.

Steps to reproduce:
1. Create a payslip for an employee with a contract of Fixed wage of 2000 per week.
2. The created payslip is of correct amount with the standard 40-hours work week.
3. Add a work entry of type Overtime with duration of 4 hours. Recompute the worked days amounts.

Current behavior:
The total remains 2000 and the computed hourly rate becomes 2000/44=45.45

Expected behavior:
The hourly rate should remain the same 50.
The total should increase to be:
fixed_wage + hourly_rate * overtime hours
2000 + 50 * 4 = 2200

Fix:
1. While computing the amounts for each worked days type, exclude hours of type Overtime from total hours when calculating the hourly rate.

2.The casual loading rate should not apply to Overtime work entry types.

task-4617681

#payroll#overtime#Australia#payslips

In this commit: https://github.com/odoo/enterprise/commit/c0f8c5d17b9d78b640d744d8bfb6a2bb4002776a, we changed the way payment are matched with statement lines. Before, we were splitting the aml.ref based on ' ', then check for each word if there is an equivalent in the st_line label. But this is not restrictive enough. So now, there is the rules we apply, in the right order : 1 - Check if there is a payment ref like SO|INV|BILL|...xxxx/xxx-yy in the aml.ref 2 - Check for full match with aml.ref 3 - Check if there is a word more than 16 characters long who match with aml.ref 4 - Check for full match with aml.move_name 5 - Check for full match with move.payment_reference If we have any multiple match, we don't reconcile. no-task

The system will crash when we try to set the account for statement lines. And at [1], we can see that this fetches the `previous_statement_lines`. [1] https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L654-L656 After that, it calls the `_prepare_reconciliation_rule_data` method. and try to find a `common substring`. https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L676 In the `_get_common_substring` method, when [2] is executed, and if we have the below `payment_ref` ``` [ 'PRLV SEPA VROOMLY STR16NASUC4VSCWSRGTVURANBFJQM4LJU9 VROOMLY', 'PRLV SEPA AMAZON PAYMENTS EUROP 450X4WSOR73LFYYL 171-6087599-8440309 AMZN MKTP FR 45 0X4WSOR73LFYYL', 'PRLV SEPA VROOMLY STR16NASTLNFBLLPVADQPRANTXVPUDYDFY VROOMLY', 'VIR STRIPE VROOMLY-6NXKKON62EKBHVFLXZ3T9PTDOP5 VROOMLY', 'PRLV SEPA VROOMLY STR16NAST8PLKGEKOLWOLRANIEPSODZENR VROOMLY' ] ``` (means our len(substring) is less than 10), Then it returns `None` from line [3]. [2] https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L777-L781 [3] https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L780 **Steps to produce:-** 1. Install the `Accounting` module. 2. Set up the `Odoo demo bank`. 3. Click on `Transactions` under Bank. 4. Set account as `Cash Discount Loss` for `Monthly Office Rent ` and `Annual Public liability insurance`. 5. For `Deposit on the invoice 784`, set the account as other than `Cash Discount Loss` and then delete that, and again set the account as `Cash Discount Loss`. **Error:-** `AttributeError: 'NoneType' object has no attribute 'strip'` **Solution:-** - In this commit, we handle the case where `_get_common_substring` returns `None` by checking it before calling .strip(). - This prevents the system from crashing without changing the function’s return value. **Sentry - 6682820343**

Since https://github.com/odoo/odoo/commit/0d3228e10d04a01c87fbef1e0e78b37c462c9ea5, payment providers are automatically duplicated for newly created companies. However, if a provider module is installed after creating a new company it does not work. Steps to reproduce: - Create a new company without installing any payment provider. - Install `payment_sepa_direct_debit` module after the company is created. - You’ll notice that the `code` field is not set on the provider record copied to the new company, which makes the provider unusable. Issue: - Provider record is missing critical fields like `code` in newly created companies. - Without these fields, it’s impossible to configure or use the provider. Cause: - When the module is installed after company creation, the provider setup does not run for those companies, so the copied records are incomplete. Solution: - Add `post_init_hook` to copy the provider after installation. - This ensures all required fields like `code` are correctly set up in all companies. See Also: https://github.com/odoo/odoo/pull/213804 opw-4857980 affected version-master

### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/55268816d [REL] 18.0.34 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/093517d5c [FIX] collaborative: don't send duplicate messages [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/bbc9b0053 [PERF] collaborative: avoid useless transformations [Task: 4873461](https://www.odoo.com/odoo/2328/tasks/4873461) https://github.com/odoo/o-spreadsheet/commit/9216eee84 [FIX] sheet: autoresize didn't work for array formula [Task: 4822877](https://www.odoo.com/odoo/2328/tasks/4822877) https://github.com/odoo/o-spreadsheet/commit/8fac09350 [FIX] menus: hide invalid 'delete' option from edit menu [Task: 4854659](https://www.odoo.com/odoo/2328/tasks/4854659) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

This commit introduces validation to sale.order.line to prevent inconsistent behavior with negative prices and quantities: - A negative price unit with a positive quantity now raises a UserError. - A negative quantity with a negative price unit now raises a UserError. - A negative quantity with a positive price unit (e.g., for returns) remains valid. New test cases have been added to test_sale_order.py to cover these scenarios. Additionally, sale_order_line.py and test_sale_order.py have undergone extensive linting and formatting to comply with Odoo coding standards. 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

**PROBLEM** When using the kiosk on a company that's not the default company, the employee count displayed for all department is 0. **STEP TO REPRODUCE** 1.install the attendance module. 2.select another company. 3.go to the kiosk (attendance/Kiosk Mode). 4.identify manually. 5.notice the department count is incorrectly displayed as 0. **CAUSE** When entering the kiosk, the user is disconnected from their session, the user in this context is the public_user who have only access to the default company. The _compute_total_employee filter employees based on the company we have access to, so any employee from the non-default company are not taken into account. **FIX** We set the allowed_company_ids to the correct company id in the request context. opw-4647574

**Note: issue discovered in saas-18.3** **Step to reproduce:** - In mobile view, create a quotation (version saas-18.3) - Trying to change the quantity or view the product a traceback will be received **Traceback** ``` Uncaught Promise > Cannot read properties of undefined (reading 'activeFields') Occured on localhost:9000 on 2019-03-11 09:30:00 GMT TypeError: Cannot read properties of undefined (reading 'activeFields') at http://localhost:9000/web/assets/debug/web.assets_unit_tests_setup.js:82391:75 at async openRecord (http://localhost:9000/web/assets/debug/web.assets_unit_tests_setup.js:106172:18) ``` **Issue:** fieldDependencies of widget are evaluated by `addFieldDependencies` function. now if a field of type "x2many" is added as fieldDependencies, and field is not present in the form, examples : [sol_product_many2one](https://github.com/odoo/odoo/blob/saas-18.3/addons/sale/static/src/js/sale_product_field.js#L409) and [qty_at_date_widget](https://github.com/odoo/odoo/blob/saas-18.3/addons/sale_stock/static/src/widgets/qty_at_date_widget.js#L119) the `related` key is not added for such fields by `addFieldDependencies` function https://github.com/odoo/odoo/blob/b092750d2a595ac6d4bb6402c0b78db5db6d4dce/addons/web/static/src/model/relational_model/utils.js#L52-L76 which is required, when opening the subview here https://github.com/odoo/odoo/blob/b092750d2a595ac6d4bb6402c0b78db5db6d4dce/addons/web/static/src/model/relational_model/static_list.js#L227-L233 **opw-4858035** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

…ith manual confirmation **Steps to reproduce:** - Install Appointement app - Edit an appointement appointment type - Set manual confirmation for the appointement type - Add CC contact as well - Go to the appointement website (/appointement) - Create an appointement and submit it - Nothing is sent to CC contact when the request is made **Issue:** Process was designed to only send notification mails to the CC contacts (`message_partner_ids`) when the request was approved or cancelled (`booked` or `cancelled` appointment_status) but not for `request` when using manual confirmation. This is also quite problematic if `Availability on` is set to resources, as no confirmation mail is sent to anyone in that case (when no CC is specified, there is no other user than the requester). The observed behavior is due to the new process used when making appointement, previously in 17.0 the state was directly set to 'booked' so the mail was directly created and no further mail was sent unless the user explicitly cancelled its appointment. **Fix:** Added 'request' to the filtering on 'appointment_status' when adding the mail templates. Adapted field description and mail templates for clarity. related: cc field description https://github.com/odoo/enterprise/commit/adf47c32ee190dbf98c266d0816c8d03c8cd3e4f appointment_status https://github.com/odoo/enterprise/commit/3c64aa6dcd191248f0806c0b84ffa416d455fde4 request template https://github.com/odoo/enterprise/commit/2316947a0251709f3e469fea996ffac8f4623d98 opw-4658521

Bug: 1. Worked overtime hours are included within the gross paid amount of a contract rather than being added on top. 2. Casual loading rate applies to Overtime hours. Steps to reproduce: 1. Create a payslip for an employee with a contract of Fixed wage of 2000 per week. 2. The created payslip is of correct amount with the standard 40-hours work week. 3. Add a work entry of type Overtime with duration of 4 hours. Recompute the worked days amounts. Current behavior: The total remains 2000 and the computed hourly rate becomes 2000/44=45.45 Expected behavior: The hourly rate should remain the same 50. The total should increase to be: fixed_wage + hourly_rate * overtime hours 2000 + 50 * 4 = 2200 Fix: 1. While computing the amounts for each worked days type, exclude hours of type Overtime from total hours when calculating the hourly rate. 2.The casual loading rate should not apply to Overtime work entry types. task-4617681