opw-2294930
The tax amount not included in price should be computed in the remaining
balance, even if not included in price.
closesodoo/odoo#54356
X-original-commit: 6a6aefdfac472421b9cf6de043682a6cdc131d85
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Issue
- Install 'Accounting' app
- Create tax A and tax B for 5%, make sure they are NOT included in price
- Create a tax C as a group that includes Tax A and B
- Go to any bank journal and create a statement line for 100 dlls
- Click Reconcile
- Select Manual Operations
- Select any account
- Add Tax C
- Check on 'Tax Included in Price'
Wrong calculation.
Cause
Not considering forced 'Tax Included in Price'
('force_price_include'),when cumulating tax included
amount.
opw-2280714
closesodoo/odoo#54003
X-original-commit: 523e407e164d96ead0ce836e3dc1a6bb8f258af9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
- Create an invoice with a Product X and Post it;
- Generate a Credit Note from the invoice;
- Reporting > Invoices;
- use Pivot Table View;
- Enable 'Product Quantity' in Measures;
- Filter by 'Invoice #';
- Expand Pivot Table by 'Product'.
Before this commit, the products in the credit note had a positive sign,
contrary to the untax total that has a negative sign. The issue with
this, is when the quantities of the credit notes is added with the
quantities of the invoices the total is not coherent with the actual
sell products.
Now, the product quantity that comes from a credit note has a negative
sign. This was already the behaviour in version 11 and 12.
opw-2283833
closesodoo/odoo#53931
X-original-commit: 917b2076b77ba3f682b342989c41b7f7d0670ca2
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
* Improve layout of access error messages from group restriction
* Improve layout of access error messages from security records rules
* Use the error title in the js crash manager when possible
* adapt unit tests
closesodoo/odoo#50369
Taskid: 2206787
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Fields that are shared between account.payment & account.move models are badly set when creating the records.
For example, 'partner_bank_id' in vals will be set on account.payment but not on the account.move.
closesodoo/odoo#53832
X-original-commit: a23c1e30c5b6b28f25c5f76d9fb85f075433b18f
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Activate multicurrency and use a 1.5 rate on USD to EUR (to ease
calculations)
- Create two customer invoices in EUR (company is in USD) for two
different partners (e.g. partner1 and partner2) with only one line and
an amount of 100 EUR (removed the tax as well so that payment term line
is 150 USD on receivable account)
- On the "Invoices Matching Rule" reconciliation model:
1. Set Amount Matching to 90%
2. Define any account for the counterpart
3. Remove "Same Currency Matching"
4. Ensure "Partner Is Set & Matches" is marked
- Then create a new bank statement with two lines as follows:
1. dummy label, partner1, 140 USD
2. dummy label, partner2, 100 USD
- When clicking on reconcile,
1. the line for partner1 is not matched
2. the line for partner2 is matched
This occur because the amount from the invoice is not correctly
converted in company currency before making the check with the bank
statement amounts
opw-2261134
closesodoo/odoo#52529
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
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>
Invoice matching rules now also match account.move.lines based on their partner's name : if the statement line's payment reference contains the first name and last name of its patner (in any order, at any position), we match the move line.
closesodoo/odoo#50083
Related: odoo/enterprise#10166
Related: odoo/upgrade#1317
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Partner mapping is a new field defined on invoice matching reconciliation models. It allows defining a mapping between partners and regular expressions. When ran, on a statement line without any partner set, those rules use this mapping to assign a partner to statement lines without any one set, using the regular expressions to match the payment reference of the statement line.
It is important to note that the mapped partner will only be set to the statement line when the reconciliation is actually performed (so, when clicking the validate button, if the matching rule is not auto_reconcile = True), just like with the partner_map.
This limit is set by the past_months_limit field of reconciliation models. When set, it specifies the number of months in the past to search for matches when using this model. Older move lines will be ignored.
The point of this feature is to exclude too old stuff that we know we won't reconcile (because of import, old misconfiguration, former misuse of some features, ...). It also allows reducing the number of move lines taken into consideration, and solving perfomance issues functionnally by isolating the move lines into smaller periods to reconcile them separately.
When opening the reconciliation widget and calling the matching rules, instead of calling all the rules in a single huge SQL query and then iterating on all the statement lines to match them with the results, we now first group the lines per applicable model and each time call a distinct (but way smaller) query for each group, stopping trying other rules for a statement line when one returns candidates. More queries are performed, but they are way more simple.
Task 2274998
1/ In the accounting dashboard, maximum one primary button per box
2/ In all boxes : "Sample data" must be removed. (Too obvious)
3/ In the configuration of Accounting Periods
* Opening date and fiscal year end must be on a same line.
* Remove the button "Configure your tax accounts".
4/ "Configure your tax accounts" is still available in the settings.
* But also make it available while doing the Tax Report Entry, if an
error message pops up.
5/ Chart of Account (list view)
* Captital D for opening Debit/Credit
* Rename "Name" into "Account Name"
6/ While génerating an Invoice
* Rename "Post" button into "Confirm"
* Check that the incremental number is added as a suffix of the name
of the bill ; not as a prefix
7/ Vendor Bill (list view)
* Status must appear as a Tag ; like it is already done in "Payment
State"
* Rename "Payment State" into "Payment Status"
8/ Bank journals
* On the bank journal level, if bank feed is set to synchronization,
then while selecting that journal from the accounting dashboard, then
directly go to the statement lines rather than the bank statement
itself.
* In the bank statement's account moves, remove the button duplicate.
It is enough to have it in the actions.
closesodoo/odoo#52818
Related: odoo/enterprise#11081
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
As _toggle_reconcile_to_true updates the amount_residual on unreconciled
move lines linked to the account, _toggle_reconcile_to_false must
set the amount_residual to 0.
However as the SQL query is broken the update fails and move lines
supposed to have 0 as amount_residual still have the value.
closesodoo/odoo#52533
X-original-commit: 8e32134cedce688c0fa33d1c51c5570d63f14efa
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
The description of the model is used in sentences like
This <model> has been created from: <link>
All model descriptions should be singular
Courtesy of Erwin van der Ploeg for raising the issue
closesodoo/odoo#51837
X-original-commit: e0acef778272abb748dacfe4460b3536b3c30a82
Signed-off-by: Martin Trigaux (mat) <mat@odoo.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>
[FIX] account: reconciliation models: don't mix currencies when checking the candidates for applicability of a model
Before that, similiar amount of different currencies could be matched together, regardless of the exchange rate. We now entirely forbid this case from the reconciliation models.
closesodoo/odoo#51153
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This restricts the attributes of a BaseModel instance to `env`, `_ids`
and `_prefetch_ids`. This way, one can only assign fields on a record;
other assignments are programming errors.
This also reduces the memory footprint of records from 168 to 64 bytes
(-62%), and makes their instanciation faster.
closesodoo/odoo#51075
Related: odoo/enterprise#10529
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Fine tuning of the test of https://github.com/odoo/odoo/commit/d9eaae8acc600f936fbc4fa48a49a7f4d65fcd7f
As the journal was not explicitely set, a default journal with a company different that the one set up from
function setUpClass() defined in class InvoiceTestCommon
So a traceback was sometimes raised in the test saying:
Some records are incompatible with the company of the Journal Item.\n\nIncompatibilities:\nFields: account_id\nRecord ids: 1809, 1810, 1811
opw:2244708
closesodoo/odoo#51285
X-original-commit: dd40fb63b4ebdd4dd7b44c75d415e99b52d633a1
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
Let's consider a company C with french accounting
Create a new journal entry JE with one line L with debit = 100 and credit = 0
and account = 601100 Achats stockés - Matières premières ou groupe A)
Set TVA déductible (achat) 20,0% TTC on JE (where this tax is included
in price but not included in base amount)
Bug:
A new line is created on account 445660 TVA déductible sur autre bien et service with a debit = 16,67 instead of 20.0 and credit 0
Now with this fix, we consider that the amount encoded by the user is the base on which each taxes must be computed (instead of
magically subtracting included tax from the base)
opw:2244708
closesodoo/odoo#51219
X-original-commit: c9ce26534d2f8fa69068bfdbeb9994eb12d4124e
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The properties must always be accessed using the company of the journal entry defined by
its journal.
closesodoo/odoo#51094
Task: 2244829
X-original-commit: bf416d95b1216c5780d3dbeaa32f0e57dc50c574
Related: odoo/enterprise#10543
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Set the Product Price precision to 5
- Create an invoice with one line:
No taxes
Price Unit: 0.895
- Save
An error is raised because of an unbalanced journal entry.
The root cause is the `balance` which is not rounded. This is due to the
fact that the currency field (`company_currency_id`) is a related and
not set at the moment of computation. This leads to this being equal to
`0.01` instead of zero:
https://github.com/odoo/odoo/blob/ed1926cb12c830f383dbe540cb96e14d0804eb3d/addons/account/models/account_payment_term.py#L64
Note that if the line is saved with another value then the price unit
is modified, the error doesn't occur since the balance is properly
rounded.
opw-2209543
closesodoo/odoo#50655
X-original-commit: bd4bf1fe759a70d0b44606f1b2a3b27f8e71971d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
With this commit, module operations such as install, upgrades and
uninstalls are henceforth forbidden inside unit tests and instead such
tests must be performed with standalone Odoo scripts.
This is done because module operations during tests are not
transactional, this can leave the registry in an unclean state and
further tests may be affected by this, it also creates a new registry
which complicates registry cleanup if anything crashes,
because the registry to be cleaned up is not the same one that crashed.
Instead, what should be done is a script that imports odoo as a library,
and loads the database necessary then performs whichever operations
necessary. This script should contain a single function with a single
parameter (env) and should be decorated with
@odoo.tests.common.standalone in order to be executed properly, this
decorator accepts any amount of positional parameters as tags that can
be specified when calling the script in order to execute only a select
subset of scripts.
Special tags are: 'all' and <module_name>, these are generated
automatically, the first will execute ALL scripts available whereas
<module_name> will execute all scripts introduced by said module.
When calling the test_module_operations script, only scripts found in
*installed* modules will be executed, script discovery is only possible
if the code is loaded therefore it is only possible if the module is
installed.
closesodoo/odoo#49669
Signed-off-by: Adrian Torres (adt) <adt@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>
- 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>
Followup of #48896, ensures that the registry is correctly cleaned up
after the installation of the different l10n_* modules and that the
subsequent setup_models is done with the correct registry
closesodoo/odoo#49197
X-original-commit: bfd6bdcd89724f04442bbe07307177c523bed5f0
Signed-off-by: Raphael Collet (rco) <rco@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>
- 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>
Task 2206699
* All the amounts are now expressed in the company currency
- The amounts are taken from debit/credit on the aml
- When opening the report for multiple companies, convert in the
current company's currency
* New default view:
- Group by month instead of category
- Line chart instead of bar chart
- Filter on customers
* Remove useless fields:
- name
- invoice_partner_bank_id
- invoice_payment_term_id
- residual (including taxes)
- amount_total (including taxes)
- nbr_lines as it is a generic feature
* Rename currency_id to the more correct company_currency_id
* Remove useless group_by clause from the SQL query
closesodoo/odoo#47066
Related: odoo/upgrade#1021
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before this commit, the account on the original line was replaced by the
accrual account. This could be problematic for hashed journals. Instead
of having 2 different behaviors for hashed/non hashed journals, we
decided to always create 2 journal entries, which is also more academic:
* We don't replace something on an entry that has been posted
* We don't end up with taxes on the accrual account
* Accountants are used to do it this way
closesodoo/odoo#42787
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
- Create a 12% tax, price included
- Create an invoice for a single product @ 52.50
The total is 52.51.
This happens be cause the tax is computed on a non-rounded base amount.
opw-2198712
closesodoo/odoo#48084
X-original-commit: f307c29160675583c1c40ccf0f4452c6a1461cbe
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.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
The use of such tags was not supported if no country was set on them (we need one to properly filter what to display in tax configuration). We just make it explicit by adding this constraint.
closesodoo/odoo#47813
X-original-commit: f76c2d92c58b2055bc906b32d47f192c615a46ed
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Active 'Round Globally'
- Create the tax:
Amount: 21 %
Tax Included
- Create the following invoice:
Line 1: qty 1.0, price 11.90
Line 2: qty 1.0, price 2.80
The Taxes amount should be 2.56 since we apply a 'Round per line' logic
in case of included taxes.
opw-2181486
closesodoo/odoo#47175
X-original-commit: a55bc67f0797f412c3bd82074c3f8f5d1497bce2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
qdp-odoo