…, sale_order_import_ubl, sale_order_import_csv, sale_order_ubl, sale_commercial_partner

Add another README.

because we want to have access to the code of the modules that inherit business.document.import

'text/xml'

PEP8 fix

Add support for partner bank matching on invoice update (before, it was only supported on invoice creation)

Rename __openerp__.py to __manifest__.py and set installable to False

… module

Fix spelling mistake and other remarks on README by Tarteo

…o v10.0

base_business_document_import: Add support for the creation of res.bank

Add ubl invoice generation option in accounting config page

Add method to create SO in sale.order.import accessible via JSON-RPC

Add readme fragments

… has visible discounts

Code improvements in sale_order_import
Add unit tests in sale_order_import
Use display_name instead of name_get()[0][1]

Fix travis

…iness document is imported in the right company

Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.

Translation: edi-13.0/edi-13.0-sale_order_import
Translate-URL: https://translation.odoo-community.org/projects/edi-13-0/edi-13-0-sale_order_import/

…tner matching.

A shipping partner is not especially related to the ordering party. It
could be any partner. However, we want to ensure that the address is
respected.

Fix-up: PartyIdentification/ID is a 1..N relation. Parse each of them for a match

Do not suggest to update an open quotation that does not have the
corresponding client ref. UBL endpoint was blocked as soon as a
quotation for the same customer was existing.

…rcial entity

Parse the latest delivery date and time from the delivery node of an UBL
sales order.
And assign the value to the `commitment_date` of the sales order.

Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.

Translation: edi-14.0/edi-14.0-sale_order_import
Translate-URL: https://translation.odoo-community.org/projects/edi-14-0/edi-14-0-sale_order_import/

Disable the subscription (mail chatter) to the new sales order
for the user used by the endpoint.
To me it does make sense because good practice would be to have a
specific user for the endpoint.

When importing an order the module checks if a similar order already
exists in the system. The search domain used for this is not
customizable.
This change extract the domain computation for the search in its own
function.

When no handler is defined for the given document
NotImplementedError could be raised.

Handle this case properly when parsing.

SO and SOL creation should be done w/ all defaults loaded.
In particular, the company is not propagated directly to the SOL
when we play onchanges.

Hence, at least in our tests, it can happen
that the company is not set yet on the line
and the computation of the price via 'product._get_tax_included_unit_price'
is broken when calling 'res.currency._convert' w/ an empty company.

Error example::

    [...]/base/models/res_currency.py", line 192, in _convert
    assert company, "convert amount from unknown company"
    AssertionError: convert amount from unknown company

ATM I'm adding only the company since it turns out that
if we load all defaults w/ `order.default_get` it breaks price
computation.

Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.

Translation: edi-14.0/edi-14.0-sale_order_import
Translate-URL: https://translation.odoo-community.org/projects/edi-14-0/edi-14-0-sale_order_import/

Handle additional fields dynamically if available.
This way, if you add a field to a record and it's value is injected by a parser
you won't have to override  to let it propagate.

You can now pass 'sale_order_import__default_vals' key in the ctx
to pass order values down the stack.

- Add new selection import_type field for choosing the type to import
- Refactor _parse_file with import_type field
- Drop some not used method