Friday, October 25, 2024
129 changes
18 changes
Enhancements to existing features
Commission purchase orders are now grouped across multiple salespeople when they relate to the same partner, reducing the number of documents created. This lowers processing effort for accounting teams while keeping salespeople able to access the relevant purchase orders.
Original PR description
Previously, commission POs would be grouped per salesperson. In large companies commission is generated through different salespeople which leads to many POs to the same partner. This causes more overhead for the accounting teams on both sides: there are more POs to process on one side, and more invoices to process on the other. To minimize the number of POs, we remove the salesperson from the domain and stop assigning them as user_id (there can now be multiple). To ensure they keep access to the same POs as before, we add them as a follower on the PO and modify the record rule to take this into account. task-4250635
The Planning app now includes clearer demo examples showing how employee shifts and allocated hours vary across different contract periods. This helps business users better understand and evaluate contract-based planning scenarios during demonstrations or testing.
Original PR description
- master Before this commit, there was not quite much demo data to showcase about shifts and its allocated hours depending on various contracts of employees. This commit adds demo data to show shifts allocated to resource depending on their different contract period. task-3128491
Resolved issues and error corrections
This update aligns Odoo spreadsheet side panels with recent spreadsheet engine changes, improving consistency in menus, titles, fonts, and chart controls. It also adds test coverage for pivot autocomplete behavior to help prevent regressions in spreadsheet reporting features.
Miscellaneous changes
Fixed onboarding Social Marketing tour which is not working properly. Reason ====== We're not getting this `'textarea[name="message"]` for some reasons, & there is no `name` attribute in textarea. Also, we removed `extra_tringger` in later version, and we can use `run: 'edit` instead so removed that & used common classes that works on all version. Task-4210376 Forward-Port-Of: odoo/enterprise#72754 Forward-Port-Of: odoo/enterprise#71016
Original PR description
Fixed onboarding Social Marketing tour which is not working properly. Reason ====== We're not getting this `'textarea[name="message"]` for some reasons, & there is no `name` attribute in textarea. Also, we removed `extra_tringger` in later version, and we can use `run: 'edit` instead so removed that & used common classes that works on all version. Task-4210376 Forward-Port-Of: odoo/enterprise#72754 Forward-Port-Of: odoo/enterprise#71016
11 changes
New functionality added to Odoo
This update adds support for Zengin, Japan's primary bank payment system, enabling businesses to process batch payments and import bank statements directly through Odoo. The integration currently supports text file formats and streamlines payment processing for Japanese companies using the platform.
Original PR description
- Add support for batch payment via Zengin and bank statement import - Currently only support txt files task-3304270
In this commit, we close active modals when the focussed element of a step (trigger) is below the modal. https://github.com/odoo/odoo/pull/185231 Forward-Port-Of: odoo/enterprise#72756
Original PR description
In this commit, we close active modals when the focussed element of a step (trigger) is below the modal. https://github.com/odoo/odoo/pull/185231 Forward-Port-Of: odoo/enterprise#72756
### Steps to reproduce the issue: 1. In a Multi-Company setup with different Charts of Accounts, create (or find) a Report with Availability set to Chart of Account Matches - For example, you can use Belgian Profit and Loss or Balance Sheet reports 2. With multiple companies visible, including the one with the correct Chart of Accounts, go to the Root Report of the one you created (or found) 3. Under the Report Variants filter, the "coa" Report can not be found, or the filter is simply
Original PR description
### Steps to reproduce the issue: 1. In a Multi-Company setup with different Charts of Accounts, create (or find) a Report with Availability set to Chart of Account Matches - For example, you can use…
### Steps to reproduce the issue:
1. In a Multi-Company setup with different Charts of Accounts, create (or find) a Report with Availability set to Chart of Account Matches
- For example, you can use Belgian Profit and Loss or Balance Sheet reports
2. With multiple companies visible, including the one with the correct Chart of Accounts, go to the Root Report of the one you created (or found)
3. Under the Report Variants filter, the "coa" Report can not be found, or the filter is simply not displayed
### Explanation:
When looking for variants with `availability_condition="coa"`, the current condition is for `companies.mapped("chart_template")` to consist of only `account.report.chart_template`.
Before 18.0, `account.report` using `account.account.code` as filter retrieved accounts from all active companies. `account.account` with a `code` corresponding to the request, even if their function is not the same, would be added into the report, falsing the amounts as a result.
### Fix reasoning:
Since 18.0, with commits odoo/odoo@854c3b27aa5476c208572f19e64f8f3364bfc381 and odoo/enterprise@92bf8e36c40f99c697318ddc9784cde0a1b3736e, `account.account.code` became company dependent, and only `self.env.company` is used to retrieve them in `account.report`.
Thanks to this change, `availability_condition="coa"` does no longer require a restriction to environments where all companies have `account.report.chart_template`.
opw-4263627
Forward-Port-Of: odoo/enterprise#72365When deleting the measure on which the pivot is sorted, the side panel would crash. This commit fixes this issue by removing the sortedColumn from the pivot when the measure is deleted. Task: [4154831](https://www.odoo.com/web#id=4154831&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#72684 Forward-Port-Of: odoo/enterprise#69926
Original PR description
When deleting the measure on which the pivot is sorted, the side panel would crash. This commit fixes this issue by removing the sortedColumn from the pivot when the measure is deleted. Task: [4154831](https://www.odoo.com/web#id=4154831&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#72684 Forward-Port-Of: odoo/enterprise#69926
### Steps to reproduce: - Create and configure a Sendcloud shipping method - Create a Contact Bob - Create a subconcat of type delivery for Bob without setting any name > by default its display name will be "Bob, delivery address" - Create a sale order for Bob - Add a Sendcloud shipment method to that SO and confirm the SO - Go on the associated delivery and try to validate it ### Expected behavior: You should raise a user error telling you that you a pickup point was required fo
Original PR description
### Steps to reproduce: - Create and configure a Sendcloud shipping method - Create a Contact Bob - Create a subconcat of type delivery for Bob without setting any name > by default its display name…
### Steps to reproduce: - Create and configure a Sendcloud shipping method - Create a Contact Bob - Create a subconcat of type delivery for Bob without setting any name > by default its display name will be "Bob, delivery address" - Create a sale order for Bob - Add a Sendcloud shipment method to that SO and confirm the SO - Go on the associated delivery and try to validate it ### Expected behavior: You should raise a user error telling you that you a pickup point was required for the selected shipping method. ### Current behavior: You raise a traceback prior to that point. ### Cause of the issue: Since you did not set a name on your delivery partner the code will break as soon as you try to generate the parcels data because "False" is not iterable, see: https://github.com/odoo/enterprise/blob/37577535a4482eaa1250b41136b47b3613eb7693/delivery_sendcloud/models/sendcloud_service.py#L576-L577 ### Fix: If for some reason the name of the delivery partner has been removed or was unset (e.g. display name is of the form: Bob, Delivery address), the name of its parent should be used to generate the parcel data. Note: This fix should normally not be that relevant, because, if you were to select a pickup point, the partner used to generate the parcel would already be the parent partner and is guarranteed to have a name: https://github.com/odoo/enterprise/blob/37577535a4482eaa1250b41136b47b3613eb7693/delivery_sendcloud/models/sendcloud_service.py#L556-L561already However, now, if you proceed with this flow without any pickup point (which you can only select form the website) you will now raise a relevant user error: #### Invalid Operation: "A service point is required for the selected shipping method" opw-4118362 Forward-Port-Of: odoo/enterprise#72076
Before this commit, in single app mode (only studio is installed), a tour failed because we added approvals on a button on the Form View of Apps without specifying which. At the end of the day, a module got actually installed which triggered a lot of crashes, including the tour itself and a few low-level cursor-related functions. After this commit, we precisely specify in the tour on which button and function we make approvals for. The tour succeeds and there is no crash. Forward-Port-Of: od
Original PR description
Before this commit, in single app mode (only studio is installed), a tour failed because we added approvals on a button on the Form View of Apps without specifying which. At the end of the day, a module got actually installed which triggered a lot of crashes, including the tour itself and a few low-level cursor-related functions. After this commit, we precisely specify in the tour on which button and function we make approvals for. The tour succeeds and there is no crash. Forward-Port-Of: odoo/enterprise#72702
Steps to reproduce the issue: 1. Install the MRP module 2. Go to Production Analysis 3. Click on the pivot table 4. Select the `Expected component cost / unit` field 5. The miscalculation will be show for `expected_component_cost_unit`. It is dividing by the MO quantity produced rather than the BOM quantity. Explanation: The issue lies in the SQL query, where the expected cost is divided by `prod_qty.product_quantity`, meaning we are using the quantity produced by a MO. instead,
Original PR description
Steps to reproduce the issue: 1. Install the MRP module 2. Go to Production Analysis 3. Click on the pivot table 4. Select the `Expected component cost / unit` field 5. The miscalculation will be show for `expected_component_cost_unit`. It is dividing by the MO quantity produced rather than the BOM quantity. Explanation: The issue lies in the SQL query, where the expected cost is divided by `prod_qty.product_quantity`, meaning we are using the quantity produced by a MO. instead, it should be divided by the BOM quantity. Fix reasoning: With this commit, the issue is resolved by dividing the expected cost by the BOM `product_qty`. Forward-Port-Of: odoo/enterprise#72647 Forward-Port-Of: odoo/enterprise#69905
Column L and M were static (hardcoded dates) Task: 4268760 Forward-Port-Of: odoo/enterprise#72445
Original PR description
Column L and M were static (hardcoded dates) Task: 4268760 Forward-Port-Of: odoo/enterprise#72445
Forward-Port-Of: odoo/enterprise#72577
Original PR description
Forward-Port-Of: odoo/enterprise#72577
Steps to reproduce: - multi-currency - upload an expense with a differenct currency than the company - OCRize it Issue: The exchange rate is always 1:1 Cause: We don't fetch the echange rate with OCR and the compute's cannot fetch it since we cill never satisfy the condition https://github.com/odoo/odoo/blob/86b748dc91f7260b30c6944fd906a4d68ec1849b/addons/hr_expense/models/hr_expense.py#L251-L261 Solution: Fetch the exchange rate directly during the process of the extracted data.
Original PR description
Steps to reproduce: - multi-currency - upload an expense with a differenct currency than the company - OCRize it Issue: The exchange rate is always 1:1 Cause: We don't fetch the echange rate with OCR and the compute's cannot fetch it since we cill never satisfy the condition https://github.com/odoo/odoo/blob/86b748dc91f7260b30c6944fd906a4d68ec1849b/addons/hr_expense/models/hr_expense.py#L251-L261 Solution: Fetch the exchange rate directly during the process of the extracted data. I differed the write operation at the end to avoid unwanted computed that could overwrite what we need. opw-4151571 Forward-Port-Of: odoo/enterprise#72112
Steps to reproduce: - Sign app > Upload a PDF & Sign - Add a Date field > Sign Now > Sign Now - Click the date field The value 'undefined' fills the field instead of today's date. This was caused by an oversight when resolving a conflict in https://github.com/odoo/enterprise/pull/71864, the query selector should have grabbed the date from the HTML document but didn't. opw-4278391 Forward-Port-Of: odoo/enterprise#72574
Original PR description
Steps to reproduce: - Sign app > Upload a PDF & Sign - Add a Date field > Sign Now > Sign Now - Click the date field The value 'undefined' fills the field instead of today's date. This was caused by an oversight when resolving a conflict in https://github.com/odoo/enterprise/pull/71864, the query selector should have grabbed the date from the HTML document but didn't. opw-4278391 Forward-Port-Of: odoo/enterprise#72574
Steps to reproduce: - install Documents and CRM - login as Marc Demo - go to any pivot view - click on "Insert in spreadsheet" - select the Dashboards tab and confirm => boom Task: 4273554 Forward-Port-Of: odoo/enterprise#72711 Forward-Port-Of: odoo/enterprise#72395
Original PR description
Steps to reproduce: - install Documents and CRM - login as Marc Demo - go to any pivot view - click on "Insert in spreadsheet" - select the Dashboards tab and confirm => boom Task: 4273554 Forward-Port-Of: odoo/enterprise#72711 Forward-Port-Of: odoo/enterprise#72395
… partners This enhancement introduces an XLSX export variant for the trial balance, specifically tailored for Colombian companies under the report name "BALANCE DE PRUEBA POR TERCERO." The requirement is to provide a detailed breakdown per partner for each account. The initial trial balance lines are primarily derived from the general ledger report, which originally focused on grouping by accounts. Inspired by the structure of the general ledger accounts, this implementation now extends t
Original PR description
… partners This enhancement introduces an XLSX export variant for the trial balance, specifically tailored for Colombian companies under the report name "BALANCE DE PRUEBA POR TERCERO." The requirement is to provide a detailed breakdown per partner for each account. The initial trial balance lines are primarily derived from the general ledger report, which originally focused on grouping by accounts. Inspired by the structure of the general ledger accounts, this implementation now extends the grouping to include both accounts and partners. While initially designed for the Colombian localization, the code is flexible and can be easily adapted for use in other localizations as needed. Co-authored-by: Brice Bartoletti <bib@odoo.com> task-3594546 Forward-Port-Of: odoo/enterprise#72471 Forward-Port-Of: odoo/enterprise#70110
Currently, Odoo supports several currencies (USD, EUR, JPY, GBP) for Banxico data parsing, but CNY (Chinese Yuan) is missing. This commit adds support for CNY in the list of currencies retrieved from Banxico’s API (through iap proxy). related pr: https://github.com/odoo/iap-apps/pull/912 task-4205613 Forward-Port-Of: odoo/enterprise#72202
Original PR description
Currently, Odoo supports several currencies (USD, EUR, JPY, GBP) for Banxico data parsing, but CNY (Chinese Yuan) is missing. This commit adds support for CNY in the list of currencies retrieved from Banxico’s API (through iap proxy). related pr: https://github.com/odoo/iap-apps/pull/912 task-4205613 Forward-Port-Of: odoo/enterprise#72202
When there are no journals and the user tries to open the balance sheet report, a traceback will appear. Steps to reproduce the error: - Install ``account_reports`` module without demo data - Remove all journals - Go Reporting > Open Balance sheet Traceback: ``` StopIteration: null File "odoo/http.py", line 2364, in __call__ response = request._serve_db() File "odoo/http.py", line 1891, in _serve_db return self._transactioning( File "odoo/http.py", line 1954, in _t
Original PR description
When there are no journals and the user tries to open the balance sheet report, a traceback will appear. Steps to reproduce the error: - Install ``account_reports`` module without demo data - Remove…
When there are no journals and the user tries to open the balance sheet report,
a traceback will appear.
Steps to reproduce the error:
- Install ``account_reports`` module without demo data
- Remove all journals
- Go Reporting > Open Balance sheet
Traceback:
```
StopIteration: null
File "odoo/http.py", line 2364, in __call__
response = request._serve_db()
File "odoo/http.py", line 1891, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1954, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1921, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2168, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 330, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 728, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "home/odoo/src/enterprise/18.0/account_reports/models/account_report.py", line 1914, in get_options
initializer(options, previous_options=previous_options)
File "home/odoo/src/enterprise/18.0/account_reports/models/account_report.py", line 379, in _init_options_journals
options['journals'].extend(next(iter(company_journals_map.values())))
```
https://github.com/odoo/enterprise/blob/302eb1052609462fe607f77fcc934690f9abbe5a/account_reports/models/account_report.py#L379
When there are no journals ``company_journals_map`` will be empty,
So, it will lead to the above traceback.
sentry-5993507281
Forward-Port-Of: odoo/enterprise#72072Enhancements to existing features
This update enhances the performance of the VAT Book report by limiting the number of displayed lines, preventing browser overload. A warning message is now shown if lines are hidden, ensuring users are informed and avoiding unexpected behavior. The change improves report loading times for large datasets.
Original PR description
When this report contained too many lines (~6000), the browser couldn't handle the load and did not manage to render it. This is a known case, which normally only happens with line expansion, for…
When this report contained too many lines (~6000), the browser couldn't handle the load and did not manage to render it. This is a known case, which normally only happens with line expansion, for which the prefix groups and load more features have been made. In this case, though, it's a bit different, as those lines are directly at the root of the report (they don't come from a line expansion). We make the choice here to use the load_more_limit anyway as a means to put a limit to the number of lines that are shown. When this limit is reached, we just don't display the exceeding lines, and replace them by a summary line. To avoid confusion, a warning is now shown on top of the report when some lines need to be hidden. Since such a warning requires a module update (because it's a template, and needs to exist in db), we only apply our new trimming mechanism if the warning template exists (and can hence be displayed). This way, we won't change the behavior on existing databases without being sure the user is properly notified. Plus, thanks to that, we're sure the old load_more_limit value (originally 80 by default) set on the VAT Book will have been increased to a value fitting our use case more, so we won't bother people with excessive trimming. Original fix suggestion raised here by Adhoc: https://github.com/odoo/enterprise/pull/45936 Forward-Port-Of: odoo/enterprise#72096
This update optimizes how Odoo searches for documents, making it faster to find files based on the related model and ID. Similar to how attachments are searched, this change enhances the efficiency of document retrieval, particularly when using complex search criteria. This improves overall user experience and system performance.
Original PR description
Add a compound index on (`res_model`, `res_id`) to support domains searching documents based on those criteria, similarly to `ir_attachment_res_idx` on `ir.attachment`.
Resolved issues and error corrections
This pull request addresses several minor issues impacting the shop floor experience in Odoo Enterprise. Specifically, it corrects inaccurate quantity displays during production steps and improves filtering of workorders linked to shop floor workcenters, ensuring data consistency and a more reliable workflow. These changes enhance the accuracy of production tracking and reporting.
Original PR description
Collection of small shop floor fixes for v17. Please refer to the individual feature commits for details.
This update resolves a visual bug where the 'Start' button on the sign document flow was obscured. The issue stemmed from a stacking order problem with the sign navigator item. By increasing the z-index, the 'Start' button is now correctly displayed and functional, ensuring a smooth user experience.
Original PR description
Versions: ------------ 17.0 Steps to Reproduce: ----------------------------- 1. go to sign document 2. add sign item in document 3. click on sign document now 4. click on start seems be not working properly 5. video link: https://nimb.ws/WKMlFjB Issue: ------- stacking order of sign item navigator seems to be low Solution: ------------ increase z-index value of `o_sign_sign_item_navigator`. task-4191542
This update fixes a bug where the 'past' filter on the Odoo portal's appointment section was being unintentionally removed from the URL, causing users to lose their filter settings. The fix ensures that the 'past' filter remains active and persistent across multiple pages of appointments, improving the user experience. This resolves a reported issue impacting appointment scheduling functionality.
Original PR description
steps: -> populate the portal user's appointments with enough appointments to have multiple pages in the portal -> go on the portal, filter by "past" -> go to page 2 --> the filter by "past" is removed from the url opw-4236596 Forward-Port-Of: odoo/enterprise#71965
This update resolves an issue where Brazilian service invoices were incorrectly generating HS codes, leading to validation errors with Avalara. Avalara support clarified that service invoices require periods to be kept but leading zeroes to be removed, a change now implemented to ensure compliance with local tax regulations.
Original PR description
Some cities that process service invoices [1] have stricter hsCode validations than others and error on the hsCode we send. Avalara requires periods to be removed from the hsCode field for goods transactions. This was already the case. For services they inform us that the periods should be kept but leading zeroes should be stripped [2]. [1] e.g. Belo Horizonte [2] There's no documentation on this. This was specified by Avalara support in an internal support ticket. opw-4009684
This update fixes an issue where quality checks weren't visible for finished lots linked to manufacturing orders. The change ensures that the quality check button is always displayed when a finished lot's serial number is accessed, streamlining the process of verifying product quality.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Tracked with SN
- Create a BoM:
- no need to component
- Add an operation “OP1” with steps
- Control by product
- Create a manufacturing order for one unit of P1
- Confirm the MO
- Go to the shop floor and process “OP1”
- Validate the MO
- Go to the SN of P1
Problem:
The quality check smart button is not displayed, while the SN is linked to a QC.
opw-4189396This update fixes a reporting issue where the Aged Payable report incorrectly displayed partners with zero balances when storno accounting was enabled. The fix addresses a technical detail in how the system checks for open balances within storno transactions, ensuring accurate reporting of outstanding amounts.
Original PR description
To reproduce: 1) Activate storno accounting in the settings 2) Create a new partner 3) Create a Vendor Credit Note for that partner, post it 4) Register a full payment for the credit note 5) Open the Aged Payable report ====> The partner appears in the report, even though it has an amount of 0. It shouldn't, since there is no open amount for it. This was due to the way we checked the amount of the credit note was zero. In storno, the payable line of the refund is a negative credit instead of being a debit. Still, it's linked through the debit_move_id field to the partial reconcile. So, removing the debit from the debit or credit from the credit wasn't enough in that setup. opw-4166891 Forward-Port-Of: odoo/enterprise#72422
This update resolves an issue where bank reconciliation in multiple currencies (like USD and MXN) could lead to small, unmatched amounts, particularly impacting EDI validation for localized accounting systems. The change allows users to adjust exchange amounts within the bank reconciliation process, ensuring accurate matching and compliance. This improves the reliability of financial reporting.
Original PR description
Let's say you have: - One statement line of 3000 USD / 1000 MXN (rate 1:3) - Three invoices of 1000 USD / 500MXN (rate 1:2) => If you reconcile in the bank widget, the statement entry amounts will be divided by 3 ending with 3 lines of 1000 USD and 333.33 MXN leaving a 0.01 unmatched. This can be an issue for the validation of payment EDI for localizations like Mexican one. This PR gives more flexibility to user when dealing when bank reconciliation in multiple currencies by allowing to edit amounts on generated exchange moves to allocate this small difference. opw-4128899
This fix prevents the salary configurator from overwriting existing employee user names and identifiers (like trigrams). When an employee already has a user account set up with specific naming conventions, the system will now preserve that information instead of replacing it with values entered in the salary configurator.
Original PR description
Purpose ======= If there is already a user for a given employee (including a trigram for instance), we should avoid erasing it to the value the employee encodes on the salary configurator.