Fix in cc67b5ac95 was done in v14
originally and would lock both the edi document and the
account move instead of just the edi document
(and the move while cancelling)
However in the fw-port in 5319b71b66,
some kind of mix happened.
We have some tickets in v15 however where the
invoice is sent to the government, but it was not changed in Odoo because
of the concurrent access on the account_move, so we need to lock the
account_move as well.
opw-2714559, opw-2663502
closesodoo/odoo#82254
X-original-commit: 8d896b19007a788d88f2ffb45385f0d10cb476b5
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
This solution is not perfect. In order to be, we would need to have a
sanitized function that is used to store the number in the database, and
to use the same function to search in it. This will most likely be done
in master with a refactoring of `base_vat`, on which `account` will
depend one way or another.
In the meantime, we need to support cases that were working before these
fixes:
https://github.com/odoo/odoo/commit/bfb2436b9d99bf9eea29ee44000e18197efa88b6https://github.com/odoo/odoo/commit/e24c5ba4efef466919735ec4304cfd46be5f0d3f
Since these, it was indeed impossible to detect a partner based on his
VAT for Swiss partners if `base_vat` was installed, which is the
default.
closesodoo/odoo#81263
X-original-commit: 04aa5cd79c6aca1615ba022c351054a390e6c0b5
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
- allow to match a partner having 'BE0477472701' as vat but '477472701' inside the xml.
- code cleanup as suggested in the original PR
Introduced by https://github.com/odoo/odoo/pull/80266closesodoo/odoo#81237
X-original-commit: 598bfedb540aa81676b957340255aafef85d2823
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
When assembling the email we are leaving the assignment of the attachments
to another method that we can inherit and then modify instead of doing it
in the same method to attach them.
The idea is that in any localization we need only to modify that method
in order to add new attachments to the mail template.
closesodoo/odoo#80490
X-original-commit: 6f2e7dc3e8c468bcdb0862468eb08b65ce40c983
Related: odoo/enterprise#22568
Signed-off-by: Laurent Smet <las@openerp.com>
When using EDI, documents often fail to be submitted to the relevant API. This provides the ability to generate and download the XML
Task-2669041
closesodoo/odoo#80088
X-original-commit: 6eba7935c4d4f0fef5e1e7ad9b1d7726aa3db109
Related: odoo/enterprise#22392
Signed-off-by: Laurent Smet <las@openerp.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
In some flow like subscription, invoices are sent by mail automatically to the customer.
Sometimes, the invoice must be approved by the government before sending the mail like the Mexican EDI.
This commit aims to add a custom method to detect when an invoice is ready to be sent to the customer.
PR (community): https://github.com/odoo/odoo/pull/78714
PR (enterprise): https://github.com/odoo/enterprise/pull/21809closesodoo/odoo#79504
X-original-commit: 3a29371eb70309f46e3b8938434287fefc23b351
Related: odoo/enterprise#22171
Signed-off-by: William André (wan) <wan@odoo.com>
1. Configure MX company, make sure testing certificate and vat are loaded into the company
2. Sign an invoice with 16% included in price
No errors will be shown but opening the resulting CFDI xml will show a
discount "Descuento" equal to the tax amount, which is incorrect
opw-2665082
closesodoo/odoo#79501
X-original-commit: 3f58aefe607e562044617e2c9dbecb1afd2de586
Related: odoo/enterprise#22170
Signed-off-by: Laurent Smet <las@openerp.com>
This module sends the taxes information (mostly VAT) of the
vendor bills and customer invoices to the SII. It is called
Procedimiento G417 - IVA. Llevanza de libros registro. It is
required for every company with a turnover of +6M€ and others can
already make use of it. The invoices are automatically
sent after validation.
How the information is sent to the SII depends on the
configuration that is put in the taxes. The taxes
that were in the chart template (l10n_es) are automatically
configured to have the right type. It is possible however
that extra taxes need to be created for certain exempt/no sujeta reasons.
You need to configure your certificate and the tax agency.
closesodoo/odoo#76615
Task: 2492978
Forward-port-of: https://github.com/odoo/odoo/pull/70302
X-original-commit: ff4cb972b6a8b61caeac13d8eb5c6a4d43a62ccb
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Also, remove the duplicated 'edi_document_ids' field inside the view.
'edi_document_ids' is now in debug mode for payments.
closesodoo/odoo#76123
X-original-commit: ad346eec9fd06e430b9b5859578b00e0b28cc443
Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
In some reports, we need to detail the taxes for each journal items.
This is the case of all EDIs, the SAFT-report, l10n_in etc.
This task adds an SQL view mapping each tax lines with their corresponding base lines and computing the tax_amount and base_amount.
closesodoo/odoo#70866
Task: 2352524
Related: odoo/enterprise#18344
Related: odoo/upgrade#2686
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit, for an EDI to be successfully posted, returning an attachment from 'post_invoice_edi' was required. In some cases this caused problem:
- When an EDI is posted in two steps, sometimes the attachment is generated in the first step and nothing is returned until the second step. This forced to do some hack where the reference to the attachment in a seperate field to be able to return it after the second step.
- When an EDI doesn't have a file to return (maybe we just send data over an API and get a response without any file involved).
Now, the attachment are removed from account_edi flows. When returning from 'post_invoice_edi', it is still possible to return an attachment whose reference will be kept in the edi_document, but will not change the state of the document to 'sent'.
To make the state change to 'sent', 'post_invoice_edi' must return {'success': True}.
Nothing has changed in the 'cancel' flow, meaning that the buttons related to canceling or reseting an invoice to draft are now based on the state and not on the existence of an attachment on the document. Also, when an invoice is successfully cancelled, the reference to the attachment is STILL removed from the document, since the document does not represent an electronic invoice anymore.
closesodoo/odoo#70040
Related: odoo/upgrade#1946
Related: odoo/enterprise#13220
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
In some cases, non-generic operation needs to be done when retrying to process and edi.document.
For example : for web-services with two steps, if there is an error we need to restart the two steps (and therefore reset the internal state of the edi to the first step, typically by deleting the transaction_id). In case of a warning, we want to retry the second step. This can only be done in the non-generic part of the code, so a hook is added in `account.move`.
In some specific cases, a serialization error can happen on the account
move if it's not a move to cancel. If it happens, the full process
starts again for that move, which includes the requests sent to the
PAC in MX accounting.
It will send 2 CFDI files for the same invoices and the PAC will
interpret that as 2 different invoices, which is a problem.
This fix ensure that the concerned account moves are always locked
to avoid this kind of issue
opw-2489399
opw-2529134
closesodoo/odoo#73789
X-original-commit: bcc4934f80bea4ce70b9edfb22fd40030c5f0063
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit, only files coming through ir_server_mail where parsed. The goal of this commit is to allow upload of p7m files.
closesodoo/odoo#73337
X-original-commit: 13ff9b488d28da5dceec22e1c26f448796ca30c0
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
In account_edi, errors are shown as html, and might come from an external service if they are returned by a web-service.
X-original-commit: 261c037a602edb907a4c2018cf8b0c8cab0f2f63
When embedding to pdf, the name of the attached file should be 'factur-x.xml' (official specifications, section 6.2)
closesodoo/odoo#70442
X-original-commit: 04f4633d15f0a0824bd07f56a0f99491584f1a12
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
Before this commit, when an attachment was present in the xml (pdf) and the import was to create a new invoice, it crashed when trying to post the pdf on the not-yet existant invoice.
This commit also fixes:
- In the tests, `create_invoice_from_file` didn't handle the subfolder parameter correctly
- `create_invoice_from_file` now returns the created invoice
closesodoo/odoo#69722
X-original-commit: e81457501f4815a4d9add7a56a9dfe66a7656269
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
The Payment form view is simplified for a much less cluttered screen.
A paired internal payment is now created when an internal transfer is posted.
Task: 2403336
So, instead of waiting for the cron every hour, we create
a cron trigger, which is created/activated every time
we post/cancel an invoice. When the CRON worker is available,
it can take the job immediately.
To be sure that we don't miss any crons or that events
might be needed that are not triggered, we still launch the
cron every day.
A test was added to check that the crons are correctly
triggered.
closesodoo/odoo#67088
Signed-off-by: Josse Colpaert <jco@openerp.com>
Before, account_fiscal_country_id was only use for tax operations; and country_id was used for all the other accounting stuff. Now, with the new ability to use foreign tax reports (with foreign VAT fiscal positions), we can generalize the fiscal country, sot that it is the one that needs to be used for the whole accounting. Since foreign tax reports were not supported before, account_fiscal_country_id is already set on existing database as the country for the "main" accounting, so the impact of this change is small.
closesodoo/odoo#68349
Related: odoo/upgrade#2322
Related: odoo/enterprise#17299
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When we want to send the invoice to the client, a hack was made in account_edi
to make sure that we put the XML of the electronic invoice formats as well, in
the case of web services such that the client has the XML we sent to the government.
For MX however, we also send the payment to the government. However when we wanted
to send the confirmation about the different changes, we still needed to add the XML
manually before this fix. Now it should be added manually even when manually composing
the mail to the customer with the payment receipt confirmation. (but we hope it dies)
closesodoo/odoo#67315
X-original-commit: 327852a6399a19191bd78c820971cc4108dc7821
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
For odoo-master Transifex project, no demo data
closesodoo/odoo#66500
X-original-commit: 813931ac850e5ba4181259a5957ec72226fb670c
Related: odoo/enterprise#16510
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before the introduction of account_edi_extended and blocking_level, if an edi.document was in error, it was retried each the time the edi.documents were processed. With account_edi_extended a bug was introduced and only the document not in error were processed. This commit aims to restore the previous behavior.
Also fixes tests of account_edi.
See https://github.com/odoo/odoo/commit/a9a46cf09b0c841c7fda95b5ed03033fc6936ca2
X-original-commit: 385fa29322f6dffc7d7d0de96a1cfbddb0cab7f0
Before this commit, account_invoice_extract and account_edi where independent in parsing files uploaded or added as attachment in an invoice. Some tricks where used to avoid clash, but they were not perfect and some bugs appeared like the OCR not triggering automatically or an attachment being parsed twice by account_edi when parsing failed. The goal of this commit is to unify the import of files between the two features and ensure that they will not clash.
For more information about potential problems that appeared before :
See https://github.com/odoo/odoo/pull/61169
See https://github.com/odoo/enterprise/pull/15124/closesodoo/odoo#65660
X-original-commit: 8435d0e8990509ee67425977f970ab27bea8133a
Related: odoo/enterprise#16172
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
- Some errors will never get fixed until user intervention, it doesn't make sense to run the CRON when there is such error.
+ some small improvements and esthetic changes
- When we are in a CRON, we need to commit the changes between each call to web-service to avoid loss of data.
- Small refactor of edi.document prepare_jobs and process_jobs
- Added an arbitrary key to create the batches.
- On account_edi_document, lock the documents successively instead of all at once.
- Lock account_move that should be cancelled. Before, cancelling the invoice after cancelling it on the web-service could fail.
- Lock ir_attachment that might be unlinked. Before, attachments that weren't attached to any model could become unreachable but still present in the database when an invoice was cancelled or a new attachment was produced.
closesodoo/odoo#64946
X-original-commit: 8d0c25f359f92533eb25f2990d6e2aceef33b77a
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
This reduces the number of cache invalidation and recompute.
Because the full environment was not flushed anymore everytime, the test
:TestSaleProject.test_project_overview_by_project was failing.
closesodoo/odoo#49276
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Steps:
- Install accounting
- On the dashboard, try to upload an "encrypted" PDF like this one https://launchpadlibrarian.net/24827090/DS-0157.pdf
Bug:
Traceback:
PyPDF2.utils.PdfReadError: file has not been decrypted
Explanation:
In 13.0, these errors were caught in a catch all `except` as shown here: https://github.com/odoo/odoo/blob/4e089041252c25cc197a30f9e285d82f7162d809/addons/account_facturx/models/account_move.py#L303-L328
From this SO comment: https://stackoverflow.com/questions/52047944/pdfbox-extracting-blanks-from-pdf-encrypted-with-no-password#comment91054285_52047944
> A PDF can be encrypted with two passwords: a user password and an owner password. When a PDF is encrypted with a user password, you can't open the document in a PDF viewer without entering that password. When a PDF is encrypted with an owner password only, everyone can open a PDF without that password, but some restrictions may be in place.
From time to time, we get a PDF encrypted with an owner password. The
content is still readable, but PyPDF2 fails because it thinks the PDF is
encrypted. With this fix, we try to unwrap the PDF by providing an empty
user password. This way, PyPDF2 thinks the content is now decrypted.
However, PyPDF2 only supports decrypting versions 1 and 2 of the
encryption implementation. If the version is different, we skip reading
the attachments and carry on to allow the user to upload the document.
opw:2375993
closesodoo/odoo#64320
X-original-commit: 851fe64f7789bb398383c22e3ebbaebb051791f6
Signed-off-by: backspac <backspac@users.noreply.github.com>
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
this is more safe way than previously applied in
https://github.com/odoo/odoo/pull/62939
because it doesn't require ``-u account_edi`` in cases when it worked
correctly, i.e. when _compute_edi_web_services_to_process is called, but
computes empty string value.
Additionally, it fixes same problem in account.payment model.
---
opw-2414500
closesodoo/odoo#63543
X-original-commit: d393467886be1bd356a135e3fdc1ebb304c6614c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
- Before the fix, the banner with the button would show when the move is posted or in creation mode even though no async edi is associated to this move.
closesodoo/odoo#62974
X-original-commit: e18c3f023d10944b2cea9cd23703529b41ba48d3
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
Josse Colpaert