As the number of `account.move`, `account.move.line`,
`account.bank.statement.line` and `account.journal` is growing, the
accounting dashboard, which is the entry point of the app, gets slower
and slower.
There are multiple issues being addressed in this commit:
* The data for each journal is computed journal by journal. This means
that the number of queries run increases linearly with the number of
journals. While the boilerplate around running multiple queries is
negligible compared to the running time of the queries in this case,
some queries take as much time to run for one journal or for many.
To improve this, all the queries are now batched. This has been done
by refactoring the code; all these functions are now called on as many
records as needed[^1]:
- `_get_journal_bank_account_balance`
- `_get_journal_outstanding_payments_account_balance`
- `_get_last_bank_statement`
- `get_line_graph_datas`
- `get_bar_graph_datas`
- `get_journal_dashboard_datas`
* The gap detection and the entries' count are computed fields
(`has_sequence_holes` and `entries_count` respectively). We don't need
to display/compute these fields for all types of journals, but since
they were mentioned by using a `<field/>` node in the view, they were
computed for all journals displayed. Instead of using the `<field/>`
node, we are now setting the value in the `kanban_dashboard` field.
* Documents in foreign currencies on journals in foreign currencies need
to get the rate in order to be aggregated in the journal's currency.
There are 3 cases:
- Document in journal's currency
- Company's currency is the same as the journal's
- Document, company and journal have 3 different currencies
Before this commit, the second case will still fetch the daily rate
for the document in order to do the conversion, but we actually
already know the conversion; it is stored on the document.
Benchmark
=========
On a `populate` database with:
- 4 `res.company` (with accounting enabled)
- 45 `account.journal`
- 19k `account.move`
- 140k `account.move.line`
- 4k `account.bank.statement.line`
- 4 `account.bank.statement`
| Query count | Query time | Remaining time
--------------------------- | ----------- | ---------- | --------------
Before fix | 279 | 0.333s | 0.375s
After fix (without update) | 40 | 0.120s | 0.170s
After fix (with update[^2]) | 38 | 0.100s | 0.170s
Note that the currency conversion was disabled because the populate
database doesn't represent a realistic dataset regarding this. Disabling
it only improves the numbers before the fix.
Note
====
A lot of the time remaining comes from the aggregation of
draft/unpaid invoices with the correct rate done in python instead of in
SQL. This commit doesn't change the behavior but this could be rethought
from a function point of view.
________________________________________________________________________
[^1]: the old functions have been kept for compatibility, new ones are
suffixed by `_batched` and made private if it wasn't the case.
[^2]: some optimization require the views and indexes to be updated
closesodoo/odoo#117964
X-original-commit: 0a386932d2cbcb44cf36c1830422e52b285ae990
Related: odoo/enterprise#39461
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Steps to reproduce:
- Create a new journal Bank
- In Sequence, find the 'New Bank Check" and edit it so the sequence can be 10 number digits long
- Create a Vendor Payments with the the New Banck and Check as a method
- Click on Print a check
- Set the check number to 2147483648 and validate
- Create a new payment with the check method
- Click on Print a check
Issue:
Error is raised
Cause:
As for https://github.com/odoo/odoo/pull/112832 there is a second check in order to increment the check number
opw-3140973
closesodoo/odoo#114496
X-original-commit: 531147bb5fad6372c3742bc061f78687f7f11e5b
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Steps to reproduce:
- Create a new journal Bank
- In Sequence, find the 'New Bank Check" and edit it so the sequence can be 10 number digits long
- Create a Vendor Payments with the the New Banck and Check as a method
- Click on Print a check
- Set any number > 2147483647 and validate
Issue:
Traceback
Cause:
The query SQL make a check to verifiy that the number is correct ('025'::integer == '25'::integer but '025'!='25)
But using INTEGER limits the number up to 2147483647 (https://www.postgresql.org/docs/current/datatype-numeric.html)
Solution:
Use BIGINT whose limit is 9223372036854775807
opw-3140973
closesodoo/odoo#113499
X-original-commit: 49dd9dffd7b96fd90860123f8b3f0e623979b246
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Be able to add multipe checks payment method on journal
accountamatata task 3130305
closesodoo/odoo#109774
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
In order to make this modules to also match new module l10n_latam_check.
* refactory of some methods to make it more heritable
* check number now is showed only when is defined and is related to
check_printing payment method.
X-original-commit: 9394903813947cd4bfbad87f077cdf67233907d8
Part-of: odoo/odoo#107163
When printing a check that comes from an expense,
the check has no reference to the move from which
the payment has been created.
The reason is that we filter the move by taking
only outbounds to complete the check informations,
but moves from an expense are of type entry.
With this commit, we allow moves coming from
expense to be taken into account by adding a
check on move.move_type.
opw-3044141
closesodoo/odoo#105157
X-original-commit: b588329a45633f0dec89fe195cf24a8b3671dedd
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Since 'check_number' is now part of the journal item's label, the account_accountant_check_printing module is no longer necessary.
Task: 2555114
Part-of: odoo/odoo#91448
With this commit, we allow mutliple payments with manual
check printing.
Steps to reproduce:
- With manual check numbering
- Create +=3 vendor bills
- In bills list view, select all bills and register payment
- Select Checks as payment methos, and validate
-> Validation Error: The following numbers are already used ...
Setting the check_numbers before calling the super of
payment.action_post.
opw-2830586
closesodoo/odoo#91128
X-original-commit: c26cd9fa30ac9093f5c7500ca1dd9a9f9cfd06a5
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
Fix two issues linked to payment methods and their journal link.
SEPA Credit Transfer was marked as only available on EUR journals, but
from what we have been told, and we have seen, it should also be made
available for other currencies (CHF/SEK).
So we are changing the rule used to determine if SEPA Credit Transfer
is available on a journal to allow to use it on journals using CHF or
SEK as a currency.
There is another issue, where the filtering is done differently at the
journal creation and when the user add the payment method manually in
the lists.
The filter rules were not respected at the journal creation, which
would lead to incorrect default inbound and outbound payment method list.
For example, a new journal would have the company currency (let's say,
USD) but still have SEPA Credit Transfer (EUR,CHF,SEK) added on it by
default while it should not be available there.
opw-2777522
X-original-commit: 0ad8faf3bfc7b28e5668c3445fcc06c24ad98354
[FIX] account_*: payment method journal filter
Fix two issues linked to payment methods and their journal link.
SEPA Credit Transfer was marked as only available on EUR journals, but
from what we have been told, and we have seen, it should also be made
available for other currencies (CHF/SEK).
So we are changing the rule used to determine if SEPA Credit Transfer
is available on a journal to allow to use it on journals using CHF or
SEK as a currency.
There is another issue, where the filtering is done differently at the
journal creation and when the user add the payment method manually in
the lists.
The filter rules were not respected at the journal creation, which
would lead to incorrect default inbound and outbound payment method list.
For example, a new journal would have the company currency (let's say,
USD) but still have SEPA Credit Transfer (EUR,CHF,SEK) added on it by
default while it should not be available there.
opw-2777522
closesodoo/odoo#88677
X-original-commit: e2cd91ad8339f73b2547bc839e675443528f3adf
Related: odoo/enterprise#26172
Signed-off-by: Florian Gilbert <flg@odoo.com>
Unnecessary call to _create_check_sequence because is called in create method and create is called in supper().copy()
TT35608
closesodoo/odoo#88159
X-original-commit: 2f83737b8eb4f2b378cf4d6a6348d9ba15200561
Signed-off-by: Florian Gilbert <flg@odoo.com>
Steps to reproduce:
- On bank journal, set at least two manual
outbound_payment_method_line_ids
- Set a vendor X with manual property_payment_method_id
- Create a Vendor Bill with vendor X, confirm it, and register payment
OR
- Create a payment with outbound method and select vendor X
Issue:
Got a traceback
The reason is we expected one value instead of several.
With this commit, we take the manual payment method with the
highest priority based on its sequence number.
opw-2743110
closesodoo/odoo#86270
X-original-commit: 6235466e70cefd5d948ce06dd39fb04d88387a43
Signed-off-by: William André (wan) <wan@odoo.com>
When install the module on a db with huge amount of account move,
prefetching data when accessing partner_id of first move iteration is
costly and should be avoided.
closesodoo/odoo#84989
X-original-commit: c80700ee616e5588669879fd5e020ea868665a8f
Signed-off-by: William André (wan) <wan@odoo.com>
The method constraint to validate the Check Number is slow
1. Analyzing the following query:
```sql
SELECT
payment.check_number,
move.journal_id
FROM
account_payment payment
JOIN account_move move ON move.id = payment.move_id
JOIN account_journal journal ON journal.id = move.journal_id,
account_payment other_payment
JOIN account_move other_move ON other_move.id = other_payment.move_id
WHERE
payment.check_number::integer = other_payment.check_number::integer
AND move.journal_id = other_move.journal_id
AND payment.id != other_payment.id
AND payment.id IN (1085159)
AND move.state = 'posted'
AND other_move.state = 'posted';
```
The output is:
Planning Time: 3.354 ms
Execution Time: 2514.660 ms
Discarding null values
```diff
AND other_move.state = 'posted';
+ AND payment.check_number IS NOT NULL
+ AND other_payment.check_number IS NOT NULL
```
The output is
Planning Time: 3.216 ms
Execution Time: 0.140 ms
2. The constraint is computed even if the payment is not a check (check_number is empty)
Returning early save useless extra computating
It is not needed to compare falsy values for duplicated for whole table
3. The validation to check is it not a number is not optimal
It is transforming the string -> integer -> string to check if the string is not a number
but it is enough using only string -> integer not needed to transform to string again
python3 -m timeit -u msec -s "check_numbers = [str(i) for i in range(1000000)]" "[str(int(i)) for i in check_numbers]"
> 1 loop, best of 5: 323 msec per loop
python3 -m timeit -u msec -s "check_numbers = [str(i) for i in range(1000000)]" "[int(i) for i in check_numbers]"
> 2 loops, best of 5: 135 msec per loop
It is better but not enough, using `str.isdigit` method is 5x faster than original approach
python3 -m timeit -u msec -s "check_numbers = [str(i) for i in range(1000000)]" "[i.isdecimal() for i in check_numbers]"
> 5 loops, best of 5: 64 msec per loop
closesodoo/odoo#83851
X-original-commit: 31e0ed8c957e8a6af7f6bd5d449b450967206eab
Signed-off-by: Olivier Colson <oco@odoo.com>
To improve the payment method system, proceed to a few changes
such as changing the view a bit, making sure payment acquirers are not
linked to a journal by default and that only the manual payment method
type can be used multiple times in a single journal.
Task id #2573145closesodoo/odoo#73596
X-original-commit: 9122b367baea10e59b66e45bf7c458a6f1e82efb
Related: odoo/enterprise#19623
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The payment method added by account_check_printing is meant as:
> Preferred payment method when paying this vendor. This is used to
> filter vendor bills by preferred payment method to register payments
> in mass. Use cases: create bank files for batch wires, check runs.
But it may also select the default payment method on an account.payment.
With this changeset, we copy what is done in account.payment to
account.payment.register so the behavior is the same for it.
forward-port of #72655
opw-2508263
X-original-commit: a546e7e870987e882ab2c9a6fa2618476b76fcb8
Users may want to be able to have transactions coming from multiple
payment acquirers to be registered in the same journal.
This will allows that.
Task id #2414749closesodoo/odoo#67331
Related: odoo/upgrade#2500
Related: odoo/enterprise#17258
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce the bug:
- Let's consider a user U not in group group_system
- Log with U
- Create a vendor payment with payment method Checks
- Print it
Bug:
An access error was raised because U didn't have the rights to write on model ir.sequence
opw:2513014
closesodoo/odoo#70062
X-original-commit: 11376c88e0068a0bece0b0b56ffd4a9f296ffb87
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When printing a check from a payment the check number wizard shows the
number 1 for the next check... it should show the last check added one
+1, it doesn't because it doesn't exclude the account.payments without
checknumber.
This fix excludes the account.payments without checknumber so that it
doesn't shows "1" as the next check number when there are multiple new
checks to be printed
X-original-commit: adfb8299141cb8fe9883741c43871a51f849655e
1. Go to Settings > Accounting and set a Check layout
2. Go to Accounting > Vendors > Payments
3. Create 2 payments to Vendors, and Confirm (but do not print).
- Payment Type: Send money
- Partner Type: Vendor
- fill in any Amount
- Payment Method: Checks
4. Go to the accounting dashboard, click on "2 checks to print"
5. Select both payments and print the checks from the Actions menu
6. Refresh the page.
Both payments still show up with the "Checks to print" search filter
enabled. They also shows up in Accounting dashboard as checks to print
opw-2427523
closesodoo/odoo#64908
X-original-commit: 8ad9c16d7b10da17795c805b0541f0a3a9256dc4
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
the field can be used in reports for any payment method
---
opw-2423290
closesodoo/odoo#64105
X-original-commit: c37afdf3e9f680cd186872e509c6ab8e47b70782
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider a bank journal BJ with manual numbering activated
- Create a customer payment CP using BJ as journal and confirm CP
- Create a vendor payment VP using BJ as journal, select Check as payment method
- A Check Number with 0001 is automatically assigned to VP
- Confirm or save VP
Bug:
An error was raised saying that:
The following numbers are already used: 0001
PS: When creating the customer payment, a check number was assigned to CP even if
customer payment has nothing to do with check numbers
opw:2415170
closesodoo/odoo#63372
X-original-commit: f01eb942716800921148b5de8d6bc4140d122912
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When some bills are not paid, some with due date, some without, when registering the payment of these bills as a group payment with checks, it is not possible to print the check
To reproduce the error:
(Need account)
1. Go to Invoicing > Vendors > Bills
2. Create a new one
- Add at least one line
- Add the Payment Terms
3. Save & Post
4. Duplicate it, then Save & Post
5. Go back to Bills
6. Select the two bills
7. Click on Action > Register Payment
8. Select Checks, enable Group Payment
9. Click on Create Payment
10. Click on Print Check
11. Click on Print
=> An Odoo Error is raised
The user should be able to print it.
OPW-2389368
closesodoo/odoo#62391
X-original-commit: 4dc4dc3d20114bea54266d97de29565a1a1ac230
Signed-off-by: adwid <adwid@users.noreply.github.com>
Install "account_check_printing" module
Open "Accounting" icon from the main menu
It opens the journal dashboard by default
It runs the following search domain in account.payment model:
domain = [
...
('payment_method_id.code', '=', 'check_printing'),
...
]
It runs the following query:
SELECT "account_payment".id
FROM "account_payment"
WHERE ...
AND ("account_payment"."payment_method_id" in ($2)))
...
The average duration of this query is 37ms
It query is ran for each journal created
If you have created 600 journals (real case) so it will run 600 times
It will spend more than 22 seconds opening this dashboard
After that, you are available to create accounting actions since that
the menu is not available before of this dashboard
So, it is important to open it faster
Creating the following index:
- account_payment(payment_method_id)
The average duration of the last query is reduced to 0.935ms instead.
It means, it will spend 0.5s opening this important dashboard with 600 journals
44x faster
closesodoo/odoo#56831
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
PURPOSE
Improve performances of various Odoo code bits.
SPECIFICATIONS
Use a read_group to compute number of checks to print, using a search_count
instead of a search.
LINKS
Task ID-2281297
PR odoo/odoo#53053
PR odoo/enterprise#11299
X-original-commit: 7035b99b09152f224e74eed7d6b67a8ab04fdce8
Task 2005940
account:
* Use stored compute methods instead of default for
{out,in}bound_payment_method_ids
* Track is_move_sent in the chatter
* Split 'Invoices' and 'Bills' in the smart button of payment form
* Because account.payment.method can be shown on the res.partner form,
we need to relax the security level to readonly for all users
account_check_printing:
* Add the preferred payment method for partners, with a related on
account move allowing to do a group by and doing payments in batch
* Add a constraint to forbid twice the same check number in the same
journal
* The amount in words is now readonly to prevent typos and mismatches
with the amount in digits
* Remove the field `check_number_int`. The check number is kept as Char
so that '000012345' is not displayed (and printed) as '12,345' but it
is parsed so that comparison and incrementation are possible.
closesodoo/odoo#56179
Related: odoo/upgrade#1669
Related: odoo/enterprise#12527
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Steps to reproduce:
- Let's consider a company C in $
- Create a ventdor bill VB of 100$
- Validate VB and register a payment with a check in €
- Print the check
Bug:
The symbol of the currency of the payment was $ instead of €
opw:2314005
closesodoo/odoo#55813
X-original-commit: f05bd107aca192cd7e4b4ab84d0a3e61e932a241
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
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,... )
When the model is loaded, the value of 'check_amount_in_words' is computed for each existing payment.
It could lead to a traceback if the second condition is reached referencing an xml_id that is not yet loaded.
Indeed, data are loaded after the models.
X-original-commit: a9234e7581f267c64c4bf19d93e7b6844fe4d0b4
- 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>
Many localization modules adds field 'l10n_xx_country_code' on
Company/Settings views with the purpose of using it to hide that
particular localization's fields from other country's users.
So, it is better to add a common field in account module so that
other localization can use that field instead of adding a new one
where ever it is required.
Also, one such field was already added from account_check_printing
module, so we removed it from there as it is not needed anymore.
Task: 2049977
Closes: #35755
Related: odoo/enterprise#5158
Adding required fields on company model is annoying for tests. Indeed multi
company tests may run during module installation, notably in CRM. Those tests
generally require to create a new company which is not possible if the column
is required but module not already loaded in registry. This is the case
if for example account_invoice_extract is installed and updating CRM
when testing website_crm_score.
When possible, avoid required fields on a such used model as company. In this
case we simply make the field required in the view, and handle a void value
as the default disabled one, leading to no functional change.
closesodoo/odoo#48059
Related: odoo/enterprise#9381
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Go to Accounting > Vendor Bill, pay via check, view the invoice and
click on 'Print Check'. The widget will popup but as the 'next check
number' will always display 1.
This append because the model of account_payment has changed
https://github.com/odoo/odoo/blob/13.0/addons/account_check_printing/models/account_payment.py#L28
and now check_number is a char so it will not sorted correcly by the
database.
To avoid doing a lot of strings manipulation it is convenient to
store the check number as integer, with proper default case
Followup of opw 2151242
closesodoo/odoo#41659
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Now, if user intends to add a check layout for it's own country then he/she
will need to define a layout template and a report action associated to it.
The xmlID(s) of this report action(s) needs to set as key of
'account_check_printing_layout' selection field after redifining
it in it's own module.
Refer l10n_{ca/us}_check_printing modules.
closesodoo/odoo#35438
Task: 2030714
Closes: 35438
Related: odoo/enterprise#5007
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Task 2034073
The reconciliation widget is now entirely part of the enterprise version
as it is an advanced accounting feature
closesodoo/odoo#38424
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- Create a vendor payment by check
- Remove the amount in words
- Confirm
It is impossible to set the amount to print the check.
We add an action button to recompute the amount in words. It is only
visible when the amount is not set.
opw-2046339
closesodoo/odoo#35968
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit merges the following models
* account.invoice and account.move
* account.invoice.line and account.move.line
* account.voucher and account.move
* account.voucher.line and account.move.line
It was the opportunity for a big cleanup of the code, so it also restructures the whole account module, its different models/fields, the tests etc. for a better world and a better code readability.
==== Rationale ====
The rationale of this huge change is that we want journal entries / invoices to be easily edited, and changes reflected in the other model. It's a HUGE feature and very strategic for the fiduciary companies. For example, changing the account of a journal entry needs to be automatically reflected on the related invoice.
The same reasoning applies to sale/purchase vouchers.
==== Changes made in features =====
When creating an invoice, you are now creating a journal entry directly.
--> The object account.invoice no longer exists.
In the same fashion when creating an invoice line, you're now adding journal items directly in the journal entry representing the invoice. If this invoice line has some tax, it may create additional journal items as well.
--> The models account.invoice.line & account.invoice.tax no longer exist
Identically, when creating a sale/purchase receipt with its lines, you are now creating a journal entry directly and there's no more usability difference between encoding a receipt or an invoice.
--> The object account.voucher no longer exists.
--> The object account.voucher.line no longer exists.
--> The whole account_voucher module no longer exists.
Positive side-effects coming from these changes are
* draft invoices/bills/sale or purchase receipts now create a draft accounting entry. Validate these objects now simply post its journal entry. That means that draft invoices/bills/sale or purchase receipt can straightforwardly be included in reporting or budgets.
* opening a journal entry in form view will now always open the correct view: if it's a sale/purchase journal entry we will have a customer invoice/vendor bill view or a sale/purchase receipt view, whatever the menu we're coming from.
* code & business logic simplification. It is also condensed in a single place instead of being partially duplicated on invoices, vouchers and journal entries.
There should be no feature loss, except the one allowing to group multiple journal items together based on the same product during the invoice validation.
==== Changes made in models =====
* account.invoice: model removed. Instead, now use account.move with following mapping
field (account.invoice) field (account.move)
----------------------- --------------------
name invoice_payment_ref
number name
reference ref
comment narration
user_id invoice_user_id
amount_ total_company_signed amount_total_signed
residual amount_residual
state state + invoice_payment_state /!\ selection changed
date_invoice invoice_date
date_due invoice_date_due
sent invoice_sent
origin invoice_origin
payment_term_id invoice_payment_term_id
partner_bank_id invoice_partner_bank_id
incoterm_id invoice_incoterm_id
vendor_bill_id invoice_vendor_bill_id
source_email invoice_source_email
vendor_display_name invoice_vendor_display_name
invoice_icon invoice_vendor_icon
cash_rounding_id invoice_cash_rounding_id
sequence_number_next invoice_sequence_number_next
sequence_number_next_prefix invoice_sequence_number_next_prefix
'invoices' subset of account.move can be accessed by using the selection field 'type' or one of the many helpers like is_invoice()
* account.move: now has a valid state 'cancel' that has to be excluded from all business logic
* account.move: field 'amount' renamed into 'amount_total'
* account.move: field 'reverse_entry_id' renamed into 'reversed_entry_id'
* account.move.line: now has a field 'display_type' that has to be excluded from all business logic, in order to support invoice layouting
* account.invoice.line: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.line) field (account.move.line)
---------------------------- -------------------------
invoice_id move_id
uom_id product_uom_id
invoice_line_tax_ids tax_ids
account_analytic_id analytic_account_id
'invoice lines' subset of all account.move.line from a journal entry can be accessed by using the boolean field 'exclude_from_invoice_tab'
* account.invoice.tax: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.tax) field (account.move.line)
--------------------------- -------------------------
invoice_id move_id
account_analytic_id analytic_account_id
amount price_unit
base tax_base_amount
'tax lines' subset of all account.move.line from a journal entry can be accessed by using the relational field 'tax_line_id'
* account.invoice.confirm: model removed. Instead, now use the 'post()' function of account.move
* account.invoice.refund: model removed. Instead, now use account.move.reversal to reverse the entries with the same options as we had for invoices
* account.voucher: model removed. Instead, now use account.move of type in ['out_receipt', 'in_receipt]
* account.voucher.line: model removed. Instead, now use account.move.line
==== Changes made in functions ====
* on account.move, method _run_post_draft_to_post() renamed into _autopost_draft_entries()
* on account.move, method action_account_invoice_payment() renamed into action_invoice_register_payment()
* on account.move, method action_invoice_reconcile_to_check() renamed into action_open_matching_suspense_moves()
* on account.move, method _get_domain_edition_mode_available() renamed into _get_domain_matching_supsense_moves()
* on account.move, method _get_intrastat_country_id() renamed into _get_invoice_intrastat_country_id()
* on account.move.line, method _get_domain_for_edition_mode() renamed into _get_suspense_moves_domain()
* in account.bank.statement, contextual key 'edition_mode' renamed into 'suspense_moves_mode'
Was task 1917430
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
william-andre