Tuesday, March 4, 2025
62 changes · 18.0
Enhancements to existing features
Belgian states have been added to Odoo’s standard country data, improving address and localization accuracy for Belgian records. A related tax test was adjusted so existing validation continues to work with the new Belgian state data.
Original PR description
Add belgian states to the states data list. Done as part of task-4522433
Adds automated checks to ensure accounting security access is granted only in the intended situations and that journal checks no longer raise errors. This helps protect the reliability of secured accounting entry features without changing day-to-day user workflows.
Original PR description
In odoo/odoo#196748, the secured group usability was changed to only grant access to the new features relating to securing entries if moves from a journal without "Hash on Post" are secured. In odoo/odoo#197226, an issue with the first commit was addressed, in which an error was raised when checking if a journal had unhashed entries. This commit adds tests to validate that the group-granting behavior occurs correctly, and that there are no errors raised when checking a journal for unhashed entries. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Indian payroll yearly salary by employee report now uses a clearer date format, shows the employee registration number as the employee code, and improves table presentation. These changes make the report easier to read and more consistent for payroll and HR teams.
Original PR description
-change the date format to dd/mm/yyyy -employee code should be employee registration number of the employee -title should be bold -borderline should be same on both table task-4452670
Resolved issues and error corrections
The attendance screen no longer shows approve or refuse actions when an employee has no extra hours to review. This avoids confusing managers with unnecessary buttons for attendance entries that are already approved by default.
Original PR description
Since logging new attendance is approved by default, the refuse/approve buttons for rejecting/approving extra zero hours should be invisible. task-4320142 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
Miscellaneous changes
Steps to reproduce =================== - Create database with a valid mail configuration. - Open CRM module apply some random filters to get the helper. - alias name is there in the helper. This PR addresses the issue and now the alias email will be there instead of the name. Task-4619974 Forward-Port-Of: odoo/odoo#200129
Original PR description
Steps to reproduce =================== - Create database with a valid mail configuration. - Open CRM module apply some random filters to get the helper. - alias name is there in the helper. This PR addresses the issue and now the alias email will be there instead of the name. Task-4619974 Forward-Port-Of: odoo/odoo#200129
A new automated test checks that saved popup snippets appear immediately when reused on another website page. This helps prevent a past issue where users had to manually toggle visibility before the popup appeared.
Original PR description
**Steps to Reproduce:** 1. Drop a popup snippet on any page (e.g., Home page). 2. Save the popup snippet for reuse. 3. Drop the same custom snippet on another page (e.g., Contact Us page). 4. Try to…
**Steps to Reproduce:** 1. Drop a popup snippet on any page (e.g., Home page). 2. Save the popup snippet for reuse. 3. Drop the same custom snippet on another page (e.g., Contact Us page). 4. Try to make the snippet visible on this page. **Specification:** Previously, when creating a custom Popup Snippet for later use and attempting to drag and drop it, the popup was not visible on the first attempt. The visibility needed to be manually toggled from the snippet options (it only became visible on the second click). This issue was addressed in commit https://github.com/odoo/odoo/commit/d8daeed8bac9c5e48882a25031dace0b9355c7d7, and it persisted from version 16.0 to saas-17.4. To prevent this issue from recurring, we have introduced a test tour in this commit to verify that custom popups are now displayed immediately after a drag-and-drop action, eliminating the need to manually toggle visibility. Commit that resolved this issue in version 18.0 : https://github.com/odoo/odoo/commit/edf81c13d8f2f6d29a77d68cbfa0dc9216da3c2a task-4088420 Forward-Port-Of: odoo/odoo#198912 Forward-Port-Of: odoo/odoo#184659
Fixes an editing issue where pressing Enter after an image-only list item removed its bullet and changed the list layout. Users can now continue lists with images more predictably, keeping notes and to-do content properly formatted.
Original PR description
### Steps to reproduce: - Open the To-Do app. - Create a list (e.g., `/list`). - Insert an image into a list item and press `Enter`. - Notice that the list item containing the image is outdented. ### Solution: - In `handleSplitBlock`, the `!closestLI.textContent` check did not handle list items containing only an image. Adding an `isEmptyBlock` check ensures the bullet point is preserved. ### Description of the issue/feature this PR addresses: - Pressing Enter in list item containing only an image removed the bullet point. ### Desired behavior after PR is merged: - Pressing Enter in a list item with only an image preserves the bullet point and creates a new empty list item. task-4586704 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents an error that could occur when users pasted content into the editor under specific conditions. It improves editing reliability by safely handling empty invisible content during paste operations.
Original PR description
Description of the issue this PR addresses: Pasting content on a node with an invisible empty text node as the last child would result in a traceback. This occured because the empty node being removed when inserting text. task-4566557 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Archived products will no longer appear as choices when adding combo products to a sales order. This prevents sales teams from accidentally selecting unavailable or discontinued items, keeping orders aligned with the active product catalog.
Original PR description
steps: - create a combo product with 1 or more combo items - archive a product part of this combo - create an SO and add this combo product issue: - it shows archived product cause: - when product is archived the linked combo item line is not archived fix: - added an active filter in combo_configurator get data opw-4579038 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The candidate form now shows the full number of related applications, including inactive or refused ones. This gives recruiters a more accurate view of a candidate's recruitment history directly from the Applications button.
Original PR description
Description of the issue/feature this PR addresses: On the candidate form view, the "Applications" smart button doesn't show the correct count. It counts only active applications. Desired behavior after PR is merged: On the candidate form view, show the correct count on the "Applications" smart button including both active and refused applications. task-4473067 **Forward port:** 18.0 -> 18.1 Candidate was removed in 18.2 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The editor toolbar now hides link, AI, and translation actions when a user selects content across block elements, such as multiple table columns. This prevents confusing or invalid toolbar options from appearing and restores the expected editing behavior.
Original PR description
**Problem**: In previous versions, the link button (AI & translation too) was not displayed in the toolbar when the selection included block elements. However, this behavior has regressed, and the link button (AI and Translation too) now appears even when the selection spans blocks. **Solution**: Hide the link button (AI & translation too) in the toolbar when the selection includes block elements. **Steps to reproduce**: 1. Create a table in the editor. 2. Select multiple columns. 3. Observe that the toolbar incorrectly displays the link button. opw-4397649 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes the quick assign icon appear again when users hover over tasks in the Project kanban view. It restores an expected shortcut, helping users assign work from the task board without extra clicks or navigation.
Original PR description
Steps to Reproduce: - go to project and navigate to the`project.task` Kanban view. - hover over any task element. - the quick qssign icon is hidden. Cause: - the CSS class responsible for displaying the Quick Assign icon on hover was removed from the views. Solution: - Added a new class to ensure the Quick Assign icon is visible when hovering over a task. task-4461236
Customers and staff can now download files attached to sales order portal messages immediately after opening the preview page. This prevents an error page caused by an incorrect preview link, making document sharing from sales orders smoother and more reliable.
Original PR description
## Versions: 18.0+ No fix needed before as feature starts here ## Issue: An error page show up when trying to download files from SO portal preview. ## Steps to reproduce: - Create a new `Sale Order`…
## Versions: 18.0+ No fix needed before as feature starts here ## Issue: An error page show up when trying to download files from SO portal preview. ## Steps to reproduce: - Create a new `Sale Order` for any client with any product(s); - Click the `Send message` button in the chatter: - Write down any message and attach at least 1 file; - Send the message; - Click on the SO's `Preview` button that will redirect you to the portal; - **Don't reload the page**; - Move down to the chatter; - Hover the message containing the file(s); - Click the three dots then `Download Files`. ## Cause: The relative URL is created a wrong way, including an old way (<16.0) to access edition mode (even replaced by `get_client_action_url`[^1]) which we don't want here. Probably copy-pasted from https://github.com/odoo/odoo/blob/ddb03a55ac94b9fd48ae6ce138e70c0070bedd36/addons/website_sale/models/account_move.py#L23-L28 *We might want to remove it from here too but no bug declared yet (?)* opw-4545106 [^1]: https://github.com/odoo/odoo/pull/99926
Fixed an issue where special mentions such as @everyone could appear as raw HTML text instead of clickable links in mail messages. This improves message readability and ensures users can interact with mentions as expected.
Original PR description
Before this commit: Special mentions (@everyone) appeared as raw HTML instead of links because when message content is not `markup()`, it is rendered as text instead of HTML when using `t-out`. After this commit: This commit ensures special mentions are correctly rendered as links. Before / After  
Payment requests now use only the first email address when a customer record contains multiple addresses. This prevents payment provider issues, especially with Stripe, which expects a single email per payment request.
Original PR description
If the email field is provided, it must be unique as Stripe doesn't handle multiple emails per payment request. In Odoo, the field partner_email is designed for more than 1 email in order to send documents easily to multiple recipients. Considering the first email only for Stripe in case of multiple emails. opw-4576386
Users who have Project access but no Sales rights can now duplicate projects without encountering an access error. This prevents an unnecessary blocker in project administration while keeping sales permissions unchanged.
Original PR description
**issue:** If a user lacks Sales module rights, they are not allowed to duplicate a project. **steps to reproduce:** - Settings / Users & Companies / Users - Remove sales rights from the user while retaining rights in projects - In the project module, try duplicating a project An access error is raised because the ```reinvoiced_sale_order_id``` field is attempted to be read during the copy operation opw-4466519
The General Ledger search now skips draft accounting lines that do not have a name. This prevents an error when users search reports after resetting entries to draft and clearing their names, keeping reporting workflows uninterrupted.
Original PR description
### Steps to reproduce: - Create a draft vendor bill - Go to Accounting > Reporting > General Ledger - Include draft entries in the report - Click the three dots on a posted entry and view the entry - Reset it to draft - Delete the name of the entry and save - Return to the General Ledger - Type something in the search bar - Error ### Cause: This flow automatically search on the lines but draft lines have no name (null) so it crashes on `const lineName = line.name.trim().toLowerCase();`. ### Solution: Ignore lines with no names when searching. opw-4589598
This fixes an automated Knowledge calendar test that could fail on rare month-start dates. It improves release reliability by making the test use a stable date and correcting checks that were not validating the page properly.
Original PR description
Prior to this commit, `knowledge_calendar_command_tour` failed on the first day of the month, if it was a Saturday. This is because it creates an `ArticleItem` on Monday of the week containing the current date, which may be in the previous month, and then tries to find that same `ArticleItem` in the FullCalendar representation of the current month with week ends days hidden. In that view, with that setting, Monday of the current week is always shown (even if it is part of the previous month) UNLESS the first day of the month is Saturday. This commit also fixes some selectors using `:not` pseudo-class incorrectly (they were always true and did not verify anything). runbot-task-114354
This fix ensures copied databases using the Tyro point-of-sale integration are neutralized so they do not accidentally contact external payment systems. It helps support teams investigate customer databases safely without risking unwanted production impact.
Original PR description
This commit adds the missing neutralization necessary for the pos_tyro module introduced in 18.0 in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] https://github.com/odoo/enterprise/pull/79432
UrbanPiper order processing now verifies that the required fiscal position exists and belongs to the correct company. If it is missing or linked to another company, the system creates a valid one, helping prevent order or tax configuration issues.
Original PR description
Before this commit: === - If `urbanpiper_fiscal_position_id` is not set, the system attempts to retrieve the default UrbanPiper fiscal position. After this commit: === - The check ensures that if no valid fiscal position is found (either missing or belonging to a different company), a new one is created. runbot-115934
Fixes an issue where Knowledge article templates sent through the chatter were inserted below the user's email signature. Templates now appear in the intended message area, helping users send cleaner, properly formatted messages without manual repositioning.
Original PR description
Currently, the "Clipboard" functionality pastes templates at the very end of the text box, causing them to appear after the signature. ### Steps to reproduce 1. Install the `knowledge` module. 2. Open any view with a chatter. 3. Click the "Search Knowledge Articles" icon (ribbon icon next to the pager). 4. Select the "Welcome Mitchel Admin" article. 5. In the article, find a template and click the "Send as message" button. You should notice that the template is placed below the signature. ### Cause Since version 18.0, the full composer includes the signature. As a result, anything pasted at the end of the composer will appear below the signature. opw-4410141
Belgian Intrastat reports no longer show duplicate CSV and XML export buttons. This reduces confusion for users preparing Intrastat declarations and also fixes the related asset loading setup.
Original PR description
- Due to how _custom_options_initializer is handled with children reports, there is 2 xml & 2 csv buttons. This fix checks that they are added only once. - This commit also corrects manifest assets import
Creating a new Field Service task from a mobile view now correctly applies the default context, so the current user is set as the assignee when expected. This also avoids a debug-mode error caused by unsupported form options, improving reliability for mobile Field Service users.
Original PR description
Steps to reproduce ================== - Go to Field Service - Use a mobile viewport - Click on "new" Without debug: The default assignee is not the current user In debug: Invalid props for component 'ProjectTaskFormController': unknown key 'additionalContext', unknown key 'onClose' opw-4512178
Steps to reproduce the bug: - Create a cash or bank account journal - Archive it (you will have an error, because it is associated with a payment method) - Delete it (it will be deleted normally) Problem: The problem is because of added constraint on the archival of account journal, that wasn't added to the deletion as well. The constraint on the archival was too strict after discussion with accounting team, it should be reverted and a new constraint will be added from the pos side. Now,
Original PR description
Steps to reproduce the bug: - Create a cash or bank account journal - Archive it (you will have an error, because it is associated with a payment method) - Delete it (it will be deleted normally)…
Steps to reproduce the bug: - Create a cash or bank account journal - Archive it (you will have an error, because it is associated with a payment method) - Delete it (it will be deleted normally) Problem: The problem is because of added constraint on the archival of account journal, that wasn't added to the deletion as well. The constraint on the archival was too strict after discussion with accounting team, it should be reverted and a new constraint will be added from the pos side. Now, the journal can't be archived nor deleted if it has at least one payment with payment method for that journal in an active session, because the journal items are written when the session is closed only. So, if the journal is archived with some active payments before closing the session, the journal entries are lost because it fails to write them in archived journal. The constraint is added to both archival and deletion to prevent the possibility of deletion while we can't archive. Testing: A performance testing was held on the new constraint, and based on the profiling the execution time was 0.00 seconds, and the pos.payments test passed successfully. Commits that added the constraint: d430231 5722d52 Tickets that required that constraint: opw-4070620 ------------------------------------------- opw-4554961 opw-4438601 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#199854 Forward-Port-Of: odoo/odoo#199009
**Current behavior:** It's possible to end up with a negative valuation for a product with zero product qty. **Expected behavior:** No negative valuation for 0 product qty. **Steps to reproduce:** 1. Create a FIFO, real-time product; create a BOM for fifo-product with some component (tracked by qty, costing method doesn't matter, `standard_price=1`) 2. Purchase 2 units of component @ $1 3. Create and fully process an MO for fifo-prod 4. Change the standard price of component fr
Original PR description
**Current behavior:** It's possible to end up with a negative valuation for a product with zero product qty. **Expected behavior:** No negative valuation for 0 product qty. **Steps to reproduce:** 1.…
**Current behavior:** It's possible to end up with a negative valuation for a product with zero product qty. **Expected behavior:** No negative valuation for 0 product qty. **Steps to reproduce:** 1. Create a FIFO, real-time product; create a BOM for fifo-product with some component (tracked by qty, costing method doesn't matter, `standard_price=1`) 2. Purchase 2 units of component @ $1 3. Create and fully process an MO for fifo-prod 4. Change the standard price of component from $1 -> $2 5. Create and fully process a second MO for fifo-prod 6. Unbuild the second MO (from step 5) 7. Sell 1 unit of fifo-prod 8. Check the valuation, see that both the unbuild and out move (sale) use a `unit_cost=$2` despite there having been only 1 qty valued at $2 in the valuation history **Cause of the issue:** SVL creation for fifo costing in an unbuild context does not limit the candidate layer search to moves linked to the actual manufacturing order specified on the unbuild form. So despite us unbuilding the second MO in step 6, the valuation from the first MO's SVL is used. The reason we get the correct `unit_cost` despite using the wrong layer is due to commit: 84dda96 Prior to which, the valuation would have correctly zeroed out but there would have still been this valuation mis-match behind the scenes. **Fix:** Constrain the fifo candidate layer search to finished moves from the unbuilt production (if actuallywhen `_action_confirm`ing unbuild moves. opw-4416350 Forward-Port-Of: odoo/odoo#198441 Forward-Port-Of: odoo/odoo#197190
This commit will set the company_id from partner party legal entity when the partner is not from SA task: 4531706 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196757
Original PR description
This commit will set the company_id from partner party legal entity when the partner is not from SA task: 4531706 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196757
This is a solution for https://github.com/OCA/timesheet/issues/740 Forward-Port-Of: odoo/odoo#199851
Original PR description
This is a solution for https://github.com/OCA/timesheet/issues/740 Forward-Port-Of: odoo/odoo#199851
We recently enabled recaptcha on the registration form in [1] Turnstile can be implemented on top of it by just invoking the turnstile script in js. As it's implicitly checked when recaptcha is checked, this also avoids any issue with the form potentially not working if turnstile is enabled. [1]: bafa915f85fb8fc6ca2ae7d194a4593cb2463c2e task-4335141 Forward-Port-Of: odoo/odoo#199853 Forward-Port-Of: odoo/odoo#192827
Original PR description
We recently enabled recaptcha on the registration form in [1] Turnstile can be implemented on top of it by just invoking the turnstile script in js. As it's implicitly checked when recaptcha is checked, this also avoids any issue with the form potentially not working if turnstile is enabled. [1]: bafa915f85fb8fc6ca2ae7d194a4593cb2463c2e task-4335141 Forward-Port-Of: odoo/odoo#199853 Forward-Port-Of: odoo/odoo#192827
**Description of the issue/feature this PR addresses:** When computing l10n_in's `res_partner.l10n_in_gst_state_warning` field, we [search](https://github.com/odoo/odoo/blob/f1fb0527f1b29e4b464e13718d6d0edb3b32a114/addons/l10n_in/models/res_partner.py#L45) for a res_country_state whose `l10n_in_tin` is the same as the one encoded in the partner's `vat`; if none is found we warn the user. Since the res_country_state's [`l10n_in_tin`](https://github.com/odoo/odoo/blob/f1fb0527f1b29e4b464e137
Original PR description
**Description of the issue/feature this PR addresses:** When computing l10n_in's `res_partner.l10n_in_gst_state_warning` field, we…
**Description of the issue/feature this PR addresses:**
When computing l10n_in's `res_partner.l10n_in_gst_state_warning` field, we [search](https://github.com/odoo/odoo/blob/f1fb0527f1b29e4b464e13718d6d0edb3b32a114/addons/l10n_in/models/res_partner.py#L45) for a res_country_state whose `l10n_in_tin` is the same as the one encoded in the partner's `vat`; if none is found we warn the user.
Since the res_country_state's [`l10n_in_tin`](https://github.com/odoo/odoo/blob/f1fb0527f1b29e4b464e13718d6d0edb3b32a114/addons/l10n_in/models/res_country_state.py#L10) is not unique though, it is legal for the customer to have multiple res.country.state entries with the same l10n_in_tin (typically one standard plus one custom state):
```sql
> SELECT ARRAY_AGG(id),ARRAY_AGG(country_id),ARRAY_AGG(name),ARRAY_AGG(code),l10n_in_tin FROM res_country_state WHERE l10n_in_tin IS NOT NULL GROUP BY l10n_in_tin HAVING COUNT(*)>1
+-------------+------------+------------------------+--------------+-------------+
| array_agg | array_agg | array_agg | array_agg | l10n_in_tin |
|-------------+------------+------------------------+--------------+-------------|
| [1741, 589] | [104, 104] | ['HARYANA', 'Haryana'] | ['06', 'HR'] | 06 |
+-------------+------------+------------------------+--------------+-------------+
```
If our search passes more than one results to `state_id.name` though, Odoo fails with a ValueError:
```
Traceback (most recent call last):
File "/tmp/tmpdugmps2c/migrations/base/tests/test_mock_crawl.py", line 256, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpdugmps2c/migrations/base/tests/test_mock_crawl.py", line 269, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpdugmps2c/migrations/base/tests/test_mock_crawl.py", line 429, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpdugmps2c/migrations/base/tests/test_mock_crawl.py", line 457, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3801, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4032, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6999, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1291, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1473, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 429, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5238, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 113, in determine
return needle(records, *args)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 710, in _compute_related
record[self.name] = self._process_related(value[self.related_field.name], record.env)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6999, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1291, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1473, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 429, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5238, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
return needle(*args)
File "/home/odoo/src/odoo/18.0/addons/l10n_in/models/res_partner.py", line 48, in _compute_l10n_in_gst_state_warning
"As per GSTN the state should be %s, so it's recommended to", state_id.name
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1232, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6212, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: res.country.state(1741, 589)
```
**Desired behavior after PR is merged:**
We can avoid this by explicitly limiting the search to a single result.
TBG: https://upgrade.odoo.com/web#cids=1&menu_id=107&action=178&model=upgrade.request.traceback.group&view_type=form&id=1804
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#198388*FPOS - Fiscal Position *POS - Place of Supply - Before this commit: The fiscal position was determined based on the partner's shipping address (`partner_shipping_id`) in sales orders, which did not align with Indian tax regulations. - After this commit: The fiscal position is now computed based on the place of supply, ensuring compliance with Indian tax requirements. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo
Original PR description
*FPOS - Fiscal Position *POS - Place of Supply - Before this commit: The fiscal position was determined based on the partner's shipping address (`partner_shipping_id`) in sales orders, which did not align with Indian tax regulations. - After this commit: The fiscal position is now computed based on the place of supply, ensuring compliance with Indian tax requirements. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199834 Forward-Port-Of: odoo/odoo#197433
When we import an Italian EDI file with a withholding tax line that has a zero amount, we get a division by zero error. This commit fixes this issue by ensuring the import handles zero amounts without raising an error. Steps to reproduce: - Import an XML file containing the following `DettaglioLinee`: ```xml <DettaglioLinee> <NumeroLinea>2</NumeroLinea> <Descrizione>Contributo ENASARCO</Descrizione> <PrezzoUnitario>0.00</PrezzoUnitario> <PrezzoTotale>0.00</PrezzoTotal
Original PR description
When we import an Italian EDI file with a withholding tax line that has a zero amount, we get a division by zero error. This commit fixes this issue by ensuring the import handles zero amounts without raising an error.
Steps to reproduce:
- Import an XML file containing the following `DettaglioLinee`:
```xml
<DettaglioLinee>
<NumeroLinea>2</NumeroLinea>
<Descrizione>Contributo ENASARCO</Descrizione>
<PrezzoUnitario>0.00</PrezzoUnitario>
<PrezzoTotale>0.00</PrezzoTotale>
<AliquotaIVA>22.00</AliquotaIVA>
<AltriDatiGestionali>
<TipoDato>CASSA-PREV</TipoDato>
<RiferimentoTesto>TC07 - ENASARCO</RiferimentoTesto>
<RiferimentoNumero>10.03</RiferimentoNumero>
</AltriDatiGestionali>
</DettaglioLinee>
```
Since PrezzoUnitario is 0, this causes a division by zero error.
Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4555966)
opw-4555966
Forward-Port-Of: odoo/odoo#197456Before Commit: --------------- - Shipping rates were retrieved based on the total shipping weight calculated from product. - Manually adjusted weights were not considered in the rate retrieval, causing inconsistencies. After Commit: ------------- - The weight computation for the packages was updated to take into consideration the manually modified order weight. - If an adjusted weight is provided, it will be used for rate calculations; otherwise, the calculated weight will be used. - T
Original PR description
Before Commit: --------------- - Shipping rates were retrieved based on the total shipping weight calculated from product. - Manually adjusted weights were not considered in the rate retrieval, causing inconsistencies. After Commit: ------------- - The weight computation for the packages was updated to take into consideration the manually modified order weight. - If an adjusted weight is provided, it will be used for rate calculations; otherwise, the calculated weight will be used. - This fix prevents confusion and ensures that the shipping rate reflects the actual weight of the order as adjusted by the user. task-4203065 Forward-Port-Of: odoo/odoo#189392
Steps: - Install sales app. - Open a sale order and toggle studio. - Click on list view, select 'Edit list view' - Select 'Open form view' for 'when creating record' under 'views' side panel. - Go back to sale order. Add Product in sale order line. - Create Order Lines form opens. Issue: - Fields (quantity, delivered, etc.) are misformatted and not in sequence. - Product field has no label. Cause: - There was no label defined for product field as done for others that was breaking
Original PR description
Steps: - Install sales app. - Open a sale order and toggle studio. - Click on list view, select 'Edit list view' - Select 'Open form view' for 'when creating record' under 'views' side panel. - Go back to sale order. Add Product in sale order line. - Create Order Lines form opens. Issue: - Fields (quantity, delivered, etc.) are misformatted and not in sequence. - Product field has no label. Cause: - There was no label defined for product field as done for others that was breaking the flow and sequence. Fix: - Added a Label to product field which solves the issue. opw-4455197 Forward-Port-Of: odoo/odoo#199572
This commit adds new tax ISR 1.25 witheld RESICO for mexican localization target: 17 -> master task-4486643 Linked PR: [odoo/enterprise#80081](https://github.com/odoo/enterprise/pull/80081) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199201 Forward-Port-Of: odoo/odoo#195346
Original PR description
This commit adds new tax ISR 1.25 witheld RESICO for mexican localization target: 17 -> master task-4486643 Linked PR: [odoo/enterprise#80081](https://github.com/odoo/enterprise/pull/80081) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199201 Forward-Port-Of: odoo/odoo#195346
Steps to Reproduce: - Log in with a user having no special access right in Employees. - Install point_of_sale and hr modules. - Try to download the "User Labels" from the "My Profile" section. Cause: - In the report barcode field has been used which is accessible only to users having "group_hr_user" group. Fix: - Added a check before accessing the barcode field, to ensure the user has the appropriate access right. task-4497441 --- I confirm I have signed the CLA and read the PR
Original PR description
Steps to Reproduce: - Log in with a user having no special access right in Employees. - Install point_of_sale and hr modules. - Try to download the "User Labels" from the "My Profile" section. Cause: - In the report barcode field has been used which is accessible only to users having "group_hr_user" group. Fix: - Added a check before accessing the barcode field, to ensure the user has the appropriate access right. task-4497441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199592 Forward-Port-Of: odoo/odoo#196912
Currently, using the tax '12% agri' on a Vendor Bill makes the document impossible to validate because of the error `1166 - Valor del campo Tipoimpositivo no está incluido en la lista de valores permitidos` Steps to reproduce: - Have l10n_es_edi_sii module installed and have a tax agency selected. - Make a Bill using '12% agri' tax Issue: When sending the bill for validation the error is raised. This occurs because the field "ClaveRegimenEspecialOTrascendencia" is set to "01", whe
Original PR description
Currently, using the tax '12% agri' on a Vendor Bill makes the document impossible to validate because of the error `1166 - Valor del campo Tipoimpositivo no está incluido en la lista de valores…
Currently, using the tax '12% agri' on a Vendor Bill makes the document impossible to validate because of the error `1166 - Valor del campo Tipoimpositivo no está incluido en la lista de valores permitidos` Steps to reproduce: - Have l10n_es_edi_sii module installed and have a tax agency selected. - Make a Bill using '12% agri' tax Issue: When sending the bill for validation the error is raised. This occurs because the field "ClaveRegimenEspecialOTrascendencia" is set to "01", when it should be "02" for exempt taxes. Also, in this case TipoImpositivo and CuotaSoportada should be replaced by PorcentCompensacionREAGYP and ImporteCompensacionREAGYP https://sede.agenciatributaria.gob.es/Sede/iva/regimenes-tributacion-iva/regimen-especial-agricultura-ganaderia-pesca/que-consiste-regimen-especial-agricultura-pesca.html https://sede.agenciatributaria.gob.es/static_files/Sede/Procedimiento_ayuda/G417/FicherosSuministros/V_1_1/Validaciones_ErroresSII_v1.1.pdf opw-4486190 Forward-Port-Of: odoo/odoo#198345 Forward-Port-Of: odoo/odoo#196017
Description of the issue/feature this PR addresses: Task: https://www.odoo.com/odoo/my-tasks/4179478 Current behavior before PR: - Wrong names for certain accounts Desired behavior after PR is merged: - Fix names for accounts --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190705
Original PR description
Description of the issue/feature this PR addresses: Task: https://www.odoo.com/odoo/my-tasks/4179478 Current behavior before PR: - Wrong names for certain accounts Desired behavior after PR is merged: - Fix names for accounts --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190705
**Steps to reproduce** - Create accrual plan with "Accrued gain time": at the start of the accrual period - Create a milestone with 10 days yearly on the 1st of the year, don't cap accrued time, milestone reached: 0 days after allocation start date, carry over: all accrued time carried over. - Create an allocation using this accrual plan. Set the start date a few years in the past (e.g. 3 years ago). Save the allocation. - Manually set the number of days of the allocation to 0. - Validate
Original PR description
**Steps to reproduce** - Create accrual plan with "Accrued gain time": at the start of the accrual period - Create a milestone with 10 days yearly on the 1st of the year, don't cap accrued time,…
**Steps to reproduce** - Create accrual plan with "Accrued gain time": at the start of the accrual period - Create a milestone with 10 days yearly on the 1st of the year, don't cap accrued time, milestone reached: 0 days after allocation start date, carry over: all accrued time carried over. - Create an allocation using this accrual plan. Set the start date a few years in the past (e.g. 3 years ago). Save the allocation. - Manually set the number of days of the allocation to 0. - Validate the allocation. - Time Off Dashboard > Check the number of days accrued on the 2nd day of next year. Actual: 20 days. Expected: 10 days (gained on the 1st of next year, 0 days before that as the allocation has been set to 0). **Cause** 0 days allocations (using an acrcual plan with gain time at start) are considered as not already accrued, even if they are marked as `already_accrued`. https://github.com/odoo/odoo/blob/8b339fdde161e81e1a00cecd3b1fd280de51fd08/addons/hr_holidays/models/hr_leave_allocation.py#L460 In this case, we process the accrual plans when changing the date, which triggers the `_onchange_date_from` and marks the allocation as `already_accrued`. opw-4340521 Forward-Port-Of: odoo/odoo#198110
Traceback when state (which is a non required field) is empty. Fix the express checkout flow. Bug introduced in 80507191 opw-4577470 Forward-Port-Of: odoo/odoo#199594
Original PR description
Traceback when state (which is a non required field) is empty. Fix the express checkout flow. Bug introduced in 80507191 opw-4577470 Forward-Port-Of: odoo/odoo#199594
## Versions: 17.0+ ## Issue: Multi-checkboxes attributes are displayed as filters in the shop view but are not displayed in mobile view. ## Steps to reproduce: 1. Create a `Multi-checkbox (option)` attribute called "Extra" via `Sales / Configuration / Products / Attributes`; 2. Add 1 attribute value; 3. Go to any product available on the shop (e.g. Acoustic Bloc Screens); 4. Via its `Attributes & Variants` tab, add the newly created attributes and select the value; 5. Go to the shop
Original PR description
## Versions:
17.0+
## Issue:
Multi-checkboxes attributes are displayed as filters in the shop view but are not displayed in mobile view.
## Steps to reproduce:
1. Create a `Multi-checkbox (option)` attribute called "Extra" via `Sales / Configuration / Products / Attributes`;
2. Add 1 attribute value;
3. Go to any product available on the shop (e.g. Acoustic Bloc Screens);
4. Via its `Attributes & Variants` tab, add the newly created attributes and select the value;
5. Go to the shop via the `Website` app;
- *In normal web view, the filter is available on the left*
6. Change view to mobile mode and open the filters;
7. Open the "Extra filter and see no filter under it.
## Cause:
Mobile displayed filters are restricted to avoid color attributes but didn't expand to allow multi-checkboxes.
opw-4383970
Forward-Port-Of: odoo/odoo#198087Some "True"/"False" terms were incorrectly untranslated back into "True"/"False" in German. This cases a test to fail and was incorrect in these contexts. Revert it. Note: Some inconsistency reverts may have been applied, but should have no effect on code. More thorough revert will be done later on by translator. 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 t
Original PR description
Some "True"/"False" terms were incorrectly untranslated back into "True"/"False" in German. This cases a test to fail and was incorrect in these contexts. Revert it. Note: Some inconsistency reverts may have been applied, but should have no effect on code. More thorough revert will be done later on by translator. 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 way the queries were formatted was prone to create injections (though it didn't in this case). This commit makes proper use of the SQL formatter to avoid that and make the code more robust. Forward-Port-Of: odoo/enterprise#80586 Forward-Port-Of: odoo/enterprise#80493
Original PR description
The way the queries were formatted was prone to create injections (though it didn't in this case). This commit makes proper use of the SQL formatter to avoid that and make the code more robust. Forward-Port-Of: odoo/enterprise#80586 Forward-Port-Of: odoo/enterprise#80493
Mod349 tax report in Spanish localization should report the total number of intra-community operators and a following details of each operation type Currently if the user decide to unset the field l10n_es_reports_mod349_invoice_type on an intra-community invoice (because of a mistake or an exception) the Mod349 will still report the invoice in the total number of intra community operators but no operation will be reported in the following section Steps to reproduce: - With an ES company se
Original PR description
Mod349 tax report in Spanish localization should report the total number of intra-community operators and a following details of each operation type Currently if the user decide to unset the field l10n_es_reports_mod349_invoice_type on an intra-community invoice (because of a mistake or an exception) the Mod349 will still report the invoice in the total number of intra community operators but no operation will be reported in the following section Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner - Make sure Mod349 Invoice Type is unset - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) Issue: Total number of intra-community operators is 1, but no operation is shown opw-4403287 Forward-Port-Of: odoo/enterprise#80458 Forward-Port-Of: odoo/enterprise#80253
ASP-ONE.FR is now a brand of Tessi Informatique and we have to update the information passed in the xml. task-4605970 Forward-Port-Of: odoo/enterprise#80219
Original PR description
ASP-ONE.FR is now a brand of Tessi Informatique and we have to update the information passed in the xml. task-4605970 Forward-Port-Of: odoo/enterprise#80219
This commit is a patch to the following PR: https://github.com/odoo/enterprise/pull/76478#discussion_r1946575309 Steps to reproduce the bug: - Create two storable products “P1” and “P2”: - Tracked by Serial Number - Create a quality control point: - Operation: Receipt - Control per: Quantity - Create a receipt: - 10 units of P1 - 10 units of P2 - Mark it as "To Do." - Open the detailed operation of P1: - Assign two SNs: - SN1 - SN2 - Save. - The “Quantity” f
Original PR description
This commit is a patch to the following PR: https://github.com/odoo/enterprise/pull/76478#discussion_r1946575309 Steps to reproduce the bug:
- Create two storable products “P1” and “P2”:
- Tracked by Serial Number
- Create a quality control point:
- Operation: Receipt
- Control per: Quantity
- Create a receipt:
- 10 units of P1
- 10 units of P2
- Mark it as "To Do."
- Open the detailed operation of P1:
- Assign two SNs: - SN1 - SN2 - Save.
- The “Quantity” field of the P1 move is updated to 2.
- Mark the move of P1 as "Picked."
- Validate the receipt.
- The backorder wizard is triggered → Validate it.
Problem:
A wizard to process the quality check is triggered, but 12 quality checks (2 for P1 and 10 for P2) are loaded instead of only 2 for P1.
Expected Behavior:
Quality checks should only be triggered for picked moves
opw-4442564
Forward-Port-Of: odoo/enterprise#80467"Customs" was translated to "Pedimiento" instead of "Pedimento". Have also updated / re-exported the po and pot files to keep them in sync. opw-4507567 Forward-Port-Of: odoo/enterprise#80511 Forward-Port-Of: odoo/enterprise#78933
Original PR description
"Customs" was translated to "Pedimiento" instead of "Pedimento". Have also updated / re-exported the po and pot files to keep them in sync. opw-4507567 Forward-Port-Of: odoo/enterprise#80511 Forward-Port-Of: odoo/enterprise#78933
There is no reason to not reset the payment exception state if an invoice is in draft and the subscription has not to be paid before the invoice. Also reset the next payment date on reset of the order/subscription and also make it eligible to be invoiced via cron. **Reproduction/Rationale**: - Have a scenario where the invoice of a subscription is proposed to be posted manually instead of automatically posting it - The order might be to be signed but not marked to be paid for acceptanc
Original PR description
There is no reason to not reset the payment exception state if an invoice is in draft and the subscription has not to be paid before the invoice. Also reset the next payment date on reset of the…
There is no reason to not reset the payment exception state if an invoice is in draft and the subscription has not to be paid before the invoice. Also reset the next payment date on reset of the order/subscription and also make it eligible to be invoiced via cron. **Reproduction/Rationale**: - Have a scenario where the invoice of a subscription is proposed to be posted manually instead of automatically posting it - The order might be to be signed but not marked to be paid for acceptance - Therefore the signature will confirm the order and the subscription will be invoiced via cron later - The draft is, as stated, not a failure but the wanted behavior in this scenario and no payment exception is possible because there is no payment related and created on confirmation. As the approach is to automatically put the order into a payment exception it is very important to catch ALL the scenarios where it needs to be removed. (this approach should be reconsidered in master IMO as it is a trap and rabbit hole) Info: @wt-io-it Forward-Port-Of: odoo/enterprise#79391
This PR aims to automatically set the status of a “Rejected” document to “Cancelled” while preserving the sequence number assigned by DGI (based on the CAE) to ensure all documents, including rejected ones, remain in the system with their original sequence. This is to maintain proper accounting records and provides visibility of all rejected documents. Forward-Port-Of: odoo/enterprise#76931
Original PR description
This PR aims to automatically set the status of a “Rejected” document to “Cancelled” while preserving the sequence number assigned by DGI (based on the CAE) to ensure all documents, including rejected ones, remain in the system with their original sequence. This is to maintain proper accounting records and provides visibility of all rejected documents. Forward-Port-Of: odoo/enterprise#76931
When settling the user account from `pos_settle_due`, we show a receipt with no order (as expected), but with an empty state saying "Start adding products"! This bug has been reported while using the `pos_settle_due` module, however, the fix has been made generic and hence been implemented in the `point_of_sale` module. This PR just adds the test specific to `pos_settle_due`. opw-4430325 Forward-Port-Of: odoo/enterprise#80332 Forward-Port-Of: odoo/enterprise#79454
Original PR description
When settling the user account from `pos_settle_due`, we show a receipt with no order (as expected), but with an empty state saying "Start adding products"! This bug has been reported while using the `pos_settle_due` module, however, the fix has been made generic and hence been implemented in the `point_of_sale` module. This PR just adds the test specific to `pos_settle_due`. opw-4430325 Forward-Port-Of: odoo/enterprise#80332 Forward-Port-Of: odoo/enterprise#79454
A non-deterministic behavior resulted in fetching unexpected IDs from the `hr_recruitment_stage_report`. The SQL query is fixed and the non-deterministic behavior is gone now. The non-deterministic behavior was because the view query uses `ROW_NUMBER()` to generate the IDs dynamically in each query before union which results in records with duplicate ids, resulting in non-deterministic behavior. Three CTEs were used. Two CTEs were used to simplify the two queries before the union. A `global_cte
Original PR description
A non-deterministic behavior resulted in fetching unexpected IDs from the `hr_recruitment_stage_report`. The SQL query is fixed and the non-deterministic behavior is gone now. The non-deterministic behavior was because the view query uses `ROW_NUMBER()` to generate the IDs dynamically in each query before union which results in records with duplicate ids, resulting in non-deterministic behavior. Three CTEs were used. Two CTEs were used to simplify the two queries before the union. A `global_cte` is used to union both CTEs. A `ROW_NUMBER() OVER()` is used to assign sequential integers to rows, along with a necessary `ORDER BY` clause to ensure deterministic behavior. task-4440977 Forward-Port-Of: odoo/enterprise#80446
We're adding support for recaptcha in appointment forms to prevent bots from easily filling up slots. In 17.0 cloudflare turnstile is added as an alternative and/or fallback for recaptcha. We adapt the js code to call the cloudflare client API which gives us support of this feature "for free" as all of the logic is already implemented for the check. task-4335141 Forward-Port-Of: odoo/enterprise#80498 Forward-Port-Of: odoo/enterprise#76672
Original PR description
We're adding support for recaptcha in appointment forms to prevent bots from easily filling up slots. In 17.0 cloudflare turnstile is added as an alternative and/or fallback for recaptcha. We adapt the js code to call the cloudflare client API which gives us support of this feature "for free" as all of the logic is already implemented for the check. task-4335141 Forward-Port-Of: odoo/enterprise#80498 Forward-Port-Of: odoo/enterprise#76672
Since this commit https://github.com/odoo/enterprise/commit/bd52a436a2e94aea53a3cf4cc07a39896f4ff967 if the order was already synchronized, the call to the blackbox was skipped. This is not the expected behavior, the blackbox should be called when paying an order, even if it was already synchronized so that the signature is given. Forward-Port-Of: odoo/enterprise#76277
Original PR description
Since this commit https://github.com/odoo/enterprise/commit/bd52a436a2e94aea53a3cf4cc07a39896f4ff967 if the order was already synchronized, the call to the blackbox was skipped. This is not the expected behavior, the blackbox should be called when paying an order, even if it was already synchronized so that the signature is given. Forward-Port-Of: odoo/enterprise#76277
This error occurs when we delete the user's role in the configuration and then attempt to ``Send`` the template in Templates. Steps to reproduce: - Install the ``Sign`` module - Sign > Configuration > Roles > Delete ``User`` role - Now go to ``Templates`` and Click on the ``Send`` and `Sign Now` buttons of any template Traceback: ``ValueError: External ID not found in the system: sign.sign_item_role_user`` The error in [1] occurred because the ``sign_item_role_user`` ID is missing
Original PR description
This error occurs when we delete the user's role in the configuration and then attempt to ``Send`` the template in Templates. Steps to reproduce: - Install the ``Sign`` module - Sign > Configuration > Roles > Delete ``User`` role - Now go to ``Templates`` and Click on the ``Send`` and `Sign Now` buttons of any template Traceback: ``ValueError: External ID not found in the system: sign.sign_item_role_user`` The error in [1] occurred because the ``sign_item_role_user`` ID is missing from the ``Sign`` model, as it was deleted. [1]- https://github.com/odoo/enterprise/blob/ec873122c01f5312e907a96e462ace794e12fe18/sign/wizard/sign_send_request.py#L132 sentry-5694515390 Forward-Port-Of: odoo/enterprise#70087
**Issue:** The formula of the cross report line for the 2024 variant of the balance sheet report is referencing a report line from the main profit and loss report instead of its 2024 variant. opw-4566689 opw-4590293 opw-4572865 Forward-Port-Of: odoo/enterprise#80551
Original PR description
**Issue:** The formula of the cross report line for the 2024 variant of the balance sheet report is referencing a report line from the main profit and loss report instead of its 2024 variant. opw-4566689 opw-4590293 opw-4572865 Forward-Port-Of: odoo/enterprise#80551
This PR addresses a payslip-calculating issue where overtime records right outside the payslip's period were being included in the calculations, messing up normal hours. The way this is fixed in this PR is by delaying the timezone-stripping code until it is necessary. This allows the local timezone variables, `date_from` and `date_to`, to be used to query the associated overtime records, rather than their UTC versions. We need this behavior because the "overtime" query depends on the field `
Original PR description
This PR addresses a payslip-calculating issue where overtime records right outside the payslip's period were being included in the calculations, messing up normal hours. The way this is fixed in this…
This PR addresses a payslip-calculating issue where overtime records right outside the payslip's period were being included in the calculations, messing up normal hours.
The way this is fixed in this PR is by delaying the timezone-stripping code until it is necessary. This allows the local timezone variables, `date_from` and `date_to`, to be used to query the associated overtime records, rather than their UTC versions. We need this behavior because the "overtime" query depends on the field `HrAttendanceOvertime.date`, which is of type `fields.Date` and is timezone-agnostic.
This bug can be replicated in any variation of the following scenario (this one assumes the payslip period covers exactly one month of work):
- Create an attendance record for employee `A` that would cause them to have `h` hours of overtime at the end of month `X`, where `X` is a number in the set `{1, 2, ..., 12}`.
- Create an attendance record for `A` on the 1st of the next month, `Y := X mod 12 + 1`, with `h'` regular hours and `0` hours of overtime.
- Generate their payslip for the month `Y`.
- See that there is an overtime line with `h` hours and a regular hours line with `h' - h` hours. 🐛
opw-4371083
Forward-Port-Of: odoo/enterprise#79259
Forward-Port-Of: odoo/enterprise#78880This commit adds new tax ISR 1.25 witheld for mexican localization target: 17 -> master task-4486643 Linked PR: [odoo/odoo#195346](https://github.com/odoo/odoo/pull/195346) Forward-Port-Of: odoo/enterprise#80126 Forward-Port-Of: odoo/enterprise#80081
Original PR description
This commit adds new tax ISR 1.25 witheld for mexican localization target: 17 -> master task-4486643 Linked PR: [odoo/odoo#195346](https://github.com/odoo/odoo/pull/195346) Forward-Port-Of: odoo/enterprise#80126 Forward-Port-Of: odoo/enterprise#80081
This commit adds 2 major module for handling SIE4 files within Odoo. Even though the SIE5 is already available in Odoo, the majority of the Swedish userbase still uses SIE4 (or below) for importing and exporting accounting data. In addition to the new features below, this commit also renames the current odoo implementation of SIE5 from just "SIE" to "SIE 5" to avoid confusion between the two. This first implementation does not at all consider the effects of the `#OBJEKT` and `#DIM` (or
Original PR description
This commit adds 2 major module for handling SIE4 files within Odoo. Even though the SIE5 is already available in Odoo, the majority of the Swedish userbase still uses SIE4 (or below) for importing…
This commit adds 2 major module for handling SIE4 files within Odoo. Even though the SIE5 is already available in Odoo, the majority of the Swedish userbase still uses SIE4 (or below) for importing and exporting accounting data. In addition to the new features below, this commit also renames the current odoo implementation of SIE5 from just "SIE" to "SIE 5" to avoid confusion between the two. This first implementation does not at all consider the effects of the `#OBJEKT` and `#DIM` (or other similar dimension) items. --- ### SIE4 Import - `l10n_se_sie4_import` Odoo can now import accounting data from SIE of type 4 and below (thanks to backward-compatibility of SIE format). SIE4 files are designed as a text file with label on each line and its contents. One item can be referred by another item down the file, so we need a variable (`data_map`) to save the required information for future use, in-between the reading process. From the SIE4 file, we can then import the following data: company, chart of accounts, fiscal year, and move informations. An option will be provided when creating the wizard to allow user to choose whether they'd like to import opening balance move, and/or update any duplicate accounts already found in their company with the one in the file. --- ### SIE4 Export - `l10n_se_sie4_export` Odoo's implementation of exporting SIE4 files are placed in the General Ledger view's export buttons, similar to other import implementation like SAF-T and Libros. To be able to export SIE4 file, the date periods in the selected options must be of type fiscal year, and exporting multiple companies at once is forbidden. --- [SIE 4 documentation](https://sie.se/wp-content/uploads/2020/05/SIE_filformat_ver_4B_ENGLISH.pdf) task-id: 3735808 Forward-Port-Of: odoo/enterprise#80344 Forward-Port-Of: odoo/enterprise#66263
- Positive-Negative total amounts were set to `''` instead of `'000000000000000'` when they were zero. - In the descriptive field there's now the reconciled moves name and not the batch payment name. - File import we use for troubleshooting used to read the field `creditor_sia_code` as `int` but it's `alnum`. - `negative_amount` amount was the sum of the payment amounts, and it has some rounding differences. Now I'm using the Batch Payment amount. - The total in the description field of each
Original PR description
- Positive-Negative total amounts were set to `''` instead of `'000000000000000'` when they were zero. - In the descriptive field there's now the reconciled moves name and not the batch payment name. - File import we use for troubleshooting used to read the field `creditor_sia_code` as `int` but it's `alnum`. - `negative_amount` amount was the sum of the payment amounts, and it has some rounding differences. Now I'm using the Batch Payment amount. - The total in the description field of each payment section is correct, but it was rounded incorrectly instead in another field on the first row of the section. - Now using ASCII instead of UTF8 - accents are changed to apostrophes as per the Company Registry in Italy - `payment_date` in record `14` should be `invoice_date_due` - Test has been adjusted. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4535559) opw-4535559 Forward-Port-Of: odoo/enterprise#80538 Forward-Port-Of: odoo/enterprise#78827
Following feedbacks from partners and clients, we add the following improvements: - Employee Address on the payslip - Employee bank account on the payslip - Private phone and email on the employee view Forward-Port-Of: odoo/enterprise#80366
Original PR description
Following feedbacks from partners and clients, we add the following improvements: - Employee Address on the payslip - Employee bank account on the payslip - Private phone and email on the employee view Forward-Port-Of: odoo/enterprise#80366
- update upper and lower limits for nssf parameter Task: 4599150 Forward-Port-Of: odoo/enterprise#80016
Original PR description
- update upper and lower limits for nssf parameter Task: 4599150 Forward-Port-Of: odoo/enterprise#80016
In Knowledge, in the Calendar embed, event text descriptions and properties tend to overlap with each other, and the header. The Calendar embed also does not resize properly when the sidebar width or article width get changed. This commit makes it so that event descriptions and properties do not overlap ; and that calendar width (and, subsequently, column width) is affected by sidebar or article width changes. task-4558391 Forward-Port-Of: odoo/enterprise#79164
Original PR description
In Knowledge, in the Calendar embed, event text descriptions and properties tend to overlap with each other, and the header. The Calendar embed also does not resize properly when the sidebar width or article width get changed. This commit makes it so that event descriptions and properties do not overlap ; and that calendar width (and, subsequently, column width) is affected by sidebar or article width changes. task-4558391 Forward-Port-Of: odoo/enterprise#79164
When confirming a vendor bill imported from an uploaded document and pressing the "Update SAT" button, the SAT state is not updated. This commit adds the missing EDI document state, `invoice_received`, in a validation that triggers the update of the SAT state for the current invoice. Steps to reproduce: <img width="1301" alt="Screenshot 2025-02-13 at 11 23 47 PM copy" src="https://github.com/user-attachments/assets/bad64936-bae1-4846-8cde-12f6d1748d46" /> <img width="1301" alt="Screenshot 2
Original PR description
When confirming a vendor bill imported from an uploaded document and pressing the "Update SAT" button, the SAT state is not updated. This commit adds the missing EDI document state,…
When confirming a vendor bill imported from an uploaded document and pressing the "Update SAT" button, the SAT state is not updated. This commit adds the missing EDI document state, `invoice_received`, in a validation that triggers the update of the SAT state for the current invoice. Steps to reproduce: <img width="1301" alt="Screenshot 2025-02-13 at 11 23 47 PM copy" src="https://github.com/user-attachments/assets/bad64936-bae1-4846-8cde-12f6d1748d46" /> <img width="1301" alt="Screenshot 2025-02-13 at 11 24 12 PM copy" src="https://github.com/user-attachments/assets/b4a839c2-a5ab-4638-b46d-3eb9ccf1b59d" /> <img width="1307" alt="Screenshot 2025-02-13 at 11 26 30 PM copy" src="https://github.com/user-attachments/assets/14645d48-5e90-405c-8a36-3ec7b0af50ef" /> <img width="1306" alt="Screenshot 2025-02-13 at 11 26 47 PM copy" src="https://github.com/user-attachments/assets/839349bf-be83-408a-bbd4-676d84a34493" /> <img width="1305" alt="Screenshot 2025-02-13 at 11 26 57 PM copy" src="https://github.com/user-attachments/assets/1e3773de-f3ab-47b4-9548-b5633c078943" /> Actual result: <img width="1306" alt="Screenshot 2025-02-13 at 11 27 08 PM copy" src="https://github.com/user-attachments/assets/a385847e-20cc-4410-8802-6d6b2c363633" /> Expected result: <img width="1307" alt="Screenshot 2025-02-13 at 11 27 49 PM copy" src="https://github.com/user-attachments/assets/8974cd49-13b6-40c0-8fa2-fd1fce45faf3" /> Forward-Port-Of: odoo/enterprise#79443 Forward-Port-Of: odoo/enterprise#79314