When creating an invoice with a positive line and a negative line, with
different taxes, the DatiRiepilogo node for the tax of the negative
line contained positive amounts when they should be negative.
This is because we were applying `abs()` too naively in the XML template
and in the code of _l10n_it_edi_prepare_fatturapa_tax_details.
This bugfix commit changes the logic to no longer use abs().
opw-3316300
closesodoo/odoo#122982
X-original-commit: 0241e96fe12401f0891efc00f840e03d0c0219fd
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Moved some logics belonging to the partner from the account_edi_format model to the res.partner model instead.
Functions:
_l10n_it_edi_get_values (normalized vat, country code, is_company, in_eu...)
_l10n_it_edi_normalized_codice_fiscale
Added `phone` and `email` fields to the EDI export tests.
Added a message on the export tests asserts to know what's the test file that generated an error.
Task link: https://www.odoo.com/web#id=3175408&model=project.task
Task-3175408
closesodoo/odoo#105696
Signed-off-by: Josse Colpaert <jco@odoo.com>
If the invoice has a deduction line for a down payment, the EDI
generated XML file should have a reference to it in the
DatiFattureCollegate. We take the reference from the related sales
order.
Same goes for credit notes: they should have a reference to the original
invoice. We take the reference from the move's reversed_entry_id field
Task link: https://www.odoo.com/web#id=3210485&model=project.task
Task-3210485
closesodoo/odoo#118307
X-original-commit: 1f62ed76731a15cee5345dc0312ac819dadbcb44
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Withholding
-------------------------------
Italian invoices may have a special fiscal feature which is "Ritenuta"
It means "withholding" and we implement it as a tax. The Withholding's
main use case is for professional consultants who can ask their
services' buyer to pay their income taxes on their behalf. This way, the
invoice lines will have a negative tax, and the buyer will not all the
money that is billed. The withheld amount will be sent to the tax
collector by the buyer at a later time. Professionals have any threshold
of how much money can be withhold in an year.
We added two fields to account.tax, l10n_it_withholding_type and
l10n_it_withholding_reason, for EDI import/export purposes. New taxes
with those fields filled out and a tax group have been added. The view
has been updated, to see the fields, the tax amount must be negative.
In the EDI import, the new DatiRitenuta tag is now read and handled. The
correct l10n_it_withholding_type tax must be found, or a message is
logged to the invoice chatter.
Pension fund
-------------------------------
Under Italian fiscal rules, there are cases in which professionals may
ask the buyer of their services to pay income taxes on the invoice
itself, and that's managed withholding taxes. In addition to that, the
buyer may also be asked to pay for the seller's national pension fund,
as a percentage of the invoice's total. This information needs to be
imported/exported through the EDI
Ticket link: https://www.odoo.com/web#id=2936606&model=project.task
Task link: https://www.odoo.com/web#id=2903280&model=project.task
v14 Community PR: https://github.com/odoo/odoo/pull/96930
v14 Enterprise PR: https://github.com/odoo/enterprise/pull/33083
task-2903280
opw-2936606
closesodoo/odoo#111800
Forward-port-of: odoo/odoo#102527
X-original-commit: 2525103f200b8bb13ea78eaa28f2135ed5bba755
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Just like the seller's codice fiscale is always shown in the FatturaPA
XML if present on the partner, so should be the one from the buyer.
If it's not, then when a company is a part of a fiscal group sharing
the same VAT number and different Tax Codes, the SDI will reject the
XML because the VAT number won't be enough for the Tax Agency
to identify the company.
There is no damage in showing the Codice Fiscale when the VAT is also
there.
opw-3114115
closesodoo/odoo#110307
X-original-commit: db5ce853e15b5003771c4811302dbff6e3cc054b
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@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
closesodoo/odoo#106312
X-original-commit: 8c18b870ecc04314380fcdb6b61179de78e28703
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Taxes on self-invoices for non-EU export actually have amount > 0,
l10n_it_has-exoneration = False but they must have the law reference
field filled out, so we're taking the "invisible" clause
out of the view.
Task: https://www.odoo.com/web#id=3010849&model=project.task
opw-3010849
closesodoo/odoo#105238
X-original-commit: cdb90133ae463f62ade82f67ac89293e09b69740
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Due to the deprecation of t-esc to the unique use
of t-out in the rendering template, this replace
every usage of it and ensures everything continues to
work as inteded. Removing deprecation warnings
polluting terminal
deprecation commit: odoo/odoo:9ce5bc8881ae06b613ef61eb07453b224f62bae6
closesodoo/odoo#103731
Related: odoo/enterprise#33037
Signed-off-by: William André (wan) <wan@odoo.com>
Fixing some demo data from US having an Italian VAT.
Also, a partner's name and VAT has been changed not to be too similar
to one of our actual clients. Now the Engie Italia's VAT is used.
closesodoo/odoo#102989
X-original-commit: d169552778dff396ef28bd7b76500db8dca32879
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
The RappresentanteFiscale and CessionarioCommittente nodes must be in this order in the invoice xml. The RappresentanteFiscale node is only added if the company has a tax representative configured. In that case, before this fix, submitting an invoice to the SDI (Italian tax agency) would not go through and generate an error :
The invoice has been refused by the Exchange System
File non conforme al formato : Invalid content was found starting with element 'RappresentanteFiscale'. One of '{TerzoIntermediarioOSoggettoEmittente, SoggettoEmittente}' is expected.
How to reproduce :
- Install l10n_it_edi_sdicoop
- Configure a tax representative on the company
- Go to accounting settings > Electronic Document Invoicing and choose the test mode + check the “Allow odoo…” checkbox.
- Create a new invoice and confirm
- Click on “Send now”
- Click again on “Send now” until there is an update and the error is displayed.
closesodoo/odoo#100264
Task: opw-2952098
X-original-commit: 71da80deb044852a2af6b111d695f94aad7803ac
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@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>
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
In order to perform reverse charge self-invoicing, a company must have
its codice destinario (pa index) defined. This commit adds a valid
pa_index (from the sdicoop test channel) to the demo company.
closesodoo/odoo#97658
X-original-commit: 42c08b298dba5d4e34ed10ae4fd8828db9636a8a
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>
When the payment reference on an invoice is empty an error occurs when
trying to generate the edi xml. The error comes from trying to retrieve
a slice on a bool.
To solve this, a t-if has been added in this commit, such that the
function is not called when the field is empty.
closesodoo/odoo#97151
X-original-commit: 67616aac66a0b7895dfad80d825ecff7b4cd75b1
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@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>
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@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>
The total value of the invoice can be reported in the edi using the
field <ImportoTotaleDocumento>. This commit uses the amount_total of the
invoice to occupy this field.
Adapt the l10n_it_edi_sdicoop tests to include this field in the
expected xml.
closesodoo/odoo#95175
Task-id: 2894623
X-original-commit: 2e0c6def4d9be3b73e874304813ed3bb685ade95
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@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>
The pa index should only be XXXXXXX when the foreign partner is not
identified. In this commit we change the condition on the template such
that if the pa index is defined, we always utilise it. If the pa index
is not defined but the partner is italian, we use '0000000', and when it
is not defined and the partner is not italian, we use 'XXXXXXX'.
closesodoo/odoo#91871
Task-id: 2858092
X-original-commit: bf468affa2d86967b3b63a0be62063061b7b263c
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@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>
In case there is an AML with 0 qty, the generation of the FatturaPA e-invoice
tracebacked. Even if it's a functional error on the invoice, this also impeded
the EDI cron to run, and this is solved by avoiding the case in the
computation.
closesodoo/odoo#89348
X-original-commit: 79cbea8b9241c1fa98db1bb575ea430360d630e3
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@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>
Demo data to improve the flow of testing the edi. A bank account and a
partner with a street/city/zipcode/codice fiscale are required for the
edi, so having these as demo data is useful.
The demo company vat code and codice fiscale are also changed to those
of a valid company, so that they will be accepted by the sdi testing
environment. The address of the demo company is updated so that, if by
accident, an invoice is sent using the demo company, through the
official channel, the address will make it an obvious test.
closesodoo/odoo#87835
Task-id: 2809328
X-original-commit: f8da2dbedf948eaf86b92a0ac4ecd90acc811203
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@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>
When codice fiscale is not the same as the partita IVA, the template was
utilising the wrong value for IdCodice in <IdTrasmittente>. It should
use the value of codice fiscale, and if it's not found, then use the vat
value (e.g. when it's not an Italian company).
closesodoo/odoo#86621
X-original-commit: e961ff220aee5e89a3de7b301923bfa3f1665077
Signed-off-by: Josse Colpaert <jco@odoo.com>
PrezzoUnitario causes an error when the discount is 100% as it tries to
divide by zero. Fix this by just using the unit price when the discount
is 100%.
closesodoo/odoo#86614
X-original-commit: 23e84145ad5beaf1baa0d6a1fc9ed4056a6b1243
Signed-off-by: Josse Colpaert <jco@odoo.com>
The EDI rejects the xml if the <IdDocumento/> is longer than 20
characters long.
X-original-commit: 2c76293c1575923048d66e66c6999af773c309cf
Part-of: odoo/odoo#86614
According to the spec, the PrezzoUnitario should be the unit price
without the taxes. If we use taxes included, this can be problematic.
That is because there is another rule that says that the PrezzoUnitario
* Quantita - Sconto should be within 0.01 precision of the PrezzoTotale.
So, with taxes included and a price unit only rounded to 2 decimals, you
easily go out of that limit.
The solution is to increase the precision on the price_unit (6 decimals
should not cause side effects and precise enough for most cases)
and to do the calculation differently by calculating it again from the
price_subtotal on the invoice line.
Task id: 2764978
closesodoo/odoo#85718
X-original-commit: 82f2794a2aee8492cbd36d8ab4d8a62c9665789d
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
The number is set as zeros, but we should still provide
the IdPaese tag.
opw-2703669
closesodoo/odoo#82398
X-original-commit: 3e4361ff621e5458e6a2ad09610274bf33290106
Signed-off-by: William André (wan) <wan@odoo.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>
Before it was only done on MyCompany, but interferes easily
with other demo data. Better for the Italian localization
to try the demo immediately in IT Company.
We also added an Italian demo partner, so it is clear
which one can work immediately.
closesodoo/odoo#67615
X-original-commit: 91ff96a79121c1b7018f8a1f7fa9850170852c41
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
Have an invoice with single line and 0% tax on it
As the tax has 0 amount, no related moves are created,
the e-invoice export will fail the formal compliance check as it is
missing a section
opw-2461496
closesodoo/odoo#66960
X-original-commit: 71cc7212b1c1abad5d37e29f3a1f33f6e6cd2a81
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
This is mandatory for PA customers, and required by several enterprise customers as well.
Related Ticket: 2425845
closesodoo/odoo#64443
X-original-commit: bb898e663019942a6fd99ce96ce5742a8ff7ea56
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
- Create a partner outside Europe
- Set a VAT number
- Create an invoice for the partner
- Post the invoice
The `IdPaese` and `IdCodice` is obtained from the VAT number, but it is
not correct for partners outside Europe: the VAT number should always be
`OO99999999999`.
A workaround is to set the VAT number of the partner to
`XXOO99999999999`, where `XX` is the country code. However, in case of
multi-company with shared partners, another company might need the
proper VAT number.
In case of a customer outside EU, we:
- get the `IdPaese` from the country of the partner
- set the `IdCodice` to `OO99999999999`
We also add the `IdPaese` to customers without VAT.
opw-2355842
closesodoo/odoo#60416
X-original-commit: 35267c59c32f747351e8741cfe6011749914e809
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
For foreign customers (out of Italy) who do not have a VAT number,
"0000000" should be used as VAT code.
opw-2325991
closesodoo/odoo#58204
X-original-commit: c5589bf8880e109990d902bb905c7de967910524
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Added edi.documents representing an electronic document for a move and an edi.format.
A format can be asynchronous if it needs to call a web-service to generate the document, it will then be generated by the CRON (otherwise it's generated in post).
The formats can support payments if needed (can be generated immediately or by the CRON).
Added support for errors and related views.
Setting defaults format on a journal can be done automatically (based on a hook).
Added tests : xml comparaison with diff and helpers to test a EDI import/export
--task: 2247368
- Support for account_edi workflows (only import) + fattura_pa as an account.edi.format.
- XML containing multiple invoices cannot be imported from the chatter.
- Create journal entries as soon as bank/cash statement lines are created, temporary booked on a suspense account set on the journal.
- Simplify the management of "blue" lines in the reconciliation widget. A "blue" line is now a journal item using a temporary liquidity account (outstanding payment/receipt accounts, set on the journal).
- Adapt and simplify the bank reconciliation report.
- Remove the bank reconciliation threshold date. The reconciliation report will show the not already reconciled journal entries using a liquidity account and the not already reconciled journal entries using a temporary liquidity account. Without accounting, an account.payment will involve directly the liquidity account and then, will be considered as a statement line directly.
- Remove the post_at bank reconciliation feature. The "paid" state will be set on the invoices only if reconciled with a journal entry involving the journal's liquidity account.
With invoicing, the payment will do that so the "in_payment" state should never be shown up.
With accounting, only the statement lines have the power to move an invoice to the "paid" state.
- Fix various corner cases about the management of multi-currency in bank statement lines.
- Fix the conversion dates in multi-currency: Since the bank/cash is always used on the statement lines, it will use always the real "bank" date instead of the fictive payment one.
- Ensure the 'reconcile' method will raise an error if the involved moves are not posted.
related enterprise PR odoo/enterprise#7019closesodoo/odoo#41301
--task: 2092096
Related: odoo/upgrade#1018
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This removes the measure_type field which has become unused and
causes issues when users try to add new uom categories.
Task-2043927
closesodoo/odoo#41056
Related: odoo/enterprise#6945
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
shown payment information along with bank details in exported
electronic invoice XML file
closesodoo/odoo#41656
Task: 1948158
X-original-commit: 7d2cf514a2443accbb9455553f27bbe2185e47a4
Signed-off-by: Josse Colpaert <jco@openerp.com>
Antoine Dupuis (andu)