The buttons created in the reconciliation widget by the reconciliation models did not apply the percentage of their lines correctly.
Example of the behavior before the fix :
1) Create a 'writeoff_button' reconcile model, with two lines of 50% on distinct accounts
2) Create a statement line of 100€
3) Open the reconciliation widget and apply the model created in 1) to the line made in 2)
=> Two lines are created, 50€ and 25€. They should both be 50€.
closesodoo/odoo#49963
X-original-commit: d3bd67fa12d85515fa6683f7b5d9ae114056bb62
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
- Go to Accounting
- On Customer Invoices kanban card, click on the 3 dots > Credit Notes
Invoices, credit notes and receipts are shown.
This happens because the action domain is overridden, while it shouldn't
be in this case.
We only set the action domain if the action name was not explicitly
requested.
opw-2242195
closesodoo/odoo#50052
X-original-commit: 5dab4d56055cc197fb0f3a6cd20e60cd0f638fa9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Do not set a default `account_id` for section and note lines. Indeed,
when set the constraint `check_non_accountable_fields_null` will raise.
opw-2241575
closesodoo/odoo#50040
X-original-commit: 997a98d2d3d12caf554040922876164040de9efa
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Such a change breaks XML-RPC calls. Moreover, it allows the creation of
partners without the accounts set, which will cause inconsistencies
later on.
This reverts commit 29c362b7c3353c2be11ab117f454d04ed9853f75.
opw-2241875
closesodoo/odoo#49982
X-original-commit: f720602ac24246d29de4919f18ae7c32cce2ffc2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Let's consider the customer invoice journal J with the default credit account A1
- Let's consider a customer invoice I with one line L1
- On L1 is set account A2 and product P1
- Import on I a new line L2 with account A3 and product P2
Bug:
The account of L1 was changed by A1 instead of keeping A2
opw:2230808
closesodoo/odoo#49582
X-original-commit: 115a18a1cdecdc6d76920efdf323fb91f2f408ee
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
During the onboarding, if Invoicing is installed but no chart of account
is set the field property_account_receivable_id and
property_account_payable_id prevent from validating a new partner
because they are required but not auto-filled, and the fields are not
visible if Invoicing is not installed.
closesodoo/odoo#49732
X-original-commit: 29c362b7c3353c2be11ab117f454d04ed9853f75
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
When creating or writing on a account.journal model,
it is possible to pass a char representing the bank account number
into bank_acc_number instead of passing directly a res.partner.bank.
In case we pass bank_acc_number the system will try to create automatically
a new res.partner.bank for us, however if a res.partner.bank already exists
with the same account number it will result in an error as we have a unicity
constraint for that. Therefore it is best to first seach for such an existing
res.partner.bank before trying to create it. The search is done on the
sanitized_account_number field as the unicity constraint is on that field.
closesodoo/odoo#49637
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Purpose of this commit is to allow multi-create in alias mixin by correctly
creating / updating aliases in batch.
Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Clean the usage of mail aliases and more specifically its associated mixin
`mail.alias.mixin` .
Stop using context for model of aliases, and correctly give model_id and
parent_model_id to the call chain through a cleaned code easier to override.
We also merge methods get_alias_model_name and get_alias_values in single one
called before record creation (alias first values) and right after (to have
values depending on actual record).
LINKS
Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
- Activate multi-currency
Company currency: USD
EUR rate: 0.14
- Set the decimal accuracy of Product Price to 5
- Create the following invoice in EUR:
Name Qty Price Unit Subtotal
A 38.0 38.73553 1471.95
B 222.0 4083.19000 906468.18
C 35.0 49.45257 1730.84
D 1.0 17.99000 17.99
- Save the invoice
- Edit the invoice and set a payment term, e.g. 30 days
- Save
There is a difference in debit and credit of 0.01 coming from the
following:
1471.95 / 0.14 = 10513.93
906468.18 / 0.14 = 6474772.71
1730.84 / 0.14 = 12363.14
17.99 / 0.14 = 128.50
SUM = 6497778.28
But the receivable account:
909688.96 / 0.14 = 6497778.285714286 => 6497778.29
When changing the payment term, all invoice lines are recomputed.
`price_unit` and `tax_ids` are in the list of the updated fields, which
triggers the synchronization of accounting and business fields. During
this synchronization, `_get_fields_onchange_subtotal_model` is called
and recomputes the debit amount, leading to the difference.
We only synchronize if the value of the business fields have changed.
opw-2209543
closesodoo/odoo#49605
X-original-commit: 70bd2c9c7a7c8ec832edd2c158f4f61b78cdeb37
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
External addons (such as the POS) can create entries and end up
bypassing the `_check_balanced` in the whole process.
We force a check at posting, since at this point there is no reason to
have an unbalanced entry anymore.
opw-2168096
closesodoo/odoo#49489
X-original-commit: 88902e2d3953a311dfb3629daeebf22b8874b6e9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.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>
Before this commit, we had an error when writing on account_opening_move_id, fiscalyear_last_day, fiscalyear_last_month on multiple company at once
closesodoo/odoo#49397
X-original-commit: 46c7b398b678da7a977e466e626162d66e1ee05f
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
In this commit,we add a proper reference on credit and debit
because we are referencing an attribute or attributes that
belong to more than one of the tables we are using in the query,
and have not qualified the attribute reference.
closesodoo/odoo#48796
X-original-commit: 9de090926390e2f02dea979347b477e31bc9188f
Signed-off-by: Christophe Simonis <chs@odoo.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.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>
- moved company_id in other info tab
- currency_id is shown near journal_id
- invoice:
-- ref renamed to 'customer reference' and move to other info tab
-- payment_reference hidden if state is draft
-- Fixed bug in l10n_in where xpath did not find removed element
- vendor bill: auto-complete only shown in edit mode
was task:2209497
closesodoo/odoo#48913
X-original-commit: 170635c901914cfe8f33fdbe8d498cbd5f54054e
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- Create an invoice without partner.
- Set a custom receivable account.
- Set a partner => the account used as payment terms is not recomputed that is wrong.
closesodoo/odoo#48898
X-original-commit: 33de1c8f5e459eb26194736c17c053dce3a1c206
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
In some situations, the context can contain a default journal id. When creating the cash
basis entry, we are correctly retrieving the Cash Basis Journal for the account.move, but
as we do not explicitly set the journal on the account.move.line also, it is using the
context default value for journal_id (usually the customer invoices journal). As journal_id
on account.move.line is a related field to journal_id of account.move, we are wrongly
updating it. We should populate journal_id on account.move.line explicitly to avoid this.
closesodoo/odoo#48837
X-original-commit: 73bcbdfddf0751d9aba27c9d101f60e6e844edb2
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
The moves that have this field set are the reversal of the value of
that field. Not the other way around.
closesodoo/odoo#48667
Related: odoo/enterprise#3334
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- open accounts in a full view instead of a modal
- ability to reverse entries at their own accounting date
- don't create draft closing entries and reminder if no configuration for tax groups
- reordered account menus
- improved invoice form view
Task ID : 2209497
closesodoo/odoo#48355
Related: odoo/upgrade#1001
Related: odoo/enterprise#9485
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
There is a default filter on Posted, no need to add it in the domain.
This prevented seeing draft invoices.
closesodoo/odoo#48635
X-original-commit: ca67c83e8d36ececaf97a7579c3ff2529b3e227c
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Before this commit, `accounting_date` was editable when Bank Statement is confirmed which doesn't make any sense as it is meant to be used for creating accounting entries on Confirming.
In this commit, we set `accounting_date` readonly when Statment is confirmed
closesodoo/odoo#48298
X-original-commit: 0ca74b447313325be8f4a29a0e0ae3c9056e8039
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- Create 2 companies C1 and C2
- Create a cash rounding method for C2, i.e. use an account of C2
- In the POS configuration of C1, choose the created cash rounding
method
When closing the POS, entries will be booked in C1 and C2 => error.
We define a `company_id` field which is a related to the `account`
company.
opw-2223150
opw-2217718
closesodoo/odoo#48632
X-original-commit: a1feee5db2d6509c0af8f59812a8e8ce5b23c662
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This new modelling makes it easier to add new QR-code formats, and allows using all of them in website_sale and account.payment's form view as well (so, Swiss QR codes are now available there, while they were restricted to only invoices in the past). All barcodes are now generated as reports, from a dedicated route. This was only partly the case before : Swiss QR added a cross on top of the QR-code directly in the template, it wasn't part of the image returned by the route; now it is.
[ADD] base_qr_code_sepa: new module decoupling SEPA QR-codes generation from the base module
Each new QR-code generation option should thus be done in a dedicated module (or added to a localization) in the future.
[IMP] base_qr_code_sepa: update the generated QR codes to version 2 of the specification
Version 1 is still supported, so no need to backport this.
[IMP] l10n_ch: make Swiss QR-codes compatible with the new version of the specification (the old one is deprecated)
This will be backported to 11.0 and 12.0, as these QR-codes will soon replace ISR.
[IMP] account: make it possible to mark manual payments as sent with a button on the form view
This way, when making them directly with a QR-code (or doing a more classical wire transfer), people can keep track of what they already have asked the bank to do, and what they still have to treat.
closesodoo/odoo#44839
Related: odoo/enterprise#8262
Related: odoo/upgrade#992
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Create an account in foreign currency;
- Create different currency rates for the foreign currency at different
dates;
- Create a journal entry at past date X with 2 lines, and use the
"foreign currency account" for one of the lines, but a domestic
currency account for the other;
- Now try to reverse the entry at a later date with a different exchange
rate (select an appropriate date in the wizard).
Before this commit, an error was raise because the move is not balanced.
This issue occurs because the 'amount_currency' value is used to
recompute the debit/credit value based on original currency rate. But
the _onchange_currency function is also called, and it recomputes the
credit/debit for the foreign currency line with the exchange rate of
the date of the reverse entry.
This commit is a fine-tuning of ae3d7aeb706dc1bc3216fd63c6a943e5d9cb56e7
to avoid recomputing credit/debit in a reverse entry.
opw-2227098
closesodoo/odoo#48609
X-original-commit: 748b2bcb3950840d815040684f72802c968240f2
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
When the currency_id is unset from the invoice and account moves are set,
by means of updating taxes or the line itself,
since there are no checks on the actual presence of a currency,
currency methods will invoked causing crashes.
Imposing the condition directly on top of the onchange solves the issue.
Since the currency_id is a required field for the invoice the
recomputation will be triggered again with the correct values.
opw-2192628
closesodoo/odoo#48458
X-original-commit: f795b1bc7b42bdcbd4bd9895616461d2702f1e41
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit ensure the user have to minimum rights to post invoices
The 'Post' button was already hidden but the post() method is public
Task : 2206969
X-original-commit: 28ae3fb5366d61d3f5f9067cda962b047105199e
When you create a invoice from a sale_order
the account was taken from the journal and
it should comes from the product
or the product_categories and in last resort the journal
and finally fiscal position should have been apply.
It was not the case anymore,
because setting the partner_id prior the account_id
trigger the default_get on the account_id which
in that case take the wrong value
closesodoo/odoo#47267
Solution: set first the account_id then the partner_id
X-original-commit: 857564367691f3f11572f718499c9d22c823c421
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- Create and validate an invoice in a date (near the end of the fiscal
year for example: 20.12.2019) in a foreign currency;
- Pays the invoice in a different date (23.12.2019), the invoice is
settled and a currency exchange is created;
- In the new fiscal year (for example: 03.01.2020), amends the invoice
(a description change for instance): cancel the invoice, change the
invoice into draft, made the amends, re-validate the invoice and
re-settle the invoice (a new currency exchange reversal is created).
Before this commit, when cancelling the invoice, a currency exchange
reversal is created at the current date (03.01.2020) to revert the first
currency exchange reversal. When the invoice is re-settle, a new
currency exchange is created a date of the payment (23.12.2019).
This means that, in the fiscal year of 2019 two currency exchanges were
created, and in the new fiscal year of 2020 a currency exchange revert
is created. To avoid this erroneous situation, the date of a currency
exchange reversal should be the creation date of the currency exchange.
Now the currency exchange reversal entries has the same date as the
initial currency exchange entry.
opw-2209675
closesodoo/odoo#48344
X-original-commit: cedfbd0379a907650db9b23f6c5203522d4ced95
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Steps to reproduce the bug:
- Lets consider two companies C1 in € and C2 in $
- Let's consider two customer invoices I1 in C1 and I2 in C2
- Select these two invoices in the list view of invoies and print it
Bug:
A traceback was raised because the function _convert expects a singleton
opw:2222140
closesodoo/odoo#48323
X-original-commit: b66bcfe96dfdc62a1faa26ccf9c6adfa2b8929a4
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this fix, when default debit and credit account where not
set on the journal, there was a simple error message saying
that an account was missing on an invoice line:
"Missing required account on accountable invoice line."
Now, the error message tells on which journal the accounts are missing,
giving better insight to the user.
Update addons/account/i18n/account.pot
Update addons/account/models/account_bank_statement.py
closesodoo/odoo#48312
X-original-commit: bb4b707fbcafa54a2e8b8a6e73fbe102b8b13811
Signed-off-by: jev <jev-odoo@users.noreply.github.com>
Co-authored-by: Richard Mathot <rim@odoo.com>
Co-authored-by: Richard Mathot <rim@odoo.com>
Fixes#47147
Followup on 39e2dfca0a4a2cf641a50ee9af510180fff6eb9c and 737eaf9333
Before this commit, Accounts with single character code was setting non-existing `root_id` which crashes on Grouping by using that field. (and also Accounts were not visible search panel)
With this commit we support computing `root_id` with Single Character.
closesodoo/odoo#48261
X-original-commit: d93ccdc5a25c061468870359ad8f749496140d19
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
PURPOSE
Clean and rename code about language management and template rendering in mail
template model.
SPECIFICATIONS
Clean method naming and try to make code easier to understand and call. Also
add and/or clean docstrings of rendering methods.
Notably
* ``_classify_per_lang``: for each lang-contextualized template, give the list
of record ids;
* ``_render_template``: now working only on a valid list of IDs instead of
allowing both int / list and having a return type depending on the input
type. It allows to simplify code and delegate some processing to callers;
Introduce new API method
* ``_render_lang``: for each record id return the lang matching it;
* ``_render_field``: render a field of mail.template, on given set of record
ids. Usage: template._render_field('body_html', records.ids). Language
computation is available for this method;
Remove the "multi mode" support of rendering that either returned a rendered
value, either a dict based on given ids. Now all methods always work in batch
and caller have to fetch the correct result if necessary.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
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
This code adapts all business code instances of calls to
`resolve_2many_commands` and replaces them by calls to `new` which
returns a record-like object whose api is more familiar than the
`resolve_2many_commands` api.
opw-2220539
The depends of _compute_name and _compute highest_name could lead to a
double recompute.
To reproduce:
* create a draft invoice in a new journal; a name is set
* post a new invoice in the same journa; the name is the one of the
draft + 1
* post the draft invoice; the name is changed to the other posted + 1
but it shouldn't
closes#47944closesodoo/odoo#48144
X-original-commit: 2d7b751477d9c723fcbbc868534f47565e0a1621
Signed-off-by: Josse Colpaert <jco@openerp.com>
Write on business field on account.move.line
may lead to an unbalanced move due to currency conversion
from the price_subtotal to debit or credit
How to reproduce:
You need to create an invoice in a different currency
than the company currency
The rate form currency to company currency should be much
bigger then 1 for example 8 or 10
Create a line the will have a pricesubtotal
with 3 decimal
For example:
price unit : 28.8
qty: 4
discount: 22%
the price_subtotal will be 89.856
rounded in the form to 89.86
Based on that with a rate of 7.79356837023608
You end up with a credit of 700.33
then write on the line, for example the analytic account
It will trigger the computation of the price subtotal
and directly with that value the credit
and you endup with a credit 700.30
which is not balanced with the 700.33 of the other line
Solution:
Always round the pricesubtotal computed with the currency before
using it in any further computation
closesodoo/odoo#47305
X-original-commit: a60017df0e947e32f0606ee1487224d2c00470a4
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Previously a task was created to prevent holes between bank statement,
meaning that starting balance should always be the same as previous
ending balance. The goal was that during synchronization or imports,
we could add statement lines in previous statement and not have to
recompute manually the full chain of starting and ending balance of
next statements entries. This works fine with online synchronization
as we always write after creating the statements the balance
of the account on the latest statements to detect missing stmts,
however if we create stmts by hand, it is possible that we have the
following case:
Statement on 10 January with a starting and ending balance of 100 and 200
respectively. We are missing 2 statements with a line of 50 each before that
date. So we create the first missing statement at date: 8 January with a
starting balance 0 and ending balance 50, this will recompute the starting
and ending balance of next statement and overwrite the values to 50 and 150
(starting and ending balance respectively). At that time the system will say
that everything is normal but we are still missing a stmt and we are not seeing
it.
The way to fix this is by not touching the ending balance of the last
stmt entry during the computation, that way we can still detect that there is
an error and that 50€ are still missing.
closesodoo/odoo#48000
X-original-commit: b97b4f4217989e8cae5c32be0d62c11d36eaf1d7
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Field is_valid_balance_check is used to display a warning in case
starting balance of a bank statement is not the same as ending balance
of the previous statement. However the check was done without rounding
resulting in some error in the following casse:
starting_balance = 10.00000001
previous_ending_balance = 10
X-original-commit: 6673d23cfdee97b1e5e6368bc527a9a784578977
As we already have the Post Automatically concept in account.move, we want to be able to use it for vendor bills.
This way, e.g. one can prepare all it's office rents bill for the year and everything will be automatic..
Other changes :
- auto_post reset to False when move is canceled
- auto_post set to readonly in view when state != draft
Task : 2200743
closesodoo/odoo#46218
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
oco-odoo