This commit improves the fiduciary mode by:
- removing message error about the change of sequence format
- suggesting the Customer Invoice / Vendor Bill date according to the following heuristic:
- Last day of the month of the most recent Customer Invoice / Vendor Bill (ignoring drafts) OR today (whichever is the smallest)
- If this date falls before a Lock Date, pick the last day of the first month that is not locked
- Examples:
- Example 1 :
We are June 17th 2022. No Lock date. Bill Date of the most recent Vendor Bill : March 15th 2022
==> Default New Vendor Bill date = March 31st 2022 (last day of March 2022)
- Example 2 :
We are June 17th 2022. No Lock date. Bill Date of the most recent Vendor Bill : March 31st 2022
==> Default New Vendor Bill date = March 31st 2022 (last day of March 2022)
- Example 3 :
We are June 17th 2022. No Lock date. Bill Date of the most recent Vendor Bill : June 2nd 2022
==> Default New Vendor Bill date = June 17th 2022 (today is the smallest)
- Example 4 :
We are June 17th 2022. Lock date : April 30th 2022. Bill Date of the most recent Vendor Bill : April 30th 2022
==> Default New Vendor Bill date = May 31st 2022 (last day of the first month not locked)
- renaming the invoice according to the suggested date
Task id: 2887007
closesodoo/odoo#101799
X-original-commit: 179f4f83db0d029850375012bbf80dedc6679505
Signed-off-by: William André (wan) <wan@odoo.com>
The account_move view was changed in master and that way
the document type and number were not visible anymore or in
a weird way. If we just put it after the journal_div, everything
seems fine.
closesodoo/odoo#98810
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Steps to reproduce:
- Install l10n_ar module (or any l10n_* module that depends on
l10n_latam_invoice_document)
- Go to Accounting -> Vendors -> Bills
- Click on Upload and select a bill file
- Open draft bill
- Click on `Send For Digitalization`
Issue:
Digitalization don't start and a warning message is diplayed saying
that some required fields are invalid.
Cause:
When clicking on the button to digitalize the invoice, we try
to save the form first before executing the action.
By doing so, if some fields are required and empty, a warning message
will be displayed.
In this case, the issue is with the fields `Document Type` and
`Document Number`.
Solution:
Set `Document Type` and `Document Number` to not required if there is
no partner_id set on the bill.
opw-2797444
closesodoo/odoo#98115
X-original-commit: b95473e3edf79796c7915afcdec5b4aa9addf273
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Only for terms containing Credit Note and expenses
closesodoo/odoo#97840
X-original-commit: 1754b094a66476a0bdb29fe60dc5583c03336c3f
Related: odoo/enterprise#30262
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Have a Peru company setup
Create 2+ draft invoices of mixed type 'Boleta' and 'Factura'
In list view select the created moves and do action>"post entries"
The posted entries will have the same name prefix, either all 'BOL' or
'FFI', depending on the first computed name, the system will use the
same prefix for the remaining move names
opw-2860231
closesodoo/odoo#95271
X-original-commit: d7a5b34e46436f49592ab6706ac33bcf7a3fbf80
Signed-off-by: William André (wan) <wan@odoo.com>
Most of the extensions of `_name_get` are very similar and only want to
search for the given string in multiple fields.
A lot of extensions also don't take into account the negative operators.
Some implementations were also really outdated and needlessly
complicated.
closesodoo/odoo#86588
Related: odoo/enterprise#25608
Signed-off-by: Raphael Collet <rco@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>
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 license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.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>
This commit implements improvements in the layout designer, such as addition of a new custom background, adds custom report footer and company details.
task-2355704
closesodoo/odoo#66860
Related: odoo/upgrade#2275
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.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>
When l10n_latam_invoice_document is installed and the current company
does not have a custom header (in stable, only Chile and Argentina with
their localization installed use custom header), printing multiple
invoice at once, one out of two had no header or footer.
This is because `<div class="header"/>` and `<div class="footer"/>`
should be unique per record being printed, and when a custom header was
not used they were duplicated with the duplicate empty.
As an example, if we had 3 documents:
- record 1 : good header
- record 1 : empty header
- record 1 : body
- record 1 : good footer
- record 1 : empty footer
- record 2 : good header
- record 2 : empty header
- record 2 : body
- record 2 : good footer
- record 2 : empty footer
- record 3 : good header
- record 3 : empty header
- record 3 : body
- record 3 : good footer
- record 3 : empty footer
When we give them to wkhtmltopdf, it would be mismatched:
- headers:
- record 1 : good header
- record 1 : empty header
- record 2 : good header
- bodies:
- record 1 : body
- record 2 : body
- record 3 : body
- footers:
- record 1 : good footer
- record 1 : empty footer
- record 2 : good footer
so record 2 will have empty header/footer, and record 3 will get those
of record 2.
opw-2507137
note: the master forward-port also remove t-if that are no longer
necessary since the same t-if is on an ancestor tag now.
closesodoo/odoo#69718
X-original-commit: 90bdb5c7b7aa6a9b98e9acb1774d449ae65a3918
Signed-off-by: Nicolas Lempereur (nle) <nle@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
Part of task 2124952
Amend the demo data to populate required fields added in dependencies of
l10n_cl.
The field l10n_latam_document_number is not required if the journal is
not using Latam invoice documents.
The name of your first customer invoice is a configuration that
determines the next ones. The problem before is that when you
confirmed a first invoice, you could not alter its document number
anymore. With this commit, as long as it is the first invoice,
you can still change the document number when you reset to draft.
closesodoo/odoo#65341
Related: odoo/enterprise#16058
Signed-off-by: Josse Colpaert <jco@openerp.com>
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>
Issue
- Install "l10n_latam_invoice_document"
- Try to add a credit note to any invoice
Cause
"l10n_latam_manual_document_number" is unitialized when
"l10n_latam_use_documents" is equal to False
Solution
Init "l10n_latam_manual_document_number" to False
opw-2366298
closesodoo/odoo#60656
X-original-commit: 6b5f40f4310f02204d98c58d45f92a27c7fad7c1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.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>
For terms different than es
closesodoo/odoo#57550
X-original-commit: cb8e12aeda19373764fd01971aa9f7b24aef866c
Signed-off-by: Martin Trigaux (mat) <mat@odoo.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.
port foward from 13.0 branch, also remove the logic of _get_name_invoice_report()
method already added in account module and remove the not needed latam
report templates.
In version 13.0 we add account_debit_note as dependency to l10n_ar_edi,
but this was made because we were not able to add new depends to
l10n_latam_invoice_document module in stable version.
Now that we are in master we are able to add the dependency directly
here and remove it from l10n_ar_edi
closesodoo/odoo#55771
Related: odoo/enterprise#12361
Signed-off-by: Josse Colpaert <jco@openerp.com>
The latam docuemnts used for document type an document number are not
showed correctly in the view, they displaying to close side by side and
the related labels are not show.
After this PR this has been fixed and now we have the labels and the
proper separation of the fields in the invoice form view.
closesodoo/odoo#55648
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,... )
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.
When printing an invoice using l10n_latam_invoice_document it crashes as res.partner does not have an attribute 'l10n_latam_identification_type_id', keeping the whole xpath is not needed as the VAT label is already considered in the account module: https://github.com/odoo/odoo/blob/13.0/addons/account/views/report_invoice.xml#L10closesodoo/odoo#48800
X-original-commit: 9f0bf9bcaa6c21c36d5abdc5316aa80cef67f12f
Signed-off-by: Josse Colpaert <jco@openerp.com>
* 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
Task 2206699
* All the amounts are now expressed in the company currency
- The amounts are taken from debit/credit on the aml
- When opening the report for multiple companies, convert in the
current company's currency
* New default view:
- Group by month instead of category
- Line chart instead of bar chart
- Filter on customers
* Remove useless fields:
- name
- invoice_partner_bank_id
- invoice_payment_term_id
- residual (including taxes)
- amount_total (including taxes)
- nbr_lines as it is a generic feature
* Rename currency_id to the more correct company_currency_id
* Remove useless group_by clause from the SQL query
closesodoo/odoo#47066
Related: odoo/upgrade#1021
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Ricardo Gomes Rodrigues (rigr)