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>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Add a check in 'AccountTestInvoicingCommon' to ensure that all
tests using it are run in post_install.
These tests cannot be run at install, thus they would be ignored
and wouldn't run on the Runbot.
X-original-commit: 659ee179e1beed962026e3abac1bda322c2ac964
[FIX] account,*: Ensure tests using TestInvoicingCommon runs
Add a check in 'AccountTestInvoicingCommon' to ensure that all
tests using it are run in post_install.
These tests cannot be run at install, thus they would be ignored
and wouldn't run on the Runbot.
closesodoo/odoo#90242
X-original-commit: ec36b403edda3fbe3b5bd5f30f31ef6bad680967
Related: odoo/enterprise#26791
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: William André (wan) <wan@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
The problem is that when we update the account_edi, e.g. by updating the
base module, the cron gets deactivated because initially the ir.cron
record is set to active False and we activate it when we have an
edi format that requires web services.
By setting the record to noupdate, it will not execute setting it to
False again when updating the module. (It will however not update
the record to noupdate)
closesodoo/odoo#89794
X-original-commit: 69ba48ea8cca151cb242118305dd8c152da266d1
Signed-off-by: William André (wan) <wan@odoo.com>
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>
Retroactive fix for an issue in 15.0+
In 15.0+, importing an invoice with an inactive currency will raise
a traceback. Before this it was handled by not setting the correct
currency on the invoice if not active.
With this change, we'll raise an error instead of creating an invoice
with the wrong currency.
closesodoo/odoo#85678
X-original-commit: 14c61c2563efeed1ca14294da32e2eb6d1855c5b
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
compute tax amounts corresponding to each invoice line in the edi
document for the invoice.
The issue
In Mexico, companies are required to send every invoice in electronic
format to the government. This document (called the CFDI) specifies,
for each invoice line, the taxes applicable, the amount before tax
and the tax amount. The document also specifies the total amounts
withheld for each tax which was applicable to the invoice.
The PAC (the external service which signs this electronic document
and sends it to the government) does checks on those amounts. In
particular, the tax amounts must satisfy two constraints to pass
validation:
(1) The total tax amount for a tax must be equal to the sum of the
tax amounts reported for each invoice line.
(2) The tax amount reported for each line must be equal to
(tax rate * base amount), rounded either up or down. For example, for
a line with base = MXN 398.28 and an applicable VAT of 16%, the
exact tax amount would be 0.16 * 398.28 = 63.7248, so the acceptable
values for the tax amount on that line are 63.72 and 63.73.
In v14, we used the AccountTax.compute_all method to compute the tax
amounts reported for each invoice line. This gave the exact tax
amount, rounded (either up or down depending on which side of 0.5 it
is). This always fulfils condition (2) but fulfils condition (1)
only if the tax rounding method is 'Round Locally'. Because of this,
in v14 MX users couldn't use 'Round Globally'.
In v15, we use a new SQL-based method to compute the tax amount
reported for each invoice line: we take the total tax amount, and
allocate it among the invoice lines proportionately to the base
amount of the invoice line. This always fulfils condition (1) but
sometimes doesn't fulfil condition (2). This has caused many issues
in customer DBs (see list of tickets at the end).
This was introduced in commit 433656415a and seems to be an issue
for all MX customers who have upgraded to v15.
The solution
@smetl and I have looked into what can be done about this.
Modifying the tax amount computation method in a way which satisfies
both conditions is possible, but requires more work and testing.
The existing v14 code generates tax amounts which satisfy both
conditions, at least when the tax computation method is
'Round Locally'.
A good temporary solution, while we try to modify the tax amount
computation to satisfy both conditions, would therefore be to use
the v14 tax amount computation when the tax rounding method is
'Round Locally'. While not ideal, this will at least enable
customers with the 'Round Locally' rounding method to correctly
submit their invoices to the government. Customers with the
'Round Globally' method will need to wait for the full fix.
This commit does exactly that.
Tickets linked to this problem (non-exhaustive list):
opw-2695243
opw-2733280
opw-2723571
opw-2724805
opw-2722370
opw-2722388
closesodoo/odoo#85407
X-original-commit: cddb5bc3af4806c7d1b9b09d07a5b9361d2815c0
Related: odoo/enterprise#24767
Signed-off-by: Laurent Smet <las@odoo.com>
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>
Adrien Minet