account: Compacting the creation of Journal Lines for CABA base lines.
Main
-
Creation of Cash Basis (CABA) Journal Entries can lead to the creation
of a huge number of lines that are not quite useful and its creations
can lead to a lengthy process of creation of payment when several
invoices with a huge amount of invoice lines involved or to a lengthy
process of cancelation of payment because of reversion of the CABA, in
case of l10n_mx, many users have opted for using
l10n_mx_edi_avoid_reversal_entry, and then this causes a lengthy process
of deletions of CABA entries.
Justification
-
CABA Entry is divided into two parts when it is created
- Tax Part: The part that deals with the taxes themselves (this PR does
not mess with them).
- Base Part: The part of the base of the taxes (what this PR is all about)
So far the Base Part has been using a Brigde/Order account that does
not
have any financial use other than providing the source for computing
the
base of the amount of taxes due. In the financial statements, the
value
of the account used is always zero. So providing a huge amount of
details on this account has proved, in the wild, of no use.
Scenario
-
- Configure Tax based on payment.
- Configure the tax base account in the Tax.
- Have four invoices, each one with one hundred invoice lines, each line
is a different product or a different account. (4 invoices x 100 lines =
400 lines to be used as a tax base)
- Make three partial payments to each invoice. (3 payments x 4 invoices
= 12 payments)
Before this change
-
- Check the CABA entry created:
Chances are that each CABA Journal Entry will end up having:
-- 1 Entry line per tax collected.
-- 1 Entry line per tax to be collected.
-- 200 Entry lines for the base (100 lines in debit, 100 lines in credit)
That is a **whopping 2424 lines** for CABA entries where 2400 are
only
base lines.
And let us say that I have made a mistake on all the 12 payment (I am that dumb).
Reversal Method will clone your 2424 lines so now there are 2424
additional lines.
And remember I have to fix my payments and that creates again 2424
additional lines.
So **I end up with 2424 x 3 = 7272 lines.** This only for 3 invoices and
4 payment, for payments canceled and their corrections.
After this change
-
- Check the CABA entry created:
-- 1 Entry line per tax collected.
-- 1 Entry line per tax to be collected.
-- 2 Entry lines for the base, one debit, one credit.
Chances are that this could be increased but the algorithm tries only to
group by a set of keys.
So with the same steps, payments reversals and corrections, I could end
up with 12 payment x 4 lines x 3 steps = **144 lines down from 7272
lines.**
2 related fixes:
- When removing an asset line depreciation move, we have to pass it
first to draft, or we won't be able to remove it even with the
context.
- When removing a move, the check for removing the linked asset should
be only for purchase documents, not for "not sale" documents.
* [FIX] Do not hide Originator Tax
* [IMP] Add optional hide option to Originator Tax
* [FIX] Drop tax_ids field from Journal Item page, as it is already displayed.
- Change in journal the existing 'Lock date' by two dates, the same as in company.
- Add a wizard to allows a massive update of those dates for several journals at the same time.
The test failed on travis (not on a local install) because the
admin users if part of the Adviser group. Make sure we have the right
group and add a test for that feature too.
