* Previously, when reconciling journal items in multi-currencies, the exchange difference entry was created only on the full reconciliation. It will now be created directly at each partial to ensure the ratio between amount_residual_currency and amount_residual is always kept identical.
* Also when reconciling two lines, one with a foreign currency and one expressed in company currency, the reconciliation is now made based on the foreign currency.
==== RATIONALE ====
This patch allows to fix the following use cases (among others)
1) When everything is expressed in foreign currency, the reconciliation is made in that currency:
Suppose EUR is the foreign currency and USD is the company currency. Reconciling:
L1: 120 EUR 60 USD (rate 2:1)
L2: 240 EUR 80 USD (rate 3:1)
..leads to a partial of 120 EUR and min(80, 60) = 60 USD
After the reconciliation, L1 is fully matched but L2 is still open with 120 EUR but only 20 USD.
This is the first problem is the current reconciliation because L2 is supposed to have a rate 3:1 so the residual amount should be 120 / 3 = 40 USD.
Since the rate is no longer consistent on L2, the user will probably close the reconciliation by using another line in EUR or will close manually the reconciliation with 20 USD but without any additional exchange difference journal items explaining where this unconsistency comes from.
2) When the current lines are mixing multiple currencies, the reconciliation is made using the company's currency.
In some countries like Mexico, Ethiopia or Costa Rica, the customer is free to pay an invoice using the company's currency instead of the foreign one.
So, suppose USD is the foreign currency and MXN is the company currency.
The invoice is expressed by:
L1: 120 USD 60 MXN (rate 2:1)
If the customer is paying at a date in which the rate is 3:1, he is free to pay
either L2: 120 USD 40 MXN (rate 3:1), either L2: 40 MXN.
In the second case, he is expecting the invoice to be fully paid because its paiement is equivalent to 120 USD at the payment date.
In Odoo, the second case led to an open balance of 20 MXN and the invoice was not completely paid.
Even this situation could be easily fixed by a manual write-off, this makes the Mexican payment EDI very complicated to fullfil correctly because the government is expecting a complete matching between the invoice and the payment.
When the customer is paying multiple invoices or the invoices are paid using multiple payments, the currently generated mexican EDI file in Odoo was wrong.
==== REFERENCES ====
Original idea suggested by hbto@vauxoo.com. Thanks for the contribution and patience of the many persons having, at some point, helped on that.
github issue: https://github.com/odoo/odoo/issues/37469closesodoo/odoo#84201
Task: 2669371
Related: odoo/enterprise#24268
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Query counter tests related to account composer are actually dependent on
l10n due to extra queries, related to account.move fields and/or COA
specific code. Moreover some COA might skip or delay the sending, leading to
emails not being sent.
Purpose would be to run those tests only with generic_coa. Those tests will
be moved and improved soon, removing it currently to avoid frictions with
L10N builds.
This reverts odoo/odoo@d0e0db3b8eclosesodoo/odoo#86540
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Just have some numbers before working on composer onchange removal and see
its impact.
Task-2789182 (Account: Invoice send performance test)
Prepares Task-2088884 (Mail: Composer onchange removal)
closesodoo/odoo#85902
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
A new field on tax groups makes it now possible for this group to be displayed under a subtotal label. If not set, this defaults instead to "Untaxed Amount", keeping the traditional behavior. This is intended for withholding taxes, which can now be implemented with negative taxes and a tax group with this field set.
To do that, this commit entirely refactors the way amount_by_group worked, and replaces it with a more complete json field called tax_totals_json. It also streamlines the way taxe totals are displayed on invoices, PO and SO and makes it so that a common code is called instead of copy-pasting the same block 3 times as before.
[IMP] purchase: always display tax totals by groups on purchases orders
Before, tax totals on purchase.order's form were not shown by group, and were instead all aggregated in a single "Taxes" category. The same went for the pdf export. The portal view, though, did show the totals by group. We now display the tax groups in the same way all the time.
closesodoo/odoo#74138
Task: 2457374
Related: odoo/enterprise#19802
Related: odoo/upgrade#2670
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
In some reports, we need to detail the taxes for each journal items.
This is the case of all EDIs, the SAFT-report, l10n_in etc.
This task adds an SQL view mapping each tax lines with their corresponding base lines and computing the tax_amount and base_amount.
closesodoo/odoo#70866
Task: 2352524
Related: odoo/enterprise#18344
Related: odoo/upgrade#2686
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This reverts commit 7e3e99adb4.
Usability of that new wizard was too poor. We revert it for now; it'll make a comeback eventually.
closesodoo/odoo#63436
X-original-commit: 1d75786b8b45fd4f6b08d726165b60875b62b1e7
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
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: 2301180
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>
Task 2201948
*These actions were either unused or only used in enterprise modules.
The first ones have been deleted, and the second ones have been move to
the corresponding enterprise modules.
* account.fiscal.year: the whole model has been moved to enterprise
closesodoo/odoo#46110
Related: odoo/enterprise#8706
Related: odoo/upgrade#1083
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.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>
On invoices, we had cases where the supplier was added as a follower to
the invoice, and an email was sent to them.
This commit adds tests that reproduce the same follower assignment that
happened in saas-12.3, and fixes the issue for 13.0.
We also treat the case when custom_values is None (the default value),
and call the super method instead of just returning False.
Since saas-13.2, account.move.name is computed, so there is no default
value, and no need to specify it at the invoice creation.
closesodoo/odoo#49004
X-original-commit: 4a32716c0c57fe904e1aeea63926fb5b65e3516b
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
This wizard also reconciles automatically entries done on reconcilable accounts. It can hence for example be used to "move" the balance of a receivable account into a payable account (or the opposite), using the generated transfer entry to do as if the receivable and payable accounts were directly reconciled together.
[IMP] account: display 'P' as matching number when account.move.line objects are partially reconciled
For this, we introduce a new matching_number field, used in account.move.line's tree views instead of full_reconcile_id, which used to be shown directly.
Was task: 2037318
closesodoo/odoo#39415
Related: odoo/enterprise#6544
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
There is actually nothing preventing changing the company of some records even
there is some journal entries/items that are using them.
closesodoo/odoo#41945
X-original-commit: b3b66304eb98819cd87d6e4c7a29ca4803ffc3ff
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
A simple test to easily check performance of the reconciliation.
opw 2121587
Co-authored by: François Honoré <francois.honore@acsone.eu>
closesodoo/odoo#41272
X-original-commit: 616c7d4252b30cee0a17ac776a17b626ee815c74
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
- Introduce a new account.tax.report object
> Tax report lines now refer to a tax report, and the tax report to a country
- Tax report lines can share tags accross reports within the same country
> To support the cases where some report is a simplified version of another one: some of its lines can be computed in the same way as the 'bigger' report.
> This is done by giving the same tag_name to the tax report lines, and the same country_id to their parent report.
> Full support for tag name modification, and the way it impacts the shared tags (sometimes, we can overwrite them all, sometimes we must delete them, sometimes, we create new tags to replace them on some report lines).
- Support copying tax report (and the lines/tags linked to it), so that it is possible to duplicate them and change the country set on the duplicate for use in another country (coopying is way better as replacing in place, as we don't keep any link to an xmlid, and still allow using the original report in the original country it was created for).
- Make all l10n* modules compatible with those changes
closesodoo/odoo#38964
Related: odoo/enterprise#6217
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
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>
To prevent having holes between statements and for better usability using import and synchronization
we try to automatically set the starting and ending balance based on the previous existing
statement.
To do that, we added a new field previous_statement_id so that whenever we change the ending_balance
of the previous statement, we recompute the starting balance and ending balance of the current statement.
Also creating a new statement in between 2 others statements will automatically set the correct value
to the starting and ending balance of that statement and all the statements afterwards.
Exception: creating a statement by hand won't automatically set the balance_end_real, however if you
create one between 2 statements, the balance_end_real of next statements will be recomputed
Was Task #1880409closesodoo/odoo#38696
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Task 2074811
Allow to specify on an account the journals that can be allowed
Example of use case :
* I create an IFRS journal and some specific IFRS accounts
* I want to make sure that the accounts I configured for the IFRS are
only use to make entries in the IFRS journal
In this commit we also prevent from changing the configuration of a
journal if there are account.move.line that should not have been allowed
to be created with the new configuration.
closesodoo/odoo#38255
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>
This fix is similar to 8020033; both are workarounds for the bug (limitation)
introduced by 9d87d15db6.
In this case, the currency_field is a related field, and these fields are only
computed after scalar values are written in database.
As a result, this value is not rounded at creation.
It is a problem since typically accounting reports are written directly in SQL,
and thus reuse the values directly.
Anyway even in the ORM the convert_to_cache optimised this away using the
assumption that 'the value should have been rounded in convert_to_column'.
It follows that in the report, errors can be accumulated
to the point where the report is not balanced.
This needs to be fixed in database by going through every existing line.
Of note: the limitation that was readily acknowledged has not been worked around
anywhere, in fact almost every single currency_field is a related one.
Also of note, commit afef71d6b should "Always round monetary values in database"
while it explicitly checked for the presence of the currency_field in the values
and while not introducing a mechanism to make sure it would always be in the
values.
opw 2066849
closesodoo/odoo#38376
X-original-commit: 937893379ba8c149c681b61a951ca507df798e6b
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Because of f206714af0 and subsequent commits, adding groups may raise.
We ensure that switching between tax included and tax excluded keeps working.
Closes#37481closesodoo/odoo#37633
Forward-port-of: #37517
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
The tax lock date no longer blocks the user when creating a journal entry priors to it.
Instead, the accounting date is moved automatically during the validation to the next
available date.
This commit also brings more flexibility when dealing with the tax lock date. Indeed,
the error is now shown only when adding something impacting the tax report that was not
always the case before (e.g. adding a new line not affecting the tax report must not
raise something).
Others check has been also refactored to be more consistent with the "fully editable" mindset.
closesodoo/odoo#36304
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Purpose
=======
To correctly choose in which account a line should be posted,
we have to know if the partner is a customer or a supplier.
Specification
=============
Keep track of the number of account moves "in" and "out"
a partner has. These counts should be based on the posted
account moves. A customer that has been created from the
'Customer' menuitem will have a rank=1. When a customer
invoice will be created for him, the generated account moves
will be taken into account to compute its rank. The most
invoices we have for a partner, the higher his rank is.
Note: To avoid any concurrent update failures on the partner,
if one transaction has already locked a partner row, the count
update will be skipped that time.
This means the values may be approximative in the database!
The exact values will eventually be correctly computed at
the next successfull try.
Known limitation of this approach: The computation ignores
the set of currently selected companies. Actually, storing
context dependent values in the database is a bad practice,
and is avoided in that case by taking all the companies into
account.
Use the stored fields `customer_rank` and `supplier_rank`
to order partners when searching by name. This allows to show
best customers or best suppliers on top.
To choose if best customer or supplier are shown on top,
the context key `res_partner_search_mode` is used.
The context key can take two values: 'customer' or 'supplier'.
This decision partially reverts/revamps 8766f38 to only use
account moves instead of PO and SO
On actions showing partners, set a default filters to menus to
only display customers (customer_rank > 0) if the string is
"Customers", and only suppliers if the string is "Vendors" or
"Suppliers".
TaskID: 2049131
closesodoo/odoo#35942
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Follow up of 61de1c263a
- Remove the dangerous **kw from the route in favor of specifying useful args.
- Use the existing method to link attachments to message instead of duplicating
the logic in an incomplete manner.
- Fix an issue where the actual email would not be sent if the message was empty
but an attachment was defined.
- Ensure the send attempt is done immediately instead of after the cr commit.
The goal is to show potential error messages correctly to the user with the
crash manager instead of a generic error page.
This also increases the send timeout and prevents the error in the first
place in most situations.
closesodoo/odoo#35263
Signed-off-by: Christophe Simonis <chs@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
The onboarding modal for setting up the few base fields of a company
has now been moved to a wizard
It is accessible from the general settings, but also in the onboarding
section of sale and account modules.
The following company settings are editable with that wizard:
- Set report **layout**:
The user can chose the overall look of the report. The current choices
are : *Standard* (default), *Background*, *Boxed* and *Clean*.
- Set company **logo**:
Changes the company logo.
- Set report **colors**:
The user can set the primary and secondary colors of the report through
a newly added widget allowing to pick a custom color.
When changing the **logo**, colors are automatically set to its most dominant
colors.
> A "Reset colors" button also triggers the color calculation.
- Set report **font**:
Changes the overall font of the report. Only Google Fonts are used
for enhanced compatibility.
- Company **tagline**, also called "header"
- **Footer**
- **Paper format**
- Report **preview**:
A mockup of a final report
Automatically updates when changing **layout**, **logo**, **colors** or **font**
Co-authored by: Julien Mougenot <jum@odoo.com>
closesodoo/odoo#33863
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Lucas Perais <lpe@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
Purpose:
Journal entry can be changed the way we want while the lock date is before then entry date..
Entry : Draft -> Validated (or posted)
Specs:
add a date field in the accounting settings: tax lock date
implement a constraint ensuring that no one can modify the information related to tax on account.move.line prior to this lock date. That means the debit, credit, tax_ids, tax_line_id fields. Other fields can be modified. This also means we cannot create/delete an account.move.line with tax information prior to this lock date.
Task 1914762
closesodoo/odoo#29272
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
When creating a new line on a customer invoice, we could get the price
unit in the company currency instead of the invoice currency.
This is because the uom_id onchange would ignore currency when setting
the price.
Changing an invoice line's price unit on uom_id change was introduced
in february 2018 in saas-11.3 with 3a38080ff.
Change to how currency is applied when setting an invoice line's price
unit was introduced in june 2018 in 9.0 with 367fadc8.
So there was a missing part in saas-11.3 to adapt 367fadc8 for 3a38080ff
change that is added with this commit.
Without the fix, the added test failed with:
AssertionError: 10.0 != 20
opw-1920504
closes#29776
Bank statement lines need to be matched with entries; We have to automate this operation as much as possible.
At the same time, create an algorithm that fit everyone needs is quite impossible.
For that reason we will let users choose the rules they want with the improvement of reconciliation models.
Note that we did it only for bank statement reconliation, not for manual reconciliations.
Was task: 1877375
Was PR #26669
l10n modules are blacklisted on the runbot.
With this commit, a tagged test is added that installs all the l10n
modules. A chart of account is installed in a different company for each
one. This test is a first step to test all l10n. It's intended to be
launched by a runbot cron script.
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
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
- 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.
Laurent Smet