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>
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>
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>
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>
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>
How to reproduce the bug ?
- install point_of_sale,l10n_mx_edi
- In Point of Sale > Settings, add at least one Payment Methods
- Still in Point of Sale > Settings, create one Point of Sale
- In Point of Sale > Products > Products, select one product.
- In the Accounting tab of the product, set the UNSPSC Category.
- Go back on the dashboard of Point of Sale and start a new session.
- Add the product you have selected before and go to calidate the
invoice.
- Pick a payment methode and a costumer and check the invoice option.
- Validate the invoice.
- Close the session and go to Point of Sale > Orders > Orders.
- Click on the order you have just created and click on Invoice (in the
top right corner).
- Reset the invoice in draft.
- Wait for the cron task to be executed or execute it manually.
What is the bug ?
The cron task that send all the edi documents doesn't consider the state
of the account_move linked to it. Because of that if an invoice poster
is reset to draft, it will have a document and this document will be
sent.
opw-2925137
closesodoo/odoo#97648
X-original-commit: b27ff3c3c610102b2254acbad3801f21f0b36ef3
Signed-off-by: Adrien Minet <admi@odoo.com>
Signed-off-by: Josse Colpaert <jco@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>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
When creating a bill from a bill mail alias, we can end up with a tax or a product from another company
inside the bill. This can cause access issues afterward.
Here is a use case:
- Setup with 2 companies -> A and B
- Both companies have a 21% tax for purchase but the tax from company A has a lower sequence number
- Create an invoice in company A with a 21% tax and print the PDF
- Send the PDF by mail to company B
- The bill generated from facturx will have the purchase tax from company A
=> access error when it's opened
We use 'with_company' function with 'self.env.company' to imply a company to search into but this lead to
two issues when the generation comes from a mail alias.
1. 'self.env.company' may not be the company of the invoice
2. 'self.env.su' is set to True -> company constraints from the environment are not applied
This commit aims to change those two problems.
opw-2752673
closesodoo/odoo#96026
X-original-commit: b706eb6333913fb6c39cfa941f00c4bf499dfa3d
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Beckers Thomas (tbs) <tbs@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>
An enterprise module adds the possibility to upload bank statements.
Since the mechanism is exactly the same, we should use the same
functions.
closesodoo/odoo#83639
Related: odoo/enterprise#25123
Related: odoo/upgrade#3460
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Issue:
When receiving a mail with a facturx XML file as attachment,
the datas in the XML files are not parsed.
Cause:
For security reason, if a mail attachment is a XML file, it will
be saved as plain text and therefore not be parsed.
Solution:
If attachment mimetype is `plain/text` and content starts with
`<?xml`, consider attachment as XML for the parsing.
opw-2655445
closesodoo/odoo#91609
X-original-commit: c402815652cedae1c0934edeefac7cd547b12d0a
Signed-off-by: William André (wan) <wan@odoo.com>
The _get_unece_code method does not work in case where a specific uom
has multiple xml_ids.
Change it to handle such case and try to match every xml ids with a
unece code if possible.
closesodoo/odoo#91076
X-original-commit: d488b3cde3701b5eb69ac36cb6bbcc913956a0d4
Signed-off-by: Florian Gilbert <flg@odoo.com>
The xml we generate for factur-x is no longer compliant with all
the latest standards. With these changes, we are providing the tools
to make it work once again and make sure it is validated by the
factur-x and zugferd validators in all aspect (PDFA/3, XMP, XML)
It should also be valid to be sent to Chorus pro if applicable.
This adds a mapping to the UNECE unit of measure codes for uom, that
are required for factur-x.
It will also calculate a category for each taxes as such:
- If the tax is an export from EU to outside EU, G.
- If the supplier and customer are both in EU but different country,
K
- If both are in EU, in the same country but the tax amount is 0, E
- Otherwise, it will be S.
See https://unece.org/fileadmin/DAM/trade/untdid/d16b/tred/tred5305.htm
opw-2714544
closesodoo/odoo#90105
X-original-commit: e1bfb363bccd7b84f660d1e6c5b1e4d4fe02d398
Signed-off-by: Laurent Smet <las@odoo.com>
For the Switzerland localization, we need to append some extra pages during the PDF generation such as QR barcodes or ISR payment slip.
There were multiple difficulties with the current codes:
- The ir.attachment was generated before the hook allowing to append the extra pages.
- There is no existing hook allowing to get the pages for each invoice when printing on multiple records at once.
This commit aims to dispatch the generation of PDFs from the creating of extra attachments:
- `_render_qweb_pdf_prepare_streams` is called first and creates a stream for each record containing the PDF pages.
- Then, the ir.attachment are generated if necessary.
- Finally, all streams are aggregated together to get the final PDF.
Task: 2726507
Part-of: odoo/odoo#85150
Before, when sending an invoice for the first time, it would give
a "cannot find savepoint" traceback upon wanting to release it.
We avoid that error by putting less code in the with statement,
so the savepoint gets released a lot earlier while the record
remains locked for the rest of the transaction.
We also put a nice error message if the user can not send at the
moment because another process is already sending. (might happen
more often in v15)
We also updated the translation .pot as we added a new message
and some messages were missing anyways in the .pot, so we added
those as well.
closesodoo/odoo#86317
X-original-commit: a135ef6c78a5ddd1eed36bbb91ee01d82c18e592
Signed-off-by: William André (wan) <wan@odoo.com>
Yolann Sabaux