Before that, even though the code contained something about it, the duplication of account.journal objects handled their code field pretty poorly (as it was trimmed to 5 characters), leading to situations where journals could have the same code, leading to possibility for account moves to have the same name.
This commit improves the SQL constraint testing journal codes so that they must now be unique per company. We also recompute the code in a more advanced way so that journal duplications works as smoothly as possible.
Task 2346404
closesodoo/odoo#59791
Related: odoo/enterprise#14447
Related: odoo/upgrade#1880
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
It's needed only on using skipTest in SavepointCase.setUpClass.
From docs https://docs.python.org/3/library/unittest.html#unittest-skipping:
> Skipped classes will not have setUpClass() or tearDownClass() run.
This may lead to running out of available sql connections. It mostly happens in
odoo.sh, which has max connections set to 16, while default value is 64
Fixes#56636
opw-2345762
closesodoo/odoo#59388
X-original-commit: b7f922050217634cdf85d15cae62b78fa3ce1834
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Solves https://github.com/odoo/odoo/issues/56803
Use case:
1) Create accounts ACC TAX A, ACC TAX B, with reconcile = True, internal_type = other
2) Create Tax A, with tax_exigibilty = on_invoice and account_id = ACC TAX A, 20%
3) Create Tax B, with tax_exigibilty = on_payment and account_id = ACC TAX B and cash_basic_account_id = ACC TAX A, 20%
4) Create invoice A, account_id = Tax A, unit_price = 1000, Valide invoice
5) Create invoice B, account_id = Tax B, unit_price = 500, Valide invoice,
6) Register full payment for invoice B. The cash basis tax creates a miscellaneous operation MISC A, containing a line on ACC TAX A.
7) Create a mis operation MISC TVA, like this:
line 1 : account_id = ACC TAX A, credit = 300
line 2 : account_id = 401100, debit = 300
8) Reconcile the following move lines:
line of MISC A with account ACC TAX A (300)
line of invoice A with account ACC TAX A (200)
line of MISC TVA with account ACC TAX A (100)
==> When doing that, not full reconcile object was created between the reconciled lines, while it should have been.
X-original-commit: ff35a49
[IMP] account: reintroduce a test that should have been forward-ported …
This test was made together with a bugfix by https://github.com/odoo/odoo/pull/51529 . The fix did not need to be forward-ported to 13.0, but the test should have been, so that we are sure it does not break again in the future.
closesodoo/odoo#58072
X-original-commit: 5d00592f7d803888d8d5befd5a8cd1b096067860
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Added edi.documents representing an electronic document for a move and an edi.format.
A format can be asynchronous if it needs to call a web-service to generate the document, it will then be generated by the CRON (otherwise it's generated in post).
The formats can support payments if needed (can be generated immediately or by the CRON).
Added support for errors and related views.
Setting defaults format on a journal can be done automatically (based on a hook).
Added tests : xml comparaison with diff and helpers to test a EDI import/export
--task: 2247368
Thanks to this setup, we will be able to run the tours independently to any demo data.
To do so, the HttpSavepointCase is born to do the same as HttpCase but with a setUpClass.
--task: 2290120
Add an easy way to not post the entries in the future when calling
post() on it, but rather set it to be auto-posted at accounting date.
This is useful when we are creating a lot of entries in batch and some
might be in the future, some in the past, and we don't want to separate
that in two batch every time. (asset, accrual, transfer,... )
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2301180
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2301180m
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2301180
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2296213
If a test is supposed to be run with the Belgium CoA, we expect the company is created by default with the EUR currency.
Before this commit, the currency of the company was replaced by the current company's one: USD (most of the time).
This commits refactors the code of the reconciliation, in order to facilitate the process of complex use cases, namely multi-currencies or cash-basis-taxes related (see details below). It also prepares the code for a second refactoring where we will save on each journal items the amount_currency and currency_id field (even in case of operation made in company currency), also in the sake of simplification.
1) Multi-currencies:
- the account.partial.reconcile model now will have dedicated columns to specify the amount of the partial reconciliation in the debit_line_id currency and the credit_line_id currency. That comes in handy when dealing with journal items having different secondary currencies, but also allows some simplification.
- residual_amount_currency computation changed accordingly
- moved models account.full.reconcile and account.partial.reconcile in their dedicated .py file
2) Cash basis taxes
- cash basis entries now handle correctly rounding errors to make sure the exact amount of gets reported when the reconciliation becomes full.
- the account for the base amount of cash basis entries has to be set, now, on the company instead of on each cash basis tax.
- that new 'property' field can be set at the CoA installation via the field property_cash_basis_base_account_id of account.chart.template, or going through the accounting settings.
Was task task: 2243420
Was PR #50308
Related: odoo/upgrade#1121
Related: odoo/enterprise#10252
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The properties must always be accessed using the company of the journal entry defined by
its journal.
closesodoo/odoo#51094
Task: 2244829
X-original-commit: bf416d95b1216c5780d3dbeaa32f0e57dc50c574
Related: odoo/enterprise#10543
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Create journal entries as soon as bank/cash statement lines are created, temporary booked on a suspense account set on the journal.
- Simplify the management of "blue" lines in the reconciliation widget. A "blue" line is now a journal item using a temporary liquidity account (outstanding payment/receipt accounts, set on the journal).
- Adapt and simplify the bank reconciliation report.
- Remove the bank reconciliation threshold date. The reconciliation report will show the not already reconciled journal entries using a liquidity account and the not already reconciled journal entries using a temporary liquidity account. Without accounting, an account.payment will involve directly the liquidity account and then, will be considered as a statement line directly.
- Remove the post_at bank reconciliation feature. The "paid" state will be set on the invoices only if reconciled with a journal entry involving the journal's liquidity account.
With invoicing, the payment will do that so the "in_payment" state should never be shown up.
With accounting, only the statement lines have the power to move an invoice to the "paid" state.
- Fix various corner cases about the management of multi-currency in bank statement lines.
- Fix the conversion dates in multi-currency: Since the bank/cash is always used on the statement lines, it will use always the real "bank" date instead of the fictive payment one.
- Ensure the 'reconcile' method will raise an error if the involved moves are not posted.
related enterprise PR odoo/enterprise#7019closesodoo/odoo#41301
--task: 2092096
Related: odoo/upgrade#1018
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Task 2092079
Accounting firms that want to give access to their customers avoiding
mistakes and risks will love this profile that can't do anything
wrong... Maybe as well as companies auditors..?
closesodoo/odoo#39860
Related: odoo/enterprise#6576
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Purpose
Fix multi-company access issues following the big changes that happened
(the 13.0). Make the usability better in order to avoid potential
multi-company issues for the user.
Specification
Check the related commits to see the different fixes that have been
made. For more information about the technical/functional considerations,
check the related task.
Taskid: 2088891
X-original-commit: 5c8df3a5e5f7960e5eab6439e0a32a06224ba826
1) Don't set an amount_currency without currency_id set.
2) Use the journal's currency only if different of the company one.
closesodoo/odoo#41094
X-original-commit: 3dd8bf6a38704df0db4f0879e685d2230be572a2
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
There is no unique constraint on the properties to avoid having two
properties for the same field, company and res_id.
Having two properties for the same field, company and res_id, leads to
inconsistencies through the code, as reading a company-dependent field
nondeterministically returns one of the available property value.
So now, before creating a property, we have to check that there is not
already a value for the field, company and res_id and write or create
depending on if it is already exists.
The properties of specific records already satisfy the constraint thanks
to the implementation of company-dependent fields that use the method
`set_multi`. We added a method `set_default` to set generic properties,
and its implementation does the right thing. It also simplifies the
code to set such properties, by the way.
closesodoo/odoo#40473
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Cash rounding only allowed for one account to be specified => Belgian accounting requires 2 types of account depending on whether the rounding line on the invoice is a + or - amount.
On cash rounding config (account.cash.rounding), one account is added (many2one). Existing account is renamed Profit account, new account is named Loss account.
The loss account is used when rounding line has a negative amount, and vice versa for profit account (account.move).
If no Loss account is set, only Profit account is used.
task : https://www.odoo.com/web?#id=2091658&action=327&model=project.task&view_type=form&menu_id=4720closesodoo/odoo#39488
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Raphael Collet