Adds new account to withhold vat tax, and new vat tax
Enables document type 46
Allow electronic docs in purchase journals
[FIX] l10n_latam_invoice_document Consider doc type 46 as a vendor document
More information -> https://www.sii.cl/preguntas_frecuentes/catastro/001_012_3665.htm
[RM] l10n_cl: remove _filter_taxes_included method
closesodoo/odoo#79479
X-original-commit: 0c34fe795cee7eb6f0c5678f9e505ccc9b6e57e8
Related: odoo/enterprise#22160
Signed-off-by: Josse Colpaert <jco@openerp.com>
Fields removed:
* l10n_latam_amount_untaxed
* l10n_latam_tax_ids
* l10n_latam_price_unit
* l10n_latam_price_subtotal
* l10n_latam_price_net
Methods removed:
* compute_l10n_latam_prices_and_taxes
* compute_l10n_latam_amount_and_taxes
* _compute_invoice_taxes_by_group
We move the removed methods to l10n_ar and l10n_cl and now it returns
a dictionary with the removed fields as the keys.
X-original-commit: 667ffb286d27f1e7a834b15d8f61536e530acd6f
Part-of: odoo/odoo#78296
Co-authored-by: Juan Jose Scarafia <jjs@adhoc.com.ar>
A new field on tax groups makes it now possible for this group to be displayed under a subtotal label. If not set, this defaults instead to "Untaxed Amount", keeping the traditional behavior. This is intended for withholding taxes, which can now be implemented with negative taxes and a tax group with this field set.
To do that, this commit entirely refactors the way amount_by_group worked, and replaces it with a more complete json field called tax_totals_json. It also streamlines the way taxe totals are displayed on invoices, PO and SO and makes it so that a common code is called instead of copy-pasting the same block 3 times as before.
[IMP] purchase: always display tax totals by groups on purchases orders
Before, tax totals on purchase.order's form were not shown by group, and were instead all aggregated in a single "Taxes" category. The same went for the pdf export. The portal view, though, did show the totals by group. We now display the tax groups in the same way all the time.
closesodoo/odoo#74138
Task: 2457374
Related: odoo/enterprise#19802
Related: odoo/upgrade#2670
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
move l10n_latam_document_type_id_code field definition to latam module
in order to be re used by another latam localizations
closesodoo/odoo#75764
Related: odoo/enterprise#20513
Signed-off-by: Josse Colpaert <jco@openerp.com>
The compute method `_compute_l10n_latam_document_type` could give
results that were not satisfied by the constraint
`_check_invoice_type_document_type`.
The onchange/inverse would only be triggered in the case of manual document number (vendor bills)
or not highest_name, but in other localizations there are cases where we want to be more flexible
to when we change it and instead of inheriting the method, we can relax it here.
Also, it should have been avoided before already to change the document number and type in those situations
through the attributes in the view e.g. This seems to have been more like an extra fail-safe blocking us
elsewhere.
closesodoo/odoo#73397
X-original-commit: a3f8e53deb45034250820ff54ba76288af167b6e
Signed-off-by: William André (wan) <wan@odoo.com>
For the unit price (field l10n_latam_price_unit), we need the number
rounded based on the product price precision.
To compute it we use the method compute_all that rounds using the
currency accuracy, so to fix this we multiply and divide for
10^(decimal accuracy of product price) to get the price correctly rounded.
Steps to replicate the error:
1) In a base with l10n_ar localization installed change the decimal
accuracy of "Product Price" to 5 digits (keeping the currency
precision in two digits).
2) Create an invoice with a product with price $10.12345
3) Print the invoice and check the column price unit.
Before this commit, the price unit would be $10.12000.
closesodoo/odoo#72579
X-original-commit: 17e19c6bf787fd2bf77476ffcfa1d934058aa7ec
Signed-off-by: William André (wan) <wan@odoo.com>
The fields l10n_latam_price_unit and l10n_latam_price_net should be
float instead of monetary in order to show rightly the decimal
accuracy on invoice's reports
closesodoo/odoo#69344
X-original-commit: 59afbc2e34c80516fa412de92f0d3bba2378661e
Signed-off-by: Josse Colpaert <jco@openerp.com>
For b2c invoices we mustn't show the IVA information on the reports
closesodoo/odoo#68758
X-original-commit: 4e31502f317fabc2004bd6db32883ce357563c57
Signed-off-by: Josse Colpaert <jco@openerp.com>
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>
Before, when importing twice the same invoice, or even with the more
theoretical possibility of having the same number for different partners,
the constraint would be triggered, giving unnecessary problems when
importing vendor bills with an uncertain partner_id.
If we check the logic followed in the regular accounting on the ref field,
it only triggers when a partner is set, so we can follow the same logic here.
closesodoo/odoo#68408
X-original-commit: 9cbf63bd644d6d6d629266fe31edc91b44f22aa6
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
Odoo has made some modifications to the method
_compute_invoice_taxes_by_group from de Account module,
so we need to update the inherited method in the argentinian localization
Improves:
- Don't depend on price_subtotal to compute amount_by_group
- Show taxes when they are zero on invoices print
closesodoo/odoo#68178
X-original-commit: 011631a38564bcbdd8625428b9f897aefefce270
Signed-off-by: Josse Colpaert <jco@openerp.com>
The problem that occurs before of this commit, is due the base of the taxes is in the currency of the company not in the invoice currency. For that the value that shows in this cases for the base is not correponding for the symbol of the currency.
After this changes we show the correct value an symbol for the base converting the value when is necessary.
X-original-commit: 4fd4f82ecd1b97f608168baaa780844f68e8a9d7
Issue
- Install 'Accounting' module
- Create a new 'Tax' X with a fixed price (e.g.: O.O57 $)
- Create a new 'Customer Invoice'
- Add a product P and set unit price to 0 $
- Set tax X to product P
Total tax amount : - 0.06 $ .
Solution
The sign must be forced to a negative sign in case the balance is on credit
to avoid negatif taxes amount.
enterprise PR : https://github.com/odoo/enterprise/pull/15035
opw-2378978
closesodoo/odoo#62758
X-original-commit: 684855529e8aaafa0cb90f958d19c563d6e2a897
Related: odoo/enterprise#15105
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
For this case, if the invoice currency is different from the invoice company currency, the tax calculation is considered the value in a different currency, and the subtotal is the sum of the amount untaxed + the taxes (wrongly in company currency) result in an incorrect value. This is verified when printing the invoice report
closesodoo/odoo#62388
X-original-commit: 91f152f479923a1d28dadcb3ded7c0296cc585fc
Signed-off-by: Josse Colpaert <jco@openerp.com>
Skip the computation of the field `l10n_latam_document_type_id` at the module installation.
The case has been detected during an upgrade from Odoo 12.0 to Odoo 13.0,
but the case could really well happen outside the context of an upgrade,
for instance when you create a new subsidiary in Chile or Argentina
while you already have a lot of accounting entries in your other subsidiaries
(e.g. Odoo S.A. opens a new office in Chile and has to install `l10n_cl`)
Without this, at the module installation,
it would call `_compute_l10n_latam_document_type` on all existing records
which can take quite a while if you already have a lot of moves. It can even fail with a MemoryError.
In addition, it sets `_compute_l10n_latam_document_type = False` on all records
because this field depends on the many2many `l10n_latam_available_document_type_ids`,
which relies on having records for the model `l10n_latam.document.type`
which only happens once the according localization module is loaded.
(e.g. `l10n_cl/data/l10n_latam.document.type.csv`)
The localization module is loaded afterwards, because the localization module depends on this module,
(e.g. `l10n_cl` depends on `l10n_latam_invoice_document`, and therefore `l10n_cl` is loaded after)
and therefore there are no records for the model `l10n_latam.document.type` at the time this fields
gets computed on installation. Hence, all records' `_compute_l10n_latam_document_type` are set to `False`.
In addition, multiple localization module depends on this module (e.g. `l10n_cl`, `l10n_ar`)
So, imagine `l10n_cl` gets installed first, and then `l10n_ar` is installed next,
if `l10n_latam_document_type_id` needed to be computed on install,
the install of `l10n_cl` would call the compute method,
because `l10n_latam_invoice_document` would be installed at the same time,
but then `l10n_ar` would miss it, because `l10n_latam_invoice_document` would already be installed.
Besides, this field is computed only for drafts invoices, as stated in the compute method:
`for rec in self.filtered(lambda x: x.state == 'draft'):`
So, if we want this field to be computed on install, it must be done only on draft invoices, and only once
the localization modules are loaded.
It should be done in a dedicated post init hook,
filtering correctly the invoices for which it must be computed.
Though I don't think this is needed.
In practical, it's very rare to already have invoices (draft, in addition)
for a Chilian or Argentian company (`res.company`) before installing `l10n_cl` or `l10n_ar`.
```
Traceback (most recent call last):
File "/src/odoo/13.0/odoo/service/server.py", line 1190, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/src/odoo/13.0/odoo/modules/registry.py", line 86, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/src/odoo/13.0/odoo/modules/loading.py", line 423, in load_modules
loaded_modules, update_module, models_to_check)
File "/src/odoo/13.0/odoo/modules/loading.py", line 315, in load_marked_modules
perform_checks=perform_checks, models_to_check=models_to_check
File "/src/odoo/13.0/odoo/modules/loading.py", line 202, in load_module_graph
registry.init_models(cr, model_names, {'module': package.name}, new_install)
File "/src/odoo/13.0/odoo/modules/registry.py", line 364, in init_models
env['base'].flush()
File "/src/odoo/13.0/odoo/models.py", line 5458, in flush
self.recompute()
File "/src/odoo/13.0/odoo/models.py", line 5875, in recompute
process(field)
File "/src/odoo/13.0/odoo/models.py", line 5859, in process
recs.mapped(field.name)
File "/src/odoo/13.0/odoo/models.py", line 5266, in mapped
recs = recs._mapped_func(operator.itemgetter(name))
File "/src/odoo/13.0/odoo/models.py", line 5225, in _mapped_func
vals = [func(rec) for rec in self]
File "/src/odoo/13.0/odoo/models.py", line 5225, in <listcomp>
vals = [func(rec) for rec in self]
File "/src/odoo/13.0/odoo/models.py", line 5690, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/src/odoo/13.0/odoo/fields.py", line 2329, in __get__
return super().__get__(records, owner)
File "/src/odoo/13.0/odoo/fields.py", line 995, in __get__
self.compute_value(recs)
File "/src/odoo/13.0/odoo/fields.py", line 1109, in compute_value
records._compute_field_value(self)
File "/src/odoo/13.0/odoo/models.py", line 3968, in _compute_field_value
field.compute(self)
File "/src/odoo/13.0/odoo/fields.py", line 579, in _compute_related
record[self.name] = self._process_related(value[self.related_field.name])
File "/src/odoo/13.0/odoo/models.py", line 5699, in __setitem__
return self._fields[key].__set__(self, value)
File "/src/odoo/13.0/odoo/fields.py", line 1070, in __set__
self.write(protected_records, value)
File "/src/odoo/13.0/odoo/fields.py", line 2564, in write
cache.update(records, self, [cache_value] * len(records))
File "/src/odoo/13.0/odoo/api.py", line 768, in update
field_cache.setdefault(record_id, {})[key] = value
MemoryError
```
Upgrade request 49495
closesodoo/odoo#60573
X-original-commit: f2a08faa1e65cb381315cbd5d1a359901e8b7deb
Signed-off-by: Denis Ledoux (dle) <dle@odoo.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>
internal_type context key is not used anymore, now use the
debit_origin_id directly to know if the current account.move is a debit note
closesodoo/odoo#56673
X-original-commit: c45edd11a048d4822b1ffd5dcebdb63d0e0e8f45
Signed-off-by: Josse Colpaert <jco@openerp.com>
This provides a better API to search for records by name without the
formatting part (`display_name`).
This also simplifies all the overridings of `_name_search` that no
longer need to call `name_get()`. The call to `name_get()` is done in
method `name_search` in a generic way.
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,... )
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>
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.
* remove logic of sequences in invoices and use new logic to set invoices sequences.
* re add l10n_latam_document_number field to make the sequence set possible.
* replace type field with move_type field in model account.move
* add new field l10n_latam_manual_number to know when the document number should be or not set
* update compute highest_name everytime that the journal and document type change.
* implement how we deal with first number
* for customer invoices only compute the name after they has been posted
* be able to search by document type code
* update translations
l10n_latam_country_code field is no more needed for account.move
object thanks to commit 7edb5c11
Also, since country_code field has been defined in view_move_form,
no need to redefine it when it is inherited in l10n_cn module.
closesodoo/odoo#48719
Task: 2228210
Signed-off-by: Josse Colpaert <jco@openerp.com>
This document does not have any credit/debit note related documents, so
when a credit/debit not is required then the same document type is used.
This only applies in vendor bills so we are able to create the credit
note with this type of document
closesodoo/odoo#48117
X-original-commit: 7748e0e87fd3f4677a4026ed06516d36e8d52ad5
Signed-off-by: Josse Colpaert <jco@openerp.com>
The `type` field was renamed `move_type` in
d675dbaa4c but a forward-port re-added a
use of the old `type` name, which breaks if an account.move is
unlinked while l10n_latam_invoice_document is unlinked (and there are
related moves to update).
Instead of renaming the field, use the proper utility method for the
category (purchase) provided by account.move.
closesodoo/odoo#47301
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Formerly the vendor bills, customer invoices and regular journal items were
evaluated by the _check_unique_sequence_number method, but this is wrong
and also was overwritten Odoo original constraint error message.
Now the _check_unique_sequence_number evaluate the account.moves that are
not vendor bills that use documents because this kind of bills uniqueness
depends on the vendor: we can have same name of vendor bill from different
partners. This is evaluated in the already existing
_check_unique_vendor_number method
closesodoo/odoo#44813closesodoo/odoo#45643
Original-signed-off-by: Josse Colpaert <jco@openerp.com>
X-original-commit: beaa3bbacd4bd35ed11962a7466f111e5e85f0d8
Signed-off-by: Josse Colpaert <jco@openerp.com>
to be able to inherit these methods to make it easier to
add fields in the refund wizard e.g.
closesodoo/odoo#44629
X-original-commit: e814374a20de096fd795aec34ab0e3de4977fc85
Signed-off-by: Josse Colpaert <jco@openerp.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>
When create an invoice for a foreign customer, the document types are not showed and filtered. This is happening because there is not journal defined for exportation operations. Once this one is created all the proper filters for the document types and journals are working ok.
This PR add a redirect warning when trying to create an invoice for a foreign partner when we do not have defined the expo sale journal. This also alert the user that is a missing configuration that is affecting to the compute of the available document types. I applied the same for the local/intern case
closesodoo/odoo#43913
X-original-commit: c7bd13bbd2879dded677bb223ff857fb9c959c60
Signed-off-by: Josse Colpaert <jco@openerp.com>
Now use direclty the posted state from account move.
* This was changed in a constraint in l10n_latam_invoice_document module, also extend the constraint docstring
* This old states where also in a view domain in l10n_ar module for account.move view. We remove the field for the view (AFIP Responsibility) instead of fix the state name.
closesodoo/odoo#42982
X-original-commit: 33a5cfe068323f7fc4c92f42fadb8e236954d93a
Signed-off-by: Josse Colpaert <jco@openerp.com>
Before this change the manual taxes widget in the invoice form view was
broken for Argentinian invoices, with this change now the widget is
working.
It was broke because this method is used for the report/portal and
manual taxes in widget in the form view, and for Argentinian case
report/portal invoice should not discriminate some of the taxes depending og
the responsibility of the customer/issuer and the type of document
(example: Factura A, Factura B).
Also update the method in order to match the original one in odoo
account module and add missing group_id
closesodoo/odoo#40400
X-original-commit: 6260da7604b2a831668be42bf8745c53a09e8d16
Signed-off-by: Josse Colpaert <jco@openerp.com>
Since we are not using document only in invoice by now we remove the
option to incoude receipts.
closesodoo/odoo#38842
X-original-commit: af0703f959357120ec9a8ea674e02faaddfefb85
Signed-off-by: Josse Colpaert <jco@openerp.com>
The detected errors is about a normal field
(l10n_latam_document_type_id) which is written by a computed method
(_compute_l10n_latam_documents) making that the normal field value be
overwritten the value given by the user everytime the compute field is
re computed with the default value given by the compute.
We remove this write n the compute method and now we use and onchange
instead.
IMPORTANT: the l10n_latam_available_document_type_ids computed field is
changed from a m2m to a o2m to be able to use it on the new onchange
closesodoo/odoo#38973
X-original-commit: 96c70bb1eb34198b03eb21f00b57f819367677c4
Signed-off-by: Josse Colpaert <jco@openerp.com>
On l10n_latam_invoice_document, if a sales/purchase journal use documents, then the journal sequences are not used, with this improvement the user don't see fields that are no needed (Credit Notes Next Number) and also it avoids the creation of the refunds sequences that is not going to be used
closesodoo/odoo#38335
X-original-commit: 1b647b8ead1fc70c18223914c96619c7f9a21b6e
Signed-off-by: Josse Colpaert <jco@openerp.com>
l10n_latam_base:
* update translations
* extend manifest
* update manifest, delete new menus/fields/models from manifest
l10n_latam_invoice_document:
* update translations
* remove filter journals for recipts
* make method private
* extend manifest
* update manifest, delete new menus/fields/models from manifest
* misspelling error in ValidationError
* fixup missing change apply before merge/rebase
l10n_ar:
* make method private
* update translations
* catch error when stdnum.ar.format
* fiscal position with criteria diff from Responsibility
* Install AR CoA now set properly the company values.
* add meaning of CUIT when mentioned in code.
* unse a simplier elif and less conditions to evaluate
* only get concept for invoice lines that are not section/note
* remove TODO comments, this will be not implemented in this version
* update to sincular al the AFIP POS System options
* return match responsability type directly
* improve of manifest
* reference to tax group
* remove old not used file fot tax report
* update comments from spanish to english
* only set afip serive date when post the account.move
* unused file
* sum recordsets instead of union
* method name and remove log
* update manifest, delete new menus/fields/models from manifest
* Simply extra steps when loading AR COA: check directly
get_ar_responsibility_match in order to apply the extra verifications
and the extra configs in the company
* update demo refences to new demo for odoo
* return missing fix about _l10n_ar_create_document_sequences
* fixup missing change apply before merge/rebase
* set journal data as no update data.
closesodoo/odoo#36137
Signed-off-by: Josse Colpaert <jco@openerp.com>
* remove l10n_latam_amount_tax field: This one is not really neccesary since was used for CITI reports and this ones were deprecated.
* improve invoice report view inherit: Improve way to make inherit for report invoice using position attribute
instead of position replace.
* Report amounts:
* for excluded reports get price unit computing (and not price_unit) to get the untaxed price if the line has taxes with price included (as in sales)
* fix l10n_latam_price_subtotal for report with taxes included and tax included on the price
closesodoo/odoo#36716
Signed-off-by: Josse Colpaert <jco@openerp.com>
This module special for Chile and Argentina, although e.g.
Brasil and the Domenican Republic could use it too in the
future.
The number of an invoice does not just depend on the journal, but
also on the document type which depends on the type of client you
will send your invoice to. So, each of these needs their own sequence.
For the vendor bills, LATAM countries are really not used to an internal
reference number, so the internal number is immediately the one of
the vendor.
A special case is also that on certain documents, certain taxes need to be
included in the backend, but should not appear on the ticket (hidden,
but still included in the net price)
Daniel Blanco