These changes are made as a result of simplifying attrs and 'states' in
views. However, they should have remained in a separate commit. When
applying the script making the xml changes (used later for the migration
script), the script checked the definition of the python fields in order
to convert the information into a python expression. Therefore, this
commit is not applied when the script is applied to xml changes.
During this attribute deletion pre-existing errors were found. Part of
the code was using the boolean values of 'states' and another part of
the code was not. The behavior could therefore be different (in cases
where readonly on the field had the same value as the ballan in
'states').
Following the deletion of 'states' and without the application of the
view migration, the js tests (tower) were no longer functional. Tests
using the Form view suffered the same effect. There are few tests that
had to be adapted, including two tests in business accounting (updated
by the accounting team). A test for column_invisible did not work. Test
checking if the test system triggers an error if we try to write on an
invisible field. It turns out that Form was testing on the value of
invisible but not taking into account if the column was invisible. The
test system fix is applied separately because there were a lot of tests
that were incorrect.
Part-of: odoo/odoo#104741
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>
When there is an error in the proxy for incoming file for specified proxy user
from SdiCoop.
It will raise proxy error in the terminal.
This commit will change logger error to logger warning.
sentry-4297451894
closesodoo/odoo#130229
X-original-commit: a2882524371f39b210984c50b5702f142dff76ee
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Bug:
Currently, trying to import a fatturapa XML that has a document discount
doesn't do anything.
Setup:
- install l10n_it_edi and account_accountant
- have a fatturapa XML that has a document discount
Steps to reproduce:
- switch to the Italian company ()
- make sure that the VAT number on the document matches the one on the
company
- attempt to upload the XML bill
You should be met with an empty vendor bill page.
Cause:
The issue comes from here: https://github.com/odoo/odoo/blob/43c9820b1d3020d89b1b7ca016754e29d1fc6b58/addons/l10n_it_edi/models/account_edi_format.py#LL725C21-L729C83
in 16.0, `invoice_form` is not an instance of `Form`, but a record.
opw-3193634
closesodoo/odoo#123445
X-original-commit: 3443f2fbce36f800ebb5a87ce0d393dbcb30f2bc
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
When we confirm an invoice without adding a product in it and then click on
process now then we will face the above valuerror.
Steps to produce:
1) Install 'l10n_it_edi'.
2) Change the company to 'IT Company'.
3) Now go to 'Invoicing' settings and then under 'Fattura Elettronica mode'
check 'Allow Odoo to process invoices' radio button.
4) Create an invoice by adding a partner.
5) While creating it click on 'Add a section' instead of 'Add a line'.
6) Click on confirm.
7) Now Click on 'Process now'.
By following the above steps you will be able to produce the above error.
Applying this commit will solve the valuerror issue.
Sentry- 4170737698
closesodoo/odoo#124771
X-original-commit: 8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a
Signed-off-by: William André (wan) <wan@odoo.com>
When creating an invoice with a positive line and a negative line, with
different taxes, the DatiRiepilogo node for the tax of the negative
line contained positive amounts when they should be negative.
This is because we were applying `abs()` too naively in the XML template
and in the code of _l10n_it_edi_prepare_fatturapa_tax_details.
This bugfix commit changes the logic to no longer use abs().
opw-3316300
closesodoo/odoo#122982
X-original-commit: 0241e96fe12401f0891efc00f840e03d0c0219fd
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Moved some logics belonging to the partner from the account_edi_format model to the res.partner model instead.
Functions:
_l10n_it_edi_get_values (normalized vat, country code, is_company, in_eu...)
_l10n_it_edi_normalized_codice_fiscale
Added `phone` and `email` fields to the EDI export tests.
Added a message on the export tests asserts to know what's the test file that generated an error.
Task link: https://www.odoo.com/web#id=3175408&model=project.task
Task-3175408
closesodoo/odoo#105696
Signed-off-by: Josse Colpaert <jco@odoo.com>
Edi format is going to be removed eventually - `account_edi_proxy_client` should not depend on it and be more flexible in general.
This commit:
- Removes edi_format field from `account_edi_proxy_client.user` model. We still have to add them in `l10n_it_edi` as it still heavily relies on edi format for now.
- Adds a way to have a unique edi user per company, proxy user, edi mode combination.
This is a necessary step before adding peppol, which will also depend on the account_edi_proxy_client
closesodoo/odoo#116059
Related: odoo/upgrade#4458
Signed-off-by: Laurent Smet <las@odoo.com>
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If the invoice has a deduction line for a down payment, the EDI
generated XML file should have a reference to it in the
DatiFattureCollegate. We take the reference from the related sales
order.
Same goes for credit notes: they should have a reference to the original
invoice. We take the reference from the move's reversed_entry_id field
Task link: https://www.odoo.com/web#id=3210485&model=project.task
Task-3210485
closesodoo/odoo#118307
X-original-commit: 1f62ed76731a15cee5345dc0312ac819dadbcb44
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
In case we retrieve the maximum number of documents the IAP server
can send, we retrigger the cron to receive more documents, until
we get them all.
Parameter `recipient_codice_fiscale` wasn't used at all, download is
related to the proxy user which is determined by authentication on the
IAP proxy.
See odoo/iap-apps#583closesodoo/odoo#116927
X-original-commit: 43c9820b1d3020d89b1b7ca016754e29d1fc6b58
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Every imported vendor bill now will have the chance to make its invoice_origin linked to a Purchase Order.
The function is moved from account_journal to account_edi_format to allow the link being done from all webservices, thread attachments and upload.
- Avoid mocking the proxy testing
The test on the check that the same attachment is coming twice from the proxy doesn't actually need to test the proxy. By splitting the function, we avoid mocking the proxy for no added value. Added an ir.rule for companies to only look for their account_edi_proxy_client.users
- PA Index label should be Destination Code
PA Index is a completely wrong description. This is the destination "address" of the partner at which our EDI documents (invoices) should be directed to inside the SdI e-invoicing system, much like an IP address. It's not an index, doesn't have much to share with the Public Administration. The correct literal translation of the name should be "Destination Code"
for Codice Destinatario. We have clients opening tickets because they don't recognize this field on the partner form because of the wrong translation.
- Fixes on taxes import
Lines didn't have their taxes cleared, so invoices actually added the taxes in the XML to the default supplier taxes of the product VAT taxes on import search was conflicting with actual withholding / pension fund taxes, so extra conditions are added in the search if withholding / pension fund fields are not specified
Task link: https://www.odoo.com/web#id=3175353&model=project.task
Task-3175353
closes odoo/odoo#114870
Forward-port-of: #111365
Signed-off-by: Josse Colpaert <jco@odoo.com>
If an invoice is send to the Tax Agency, we should block the fact
that the user can delete it. In that case, we can have issues when
the tax agency sends back notifications.
Task link: https://www.odoo.com/web#id=3192962&model=project.task
Task-3192962
closesodoo/odoo#114872
X-original-commit: c11a512af4e467068c6b228bf55225e5e43d7811
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Refactoring send&print wizard.
==============================
Main reason for this commit is that we want to let the user
decide when to generate the relevant documents / approvals
for its invoices. The natural choice is when the information
leaves Odoo. So now, each time the users decide to
download/send its invoices, he will be able to select the
relevant documents to be generated and the approvals to be
requested from the send&print wizard.
This used to happen automatically during the posting with lots
of undesirable behaviors (difficulty to update/revert, hard to
know exactly what will happen,...)
Main changes:
1/ Send&print wizard
- The model 'account.invoice.send' has been replaced by
'account.move.send' and became models.Model to handle
asynchrounous generation of documents (webservice,..) in
case of more than one invoice.
- The wizard is meant to be overriden in order to add
checkbox and document to be generated. A comprehensive exemple
can be found in account_edi_ubl_cii.
2/ Import invoice from attachments
- The decoding logic has moved from account_edi to account
on the attachemnts.
- The function _extend_with_attachments() serve as a common
entry point for import (from chatter, dashboard).
3/ Export invoice pdf / document
- All the specific actions to export attachments should be
implemented on the account.move and called from the wizard in
_generate_documents()
- The official pdf for the invoice is now only generated once
the user request it. In order to regenerate the pdf and
documents, it needs to be deleted.
task-id: 3117238
[enterprise](https://github.com/odoo/enterprise/pull/36757)
[community](https://github.com/odoo/odoo/pull/111857
)
[IMP] web: enable close on ir.actions.act_url in wizard
Before this commit, calling ir.actions.act_url on a modal
leaves the modal open. Which feels ackward in the send&print
wizard.
We now enable 'close' parameter on ir.actions.act_url. If set,
the wizard will close after act_url.
closesodoo/odoo#111857
Related: odoo/enterprise#36757
Related: odoo/upgrade#4387
Signed-off-by: Laurent Smet <las@odoo.com>
In some cases, Odoo's move state is unaligned to that on the
IAP Proxy Server, because the ACK message from Odoo to IAP
deletes all attachments from the EDI transactions on the IAP
without regard if they are with type "Send" or "Receive".
We fix both cases by making Odoo just look at the state and not
to the attachment when it's not needed, and it's only needed when
there is a rejection of the document being sent.
We reserve for the future a change to the ACK to only delete the
attachments by transmission type (Send/Receive) so that they don't
interfere.
Error case 1:
- Odoo client sends an invoice to the IAP Proxy
- The IAP proxy will send it to the SdI
- If everything goes well, the SdI will send a notification back
- The IAP proxy sees the notification and saves it
- The Odoo of the client downloads the notification and sends an ack
- The IAP proxy sees the ack and deletes the attachment
- (ERR!) The client resets to draft, modifies and re-confirms
- The state of his invoice is set again To Send
- Odoo tries to re-send the invoice with the same Id Transaction
- The notification for that Id Transaction is already on the IAP proxy
- Odoo client asks for changes, but just sees the old notification
- (-->) The old notif. has no attachment, so Odoo thinks there's no news
- The move in Odoo stays in the To Send state forever
Error case 2:
- Odoo client sends a Tax Integration for a Vendor Bill (reverse charge)
- The IAP proxy will send it to the SdI
- If everything goes well, the SdI will send the same Vendor Bill back
as the client's CodiceDestinatario is actually the recipient in the XML
- The IAP proxy sees the file, the Id Transaction is the same
for both the received and the sent documents
- The SdI sends a notification because the tax integration is OK
- The IAP proxy saves the notification, there are now two EDI
transactions with the same Id Transaction.
- Odoo checks for new documents
- IAP proxy sends the document to Odoo
- Odoo sends an ACK for that
- (ERR!) the IAP proxy sees the ACK and clears the attachment
from BOTH the records for sent and received document
- Odoo checks for documents updates and gets the record without
the attachment
- (-->) The notification has no attachment, so Odoo thinks there's no news
- The move in Odoo stays in the To Send state forever
Ticket link: https://www.odoo.com/web#id=3194378&model=project.task
opw-3194378
closesodoo/odoo#114051
X-original-commit: f85744ee4533ea8593b81a88ef200ec4dc1b1b94
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
If there's a l10n_it_edi_transaction id on the move, then the move
has been sent to the SdI and it has received no rejection yet.
So we avoid showing the Reset To Draft button in that case.
Task link: https://www.odoo.com/web#id=3191726&model=project.task
Task-3191726
closesodoo/odoo#113694
X-original-commit: dc088f2dabc369a3c7a00be7d20e81a56aeffef5
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
- l10n_it_edi: EDI receiving cron error handling fix
If we cannot receive invoices or bills from the IAP proxy we also can't
iterate over them
- l10n_it_edi: Check edi_format before trying to remove signature
The edi_format must be checked before trying to remove the eventual
PKCS#7 signature from the file, otherwise we're uselessly going to try
and remove the signature for every edi_format check (facturX etc.)
- l10n_it_edi: .p7m files can wrongly be missing the signature
In the case that the .p7m extension is put by mistake, try to use the
content of the file as it is before discarding it.
Task link: https://www.odoo.com/web#id=3189457&model=project.task
Task-3189457
closesodoo/odoo#113451
X-original-commit: 942e3c7f2b549fed86f9eb76f98f30b7e5db1ae9
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
# Steps to reproduce
* install account_accountant, documents and l10n_it_edi
* Switch to an Italian company
* go to Documents > Configuration > Workspaces and create a new
workspace `W` and it's child `W1`
* under Documents > Settings, activate Accounting and set `Workspace`to
`W`
* save and go back to Documents > Settings, and click `Journals` under
'Accounting'
* add a line with Journals = 'Vendor Bills' and Workspace = `W1`
* go to Accounting > Vendor > Bills and upload a Fattura PA XML bill
* now open the newly generated bill
You should see that the chatter does not load.
# Cause
When uploading a Fattura PA XML bill, a PDF attachment is created and
added to the chatter. The issue is happening because the
`ir.attachment` record ends up in an invalid state where its 'res_model'
field is false.
The 'res_model' field is actually defined when the attachment is
initially created. However, that value ends up being overwritten when a
related `documents.document` is created here: https://github.com/odoo/enterprise/blob/3f53e50989fbb9551565429aede7c0a1e4d6e5a4/documents_account/models/account_move.py#L88
Because of the following line, that `documents.document` will be
assigned a default `res_id` (but no `res_model`).
https://github.com/odoo/odoo/blob/26b2cbd4e5c73ea66456a91ea9cb36d6b174cae7/addons/l10n_it_edi/models/account_edi_format.py#L767
However, setting `res_id` (or `res_model`) on a `documents.document`
will also overwrite the related attachments' values (in this case, the
attachment's `res_model` is set to false because the document's
`res_model` is false).
This behavior happens because of this inverse compute: https://github.com/odoo/enterprise/blob/b4201e6b422e5b0bde1f04db37bcda4941d0665f/documents/models/document.py#L97-L104
opw-3119669
closesodoo/odoo#113299
X-original-commit: 6839abc79a947e30750ec535058828c190c18955
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
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
If the business is incorporated, both these fields must be present.
We don't have a field to know whether the business is incorporated,
but in any case the fields must be both present or not present.
opw-3127832
closesodoo/odoo#112366
X-original-commit: b3de98d4dd248f56461f735a6cae143296a96a0a
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Withholding
-------------------------------
Italian invoices may have a special fiscal feature which is "Ritenuta"
It means "withholding" and we implement it as a tax. The Withholding's
main use case is for professional consultants who can ask their
services' buyer to pay their income taxes on their behalf. This way, the
invoice lines will have a negative tax, and the buyer will not all the
money that is billed. The withheld amount will be sent to the tax
collector by the buyer at a later time. Professionals have any threshold
of how much money can be withhold in an year.
We added two fields to account.tax, l10n_it_withholding_type and
l10n_it_withholding_reason, for EDI import/export purposes. New taxes
with those fields filled out and a tax group have been added. The view
has been updated, to see the fields, the tax amount must be negative.
In the EDI import, the new DatiRitenuta tag is now read and handled. The
correct l10n_it_withholding_type tax must be found, or a message is
logged to the invoice chatter.
Pension fund
-------------------------------
Under Italian fiscal rules, there are cases in which professionals may
ask the buyer of their services to pay income taxes on the invoice
itself, and that's managed withholding taxes. In addition to that, the
buyer may also be asked to pay for the seller's national pension fund,
as a percentage of the invoice's total. This information needs to be
imported/exported through the EDI
Ticket link: https://www.odoo.com/web#id=2936606&model=project.task
Task link: https://www.odoo.com/web#id=2903280&model=project.task
v14 Community PR: https://github.com/odoo/odoo/pull/96930
v14 Enterprise PR: https://github.com/odoo/enterprise/pull/33083
task-2903280
opw-2936606
closesodoo/odoo#111800
Forward-port-of: odoo/odoo#102527
X-original-commit: 2525103f200b8bb13ea78eaa28f2135ed5bba755
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Following odoo/odoo@44a4cdb, account.edi.document `attachment_id`
now is restricted, so force getting it's value as superuser.
closesodoo/odoo#111839
X-original-commit: 98ae03c2a2e677643484b1988e3fc80fb8d85fc1
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
An attachment has complex access rights. If there is no res_model/res_id, the access rights are admin (not exactly but let's say that).
When an EDI like Facturx/E-FFF generates an attachment not linked to any model, you don't have access to it except if you are admin.
However, here we have a security issue since everyone is able to write any 'id' on the 'attachment_id' field.
If you do that using Facturx, knowing this EDI will embed its attachment inside the invoice PDF report in sudo mode, you have now a way to extract any attachment from the database including the ones you shouldn't have access to.
Furthermore, a different api introduced by OWL makes the form view of account.edi.document popping from the one2many inside the invoice form.
Instead of "options={'no_open': '1'}", the new api is now to put directly "no_open='1'" on the root node.
If you combine both issues above, you currently have a way to extract any 'attachment_id' from the database and odoo is kind enough to give you the form view to do it.
closesodoo/odoo#111210
Solution: "account.edi.document.attachment_id" is now accessible to the admin only.
X-original-commit: 44a4cdb3944a4b722dcfbca5e2947a4372b8501d
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Dates in FatturaPA are in ISO 8601 date format: `[-]CCYY-MM-DD[Z|(+|-)hh:mm]`
Data like `2021-01-01z` or `2021-02-05+01:00` did break the checks.
closesodoo/odoo#109838
X-original-commit: 9e50fa08a74fa842aa3a2f37dfe5b38707a50cba
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
The EDI cron was broken since we applied the batching to the EDI documents processing in this PR: #99227
Now we enable processing multiple invoices at a time.
closesodoo/odoo#109699
X-original-commit: 2e37dfcc22424a61127571254dc09eb615a09eb1
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
- [IMP] l10n_it_edi: Tax exemption kind N7 description
New specs from October 1st 2022:
https://www.doxee.com/it/blog/fatturazione-elettronica/nuove-specifiche-tecniche-per-la-fattura-elettronica-2022-in-vigore-dal-1-ottobre/
The description of Tax Exemption kind N7 is changed to:
"IVA assolta in altro stato UE (prestazione di servizi
di telecomunicazioni, tele-radiodiffusione ed elettronici
ex art. 7-octies, comma 1 lett. a, b, art. 74-sexies DPR 633/72)"
Courtesy of Tony Mascii
- [FIX] l10n_it_edi: San Marino self-invoice from paper
San Marino is a very small country completely enclosed in Italy.
That country has special agreements with Italian as far as
e-invoicing is concerned.
When a paper invoice is received from San Marino, any Italian
company has the responsability to submit that invoice integrated
with Italian tax information to the Tax Agency, indicating in the
e-invoice filling the Document Type field with the special value 'TD28'.
- [IMP] l10n_it: Round globally by default in Italian CoA
The Italian Tax Agency (and therefore any business in Italy)
makes it mandatory to compute roundings based on a Round Globally policy.
Invoices not rounded globally are refused by Italian EDI.
- [IMP] l10n_it, l10n_it_edi, l10n_it_stock_ddt: Deferred invoice
Context:
The Italian State allows making one invoice per month
to recurrent clients buying goods several times a month.
This process is called "Deferred invoice" (Fattura differita)
in contrast to Direct invoice (Fattura immediata).
To enable this, the vendor must issue one Transport Document
per client delivery. The Document is attached to the goods themselves.
Many Transport Documents (DDTs) delivered can then be invoiced together
in a single invoice up to the 15th day of the following month.
This task allows the Italian EDI to correctly communicate
the Deferred invoices data to the Tax Authority
An export test has been added.
Official FAQ (n.21) - https://www.agenziaentrate.gov.it/portale/documents/20143/287582/15+Tutte+le+faq+%28aggiornate+al+11+maggio+2021%29+.pdf/2db944b9-22c3-fa80-7c14-dfa0bcbbd65e
Reference task link: https://www.odoo.com/web#model=project.task&id=1914640closesodoo/odoo#108230
X-original-commit: 87dd99e8abd8281fd81164d1f007ceaff3123834
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
PURPOSE
Purpose of this task is to cleanup attachment management done in generic mail
models overrides and move it in account as model overrides.
SPECIFICATIONS
Account_edi and various l10n submodules hold some custom code to generate and
handle EDI attachments. It is used to add attachments linked using AccountMove
specific 'edi_document_ids' field when sending emails based on templates.
Currently MailTemplate is overridden in accounting modules to hold code related
to AccountMove and AccountEdiDocument attachments manipulation. This is linked
to EDI and report naming, not mail specific. This should therefore not be
implemented at template level, but in those specific models.
For that purpose we introduce a method in MailThread that allow to handle
attachments when being in a template context. An override in account_edi
allows to implement its specific behavior.
By the way an old docstring in l10n_it_edi that was quite unrelated to the
override is also removed, as it was more confusing than helping.
Task-2792146 (Mail: Move model-dependent code from composer / template)
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#106658
Non EU vendor bills are sent to the Tax Agency as self-invoices,
so the partner actually is the seller, but the same checks on the
VAT must apply as it was the buyer.
Task: https://www.odoo.com/web#id=3010849&model=project.task
opw-3010849
closesodoo/odoo#106312
X-original-commit: 8c18b870ecc04314380fcdb6b61179de78e28703
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
TD02 is the only document type in l10n_it_edi that requires
the invoice to be a downpayment, but this doesn't mean that
downpayments are limited to it.
The condition has been adapted to allow downpayments to fall
under the other document types cases.
opw-3033403
closesodoo/odoo#104242
X-original-commit: 197dbf7a8d14b619d19ff5904eb07d53c1fd97d2
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Before: it won't work with extension in uppercase: .XML or .XML.P7M
We put ?i: in the regex so that part would be matched case insensitively
opw-2703669
closesodoo/odoo#102766
X-original-commit: 397e9f49c1806d2188a2e0d2e3cf32eeedf91e4b
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Of course, for an XML that is imported or exported the type of the
invoice will be different: vendor bill for import, customer invoice
for export e.g. But in the case of vendor bill reverse charge we create
the XML from the vendor bill, but we did not think straight about how
it should be imported.
We did not expect it to be imported, but somehow in a database it was the
case and we see it is actually corresponding to a vendor bill coming from
a foreign vendor, so it would be better as well to import it as such. Also
those types are only needed as vendor bills/refunds in our system. (only
support bill for the moment)
opw-2977126
closesodoo/odoo#102693
X-original-commit: 75a936eaf0202b468534add610afba8976a91b59
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Add a new method `_get_move_applicability` allowing to trigger the EDI on any journal entry, using the custom functions you want.
closesodoo/odoo#101985
X-original-commit: 0e5626ca5126e6fea7fb95b694229948540764d7
Related: odoo/enterprise#32212
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
The quantities on l10n_it_edi can be positive or negative.
Since the government disallows negative quanities, the xml template
specifies the quantity as absolute. The unit price is calculated, and
will be calculated correctly regardless of whether the quantity is
positive or negative.
This constraint can be removed as it is no longer required.
The check being removed was introduced in the commit: d643164
The fixes that allowed for negative quantites in this context were made
in: 2eb72e24fdc2c21075e188d9c62ba3bc6b416805
which was part of the PR: https://github.com/odoo/odoo/pull/97907closesodoo/odoo#101806
X-original-commit: 806266fe00de2fb0ce85f8cc603434dbc7b2a1d5
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Before this fix negative aml unit prices were systematically set to positive in the edi xml generating inconsistencies.
Manual forwardport of d31d562
closesodoo/odoo#101493
Task: opw-2963947
X-original-commit: 0954550e55ce35445a198006872a12298cd77d5b
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
The `test_mode` flag was removed in 22e04c6d56closesodoo/odoo#100042
X-original-commit: b0e960bbe142f6d00b444f78fe11e63b83cecb29
Signed-off-by: William André (wan) <wan@odoo.com>
At present there are two methods of sending/receiving electronic
invoices in odoo.
The first, contained within l10n_it_edi, sends and receives the xml via
a verified email known as 'PEC mail', with use of a fetchmail server. It
is no longer the prefered method.
The second, contained within l10n_it_edi_sdicoop, sends and receives the
xml via a proxy hosted by odoo. The proxy server in turncommunicates
with the 'sdicoop' system. This has become the prefered method.
The 'PEC mail' method of sending/receiving invoices will no longer be
supported. The contents of l10n_it_edi_sdicoop will be merged into
l10n_it_edi and the fields, views, methods, and dependencies
exclussively associated with the old 'PEC mail' are deleted.
There are many instances in which a function was provided in l10n_it_edi
that worked through the fetchmail edi system, and was then overriden in
l10n_it_edi_sdicoop. In this case the content of the overriden method
is replaced with the content of the method that has overriden it.
The manifest has been updated to reflect the slight change in the file
structure (the addition of cron.xml and res_config_settings_views.xml to
the data and views folders respectively). The fetchmail dependency has
also been removed from the manifest.
The tests have been updated to match the restructuring of the module.
The i18n files have been altered to include the relevant translations
from the l10n_it_edi_sdicoop module, and the translation terms that are
made redundant are deleted.
closesodoo/odoo#82581
Related: odoo/upgrade#3828
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
The current taxes computation method defined in account_edi has been moved to account on account.tax to be usable on any models.
closesodoo/odoo#99401
Related: odoo/enterprise#30967
Signed-off-by: Laurent Smet <las@odoo.com>
Prevent archiving in-use mail servers by displaying an error message that
lists where it is still used, allowing to easily identify what need to be
updated before being able to archive the mail server.
Additionally,
- prevent the use of archived server as a fall-safe
- when duplicating a mailing with an archived mail server, replace mail
server by the default one
Detailed explanation:
1. A check has been added that raise an exception when trying to connect to the
smtp server or send an email when the server is archived.
With that solution,
- testing the connection of an archived server displays an error telling that
an archived server cannot be used.
- if a mail is still sent with an archived server, mail are in error :
"Connection failed (outgoing mail server problem)"
This fail-safe ensures that no mail will be sent through an archived mail server
and that the user will get some feedback about it.
The same fail-safe for the incoming mail server has been added.
Notes:
- the connection will outlive the archiving of a mail server still allowing
to send email through the archived server until the connection is closed. But
connection are not kept for long so this shouldn't be a problem.
- it cannot be tested because the connect method return immediately in test
mode.
2. When a mail server is archived, an user error is raised if it is in-use.
The implementation relies on each module to override the method
"_active_usages_compute" in "ir_mail_server" to complete the list with
user-friendly message describing the active elements that could send mail
through the mail server. This has been implemented for:
- l10n_it_edi: server used to send e-invoice
- mail: optional server configured for template
- mass_mailing:
-- default mail server
-- active server configured for mailing
Mail server are referenced in other elements but are not active anymore, it is
just for temporary or history purpose. Those references doesn’t prevent the
archiving of the mail server:
- mail_message
- wizard survey_invite and compose_message
- res_config_settings
Task-2821516
closesodoo/odoo#91240
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit adapts account's model to the new report engine introduced for v16, and updates the data files accordingly.
account.report model is now declared in community, together with the other models used by the reporting. This is done so that the tax tags can properly be created by the tax report and used on tax templates. All the actual computation logic stays in enterprise.
See enterprise commit for full details.
Task 2524389
Part-of: odoo/odoo#94125
Currently, the EDI attachments *content* is passed to the Send & Print wizard.
Then, the wizard re-creates these attachments and link them to itself. At the
end of the flow, when clicking 'Send & Print' button on the 'Send & Print' wizard,
the attachments of the wizard are copied on the move.
Thus, the EDI attachments are duplicated.
Passing the ids of the EDI attachments rather than the content solved the issue,
since they are simply linked to the wizard, without being re-created.
task-2957823
closesodoo/odoo#98447
Related: odoo/enterprise#30596
Signed-off-by: Laurent Smet <las@odoo.com>
The invoice line and tax line sections of the Italian edi should be
reported in euros. Due to this, the line.balance is used instead of the
line.price_subtotal when calculating the PrezzoTotale' (price_subtotal)
of the line. The amount is then made negative if the line is
representing a completed downpayment, or if it is a negative line on a
reverse charge refund.
The unit price is calculated mostly the same way (using the new
price_subtotal value). If the line has a discount of 100% then the unit
price of the line is computed from the line.price_unit, by converting it
to euros using the _convert method on the invoice currency.
The exchange rate and the original currency / original currency amount
are listed on the lines using he 'AltriDatiGestionali' elements in the
xml.
A mistake with the way a reverse charge invoice was calculated has been
corrected too. Before reverse charge was determined by the document type
being 'TD16', 'TD17' or 'TD18'. Where instead it should be 'TD17',
'TD18' or 'TD19'.
A typo (inovice -> invoice) has also be corrected in the tests.
closesodoo/odoo#98534
Ticket-id: 2952018
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Several fields in the l10n_it_edi XML template are adapted fairly often
as work progresses on l10n_it_edi/l10n_it_edi_sdicoop. This refactor
moves the computation of these field to the python code in
_prepare_fattura_pa_export_values.
The computation is done for the:
(DettaglioLinee) Invoice Lines:
NumeroLinea (line number), Descrizione (description),
PrezzoUnitario (unit price), PrezzoTotale (line subtotal),
(DatiRiepilogo) Tax Lines:
Arrotondamento (tax rounding),
ImponibileImporto (tax base), Imposta (tax amount).
These are computed by the new functions
_l10n_it_edi_prepare_line_details and _l10n_it_edi_prepare_tax_details
and returned as lists of dictionaries, which are passed to the function
that renders the template.
The template is modified on the above fields, to reference the above
dictionaries, instead of performing the computation in situ.
Moving the computation of these fields to the python code has the
benefit of:
a) easier, more concise computation of these terms
b) not requiring users to upgrade the l10n_it_edi module in order to
benefit from future changes to these fields (they will only need to
upgrade once).
Part-of: odoo/odoo#98534
The edi system does not properly represent the type when exporting
downpayment invoices. The type (TipoDocumento) should be TD02, and
instead it is TD04.
To fix this, a new key is added to the _l10n_it_document_type_mapping
function that maps invoices for which _is_downpayment is true to the
document type 'TD02'.
The description for the line is also modified to include references to
the downpayment invoice if the line is linked to a downpayment. This is
done using the _get_downpayment_lines method introduced in 8dcc25bc776.
Ticket-id: 2924728
Part-of: odoo/odoo#98534
Gorash