TLDR:
* invoices are implemented using computed methods instead of onchange
* the synchronization only happens when switching tabs in the Form view
to improve perfs.
_______________________________________________________________________
The whole engine of the synchronization of Invoices to the Journal
Entries has been refactored
* by using computed fields instead of onchange functions
* by synchronizing only from invoice to journal entry in `create` and
`write`
* by saving when switching tabs on the Invoice form, to synchronize
before showing the values
This comes with numerous advantages:
* no need to call the onchange methods manually
* no need to use the Form emulator to build invoices (i.e. EDI, OCR,
intercompany, ...)
* the performance for invoices with many lines improves drastically, going
from 2 minutes to 4 seconds to create an invoice with 500 lines
* the model is more declarative, we can now see how the values are computed
instead of having the values being copied from various places.
* remove the hack in `onchange` that disabled the recursivity of it,
which was unexpected and needed to be managed manually in all the
onchange methods
This means that:
* Some fields need to be exclusively computed on journal entries values
or invoice values, more specifically the Tax Summary widget.
It is now
- computed from entry lines, when opening the view
- computed from invoice lines when changing those, because the tax lines
will need to be recomputed anyways, erasing previously set values
- set with an inverse function when saving; after the sync has been done
* Some possible operations previously possible have been dropped.
(i.e. look at the removed test test_in_invoice_line_onchange_accounting_fields_1)
This is because such a behavior was undefined (how is changing the balance going
to affect the unit price? How is the amount currency going to affect it?)
_______________________________________________________________________
Implementation Details
----------------------
The "dynamic lines", meaning the payment terms and the tax lines are now
only created in the `create` and `write` functions.
In order to reduce code duplication, it has been implemented using
context managers used in both `account.move` and `account.move.line`
These context managers help comparing the values before/after, acting
like a local `onchange`, but getting benefit from the dirty flags from
the `compute` dependences.
This is relying on computed fields on the move (`needed_terms`) and on
the lines (`compute_all_tax`) which contain the values needed for the
related move.
Depending on the needed values and the existing values (`term_key` and
`tax_key`, respectively) the context manager will determine what needs
to be created/updated/deleted.
Some related changes are to produce a `dict` instead of a `str` for the
`tax_totals` (previously `tax_totals_json`) fields, by simplicity to
reduce the complexity of IO, and simplicity of debugging, because the
logic of the field needed to change (cannot be computed at the same time
anymore since it needed the lines to be synced)
By simplicity, and also because it makes more sense, some boolean fields
have been merged into `display_type`:
* `is_rounding_line`
* `exclude_from_invoice_tab`
* `is_anglo_saxon_line`
The `price_unit`, `quantity` and other "invoice fields" are now not set
anymore on lines that are not product lines since it didn't make any
sense to have it.
Performances
------------
You have to keep in mind that a simple `create` didn't compute a lot of
fields, for instance not taxes were set, no payment terms,...
Now it does.
```python
import random
from timeit import timeit
from odoo import Command
domain = [('company_id', 'in', (False, self.env.company.id))]
products = self.env['product.product'].search(domain).ids
partners = self.env['res.partner'].search(domain).ids
taxes = self.env['account.tax'].search(domain).ids
def create(nmove, nline):
self.env['account.move'].create([
{
'move_type': 'out_invoice',
'partner_id': random.choice(partners),
'invoice_line_ids': [
Command.create({
'name': f'line{i}',
'product_id': random.choice(products),
'tax_ids': [Command.set([random.choice(taxes)])],
})
for i in range(nline)
]
}
for j in range(nmove)
])
# After | Before
print(timeit("create(1, 1)", globals=globals(), number=1)) # 0.11 | 0.09
print(timeit("create(100, 1)", globals=globals(), number=1)) # 2.76 | 2.50
print(timeit("create(500, 1)", globals=globals(), number=1)) # 14.56 | 12.34
print(timeit("create(1, 100)", globals=globals(), number=1)) # 1.03 | 5.52
print(timeit("create(1, 500)", globals=globals(), number=1)) # 3.99 | 125.02
print(timeit("create(50, 50)", globals=globals(), number=1)) # 19.44 | 79.55
```
Another metric that can be used is running the test suite with
`--test-tags=/account` (only `account` installed)
* before: 404s, 267127 queries (366 tests)
* after: 318s, 232125 queries (362 tests)
Why this commit title?
----------------------
Someone told me that this was the perfect way of naming your commits.
c04065abd8
task-2711317
closesodoo/odoo#96134
Related: odoo/upgrade#3715
Related: odoo/enterprise#29758
Signed-off-by: Laurent Smet <las@odoo.com>
By trying to avoid concurrency issues while assigning the sequence [1],
we are locking too many operations even when not in the process of
assigning a new number.
* when computing `highest_name`, we don't need to lock as this is mostly
an information on the form that can possibly change anyway while the
form view is open (without any lock anymore)
* when computing the accounting date, we don't need to lock, the only
information we want is the format of the sequence (yearly, monthly, no
reset), which is not likely to change on a same journal.
* when changing the `journal_id`, it is only a helper for encoding, if
there is a concurrency error it will be shown during the post anyways.
Also same argument as for `highest_name`
[1] https://github.com/odoo/odoo/commit/ba6ee0b75d66d6f22a592b1b6a7c5158461bec41closesodoo/odoo#95480
X-original-commit: 809557cdd02fe6581ed573b58158a927aabe0694
Related: odoo/enterprise#29212
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Before this change, we bringed to the user the posibility to select the option “Unified Book” (boolean) on journals with type “Sales” and Pre-printed Invoice “AFIP POS System”. This allowed all documents with the same letter document to use the same sequence, and it does not matter if they are invoices, credit notes or debit notes for example.
Now that functionality is deleted and all documents will have their own sequence regardless of the letter document of each receipt.
closesodoo/odoo#88129
Signed-off-by: Josse Colpaert <jco@odoo.com>
When getting l10n_ar/l10n_cl starting_squence check with the proper
company (self.company_id) and not self.env.company_id
We do not put a journal_id anymore as it should take the correct one
automatically in v15.
Original commit d6f4fee58edf103c63836ac488be240961fd671a
closesodoo/odoo#87219
X-original-commit: f2f76dfa195226b7604076830412706447c168f2
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this change, we have the errors that documents generated on
pre-printed sales journals mark as unified book were wrongly
named using the wrong doc prefix code.
This was visible thanks to the demo data were we notices that the credit
notes were having FA- doc prefix instead of NC-
This was because we are reusing the shared sequence directly, now we
check and fix the doc prefix for those cases and all documents generated
on shared sequences are properly named.
closesodoo/odoo#86612
X-original-commit: df5bfd22c20d3a3bd72b04acbdae63657e025ce3
Signed-off-by: Josse Colpaert <jco@odoo.com>
Unify taxes computation between 'account', 'sale' and 'purchase' including:
- computation of price_subtotal/price_total.
- computation of business models total (using the json field)
closesodoo/odoo#80231
Task: 2654784
Related: odoo/enterprise#25620
Signed-off-by: Olivier Colson <oco@odoo.com>
We have a bug when we were computing the invoice rate that is used to
report to AFIP. The rate we were setting was an old rate that references
the day that the invoice was created and not the rate of the day where
the invoice was validated. This was happening because the
l10n_ar_currency_rate field that stores this value was computed before
posting the invoice. At that time the date field store the value of the
date where the invoice was created and had not been updated yet with the
accounting date.
Moving the l10n_ar_currency_rate field calculation after the invoice
post solves the problem and now the l10n_ar_currency_rate has the rate
of the accounting date.
Part-of: odoo/odoo#84470
Original commit: aac1165655d31ba3bca4b105e0c905534e91df93
closesodoo/odoo#87163
X-original-commit: ac57ac559d973a1c4c2050fa514668d20bd610f0
Signed-off-by: Josse Colpaert <jco@odoo.com>
Currently all latam localizations except Chile use country_id in _localization_use_documents().
account_fiscal_country_id should be used instead in all modules.
closesodoo/odoo#84756
Task: 2761248
X-original-commit: cf61089d9480d7450d2916911b0859cd5f6efcce
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Tastemirova Aliya (alta) <alta@odoo.com>
The currency rate could be different if the invoice date is different that the accounting date
Steps to reproduce:
1- Install l10n_ar
2- Create two different currency rate for foreign currency (i.e: Dollar) with also different Date
3- Create an invoice setting the currency as foreign currency (i.e: Dollar)
Current behavior before PR:
In page "Journal Items" could see that each account line use the currency rate defined by the accounting date,
however the currency rate filed (which is not visible) is defined by the invoice date.
Desired behavior after PR is merged:
Use always the accounting date to set the currency rate
+ CLA signing Augusto Weiss
closesodoo/odoo#83689
X-original-commit: 21692f28fd1db7097e1d4c23ce7dcbaa76936449
Signed-off-by: Josse Colpaert <jco@odoo.com>
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
E documents cannot be selected for invoices and bills which is a problem for companies in Tierra del Fuego, a fiscal exception of Argentina
Steps to reproduce:
1. Install the l10n_ar module
2. Switch to the company '(AR) Responsable Inscripto'
3. Open the Invoicing app and go to Vendors->Bills
4. Create a new Bill and select '(AR) Responsable Inscripto' as vendor
5. The document type '(19) Facturas de exportacion' is not available
Solution:
Add 'E' as journal letter for AFIP responsibility type 'IVA Responsable Inscripto'
OPW-2713805
closesodoo/odoo#83119
X-original-commit: 27edc28a2c19fad80053e668a8c72e7a629e4c1a
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Prior to this commit the line amounts on the invoice report where including the VAT always. With this change we only include VAT if invoice needs to include it (_l10n_ar_include_vat)
closesodoo/odoo#82740
X-original-commit: 47996fdd4e8c79f876d669f73b18c6046a83c95e
Signed-off-by: Josse Colpaert <jco@odoo.com>
Adapt the module to calculate removed fields from latam localization
X-original-commit: c9536ab129c96582a784efe6a5bce133cad0d650
Part-of: odoo/odoo#78296
Co-authored-by: Juan Jose Scarafia <jjs@adhoc.com.ar>
In the method _get_vat(), used to inform AFIP about the vat taxes of an
invoice, we were assuming that in the journal items of the invoices
there is always one line per tax group, but if the user enables the
option "Include in Analytic Cost" of the tax, then it could create more
than one line per tax so it will return an error if you try to validate
the invoice in AFIP or upload the vat book.
closesodoo/odoo#77526
X-original-commit: 67f5f0e86f0170f6066579749895e7d1e68d664c
Signed-off-by: Josse Colpaert <jco@openerp.com>
If an invoice is posted, sended back to draft and the rate was change on res.currency, we preserve the value already existing on l10n_ar_currency_rate
closesodoo/odoo#77388
X-original-commit: 820df9eef856d841863306eab1e26d0437a408b0
Signed-off-by: Josse Colpaert <jco@openerp.com>
Be able to create letter A documents to monotributista AFIP
responsibility types.
closesodoo/odoo#72667
X-original-commit: b204f7d1b0bcaf3984600d94395377c97facf168
Signed-off-by: William André (wan) <wan@odoo.com>
Add mapping rules to enable the electronic invoicing of document types
"CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" (60) and
"CUENTAS DE VENTA Y LIQUIDO PRODUCTO B" (61).
closesodoo/odoo#72619
X-original-commit: 9fb221459e1137c0622c14a57ec408b3b5f65fe6
Signed-off-by: William André (wan) <wan@odoo.com>
If a partner has a not handled responsibility type return an empty list
as possibles document types instead of raising an error.
closesodoo/odoo#69010
X-original-commit: abcba544043b08de4cffcf5affd12b08afec188f
Signed-off-by: Josse Colpaert <jco@openerp.com>
- Add a new responsibility type "IVA No Alcanzado"
- Update the partner "AFIP" with that responsibility
X-original-commit: e3e20fdccc2ad7bf0015d4c0a67c7ab803a97bd8
Before, account_fiscal_country_id was only use for tax operations; and country_id was used for all the other accounting stuff. Now, with the new ability to use foreign tax reports (with foreign VAT fiscal positions), we can generalize the fiscal country, sot that it is the one that needs to be used for the whole accounting. Since foreign tax reports were not supported before, account_fiscal_country_id is already set on existing database as the country for the "main" accounting, so the impact of this change is small.
closesodoo/odoo#68349
Related: odoo/upgrade#2322
Related: odoo/enterprise#17299
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Since AFIP requires to keep the original amounts in the txt files
for the digital VAT Book, we deprecate the option
'company_currency = True' in the methods used to prepare the data.
closesodoo/odoo#67927
Signed-off-by: Josse Colpaert <jco@openerp.com>
- install e-commerce and l10n_ar;
- as a Public user open a product on the shop.
Before this commit, an 403 error was raised.
Now, the public user can navigate through the products.
opw-2462477
closesodoo/odoo#66839
X-original-commit: 9a047c6a2085eab23865d3d649940f1e71c9234b
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
AFIP give us new resolution 4291 that request to print QR code in
printed version of electronic invoices. For that we:
1) update the xml report footer style
2) add generic method to sanitze the identification number we are
sending, the sanitize method is added here in order to be re used for
other functionalities across electronic invoice and reports. If we are
not able to sanitize the number then we show an error to the user
3) update translations to add new raise message translated term
NOTE: Fix pylint errors: This ones pop up when running this PR "Check Style'
in runbot
closesodoo/odoo#65034
Related: odoo/enterprise#15949
Signed-off-by: Josse Colpaert <jco@openerp.com>
AFIP currency rates goes up to 6 digits.
When invoicing exportation of services, AFIP requires to invoice on the exactly same rate. Without this change it was not possible for some currencies with 6 digits as CHF one.
The change takes effect without needing of updating module
closesodoo/odoo#63156
X-original-commit: 150493ca3fff8b44cf890205990dbd72cebdcb36
Signed-off-by: Josse Colpaert <jco@openerp.com>
Ensure the code works fine even if countries are deleted.
Also consider "re"-created countries after deletion, by only considering
the country code, not the data reference.
This should reduce support requests related to deleted countries, and
ease the resolution of such problems by the users themselves.
TASK ID - 2368842
closesodoo/odoo#60558
X-original-commit: 037012bc4e2935eb00a7f353529bb7ec55066733
Related: odoo/enterprise#14347
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The problem here is before this changes, the fiscal position only take into account if them has "auto_apply" True, and for the cases that the partner has their property fiscal position configurate for a company this is not taking into account.
After this changes we evaluate for the property fiscal position for the partner and then if non result we seek a fiscal position with the auto apply and the responsability of afip.
So this the same as the original method do.
closesodoo/odoo#59875
X-original-commit: 5ddcad3cb1d6063b7be89e4f0bd35b89885f746b
Signed-off-by: Josse Colpaert <jco@openerp.com>
stdout:
stderr:
closesodoo/odoo#58605
Error: could not apply 2b65a7c1112... [IMP] l10n_ar: Accounting Tour adaptation
Hint: after resolving the conflicts, mark the corrected paths
Hint: with 'git add <paths>' or 'git rm <paths>'
Hint: and commit the result with 'git commit'
Signed-off-by: Josse Colpaert <jco@openerp.com>
The method get_fiscal_position was missing the @api.model decorator
closesodoo/odoo#58665
X-original-commit: 7cad8db251b62972b3a0ea8ca970014cd0f1b5c1
Signed-off-by: Josse Colpaert <jco@openerp.com>
If a document type don't have AFIP code, like "FACTURAS Y COMPROBANTES
DEL EXTERIOR" or "NOTAS DE CREDITO Y REEMBOLSOS DEL EXTERIOR",
we don't have to validate the document number
closesodoo/odoo#58043
X-original-commit: 33cf9fdc0bf90a7246f3f67ada274e7a5519ee6b
Signed-off-by: Josse Colpaert <jco@openerp.com>
Port foward from 13.0 branch. Also update the _get_name_invoice_report()
method to match the one in account module.
Also update the name of payment field that has been change in master version
* o.invoice_payment_ref is now o.payment_reference
This method will be change to generic and to be use for both
l10n_ar_edi and l10n_ar_reports modules
fw-port of 50882
closesodoo/odoo#55687
Related: odoo/enterprise#12329
Signed-off-by: Josse Colpaert <jco@openerp.com>
Add an easy way to not post the entries in the future when calling
post() on it, but rather set it to be auto-posted at accounting date.
This is useful when we are creating a lot of entries in batch and some
might be in the future, some in the past, and we don't want to separate
that in two batch every time. (asset, accrual, transfer,... )
Only compute l10n_ar_vat when this one is defined, if not then the field
should not be computed.
closesodoo/odoo#55246
X-original-commit: 4e2de8c858c2d55b227b8a2fd3f8226f9da91a9d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
_("Foo %s", bar)
to progressively migrate the code to the new syntax.
A few calls were not technically incorrect but still detected by the
linter.
_("Foo" +
"Bar")
has been converted to
_("Foo"
"Bar")
as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).
closesodoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Do not construct a message by putting together translatable bits, it
makes it hard to translate (out of context) and may not work for some
languages constructing the sentences differently.
Do not try to save bits, be explict.
Clarify constructions for long oneliners.
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Before this change the constraint that check afip configurations has an ensure_one() that was throwing an error when we try to change journals in batch. Now the constraint support mutilple records at once and return the ValidationError message show information of the journal's which constraint aplies.
Also, we remove the print of the list of the invoices in the ValidationError message because this ones could be a really long list and it is not necessary, only knowing the journal is enough.
closesodoo/odoo#52914
X-original-commit: 710bb9f161da4718024c4454ce14a7dbc2d24c93
Signed-off-by: Josse Colpaert <jco@openerp.com>
william-andre