Daily updates from Odoo
Monday, March 11, 2024
13 changes · saas-17.1
Resolved issues and error corrections
A bug preventing the partner autocomplete from appearing during invoice creation has been fixed. This update ensures users can quickly and easily find and select partners when entering invoice data, improving efficiency. The fix addresses a change in how new invoices are created.
Original PR description
Steps to reproduce: [account, iap credit] - create a new invoice - start to write "test" for the partner Issue: The partner autocomplete is not displayed Cause: in https://github.com/odoo/odoo/pull/150106 we add a condition for the quickCreate bypassing the possibility of having createEdit set to true opw-3698400 Forward-Port-Of: odoo/odoo#154771 Forward-Port-Of: odoo/odoo#153608
This update addresses a warning that appears when modules incorrectly configure post-load methods. The change ensures that post-load methods are handled consistently, preventing potential issues during module loading and testing. This improves the stability and reliability of Odoo.
Original PR description
-Step to reproduce: add a post_load method in the init of any module, specify in the manifest like : 'post_load': 'post_load'. Run test_manifests of the test_lint module and we will get warning 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#156347 Forward-Port-Of: odoo/odoo#154316
This update fixes an issue where exchange rate differences were being incorrectly recorded as journal entries, leading to reconciliation problems. The change ensures that exchange rate differences are handled correctly, preventing duplicate AML creation and improving the accuracy of financial reporting. It adjusts the currency of exchange difference AMLs to zero, aligning with best practices.
Original PR description
When mixing anglo-saxon accounting and multi-currency, it sometimes leads to incorrect AMLs in the stock-in account To reproduce the issue: (Company in USD) 1. Setup some currency rates: - Yesterday:…
When mixing anglo-saxon accounting and multi-currency, it sometimes leads to incorrect AMLs in the stock-in account To reproduce the issue: (Company in USD) 1. Setup some currency rates: - Yesterday: 1000 EUR = 4335.1 USD - Today: 1000 EUR = 4348.0 USD 2. Create an auto-avco product 3. (Yesterday) Buy one product at 1000 EUR and receive it 4. Deliver the product 5. Bill the PO 6. Open the journal items of stock-in account Error: The AML for the exchange difference has been created twice When posting the bill, it leads to `_generate_price_difference_vals` where we generate AML/SVL in case of price differences. There, we also generate such records in case of exchange difference. This is what we do in the above use case. However, the AML is wrongly encoded, we need to respect some specific conditions: https://github.com/odoo/odoo/blob/d780a2fc73259244411329027349fad1cb353f34/addons/account/models/account_move_line.py#L1773-L1779 Otherwise, the reconciliation process won't work correctly and will generate its own AMLs for the exchange difference (hence the above error). On top of that, to ensure a full reconciliation, we need to first reconcile the exchange diff AML with the bill one. This is what we are supposed to do in `/stock_account`: we split all stock-in AMLs into three recordsets: `correction_amls`, `invoice_aml`, `stock_aml`. However, we don't correctly isolate the correction AMLs. Therefore, we try to reconcile all AMLs at once, which will not work. Note: This commit brings a behaviour change since the amount currency of exch-diff AML will now be zero, as it should (again, see the comment of the code quoted above in the reconciliation process). This also explains why this commit modifies an existing test: comparing the `balance` and the `amount_currency` of such AML is incorrect. OPW-3544318 Forward-Port-Of: odoo/odoo#156951 Forward-Port-Of: odoo/odoo#155421
This update allows users to select a temporary account when creating a branch company within Point of Sale. Previously, this setting was unavailable, leading to inconsistencies in accounting. Now, branch companies can be properly configured for accurate financial reporting.
Original PR description
**Before this PR:** When the user creates a branch company, the pos(accounting) setting does not allow the selection of a default temporary account for the user. **After this PR:** The user is allowed to choose a temporary account from the branch company. **Task**-3775873 Forward-Port-Of: odoo/odoo#156478
This update enhances the accuracy of location data recorded during employee attendance. Previously, location information was limited, now it provides a more precise record of where employees are working, improving attendance tracking and reporting. This change ensures better data for payroll and operational insights.
Original PR description
task-3764355 Forward-Port-Of: odoo/odoo#155159
This update fixes an issue where the order confirmation page and preparation display weren't activated when orders had a zero total amount. Now, the confirmation page and order sending process are consistently triggered upon order confirmation, regardless of the order total.
Original PR description
The confirmation page wasn't displayed and the order wasn't sent to the preparation display when confirming an order with a total of 0. Now the confirmation page is displayed and the order is send to the preparation display when the order is confirmed regardless of the total amount. Forward-Port-Of: odoo/odoo#157028
This update fixes an issue where invoices received into Odoo with an empty MISC journal would incorrectly assign a sequence number, regardless of the invoice type. The fix ensures the sequence is recalculated when the move's type is set, guaranteeing accurate VAT processing for Italian businesses. This improves the reliability of financial data.
Original PR description
Currently, if you have an empty MISC journal and receive a document, that document will be assigned a MISC sequence, regardless of the actual document's type. ### Cause When a document is received, it is processed in two steps: 1. An empty account move is created and linked with the document. 2. The newly created move is populated with data extracted from the document. At stage 1, when the move is created, it is temporarily placed in the MISC journal. In the event that this journal is empty, a sequence is assigned to the move. Consequently, even if the move's journal is subsequently changed, the sequence remains unaltered. ### Fix Manually recompute the sequence when the move's type is set. opw-3663873 Forward-Port-Of: odoo/odoo#155887
This update resolves an issue where the old job search route (`/jobs`) caused errors due to changes in how search parameters were handled. The fix automatically redirects users to the new route, preserving any search criteria entered to ensure a seamless and accurate job search experience.
Original PR description
__Current behavior before commit:__ `/jobs` routes have been modified in [this commit][1]. Old ones are deprecated but are still working for backward compatibility. When searching on this page,…
__Current behavior before commit:__ `/jobs` routes have been modified in [this commit][1]. Old ones are deprecated but are still working for backward compatibility. When searching on this page, search params are now just added at the end of the URL (instead of being part of the path like before). If the URL of the page is a deprecated one, this can create a conflict with the previous way the params were handled and produce an error. __Description of the fix:__ Redirect the user to the new route any time he tries to reach the deprecated ones. Any parameters included in the old URL will be carried over to the new route to maintain expected behavior. If a parameter is provided both in the path and as a kwarg, the kwarg value will take precedence. __Steps to reproduce the issue on runbot:__ 1. Go to `/jobs/country/20` 2. Make a search using the search bar -> Crash opw-3781374 [1]: https://github.com/odoo/odoo/commit/54f246f9c75b8f1ebdc637c6000f3e4773d702d5 Forward-Port-Of: odoo/odoo#157079 Forward-Port-Of: odoo/odoo#156918
This update resolves an issue where Odoo invoices were failing due to timezone discrepancies between the server and user locations. Specifically, when creating invoices near midnight, a date check triggered an error. The fix ensures the system correctly handles timezones, preventing these errors and improving invoice processing reliability.
Original PR description
When trying to process invoices at a time close to Midnight, and the user is using the system from a location different from the hosting location of Odoo, the system tries to check that the date of…
When trying to process invoices at a time close to Midnight, and the user is using the system from a location different from the hosting location of Odoo, the system tries to check that the date of the invoice is the same as the current date of the system. This creates problems when the hosting server's timezone is different than that of the user. For example: If the hosting location is in Middle East (India), and the user is using Odoo from Saudi Arabia, there is a difference of 2.5 hours due to the timezone, so when the system creates the Invoice at 11 PM and tries to check the date, the date of the server is actually 29th of February, 11 PM while the date on the user's machine is 1st of March, 01:30 AM, which triggers a UserError from the _check_move_configuration function. Description of the issue/feature this PR addresses: When trying to process invoices at a time close to Midnight, and the user is using the system from a location different from the hosting location of Odoo, the system tries to check that the date of the invoice is the same as the current date of the system. This creates problems when the hosting server's timezone is different than that of the user. For example: If the hosting location is in Middle East (India), and the user is using Odoo from Saudi Arabia, there is a difference of 2.5 hours due to the timezone, so when the system creates the Invoice at 11 PM and tries to check the date, the date of the server is actually 29th of February, 11 PM while the date on the user's machine is 1st of March, 01:30 AM, which triggers a UserError from the _check_move_configuration function. Current behavior before PR: If user is in Saudi and tries to create an invoice at a time close to Midnight, for example at 11 PM, the system throws an error since the timezone of the server and that of the user using the POS are different. Desired behavior after PR is merged: The system checks the invoice date against `fields.Date.context_today(self)` instead of `date.today()` and successfully processes the invoice. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157048 Forward-Port-Of: odoo/odoo#155824
This update fixes an incorrect translation within the Serbian language version of Odoo. Previously, the 'Specific VAT rate 10%' tax group was translated as an invalid term. Now, it correctly displays as 'Opšta stopa PDV-a 10%', ensuring accurate tax reporting for Serbian users.
Original PR description
Description of the issue/feature this PR addresses: This PR fixes translation of the tax group `Specific VAT rate 10%` Current behavior before PR: When using Serbian language tax group `Specific VAT rate 10%` is translated as `ZALIHE MATERIJALA` which is invalid. Desired behavior after PR is merged: When using Serbian language tax group `Specific VAT rate 10%` will be translated as `Opšta stopa PDV-a 10%` which is correct. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155198
This update fixes an issue where the quantity of components consumed during MO unbuilding was incorrectly displayed. Previously, the system showed the full planned quantity even after consuming a smaller amount. This change ensures that the unbuild process accurately reflects the actual component usage, improving inventory accuracy.
Original PR description
Step: * Create BoM A: product A - qty 1, bom line: product = Component X, qty = 20 * Create MO with Bom A and produced_qty = 1: + on components: To Consume = 20, Consumed = 15 + Unbuild MO, check Unbuild, check Product Moves of Unbuild, check line product Component X has Quantity = 20, in fact quantity must = 15 **I consumed a smaller quantity of components than planned, but when I unbuild MO, move lines of unbuild has quantity done = quantity planned, not the actual quantity consumption. I think this is a bug** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156952 Forward-Port-Of: odoo/odoo#152805
A recent update to asset depreciation calculations caused a sorting issue when viewing asset entries. This was triggered by modifying the dates of asset entries, specifically when using new entry IDs. This fix ensures that asset entries are correctly sorted regardless of their creation date, preventing incorrect display of depreciation schedules.
Original PR description
To reproduce: - Install account_accountant - Create an asset (monthly for example) - Compute Depreciation - Modify the date of the first entry to 2 months later - Modify the date of the second entry to 1 month later (so same month) => Traceback The problem is that sorted does not work with ids of NewId. We should look at its _origin. There is a PR that would try to fix it in general, but it's in master (and is not sure to be merged https://github.com/odoo/odoo/pull/155850) The problem only began to occur in 17.0 because of the changes of the onchange function. opw-3759153 (in chatter) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156874
This update adds logging for when cron jobs are run manually through the Odoo interface. Previously, these manual runs weren't tracked, leading to confusion when issues like duplicate emails occurred. By logging these actions, our support team can better diagnose and resolve problems related to concurrent cron executions.
Original PR description
The INFO "Starting job x" and "Job x done" logs are only logged for the automatic executing of the cron by the cron worker. When running the cron manually via its form view, no INFO was logged. The technical support is reporting problems where a cron server action is running twice at a same moment leading to problems such as mass-mailing sending emails twice. There is a mutual exclusion mechanism for cron workers but no exclusion mechanism seems in place for http worker vs cron worker. Logging the "run manually" actions will help us figuring out the problems. --- **[[FIX] base: concurrent cron worker and manual run](https://github.com/odoo/odoo/pull/154763/commits/3b74c9af776311e38a1712ab64cb42cd25188db4)** It is possible for a cron to be executed twice at a same moment if the cron is currently being executed by a cron worker and that a user click on the "run manually" button from its form view. Forward-Port-Of: odoo/odoo#156914 Forward-Port-Of: odoo/odoo#154763