- 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>
With this commit, all instances of errors being raised inside
`BaseModel.unlink` overrides are moved into methods decorated with
`api.ondelete` which is safer.
When creating an invoice from an attachment fails, we call super() which creates a new invoice and post the attachment to it without the `no_new_invoice` context key. This triggers an new import of the attachment.
closesodoo/odoo#61191
X-original-commit: 034625f2ade73f368f97e583b83db86372ae8001
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
Allow having in an attachment as well as an error in the same document.
This will allow to see the document that generates the error, and easy
the process of debugging.
closesodoo/odoo#60599
X-original-commit: 7313e9823fffcac747af633b9b1694aa661dfa1f
Related: odoo/enterprise#14357
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
- account.edi.document require edi_format_id and move_id because it's its very own reason of existence
- account.edi.format require code because it's the way it's identified
closesodoo/odoo#60178
X-original-commit: d06f2060e8d5e5aa3e7bc1a37bb562bac0504e11
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
Determines whether user should be warned of all problems and also causes some correctable problems to be fatal. Since we just want the widest compatibility when reading PDF, strict=False seems acceptable.
TASK ID: 2358822
closesodoo/odoo#59736
X-original-commit: 9fb637577e0c13778e253b4f1329f59459ab0824
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
When parsing XML to import invoice, different edi will need to find records for partner, product and taxes based on the values on the xml. The helpers avoids code duplication.
When using FacturX, the user shouldn't see any XML. Indeed, the XMLs are embedded inside the PDF.
Then, this is confusing to see all this XML attachments directly in the chatter.
To avoid that, FacturX is now creating the attachments without any link to the account.move.
Also, when reseting to draft/post multi-times, the old attachments are unlinked because if we want to retrieve it, we could look directly inside the old PDFs.
closesodoo/odoo#56844
X-original-commit: ea1a690d9859eca7df478a6b4de3ed704f13e0f8
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When calling 'button_cancel', the EDI documents that don't need any web-services must be cancelled directly.
X-original-commit: cd668909f578a7bbe87ab5e6f73df82855809c3b
- When an edi.document has an error and thus does not have an attachment, trying to send the invoice by mail would cause a crash
closesodoo/odoo#56450
X-original-commit: 7f9e34a5b11772af958293cd75d30cae69151497
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
When an exception is raised when importing an attachment with an edi.format, we try with the next edi.format (or stop if it was the last) instead of crashing.
closesodoo/odoo#56292
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The cron to send the invoice to web-services is disabled until an edi.format that needs web services is created
closesodoo/odoo#56131
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Added edi.documents representing an electronic document for a move and an edi.format.
A format can be asynchronous if it needs to call a web-service to generate the document, it will then be generated by the CRON (otherwise it's generated in post).
The formats can support payments if needed (can be generated immediately or by the CRON).
Added support for errors and related views.
Setting defaults format on a journal can be done automatically (based on a hook).
Added tests : xml comparaison with diff and helpers to test a EDI import/export
--task: 2247368
Add an easy way to not post the entries in the future when calling
post() on it, but rather set it to be auto-posted at accounting date.
This is useful when we are creating a lot of entries in batch and some
might be in the future, some in the past, and we don't want to separate
that in two batch every time. (asset, accrual, transfer,... )
- Support for account_edi workflows (only import) + fattura_pa as an account.edi.format.
- XML containing multiple invoices cannot be imported from the chatter.
- account_edi is the base module to manage EDIs. It manages the generic worflow of import/export and defines the methods for import/export that should be overridden by each types of EDI (in different modules).
- On export, the files are added as attachment and can be embeded into pdf (format specific).
- On export, the exported format are set on the journal to allow different settings based on journal (different companies, countries, etc).
- On import, depending on the import method (from message_post or upload button in invoice tree view) a new invoice is created or an existing one is updated (only allowed draft invoices with no invoice lines).
- Adapted factur-x
Benjamin Frantzen (bfr)