Wednesday, February 2, 2022
9 changes · master
Enhancements to existing features
SEPA Direct Debit payment notifications now reuse the payment transaction already being processed instead of searching for it multiple times. This improves processing efficiency and keeps payment validation behavior consistent.
Original PR description
Before this commit, most acquirers needed to run several successive searches for the transaction whose reference was received by a controller in notification data. This is because the security checks run on the notification data require access to the acquirer through the transaction record which was immediately discarded. Starting with this commit, all `*_feedback_data` method are no longer decorated with `api.model` and can use the transaction record they're called on if provided. They are also renamed to `*_notification_data`. task-2737144 See also: - https://github.com/odoo/odoo/pull/83850
The payroll accounting test suite for Belgium was adjusted to allow for a higher expected query count after related system changes. This is an internal maintenance update that helps keep automated tests aligned and does not change user-facing payroll features.
Original PR description
Title :) See odoo/odoo#76097 TaskId-2602897
Miscellaneous changes
Before this commit, the `_search_pricing_type` method is not overriden in `industry_fsm_sale` module like is made for the `_compute_pricing_type` method. This commit overrides the `_search_pricing_type` method to fit the domain built for also the fsm projects and not only for the basic projects. The issue has been found during the development of task-2680425 Forward-Port-Of: odoo/enterprise#23944
Original PR description
Before this commit, the `_search_pricing_type` method is not overriden in `industry_fsm_sale` module like is made for the `_compute_pricing_type` method. This commit overrides the `_search_pricing_type` method to fit the domain built for also the fsm projects and not only for the basic projects. The issue has been found during the development of task-2680425 Forward-Port-Of: odoo/enterprise#23944
Since this commit : https://github.com/odoo/odoo/commit/c6d2a50499744a9ddbb09a9974d6ab52116ef542, the bank suspense account is no longer considered a liability. To reflect that change, the corresponding account (499) should also be moved to the asset section of the BS. Related PR : https://github.com/odoo/odoo/pull/81071 task-2729822 Forward-Port-Of: odoo/enterprise#23496
Original PR description
Since this commit : https://github.com/odoo/odoo/commit/c6d2a50499744a9ddbb09a9974d6ab52116ef542, the bank suspense account is no longer considered a liability. To reflect that change, the corresponding account (499) should also be moved to the asset section of the BS. Related PR : https://github.com/odoo/odoo/pull/81071 task-2729822 Forward-Port-Of: odoo/enterprise#23496
Usecase to reproduce: - Set warehouse in 3 steps receipt - Set 30 days on each rules (QC->Stock, Input->QC) - Set 30 days on supplier - Open the MPS (by month) Imagine we are the 01-01-2022: - Plan 10 units for May and replenish - Move from QC -> Stock is plan for April - Move from Input -> QC is plan for March - Move from supplier -> Input doesn't exist but the RFQ planned date is for February However the MPS is base on `stock.warehouse` and not on a specific location. So the mo
Original PR description
Usecase to reproduce: - Set warehouse in 3 steps receipt - Set 30 days on each rules (QC->Stock, Input->QC) - Set 30 days on supplier - Open the MPS (by month) Imagine we are the 01-01-2022: - Plan…
Usecase to reproduce: - Set warehouse in 3 steps receipt - Set 30 days on each rules (QC->Stock, Input->QC) - Set 30 days on supplier - Open the MPS (by month) Imagine we are the 01-01-2022: - Plan 10 units for May and replenish - Move from QC -> Stock is plan for April - Move from Input -> QC is plan for March - Move from supplier -> Input doesn't exist but the RFQ planned date is for February However the MPS is base on `stock.warehouse` and not on a specific location. So the move selected by the MPS is either: - The RFQ line - The `stock.move` from supplier to Input if the RFQ is validate Both case the result is February. Thus the replenishment launched for May is counted for February and the replenishment for May could be relaunch infinitely. The solution is to keep everything similar than before. However if the RFQ/move from supplier is linked to destination moves, then check if a move in the chain go through `warehouse.lot_stock_id`. If it's the case add the delays from destination moves. Forward-Port-Of: odoo/enterprise#23726
When selling to someone of tierra del fuego (IVA Ley Liberado) any document type is allowed because this person could be acting as a final customer Forward-Port-Of: odoo/enterprise#23467
Original PR description
When selling to someone of tierra del fuego (IVA Ley Liberado) any document type is allowed because this person could be acting as a final customer Forward-Port-Of: odoo/enterprise#23467
… report Since there is no 'flush' made after the reconciliation, the test is made using the not updated 'amount_residual'/'amount_residual_currency' values. Forward-Port-Of: odoo/enterprise#23869 Forward-Port-Of: odoo/enterprise#23840
Original PR description
… report Since there is no 'flush' made after the reconciliation, the test is made using the not updated 'amount_residual'/'amount_residual_currency' values. Forward-Port-Of: odoo/enterprise#23869 Forward-Port-Of: odoo/enterprise#23840
In the Disallowed Expense module, the label corresponding to the disallowed % wasn't clear enough. This PR changes its display name : % --> Disallowed % Modified .pot accordingly. task-2749358 Forward-Port-Of: odoo/enterprise#23862
Original PR description
In the Disallowed Expense module, the label corresponding to the disallowed % wasn't clear enough. This PR changes its display name : % --> Disallowed % Modified .pot accordingly. task-2749358 Forward-Port-Of: odoo/enterprise#23862
Some html field are not in their ideal style, we fix it by : @see https://github.com/odoo/odoo/pull/83305 Changing the default behavior of the html fields to fit most cases. > As the style for html fields is now dependent of > where you are in the xml view ( in group or not), > we have to adapt some views and flags some fields > to ensure they have the correct look. > > This change is only be a visual enhancement > and should not prevent the function of said html fields > event
Original PR description
Some html field are not in their ideal style, we fix it by : @see https://github.com/odoo/odoo/pull/83305 Changing the default behavior of the html fields to fit most cases. > As the style for html fields is now dependent of > where you are in the xml view ( in group or not), > we have to adapt some views and flags some fields > to ensure they have the correct look. > > This change is only be a visual enhancement > and should not prevent the function of said html fields > event if the views are not updated. task-2637488 ---- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#23904 Forward-Port-Of: odoo/enterprise#23724