When creating a new company with the italian fiscal localization, the
tax "0% EU" is not instanciated properly

Steps to reproduce:
1. Install Accounting and module l10n_it_edi
2. Create a new company and select it
3. Go to Settings > Accounting > Fiscal Localization, set it to `Italy -
   Generic Chart of Accounts` and save
4. Go to Accounting > Configuration > Taxes and open tax "0% EU"
5. The fields for the italian exoneration are not properly set, they
   should have the same values as the same tax for company "IT Company"
   of the demo data

Solution:
When we set the company chart template, update tax "0% EU" with the
correct values

opw-3414593

closes odoo/odoo#131996

Signed-off-by: Olivier Colson (oco) <oco@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().

We also include a test to check that the XML is correctly generated for
credit notes.

Back-port of #121933

opw-3316300

closes odoo/odoo#122928

Signed-off-by: Josse Colpaert <jco@odoo.com>

- l10n_it_edi_sdicoop: 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

closes odoo/odoo#112845

Signed-off-by: Josse Colpaert <jco@odoo.com>

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

closes odoo/odoo#112052

Signed-off-by: Josse Colpaert <jco@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.

closes odoo/odoo#109712

Signed-off-by: Josse Colpaert <jco@odoo.com>

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

closes odoo/odoo#104779

Signed-off-by: Josse Colpaert <jco@odoo.com>

When the seller is foreign, the Fiscal Regime of the seller must
be set to 'RF18', as per:
https://www.fattura24.com/manuale/altri-documenti/autofattura-fornitori/

Task: https://www.odoo.com/web#id=3010849&model=project.task


opw-3010849

closes odoo/odoo#104780

Signed-off-by: Josse Colpaert <jco@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

closes odoo/odoo#103008

Signed-off-by: Josse Colpaert <jco@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

closes odoo/odoo#100465

Signed-off-by: Quentin De Paoli <qdp@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

closes odoo/odoo#100530

Signed-off-by: Quentin De Paoli <qdp@odoo.com>

Due to a recent fix (fae69975d8c5e2019acda1745626e42fd56cba8e), the
price subtotal of the downpayment lines (which, on the final invoice,
should be negative) are positive in the generated xml.

To fix this, we remove the condition that inverts the downpayment line
value. Since the correct (negative) value of the downpayment lines is
ascertained. Only the value of the reverse charge refund lines should
remain inverted, since in this case, the price subtotal is positive, but
the amount on the document should be negative.

closes odoo/odoo#101289

Signed-off-by: Josse Colpaert <jco@odoo.com>

Before this fix negative aml unit prices were systematically set to positive in the edi xml generating inconsistencies.

closes odoo/odoo#100598

Task: opw-2963947
Signed-off-by: Josse Colpaert <jco@odoo.com>

The default value for ``test_mode`` on ``_post_invoice_edi`` is False,
so, if any of this modules is installed, the test_mode is overwrite to
False.

Now added missing parameter to avoid error on some tests.

closes odoo/odoo#99881

Signed-off-by: William André (wan) <wan@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.

closes odoo/odoo#97907

Ticket-id: 2952018
Signed-off-by: Josse Colpaert <jco@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#97907

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#97907

According to
www.agenziaentrate.gov.it/portale/web/guest/schede/istanze/richiesta-ts_cf/informazioni-codificazione-pf

The tax identification number of natural persons
consists of an alphanumeric expression of sixteen characters.

The first fifteen characters are indicative of the master data
of each individual in the following order:

- 3 alphabetic characters for the surname;
- 3 alphabetic characters for the first name;
- 2 numeric characters for the year of birth;
- 1 alphabetic character for the month of birth;
- 2 numeric characters for the day of birth and sex;
- 4 characters, 1 alphabetic and 3 numeric for the Italian municipality
  or foreign state of birth.
The sixteenth character, alphabetic, serves as a control.

The main fix is about this part:

When two or more individuals have master data generating
the same tax code (homocodes), the tax code is differentiated
for each of them. For this purpose, systematic substitutions
of one or more digits starting from the right one are made
within the seven numeric characters contained in the code
with corresponding alphabetic characters according to the
following table:

0 = L 4 = Q 8 = U
1 = M 5 = R 9 = V
2 = N 6 = S
3 = P 7 = T

Also the check for iva number format was incomplete.
Indeed, The three penultimate digits correspond to the region of the
VAT office and must be between 001 and 100 inclusive,
or equal to 120, 121, 888 or 999.

We use the stdnum library's methods for the validation of fiscal code
and iva number format.

opw-2797408

closes odoo/odoo#95594

Signed-off-by: Josse Colpaert <jco@odoo.com>

When issuing a refund for a reverse charge bill, the document type
should be the same as the parent bill type (either TD16, TD17 or TD18,
rather than TD04), and the values of the lines and totals should be
negative.

To fix this the values are made negative dependent upon whether the
invoice is a 'rc_refund' as in a "reverse charge refund". The way that
the document type is ascertained is also changed in order to include the
'in_refund' (for the case of the reverse charge refund).

The way document_total (ImportoTotaleDocumento) has been made
conditionally negative in the case when the invoice is a reverse charge
refund.

A test has been added for the reverse charge refund case, and the test
taxes have been adapted so that the correct tags are being used (and so
that tags are used on the refund lines).

closes odoo/odoo#97263

Ticket-id: 2936967
Signed-off-by: Josse Colpaert <jco@odoo.com>

Install Documents
Open Settings > Documents, enable 'Accounting' files centralization
Configure 'Journals' with a single line
- Journal -> Vendor Bills
- Workspace -> Finance / Supplier Invoices
Now in go to Accounting>Vendor>Bills
Upload an xml representing a vendor bill, including an attachment
encoded in the <Allegati> tag
Open created bill

Traceback. The error is caused by the attachment included in the xml
registered without res_id/res_model.
In the document flow the attachment will receive a res_id, but not the
res_model, causing the traceback when retrieving the attachment

opw-2919610

closes odoo/odoo#97061

Signed-off-by: Josse Colpaert <jco@odoo.com>

In the XML, on the field holds the untaxed amount but it should have the taxed amount.
The field inside the xml correctly takes the total amount of the
invoice, but on the invoice in Odoo when using a RC tax, the tax amount
is 0 in Odoo, so the total amount will be as it is untaxed on the XML.
That's because the repartition lines are +100%/-100% distributed, but in
the self-invoice they must be exported as +100%, so we re-add them to
the total.

Task link: https://www.odoo.com/web#id=2936967&model=project.task


opw-2936967

closes odoo/odoo#96686

Signed-off-by: Josse Colpaert <jco@odoo.com>

For zero percent taxes, when the repartition lines are defined as 0% of
the 0% tax, the DatiReipilogo elements are not generated.

This is because of the recent addition of a filter to the calling of the
_prepare_edi_tax_details inside of the function that generates the
values for the template. The filter specifies that the tax data
retrieved relates to repartition lines with a percentage > 0. This
excludes taxes that are 0% of a 0% tax (which would be the same as a
repartition line of 100% of a 0% tax).

The solution is to change the > to >= so that these 0% tax repartition
lines are included.

A test is created with an invoice with two 0% taxes. One tax has a 100%
tax repartition line, and one has a 0% tax repartition line. With the
fix, there should be DatiReipilogo for both taxes in the xml.

The reverse_charge_invoice tests are also fixed in order to ignore the
invoice name (which will change depending on how many invoices are
posted in the previous tests).

closes odoo/odoo#95816

Ticket-id: 2909394
Signed-off-by: Josse Colpaert <jco@odoo.com>

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

closes odoo/odoo#94406

Related: odoo/enterprise#28798
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>

When adjusting the currency rates, the amounts in the edi invoice become
incorrect and the Italian EDI system rejects them (due to contraints on
the content of these fields).

This commit changes the referenced amount to the 'amount_currency' (for
the taxes and the base) for the fields in the EDI templates.

closes odoo/odoo#93927

Signed-off-by: Josse Colpaert <jco@odoo.com>

This commit aims at unifying the UBL formats for invoices and credit notes.

Starting from the work of LAS, the module account_edi_ubl_cii contains the templates for UBL and CII,
and provides inheritance for UBL: UBL 2.0 < UBL 2.1 < UBL Bis 3.
It contains also the formats E-FFF, EHF3 (fully covered by Bis 3), XRechnung (in UBL), Factur-x (the only one in CII).
All these formats are also improved to pass the ecosio validator and/or the country specific validator
(for Factur-x: the validator from the FNFE, and Chorus Pro).

Note that the xml files generated contain the pdf of the invoice/credit note encoded in base64.
An xml file alone imported in Odoo will thus automatically retrieve the pdf.

Before generating the xml files, we now also check a series of known constraints and possibly display
a warning on top of the move view if some are not enforced (the xml file is generated anyway but it might not be valid).

Tests were required: a new module was needed with dependency to the tested l10n: l10n_account_edi_ubl_cii_tests.
The prefix "l10n_" prevents runbot from launching the tests everytime.

Backport of: https://github.com/odoo/odoo/pull/88027



closes odoo/odoo#83849

Task: 2628093
Signed-off-by: Laurent Smet <las@odoo.com>

In 7dd5437a the usage of imagelib was changed to match the one of
general fetchmail so the flag sent to IMAP server was (\Seen) and not
\Seen which is often accepted but not always.

From recent reports, it seems that the method `uid` and `store` may have
some difference (base on using message-id rather than UID) so this
commit is reverting 7dd5437a and using the parenthesis around the flag
explicitely.

opw-2853609

closes odoo/odoo#93146

X-original-commit: 550f9e77
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

An error occurs when importing the Italian edi xml it the partner bank
account number is defined and the database is configured in such a way
that one partner has multiple res.partner.bank records, with the same
acc_number. This is possible in V14, since the constraint is:
'unique(sanitized_acc_number, company_id)'
meaning that the same bank account on the same partner can occur
multiple times (with different company_ids).
Since the domain of the search performed in the import function didn't
specify the company id or a limit, upon assigning the partner_bank_id
with the values from the search, an expected singleton error occurs.

This has been solved by altering the search domain to include only
partner bank accounts where the company id matches that of the invoice
or where the company id is None (which is technically possible, though
unlikely). A limit of one has been added to the search, and the results
are ordered by company_id, which will result in the res.partner.bank
with a company_id being selected before the one with no id.

This relates to a ticket:

closes odoo/odoo#92554

Task-id: 2854284
Signed-off-by: Josse Colpaert <jco@odoo.com>

The current problem is that the codice fiscale field is validated using
a regex that matches an alphanumeric code of 16 digits (that causes no
problems) and both a simple numeric code (of 11 digits) and an
alphanumeric code (of 13 digits, starting with the country code 'IT')
for businesses. The problem is that the systems that make use of the
codice fiscale code tend to utilise the former (i.e. the 11 digit code,
without the 'IT' prefix).

The filename for the EDI comprises a country code, the codice fiscale of
the company and a progressive number. When the codice fiscale is
completed as being eg. 'IT00465840031', the country code + codice
fiscale will be 'ITIT00465840031', which will be rejected by the edi
system (a single country code is expected).

This commit removes the 'IT' in the xml by utilising a function on the
template _l10n_it_normalize_codice_fiscale from the res.partner model.

related ticket-id: 2845341

closes odoo/odoo#90900

Signed-off-by: Josse Colpaert <jco@odoo.com>

This provides the possibility to import/export simplified invoices.
Currently, the import of simplified invoices would not work and the export of invoice without customer address would be blocked.
Simplified invoice will be able to be imported and exported if the customer address is incomplete, it's a domestic invoice and the total amount is below 400€

freeze_time was removed as it was unnecesarry and posting invoice would not be done directly as the invoicing date is in the future wrt the frozen time.

closes odoo/odoo#90052

Task: 2800967
Signed-off-by: Josse Colpaert <jco@odoo.com>

For an imap "PEC server" we will fetch mail and set \Seen flag according to
current value.

But the way imaplib was used seem to possibly cause an issue on some
particular mail providers.

Mailing RFC* gives example of adding flags with parenthesis around flag:

eg. "A003 STORE 2:4 +FLAGS (\Deleted)"

but we are sending these command wihtout parenthesis (which seems to be
working, but apparently not for some providers).

To fix this issue, we change how we use the API to do the same thing
than in fetchmail module that is a lot more battle tested (and from logs
is sending flags in parenthesis).

* https://datatracker.ietf.org/doc/html/rfc3501#section-6.4.6



fixing #89305
fixing #81443
opw-2714596

closes odoo/odoo#89357

X-original-commit: 7dd5437a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

The Italian edi system accepts utf-8 encoded documents, but actually the
contents of the fields have to be latin-1 encoded. Format-alphanumeric
should remove any non-latin1 characters and replace them with a ?

Several fields to are also truncated before the function is applied.
This is so that these fields better match the specification. This will
help to prevent edi rejections in the future.

A test is also included to test with a few lines that should / should
not be adapted in by the format_alphanumeric function. Along with the
addition of the test, the test partner italian_partner_a's is_company
field is changed to True, since the partner is a company. The expected
xml has been altered to match the changes to partner_a.

closes odoo/odoo#88816

Task-id: 2826424
Signed-off-by: Josse Colpaert <jco@odoo.com>

DatiPagamento is non mandatory, and it's contents 'DettaglioPagamento'
can be multiple (e.g. when there are payment terms, and amounts are
receivable upon different days). This commit adapts the DatiPagmento
section of the invoice template to not occur when the invoice is a
credit note (there is no sense in providing payment info for a credit
note) and creates a number of payment lines if there are multiple payments.

closes odoo/odoo#88754

Signed-off-by: Josse Colpaert <jco@odoo.com>

Step to reproduce :
	-set your company country in Italy
	-install accounting
	-install contacts
	-create a new individual contact
	-set the country address of this contact to Italy

Expected Behavior:
No problem

Current behavior:
Error message in function _l10n_it_normalize_codice_fiscale

Explanation:
In this fix commit https://github.com/odoo/odoo/commit/702c01661f255fe9ebbfc04c90b2cd0fa194d1e8


the case where vat is unset but the country is Italy is not rejected
anymore and a unset value is passed in _l10n_it_normalize_codice_fiscale

opw-2822259

closes odoo/odoo#88790

Signed-off-by: Josse Colpaert <jco@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

closes odoo/odoo#88005

Task-id: 2813957
Ticket-id: 2788927
Signed-off-by: Josse Colpaert <jco@odoo.com>

To reproduce
============

- Create one french company and one italian company with their respective localization packages.
- Go to the French company and create a contact, first set the country and then the VAT.
An error message will appear referring to Codice Fiscale but this information is not relevant on the French Company.

Purpose
=======

The VAT field has an onchange trigger `_l10n_it_onchange_vat`  to set `l10n_it_codice_fiscale` value.
on `_l10n_it_onchange_vat` there is no verification if the VAT number is Italian, so we try to get
a Codice Fiscale from it, which leads to error if the VAT number is not Italian.

Specification
=============

To solve the issue we added a verification on the VAT number to make sure that it is an Italian one before
trying to get Codice Fiscale from it.

opw-2777519

closes odoo/odoo#87603

Signed-off-by: Josse Colpaert <jco@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

closes odoo/odoo#87478

Task-id: 2795241
Signed-off-by: Josse Colpaert <jco@odoo.com>

When using price included taxes, the xml contained data that failed to
meet the constraints of the edi. This is due to the local rounding on
the lines of the invoice.
For example:

	A product costing 321€, on two lines of the invoice, with
	a price included tax of 22%
	Rounded per line:
	float_round(
		321 - (321/122 * 100),
		2 # To two decimal places
	)
	evaluates to 57.89, the total tax will be 2 * 57.89 = 115.78

	In the case of global rounding
	float_round(
		321 + 321 - (321/122*100) - (321/122*100),
		2 # To two decimal places
	)
	evaluates to 115.77,

	so we have a difference of one cent.

This can be exacerbated by more lines.

The constraints on the EDI that this conflicts with are on the tax
summary section for each tax.
The constraints (roughly reworded):
00422:  The base taxable amount for the tax must be equal to the sum of
	the base product prices (for which we have already used the
	rounded computed values, calcuated in the invoice) +
	<Arrotondamento> (rounding).

00421:  The value provided for the <importo> that is the value of the
	vat is equal to the taxable base multiplied by the tax rate.

The problem is that because of our local roundings, the taxable base
is equal to our products, but the tax rate * taxable base is not equal
to the tax amount (as present in the invoice).

This commit adds to the rounding field and subtracts from the
taxable base of the tax summary a value rounding value that
should make tax rate * taxable base equal to the value of the vat.

closes odoo/odoo#86052

Task: 2789290
Signed-off-by: Josse Colpaert <jco@odoo.com>

This fixes erroneous matching of product when the product code in an invoice is ambiguous and fixes a missuse of the label from a product rather than the one on the invoice

Previously, a product would be set on an invoice line even if several products share the product code and when a product is set the label is the one of the matched product
Now, a product is set if the code matches one and only one product and the label used is always the one from the invoice

closes odoo/odoo#86590

Task: 2764978
Signed-off-by: Josse Colpaert <jco@odoo.com>

This fixes the how general discounts and product discounts are represented in the Italian EDI.

Previously, discounts were erroneously calculated and represented on several invoice lines not linked to the product.
Now, cascading discounts are summaries as 1 percentage discount for products and 1 amount for the general discount.

closes odoo/odoo#85796

Task: 2764978
Signed-off-by: Josse Colpaert <jco@odoo.com>

Before, it would give a traceback when we would have a product.supplier_info
with the same code and partner used for multiple products.  This way, we
avoid this traceback.

opw-2703669

closes odoo/odoo#85693

Signed-off-by: William André (wan) <wan@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.

closes odoo/odoo#84724

Task-id: 2764978
Signed-off-by: Josse Colpaert <jco@odoo.com>