The default taxes for most localisations have been left undefined by
default. When loading the chart template, the model generally selects
the first sales and purchase taxes, based on the order in which the
taxes appear in the csv, for the default sales and purchase taxes
respectively.
This behaviour can be confusing to those who are not yet familiar with
it. It has been decided that it is preferable instead to specify the
default tax in _get_*_res_company function on the account chart template
model, such that the default taxes are defined explicitly for every
localisation.
task-3453997
closesodoo/odoo#130733
Related: odoo/enterprise#45531
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Edi format is going to be removed eventually - `account_edi_proxy_client` should not depend on it and be more flexible in general.
This commit:
- Removes edi_format field from `account_edi_proxy_client.user` model. We still have to add them in `l10n_it_edi` as it still heavily relies on edi format for now.
- Adds a way to have a unique edi user per company, proxy user, edi mode combination.
This is a necessary step before adding peppol, which will also depend on the account_edi_proxy_client
closesodoo/odoo#116059
Related: odoo/upgrade#4458
Signed-off-by: Laurent Smet <las@odoo.com>
Refactoring send&print wizard.
==============================
Main reason for this commit is that we want to let the user
decide when to generate the relevant documents / approvals
for its invoices. The natural choice is when the information
leaves Odoo. So now, each time the users decide to
download/send its invoices, he will be able to select the
relevant documents to be generated and the approvals to be
requested from the send&print wizard.
This used to happen automatically during the posting with lots
of undesirable behaviors (difficulty to update/revert, hard to
know exactly what will happen,...)
Main changes:
1/ Send&print wizard
- The model 'account.invoice.send' has been replaced by
'account.move.send' and became models.Model to handle
asynchrounous generation of documents (webservice,..) in
case of more than one invoice.
- The wizard is meant to be overriden in order to add
checkbox and document to be generated. A comprehensive exemple
can be found in account_edi_ubl_cii.
2/ Import invoice from attachments
- The decoding logic has moved from account_edi to account
on the attachemnts.
- The function _extend_with_attachments() serve as a common
entry point for import (from chatter, dashboard).
3/ Export invoice pdf / document
- All the specific actions to export attachments should be
implemented on the account.move and called from the wizard in
_generate_documents()
- The official pdf for the invoice is now only generated once
the user request it. In order to regenerate the pdf and
documents, it needs to be deleted.
task-id: 3117238
[enterprise](https://github.com/odoo/enterprise/pull/36757)
[community](https://github.com/odoo/odoo/pull/111857
)
[IMP] web: enable close on ir.actions.act_url in wizard
Before this commit, calling ir.actions.act_url on a modal
leaves the modal open. Which feels ackward in the send&print
wizard.
We now enable 'close' parameter on ir.actions.act_url. If set,
the wizard will close after act_url.
closesodoo/odoo#111857
Related: odoo/enterprise#36757
Related: odoo/upgrade#4387
Signed-off-by: Laurent Smet <las@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>
PURPOSE
Purpose of this task is to cleanup attachment management done in generic mail
models overrides and move it in account as model overrides.
SPECIFICATIONS
Account_edi and various l10n submodules hold some custom code to generate and
handle EDI attachments. It is used to add attachments linked using AccountMove
specific 'edi_document_ids' field when sending emails based on templates.
Currently MailTemplate is overridden in accounting modules to hold code related
to AccountMove and AccountEdiDocument attachments manipulation. This is linked
to EDI and report naming, not mail specific. This should therefore not be
implemented at template level, but in those specific models.
For that purpose we introduce a method in MailThread that allow to handle
attachments when being in a template context. An override in account_edi
allows to implement its specific behavior.
By the way an old docstring in l10n_it_edi that was quite unrelated to the
override is also removed, as it was more confusing than helping.
Task-2792146 (Mail: Move model-dependent code from composer / template)
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#106658
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>
- Support for account_edi workflows (only import) + fattura_pa as an account.edi.format.
- XML containing multiple invoices cannot be imported from the chatter.
- Generate e-invoice in xml when validating invoice
- e-invoice is sent via PEC mail and attached to the invoice
- electronic vendor bills and error/receipt messages can
be received through an IMAP incoming pec server
(configured in settings > technical)
We use the pec mail system to send invoices. We don't manage
signed invoices for B2G.
Configuration is done on the company and the receiving partners
should have the correct codice fiscale / TVA. On the taxes,
you might need to configure the exonerations.
You will need to configure the government mail address on the
company. (sdi01...) You might need to modify after the first
incoming message.
closesodoo/odoo#30845
Daniel Kosky (dako)