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>
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
closesodoo/odoo#85725
X-original-commit: d7b35bb60d84eb587d82a3d9da24e39e8a42af9d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Sometimes when importing products that share the same internal reference code (default_code) the _import_fattura_pa function will throw an expected singleton error. This is because, in order to find the product for the line of the invoice, it will search for the product reference code (e.g. [CONS_0001]), which is not necessarily unique.
I've set the limit to one on the search to fix the immediate error for
now, but I will add more logic to better search for the relevant product
in a future commit.
closesodoo/odoo#84826
Task-id: 2764978
X-original-commit: aae609915cb1f76c32c518ff8959674853633f55
Signed-off-by: Josse Colpaert <jco@odoo.com>
Allow the bill prediction when data like facturx is imported.
This revert #68311 stating prediction might cause traceback when no account_id is found.
Now, this error seems to not occur anymore.
When importing data like facturx and no account_id is predicted, the default account set on the
vendor journal will be set.
opw-2662158
closesodoo/odoo#84092
X-original-commit: 1acece31eaf1417dea6ed330ac25c3b8de162baf
Signed-off-by: William André (wan) <wan@odoo.com>
Italians do not always mention the country code in the VAT
number of the partner, but we can suppose in that case that
it is within Italy. Instead of IT0477472701, they would put
just 0477472701.
closesodoo/odoo#83324
X-original-commit: 91b4168b5481d57e6af6e0c64895e97e47303ae8
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Some use cases require the use of the same account number on multiple
partners. This will relax the constraints to allows such use cases, and
adapt to avoid setting the partner or bank when we cannot be sure of the
one we should take (on bank statement line, and during reconciliation)
Task id #2692025closesodoo/odoo#81362
Related: odoo/enterprise#22881
Signed-off-by: Laurent Smet <las@odoo.com>
When encoding a string or bytes with base64,
the resulting byte string must be decoded
to get the string back.
* `addons/account_edi_proxy_client/models/account_edi_proxy_user.py`
AccountEdiProxyUser._register_proxy_user()
* `addons/l10n_it_edi/models/account_invoice.py`
AccountMove._prepare_fatturapa_export_values()
* `addons/l10n_it_edi_sdicoop/models/account_edi_format.py`
AccountEdiFormat._l10n_it_post_invoices_step_1()
X-original-commit: 3a705d93543e910b6af4b3b4aa53c523f367782a
Part-of: odoo/odoo#77977
In order to limit encoding decoding, the _render method returns a
unicode string in the markup safe object instead of a MarkupSafeBytes
closesodoo/odoo#68299
Related: odoo/upgrade#2454
Related: odoo/enterprise#17270
Signed-off-by: Antony Lesuisse (al) <al@openerp.com>
Even in the interface, when we empty a string, the value
in the database is '' and not NULL. So, we should let the user
put the field to '' again. (as it is not required)
This will require un update, but otherwise, it just relaxes
the constraint.
closesodoo/odoo#74572
X-original-commit: bc64805e27c9f31f446680aa2398affb945ffd83
Signed-off-by: William André (wan) <wan@odoo.com>
Some field strings are duplicated and raising a warning in the CI.
Solution is to remove duplicated fields and put them in a common module,
or to change the string in the field declaration and put the right one
in the view.
If the buyer is Italian, it must have a zip code of length 5.
If the buyer is not Italian, the zip code is optional
closesodoo/odoo#73883
X-original-commit: 86aa7507b0d86bd13dba303c75821048d420f647
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
Before this commit, for an EDI to be successfully posted, returning an attachment from 'post_invoice_edi' was required. In some cases this caused problem:
- When an EDI is posted in two steps, sometimes the attachment is generated in the first step and nothing is returned until the second step. This forced to do some hack where the reference to the attachment in a seperate field to be able to return it after the second step.
- When an EDI doesn't have a file to return (maybe we just send data over an API and get a response without any file involved).
Now, the attachment are removed from account_edi flows. When returning from 'post_invoice_edi', it is still possible to return an attachment whose reference will be kept in the edi_document, but will not change the state of the document to 'sent'.
To make the state change to 'sent', 'post_invoice_edi' must return {'success': True}.
Nothing has changed in the 'cancel' flow, meaning that the buttons related to canceling or reseting an invoice to draft are now based on the state and not on the existence of an attachment on the document. Also, when an invoice is successfully cancelled, the reference to the attachment is STILL removed from the document, since the document does not represent an electronic invoice anymore.
closesodoo/odoo#70040
Related: odoo/upgrade#1946
Related: odoo/enterprise#13220
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Codice Fiscale can be 16 length (letters + digits) for physical people.
Codice Fiscale can be 11 digits prefixed or not with 'IT' for companies.
An error is raised if the codice fiscale is not saved in the correct format. When registering to l10n_it_edi_proxy, we try to normalize the Codice Fiscale if possible.
Also, when entering the vat in the partner, the Codice Fiscale is automatically set normalized.
closesodoo/odoo#73774
X-original-commit: 3741e141e5a468b8ce0413f4f7d7fc05751b0c1b
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
Before this commit, only files coming through ir_server_mail where parsed. The goal of this commit is to allow upload of p7m files.
closesodoo/odoo#73337
X-original-commit: 13ff9b488d28da5dceec22e1c26f448796ca30c0
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
When importing vendor credit note from an italian e-invoice xml file with a "DettaglioPagamento" section,
the data import will fail and you will have the "Unsupported image format" message on top of the invoice.
The use of '_compose_info_message' function is not possible on a 'account.edi.format' object and was
changed to use the 'invoice' parameter.
opw-2500569
closesodoo/odoo#72018
X-original-commit: 8e886704a4efb9ca2f8d2e2b021f66d668af40d8
Signed-off-by: Nicolas Lempereur (nle) <nle@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>
Guillaume (guva)