Trying to print or send an invoice using a foreign currency leads to a traceback while generating the PDF.
Steps to reproduce:
- Install l10n_ar and step into the AR company;
- Create a new invoice using a foreign currency (e.g. USD);
- Confirm the invoice;
- Try to Send/Print the invoice.
This is also the case with l10n_cl.
opw-3477108
closesodoo/odoo#134612
X-original-commit: 9578fa9854a000a58ca6ffbdf144104d6a99c56d
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Corentin Thaon (thco) <thco@odoo.com>
The default taxes for most localisations have been left undefined by
default. When loading the chart template, the model generally selects
the first sales and purchase taxes, based on the order in which the
taxes appear in the csv, for the default sales and purchase taxes
respectively.
This behaviour can be confusing to those who are not yet familiar with
it. It has been decided that it is preferable instead to specify the
default tax in _get_*_res_company function on the account chart template
model, such that the default taxes are defined explicitly for every
localisation.
task-3453997
closesodoo/odoo#130733
Related: odoo/enterprise#45531
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Description of the issue/feature this PR addresses:
Before SII resolution 46 from 2022, the only documents for foreign vendors were 110 111, and 112.
After that, SII and accountants are indicated as a practice to issue purchase invoices (Factura
de compra 46) to foreign vendors in order to pay the vat taxes, mainly for digital services.
Current behavior before PR:
It is not allowed by validation restrictions to issue this document type to foreign vendors
Desired behavior after PR is merged:
the validation release the restriction for document type 46
closesodoo/odoo#124392
X-original-commit: ee2485fd4c4e0f1ababbc74a0e1f349d58380cff
Signed-off-by: Josse Colpaert <jco@odoo.com>
Co-authored-by: Daniel Blanco <daniel@blancomartin.cl>
Co-authored-by: José Moreno Hanshing <jose@blancomartin.cl>
* l10n_ae, l10n_ar, l10n_at, l10n_au, l10n_bg, l10n_br, l10n_ch,
l10n_cl, l10n_dk, l10n_es, l10n_hu, l10n_in, l10n_mn, l10n_nl, l10n_no,
l10n_pt, l10n_sa, l10n_se, l10n_sg, l10n_si, l10n_uk
Some localizations do not have any default account for tax closing.
This leads to the opening of a RedirectWarning when trying to do a tax
closing.
task-3082332
closesodoo/odoo#124003
X-original-commit: 14abe7acb11d522fb2b4a274ac0eb06d41e637ed
Related: odoo/enterprise#42071
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
A lot of the separate files were kept up to now because it made the
process easier while applying the script to rebase.
The files can now be merged.
Some code is also cleaned by using CSV instead of a python dict.
Part-of: odoo/odoo#114164
Before this commit, the name and report name of document type for latam localization had been added in each latam localization. Since they depend on l10n_latam, we decided it would be better to just add translate=True to already existing field (name and report_name) instead of adding new field in those module. This commit corrects that.
Task-id: 3179209
Part-of: odoo/odoo#112803
Rewrite the whole chart template mechanism, removing the templates
stored in the database. The new format will mainly use CSV.
Speed up install time
---------------------
* About half of the time of installing a localization for the first time is
taken by creating the template records. This new in code format gets
completely rid of this.
* Creating the template records could often not be done in batch because
of parent/children relations.
* The instanciation of the accounts on the company has been entirely
reworked too, by
- optimizing the order of creation of records to avoid UPDATE queries
- using precomputed fields to avoid UPDATE queries
- updating the translation in batch
- deactivating logging in the chatter
- avoiding access rights checks by checking the rights at the start
Overall, when installing a chart template for the first time, it is 4
times faster because half of the time spent on saving the template in
the database is not done at all anymore, and the instanciation on the
company is more than twice as fast.
Reduce technical debt
---------------------
There is no need to synchronize the templates with the real records
anymore. No need to use hooks to copy the data from one to the other.
It is easier to change a template in a stable version, which can often
be necessary due to legal reasons (i.e. a change of tax rates, reporting
tags,...)
Two modules have been removed:
* `l10n_generic_coa`: since there is nothing left datawise in this
module, it can be integrated in `account` for free. It is just code
and CSV.
* `l10n_multilang`: the fields that this module modified to be
translatable are now always translatable:
- there was an issue when updating modules that deleted all the
translations because the fields were not translatable at some point
during the loading of the registry, then they because translatable
again but lost all translations because of the column type change.
- most devs are not able to understand all the languages needed for
all the localization available. Therefore, english has been added in
the sources in most localization to understand better issues while
debugging.
- no need to call post init hooks anymore, doing the sync with the
templates.
- more: see "Translations" section
Because most of the data is now in CSV, it is also easier for product
owners to edit, audit, modify files themselves, removing one layer
during trivial development processes when only data should be changed.
More flexibility for declaration
--------------------------------
The data declaration can now be done easily in python or CSV.
A nice feature is that you can declare everything at once, even for some
more complex chart of accounts:
* if you have to set default taxes on accounts, would need to
- declare the accounts because accounts are required on the taxes
- declare the taxes
- declare the taxes to put on the accounts
This would lead to scatter information in multiple files. Now,
everything can be declared in the same place and the loading of the
chart of accounts will do the 3 steps automatically.
* if you have a relation of child/parent, you would first need to
declare the parents then the children, and the loading would not be
efficient because done one by one. Now, everything is done in batch
automatically without having to think about it.
It is also easier to update fields on records where there was no field
for that on the templates, like
* setting a restriction for journals on accounts
* setting specific values on the company
* modifying journals and linking them easily by using the xml_id instead
of having to compute it manually
Translations
------------
Some countries have multiple languages (i.e. Belgium uses officially
French, Dutch and German, and the CoA also has an official English
version) and we must support the languages in all these countries.
All these translations are known, and hard coded without using out
translation platform (Transifex). We also like to have the English
version (even if an official one doesn't exist) so that support can be
done more easily in databases using chart templates in other languages
(especially using a non roman alphabet).
Because the translations were not on Transifex for these records, it was
really hard to maintain: the translation templates (`.pot` files) were
not easy to extract as the automatic export would give values mixing
both the CoA and the menuitmes, the fields' strings,... But we don't
want to translate the CoA as we already know the value.
Managing the translations in the `.po` files was also annoying:
- it is easy to forget that the translations need an update too
- it requires a special editor, special terminal commands that everyone
is not familiar with
- it is easy to make mistakes in the source string
The new format is the following: `field@en_US` where `field` is the
translatable field (usually `name`) and `en_US` is the locale code.
This allows to have the whole declaration on one line, everything in one
file. It also makes the process easier when debugging: instead of
searching for the translation in the `.po` files, it directly appears
next to the configuration of the account/tax/... .
Update of the code
------------------
The code can be updated using this script
https://github.com/william-andre/transform_coa
Forward ports can be managed too by stashing/resetting/checkout the new
modules or the changes in the modules updated in the same PR.
task-2687567
Part-of: odoo/odoo#110016
Before this PR, all this localisation was written in Spanish, but all the localisation have to be written in english and then translated back in the native language. This PR correct that.
closesodoo/odoo#112160
Task-id: 3166093
Related: odoo/enterprise#36801
Signed-off-by: William André (wan) <wan@odoo.com>
this fixes the domain of document types for vendor bills, (was failing since it included
invoices as a document type as option for
credit notes in the wizard and also fixes the opposite (credit notes in invoices generation)
closesodoo/odoo#98002
X-original-commit: 1a8a6c369b257bef87bc3efe62fc9b764a02ebf1
Related: odoo/enterprise#30368
Signed-off-by: Josse Colpaert <jco@odoo.com>
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>
(i.e. orden de compra, guia de despacho) if they are enabled
closesodoo/odoo#93763
X-original-commit: afde2ab2cd44078b812e3fdd1553a55650fa45c0
Signed-off-by: Josse Colpaert <jco@odoo.com>
Task: 2817024
1. l10n_cl uses _prepare_tax_lines_data_for_totals_from_invoice() and _get_tax_totals() to prepare invoice totals for exporting invoices in pdf.
After the recent changes these methods no longer exist and invoice totals should be calculated in a different way.
2. Contact widget should not have ```'no_tag_br': True``` anymore to show the address properly.
closesodoo/odoo#88144
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Have a CL company setup
Issue a vendor bill
Then generate the credit note via 'Add Credit Note' wizard
Add a reason and confirm
Error will raise “You can not use a invoice document type with a refund
invoice”
As
https://github.com/odoo/odoo/commit/c9ff9d28ab75c02093ca54d9fbd1d2e203c5ee2e
for the invoice case
we need to add specific logic to handle credit notes in l10n_cl
opw-2801576
closesodoo/odoo#87946
X-original-commit: 0f1edf4d47d936c440e42fa105a8a5d6a75a8a77
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@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>
Have a CL company setup
Issue an invoice
Then generate the credit note via 'Add Credit Note' wizard
Add a reason (credit method is locked to 'partial refund') and confirm
Error will raise “You can not use a invoice document type with a refund
invoice”
This occur after
https://github.com/odoo/enterprise/commit/9e049b833b23809e4287ef61ddf7482413debefd
We now fall back to the logic of l10n_latam_invoice_document
which, in turns, fall back to the l10n_cl, ignoring the 'credit_note'
case.
opw-2794515
closesodoo/odoo#87116
X-original-commit: c9ff9d28ab75c02093ca54d9fbd1d2e203c5ee2e
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@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
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>
[FIX] l10n_cl: adds new latam reference document types
[FIX] l10n_cl: add additional document references
[I18N] l10n_cl: translate as T.doc to reduce width of column
[FIX] l10n_cl: add l10n_cl_active to latam document type view
[FIX] l10n_cl: change account 410235 to direct cost instead of expenses
[FIX] l10n_cl: change account withholding of second category to most recent tax rate (-11.5%)
closesodoo/odoo#75865
Related: odoo/enterprise#20565
Signed-off-by: Josse Colpaert <jco@openerp.com>
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>
Adapt the module to calculate removed fields from latam localization
closesodoo/odoo#78296
X-original-commit: 9269ac23e86cfd0218234360ac8271785697a725
Signed-off-by: Josse Colpaert <jco@openerp.com>
Co-authored-by: Juan Jose Scarafia <jjs@adhoc.com.ar>
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>
Steps to reproduce the bug:
- install l10n_cl
- Create two contacts and for only one of the two fill in the "Identification Number" field
- Go to contact app > select both contacts to edit some of their fields at the same time
- For example, edit “City” > save
Problem:
The "Identification Number" of contact 1 is copied to the second contact,
while normally only the "city" field of the two contacts needs to be changed.
This is due to the fact that we do not check in the write function if the vat or identification_type are in values before changing the vat.
Solution:
check that `vat` or `l10n_latam_identification_type_id` are in values before changing the vat
opw-2587994
closesodoo/odoo#75472
X-original-commit: 11ec94df926db98265d26af1072a0c8bf1843083
Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>
- latam document type was used in l10n_cl_sequence_ids and used the same
table in l10n_cl_journal_ids but it was never used any where
task- 2464212
closesodoo/odoo#71095
Related: odoo/upgrade#2478
Signed-off-by: Josse Colpaert <jco@openerp.com>
This method was defined in `account` but overrided in `l10n_cl`. Prefix
the method to avoid that.
X-original-commit: c60530eedc70f7bb6040adaf311a273bad5aa37c
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>
when the partner is Tesoreria de la República, and exclude the credit note.
closesodoo/odoo#67630
X-original-commit: 8ca3ea063050f2ab2d19cce8a68116489872a734
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>
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,... )
Create an invoice, fill document type
"(61) Nota de Crédito Electrònica". Save.
Action will be blocked by a warning: document type is invalid.
Some options in the document type should not be shown as they can not be
used in the customer invoices and customer credit note.
opw-2286623
closesodoo/odoo#53987
X-original-commit: 3b9738a394c4944b0c859f68f561e50d14b92942
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
[FIX] l10n_cl: format RUT/VAT as used in Chile (99999999-X)
[FIX] l10n_cl: prevent errors with domain of available documents in invoice view.
[FIX] l10n_cl: allow to select document types when partner is empty
[ADD] l10n_cl: add ILA taxes (purchase and sale) and assign account to taxes
[ADD] l10n_cl: add fiscal position exempt for purchases and sales
[IMP] l10n_cl: configure accounts used in inventory valuation
[FIX] l10n_cl prevent to put unneeded sales documents in sales journal
[FIX] l10n_cl limit revision of document types and partner constrains only for sale and purchase journals
[FIX] l10n_cl: add extra validation to know wether there is a latam_document_type_code selected
[ADD] l10n_cl: add document type '801' Orden de compra
[WIP] add tag to costo de ventas account
[FIX] l10n_cl: fiscal position templates: fix supermarket tax
[FIX] l10n_cl: change order for boletas
[WIP] l10n_cl: fix the compute document types method
[FIX] l10n_cl: prevent expected singleton error (checked in tests) in post
[I18N] l10n_cl: add new translations
[I18N] l10n_cl: reduce size of taxes names and abbreviation for invoices (probably more work to add here)
[FIX] l10n_cl: remove countries from accounts
[FIX] l10n_cl: remove recalc of domain when journal changes
[FIX] l10n_cl: remove sale constraint
closesodoo/odoo#53068
X-original-commit: 060f083879f6094941f746928832fec253a23bb0
Signed-off-by: Josse Colpaert <jco@openerp.com>
* avoid doing super where we removed the super method: Was done in adapting l10n_cl to do without the methods in l10n_latam_invoice_document
* journal name to create
* at least fix for the document type itself
* making it work like before with shared sequences
closesodoo/odoo#49095closesodoo/odoo#51496
Related: odoo/enterprise#9699
Related: odoo/enterprise#10654
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>
Description:
- Add readonly attribute to partner view for l10n_cl_sii_taxpayer_type field for children res.partner records.
- Fix the tax payer type label to prevent usage of "label for.."
- Optimize document type order to put most used on top of file and in selection of document types during invoicing process
closesodoo/odoo#41372
X-original-commit: 4162b9b618ffe62548e9a1d5ae3c0fdd604a1395
Signed-off-by: Josse Colpaert <jco@openerp.com>
Corentin Thaon (thco)