A tax line affecting the base of subsequent taxes is a line having some values in 'tax_ids' & 'tag_ids'.
When creating a refund, tags was wrongly computed in this case.
closesodoo/odoo#74307
Issue: 2596368
X-original-commit: 49d1dbbb74ea97e4337fe1af3b8074dc9146143c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Explain the situation when a manual change has been done to the sequence
of `account.move`. This was needed because some user didn't realize that
they changed the sequence, and when they realized it, it had polluted
multiple numbers after that.
closesodoo/odoo#74326
X-original-commit: 56f7afb253da6560cddae121f5b6cdab3e3b1c6e
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Improve usability of payments. Allow selecting multiple Vendor Bills AND Refunds
and pay them all together in one single payment.
E.g. When running server action “Register Payment” for :
- one 100€ Vendor Bill
- one 50€ Vendor Bill
- one 80€ Refund
Previous result = one 150€ outgoing payment + one 80€ incoming payment
New result = one 70€ outgoing payment
closesodoo/odoo#69578
Task: 2475598
Related: odoo/enterprise#19902
Signed-off-by: William André (wan) <wan@odoo.com>
In the first days of the month, many of the previous month's invoices
could still to be posted since the lock date is not yet set to the last
day of the previous month. To avoid the user having to modify the
default accounting date on each such bill, detect whether the conditions
allow the invoice to be posted on the very last day of the oldest
possible month, and then adapt the accounting date to the last day of
that month.
task-2575560
closesodoo/odoo#73701
X-original-commit: 2c5c1a4478505688f35e47ca20e7977b134d0fdb
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
For data quality purposes and bug prevention, when I reverse an entry,
the reversal should always be postable on a journal having the same type
as the initial Journal Entry's journal.
closesodoo/odoo#72431
Task: 2497529
Related: odoo/enterprise#19543
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
To improve the payment method system, proceed to a few changes
such as changing the view a bit, making sure payment acquirers are not
linked to a journal by default and that only the manual payment method
type can be used multiple times in a single journal.
Task id #2573145closesodoo/odoo#73596
X-original-commit: 9122b367baea10e59b66e45bf7c458a6f1e82efb
Related: odoo/enterprise#19623
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
PURPOSE
Align default sequence numbering on customer's expectation per journal.
Because of some feedbacks received, we acknowledge that most users will
want an annual sequence on sales documents and a monthly sequence for
the rest.
SPECIFICATION
By default, on customer invoices/credit notes (the default sequence
should be annual.)
We don't want an option and therefore, we make a decision ; user can
change it by resequencing if he doesn't like it.
task-2591145
closesodoo/odoo#73278
Related: odoo/enterprise#19565
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
To reproduce:
- Create a cash basis tax
- Make an invoice with two lines, a positive and a negative one (the positive having a higher value), both using this tax
- Post the invoice and register a payment for it
===> It crashes when registering the payment. The SQL constraint ensuring debit/credit consistency fails when creating the cash basis entry.
This is because we were not grouping debit and credit values together on the lines sharing the same taxes; we were summing them separately. The cash basis entry then received line values with both credit and debit set, which is forbidden by the SQL constraint. We now compute the balance first, and set either debit or credit depending on its sign.
closesodoo/odoo#72383
X-original-commit: 896496d84413e7bb5e5df582e2b67eae2583671b
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This commit fixes the case when the reconciliation never ends due to an infinite loop.
This happens when we attempt to reconcile two journal items having differents foreign currencies but an amount_residual = 0.0.
In that case, partials are created everytime with zero amount, zero debit_amount_currency and zero credit_amount_currency.
We don't need to handle such reconciliation because exchange difference journal items are always created using the same foreign currency as the originator line.
The way the reconciliation is made for reversal moves is also edited by this commit to avoid reconciling lines on the same moves but with different currencies.
closesodoo/odoo#72266
X-original-commit: 1231d54b8c2084db6ffb9551af7ed4ee9e31a95a
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Consider the following example:
1) Create tax ONE, 10%, include_base_amount=True
2) Create tax TWO, 20%, is_base_affected=False
Create an invoice with just one line of 100€, with taxes ONE and TWO (in this order).
The journal entry then contains:
- The payable/receivable line => 130
- The base line => 100
- The tax line for ONE => 10
- The tax line for TWO => 20
The bug this commit fixes concerns the tax_ids set on tax lines. In our example, none should be set, since tax TWO is not affected by ONE. But tax line for ONE actually had tax_ids=TWO, hence impacting TWO's base. This was wrong; the base for TWO is 100, not 110.
closesodoo/odoo#72063
X-original-commit: ff2d1728c835e7d43638502d69245291d0fa3c59
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
The accounting date must be today by default and changing the bill date
must not affect that.
Kind of followup after this change of behavior fcaa54939e9a4f0dd5e47cd0ccffe7aa24bd451c
task-2550985
closesodoo/odoo#71977
X-original-commit: c63af09774414a004ef34644b4f38b4fdb1d12bd
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Open Accounting>Reporting>Invoices
Add measure 'Average Price'
The reported amount will be wrong, as it will not consider the quantity,
making an average of the price subtotal
opw-2522621
closesodoo/odoo#71862
X-original-commit: 978012b38abb941c88fe85f1befa2ac659545915
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Users may want to be able to have transactions coming from multiple
payment acquirers to be registered in the same journal.
This will allows that.
Task id #2414749closesodoo/odoo#67331
Related: odoo/upgrade#2500
Related: odoo/enterprise#17258
Signed-off-by: William André (wan) <wan@odoo.com>
- Enable cash basis (Accounting>Settings>Taxes)
- Enable analytic accounting (Accounting>Settings>Analytics)
- Have a sale tax:
- Based on payment (Account 10100 Current Assets)
- Included in Analytic Cost
- Create a [DEMO] product with such tax
- Create an invoice with 2 lines:
- One line with product DEMO and whatever analytic account
- One line with product DEMO but no analytic account
-Confirm and receive payment
CABA entry will consider only 1 tax line, because the
2 entries are equal beside the analytic account which is not considered
in the grouping keys
opw-2507417
closesodoo/odoo#71556
X-original-commit: 2a8f777c04bdbdce77dc44d92e099612f158cbef
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Original issue:
Create a payment like follow:
Payment type: receive money
Partner type: customer
Destination account: whatever receivable
Amount: define an amount (i.e. 90.00)
On Save, open the draft jounral entry created.
Lower the liquidity or counterpart amount and add a writeoff
Go back to the payment, change the amount and save.
The journal entry writeoff will swap from debit to credit at every
change made to the amount. This occur also when changing currency on the
payment
opw-2475223
Otherwise, this fix is not covering all cases:
inbound with write-off in debit
inbound with write-off in credit
outbound with write-off in debit
outbound with write-off in credit
closesodoo/odoo#70903
X-original-commit: 01b9bff35e85fafb1a50bb0819123d186acf4925
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Since the payment refactoring, the structured reference of a payment is stored in its ref field, not payment_reference like for invoices. This caused payments never to be matched with highest priorities, as payment_reference_flag was always false, and only communication_flag could match.
To reproduce:
- Have a reconcile model with match_total_amount=False.
- Create a statement line with communication a1b2c3 for 1000
- Create 3 payments:
> 500, with memo a1b2c3
> 500, with memo a1b2c3 (so, the same one)
> 500, with memo d1e2f3
- Open the reconciliation widget for your statement line
===> The 3 payments are matched, while only the two first ones should have been, as they were exact matches for the communication, and should hence have received higher priority.
closesodoo/odoo#70394
X-original-commit: b5800c9d2088df2bb9c4fbe0fed91c7ef24299c5
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
- Create an invoice with an empty fiscal position
- Create a line with a product having 100.0 as sale price and 21.0% price-included tax
=> price_unit equals 99.99
This is because 100 / 1.21 ~= 82.64 but 82.64 * 1.21 ~= 99.99 != 100.0.
The bug only appears when managing a fiscal position because the code is trying to adapt the product price_unit to the newly computed taxes.
closesodoo/odoo#70276
X-original-commit: 3470a3c94e06d92afcd8a8129f80e4dfea14efe4
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When the same sequence is used in different journals (i.e. BNK1 in two
different companies), a clash might happen in the grouping optimization
of the `_compute_name`
closesodoo/odoo#70152
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, such configuration wasn't allowed.
However, in some countries, this is mandatory, when dealing with eco-tax for example:
Suppose t1, t2 being taxes where:
- t1 is include_base_amount, price_excluded, fixed tax of 10 (eco-tax)
- t2 is include_base_amount, price_included, percent of 21%
The computation on 1210 should be:
price_excluded: 1210 / 1.21 = 1000
price_included: (1000 + 10) * 1.21 = 1222.1
closesodoo/odoo#69449
X-original-commit: 2bb9e68b546db191b2a88b787a865548d8107bcd
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When an auto-validating reconciliation model is defined for matching
bank statement lines to invoices, it was possible to get a traceback
when the bank statement lines were in a certain order and matched in a
certain way.
In particular, if the first bank statement line is priority 3
(communication_flag True) and the amount is an exact match with the
invoice, it will be instantly reconciled. If there's a second line
that's a priority 5 match, it crashed because _filter_candidates didn't
take into account that candidates_by_priority could be empty if the
candidates were already reconciled.
Instead we just return an empty list of candidates and priorities when
this happens.
closesodoo/odoo#69331
Ticket: 2507189
X-original-commit: e9538d9cee092e034b85187a2eae857349f42ce7
Signed-off-by: William André (wan) <wan@odoo.com>
Beforehand, users could configure an account as non reconcilable
even when it was configured as a payment credit or debit account
in a journal. This prevented journal items to be reconciled
Now, when a user tries to set an account as non reconcilable,
we check if there is no journal with a payment credit or debit account
set to this particular account. If there is at least one journal,
then we display an error message stating the journals names and ids
that the user would have to modify before changing the account
configuration.
closesodoo/odoo#69317
X-original-commit: 87c207f3a408abb93d9b8378ef4aa1744935d86d
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Julien CHEVREAU <Julien-CHEVREAU@users.noreply.github.com>
Beforehand, if two users independently opened a draft
invoice on their respective sessions, then both of them
clicked on the "Post" button, then the invoice was
posted twice.
On a more general aspect, the view currently "prevents" users
from posting moves several times, but technically speaking,
nothing stops users from posting moves several times.
Now, after checking that the user indeed has the right to post
a move, the next check is about verifying that the move is
not already posted.
opw-2479201
closesodoo/odoo#69178
X-original-commit: b7db7db283d7b9d167201b791e6282b022d59c40
Related: odoo/enterprise#17658
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Julien CHEVREAU <Julien-CHEVREAU@users.noreply.github.com>
- On accounting settings, activate 'Cash Basis';
- Select a 'Base Tax Received Account';
- Modify a purchase taxes, and set the 'Tax Due' to 'Based on Payment';
- Set a 'Cash Basis Transition Account';
- Be sure that the previously selected account allows reconciliation;
- Create a Vendors Bills, using the modified purchase tax;
- Register a payment;
- Reset to draft the vendors bill.
Before this commit, an error was raised : 'Record does not exist or has
been deleted.'
This occurs because when trying to unlink the partial reconcile, it will
first reverse and unlink the tax cash basis partial reconcile moves.
After when trying to access the partial reconcile to unlink the error is
raised because one is already unlink.
Now, the vendors bill is correctly reset to draft.
opw-2477526
closesodoo/odoo#68754
X-original-commit: 72c29b105bdb4da5b306cd3b48a1683c1bf3e620
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Laurent Smet <las@odoo.com>
The Payment form view is simplified for a much less cluttered screen.
A paired internal payment is now created when an internal transfer is posted.
Task: 2403336
Such fiscal positions define an alternate VAT for a specific region. When foreign_vat is set, a country must be set on the fiscal position; it'll be used to know for which tax report the fiscal position must be available as an alternate VAT (in the tax report; see enterprise branch). Note that it is possible to defined several foreign VATs for the same country, as long as they belong to different states within that country.
Note that this new feature is only for FOREIGN stuff; so, when you have to submit a tax report in different regions than yours. For example if you have a Belgian accounting, have French customers, and have a French VAT in addition to your Belgian VAT, to submit a tax report in France. For domestic operations, simply use your the vat field of your company, just like before.
[IMP] account: add country_id on taxes and filter them on invoices
The invoices now compute the country from which they should accept the taxes: it's either the one defined by fiscal_position_id.country_id (if fiscal_position_id is a foreign VAT fiscal position, i.e. it defines a foreign_vat value), or the company's account_fiscal_country_id.
Taxes from other countries are filtered from the view; we don't want them to be available there. There is also a constraint ensuring that. Same goes for tax repartition lines and tags from other countries.
We don't want to mix taxes, tags and foreign VAT fiscal positions from different countries, as it would break the tax report in enterprise. Doing this ensures the tax report can efficiently discriminate the move lines between the different regions whose report they have to appear in.
[IMP] account: add country_id to account.chart.template
This is done so that the taxes are created in the right country, and the fiscal country is initialized in a consistent way when instantiating the CoA on the company.
[IMP] account: print foreign VAT on invoice instead of company VAT if one is defined
[IMP] web: allow forcing company vat on document templates
This is done to allow the use of foreign vat fiscal position on invoices: in that case, we don't want to use the company VAT, but the value of fiscal_position_id.foreign_vat. So, when such a value exists, the invoice simply set the force_vat variable to the right value.
[IMP] base_vat: also validate VAT of foreign VAT fiscal positions
We generalize the code formerly only done for res.partner so that the foreign_vat field of account.fiscal.position can be checked in the same way.
We don't check anymore that a move has been posted before in order to allow its deletion. Instead, we look at its sequence: if it's set and is not at the end of the sequence chain it belongs to, we know removing the move will create a gap, whatever the move state, so we forbid it.
If the user really wants to remove the move anyway, it is possible, by manually emptying the name of the move to delete. This way, he won't have any sequence anymore, and will be deletable. Users should however, rather rely on move cancellations and reversals, just for the sake of a cleaner accounting.
We also inject a context key to ignore prediction in case account_predictive_bills (enterprise) is installed. This way, having the same label on invoice lines generated by the helper will still behave in the same way, even if enterprise is installed.
closesodoo/odoo#67998
X-original-commit: b6c37754532ae6a7cc1f68a345fde6258abdc893
Related: odoo/enterprise#17125
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
The current behavior was to set the label as memo in the payment register wizard.
However, this is to restrictive when a vendor bill hasn't any payment reference but a bill reference.
In that case, the user is expecting to have the bill 'ref' in the payment 'memo'.
Since the matching rules in the reconciliation widget are matching line.name, then line.move_id.ref and then line.move_id.name, the same logic is applied here to construct the payment 'memo'.
closesodoo/odoo#68004
Opw: 2440389
X-original-commit: 92ceb86d58f4d78c8a4256f29d101d3730517b93
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Allow creating a journal entry in the past after having changed the
sequence number reset on newer sequences.
opw-2445559
closesodoo/odoo#67963
X-original-commit: 26a43f23ec2b2490aec0731e25568703729581f0
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Fine tuning of f816c326f348ff78a982f91a736cc005d3e0cd31
We should not look at the `seq` when grouping again.
opw-2472061
closesodoo/odoo#67788
X-original-commit: fd36a69a6ed1484d6b7570dae3ff63d3f12ad035
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
In India, we need to configure taxes like this:
- 6% applied on base amount
- 6% applied on base amount
- 1% applied on 1.12 * base amount
If both 6% taxes are affected the base of subsequent taxes, it gives the following result:
- 6% applied on base amount
- 6% applied on 1.06 * base amount
- 1% applied on 1.06 * 1.06 * base amount
Thanks to the new 'is_base_affected' field set on the second tax, it gives the expected results.
closesodoo/odoo#66134
Task: 2343958
Related: odoo/upgrade#2254
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The test is running in sudo mode, so we need to specify the company in
the search.
Also do not load the demo data when installing as we would do the work
twice for most localization.
closesodoo/odoo#67235
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Tests are crashing when the number of months between the data date and today is higher than 18 months due to the 'past_months_limit' field on account.reconcile.model.
closesodoo/odoo#67051
X-original-commit: fd2c14374598b7009b70196ccc6ac3607b30245a
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
A move with type 'entry' cannot be posted in a 'sales' journal. It should be
the default 'miscellaneous' journal instead.
closesodoo/odoo#66851
X-original-commit: 1c45685922b5561b8bce1c91b158184837391089
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
When reconciling a statement line from the bank reconciliation widget, the journal entry of the statement line is already posted and then, the analytic lines was never created.
This commit fixes the issue by refreshing the analytic lines at the end of the statement line's reconciliation.
closesodoo/odoo#66850
Opw: 2466236
X-original-commit: 2c38dc6e34ebb8d4590adead74ebf02fee40d66a
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Suppose an invoice of 1200USD = 3600EUR reconciled with a payment 1800USD = 3600EUR.
The generated exchange difference journal entry is:
600USD = 0EUR because 1800 - 1200 - 600 = 0 and 3600 - 3600 = 0
=> Everything is reconciled and all residual amounts are 0.
Remove the reconciliation. The exchange difference entry is reversed in other to cancel it.
Because the current exchange difference entry contains a line of 600USD, the reversal is creating a line of -600USD.
Before this commit:
Because both lines were sharing the same foreign currency (EUR) but have an amount_residual_currency of 0, no partial was created and then, a new exchange difference was generated in order to fix the amount_residual of 600 in USD.
After this commit:
A partial is created to handle the residual amount in USD even the residual amount in foreign currency is already zero.
Note: this issue is also there when the reconciliation is made using the company's currency with different foreign currencies.
In that case, amount_residual is zero but not amount_residual_currency.
closesodoo/odoo#66825
Opw: 2450699
X-original-commit: 07d5735de0e1b3080676ab26e872e55120fa2628
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Issue
- Install "Accounting" module
- Create a new bill :
- Set vendor
- Set no payment reference
- Set a bill reference
- Add products to bill
- Confirm and click on Register Payment
Memo field has no value.
Cause
The memo field is based on lines name.
Lines name is computed in `_onchange_payment_reference`
and depends only on payment_referecence.
Solution
If no `payment_reference`, fallback on `ref` to set line name.
opw-2440389
closesodoo/odoo#66491
Co-author: nboulif <bon@odoo.com>
X-original-commit: 7a7dc212af7279544cffba362bce7daa4fc00865
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Reproduce:
* Create one move in a journal
* Create another move in another journal but in the same year
* Both journals should have a yearly sequence reset
* Post both moves at the same time
Bug:
They both are using the same sequence.
Expected:
Both should be using their own sequence.
closesodoo/odoo#66383
X-original-commit: f816c326f348ff78a982f91a736cc005d3e0cd31
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Task 2124952
Extract all the demo data from `l10n_generic_coa` to a new way of
generating the demo data for accounting modules.
Because the data needs to be created multiple times, and right after the
chart template instanciation, it cannot be done the usual way. Instead,
we use python generators to declare the data. It allows us to reference
data that was not created yet at the start of the creation of the demo.
An xml_id is given, prefixed with the id of the company it is created
for (just like the instanciation of the chart template)
To find the correct accounts, a helper method has been added to
`account.account`. It will look for an account with the correct xml_id
(which is the one of the l10n_generic_coa, that we have to put on the
other l10n modules too, in the future). If it didn't find the xml_id, it
will look for an account with the correct type. If it still didn't find
one, just take any account.
Laurent Smet