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>
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>
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@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>
Was still using the old "selection:" form instead of ir.model.field.selection
closesodoo/odoo#44322
X-original-commit: fdf9b06d76f95965ed173b1631305f8c8c3a8d9d
Related: odoo/enterprise#8050
Signed-off-by: Martin Trigaux (mat) <mat@odoo.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>
Note: the original would only set the domain if
`l10n_latam_use_documents` was enabled but even if the fields are not
shown without that it doesn't make much sense to allow any document
type to be selected when latam docs are *not* being used.
In this revision, the document type is always filtered by available
types and that is only non-empty if we're using latam documents.
Task 2147923
closesodoo/odoo#40955
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Task 2085023
* Add a field that replaces the context to get the ids of the
entries/invoices
* Remove move_id, we can use move_ids instead
* Add text to explain invioces/bills will create refunds
closesodoo/odoo#38857
Related: odoo/enterprise#6263
Signed-off-by: Quentin De Paoli (qdp) <qdp@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>
The way the active_id(s) were retrieved made the wizard only take care
of one active_id. This prevented from reverse multiple invoices at the
same time.
closes odoo/odoo#38537
Fixes: #35759
X-original-commit: fe47011c3fdcec0bda5334f10679e853fe41e45a
Signed-off-by: Quentin De Paoli (qdp) <qdp@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)
Josse Colpaert