The method `_get_unece_code` is called in the module `account_edi` and `account_edi_facturx`.
The latter depends on the former but the opposite is not true. So this method should be defined in the module `account_edi` otherwise a traceback appears when we confirm an invoice and `account_edi_facturx` is not installed.

opw-3171405

closes odoo/odoo#122912

Signed-off-by: William André (wan) <wan@odoo.com>

Previously (since https://github.com/odoo/odoo/commit/649e0f2d1aefed585c3cf2b0c96ff6004280de97

) it was only set when the invoice had taxes, and it was re-defined as many times as taxes.

closes odoo/odoo#106862

Signed-off-by: William André (wan) <wan@odoo.com>

In Factur-X, there is no way to represent a tax "price_include" because
every amounts should be tax excluded.

Currently in Factur-X, a line with a tax price_include = True will be
incorrectly exported. Indeed, the Factur-X.xml is generated by setting the
GrossPriceProduct as the price_unit. In Factur-X, this amount (and the others
in the line details) should be tax excluded. Thus, it's wrong to set the
GrossPriceProduct as the price_unit.

To fix this, the GrossPriceProduct should be the price_unit if no tax
price_include = True is set, otherwise, the gross price = price_unit/(1+tax/100).

This way, the Factur-X file will be consistent with the norm.

Note that the import of a Factur-X xml will thus try to pick taxes with price_include = False,
and the price_unit will be tax excluded. If no matching tax with price_include = False is
retrieved, a tax with price_include = True is searched, if found, the price_unit is
recomputed accordingly. In both cases, the lines subtotals are the same.

opw-3032382

closes odoo/odoo#105276

Signed-off-by: William André (wan) <wan@odoo.com>

The previous link was dead

closes odoo/odoo#103051

X-original-commit: 570fec0a
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Currently, when creating an invoice from factur_x XML, the vendor is
identified by sequentially checking (in this order) the following
information :
- VAT number
- name
- email
However, when we generate a factur_x XML, we do not include
the partner's email address. This means that in some cases, two odoo
databases are not able to communicate bills/invoices properly.
This commit brings back a behavior that was unintentionally removed in
https://github.com/odoo/odoo/commit/d25fdafcd8eb4cfef14c2ef7ed8ad7785dd01b55



opw-2909408

closes odoo/odoo#99118

X-original-commit: 090cb251
Signed-off-by: William André (wan) <wan@odoo.com>

Odoo attaches factur-x doc to every invoice pdf. That data can be used to upload
invoice to another Odoo instance.

On uploading such an invoice, Odoo tries to find product in its DB. But it
doesn't work if original product has Sales Description which is by default
copied to line's Description (field `name`).

Fix it by searching by first line in the name value of factur-x. Product name
doesn't contain \n symbol in most cases anyway.

This commit doesn't fix factur-x doc generation because of stable version
policy. In next Odoo release we should use separate factur-x attributes for
product name and invoice line description.

opw-2878530

closes odoo/odoo#95066

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

Add a new module that makes three new fields available on the invoices.
These fields are required when using facturx to send invoices to
public services through Chorus PRO.

The original template is updated to make it easier when integrating
the ubl refactoring coming soon, and avoid template issues that would
happen with an inherit if the inheriting module isn't updated after the
refactoring deployment.

opw-2714544

closes odoo/odoo#92954

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

The _get_unece_code method does not work in case where a specific uom
has multiple xml_ids.
Change it to handle such case and try to match every xml ids with a
unece code if possible.

closes odoo/odoo#90984

X-original-commit: f97fe80f
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>

The discount inside a facturx document has recently changed to include
the amount instead of the percent.
In the process, there is an issue when using tax_included where
the discount would be computed not based on the amount without tax
but on the amount taxed.

This change will align the discount computation on what will be
used in 15.0+

closes odoo/odoo#89656

X-original-commit: 95f4794e
Signed-off-by: Laurent Smet <las@odoo.com>

The xml we generate for factur-x is no longer compliant with all
the latest standards. With these changes, we are providing the tools
to make it work once again and make sure it is validated by the
factur-x and zugferd validators in all aspect (PDFA/3, XMP, XML)
It should also be valid to be sent to Chorus pro if applicable.

This adds a mapping to the UNECE unit of measure codes for uom, that
are required for factur-x.

It will also calculate a category for each taxes as such:
    - If the tax is an export from EU to outside EU, G.
    - If the supplier and customer are both in EU but different country,
        K
    - If both are in EU, in the same country but the tax amount is 0, E
    - Otherwise, it will be S.
See https://unece.org/fileadmin/DAM/trade/untdid/d16b/tred/tred5305.htm



opw-2714544

closes odoo/odoo#89491

X-original-commit: d25fdafc
Signed-off-by: Laurent Smet <las@odoo.com>

How to reproduce the bug:

- Install the account app
- Get a FacturX invoice with a discount on item
- Upload the invoice
- Check that the price of the discounted item takes the
  discount into account

Bug:

If you want to upload a FacturX invoice that contains a discount,
Odoo will take the original price into account instead of the
discounted one.

opw-2705291

closes odoo/odoo#87126

X-original-commit: fc853c21
Signed-off-by: Adrien Minet <admi@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>