- 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>
Go to Accounting / Reporting / Management / Invoices
Select Pivot view
Add "Total" measure
expand results adding "invoice #" and product
Total will be incorrect because it is summing up the value reported from
several lines of the query in which the total is taken as the invoice
total, so it will display total * # lines.
Using the price retrieved from the single lines fix the issue, but it
needs to be converted according to the currency rate of the invoice.
Moreover the test need to be modified because the amount_total variable
of the report should NOT be the move amount_total but the amount from
all the lines converted in company currency
opw-2187369
closesodoo/odoo#45050
X-original-commit: 1558bb2a62cf169e6b19a2aa4dd92fcd8ff1b25a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Task 2146469
Rework the name computation:
* It doesn't use ir.sequence anymore
* It is an editable computed field
* Add a renaming tool
This allows the user to tweak the sequences more easily than having to
get through the ir.sequence settings.
The sequence depends on a parameter of the journal: continuous, montly
and yearly restart of the sequence. Everytime a new period is started,
try to make a pattern form another period.
The incrementing is done by taking the previous name, ordered
lexicographically, splitting it by taking the digits at the end, adding
1 and re contstruct with the prefix.
** This means there could be cases where the prefix has a big importance
on the next number. For instance, if you have
INVOICE/2019/0001
INVOICE/2019/0002
and then rename the last one to INV/2019/0002, don't expect the next
number to be INV/2019/0003. It will be INVOICE/2019/0002 (again) because
the highest number was INVOICE/2019/0001.
You will then end up with
INVOICE/2019/0001
INV/2019/0002
INVOICE/2019/0002
closesodoo/odoo#41485
Related: odoo/enterprise#7189
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
If accounting entries have already been generated by this currency, we now forbid setting it a lesser number of decimal places (so, higher rounding factor). We also display a warning when increasing the number of decimal places, to make sure the user is aware of the impact it'll have.
closesodoo/odoo#42017
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Create a partner which is a company
- Add a contact
- Create an invoice for the contact, post it
Both the contact and the company are set as followers of the invoice.
Only the contact should be, there is no reason to make the company
follower too.
opw-2179084
closesodoo/odoo#44624
X-original-commit: daedd9eb402e5dd3c6a700a93ee58022266ec95b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
There is nothing left preventing to delete an account.move.line making
the related account.move unbalanced.
closesodoo/odoo#44341
--issue: 2185112
X-original-commit: 92364270d21cc4688471597f04fe25206b320a58
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
When having an invoice in foreign currency and a partial payment in
domestic currency (in a different date with a different exchange rate),
the computed amount due is incorrect. When computing the
amount_residual_currency the payment (in domestic currency) is converted
to the foreign currency using the exchange rate of the invoice date, and
not the one of the payment date (see 56d92213b8).
If the account.partial.reconcile line will have a currency_id and a
amount_currency the amount_residual_currency will not be converted but
simply added.
This behaviour was introduced with e130606602
and backported to version 11.0 with 3363d7235137f286458c734a1a0417beeb1f66bb.
In version 12.0 this behaviour was partially reverted in d3d2612061.
opw-2156001
closesodoo/odoo#44181
X-original-commit: 94d34e052f3757c21884fd5a57cc68ea8c51aafb
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Suppose a price_unit of 2300 with a 5.5% price-included tax applied on it.
The computed balance will be computed as follow: 2300.0 / 1.055 = 2180.0948 ~ 2180.09.
Since accounting / business fields are synchronized, the inverse computation will try to
recompute the price_unit based on the balance: 2180.09 * 1.055 = 2299.99495 ~ 2299.99.
--issue: 2168073
Task 2092079
Accounting firms that want to give access to their customers avoiding
mistakes and risks will love this profile that can't do anything
wrong... Maybe as well as companies auditors..?
closesodoo/odoo#39860
Related: odoo/enterprise#6576
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.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>
- 'partial' payment state corresponds to invoices whose payable/receivable move line has been partially reconciled with some other line.
- 'reversed' payment state corresponds to entries that have been cancelled by the creation of a single reverse entry (using the dedicated button on the form view). This state can be set on invoice as well as on regular entries.
=> To stay consistent with the naming conventions, this commit also renames invoice_payment_state field to payment_state, since it's no longer only applicable on invoices.
closesodoo/odoo#41723
Related: odoo/enterprise#7202
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Purpose
Fix multi-company access issues following the big changes that happened
(the 13.0). Make the usability better in order to avoid potential
multi-company issues for the user.
Specification
Check the related commits to see the different fixes that have been
made. For more information about the technical/functional considerations,
check the related task.
Taskid: 2088891
X-original-commit: 5c8df3a5e5f7960e5eab6439e0a32a06224ba826
Before the merge of account.invoice with account.move, a group of taxes was
expanded on journal items and not on invoice lines. Since both are now the
same thing, we only get the group of taxes when using the 'tax_ids' field.
To correctly handle this new behavior, we need to call 'flatten_taxes_hierarchy'
every time we use the 'tax_ids' field to get the children taxes instead of the
group of taxes itself.
[FIX] account: Wrong unit price with included tax and fiscal position
Steps to reproduce the bug:
Let's consider a sale included tax T1 of 10% and a sale excluded tax T2 of 0%
Let's consider a product P with T1 and a sale price of 110€
Let's consider a fiscal position FP that mappes T1 to T2
Let's consider a customer C with FP as fiscal position
Create a customer invoice for C
Add P on the first line and T1 is replaced by T2
Bug:
The unit price of P was still 110€ instead of 100€ because the included tax was not removed from the base
price of P.
Same behavior as in 11.0 and 12.0
opw:2150564
closes odoo/odoo#43100
Co-author: simongoffin (sig@odoo.com)
Forward-port-of: #42926
Forward-port-of: #42188
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
When an account of type receivable or payable is used as default debit
account or default credit account of a journal of type sale or
purchases, an error is raised.
Now, constraints are added to avoid this.
opw-2151924
closesodoo/odoo#42817
X-original-commit: 0c90eb50b352ee003d52ef927260d1b9310ec69f
Related: odoo/enterprise#7562
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, the corrected test crashed when the current
date was before the arbitrary dates of the test
because the wrong exchange rate was taken
After this commit, the test passes
closesodoo/odoo#42671
X-original-commit: 5867e9bf0cc745d7b1b3dcf76bc94567e859cff7
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When an invoice is duplicated, the `invoice_date` is not carried over.
If the field is not set, it will be set at posting at the current date.
closesodoo/odoo#42622
X-original-commit: 135d3db7b9b222be198e91235657bbef77d2f69b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.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>
- Create a misc. journal entry.
- Add a foreign currency on the line.
- Change the date.
=> The currency is erased because the onchange works only for invoices.
X-original-commit: e0bb4134512ec252b66ecfe91ce259d8cdcffedf
Initial issue solved by 3eb06a27da
We keep the test since it ensures that settings can be saved properly.
X-original-commit: 2c1b92f626edaf89c93c3bd96d656aa77c580c69
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>
Task 2046908
Instead of having all the fields duplicated with second_*, we have now a
o2m allowing us to
* have more than 2 lines
* reduce duplicated code
* fix bugs and add features at only one place
We also remove the computation of writeoff and suggestions from the
client side as some code was 4-upled before (twice in in client and
twice in server side). The logic is now only at one place.
closesodoo/odoo#38119
Related: odoo/enterprise#6324
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.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>
The trailing check on the fiscal year lock date is wrong and is
triggered whatever the values passed to 'write'.
closesodoo/odoo#41100
X-original-commit: 5b3486a434dbb0d9d1ed583e59f6b478b33e9745
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
In the Mexican Localisation (l10n_mx), there is a "custom" behavior
made when there is more than one payment term lines.
Before the account-pocalypse, the receivable lines having a balance equals
to zero was ignored.
This commit aims to restore this behavior and then, fix l10n_mx.
--issue: 2121973
X-original-commit: 6a4f9a2666b7414d208248da52862428c04bb4a6
Task 2092104
Accounts group Hierarchy should be automatically well done without to
have to specify the parent (based on the account group CODE)
Before, we had to set all the accounts in the correct groups manually
and it was cumbersome.
Now:
* No need to fulfill account group parent
* No need to fulfill account group id on account
We can still change the groups if there are exceptions; the groups are
only set at create and write time.
Task 2085023
* Add a field that replaces the context to get the ids of the
entries/invoices
* Remove move_id, we can use move_ids instead
* Add text to explain invioces/bills will create refunds
closesodoo/odoo#38857
Related: odoo/enterprise#6263
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Laurent Smet