Friday, December 15, 2023
7 changes · master
Enhancements to existing features
French customer and company records now show localized registry labels, using SIRET/SIREN terminology where relevant. This makes French legal identifiers clearer on records, invoices, and company document layouts, reducing ambiguity for users handling French accounting documents.
Original PR description
Adds a way to have dynamic fields label based on the record country_id field. This will be used in l10n_fr to have the company_registry field named SIREN if the partner or company has its address in France. task id #2827661 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes an unnecessary database step during system initialization. It slightly streamlines internal startup/setup work without changing how users interact with Odoo.
Original PR description
The SQL query removed in this revision is no longer useful since the revision: https://github.com/odoo/odoo/commit/92be431236bd93054c5134cb0d4daf8124918e39#diff-3350ff6a7375591a483754ef9f4718e5fadb298b4c605ee016154ec8bef1e074L57
This update improves how Odoo chooses new accounting codes so they stay consistent with local chart of accounts rules and avoid odd or overly long codes. It also lets EU OSS tax reporting use dedicated existing accounts, such as Germany's OSS accounts, instead of creating unnecessary duplicates.
Original PR description
### Context While doing the balancing of the Balance Sheets, I found that: 1. some OSS accounts were being created with non-sensical account codes (e.g. in Lithuania, the OSS account is created with…
### Context
While doing the balancing of the Balance Sheets, I found that:
1. some OSS accounts were being created with non-sensical account codes (e.g. in Lithuania, the OSS account is created with code 4402 whereas the basic VAT Payable account has code 4492),
2. some CoAs already have a dedicated account for OSS (e.g. Germany should use account 1767 for OSS), but we create a new one.
### Problem 1: non-sensical account codes
At heart, this is due to the implementation of `_search_new_account_code`. What it should do, is start with the given `prefix`, expand it to `digits`, and increment it until an available code is found.
However, this is not what `_search_new_account_code` does at the moment: if `len(prefix) == digits`, it truncates the last digit of `prefix`, then appends 1, 2, 3, ... until an available code is found.
This behaviour is unwanted for two reasons:
- Firstly, if `prefix` ends with a different digit than `0` or `1`, we want to only try codes higher than `prefix`.
- Secondly, the resulting code may exceed the expected number of digits passed to it. This was ruled by TSB as something that should be avoided, due to constraints on the length of codes in some countries (e.g. limited to 8 in Germany).
We therefore change the behaviour of `_search_new_account_code` to the following:
1. _search_new_account_code now takes an argument `start_code`, which is a code to start incrementing from, instead of `prefix` and `digits`.
2. We check whether `start_code` is available; if not, we increment it until an available code is found. The incrementation works by regexing an integer at the end of the `start_code` string, and incrementing it without increasing the length of the code.
3. If, due to non-numeric characters in the code, the incrementation fails, or if no codes are available, we fallback to `'{start_code}.copy'`, `'{start_code}.copy2'`, etc.
Because `_search_new_account_code` is used to create new account codes when loading CoA templates, this change in behaviour (in particular, ensuring that the generated code has the specified number of digits) requires us as well to fix too-low values of the `code_digits` property on CoA templates.
I also note that while the implementation of `AcccountAccount.copy()` does not currently use `_search_new_account_code`, we could consider using it at some point.
### Problem 2: CoAs that already provide an OSS account
We need a way to specify an existing account from the CoA if there is one dedicated for OSS. For this, I've just added the CoA accounts directly in the `l10n_eu_oss` module, as I didn't think providing a prefix in each localization's template was needed. However, if that's considered better, I'm open to the change.
Enterprise PR: https://github.com/odoo/enterprise/pull/48066
taskids: 3521121, 3523224Discuss sidebar categories can now be managed through mail records instead of a fixed registry. This makes it easier to introduce or adjust categories dynamically, including for live chat, while aligning the implementation with the rest of Discuss.
Original PR description
Before this PR, a registry was used to list the categories shown in the discuss sidebar. This can be done easily with mail records instead. Doing so will allow to add new categories dynamically. Moreover, this is more consistent with the discuss code base. part of task-3640730 enterprise: https://github.com/odoo/enterprise/pull/52873
WhatsApp conversation categories in Discuss can now be managed through mail records instead of a fixed registry. This makes it easier to add new sidebar categories over time and keeps the feature aligned with the rest of Discuss.
Original PR description
Before this PR, a registry was used to list the categories shown in the discuss sidebar. This can be done easily with mail records instead. Doing so will allow to add new categories dynamically. Moreover, this is more consistent with the discuss code base. part of task-3640730 enterprise: https://github.com/odoo/odoo/pull/146451
Austrian financial reports now use account codes instead of optional account tags, reducing the risk of missing or inaccurate figures when tags are absent. The balance sheet also calculates profit and loss automatically, improving consistency without relying on specific account setup.
Original PR description
Replace the tags_id used in domains in the financial reports by the account ids. Tags ids are not required and could be missing on accounts, using account ids helps to have financial reports staying as correct as possible. Also change the balance sheet so that it automatically calculate the p&l balance instead of relying on specific accounts for it. Task id #2612900
The update limits certain Mexico-specific invoice fields so they are only saved for invoices created by Mexican companies. This keeps invoice records cleaner and avoids storing irrelevant localization data for companies outside Mexico.
Original PR description
Change two fields on account moves to only store values for invoices created with an MX company. Task id # 2715634