Sunday, November 5, 2023
6 changes · 17.0
Resolved issues and error corrections
The AFIP certificates used for Argentina's electronic invoicing had expired, causing connection tests and unit tests to fail. This update replaces all expired certificates with new valid ones, restoring full functionality for Argentine localization features and enabling proper testing.
Original PR description
The last ones where expires and do not let us to make any functional tests on runbot, and the unit tests where failing If we go to settings > Accounting > Argentinean Localization. Button test connection we receive this error  with this PR the certificate are working  Forward-Port-Of: odoo/enterprise#49886
This update fixes how financial reports handle company branches when multi-company filtering is disabled or set to tax units. Previously, invoices and transactions from selected branches were not appearing in reports like Aged Receivable. The fix ensures that when you select a company and its branches, all their financial data is properly included in the reports. Additionally, export buttons now display as disabled (rather than hidden) when incomplete branch selections would create invalid exports, and tax closing entries are now correctly assigned to their respective branches.
Original PR description
Example of the issue: 1) Create a company called "main" 2) Create a branch for "main" called "branch" 3) Make an invoice in "main" 4) Make an invoice in "branch" 5) Modify the Aged Receivable report, and set filter_multi_company to 'disabled' 6) Select "main" as current company. By default, "branch" is selected as well, keep it like this. 7) Open the Aged Receivable ====> You only see the invoice made for "main", not the one in "branch". While totally correct in a regular multi-company setup, this is not the behavior we want when those companies contain branches. When filter_multi_company only accepts the active company (so, when it's 'disabled' or set to 'tax_units' and no tax unit is selected), we also want to include all of its branches that are currently selected in the company selector. Forward-Port-Of: odoo/enterprise#49224
A debug console.log statement was accidentally left in the account reports widget code and has been removed. This cleanup ensures the application runs cleanly without unnecessary debug output in production.
Original PR description
Forgot to remove a `console.log`.
Miscellaneous changes
It is not possible to add to comparison a product without variant. But before this commit, if you add the product to the wishlist, it is possible to add it to comparison. This commit prevents this button from appearing in case the product has no variant. Solves #139175 Forward-Port-Of: odoo/odoo#140174
Original PR description
It is not possible to add to comparison a product without variant. But before this commit, if you add the product to the wishlist, it is possible to add it to comparison. This commit prevents this button from appearing in case the product has no variant. Solves #139175 Forward-Port-Of: odoo/odoo#140174
_Description of the issue/feature this PR addresses:_ When bank statements are imported using Enterprise's account_online_synchronization, or when invoices are created from incoming email using mail aliases on `account.journal`, journal entries can end up with a fiscal position from the default company of the user that the account.move creation runs as, or the import fails with an error `'Draft Entry' belongs to company X and 'Fiscal Position' belongs to another company.` While `account.move
Original PR description
_Description of the issue/feature this PR addresses:_ When bank statements are imported using Enterprise's account_online_synchronization, or when invoices are created from incoming email using mail…
_Description of the issue/feature this PR addresses:_ When bank statements are imported using Enterprise's account_online_synchronization, or when invoices are created from incoming email using mail aliases on `account.journal`, journal entries can end up with a fiscal position from the default company of the user that the account.move creation runs as, or the import fails with an error `'Draft Entry' belongs to company X and 'Fiscal Position' belongs to another company.` While `account.move`'s `_compute_fiscal_company_id` calls `account.fiscal.position`'s `_get_fiscal_position` with the correct company, it passes one or two `res.partner` records to this method that are still browsed with the default company of the executing user which can result in a fiscal position from that company instead of the company of the journal entry. _Current behavior before PR:_ Entry is not created or is created with a fiscal position from another company than the company of the entry. _Desired behavior after PR is merged:_ Entry is created with a fiscal position from the right company. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#138722
__accessible_branches() used to call search() to get the children companies, but doing so, it returned them sorted according to res.company's _order, so (sequence, name). Because of that, a branch company with a name coming before it's parent's in alphabetical order, if they had the same sequence (which is the default), would always be returned before it by this function. This behavior caused some issues, as it was assumed the order of the element it returned would be the same as in the compa
Original PR description
__accessible_branches() used to call search() to get the children companies, but doing so, it returned them sorted according to res.company's _order, so (sequence, name). Because of that, a branch…
__accessible_branches() used to call search() to get the children companies, but doing so, it returned them sorted according to res.company's _order, so (sequence, name). Because of that, a branch company with a name coming before it's parent's in alphabetical order, if they had the same sequence (which is the default), would always be returned before it by this function. This behavior caused some issues, as it was assumed the order of the element it returned would be the same as in the company selector ; respecting the hierarchy of branches, with parent companies coming first. This was spotted in Accounting, with the following setup: - A company named "main", with one branch called "branch". - "branch" has one sub-branch called "branch branch". - Enable "main" and all its sub branches in the selector ; "main" is the active company. Here are the issues that were found in Accounting: 1) Click on the "new" button in the Customer Invoices' tree view. Don't change anything in the form that opens, and check the value in the company_id field of the invoice being created. It should be "main", but it's "branch" instead. 2) (when applying the fix commit on the enterprise branch related to this one) When printing an accounting report, the route called to generate the file restores the active companies from the options' multi_company key https://github.com/odoo/enterprise/blob/16.0/account_reports/controllers/main.py#L21 . Because of that, if the report does not support multicompany, but only branches of the active company (see corresponding enterprise commit for details), if the first company in this list is one of the branches instead of the main company, the companies computed for the report will be different. In our example, "branch" will be first in the list, so the options for the file export will be computed with "branch" as main company, enabling only its branches that are selected in self.env.companies ; so only "branch" and "branch branch" will be in the report ; which is wrong, as we also want "main". Forward-Port-Of: odoo/odoo#139217