The changes should not have been merged in stable.
Users installing the account module before 3754280a had a not null constraint
on the field company_id.
After updating the code, the field is still required but has no default value.
If a chart of account is installed after updating the code, it would fail.
opw-1867358
We want to force the tax template to be blank always, because multiple companies can potentially use this template to create taxes. We want consistency company-wise.
When setting a chart of account on a company, we have default taxes from
the default chart of account different from chosen one.
But if a chart of account is chosen, it should override them in the
onchange_chart_template_id function. This works as expected for a
truthy complete_tax_set chart of account template, but not for a falsy
complete_tax_set chart of account template.
The complete_tax_set indicates that we don't want to set default taxes
and the user should do it or modify the given tax rates himself.
opw-1824751
closes#23655
Before this commit, in the event that the admin user has set the language
to english, but the COA's target company had a different language,
the admin user's language had been taken instead of the copany's one
for the translation of journals and other coa intialization stuff.
This is wrong as the CoA is more connected to the company, than to the
user, which could be a functional support user that just happens to prefer
the english version over the local one.
Now, we ensure in two neuralgic places, that the company's language is passed
to the context and therefore picked up by the translation's GetTextAlias.
Signed-off-by: David Arnold <dar@xoe.solutions>
Taxes tags for some localization have been rewrote in order to improve the taxes report.
However, these changes delete the existing account.tags on stable version.
These "[l10n_*] one tag per grid in tax reports" should target master instead of 9.0.
-opw: 777464
* account, hr, hr_recruitment, maintenance, mrp, sales_team, stock
Adaptation of https://github.com/odoo/odoo/commit/a79d83e436e5e965d59663d4a06a0f8a62d8f694 for saas-18 new colors.
Also change back all color defaults to 0 instead of 1 (see
mentioned commit: they were changed from 0 to 1 as in saas-16
the color was applied to kanban headers which had to be gray
(the old color 1) by default).
Also add default violet color for 'Customer Invoices' and 'Vendor Bills'
dashboards.
* CoA up to date
* Taxes up to date
* SKR03 installed by default but users can easily switch to SKR04 while no accounting entries exists for the company
* removed unneeded things
* set tags accordingly on accounts and taxes for the reports to work (new reports in enterprise)
Was task 31826. Was PR #17447. Discussion related on #18571
Add a setup bar on account's dashboard, so that the user can more easily enter the initial data of his Odoo installation, following the steps that are proposed to him.
Was PR #16864
Was task 32119
- Replace 'Use Cash Basis' checkbox by 'Tax Due' having two radio buttons,
- Based on Invoice (default)
- Based on Payment
- "Tax received account" display only when we select "Based on Payment"
- Changed the field name 'use_cash_basis' into 'tax_exigibility'.
Was PR #17326
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
* [IMP] account, account_accountant: Move 'tax_cash_basis_journal_id' field from 'account_accountant' to 'account' module.
* [IMP] account: Few improvements in accounting settings,
- Set 'Invoicing' section as a last section.
- Add checkbox 'Cash Basis' in settings and make it company dependent and add multi company's icon to it.
- Disable the 'Tax Cash Basis Journal' field if 'Cash Basis' not active. Also add tooltip on 'Cash Basis'.
- Visible/Invisible 'Use Cash Basis' field in 'Taxes' form view based on 'Cash Basis' settings from accounting settings.
- Don't allow untick 'Cash Basis' settings if there are taxes using the configuration.
- When any CoA is installed which is creating taxes with configuration 'Use Cash Basis' set then make the 'Cash Basis' option in accounting settings checked by default.
Was PR #16516
Purpose
=======
When generating `Cash` bank journal on CoA import, it doesn't makes sense to have the `Check` payment method enabled by default
Specification
=============
When system automatically creates journals of bank and cash type when CoA is being installed,
1) type = "Bank"
- Manual -> Checked
- Check --> Checked
2) type = "Cash"
- Manual -> Checked
- Check --> Unchecked
We can now select a new localization module in place of the existing one, if no accounting has been done yet.
This allows to set a default CoA for Germany and China, by choosing arbitrary one of the existing localization package at the installation since they can directly switch if needed.
Was PR #16605.
* cross-version metaclass spec
* more formally deprecate browse_record and browse_null since they
were using metaclasses anyway
* update docstrings referencing the latter
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
- Some fields were simply missing on templates, making impossible to give them a value on chart template installation.
- Added a real link between account.reconcile.model.template and its chart template instead of using account_id.chart_template_id
- Added tests for checking the consistency of those objects in the future.
* The module was not loading the fiscal position templates before executing the template generation.
* Also, as reported in #15384, at the second installation it was crashing because of a missing xml id (which is not supported currently). This last bug was fixed by giving specific xml_ids instead of skipping the data.
This reverts commit 929d983575.
In some cases, the records have no xml_id like
in module l10n_jp, the way the account.fiscal.position.tax.template
are declared in account.fiscal.position.template.csv doesn't set
an xml_id for these records. So when using, the function create_record_with_xmlid
it raised an error if the record has no xml_id because it tried to concate
a string with a boolean with "str(company.id)+'_'+template_xmlid.name".
Fixes: #15384
opw:707704
Martin Trigaux