Steps to reproduce:
- install l10n_it_edi
- create a bill and set the move line with a tax "RC"
- confirm
-> the blue banner edi appears
- reset to draft
- change the tax to a non "RC" tax
- post the bill
Issue:
Despite resetting the bill to draft state and rectifying the tax configuration, the document could still undergo unintended processing as a Reverse Charge Bill.
Solution:
Reverse Charge bills, particularly those involving Intra-EU transactions, mandate that the VAT be paid by the buyer rather than the seller.
Italian EDI regulations necessitate the submission of such bills to the Tax Agency, specifying the buyer's tax obligations through a process known as tax-integration or self-invoicing.
In cases where an incorrect Reverse Charge tax is mistakenly applied to a domestic vendor bill, the existing issue becomes evident.
Even if the bill is Reset to Draft and the incorrect tax is removed, the associated edi_document will still be existing and will still have its "to_send" state. Consequently, the Scheduled action incorrectly attempts to send it.
This commit rectifies the problem by ensuring that when a bill is reset to draft state, the associated edi_document is promptly deleted.
The document will be recreated only during the posting process, should it genuinely require submission to the tax agency.
opw-3281007
closesodoo/odoo#132752
X-original-commit: f2c973a970af947a0e77a5e835237b09f11bdf7e
Related: odoo/enterprise#46112
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
When selecting several invoices from the list view, it is possible to trigger an action to export all edi documents in a zip file. This commit fixes 2 different issues:
a) We want to be able to export edi documents that have not been sent. Therefore, we no longer filter for 'sent' and 'cancelled' edi documents.
b) We want to also export edi documents that have ubl format. These documents are, from 16.2, in another field on account.move and no longer part of edi_document_ids. This is the reason why we had to move the logic from account_edi to account to make it overridable to other modules. This new way of overriding the function will also enable other formats to be included in the export function.
task-3441449 (issue 1)
task-3439427 (issue 2)
closesodoo/odoo#131242
X-original-commit: f8654b3501aca6e5d77ced5f73cb351c61684cd2
Related: odoo/enterprise#45529
Related: odoo/upgrade#5032
Signed-off-by: Laurent Smet (las) <las@odoo.com>
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>
We change account_edi to be auto_install=False to avoid installing it when
it is not nedeed and create noise data that will always be empty.
It was previously auto_installed when Invoicing was installed.
Note that auto_install=['parent_module'] will automatically install the module
when 'parent_module' is installed (in this case the localization) AND install
missing dependencies (in particular here 'account_edi').
task-3454076
closesodoo/odoo#130997
X-original-commit: 2d2faafb744abdb09f199ab85f11d317ee1d065e
Related: odoo/enterprise#45337
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
With an mx company setup
Create Invoice
Validate CFDI
Click "Send & Print"
Issue: xml not in attachments
In e9e9081 FW-port for saas-16.3
`_get_default_email_attachment_data`
method was removed
opw-3419746
closesodoo/odoo#129414
X-original-commit: 1001f6b5c007360ad2ecd5408cad78a744bf3d36
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Since the dependency to account_edi has been removed from l10n_mx_edi
and knowing we plan to remove completely the account_edi module and
since it's the single localization needing an EDI on payments, all this
code can be removed.
Task: 3069324
Part-of: odoo/odoo#128395
Before commit:
After sending e-invoice, when requesting for edi cancellation, e-invoice is also
cancelled even if error in response.
After commit:
After sending e-invoice, when requesting for edi cancellation,
e-invoice is not cancelled in case of error in response.
closesodoo/odoo#129074
X-original-commit: 2af74c260a6223256e3a975f1378bfa25728edfb
Signed-off-by: Josse Colpaert <jco@odoo.com>
Goal of this pr is to improve the banner on top of all e-invoicing by shorten
the text and make it one line
task:3374897
closesodoo/odoo#125574
Signed-off-by: Josse Colpaert <jco@odoo.com>
With an mx company setup
Create Invoice
Validate CFDI
Click "Send & Print"
Issue: xml not in attachments
In e9e90811aeee46989a83b21f9b59071a9c7bc362 the name of method responsible
for loading attachment was changed from
`_get_default_mail_attachments_data`
to
`_get_default_email_attachment_data`
But the account_edi override wasn't changed so no xml was attached
opw-3370272
closesodoo/odoo#125275
X-original-commit: 0bf8296d74002ab691b809c484d38c3ead2c090b
Signed-off-by: Josse Colpaert <jco@odoo.com>
If applied, this commit will solve the 'NoneType' object is not iterable when
in _get_mail_attachment_from_doc function returns None.
Steps to reproduce the issue:
- Install Accounting and l10n_in_edi.
- Go to accounting -> Configuration -> Journals -> Customer Invoices
-> Advanced Settings -> Enable Electronic invoicing
- Switch company to IN Company
- Go to Account -> New invoice -> Add required fields -> Confirm -> Send & Print
sentry-4215675843
closesodoo/odoo#124346
X-original-commit: 84bcdcf6042a7d938803c95a6e0fe06f6e22aef9
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
THese are rarely intended for all users but often intended only for
employees.
account:
account.incoterms: only used within internal business models
account.journal.group: same as account.journal, add sudo in computed field
account_edi: need access to accounting objects
base_address_extended:
res.city: only employees should access address data
board: only employees uses this (old) module
crm:
crm.stage: internal users business object
hr_recruitment: employees can read
im_livechat: apply same as for the steps
l10n_ar: used on partner, not only invoices
l10n_ec: accessed only through account.move
l10n_latam: accessed on res.partner
mail:
publisher.warrenty.contract: no data, only static models
mail.channel: group_user has already his own rule
mail.group: group_user has already his own rule
mail.message.subtype: group_user has already his own rule
mail.message.all: remove, already has a portal and employee rule
partner_autocomplete: no interaction with public
project:
project.tags: only needed for project sharing
sale_management:
sale.order.option: same as sale.order
utm: employee already has write access
web_editor: test models that have nothing to do here
web_tour: only employees uses tours
website_sale:
product.ribbon: add sudo for access
base:
ir.default: only employees uses set (could probably be converted to group_system)
ir.ui.view.custom: same as ir.ui.view, add sudo when needed
report.*: portal users don't configure reports
res.users.log: create in sudo, no access needed (adapt test to use another model)
res.lang: still needed for public
closesodoo/odoo#118701
Related: odoo/enterprise#41285
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
With an EDI localization (MX)
Create 2+ invoices with edi attachments (xml)
In list view, select both and hit actions > send&print
Issue: EDI file will not be attached to the mail
opw-3330554
closesodoo/odoo#124446
X-original-commit: 9730a9753936f040a987505ed064cfd51acb50e0
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
With MX edi company setup
Create an invoice, validate cfdi
Register payment, validate cfdi
Action > Send receipt by email
Issue: payment xml is missing from email composer
opw-3289582
closesodoo/odoo#123168
X-original-commit: ed6c3c3a4a6c5c685e709734c536a5e4252b4eb8
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
As ir_cron_trigger are only processed for active crons, we should
not create them for inactive crons to avoid bloating the table.
Account_edi tests needed to be adapted to make sure the cron
ir_cron_edi_network is set up as active during the tests.
Backport e79b1a7: ([IMP] base: Garbage collect ir.cron.triggers)
closesodoo/odoo#118844
X-original-commit: a62275430e21f9e7e510913ac9afb25943da525b
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
The send and mail wizard was replaced by something simpler, but we
forgot to automatically attach the attachments of the edi documents
of the old account_edi in the mail.
Before, the XML of e.g. the Mexican EDI, generated when the invoice gets
sent (and signed) by the government, would not be included
automatically when the user wants to send the invoice by mail to the
client. Now, it will be.
closesodoo/odoo#119435
X-original-commit: b3cbd7ea2b6cc07efd9a6358bd37f23f1ba4e6ab
Signed-off-by: Laurent Smet <las@odoo.com>
Section "Electronic Data Interchange" should not be displayed for
account_edi_ubl_cii since it's empty. In addition, only display the
section in account_edi if some EDI are compatibles.
closesodoo/odoo#117901
Related: odoo/upgrade#4525
Signed-off-by: Laurent Smet <las@odoo.com>
Steps to reproduce:
- install any edi l10n
- create an invoice with edi xml
- try to print the invoice (this adds a pdf attachment)
- the attachment viewer shows whichever attachment added first
- it shows only the xml file name
Bug:
`_message_set_main_attachment_id` only works if there are no
`message_main_attachment_id` set.
Fix:
Override `_message_set_main_attachment_id` in the `account.move` module to
alter this behavior
OPW-3147811
closesodoo/odoo#117510
X-original-commit: 383834b11bf6b7a80848e5d238b12fa237b9edf3
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>
We need to wait the registry to be totally loaded to correctly recompute
the `edi_format_ids` field on all journals.
opw-3200644
closesodoo/odoo#117405
X-original-commit: b68882825aa917fc2cb64b6f083811398f7fa386
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Christophe Simonis <chs@odoo.com>
Enables the EDI postprocessing method to cancel non-invoice moves.
This is useful for entry moves such as withholds in l10n_ec
X-original-commit: 1c515e1f55ea675df3f6aace7f6537889779779c
Part-of: odoo/odoo#113302
Co-authored-by: Josse Colpaert <jco@odoo.com>
list view
In some occasions, we want to be able to download all edi documents so
the user can upload them on a governemental platform. From the list view
of all the invoice, it is now possible to selected as many invoice as we
want, and with a newly added action download them into a zip.
task-3122424
closesodoo/odoo#116854
X-original-commit: 5171f607e1fddde06b769ebb78d82548ad4dc84d
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@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>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Allow to perform multiple reconciliation at once in order to:
- ...batch the creation of records as much as possible.
Creating an account.partial.reconcile force the orm to search for amls in order to invalidate the reconciliation fields like amount_residual/amount_residual_currency.
- ...reduce the number of flush inside the orm and batch the compute.
Each call to reconcile is looking for the payment's state of invoices before/after the reconciliation.
This step is costly because this will flush all the reconciliation data and then call the computes to get the fresh value of payment_state.
- ...modify more easily the way the lines are matched together.
Before this commit, the lines were split into two batches sorted by some criteria including the currency: debit and credit.
Then, we were matching them together sequentially.
Now, we make the same things except we do that first for each batch of amls sharing the same currency in order to reduce the number of cross-currencies reconciliation.
- ...allow the orm to prefetch all the partials in the reconciliation chain all at once.
The full reconcile needs to be creating on the full reconciliation graph starting on the current amls so we need to travel the matched_debit_ids/matched_credit_ids in order to find all the involved amls.
Fetching all this data at once is also reducing the number of queries made by the orm.
Let's take an example:
Suppose 10 amls: a1, a2, ..., a10
Suppose 10 amls: b1, b2, ..., b10
You want to reconcile respectively a1 with b1, ... , a10 with b10.
Before this commit, each reconciliation was done as follow:
- Check the payment_state of invoice (on 2 amls)
- Create a partial reconcile (single record)
- Create a full reconcile (single record)
- Compute the reconciliation data to compute payment_state (on 2 amls)
All of that, 10 times sequentially.
With the new '_reconcile_plan' method, we are able to give a list of recordset [a1 + b1, ..., a10 + b10]:
- Check the payment_state of invoice (on 20 amls)
- Create a partial reconcile (10 records)
- Create a full reconcile (10 records)
- Compute the reconciliation data to compute payment_state (on 20 amls)
For a reconciliation using 2000 records (a1, ..., a1000 & b1, ..., b1000), the time to reconcile it was about +-34 seconds. Now, it's about +- 3 seconds.
closesodoo/odoo#113680
Related: odoo/enterprise#37543
Signed-off-by: Brice Bartoletti (bib) <bib@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>
To reproduce
============
- on accounting -> Vendor -> Bills
- upload the PDF attached on the ticket
an exception is raised
Problem
=======
PyPDF2 finds that this pdf is encrypted,so we try to decrypt it with empty password,
but the decryption fails which rise an error.
Solution
========
according to this [commit](https://github.com/odoo/odoo/commit/851fe64f7789bb398383c22e3ebbaebb051791f6), when the decryption fails
we skip reading the attachments and carry on to allow the user to upload the document.
opw-3196780
closesodoo/odoo#114269
X-original-commit: 124250d123666ea818d2c8004cadae2ccc43aa0e
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
Following odoo/odoo@44a4cdb, account.edi.document `attachment_id`
now is restricted, so force getting it's value as superuser.
X-original-commit: b805e90457ef57868b9742b622465ea823b05af2
Part-of: odoo/odoo#111839
When a vendor bill document is uploaded (EDI, PDF,..) the link with
the purchase order is often lost.
We want to reuse the purchase.order OCR' matching logic to enhance
vendor bill extracted from documents.
To sum up the logic;
- if we find a partner or reference match (invoice_origin)
AND the same amount, we use autocomplete and replace the line in the vendor
bill with the purchase order one.
- if we find a match with the reference and some line in the purchase order
sum up to the vendor bill total, we add those line in the vendor bill
but we set the qty to zero (the accountant can manually remove the XML
line and link the new one afterwards).
task-id: 2828521
[community](https://github.com/odoo/odoo/pull/109093)
[enterprise](https://github.com/odoo/enterprise/pull/35436)
update master: make _find_matching_subset_invoice_lines private
closesodoo/odoo#111491
X-original-commit: ebc8b007ecb375d20c566b6e6ecc3f6749ebaa2a
Related: odoo/enterprise#36545
Signed-off-by: Josse Colpaert <jco@odoo.com>
Following odoo/odoo@44a4cdb, `attachment_id` is restricted, so force
updating it's value as sudo() when posting an invoice having existing
EDI documents.
closesodoo/odoo#111426
X-original-commit: 6b101d5ff0ad78b9ae2ad312f362c2224e7af457
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
An attachment has complex access rights. If there is no res_model/res_id, the access rights are admin (not exactly but let's say that).
When an EDI like Facturx/E-FFF generates an attachment not linked to any model, you don't have access to it except if you are admin.
However, here we have a security issue since everyone is able to write any 'id' on the 'attachment_id' field.
If you do that using Facturx, knowing this EDI will embed its attachment inside the invoice PDF report in sudo mode, you have now a way to extract any attachment from the database including the ones you shouldn't have access to.
Furthermore, a different api introduced by OWL makes the form view of account.edi.document popping from the one2many inside the invoice form.
Instead of "options={'no_open': '1'}", the new api is now to put directly "no_open='1'" on the root node.
If you combine both issues above, you currently have a way to extract any 'attachment_id' from the database and odoo is kind enough to give you the form view to do it.
closesodoo/odoo#111210
Solution: "account.edi.document.attachment_id" is now accessible to the admin only.
X-original-commit: 44a4cdb3944a4b722dcfbca5e2947a4372b8501d
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
PURPOSE
Purpose of this task is to remove the _onchange_template_id method on composer
model. Split it into editable computed stored fields. It gives a better control
of value generation and avoid having to call the onchange when composer is
invoked in code.
SPECIFICATIONS
Remove onchange as it is not used anymore. All fields have been converted.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
When you have a journal configure to create add e-fff xml file to
integrate into the invoice, you get an access error when the user that
prints the invoice is not the same as the user that has posted the
invoice.
To avoid this issue, we are calling the '_prepare_invoice_report' with
an edi_document in sudo. The issue comes from that the attachment_id on
the account.edi.document has no res_id and res_model (to be hidden in
the chatter of the invoice). So to get access to such attachment, you
need to have the same 'create_uid' or being a 'Setting' user.
The issue was not present in saas-15.3 because the reports were executed
in sudo, so everything was accessible.
To easily reproduce:
- create a company in belgium
- activate E-FFF edi on the sales journal
- create and post an invoice with the user A
- print it with the user B (that is not an administrator
closesodoo/odoo#109702
X-original-commit: 87716488670b0ba4619d7e8c49e99dfd61ff88d7
Signed-off-by: William André (wan) <wan@odoo.com>
This commit aims at:
1. Fixing a bug where the invoice would be uploaded in the wrong journal
------------------------------------------------------------------------
To reproduce:
- Go to Customer invoices
- Upload an invoice (with an embedded FacturX)
- The journal is set to Vendor Bill
2. Letting the FacturX move type override the user-chosen move type
-------------------------------------------------------------------
Currently, if the user uploads a credit note in a customer invoice journal,
the document is not created and set to the OCR. This is due to a restrictive check
which has been removed. Therefore, when the move type is defined in the FacturX XML,
we will use it to override the user choice so that the document is always created
within the right journal.
3. Harmonizing the invoice upload between the Accounting and the Documents apps and avoid code duplication
----------------------------------------------------------------------------------------------------------
Currently, the flow of uploading an invoice from the Accounting app and the Documents app is different.
Indeed, if one uploads an invoice in the Document app and click on the "Create invoice",
the document is sent directly to the OCR. Now, instead, we will pass this document to the same upload method
of the Accounting (which will try to create the invoice from the FacturX XML if present).
Therefore, the flow will now be the same from the two apps for better harmonization.
4. Adding a 4th button in the Documents app to create a Vendor refund
---------------------------------------------------------------------
Currently, there are 3 buttons to create a customer invoice, a credit note, a vendor bill, but no vendor refund.
This is due to a duplicate xmlid which has now been fixed allowing the 4th button to be seen in the UI.
5. Adding a button "Switch into customer invoice/vendor bill" button in the account.move's form view
----------------------------------------------------------------------------------------------------
Currently, the user has access to a "Switch into credit note/refund" but not the reverse button to
go from a credit note/refund to an invoice/bill. This is now the case.
Task id 2961932
closesodoo/odoo#103427
Related: odoo/enterprise#32890
Signed-off-by: William André (wan) <wan@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
Steps to reproduce:
- install a localization which uses the account_edi module;
- define Lock date for the fiscal period;
- choose an invoice which was sent before this date;
- click on the "REQUEST EDI CANCELLATION" button.
Issue:
We try to cancel the EDI document despite exceeding the fiscal period.
Cause:
The verification of the fiscal period is done when clicking on the "RESET TO DRAFT" button which, in the flow, is after the request for cancellation of the EDI document.
Solution:
Make a verification of the fiscal period when clicking on the "REQUEST EDI CANCELLATION" button.
opw-2990873
closesodoo/odoo#106096
X-original-commit: fda04e2153f541ddf88afc60be4662a0d78ea7ce
Signed-off-by: Josse Colpaert <jco@odoo.com>
The previous link was dead
closesodoo/odoo#103111
X-original-commit: 570fec0ae6f4441a6134c5b488d4b3c6b33f0466
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When computing the edi_formats on a journal, keep the ones
that are already checked (if they are compatible with this journal).
The bug occurs when migrating a DB: if a new edi_format is created,
the `create` will call the `_compute_edi_format_ids` on all journals.
Thus, all edi_formats will be reset since nothing keeps track of the
already checked edi_formats. This PR fixes this.
closesodoo/odoo#102368
X-original-commit: 166aaeef1ca69399581714b61ea77db7c3e04f31
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Add a new method `_get_move_applicability` allowing to trigger the EDI on any journal entry, using the custom functions you want.
closesodoo/odoo#101985
X-original-commit: 0e5626ca5126e6fea7fb95b694229948540764d7
Related: odoo/enterprise#32212
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Issue: When a user create -> confirm and then set the invoice to draft, Another user even
with right access (in the case Billing right on the accounting access) cannot cancel it
Steps to reproduce the bug:
1) Login with admin user having administration rights set as ‘setting’.
2) Inside Customer Invoices Journal Electronic Data Interchange -> Electronic invoicing -> Set/Enable to ‘Factur-X (FR)’
3) Create an invoice ( Ex. INV/2022/00001) with admin user -> Confirm -> Reset to draft.
4) Login with the billing user (Accounting rights set to ‘Only billing rights’)
5) invoicing -> Open Invoice ( Ex. INV/2022/00001) -> Try Cancel invoice ( Ex. INV/2022/00001) without confirming it.
6) Access Error will be reproduced.
7) Go to Customer Invoices Journal -> Electronic Data Interchange -> Electronic Invoicing -> Uncheck ‘Factur-X (FR)’ -> Save.
8) Repeat above mentioned steps again -> No Access error came this time.
Solution: Give the right access to unlink an attachment from set to draft invoice.
opw-2925207
closesodoo/odoo#100245
X-original-commit: 8f61715e9048d7bb066d008c3993766e2c537db9
Signed-off-by: Grazioso Andrea (agr) <agr@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>
Odoo attaches factur-x doc to every invoice pdf. That data can be used to upload
invoice to another Odoo instance.
On uploading such an invoice, Odoo tries to find product in its DB. But it
doesn't work if original product has Sales Description which is by default
copied to line's Description (field `name`).
Fix it by searching by first line in the name value of factur-x. Product name
doesn't contain \n symbol in most cases anyway.
This commit doesn't fix factur-x doc generation because of stable version
policy. In next Odoo release we should use separate factur-x attributes for
product name and invoice line description.
opw-2878530
closesodoo/odoo#99006
X-original-commit: c5e08b8dcb9041235721afb99a5d05a0f51789e4
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
The "Process now" button throws a UserError if doc is already processing
=> but only thrown if parameter with_commit=False
PR odoo#87266 changed with_commit default value for test purposes
=> accidentally prevented the UserError from popping up
This PR restores with_commit default value for button action
=> User now gets the expected UserError pop up
closesodoo/odoo#98618
X-original-commit: 451fbfb356e9f7941180d14796afeb161fa09660
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Stanislas Gueniffey (stgu) <stgu@odoo.com>
Currently, the EDI attachments *content* is passed to the Send & Print wizard.
Then, the wizard re-creates these attachments and link them to itself. At the
end of the flow, when clicking 'Send & Print' button on the 'Send & Print' wizard,
the attachments of the wizard are copied on the move.
Thus, the EDI attachments are duplicated.
Passing the ids of the EDI attachments rather than the content solved the issue,
since they are simply linked to the wizard, without being re-created.
task-2957823
closesodoo/odoo#98447
Related: odoo/enterprise#30596
Signed-off-by: Laurent Smet <las@odoo.com>
This function was used to check the presence of the new module
`account_edi_ubl_cii`. The purpose was to use this module to render the xmls
for the existing modules: l10n_be_edi, l10n_no_edi, l10n_nl_edi... which used
outdated qweb templates (see https://github.com/odoo/odoo/commit/72c4972efd3f31bd86d100f160a530cc70400617).
After version saas-15.4, these old modules were removed and `account_edi_ubl_cii`
is used instead. Thus, `_is_account_edi_ubl_cii_available` is no longer used.
closesodoo/odoo#98208
Signed-off-by: Laurent Smet <las@odoo.com>
Yolann Sabaux