From July 2022, External Reverse Charge (for Import/Export)
has to be sent through the SdI to the Agenzia delle entrate.
Exports will be 0% VAT
(Reverse charged to the buyer)
Imports will have a -100%/+100% VAT tax
(We are the buyers, and in charge of VAT)
See specification in the Task description.
Task: https://www.odoo.com/web#id=2823646&model=project.task
opw-2823646
closesodoo/odoo#95372
X-original-commit: 2eb8b2f5bcef8ddfbc3ad83219368575174918d0
Related: odoo/enterprise#29138
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
When the cron is fetching the xml from the database, an empty invoice
with the xml as an attachment is created. The reason for this is so
that, if the import fails, there is at least a file accessible on the
invoice for the purposes of debugging.
When the cron's fetching function loops through the proxy users for each
company, fetching the results from the proxy server for each company in
turn. However when the empty invoice is created, the company is not
provided, and thus the context company is used (that of the cron), which
is not necessarily correct. This commit uses the company of the proxy to
create the empty invoice (which in turn selects the correct journal etc.
for the empty invoice).
closesodoo/odoo#92830
Ticket-id: 2854284
X-original-commit: a19cdf82f3276f84fba2961fbd82a5a1a2f7844e
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
When we receive status changes of sent invoices, we send an
ack message to the proxy afterwards to indicate we received it
correctly.
However, as awaiting_outcome is the initial state for which no
message about the invoice state was received from the gov, we do
not need to ack it as it just says "we are still waiting for the
first msg from the gov"
In a scenario:
Normal flow:
- Odoo instance sends invoice to proxy, proxy to gov, which sends back transaction_id
- On the proxy, the state of the transaction_id is awaiting_outcome
- The gov sends a message back to the proxy that the invoice is approved (directly to the server), so the state becomes "approved"
- The odoo instance asks for the status, receives the "approved" message and then tells the proxy he received it
- The proxy deletes the "approved" message
What we want to avoid:
- Odoo instance sends the invoice
- Proxy: awaiting_outcome
- Odoo instance checks the status and the server returns "awaiting_outcome"
- The gov sends a new message
- The Odoo instance acks and says he received the msg (there is actually no message associated)
- The new message from the government gets deleted.
closesodoo/odoo#91608
X-original-commit: 7d992af9561c499ef1912453f3b697bad18e441f
Signed-off-by: William André (wan) <wan@odoo.com>
First thing is that when you send an invoice to PA in test/production,
it should be considered as sent after the xml is generated as we do not
have the functionality to send sign invoices yet.
We added a test for posting the invoice when the invoice partner has a
l10n_it_pa_index (and it is of length 6).
Alos, when the proxy user is a 'demo' user, creates a
traceback. The solution is to only add the demo response to those that
would have been sent to the iap server otherwise.
We also avoid doing a call to the IAP server if there are no invoices to be
sent (e.g. because they all go to the PA)
opw-2807213
closesodoo/odoo#91419
X-original-commit: 2221f0145607e4cd0880e7435b637f620d15cecf
Signed-off-by: William André (wan) <wan@odoo.com>
The problem is that we have a limited space in the filename for
differentiating one file from the other. Only the five characters at the
end of the filename are used, this looks like:
<CODICE_FISCALE>_NNNNN.xml (where N is a character a-zA-Z0-9)
The current version utilises the invoice id to get the unique filename.
This has a couple of problems:
- It doesn't utilise the (lowercase) a-z characters
- Draft invoices still have invoice ids
- In a multicompany environment, the invoice ids are not unique to the
company (i.e. another company creating an invoice will increment the
value of the invoice.id on your company)
These above problems mean that we're not currently utilising the hashing
space available to us by the characters of the filename.
The solution is to utilise an ir.sequence, that is used to determine
each filename. This has the benefit of being editable by the user, so if
they continue to get duplications, they can offset them by adjusting the
value of the sequence's next number.
A more descriptive error message and its translation term have also been
added for when a filename duplication occurs.
relates to
closesodoo/odoo#88324
Task-id: 2813957
Ticket-id: 2788927
X-original-commit: d0f8ca31bfc761b09cda3be1c75732a56f031f2c
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Italian translation added.
Add string parameter to the fields so that the filter names are more
usable. Since the filter names are taken automatically from the field
names, the string paramter allows us to change the filter names:
L10N It Edi Transaction -> FatturaPA Transaction
L10N It Edi Attachment -> FatturaPA Attachment
L10N It Send State -> FatturaPA Send State
closesodoo/odoo#87711
Task-id: 2795241
X-original-commit: 6473aa55f08d130119aceb15deee68eb041bf25e
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Duplicate sending should be considered as positive outcome.
We also post a message on the invoice to make the user aware.
closesodoo/odoo#87292
X-original-commit: b49210bdf507850306d6f19306ea8cd6a91e3316
Signed-off-by: Josse Colpaert <jco@odoo.com>
To properly register account_edi_proxy_client.user when saving the res
config settings page, the radio buttons needed to be modified, and the
'register' button was adapted to be a checkbox instead.
Registering multiple demo proxy clients lead to an error, as it is
asserted that id_client should be unique, and the demo client has
'id_client': 'demo'.
To fix this, the id of a demo client is 'demo' + the company id.
Searching for demo clients is adapted to search on the first four
characters.
closesodoo/odoo#85794
X-original-commit: 54e54466f0858d4b19fa8f61ff2b927e00f8f5a8
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
- Sometimes the refresh_token is not saved in the db because the code
after it fails (timeout). We also want to avoid 2 processes
trying to renew the token at the same time (=> avoid desynchronization
of the refresh_token)
So, we added a locking mechanism and do a commit after we refresh the
token.
- If we have very big invoices to receive, they do not get imported into
the database. At the moment we risk timeouts.
Our solution is to do a lot of intermediary commits and we link it
to a temporary account_move before doing the import logic and maybe
putting it into the definitive one.
closesodoo/odoo#85372
X-original-commit: ce47d09c05e4bcc91ee4de68db3a7a471bcb4df8
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
In the B2B case, after a MancataConsegna, the invoice is considered
issued, but the delivery is failed.
In the B2G case, the Exchange System will retry to send it for 10 days
and inform the Public Administration. After 10 days, it will be
considered issued but not delivered.
In both cases of failure, the user is required to send the invoice
through other means than the Exchange System.
Ref (IT): https://www.datalog.it/fattura-elettronica-cosa-fare-in-caso-di-mancata-consegnaclosesodoo/odoo#85100
X-original-commit: e8e08aba971cbf688b09f39cf3b3e4bc75641e84
Signed-off-by: Florian Gilbert <flg@odoo.com>
- A new flag is added to the Setting (l10n_it_edi_sdicoop_demo_mode)
that is computed from the ir.config_parameter
'account_edi_proxy_client.demo'.
If the flag is 'demo', Odoo will not send invoices through the EDI,
if the flag is 'test', Odoo will send invoices to an IAP test server
instance that operates with a test SDICoop service
if the flag is 'prod', Odoo will send invoices to production IAP,
that routes them to the official SDICoop service.
- Some minor UI rework for the EDI parameters on res.company
The EDI settings in the res_company form, under the
'Electronic Invoicing' tab, must stay on the left
closesodoo/odoo#84925
X-original-commit: c5d049c55d21f9885e79182df2bd5f433c5bb782
Signed-off-by: Josse Colpaert <jco@odoo.com>
Sometimes when importing products that share the same internal reference code (default_code) the _import_fattura_pa function will throw an expected singleton error. This is because, in order to find the product for the line of the invoice, it will search for the product reference code (e.g. [CONS_0001]), which is not necessarily unique.
I've set the limit to one on the search to fix the immediate error for
now, but I will add more logic to better search for the relevant product
in a future commit.
closesodoo/odoo#84826
Task-id: 2764978
X-original-commit: aae609915cb1f76c32c518ff8959674853633f55
Signed-off-by: Josse Colpaert <jco@odoo.com>
Set the l10n_it_edi_transaction value on the invoice to false after
receiving notificaScarto from the edi. This is so that the methods
associated with posting the invoice will detect it again and process it
for posting.
Task-id: 2764978
X-original-commit: 925fc0ff3914e83ddaac4fd5f6c1bdb7b4b2c68b
Part-of: odoo/odoo#84826
This commit adapts the l10n_it_edi_sdicoop and account_edi_proxy_client
modules to make use of the existing config param
'account_edi_proxy_client.demo' in order to target the correct odoo iap
server for italian edi requests.
When the config param is set to:
'prod' or False (when the config param doesn't exist): Target the
production odoo iap server (by default), which submits and collects edi from the
production channel. Though if the config parameter
'account_edi_proxy_client.edi_server_url' exists, we use the value
provided there instead.
'test': Target the test odoo iap server, which submits and collects edi
from the test channel
'demo' or anything else not above: don't send anything, and simulate the
flow of italian edi submissions in odoo
task-id 2764978
X-original-commit: 32683b70a34a900a112d19bf780446a973753ae5
Part-of: odoo/odoo#84826
When we ack a file for having correctly received the response e.g.,
the file is deleted on the server and will not have a file key in the reponse,
at least before the server itself will have a new response to share.
Before, it would traceback, while now, we do nothing. (as we are still waiting)
Also, when we get the notice that the term of 2 weeks is passed, it means
it is successfull.
Also, for the batching we had a traceback, because it was possible to have
a batching mixing step 1 and step 2, which fails doing invoices.l10n_it_edi_transaction
So we added whether there is a tranaction or not in the batch key.
opw-2703669
closesodoo/odoo#82358
X-original-commit: c20e3b95a82fd35c1dcefd159525f59e2c255e9d
Signed-off-by: William André (wan) <wan@odoo.com>
When using EDI, documents often fail to be submitted to the relevant API. This provides the ability to generate and download the XML
Task-2669041
closesodoo/odoo#80088
X-original-commit: 6eba7935c4d4f0fef5e1e7ad9b1d7726aa3db109
Related: odoo/enterprise#22392
Signed-off-by: Laurent Smet <las@openerp.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
There is a test_mode to allow experimentation on the IAP server.
To be able to switch between the two, we need to make the
SERVER_URL configurable.
closesodoo/odoo#77977
X-original-commit: 11be1b25c60ae27a5e8078802883a1db867a6452
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Paolo Gatti <lordkrandel@users.noreply.github.com>
When encoding a string or bytes with base64,
the resulting byte string must be decoded
to get the string back.
* `addons/account_edi_proxy_client/models/account_edi_proxy_user.py`
AccountEdiProxyUser._register_proxy_user()
* `addons/l10n_it_edi/models/account_invoice.py`
AccountMove._prepare_fatturapa_export_values()
* `addons/l10n_it_edi_sdicoop/models/account_edi_format.py`
AccountEdiFormat._l10n_it_post_invoices_step_1()
X-original-commit: 3a705d93543e910b6af4b3b4aa53c523f367782a
Part-of: odoo/odoo#77977
When duplicating an invoice, a new edi should be generated, therefore l10n_it_edi_transaction and l10n_it_edi_attachment_id should by copy=False.
closesodoo/odoo#74799
X-original-commit: 7ea86c2662369aa8d09e6bafaf2fe024e8f57f40
Signed-off-by: Josse Colpaert <jco@openerp.com>
In order to limit encoding decoding, the _render method returns a
unicode string in the markup safe object instead of a MarkupSafeBytes
closesodoo/odoo#68299
Related: odoo/upgrade#2454
Related: odoo/enterprise#17270
Signed-off-by: Antony Lesuisse (al) <al@openerp.com>
Codice Fiscale can be 16 length (letters + digits) for physical people.
Codice Fiscale can be 11 digits prefixed or not with 'IT' for companies.
An error is raised if the codice fiscale is not saved in the correct format. When registering to l10n_it_edi_proxy, we try to normalize the Codice Fiscale if possible.
Also, when entering the vat in the partner, the Codice Fiscale is automatically set normalized.
closesodoo/odoo#73774
X-original-commit: 3741e141e5a468b8ce0413f4f7d7fc05751b0c1b
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
When demo data is installed, requests to the proxy are blocked and we simulate a successful result by default and the proxy.
- an account_edi_proxy_client.user is created even though it's counterpart on the proxy doesn't exist.
- sending invoices is successfull and checking the status return simulate the invoice was accepted.
- the cron checking for incoming invoice returns immediatly and no new invoice is created.
closesodoo/odoo#72092
X-original-commit: 7be2e136c5e7a62d440f8323f36076d486976825
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
- Allows to send and receives invoices from the fatturaPA network via the webservice (SdiCoop).
- PEC mail is disabled when SdiCoop is disabled.
- Added account_edi_proxy_client, a registered user on the proxy (see l10n_it_edi_proxy on iap-apps), that features encryption. Generates a asymmetric keys, and keep the private_key to be able to decrypt file sent by the proxy (which it encrypted with the public key).
- Added a generic way to sign the requests made to the proxy.
TASK ID 2358882
closesodoo/odoo#71928
X-original-commit: 4c8afc413a8982b2e77712eab7cf7ddac9f3851f
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
Paolo (pgi)