- [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
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:
closesodoo/odoo#92881
Task-id: 2854284
X-original-commit: 8cf535a240dea12a5a8b1e0ef3b5b82698379bf1
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
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
closesodoo/odoo#97633
X-original-commit: 262eb7bd021d177d9a05397f9cda3fc76a21d4cb
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).
closesodoo/odoo#97619
Ticket-id: 2936967
X-original-commit: ca2f4c8e1babe9444bc2c6a7421eafb63f1c9346
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
TLDR:
* invoices are implemented using computed methods instead of onchange
* the synchronization only happens when switching tabs in the Form view
to improve perfs.
_______________________________________________________________________
The whole engine of the synchronization of Invoices to the Journal
Entries has been refactored
* by using computed fields instead of onchange functions
* by synchronizing only from invoice to journal entry in `create` and
`write`
* by saving when switching tabs on the Invoice form, to synchronize
before showing the values
This comes with numerous advantages:
* no need to call the onchange methods manually
* no need to use the Form emulator to build invoices (i.e. EDI, OCR,
intercompany, ...)
* the performance for invoices with many lines improves drastically, going
from 2 minutes to 4 seconds to create an invoice with 500 lines
* the model is more declarative, we can now see how the values are computed
instead of having the values being copied from various places.
* remove the hack in `onchange` that disabled the recursivity of it,
which was unexpected and needed to be managed manually in all the
onchange methods
This means that:
* Some fields need to be exclusively computed on journal entries values
or invoice values, more specifically the Tax Summary widget.
It is now
- computed from entry lines, when opening the view
- computed from invoice lines when changing those, because the tax lines
will need to be recomputed anyways, erasing previously set values
- set with an inverse function when saving; after the sync has been done
* Some possible operations previously possible have been dropped.
(i.e. look at the removed test test_in_invoice_line_onchange_accounting_fields_1)
This is because such a behavior was undefined (how is changing the balance going
to affect the unit price? How is the amount currency going to affect it?)
_______________________________________________________________________
Implementation Details
----------------------
The "dynamic lines", meaning the payment terms and the tax lines are now
only created in the `create` and `write` functions.
In order to reduce code duplication, it has been implemented using
context managers used in both `account.move` and `account.move.line`
These context managers help comparing the values before/after, acting
like a local `onchange`, but getting benefit from the dirty flags from
the `compute` dependences.
This is relying on computed fields on the move (`needed_terms`) and on
the lines (`compute_all_tax`) which contain the values needed for the
related move.
Depending on the needed values and the existing values (`term_key` and
`tax_key`, respectively) the context manager will determine what needs
to be created/updated/deleted.
Some related changes are to produce a `dict` instead of a `str` for the
`tax_totals` (previously `tax_totals_json`) fields, by simplicity to
reduce the complexity of IO, and simplicity of debugging, because the
logic of the field needed to change (cannot be computed at the same time
anymore since it needed the lines to be synced)
By simplicity, and also because it makes more sense, some boolean fields
have been merged into `display_type`:
* `is_rounding_line`
* `exclude_from_invoice_tab`
* `is_anglo_saxon_line`
The `price_unit`, `quantity` and other "invoice fields" are now not set
anymore on lines that are not product lines since it didn't make any
sense to have it.
Performances
------------
You have to keep in mind that a simple `create` didn't compute a lot of
fields, for instance not taxes were set, no payment terms,...
Now it does.
```python
import random
from timeit import timeit
from odoo import Command
domain = [('company_id', 'in', (False, self.env.company.id))]
products = self.env['product.product'].search(domain).ids
partners = self.env['res.partner'].search(domain).ids
taxes = self.env['account.tax'].search(domain).ids
def create(nmove, nline):
self.env['account.move'].create([
{
'move_type': 'out_invoice',
'partner_id': random.choice(partners),
'invoice_line_ids': [
Command.create({
'name': f'line{i}',
'product_id': random.choice(products),
'tax_ids': [Command.set([random.choice(taxes)])],
})
for i in range(nline)
]
}
for j in range(nmove)
])
# After | Before
print(timeit("create(1, 1)", globals=globals(), number=1)) # 0.11 | 0.09
print(timeit("create(100, 1)", globals=globals(), number=1)) # 2.76 | 2.50
print(timeit("create(500, 1)", globals=globals(), number=1)) # 14.56 | 12.34
print(timeit("create(1, 100)", globals=globals(), number=1)) # 1.03 | 5.52
print(timeit("create(1, 500)", globals=globals(), number=1)) # 3.99 | 125.02
print(timeit("create(50, 50)", globals=globals(), number=1)) # 19.44 | 79.55
```
Another metric that can be used is running the test suite with
`--test-tags=/account` (only `account` installed)
* before: 404s, 267127 queries (366 tests)
* after: 318s, 232125 queries (362 tests)
Why this commit title?
----------------------
Someone told me that this was the perfect way of naming your commits.
c04065abd8
task-2711317
closesodoo/odoo#96134
Related: odoo/upgrade#3715
Related: odoo/enterprise#29758
Signed-off-by: Laurent Smet <las@odoo.com>
The render API was confusing as mixing the access to the report and
the rendering env.
The ambiguity was present for code such as
`report.sudo()._render(record_ids)` where it was not clear if the
`sudo()` is needed to access to `report` or to `record_ids`. For low
priviledge users (such as portal or public), it was common to use
`report.with_user(SUPERUSER_ID)._render(record_ids)`.
This PR changes the render methods signature to be `api.model`. The
`report_ref` can be:
- ir.actions.report external id
- ir.actions.report id
- ir.actions.report recod
- `report_name` value
This will allow to call the report methods with any user and no longer
need to use `with_user(1)` to render reports as public user.
Task-id 2670865
closesodoo/odoo#91341
Related: odoo/upgrade#3650
Related: odoo/enterprise#27323
Signed-off-by: Martin Trigaux (mat) <mat@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
closesodoo/odoo#97277
X-original-commit: 377e8eedb2ceb444d6b331debdffa17c47e4a898
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@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
closesodoo/odoo#97147
X-original-commit: 83e41d6f1adc30e24cda95c5f4ab2a875e1bcaa0
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).
closesodoo/odoo#95966
Ticket-id: 2909394
X-original-commit: 089f59ef79c554d7517d8621bfaee03875ad6062
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@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
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 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.
closesodoo/odoo#93991
X-original-commit: 34315a9114eff6fa8ce3b16bb081ad026816a08c
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), NLCIUS, 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.
The following modules are removed:
* account_edi_facturx
* account_edi_ubl
* account_edi_ubl_bis3
* l10n_no_edi
* l10n_nl_edi
* l10n_be_edi
Task: 2628093
See also: odoo/upgrade#3581closesodoo/odoo#93135
Signed-off-by: Laurent Smet <las@odoo.com>
In 7dd5437a65 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 7dd5437a65 and using the parenthesis around the flag
explicitely.
opw-2853609
closesodoo/odoo#93158
X-original-commit: 550f9e77625a7917bffd693f18aafe10a04276c9
Signed-off-by: Nicolas Lempereur (nle) <nle@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
closesodoo/odoo#91370
X-original-commit: 39dcee1cc1ef1ed4c4a85494b689f4f604e32de6
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.
closesodoo/odoo#91215
Task: 2800967
X-original-commit: 8dc17c29c7e032d94f45ec5e2e82f9dd871e4952
Signed-off-by: Josse Colpaert <jco@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.
closesodoo/odoo#89494
Task-id: 2826424
X-original-commit: 712758fc2505abfa271636caaa8ba38436086f32
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
closesodoo/odoo#89379
X-original-commit: 7dd5437a65bd43a91d6ae7e2fb4f11f2f0b1476b
Signed-off-by: Nicolas Lempereur (nle) <nle@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.
closesodoo/odoo#89163
X-original-commit: 2aa09ba39aed1a34f59914124fc9dcf11787e75b
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
closesodoo/odoo#88846
X-original-commit: fb5c8adc8aa86491cd2175f60c17d17bbd60b57b
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@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>
Even if ORM normally filters them out, no need to specify .id in domains.
This leads to better and easier to read queries / domains.
Task-2816580
closesodoo/odoo#85648
Related: odoo/enterprise#24911
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The tax map was used in a previous version of the invoice template, it
was superceeded by 'tax_details', which uses the
_prepare_edi_tax_details function
closesodoo/odoo#87734
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
closesodoo/odoo#87922
X-original-commit: cfa71276c6154d30d93a60efff6338412019118c
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: abla001 <abla@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>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
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
closesodoo/odoo#87313
Task: 2764978
X-original-commit: 47d5dff9f9a8eb0b4eebdf56e2a2d46618972453
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Florian Gilbert <flg@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.
closesodoo/odoo#85863
Task: 2764978
X-original-commit: 5769f13e48c5b68bf19fc82377b9ea716ea4a85e
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.
closesodoo/odoo#86711
Task: 2789290
X-original-commit: def954e85e83e5be18c0a1805f0af20f8116bf3d
Signed-off-by: Josse Colpaert <jco@odoo.com>
Josse Colpaert