With this change,
* some modules are now set to be automatically installed by default
* the setup bar of accounting has been changed in order to allow more easiliy the configuration of bank accounts/journals (and the step to oversee the opening entry has been removed)
* the kanban view in the dashboard has been enhanced (mostly for bank journals, but not only)
Was task: 32668
Was PR #23049
Allow the user to set taxes on lines when creating manually a new journal entry, and tax lines will be computed automatically thanks to an onchange based on new unstored fields.
Was task: 33802
Was PR #19029
Make one Payment
Reverse the entry of this payment.
Before this commit, only the lines in the receivable were reconciled.
The lines in the liquidity were'nt, leaving the two entries appearing
in some reports
After this commit, the four lines are reconciled two by two, even in the liquidity
account
OPW 1816641
closes#25026
Module account_lock has been introduced by:
https://github.com/odoo/odoo/commit/2eb344f23b3a9daa8e7c7ddaead145a8b05b39bf
A new constrains appears on the lock dates: their must not be set
after the last day of the previous month.
Then, it breaks the test on closed period that set the lock date 'yesterday'.
* Reconciliation
Change the way the reconciliation method was written to optimize performances.
Remove the "skip_full_reconcile_check" stuff that is more confusing than helping.
* Object creation
Remove the creation of tax_line from tax_ids in the account_move_line create method.
Remove a bunch of context that were invalidating the cache way too often
Was PR #21498
Was task 37976
- Company currency in EUR
- Create 2 rates for USD:
1.0 on 2018-01-01
0.5 on 2018-02-01
- Create an invoice on 2018-01-02 of 111 USD
- Register a payment on 2018-02-02 of 111 USD
- Unreconcile the payment
An error occurs: 'You are trying to reconcile some entries that are
already reconciled!'
In this specific case where the rate decreases, the exchange rate entry
is reconciled with the payment, so we need to keep the payment entries.
- Company currency in EUR
- Create 2 rates for USD:
1.0 on 2018-01-01
0.5 on 2018-02-01
- Create an invoice on 2018-01-02 of 111 USD
- Register a payment on 2018-02-02 of 111 USD
- Unreconcile the payment
An error occurs: 'You are trying to reconcile some entries that are
already reconciled!'
In this specific case where the rate decreases, the exchange rate entry
is reconciled with the payment, so we need to keep the payment entries.
Cache invalidation when subscribing people has been added at e6f038a821.
Indeed subscribing partners to a record may lead to an access right update
as some of them are based on followers. This is why a cache invalidation
is necessary to avoid access rights issues.
However subscribing people to a record should change their rights only on
the records involved in the subscription mechanism. We can therefore give
ids to the cache invalidation to limit to updated records.
Cache invalidation is also limited when writing on followers if writing
on model, res_id or partner_id fields. Indeed changing subtypes or
channel of a subscription should have no impact on cache and access rights.
Cache invalidation done manually in _message_subscribe is not necessary
as subscription create or update mail.followers records since f9c210923d.
Create and write of mail.followers records already ask for cache invalidation.
It is therefore not necessary to invalidate cache twice.
This commit allows to save a few queries on some tests, notably about
activities that deal with subscription and messages. As cache is now kept
it is not necessary to refetch some data, leading to a few query gain. We
gain about 1K queries on com runbot.
A side effect of limiting cache invalidation is that some unit tests require
a manual cache invalidation to have up to date results. Indeed record not
being up to date in cache was hidden by the invalidation we just removed.
- Create a SO for a customer of 100 $
- Create Invoice for the Sales Order and Register the payment
- Create a Refund Invoice, Validate it and keep it in "Open" state
- Create a second SO for 5 $
- Create an invoice for this order and validate it
- It will show you outstanding payments
- Apply the credit and the invoice will be fulfilled => Now you have a
credit left for 95 $
- Create a third Sales order for the same customer for 5 $
- Create an Invoice for it
- It will show you outstanding credit (95 $)
- Apply the credits
- Now 90 $ are left
- In the same invoice, the credit which you applied, Unreconcile it
- It should have shown you 95 $, but it shows you 100 $ which means it
removed the credit which we applied to second SO
The unreconcile process does not filter the partial reconciliations of
the selected invoice. All partial reconciliations on the AML are
removed instead.
opw-1819602
The recent change (e130606602) broke the use case of an invoice/payment in the company currency without any secondary currency involved. Payment was recorded correctly but no full reconciliation was created (and it was not tested).
In order to fix that, we allow to test total_debit and total_credit also when currency has never been set (no secondary currency at all)
Along with new tests, 2 things have been changed:
1) amount_currency field is not written anymore when matching an amount paid in company currency against some invoice(s) in secondary currency (see changes in test_reconciliation.py)
This was previously made to help computing the exchange rate difference entry, but we now instead completelly rely on the amount_currency field set on the partial reconciliation. Besides being wrong from a purely functional pont of view (we never received money in secondary currency so why should the ORM act as if it was the case), it was the root cause of the problem related test_partial_reconcile_currencies_02, in test_reconciliation.py.
2) when registering a payment directly from an invoice, containing both an exchange difference and a write-off to force the full reconciliation, we now correctly create the accounting entries.
A weird behavior spotted in #21888 was introduced by 2093546, to deal with impossibility to full reconcile an invoice due to rounding errors. Fortunately, this use case (test_payment_and_writeoff_in_other_currency_3, in test_payment.py) can now be solved in the right way thanks to changes introduced in the previous point.
From 'Accounting Dashboard', creating a new payment was raising an error 'Record does not exist or has been deleted.'.
That's because since cdca5d4751 the default_get() was expecting to be called directly from the account.invoice model, using 'active_ids' to compute default values. Since it was incorrect, we now also check for the active_model to avoid raising this error.
Was PR #23548
Was task: 1824893
The previous commit forbids to change the currency of a company having accounting entries, but there are some created by demo data and some tests were trying to set a different currency (to set up a fix environment). So in order to allow that in tests, we do it via a SQL query directly
This reverts commit 7642754122.
The reason is that we finally decided to implement that in another way and we want to avoid people start using this feature as it would be replaced in next saas. Yes, I know, that sucks.
New task ID: 1823153
Due to this commit: 3267e76520
Steps to reproduce the bug:
When registering a payment for a customer invoice in an other currency than
the company currency and marking it as fully paid, it raised an error:
"Wrong credit or debit value in accounting entry !".
Reason: counterpart_aml['debit'] and counterpart_aml['credit'] were both incremented
and it violated the constraint credit*debit=0
opw:815465
* analytic accounts can be shared among companies
* amount on analytic lines always refer to amount in company currency of which it belongs to
* add analytic groups (hierarchical way to classify analytic accounts)
* analytic tags:
- only present on analytic lines, not anymore on analytic accounts
- can be used to distribue/split an analytic lines among several analytic accounts
- enabled by a dedicated res.group
- added on several objects (vouchers, expenses, analytic defaults...) as well as in bank statement reconciliation widget (manual counterpart and account.reconcile.model)
* bunch of fixes made related to analytic
Was PR #22124. Was task 32386. Original work by tbe.
- One need to first enable this from Accounting Settings to use this feature
- This feature works for Vendor Bills which are validated/paid
- Once activated, user can see one option in Vendor Bills to set particular record to be recurrent document and can define the recurrency period. This will automatically create draft documents(by mean of Scheduled Actions) as per recurrency configuration.
Was PR #21411. was task 34884.
Purpose: When running tests, all the tests for the installed/updated
files are done. This commit adds a 'tagged' decorator that can be used to
tag tests. Combined with a new 'test-tags' CLI option, it adds the ability
to filter which tests are executed. For example, @tagged('slow') will
add a tag 'slow' to the test. The CLI option 'test-tags="slow"' will
only run tests tagged 'slow'.
One can use prefixes to select cases with tags.
'+' or no prefix means that the tests tagged with this tag are selected
for execution. '-' prefix will exclude the tests tagged with this tag.
Exclusion takes precedence over inclusion.
Also, by default, all Odoo tests cases are tagged 'standard' and with
the technical name of the module.
This means that when selecting tests with the 'test-tags'
parameter, if '-standard' is not specified, all tests tags are
going to be executed.
When tagging tests, one can remove such automatic tag by prefixing the
tag name with '-'. E.g. @tagged('-standard') will remove the standard
tag from the test.
Another example, if one wants to test the 'sale' module alone,
even without adding any 'tagged' decorator thos tests can be selected
like that: --test-tags="sale"
Tests are selected or deselected using a TagsSelector. When instanciated,
a string is passed with comma separated tests selectors like
'+slow,-standard'. When the 'check' method is called with a test as argument,
it returns True or False if the test has to be executed or not.
Olivier Colson