PR odoo/odoo#157918 has a bug on commit 8bd8d4a3eaf.
We cannot do `int(x) in Command` as it's TypeError.
closesodoo/odoo#162786
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
When we delay the creation of `repartition_line_ids`, the `account.tax`
gets created with default `base` and `tax` repartition lines,
which we must get rid of when we update the tax with the delayed
repartition lines.
related PR: #148370
task-3607459
closesodoo/odoo#157918
Signed-off-by: William André (wan) <wan@odoo.com>
Withholding taxes should not be used for tax closing.
This was impossible to implement before because of the bugs addressed
in the other commits of this PR.
related PR: #148370
task-3607459
Part-of: odoo/odoo#157918
`self.env.ref` -> kept of course
`deref` -> `deref_values` as it derefers for all passed values.
`defer` -> `delay`
`ref` -> kept, there's no choice, it's used in too many places
Also changed some variable names in the final loop for clarity
`data` -> `model_data`
`created_vals` -> `created_records`
`create_vals` -> `all_records_vals`
related PR: #148370
task-3607459
Part-of: odoo/odoo#157918
For `account.fiscal.position`'s submodels, REFs are not dereferenced,
they refer to virtual xmlids that only exist during import
(after account.tax.template was removed)
It should also look for: f"account.{company_id}_{template_xmlid}"
related PR: #148370
task-3607459
Part-of: odoo/odoo#157918
Added chart_template loading tests for:
- evaluation of submodel fields
- import from commands in the integer form, i.e. (0, 0, {values})
related PR: #148370
task-3607459
Part-of: odoo/odoo#157918
Files in the CSV templates that had submodels didn't get their values
evaluated.
Example:
`account.tax-xx.csv -> repartition_line_ids/use_in_tax_closing` was not
evaluated by `account/models/chart_template.py`'s `_parse_csv` function,
resulting in taxes having a "False" value still resulting as True.
This already affects `l10n_eg`.
In the process, code has been a little de-obfuscated.
*(This came out while testing the task linked below. Even if they're not
in the scope of the task itself, we noticed that withholding taxes have
`use_in_tax_closing` to `True` and putting them to False in the CSV had
no effect)*
related PR: #148370
task-3607459
Part-of: odoo/odoo#157918
This bug is generally hidden in normal localizations because the
`get_account_account` function reads `account.account-xx.csv` soon
enough to create all the needed accounts.
In `l10n_ng` there is no `account.account-ng.csv`, as it relies on the
generic_coa. The chart_template's `get_account_tax` function reads
`account.tax-ng.csv` before `get_ng_account_account` is called.
The `defer` function should check the account_tax fields and postpone
them until the creates are done, but it only checks the "first level"
and doesn't check all the way down to
`account_tax.repartition_line_ids.account_id`
By making `defer` recursive we are able to properly postpone
the creation of taxes after the accounts are made.
related PR: odoo/odoo#148370
task-3607459
Part-of: odoo/odoo#157918
When making a registry of all available chart templates from exisiting modules,
the templating function is executed 5 times per Chart template instead of once.
It may not be all this relevant, but the fix is very basic.
related PR: odoo/odoo#148370
task-3607459
Part-of: odoo/odoo#157918
Added a test to verify the behaviour when receiving a negative bill. The
invoice gets imported with negative amounts, but it can't be posted.
When the user tries to post it, they are prompted to turn it into a
credit note with a UserError.
closesodoo/odoo#141485
Signed-off-by: Josse Colpaert <jco@odoo.com>
A partner found a bug, when this public method is called on a recordset
of more than one journal then the restriction will traceback, as the
`id` can only be called on one journal.
Simplest solution is to simply get `id` on the loop variable instead,
and let the code normally block the user with a UserError.
Credits to: https://github.com/juppe
Old PR: https://github.com/odoo/odoo/pull/150888closesodoo/odoo#160585
X-original-commit: a0ca663b78741a82fcc8f4bea97779aa97087754
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
As we imported invoices from the IAP proxy we refused files when the
same filename was already present in the database.
Import invoices sent by Company A to Company B on the same Odoo database
was therefore impeded. The CRON would try to import the Company B's
vendor bill with the same attachment's filename as the Company A's
invoice and reject the file.
Now we fill in the `company_id` field on the attachment and we search
for attachments which belong to the company we're importing for, so the
case is covered.
An import test has been added.
opw-3673508
closesodoo/odoo#157755
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
- BooleanFavouriteField wasn't translated as the component was using
an untranslated variable instead of relying on the translation of
the template.
Some other translation fixing:
- ID Azienda is very generic, the correct name is Numero REA:
See: https://www.registroimprese.it/codice-fiscale-p.iva-rea
- No one calls a mobile phone "Dispositivo mobile", we already
translate it as the more common "Cellulare" even in the same file
task-3263708
closesodoo/odoo#157949
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Some translations were missing or incorrect for the VJ grid
in the Tax Report.
task-3724926
closesodoo/odoo#157622
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Codes like "Exch.Rate" in the Italian EDI XML template for invoices were
translated. They shouldn't be, as they have pretty short char limit and
it's risky to people change that. The XML users are either domestic or
the Italian Tax Agency itself, so no point in translating "Divisa" into
"Currency" anyway.
Link: https://www.odoo.com/web#model=project.task&id=3627379
opw-3627379
closesodoo/odoo#156987
X-original-commit: 8c6c244ada17b21c4f20c8ae566f44efdfeab162
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Add support for Internal Reverse Charge invoicing flows in Italy.
- Add 0% sale taxes and purchase taxes targeting VJ grids in `l10n_it`
for every Tax Exemption Reason involved (Scrap, Gold...)
- Add a Fiscal Position (equivalent to the Belgian "CoContractant" one)
mapping the sale tax and purchase taxes to their Reverse Charge
corresponding taxes. Those fiscal positions all have a different
law-required note (with the law reference) that has to be printed
on the PDF invoice through Odoo standard mechanisms.
- The way we compare the invoice features and each document type
requirements has been revised and expanded for the tax_tags sets case.
Now it should also avoid comparisons after the first failure, instead
of doing all the comparison anyway.
- Imported vendor bills that have TD16, TD17, TD18 now have their
0% reverse charge sale taxes converted to their purchase
22% VAT reverse charge corresponding tax impacting VJ tax grids,
following this mapping:
Sale tax examption reason -> VJ grid targeted by purchase tax
N3.2: VJ3
N3.3: VJ1
N6.1: VJ6
N6.2: VJ7
N6.3: VJ12
N6.4: VJ13
N6.5: VJ14
N6.6: VJ15
N6.7: VJ16
N6.8: VJ17
- Vendor bills that have taxes targeting grids VJ6, VJ7, VJ8, VJ12,
VJ13, VJ14, VJ15, VJ16, VJ17 are exported as Tax Integrations XMLs
to be sent to the Tax Agency with the document type TD16
- Vendor bills that have taxes targeting grids VJ3 are exported
as Tax Integrations XMLs to be sent to the Tax Agency with
the document type TD17
- Vendor bills that have taxes targeting grids VJ9 are exported
as Tax Integrations XMLs to be sent to the Tax Agency with
the document type TD18
Link: https://www.odoo.com/web#model=project.task&id=3724926
task-3724926
closesodoo/odoo#153556
Signed-off-by: Josse Colpaert <jco@odoo.com>
Added a small message in the chatter on an invoice when the invoice fails import.
Silencing errors on a blank invoice doesn't help us fix issues and
doesn't solve the import problem.
Part-of: odoo/odoo#153556
The compatibility was broken in a couple of points, clients
are required to update the `l10n_it_edi` or cannot send invoices
to the Italian EDI. Updating the module fixes the errors.
These two errors may appear:
```
[...]
File "/home/odoo/work/odoo/odoo/fields.py", line 1216, in __get__
raise ValueError(f"Compute method failed to assign {missing_recs}.{self.name}")
ValueError: Compute method failed to assign account.move.send(<NewId 0x7ff2da360eb0>,).l10n_it_edi_warning_message
[...]
File "/home/odoo/work/odoo/addons/l10n_it_edi/wizard/account_move_send.py", line 57, in _compute_l10n_it_edi_warning_message
action = error_data['action']
~~~~~~~~~~^^^^^^^^^^
KeyError: 'action'
```
Original broken PR: odoo/odoo#142596closesodoo/odoo#152824
Signed-off-by: Josse Colpaert <jco@odoo.com>
Some of the translation needed to be done or updated,
especially the ones about the warnings.
closesodoo/odoo#142596
Signed-off-by: Josse Colpaert <jco@odoo.com>
All the pre-sending checks that were done on the invoices before sending are now split by model, so that there's more separation.
ActionableErrors is used to show all the errors and give the user a quick action to fix the problems.
"These partners have an incomplete address, please verify xyz"
-> View partners ----> <partners view>
- Tooltip for IT XML export when readonly
We relied on the Italian xml export field's help tooltip before.
Now like other export options we have a dedicated <i> tag only shown when the field is readonly.
- Cannot change to test/official if you don't register
If you have Demo edi_mode, and you change to Test/Prod but don't register,
the EDI proxy user won't be deleted, and the edi_mode won't be saved.
So you think you changed to Test, but you haven't.
For compatibility in 17.0
- `l10n_it_edi_warning_message` must be maintained for the old view to work and make sense.
- Modified `l10n_it_edi_warning_message` becomes then `l10n_it_edi_actionable_errors`
Part-of: odoo/odoo#142596
`Model_get_actions_record(**kwargs)` helps building `ir.actions.act_window`
actions based on a certain model on very simple cases.
It opens a form if there's just one record, a list,form if there's more than one.
Given keyword arguments will overwrite those in the action.
This change serves as a base for the `actionable_errors` widget,
where it's used extensively to remove boilerplate code.
Part-of: odoo/odoo#142596
The new widget is meant to be a warnings header for wizards and forms,
where flows like EDI can list a series of errors and actions for
the users to fix the roadblocks.
The HTML result is an `<ul>` list with a point for each warning
and a link to a given action. Clicking the link will fire the execution
of a Python method on the backend, also passing back to it a series of
parameters the component has stored on setup time.
During setup, ActionableErrors accepts this structure as incoming data:
{
'error_key' : {
'message': _("Description of the warning"),
'action_text': _("Text of the link"),
'action_model': 'model.on.which.the.method.is.called',
'action_name': 'action_python_method_name',
'action_params': [...],'
},
...
}
A map is used instead of an array, so that the Owl framework
could be more precise in rendering changes in future development.
(i.e. remove a warning after clicking the action link
without re-rendering the whole widget)
This Widget will be used both for `l10n_it_edi` and `account_intrastat`
and can be embedded in many other occasions.
Part-of: odoo/odoo#142596
After #38518, there are cases in which people uninstall l10n_it_edi so the following traceback is given when importing a PDF invoice (OCR):
```
File "/home/odoo/src/enterprise/saas-16.4/l10n_it_reports/models/account_move.py", line 9, in <lambda>
lambda rec: self.env['account.edi.format']._check_filename_is_fattura_pa(rec.name)
AttributeError: 'account.edi.format' object has no attribute '_check_filename_is_fattura_pa'
```
We move everything back to l10n_it_edi, but the test will be excised.
Enterprise PR: odoo/enterprise#53452closesodoo/odoo#147676
X-original-commit: 0f897c6dd9f89c1e262dd6420829c0466dae398b
Signed-off-by: Josse Colpaert <jco@odoo.com>
The Settings page lacks a default search context key, because it lacks
the `<search>` arch.
We add a context key to make actions target some settings.
closesodoo/odoo#147149
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Copy-paste mistake in the template after refactoring.
IDCodice for the Sender has to be filled with the CodiceFiscale
and not with the VAT number.
(We only use VAT number if we don't find the CodiceFiscale.)
opw-3597050
closesodoo/odoo#143193
X-original-commit: 0c85e24a71442d0c0a717ee6264940047db1bdea
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
In Fattura Semplificata, copy-paste mistake in the template
after refactoring.
IDCodice for the Sender has to be filled with the CodiceFiscale
and not with the VAT number.
(We only use VAT number if we don't find the CodiceFiscale.)
related PR: odoo/odoo#143122
opw-3597050
closesodoo/odoo#143240
X-original-commit: 2a9344e08edb935f29489286029a75d3d236adb0
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Reproduce:
Install l10n_it_edi_withholding
Have an invoice with lines with two taxes:
. 4% INPS
. 0% with exoneration and exoneration kind
Post
Send to Tax Agency
Tax Agency rejects it
The Exoneration Kind tag is related to the VAT tax it is applied to, not
to the Pension Fund tax itself, so we have to modify the template.
A test has been added for the case.
Task link: https://www.odoo.com/web#model=project.task&id=3495670
opw-3495670
closesodoo/odoo#142543
X-original-commit: cbbdd974da4ce55a7b10fba39db4f9278f161808
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
When you open a Send and Print dialog, if the partner had no email,
then the form to edit the partne appears.
We're removing this behaviour and let the user decide if he wants
to check the partners or not
closesodoo/odoo#141549
Signed-off-by: Josse Colpaert <jco@odoo.com>
Several fixes after test:
- `l10n_it_edi_warning_message` 's compute was wrong
- `is_being_sent` allows for the Check Sending button to show, it just
reloads the page
- now the XML export button is only readonly if there's PDF and no XML.
In the other cases, it can be checked. It's checked and readonly if
all XMLs are generated.
- some label fixin'
closesodoo/odoo#139362
Signed-off-by: Laurent Smet (las) <las@odoo.com>
- `l10n_it_has_exoneration`:
This field is useless since it can be easily computed:
a 0% tax that has a `l10n_it_kind_exoneration` has an exoneration.
It's not even necessary to leave it as a computed, we just check
the presence of the kind of exoneration when necessary.
- `l10n_it_kind_exoneration`:
Renamed to `l10n_it_exempt_reason` following the
`l10n_es_exempt_reason` example
- `l10n_it_exempt_reason`, `l10n_it_law_reference`
Moving tax fields from `l10n_it_edi` to `l10n_it`.
These are tax details that also apply to Italian Taxes
even if they are not sent through the EDI.
Exempt reason and law reference are set on probably
invalid ones just for default. They will be changed
to valid ones, but we need to add more taxes.
Upgrade PR: odoo/upgrade#5305
Task link: https://www.odoo.com/web#model=project.task&id=3551241
task-3551241
closesodoo/odoo#139012
Signed-off-by: Josse Colpaert <jco@odoo.com>
The current Send and Print dialog doesn't let you
generate the XML without sending it.
An additional checkbox will be added to allow that.
It can be useful in all those cases in which the XML
is not yet 100% compliant or feature-covered to let
the Odoo customer download the XML,
modify it and send it manually through the Italian
Tax Agency web portal.
closesodoo/odoo#137034
Signed-off-by: Josse Colpaert <jco@odoo.com>
When the assets are still uncommitted (new PDF printing)
then there is a context key `commit_assetsbundle` that
commits the assets in the database before the template
that generated them actually uses it. Otherwise the
PDF will be rendered without the assets.
By putting `create` here we make the record non-virtual
and it won't be recomputed.
Part-of: odoo/odoo#137034
We have switched from a config_parameter (all companies rely on the
same) to account_edi_proxy_client_user.edi_mode which is company based
in `saas-16.3`.
We forgot to add the company to the domain while searching for existing
for test proxy users when changing the field in the res_config_settings.
So if it finds a test user "in any company" it still blocks you.
See: #116059
Task link: https://www.odoo.com/web#id=3525461&model=project.task
task-35225461
closesodoo/odoo#137012
X-original-commit: 63595f4bb1bc069387579f512082f128d1484fe5
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
In the odoo/odoo#122194 PR I incorrectly used the `need_cancel_request`
flag instead of the `show_reset_to_draft_button` one.
Italian EDI doesn't allow any sort of cancellation
(in case of error you have to a full refund credit note).
closesodoo/odoo#136436
Signed-off-by: Josse Colpaert <jco@odoo.com>
The condition for which the Fiscal Position's Note is shown only in Customer Invoices is removed because unnecessary.
A check has been added on the company's country to be 'IT'.
Task link: https://www.odoo.com/web#id=3420752&model=project.task
task-3420752
closesodoo/odoo#135966
X-original-commit: c32720dbd4df60fd9e8e10d3893501e006130d8d
Signed-off-by: John Laterre (jol) <jol@odoo.com>
The account_edi framework is no more a dependancy.
- Models account.edi.document and account.edi.format have been removed.
All the functions have been moved to the new account.move.send,
account.move, account.edi.proxy.client.user
- The move now holds the l10n_it_edi_state which admits all values that the SdI sends us as a status update
- The sending is now not handled by the cron but by the Send and Print dialog.
- Vendor bills Tax Integration sending by dedicated button
- The move form will now hold the state of the EDI transaction, its number and the EDI attachment as a Binary field on the move itself.
- A new banner will keep the latest message from the SdI, that's not the account_edi old banner.
- All the user messages have been simplified.
IAP-apps PR: odoo/iap-apps#652
Upgrade PR: odoo/upgrade#4893
Task link: https://www.odoo.com/web#id=3339971&cids=1&model=project.task
Task-3339971
Part-of: odoo/odoo#122194
- Proxy user is no longer a computed store=True field, but a proper one.
The type cannot be deduced just by some field on the company.
A company may be Italian and also use Peppol, so the two Proxy Users
must be different.
- The Proxy user `get_proxy_identification` method needs a proxy_type
argument, otherwise the method won't know if the current override
is to be applied or not. It cannot be handled by a field of the user
itself because it is also used contextually to the user creation.
- new `_get_default_enable_send_by_post` function on the Send and Print
wizard, so that it can be overridden by the features of the move
- Renamed `_compute_send_mail_extra_fields`
to `_compute_fields_from_moves_state`
Part-of: odoo/odoo#122194
New module is created (`l10n_it_edi_pa`) to add fields that are required to handle Split Payment, and it will be merged in master.
- `l10n_it_origin_document_type`
- `l10n_it_origin_document_date`
- `l10n_it_origin_document_name`
- `l10n_it_cup`
- `l10n_it_cig`
These fields are required to track money used that comes from funding to the Public Administration business for purchases, be it ordinary or project based spending.
They also need to be exported in XML during the EDI phase, in different
XML nodes depending on the `l10n_it_origin_document_type` field
ref: https://fex-app.com/FatturaElettronica/FatturaElettronicaBody/DatiGenerali/DatiOrdineAcquisto
Task link: https://www.odoo.com/web#id=2823645&model=project.task
task-2823645
X-original-commit: e07fb2503f28af1f23ef74efec6741f9623ce401
Part-of: odoo/odoo#134348
When an Italian company bills a PA business (for example they're selling cleaning services for a public building) the PA business will send the VAT to the Tax Agency themselves, while generally the VAT is collected and sent to the Tax Agency by the buyer (the PA business). This is done to avoid VAT fraud as the PA doesn't trust the business will actually pay the VAT. That's very common in Italy.
A new module will be created (`l10n_it_edi_pa`) in the next commit to add fields that are required to handle Split Payment, and it will be merged in master.
- New Split Payment related accounts are created: 2607, 2608
- New tax report data to target the VE tax chart grid
- Split Payment account.taxes are Groups of Taxes whose children target VE38 tax grid
- account_tax's l10n_it_vat_due_date is no more, we base ourselves on the VE38 tax grid
- The Group of Taxes includes normal VAT and a reversed VAT entry (for sale)
- Tax checks on the invoice now also check group of taxes with flatten_taxes_hierarchy()
- New Split Payment tax group has been added to build the correct totals in the move form view
- account.taxes and account.fiscal.position has been added to change from VAT to VAT Split Payment automatically when you select a res.partner that features the fiscal position.
- The Fiscal Position also has the law-required note that has to be featured on invoices that use Split Payment
- A PA business demo partner is added to showcase the new fiscal position
- `l10n_it_stock_ddt` tests are minimally modified because the Form component didn't let you use 'like' in the move form view
Task link: https://www.odoo.com/web#id=2823645&model=project.task
task-2823645
X-original-commit: 90d9250c66d59184a795041b8f1b7849c3b6db5f
Part-of: odoo/odoo#134348
The _prepare_edi_vals_to_export functions on account.move and
account.move.line must be moved to account from account_edi.
Account_edi_ubl_cii does not depend on account_edi anymore,
and needs them.
closesodoo/odoo#131801
Signed-off-by: Josse Colpaert <jco@odoo.com>
The visibility of the "Print" DDT button wasn't taking into
consideration the dropshipping case.
closesodoo/odoo#122328
X-original-commit: 8a45ae0842a6ac08b321e44113896581d9af42bd
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@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>
In case we retrieve the maximum number of documents the IAP server
can send, we retrigger the cron to receive more documents, until
we get them all.
Parameter `recipient_codice_fiscale` wasn't used at all, download is
related to the proxy user which is determined by authentication on the
IAP proxy.
See odoo/iap-apps#583closesodoo/odoo#116927
X-original-commit: 43c9820b1d3020d89b1b7ca016754e29d1fc6b58
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Added views and menuitems for account_edi.document
and account_edi_proxy_client.user, so that our technical team
will be autonomous in its investigations.
Task link: https://www.odoo.com/web#model=project.task&id=3204255
Task-3204255
closesodoo/odoo#115751
X-original-commit: 5e771b131e85b42a747936daf698f62fe2b125b5
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Every imported vendor bill now will have the chance to make its invoice_origin linked to a Purchase Order.
The function is moved from account_journal to account_edi_format to allow the link being done from all webservices, thread attachments and upload.
- Avoid mocking the proxy testing
The test on the check that the same attachment is coming twice from the proxy doesn't actually need to test the proxy. By splitting the function, we avoid mocking the proxy for no added value. Added an ir.rule for companies to only look for their account_edi_proxy_client.users
- PA Index label should be Destination Code
PA Index is a completely wrong description. This is the destination "address" of the partner at which our EDI documents (invoices) should be directed to inside the SdI e-invoicing system, much like an IP address. It's not an index, doesn't have much to share with the Public Administration. The correct literal translation of the name should be "Destination Code"
for Codice Destinatario. We have clients opening tickets because they don't recognize this field on the partner form because of the wrong translation.
- Fixes on taxes import
Lines didn't have their taxes cleared, so invoices actually added the taxes in the XML to the default supplier taxes of the product VAT taxes on import search was conflicting with actual withholding / pension fund taxes, so extra conditions are added in the search if withholding / pension fund fields are not specified
Task link: https://www.odoo.com/web#id=3175353&model=project.task
Task-3175353
closes odoo/odoo#114870
Forward-port-of: #111365
Signed-off-by: Josse Colpaert <jco@odoo.com>
If an invoice is send to the Tax Agency, we should block the fact
that the user can delete it. In that case, we can have issues when
the tax agency sends back notifications.
Task link: https://www.odoo.com/web#id=3192962&model=project.task
Task-3192962
closesodoo/odoo#114872
X-original-commit: c11a512af4e467068c6b228bf55225e5e43d7811
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
In some cases, Odoo's move state is unaligned to that on the
IAP Proxy Server, because the ACK message from Odoo to IAP
deletes all attachments from the EDI transactions on the IAP
without regard if they are with type "Send" or "Receive".
We fix both cases by making Odoo just look at the state and not
to the attachment when it's not needed, and it's only needed when
there is a rejection of the document being sent.
We reserve for the future a change to the ACK to only delete the
attachments by transmission type (Send/Receive) so that they don't
interfere.
Error case 1:
- Odoo client sends an invoice to the IAP Proxy
- The IAP proxy will send it to the SdI
- If everything goes well, the SdI will send a notification back
- The IAP proxy sees the notification and saves it
- The Odoo of the client downloads the notification and sends an ack
- The IAP proxy sees the ack and deletes the attachment
- (ERR!) The client resets to draft, modifies and re-confirms
- The state of his invoice is set again To Send
- Odoo tries to re-send the invoice with the same Id Transaction
- The notification for that Id Transaction is already on the IAP proxy
- Odoo client asks for changes, but just sees the old notification
- (-->) The old notif. has no attachment, so Odoo thinks there's no news
- The move in Odoo stays in the To Send state forever
Error case 2:
- Odoo client sends a Tax Integration for a Vendor Bill (reverse charge)
- The IAP proxy will send it to the SdI
- If everything goes well, the SdI will send the same Vendor Bill back
as the client's CodiceDestinatario is actually the recipient in the XML
- The IAP proxy sees the file, the Id Transaction is the same
for both the received and the sent documents
- The SdI sends a notification because the tax integration is OK
- The IAP proxy saves the notification, there are now two EDI
transactions with the same Id Transaction.
- Odoo checks for new documents
- IAP proxy sends the document to Odoo
- Odoo sends an ACK for that
- (ERR!) the IAP proxy sees the ACK and clears the attachment
from BOTH the records for sent and received document
- Odoo checks for documents updates and gets the record without
the attachment
- (-->) The notification has no attachment, so Odoo thinks there's no news
- The move in Odoo stays in the To Send state forever
Ticket link: https://www.odoo.com/web#id=3194378&model=project.task
opw-3194378
closesodoo/odoo#114051
X-original-commit: f85744ee4533ea8593b81a88ef200ec4dc1b1b94
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
If there's a l10n_it_edi_transaction id on the move, then the move
has been sent to the SdI and it has received no rejection yet.
So we avoid showing the Reset To Draft button in that case.
Task link: https://www.odoo.com/web#id=3191726&model=project.task
Task-3191726
closesodoo/odoo#113694
X-original-commit: dc088f2dabc369a3c7a00be7d20e81a56aeffef5
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
- l10n_it_edi: EDI receiving cron error handling fix
If we cannot receive invoices or bills from the IAP proxy we also can't
iterate over them
- l10n_it_edi: Check edi_format before trying to remove signature
The edi_format must be checked before trying to remove the eventual
PKCS#7 signature from the file, otherwise we're uselessly going to try
and remove the signature for every edi_format check (facturX etc.)
- l10n_it_edi: .p7m files can wrongly be missing the signature
In the case that the .p7m extension is put by mistake, try to use the
content of the file as it is before discarding it.
Task link: https://www.odoo.com/web#id=3189457&model=project.task
Task-3189457
closesodoo/odoo#113451
X-original-commit: 942e3c7f2b549fed86f9eb76f98f30b7e5db1ae9
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
If the business is incorporated, both these fields must be present.
We don't have a field to know whether the business is incorporated,
but in any case the fields must be both present or not present.
opw-3127832
closesodoo/odoo#112366
X-original-commit: b3de98d4dd248f56461f735a6cae143296a96a0a
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>
Dates in FatturaPA are in ISO 8601 date format: `[-]CCYY-MM-DD[Z|(+|-)hh:mm]`
Data like `2021-01-01z` or `2021-02-05+01:00` did break the checks.
closesodoo/odoo#109838
X-original-commit: 9e50fa08a74fa842aa3a2f37dfe5b38707a50cba
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
The EDI cron was broken since we applied the batching to the EDI documents processing in this PR: #99227
Now we enable processing multiple invoices at a time.
closesodoo/odoo#109699
X-original-commit: 2e37dfcc22424a61127571254dc09eb615a09eb1
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
The currency field shows as a badly aligned "in USD".
This PR adds a proper handling of the combinations
of accounting and multi_currency groups.
Original PR in v15: https://github.com/odoo/odoo/pull/104013closesodoo/odoo#108101
X-original-commit: d2363794411bbc9147b8ff0d519d588a3814e582
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
There's a demo vendor bill that is fixed on the 2018, while it
sure should be set at more than an year ago, but not in a fixed
point in time that keeps getting further away from the present moment.
Task link: https://www.odoo.com/web#id=2732449&model=project.taskclosesodoo/odoo#107112
Signed-off-by: Quentin De Paoli <qdp@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>
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>
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>
When using the "Holes in sequence" shortcut on a journal
in the Dashboard, the "Create" form shows the Miscellanous Entries
journal as a default instead of the same Journal that the user
trying to fix.
https://watch.screencastify.com/v/kUorLSIHwoy97UKuDJBCclosesodoo/odoo#101926
X-original-commit: a8f9950d6d55137f9c9de15042f6cb717e4a7140
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@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>
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>
Fixed the TestPurchaseInvoice.test_double_validation and the setupClass
to use test accounting data in setupClass instead of the demo data.
closesodoo/odoo#89370
X-original-commit: a7546aead36c5d56809fcd9c46b2a552991b5449
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@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>
Duplicate sending should be considered as positive outcome.
We also post a message on the invoice to make the user aware.
closesodoo/odoo#87292
X-original-commit: b49210bdf507850306d6f19306ea8cd6a91e3316
Signed-off-by: Josse Colpaert <jco@odoo.com>
In the B2B case, after a MancataConsegna, the invoice is considered
issued, but the delivery is failed.
In the B2G case, the Exchange System will retry to send it for 10 days
and inform the Public Administration. After 10 days, it will be
considered issued but not delivered.
In both cases of failure, the user is required to send the invoice
through other means than the Exchange System.
Ref (IT): https://www.datalog.it/fattura-elettronica-cosa-fare-in-caso-di-mancata-consegnaclosesodoo/odoo#85100
X-original-commit: e8e08aba971cbf688b09f39cf3b3e4bc75641e84
Signed-off-by: Florian Gilbert <flg@odoo.com>
- A new flag is added to the Setting (l10n_it_edi_sdicoop_demo_mode)
that is computed from the ir.config_parameter
'account_edi_proxy_client.demo'.
If the flag is 'demo', Odoo will not send invoices through the EDI,
if the flag is 'test', Odoo will send invoices to an IAP test server
instance that operates with a test SDICoop service
if the flag is 'prod', Odoo will send invoices to production IAP,
that routes them to the official SDICoop service.
- Some minor UI rework for the EDI parameters on res.company
The EDI settings in the res_company form, under the
'Electronic Invoicing' tab, must stay on the left
closesodoo/odoo#84925
X-original-commit: c5d049c55d21f9885e79182df2bd5f433c5bb782
Signed-off-by: Josse Colpaert <jco@odoo.com>
The title's (S)CSS selector was failing to pick up the invoice title,
because it was inside the .swiss_container_v2 while it should be out of that.
opw-2584899
closesodoo/odoo#80873
Signed-off-by: William André (wan) <wan@odoo.com>
When the Reconciliation Model had a tax on the writeoff,
the journal_id wasn't populated by widget.get_reconciliation_dict_from_model(),
preventing the reconciliation from happening.
opw-2689002
closesodoo/odoo#81396
X-original-commit: 17a1c960cc3cce1850a6009ebf9641174e0304fb
Related: odoo/enterprise#22891
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Reworked the structure of the HTML and the SCSS
to adhere to the official specs:
- 5mm padding inside the two main sections
- Correct font sizes
- Bold headers
- Increased the Swiss Cross inside the logo (7mm x 7mm)
- Scissors pictogram on the outline
- Dashed borders
Sizes now take the wkhtmltopdf (1/1.25 factor) shrinking
into consideration.
closesodoo/odoo#80544
X-original-commit: f02622684c6a220a425044d8d4a5fd474efdb519
Signed-off-by: William André (wan) <wan@odoo.com>
closesodoo/odoo#80668
X-original-commit: 3ae0b21f4b269859dc41ab6851e2e6e52b6b2e11
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
When a submodule overrides an old UNIQUE constraint with a new one,
records in that module may respect the new one and not the old one.
As the old module is updated, it would fail giving an ERROR message,
and therefore blocking the Odoo.sh deployment pipeline.
i.e. website_sale (old): res_users_login_key -> ['login', 'website_id']
base (new): res_users_login_key -> ['login']
With this patch, the error level is changed from ERROR to WARNING,
leaving Odoo.sh free to continue the build deployment, as the error
was not a blocking one.
closesodoo/odoo#79199
X-original-commit: 8ed3641f81502d3a7e9c9bb93771c6f5601a31a9
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
quotation_description on the sale order is copied from the
product template, where it already is sanitize_attributes=False,
and it has to stay like that because otherwise widgets like
"tab" or "accordion" cannot be rendered correctly.
This is also linked to a bug in the ORM where the _related_attrs
weren't copied correctly.
Related ORM PR: https://github.com/odoo/odoo/pull/78687
Ticket link: https://www.odoo.com/web#id=2487749&model=project.task
opw-2487749
closesodoo/odoo#78836
X-original-commit: ee90f6bcea35350efa9eae8db749199b39ff5644
Signed-off-by: Paolo Gatti <lordkrandel@users.noreply.github.com>
There is a test_mode to allow experimentation on the IAP server.
To be able to switch between the two, we need to make the
SERVER_URL configurable.
closesodoo/odoo#77977
X-original-commit: 11be1b25c60ae27a5e8078802883a1db867a6452
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Paolo Gatti <lordkrandel@users.noreply.github.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
Armageddon tax being created should include mandatory country_id,
which should be the fiscal country of the test company.
closesodoo/odoo#77295
Related: odoo/enterprise#21208
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
"account_tax_group.xml" and "account_data.xml" data files
have been renamed to "account_tax_group_data.xml"
when containing only tax groups, for compliance with the standard.
AE, AR, AT, BE, BO, BR, CA, CN, CR, CZ,
DE SKR03, DE SKR04, DO, ES, FI, FR, GR,
GT, HN, IL, IN, LT, MA, MX, NL, NO, PA,
PL, PT, RO, SG, SY, TH, TR, UA, UY, VE,
VN.
Part-of: odoo/odoo#77295
Many changes involved several localizations.
Tax groups data files that were missing the country_id:
AR, AU, EC, ET, HR, HU, IT, JP, LU, MN, NZ, SI, UK, ZA
Account_data.xml files being renamed or split to account_tax_group.xml
AT, CH, CL, PE, SK
Tax templates that were missing tax group information:
CH
Tax groups missing that were added:
EC
Part-of: odoo/odoo#77295
L10n_co taxes still needed their correct tax_group,
which has recently become a required field.
The tax groups have been assigned by rate and type.
Part-of: odoo/odoo#77295
The account.tax_group_taxes is the default group for every localization.
Its name shouldn't be overwritten by any localization, otherwise
any company actually using another localization will see the
name of the tax group in a language he doesn't understand.
Part-of: odoo/odoo#77295
The partner created in TestOnchangePostal and the product created in
TestSwissQR were taken from demo data, which might not be installed
in the test environment, so the create_invoice() method could
raise a traceback.
Part-of: odoo/odoo#77295
Paolo Gatti (pgi)