Specifications for implementation of EDI in logistics for exchanges with suppliers.

Order

The purchase order (Sales Order at supplier side) creation is performed 2 steps. First step is the creation of the order.

The format is compliant with UBL 2.2. PEPPOL specialization is not used but it respects the PEPPOL clarifications given on their website on the usage and values.

Document source :
UBL 2.2.
http://docs.oasis-open.org/ubl/UBL-2.2.html

http://docs.oasis-open.org/ubl/os-UBL-2.2/mod/summary/reports/UBL-Order-2.2.html
http://docs.oasis-open.org/ubl/os-UBL-2.2/mod/summary/reports/UBL-OrderResponse-2.2.html

https://docs.peppol.eu/poacc/upgrade-3/profiles/3-order-only/ (documentation)
https://docs.peppol.eu/poacc/upgrade-3/syntax/Order/ (Order description)

PEPPOL:
https://docs.peppol.eu/poacc/upgrade-3/profiles/28-ordering/
https://peppol.eu/wp-content/uploads/2017/12/PEPPOL_Policy-for-use-of-identifiers-300-11_certificates.pdf
https://docs.peppol.eu/poacc/billing/3.0/codelist/UNECERec20/

Check compliancy here : https://peppol.helger.com/public/menuitem-validation-bis2

Clarifications

OrderResponseCode

• ​Order is acknowledge
  OrderResponseCode value is AP.
• Order completely rejected
  OrderResponseCode value is RE.
  The Order is completely rejected. No lines should be sent (they won’t be processed). The purchase order is canceled at the buyer party and no more message can follow. End of the process.
  The Note node can be filled with some details
• Order completely accepted
  OrderResponseCode value is AP.
  The Order is completely accepted without amendment. No lines should be sent (they won’t be processed).
• Order accepted with amendments
  OrderResponseCode value is CA.
  The Order is accepted with amendment on line level. All lines (Order/OrderLine/LineItem in xml file) must be sent. That means accepted lines and amended lines.

The Note node can be filled with some details

LineStatusCode

For each LineItem, a status code is returned in the xml element Order/OrderLine//LineItem/LineStatusCode:

• LineStatusCode is 7 : The order line is refused. The quantity = 0, and there is a note with the error
• LineStatusCode is 3 : The order line is accepted with change. In case some quantity cannot be processed.
• LineStatusCode is 5 : The order line is accepted without changes.
• LineStatusCode is 1 : The order line has been added. This value is not supported.
• LineStatusCode is 42 : The order line has already been delivered. This value is not supported.

Details about codes are available here : https://docs.peppol.eu/poacc/upgrade-3/codelist/UNCL1229/

​MaximumBackorderQuantity

If the element Order/OrderLine/LineItem/MaximumBackorderQuantity is used, Odoo will create a back order corresponding to the remain quantity to deliver. The back order will contain all products for the same supplier and same PO.
The quantity specified in the element MaximumBackorderQuantity represents the confirmed quantity that will be delivered at a later unknown date. For example, if ordered quantity is 5 but only 3 will be delivered, the Quantity=3 and the MaximumBackorderQuantity=2.
So the total confirmed quantity is Quantity + MaximumBackorderQuantity
The quantity that is not confirmed will be canceled at the Buyer Party and is not expected to be received. In this case, for example, if ordered quantity is 5 but only 3 will be delivered, the Quantity=3 and the MaximumBackorderQuantity=0.​
If the total quantity is equal to the ordered quantity, LineStatusCode=5
If the total quantity is less than the ordered quantity, LineStatusCode=3

Examples

Order

<Order xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:oasis:names:specification:ubl:schema:xsd:Order-2"xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:UBLVersionID>2.2</cbc:UBLVersionID>
  <cbc:ID>PO03907</cbc:ID>
  <cbc:IssueDate>2019-06-13</cbc:IssueDate>
  <cbc:IssueTime>12:30:00</cbc:IssueTime>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cac:BuyerCustomerParty>
    <cac:Party>
      <cac:PartyIdentification>
       <cbc:ID schemeID="BE;VAT">BE0421812344</cbc:ID>
      </cac:PartyIdentification>
      <cac:PartyName>
        <cbc:Name>My company</cbc:Name>
      </cac:PartyName>
    </cac:Party>
  </cac:BuyerCustomerParty>
  <cac:SellerSupplierParty>
    <cac:Party>
      <cac:PartyIdentification>
       <cbc:ID schemeID="BE;VAT">BE0421845677</cbc:ID>
      </cac:PartyIdentification>
      <cac:PartyName>
        <cbc:Name>My supplier</cbc:Name>
      </cac:PartyName>
      <cac:PostalAddress>
        <cbc:StreetName>Rue du Moulin</cbc:StreetName>
        <cbc:BuildingNumber>20</cbc:BuildingNumber>
        <cbc:CityName>Louvain-La-Neuve</cbc:CityName>
        <cbc:PostalZone>1348</cbc:PostalZone>
        <cac:Country>
          <cbc:IdentificationCode>BE</cbc:IdentificationCode>
        </cac:Country>
      </cac:PostalAddress>
    </cac:Party>
  </cac:SellerSupplierParty>
  <cac:Delivery>
    <cac:DeliveryLocation>
      <cac:Address>
        <cbc:StreetName>Place Cathedrale</cbc:StreetName>
        <cbc:BuildingNumber>30</cbc:BuildingNumber>
        <cbc:CityName>Liège</cbc:CityName>
        <cbc:PostalZone>4000</cbc:PostalZone>
        <cac:Country>
          <cbc:IdentificationCode>BE</cbc:IdentificationCode>
        </cac:Country>
      </cac:Address>
    </cac:DeliveryLocation>
  </cac:Delivery>
<cac:OrderLine>
  <cac:LineItem>
    <cbc:ID>196471</cbc:ID>
    <cbc:Quantity unitCode="PCE">300</cbc:Quantity>
    <cbc:LineExtensionAmount currencyID="EUR">6194.64</cbc:LineExtensionAmount>
    <cac:Item>
      <cbc:Description>Beers</cbc:Description>
      <cac:SellersItemIdentification>
        <cbc:ID>10012542</cbc:ID>
      </cac:SellersItemIdentification>
      <cac:BuyersItemIdentification>
        <cbc:ID>10323322</cbc:ID>
      </cac:BuyersItemIdentification>
    </cac:Item>
  </cac:LineItem>
</cac:OrderLine>
<cac:OrderLine>
...
</cac:OrderLine>
</Order>

OrderResponse

<OrderResponse xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:oasis:names:specification:ubl:schema:xsd:Order-2"xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:UBLVersionID>2.2</cbc:UBLVersionID>
  <cbc:ID>PO03907</cbc:ID>
  <cbc:OrderReference>PO03907</cbc:OrderReference>
  <cbc:IssueDate>2019-06-13</cbc:IssueDate>
  <cbc:IssueTime>12:30:00</cbc:IssueTime>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cac:BuyerCustomerParty>
    <cac:Party>
      <cac:PartyIdentification>
       <cbc:ID schemeID="BE;VAT">BE0421812344</cbc:ID>
      </cac:PartyIdentification>
      <cac:PartyName>
        <cbc:Name>Belux</cbc:Name>
      </cac:PartyName>
    </cac:Party>
  </cac:BuyerCustomerParty>
  <cac:SellerSupplierParty>
    <cac:Party>
      <cac:PartyName>
        <cbc:Name>My Supplier</cbc:Name>
      </cac:PartyName>
      <cac:PartyIdentification>
       <cbc:ID schemeID="BE;VAT">BE0421845677</cbc:ID>
      </cac:PartyIdentification>
      <cac:PostalAddress>
        <cbc:StreetName>street</cbc:StreetName>
        <cbc:BuildingNumber>20</cbc:BuildingNumber>
        <cbc:CityName>City</cbc:CityName>
        <cbc:PostalZone>1152</cbc:PostalZone>
        <cac:Country>
          <cbc:IdentificationCode>BE</cbc:IdentificationCode>
        </cac:Country>
      </cac:PostalAddress>
    </cac:Party>
  </cac:SellerSupplierParty>
  <cbc:OrderResponseCode>CA</cbc:OrderResponseCode>
  <cbc:Note>any error messsage</cbc:Note>
  <cac:OrderLine>
    <cac:LineItem>
      <cbc:ID>196471</cbc:ID>
      <cbc:Quantity unitCode="PCE">300</cbc:Quantity>
      <cbc:LineStatusCode>confirmed</cbc:LineStatusCode>
    </cac:LineItem>
  </cac:OrderLine>
  <cac:OrderLine>
    <cac:LineItem>
      <cbc:ID>196472</cbc:ID>
      <cbc:Quantity unitCode="PCE">6</cbc:Quantity>
      <cbc:LineStatusCode>confirmed</cbc:LineStatusCode>
    </cac:LineItem>
  </cac:OrderLine>
  <cac:OrderLine>
  ...
  </cac:OrderLine>
</OrderResponse>

Delivery

The delivery process support the full process of receiving goods into a warehouse.

The supplier prepare the delivery and send a despach advice (called delivery order in Odoo) to the supplier. The file is transfered by the seller party, twice :

• when the delivery is planned and
• when it is delivered.
  There is one file per delivery.

The despach advice describes how the goods are packed and delivered. A delivery is taken to be a number of items that are despatched as a single consignment to a single delivery address.
It contains the quantity of goods shipped and what is outstanding.

Despach advice are identified with a unique reference and a delivery order number. The same delivery order number could be used for all disptach advice related to an order. For example in case of outstanding quantities and multiple deliveries.

During the reception of the products by the buyer party, the operator cannot enter into Odoo quantities greater than those of the order. In this case, the additional products, will require the creation of an additional order (purchase order) in Odoo. This purchase order will not be sent automatically to the supplier.
That means that Odoo must allow the configuration of the automatic sending of the order when confirming a purchase order.
Products will be received separately. The supplier must not send a despach advice for these products. The supplier will produce a separate invoice for these items.

The format is compliant with UBL 2.2. PEPPOL specialization is not used but it respects the PEPPOL clarifications given on their website on the usage and values.

Document source :
UBL 2.2.
http://docs.oasis-open.org/ubl/UBL-2.2.html
http://docs.oasis-open.org/ubl/os-UBL-2.2/mod/summary/reports/UBL-DespatchAdvice-2.2.html
https://docs.peppol.eu/poacc/upgrade-3/profiles/30-despatchadvice/ (documentation)

PEPPOL:
https://docs.peppol.eu/poacc/upgrade-3/profiles/30-despatchadvice/
https://docs.peppol.eu/poacc/billing/3.0/codelist/UNECERec20/

Check compliancy here : https://peppol.helger.com/public/menuitem-validation-bis2

Clarifications

DespatchAdvice Type Code

The DespatchAdvice is used for notifying the planned delivery date and for notifying the effective delivery. This is can be identified with the content of DespatchAdviceTypeCode:
scheduled
delivered
​

Order Reference

Used to provide a reference to the purchase order on which the Despatch Advice is based. There may be multiple Despatch Advices to cover one purchase order.

Usually, each Despatch Advice relates to one purchase order. The reference to Order Line-ID is required in the UBL syntax.

It is also possible to refer to more than one order in one single despatch advice. In this case there must not be an order reference on header level.

Example header level

<cac:OrderReference>
        <cbc:ID>4321</cbc:ID>
</cac:OrderReference>

Example 1 of Line level

<cac:OrderLineReference>
  <cbc:LineID>1</cbc:LineID>
  <cac:OrderReference>
    <cbc:ID>879865</cbc:ID>
  </cac:OrderReference>
</cac:OrderLineReference>

Outstanding quantity

The outstanding element on the Despatch line is both used to signal the outstanding quantity and to inform about delivery discrepancies.
In this case Odoo will create a back order corresponding to the remaining quantity to deliver or use an existing back order if it is related to the same supplier and same PO.
The handling of “The outstanding quantity which will never be delivered” is done like this: The amount that is declared in the element OutstandingQuantity is equivalent to the amount that will be delivered in a later Despatch. This implicitly means that the missing items that are NOT declared in the OutstandingQuantity can’t or will not be delivered.
​
####​ Batch/Lot numbers, Expiry Date and Best Before Date
The Batch number (Lot number) applies to all items in the despatch line.
Expiry date is used for products with a lot number (typically medical).
Best before date is used for products without lot number (typically food).

Example 1:

<cac:ItemInstance>
  <cac:LotIdentification>
    <cbc:LotNumberID>898A129</cbc:LotNumberID>
    <cbc:ExpiryDate>2025-07-01</cbc:ExpiryDate>
  </cac:LotIdentification>
</cac:ItemInstance>

Example 2:

<cac:ItemInstance>
  <cbc:BestBeforeDate>2025-04-15</cbc:BestBeforeDate>
</cac:ItemInstance>

When multiple lots of a same product are delivered, those are put in separate DespatchLine. In case of outstanding quantity, one of the line will contain the outstanding quantity. If the planned lot is not known, the outstanding quantity can be put in another DespatchLine without lot.

Example

<DespatchAdvice xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns="urn:oasis:names:specification:ubl:schema:xsd:DespatchAdvice-2">
  <cbc:UBLVersionID>2.2</cbc:UBLVersionID>
  <cbc:ID>565899</cbc:ID>
  <cbc:IssueDate>2019-06-20</cbc:IssueDate>
  <cbc:DespatchAdviceTypeCode>scheduled/delivered</cbc:DespatchAdviceTypeCode>
  <cac:OrderReference>
    <cbc:ID>PO03907</cbc:ID>
    <cbc:SalesOrderID>CON0095678</cbc:SalesOrderID>
  </cac:OrderReference>
  <cac:DespatchSupplierParty>
    <cac:Party>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>XLETZR BELGIUM</cbc:RegistrationName>
      </cac:PartyLegalEntity>
      <cac:PartyIdentification>
        <cbc:ID schemeID="BE;VAT">BE040153456</cbc:ID>
      </cac:PartyIdentification>
      <cac:PartyName>
      <cbc:Name>My Supplier</cbc:Name>
    </cac:PartyName>
    <cac:PostalAddress>
      <cbc:StreetName>Street</cbc:StreetName>
      <cbc:BuildingNumber>20</cbc:BuildingNumber>
      <cbc:CityName>City</cbc:CityName>
      <cbc:PostalZone>2352</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>BE</cbc:IdentificationCode>
      </cac:Country>
     </cac:PostalAddress>
    </cac:Party>
  </cac:DespatchSupplierParty>
  <cac:DeliveryCustomerParty>
    <cac:Party>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>Alcyon Belux</cbc:RegistrationName>
      </cac:PartyLegalEntity>
      <cac:PartyIdentification>
         <cbc:ID>ALCYONID</cbc:ID>
      </cac:PartyIdentification>
      <cac:PartyName>
        <cbc:Name>Belux</cbc:Name>
      </cac:PartyName>
    </cac:Party>
  </cac:DeliveryCustomerParty>
  <cac:Shipment>
    <cbc:ID>OUT/009523</cbc:ID>
    <cac:Delivery>
      <cbc:EstimatedDeliveryDate>2019-07-02</cbc:EstimatedDeliveryDate>
    </cac:Delivery>
  </cac:Shipment>
  <cac:DespatchLine>
    <cbc:ID>1315123</cbc:ID>
    <cbc:DeliveredQuantity unitCode="PCE">200</cbc:DeliveredQuantity>
    <cbc:OutstandingQuantity unitCode="PCE">100</cbc:OutstandingQuantity>
    <cac:OrderLineReference>
      <cbc:LineID>196471</cbc:LineID>
       <cac:OrderReference>
       <cbc:ID>PO03907</cbc:ID>
       <cbc:SalesOrderID>CON0095678</cbc:SalesOrderID>
    </cac:OrderReference>
    </cac:OrderLineReference>
    <cac:Item>
      <cbc:Name>SIMPARICA 80MG 20,1/40KG 3CP</cbc:Name>
      <cac:SellersItemIdentification>
        <cbc:ID>10012542</cbc:ID>
      </cac:SellersItemIdentification>
      <cac:ItemInstance>
        <cbc:BestBeforeDate>2025-04-15</cbc:BestBeforeDate>
      </cac:ItemInstance>
    </cac:Item>
  </cac:DespatchLine>
</DespatchAdvice>

Hi
I am trying to install the ZuGFERD modules for ODOO 8.0 on my test-setup and I am running into a bit of a problem:
` Traceback (most recent call last):
File "/home/markus/odoo-dev/odoo/openerp/http.py", line 546, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
File "/home/markus/odoo-dev/odoo/openerp/http.py", line 584, in dispatch
result = self._call_function(**self.params)
File "/home/markus/odoo-dev/odoo/openerp/http.py", line 318, in _call_function
return checked_call(self.db, *args, **kwargs)
File "/home/markus/odoo-dev/odoo/openerp/service/model.py", line 118, in wrapper
return f(dbname, *args, **kwargs)
File "/home/markus/odoo-dev/odoo/openerp/http.py", line 315, in checked_call
return self.endpoint(*a, **kw)
File "/home/markus/odoo-dev/odoo/openerp/http.py", line 822, in call
return self.method(*args, **kw)
File "/home/markus/odoo-dev/odoo/openerp/http.py", line 412, in response_wrap
response = f(*args, **kw)
File "/home/markus/odoo-dev/odoo/addons/web/controllers/main.py", line 968, in call_button
action = self._call_kw(model, method, args, {})
File "/home/markus/odoo-dev/odoo/addons/web/controllers/main.py", line 956, in _call_kw
return getattr(request.registry.get(model), method)(request.cr, request.uid, *args, **kwargs)
File "/home/markus/odoo-dev/odoo/openerp/api.py", line 268, in wrapper
return old_api(self, *args, **kwargs)
File "/home/markus/odoo-dev/odoo/openerp/addons/base/module/wizard/base_module_upgrade.py", line 105, in upgrade_module
openerp.modules.registry.RegistryManager.new(cr.dbname, update_module=True)
File "/home/markus/odoo-dev/odoo/openerp/modules/registry.py", line 371, in new
openerp.modules.load_modules(registry._db, force_demo, status, update_module)
File "/home/markus/odoo-dev/odoo/openerp/modules/loading.py", line 354, in load_modules
loaded_modules, update_module)
File "/home/markus/odoo-dev/odoo/openerp/modules/loading.py", line 254, in load_marked_modules
loaded, processed = load_module_graph(cr, graph, progressdict, report=report, skip_modules=loaded_modules, perform_checks=perform_checks)
File "/home/markus/odoo-dev/odoo/openerp/modules/loading.py", line 175, in load_module_graph
_load_data(cr, module_name, idref, mode, kind='data')
File "/home/markus/odoo-dev/odoo/openerp/modules/loading.py", line 117, in _load_data
tools.convert_file(cr, module_name, filename, idref, mode, noupdate, kind, report)
File "/home/markus/odoo-dev/odoo/openerp/tools/convert.py", line 862, in convert_file
convert_xml_import(cr, module, fp, idref, mode, noupdate, report)
File "/home/markus/odoo-dev/odoo/openerp/tools/convert.py", line 949, in convert_xml_import
obj.parse(doc.getroot(), mode=mode)
File "/home/markus/odoo-dev/odoo/openerp/tools/convert.py", line 812, in parse
self.parse(rec, mode)
File "/home/markus/odoo-dev/odoo/openerp/tools/convert.py", line 815, in parse
self._tags[rec.tag](self.cr, rec, de, mode=mode)
File "/home/markus/odoo-dev/odoo/openerp/tools/convert.py", line 516, in _tag_menuitem
menu_parent_id = self.id_get(cr, rec.get('parent',''))
File "/home/markus/odoo-dev/odoo/openerp/tools/convert.py", line 793, in id_get
res = self.model_id_get(cr, id_str, raise_if_not_found)
File "/home/markus/odoo-dev/odoo/openerp/tools/convert.py", line 804, in model_id_get
raise_if_not_found=raise_if_not_found)
File "/home/markus/odoo-dev/odoo/openerp/api.py", line 268, in wrapper
return old_api(self, *args, **kwargs)
File "/home/markus/odoo-dev/odoo/openerp/addons/base/ir/ir_model.py", line 904, in xmlid_to_res_model_res_id
return self.xmlid_lookup(cr, uid, xmlid)[1:3]
File "/home/markus/odoo-dev/odoo/openerp/api.py", line 268, in wrapper
return old_api(self, *args, **kwargs)
File "", line 2, in xmlid_lookup
File "/home/markus/odoo-dev/odoo/openerp/tools/cache.py", line 74, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/home/markus/odoo-dev/odoo/openerp/addons/base/ir/ir_model.py", line 894, in xmlid_lookup
raise ValueError('External ID not found in the system: %s' % (xmlid))
ParseError: "External ID not found in the system: account.menu_configuration_misc" while parsing /home/markus/odoo-dev/bank-payment/account_banking_payment_export/views/payment_mode_type.xml:63, near

Can somebody tell me, what I am doing wrong? I have met all dependencies and I am using the right branches.

Step :
Install modules permitting to import invoices
Import a pdf invoice without any configuration

When you just install import vendor bills : a record is created
When you install invoice2data and others ones : This PDF invoice doesn't match a known template of the invoice2data lib, and nothing is done.

#96 (comment)

Besides the t-cac:AddressType, some implementations also need the t-cac:LocationType generics, which includes an e-cac:Address element of type t-cac:AddressType.

For example, t-cac:PartyTypes can use them as e-cac:PhysicalLocation, see:
http://www.datypic.com/sc/ubl21/t-cac_PartyType.html

This is a meta issue to keep track of the current raid. All referenced issues are still WIP

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-11.0

Modules to migrate

• account_e-invoice_generate - By @astirpe - #44
• account_invoice_download - By @rousseldenis - #91
• account_invoice_download_weboob - By @rousseldenis - #92
• account_invoice_factur-x
• account_invoice_factur-x_py3o
• account_invoice_import - By @njeudy - #41
• account_invoice_import_factur-x
• account_invoice_import_invoice2data - By @tarteo - #76
• account_invoice_import_ubl - By @astirpe - #49
• account_invoice_ubl - By @astirpe - #46
• account_invoice_ubl_py3o
• base_business_document_import - By @njeudy - #42
• base_business_document_import_phone
• base_business_document_import_stock
• base_ubl - By @astirpe - #43
• base_ubl_payment - By @astirpe - #45
• base_zugferd - By @njeudy - #70
• purchase_order_import
• purchase_order_import_ubl
• purchase_order_ubl - By @astirpe - #48
• purchase_order_ubl_py3o
• sale_order_import - By @tarteo - #60
• sale_order_import_csv
• sale_order_import_ubl - By @tarteo - #61
• sale_order_ubl - By @astirpe - #47
• sale_order_ubl_py3o
• sale_stock_order_import

XBRL : Taxonomy builder

This proposal is about implementing a XBRL taxonomy builder into Odoo. The final goal is to be able to generate XBRL instance documents based on government taxonomies and taxonomies created by other companies. This means the solution has to be generic. But the first step will be to create an Odoo layer on top of the XML (taxonomies etc.). An Odoo layer (models) is IMO easier to use than XML and turns Odoo into a taxonomy builder.

This proposal only covers the taxonomy builder.

Features

• Import taxonomies
• Edit taxonomies
• Export taxonomies
• Validating instances
• The module act as a technical interface for other modules

GUI

Menu

The main menu item will be located in menu item 'Settings'.

Graphical interface

No new widgets are needed to implement the functionalities; the graphical interface will consist of default Odoo GUI components.

Security

To grant access to the taxonomy builder features, a group (res.groups) is needed (something like "Manage XBRL Taxonomies").

Conceptual ERD

Explanation

All entities of the model are conceptual and will be converted to Odoo models. e.g. entity 'Taxonomy' will be converted to model 'xbrl.taxonomy'.

• Schema: XML Schema documents which are not taxonomies but are used by taxonomies.
• Resource: Abstract resource, other models inherit from it resulting in a concrete resource (e.g. label resource and reference resource). The inheritance can also be solved with the introduction of a field like 'type'. But I prefer inheritance because it is IMO neater. This tactic will be consistently used.

Others

The technical name of the module will be xbrl.
Dimensions are missing in this model (no support for the XBRL Dimensions schema).

I would love to hear your suggestions, questions and comments.

Here is the Error i am getting when trying to install account Invoice UBL module on Odoo v8

ParseError: "ValidateError
Field(s) arch failed against a constraint: Invalid view definition

Error details:
Field partner_ids does not exist

Error context:
View account_payment_partner.payment.order.create.form
[view_id: 2090, xml_id: n/a, model: payment.order.create, parent_id: 1629]" while parsing /opt/odoo/odoo-server/addons/account_payment_partner/wizard/payment_order_create_view.xml:11, near

account_payment_partner.payment.order.create.form
payment.order.create

Scope
@alexis-via and me were discussing about the XRechnung standard briefly during OXP 2019.

I took the task to review the current status of the spec and make sense on how this relates to Facture-X.

Reasoning

There is quite a bite of information (though on German) on the following web page

The governmental entity "Koordinierungsstelle für IT-Standards" is coordinating the efforts.
XRechnung is an XML-only standard (i.e. no encapsulating PDF like in Facture-X) that refers to the same European Standard EN 16931 as Facture-X / ZugFERD does.

The following link (also GERMAN)

basically says that Facture-X / ZugFERD 2.0 over XRechnung has the advantage of having the PDF encapsulated and allowing a "basic" and an "extended" profil (with more information). The latter link essentially also says that ZugFERD 2.0 compliant invoices can be used for the official invoicing towards governmental entities (which is the functional scope of XRechnung), so i think there is no specific need to work on a separate XRechnung module for.

According to

https://www.xoev.de/sixcms/media.php/13/XRechnung-v1-2-1.pdf

Page 12 an "UBL invoice and credit note messages as defined in ISO/IEC 19845:2015 and UN/CEFACT Cross Industry Invoice XML message as specified in XML Schemas 16B (SCRDM - CII) should pass the conformity validator on

https://github.com/itplr-kosit/validator

if they also

• may have embedded objects according to the standards but are no embedded objects themselves
• is an UTF-8 formatted instance either of the aforementioned XML standards (UBL according ISO/IEC 19845:2015 or a UN/CEFACT Cross Industry Invoice)
• is valid according to the XRechnung Business Rule Specifications and their technical implemntation
• uses all specified elements according to their defined semantics.

The first three items are tested automatically, the last one can only be validated by human intelligence with appropriate context. The most complex thing to comply with are the 65 business rules, constraints and extending rules (pages 61 ff.) defined in

https://www.xoev.de/sixcms/media.php/13/XRechnung-v1-2-1.pdf

I am not sure if the UBL xml export of the current module already complies to all or most of these but this may be tested.

Summary / Next steps
If an UBL-file exportable by the already existing module already complies to the XRechnung conformity validation than we may only add some controls / translations / explanations for users of the modules that effectively allow using these as XRechnung documents.

Post processing the document requires nsmap for fidelity.
You could generate your own, but at the loss of consistency,

Adjust method signature to pass nsmap around instead of ns(-prefix).

This also helps creating ElementMaker from #128
While #128 is cosmetics, the present issue has more weight.

module: account_invoice_ubl
version: 12.0

Hello,

I was wondering if it was possible to mass export the XML ?
For instance, select a batch of invoice, go to Action/Export.
I couldn't find the feature.

Thank you in advance for your answer,

Kind regards,

Benjamin

This is just a request for info...

Which invoice2data external library is being used by travis? The one from akretion (5 years without changes) or the one from invoice-x (active recently) ?

The project invoice2data registered in the python package index is the one from invoice-x, but I guess the code of the odoo addon uses the one from akretion / @alexis-via, because they made it.

Can somebody answer that ?

The code of invoice-x has now support for another input_readers (like tesseract4, etc..), I have verified that it works Ok with the v12 code of account_invoice_import_invoice2data.

Is that the one being installed ? I don't see that info in .travis.yml. How can we know which is the one being installed to test ?

The python dependency specified in the manifest has no from where is being installed, so I guess it is the one from the python package index (invoice-x).

Hi @alexis-via following up on your nice presentation in LLN 2018 for a research project together with some folks of my team i was investigating the functionality of the great e-Invoicing stuff you did.

However, from the OCA-runbot as well as our own test on v10 we weren't able to issue as sale order with a valid PDF/A document and embedded invoice information. I am wondering what you took to test that the resulting PDF/A is really a standard compliant PDF/A or put differently what we may have configured wrong.

After doing some research on it, i found that VeraPDF (http://verapdf.org/) is most probably a good (if not the only reliable) way to assure that the PDF/A is standard compliant. We did the configuration multiple times as given in the documentation but still VeraPDF doesn't recongnize a valid and stanard compliant PDF/A on neigther UBL nor Facture-X

Hello I was trying to generate a PDF file with an embedded XML (ZUGFeRD 2.0 Standard).
I wanted to use the account_invoice_facturx OCA module as a basis for this.

module: account_invoice_facturx
version: 12.0.1.0.0

Current behaviour:
When clicking on the "Print" -> "Invoice" button in the Invoice form inside Odoo, I'm getting the error that the XML is invalid against the XML Schema Definition because another field is expected than given.

factur-x: The XML file is invalid against the XML Schema Definition
factur-x: XSD Error: Element '{urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100}SpecifiedTradeSettlementLineMonetarySummation': This element is not expected. Expected is ( {urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100}ApplicableTradeTax )., line 35

Traceback:

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/facturx/facturx.py", line 144, in check_facturx_xsd
    official_schema.assertValid(t)
  File "src/lxml/etree.pyx", line 3621, in lxml.etree._Validator.assertValid
lxml.etree.DocumentInvalid: Element '{urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100}SpecifiedTradeSettlementLineMonetarySummation': This element is not expected. Expected is ( {urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100}ApplicableTradeTax )., line 32

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/mnt/c/Users/niklastom.hucke/Dev/odoo-12.0/addons/web/controllers/main.py", line 1671, in report_download
    response = self.report_routes(reportname, docids=docids, converter=converter)
  File "/mnt/c/Users/niklastom.hucke/Dev/odoo-12.0/odoo/http.py", line 519, in response_wrap
    response = f(*args, **kw)
  File "/mnt/c/Users/niklastom.hucke/Dev/odoo-12.0/addons/web/controllers/main.py", line 1612, in report_routes
    pdf = report.with_context(context).render_qweb_pdf(docids, data=data)[0]
  File "/mnt/c/Users/niklastom.hucke/Dev/odoo-12.0/addons/base/models/ir_actions_report.py", line 733, in render_qweb_pdf
    return self._post_pdf(save_in_attachment, pdf_content=pdf_content, res_ids=html_ids), 'pdf'
  File "/mnt/c/Users/niklastom.hucke/Dev/Odoo/edi/account_invoice_ubl/models/ir_actions_report.py", line 35, in _post_pdf
    save_in_attachment, pdf_content=pdf_content, res_ids=res_ids)
  File "/mnt/c/Users/niklastom.hucke/Dev/Odoo/edi/account_invoice_facturx/models/ir_actions_report.py", line 34, in _post_pdf
    pdf_content=pdf_content)
  File "/mnt/c/Users/niklastom.hucke/Dev/Odoo/edi/account_invoice_facturx/models/account_invoice.py", line 773, in regular_pdf_invoice_to_facturx_invoice
    facturx_xml_str, level = self.generate_facturx_xml()
  File "/mnt/c/Users/niklastom.hucke/Dev/Odoo/edi/account_invoice_facturx/models/account_invoice.py", line 740, in generate_facturx_xml
    check_facturx_xsd(xml_string, 'factur-x', facturx_level=ns['level'])
  File "/usr/local/lib/python3.6/dist-packages/facturx/facturx.py", line 155, in check_facturx_xsd
    "cause of the problem: %s." % (flavor.capitalize(), unicode(e)))
Exception: The Factur-x XML file is not valid against the official XML Schema Definition. Here is the error, which may give you an idea on the cause of the problem: Element '{urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100}SpecifiedTradeSettlementLineMonetarySummation': This element is not expected. Expected is ( {urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100}ApplicableTradeTax )., line 32.

Configuration (Installed packages)

• WkHTMLtoPDF v0.12.4 (with patched qt)
• factur-x v1.10

Configuration (Odoo Settings)

• Format: Factur-X (CII)
• Factur-X Level: EN 16931 (Comfort)
• Factur-X Refund Type: Type 381 with positive amounts

This error was also present when trying out a different Factur-X Level (Basic) or when trying it with the Refund Type 381 w/ negative amounts.

Generated XML:

<?xml version='1.0' encoding='UTF-8'?>
<rsm:CrossIndustryInvoice xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100" xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100" xmlns:qdt="urn:un:unece:uncefact:data:standard:QualifiedDataType:100" xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">
  <rsm:ExchangedDocumentContext>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
  <rsm:ExchangedDocument>
    <ram:ID>INV/2020/0002</ram:ID>
    <ram:TypeCode>380</ram:TypeCode>
    <ram:IssueDateTime>
      <udt:DateTimeString format="102">20200427</udt:DateTimeString>
    </ram:IssueDateTime>
  </rsm:ExchangedDocument>
  <rsm:SupplyChainTradeTransaction>
    <ram:IncludedSupplyChainTradeLineItem>
      <ram:AssociatedDocumentLineDocument>
        <ram:LineID>1</ram:LineID>
      </ram:AssociatedDocumentLineDocument>
      <ram:SpecifiedTradeProduct>
        <ram:Name>Service on demand</ram:Name>
      </ram:SpecifiedTradeProduct>
      <ram:SpecifiedLineTradeAgreement>
        <ram:GrossPriceProductTradePrice>
          <ram:ChargeAmount>75.00</ram:ChargeAmount>
        </ram:GrossPriceProductTradePrice>
        <ram:NetPriceProductTradePrice>
          <ram:ChargeAmount>75.00</ram:ChargeAmount>
        </ram:NetPriceProductTradePrice>
      </ram:SpecifiedLineTradeAgreement>
      <ram:SpecifiedLineTradeDelivery>
        <ram:BilledQuantity unitCode="HUR">24.000</ram:BilledQuantity>
      </ram:SpecifiedLineTradeDelivery>
      <ram:SpecifiedLineTradeSettlement>
        <ram:SpecifiedTradeSettlementLineMonetarySummation>
          <ram:LineTotalAmount>1800.00</ram:LineTotalAmount>
        </ram:SpecifiedTradeSettlementLineMonetarySummation>
      </ram:SpecifiedLineTradeSettlement>
    </ram:IncludedSupplyChainTradeLineItem>
    <ram:IncludedSupplyChainTradeLineItem>
      <ram:AssociatedDocumentLineDocument>
        <ram:LineID>2</ram:LineID>
      </ram:AssociatedDocumentLineDocument>
      <ram:SpecifiedTradeProduct>
        <ram:Name>On Site Assistance</ram:Name>
      </ram:SpecifiedTradeProduct>
      <ram:SpecifiedLineTradeAgreement>
        <ram:GrossPriceProductTradePrice>
          <ram:ChargeAmount>38.25</ram:ChargeAmount>
        </ram:GrossPriceProductTradePrice>
        <ram:NetPriceProductTradePrice>
          <ram:ChargeAmount>38.25</ram:ChargeAmount>
        </ram:NetPriceProductTradePrice>
      </ram:SpecifiedLineTradeAgreement>
      <ram:SpecifiedLineTradeDelivery>
        <ram:BilledQuantity unitCode="HUR">30.000</ram:BilledQuantity>
      </ram:SpecifiedLineTradeDelivery>
      <ram:SpecifiedLineTradeSettlement>
        <ram:SpecifiedTradeSettlementLineMonetarySummation>
          <ram:LineTotalAmount>1147.50</ram:LineTotalAmount>
        </ram:SpecifiedTradeSettlementLineMonetarySummation>
      </ram:SpecifiedLineTradeSettlement>
    </ram:IncludedSupplyChainTradeLineItem>
    <ram:ApplicableHeaderTradeAgreement>
      <ram:SellerTradeParty>
        <ram:Name>YourCompany</ram:Name>
        <ram:DefinedTradeContact>
          <ram:PersonName>Mitchell Admin</ram:PersonName>
          <ram:TelephoneUniversalCommunication>
            <ram:CompleteNumber>+1 555-555-5555</ram:CompleteNumber>
          </ram:TelephoneUniversalCommunication>
          <ram:EmailURIUniversalCommunication>
            <ram:URIID schemeID="SMTP">[email protected]</ram:URIID>
          </ram:EmailURIUniversalCommunication>
        </ram:DefinedTradeContact>
        <ram:PostalTradeAddress>
          <ram:PostcodeCode>18540</ram:PostcodeCode>
          <ram:LineOne>1725 Slough Ave.</ram:LineOne>
          <ram:CityName>Scranton</ram:CityName>
          <ram:CountryID>DE</ram:CountryID>
        </ram:PostalTradeAddress>
      </ram:SellerTradeParty>
      <ram:BuyerTradeParty>
        <ram:Name>Joel Willis</ram:Name>
        <ram:PostalTradeAddress>
          <ram:PostcodeCode>07002</ram:PostcodeCode>
          <ram:LineOne>858 Lynn Street</ram:LineOne>
          <ram:CityName>Bayonne</ram:CityName>
          <ram:CountryID>US</ram:CountryID>
        </ram:PostalTradeAddress>
      </ram:BuyerTradeParty>
    </ram:ApplicableHeaderTradeAgreement>
    <ram:ApplicableHeaderTradeDelivery>
      <ram:ShipToTradeParty>
        <ram:PostalTradeAddress>
          <ram:PostcodeCode>07002</ram:PostcodeCode>
          <ram:LineOne>858 Lynn Street</ram:LineOne>
          <ram:CityName>Bayonne</ram:CityName>
          <ram:CountryID>US</ram:CountryID>
        </ram:PostalTradeAddress>
      </ram:ShipToTradeParty>
    </ram:ApplicableHeaderTradeDelivery>
    <ram:ApplicableHeaderTradeSettlement>
      <ram:PaymentReference>INV/2020/0002</ram:PaymentReference>
      <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
      <ram:SpecifiedTradeSettlementPaymentMeans>
        <ram:TypeCode>30</ram:TypeCode>
        <ram:Information>Direct Debit of customers</ram:Information>
      </ram:SpecifiedTradeSettlementPaymentMeans>
      <ram:SpecifiedTradePaymentTerms>
        <ram:Description>15 Days</ram:Description>
        <ram:DueDateDateTime>
          <udt:DateTimeString format="102">20200512</udt:DateTimeString>
        </ram:DueDateDateTime>
      </ram:SpecifiedTradePaymentTerms>
      <ram:SpecifiedTradeSettlementHeaderMonetarySummation>
        <ram:LineTotalAmount>2947.50</ram:LineTotalAmount>
        <ram:TaxBasisTotalAmount>0.00</ram:TaxBasisTotalAmount>
        <ram:TaxTotalAmount currencyID="EUR">0.00</ram:TaxTotalAmount>
        <ram:GrandTotalAmount>2947.50</ram:GrandTotalAmount>
        <ram:TotalPrepaidAmount>0.00</ram:TotalPrepaidAmount>
        <ram:DuePayableAmount>2947.50</ram:DuePayableAmount>
      </ram:SpecifiedTradeSettlementHeaderMonetarySummation>
    </ram:ApplicableHeaderTradeSettlement>
  </rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>

Expected behaviour:
The PDF file with the embedded XML should be downloaded.

Routinely add return statements on generators to ease inheritance / extension:

example:

    @api.model
    def _ubl_add_address(
            self, partner, node_name, parent_node, ns, version='2.1'):
        address = etree.SubElement(parent_node, ns['cac'] + node_name)
        ...
        return address

Then:

    @api.model
    def _ubl_add_address(
            self, partner, node_name, parent_node, ns, version='2.1'):
        address = super()._ubl_add_address(
            partner, node_name, parent_node, ns, version=version)

        id = etree.SubElement(
            address, ns['cbc'] + 'ID')
        id.text = 'MY-LOCALIZED-ID'
        ...
        return address

When I try to import a sales order in CSV format for a customer that has a pricelist with prices that are not the base currency, I get an error message:

The currency of the imported order ("my base currency") is different from the currency of the existing order ("currency of the pricelist for the supplier")

Any ideas on how to handle this?

At least into purchase_order_ubl, when a line is added to the UBL document, the line number is used as identifier. This identifier doesn't allow to clearly and uniquely identifies the line into Odoo (it depends of the line order and this order can be altered if the PO is altered). It also doesn't allow a fast access to the related line when this identifier is provided back by an external system for exemple into DespatchAdvice documents.

Is there a business motivation to use this line number in the PO as an identifier? If not, can I propose an evolution to use the xml_id of the odoo object as ID in the UBL document.

ping @alexis-via @astirpe @tarteo

@alexis-via, last merge has discovered several problems on Travis. Can you please fix them?

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-13.0

Modules to migrate

• account_e-invoice_generate - By @astirpe - #146
• account_invoice_facturx By @alexis-via - #208
• account_invoice_facturx_py3o By @alexis-via - #208
• account_invoice_import - By @yvaucher - #727
• account_invoice_import_invoice2data
• account_invoice_ubl - By @astirpe - #156
• account_invoice_ubl_email_attachment
• base_facturx By @alexis-via - #209
• base_ubl - By @astirpe - #154
• base_ubl_payment - By @astirpe - #155
• sale_order_ubl

❓ Missing module ❓ Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

I have imported a UBL Invoice of my fuel pass supplier.
It has multiple lines, besides fuel it also contains some parking costs.
I set the Method of Invoice Line to ”Multi Line, No Product”.
The expected result is that in Odoo I have the same invoice line price as in the UBL file.

Current behavior:
The price does not match UBL file.
The first invoice line should be €71,41 instead of €71,01.

Input code for the first line:
cac:InvoiceLine
cbc:ID1</cbc:ID>
<cbc:InvoicedQuantity unitCode="LTR">70.31</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="EUR">71.41</cbc:LineExtensionAmount>
cac:OrderLineReference
cbc:LineID1</cbc:LineID>
</cac:OrderLineReference>
cac:TaxTotal
<cbc:TaxAmount currencyID="EUR">15.00</cbc:TaxAmount>
cac:TaxSubtotal
<cbc:TaxableAmount currencyID="EUR">71.41</cbc:TaxableAmount>
<cbc:TaxAmount currencyID="EUR">15.00</cbc:TaxAmount>
cac:TaxCategory
<cbc:ID schemeID="UNCL5305" schemeAgencyID="6">S</cbc:ID>
cbc:Percent21.00</cbc:Percent>
cac:TaxScheme
<cbc:ID schemeID="UN/ECE 5153" schemeAgencyID="6">VAT</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:TaxSubtotal>
</cac:TaxTotal>
cac:Item
cbc:DescriptionDiesel</cbc:Description>
cbc:NameDiesel</cbc:Name>
</cac:Item>
</cac:InvoiceLine>

complete input
UBLInvoice.0006311117.xml.txt

Can the XML file included when sending mail?

def _ubl_add_party(self, partner, company, node_name, parent_node, ns, version='2.1')
hardcodes cbc here: party = etree.SubElement(parent_node, ns['cac'] + node_name)

instead, pass prefixed node_name and carry the nsmap of #131

Quoting

UBL 2 Guidelines for Customization,
First Edition
Committee Specification 01
25 December 2009 

Page 41, 4 Validation

Validation is recommended to be a two step process:

• Structural Constraints as defined by XMLSChema (".xsd-files")
• Value Constraints as defined by XSLTTransform (".xsl-files) - as for example compiled from a schematron

Many stylesheets (.xsl-files) in practice use Xpath 2.0 or even (proposed) Xpath 3.0 language features, which are not supported by python's lxml.

Therefore, implement a simple interface to a java toolchain which supports those validation requirements. (e.g. this: http://docs.oasis-open.org/ubl/os-UBL-2.1/val/)

_ubl_add_party only creates a legal entity tag if company argument is passed.

However the call signature of _ubl_add_customer_party (see docstring of _ubl_add_supplier_party) accepts a Falsy value for the company parameter.

First guess:

• Conditioning legal entity generation on the company parameter within _ubl_add_party is not correct.

Tested with 11.0.

Here is the scenario:

• In a multicompany environment, user A is allowed to access multiple companies, eg. Company1 and Company2.
• For Company1, a vendor (partner) with vat number = XYX is present.
• In Company2 there is also a vendor with same vat number = XYX; so that vendor is known in both Company1 and Company2.
• The module base_business_document_import is capable to select the partner based on the result of method def _match_partner(). In our scenario, the match is based on the vat number: see lines.

User A logs in with Company1 and tries to import a document (eg. an invoice).

I would expect that the retrieved vendor (partner) is the one with vat = XYX belonging to Company1.
But it could happen that the def _match_partner() retrieves the wrong partner: the one of Company2.

Adding ('company_id', '=', self.env.user.company_id.id) in the domain of these lines seems fixing the problem.
However there could be other cases where a patch is needed in order to make the module multicompany compliant.
I don't have time to investigate further and I will not have time to propose a PR during the next weeks, so I open this issue as a reminder to open a PR. In the meanwhile any help will be very appreciated!

@alexis-via I'm currently writing weboob modules for personal use (Belgium providers) and I'm asking myself if the weboob functionnality shouldn't be extracted in a separate module as you can parse different kind of websites to get invoices, purchases, ...

Is that acceptable for you if I do it in v11 ?

Moreover, I think the 'unece' should be externalized too (pulled by base_business_document_import).

Due to

The fallback with no parsing module installed leads to Exception.

@alexis-via Could you confirm ?

Not 100% sure about this, but I assume the following would be superior to the current code:

        issue_date.text = fields.Date.context_today(
            self.with_context(tz=self.company_id.partner_id.tz),
            fields.Datetime.to_datetime(self.date_invoice)
        ).strftime('%Y-%m-%d')

Maybe, this can also be mitigated by specifying the IssueDate in more detail. But usually it is sensible to emit the date in the TZ context of the document (including when TZ is specified).

Quoting: XSD/common/UBL-ExtensionContentDataType-2.1.xsd:18 ff.

  <!--import here all extension schemas-->
  <xsd:import namespace=
     "urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2"
              schemaLocation="UBL-CommonSignatureComponents-2.1.xsd"/>

We need a cleaner mechanism (at least for UBL standard documents) to validate the schema structure against UBL "conformant" cutomizations through the UBLExtensions mechanism.

e-cbc:CompanyID, used in t-cac:PartyLegalEntityType and t-cac:PartyTaxSchemeType are highly localization specific as per their nature.

Provide a method interface with a dictionary to fully configure this node according to localization needs (including attribute settings.)

In commit abd6da4 of PR #120 I temporarily disabled the tests of account_invoice_factur-x. The reason was that Travis failed with the following error:

The XML file is invalid against the XML Schema Definition
XSD Error: Element '{urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100}TypeCode': [facet 'enumeration'] The value '31' is not an element of the set {'10', '20', '30', '42', '48', '49', '57', '58', '59', '97', 'ZZZ'}., line 44
No valid XML file found in the PDF
FAIL

This issue is a reminder to:

• fix the above error;
• re-enable the tests of module account_invoice_factur-x.

Exemplifying through:

    @api.model
    def _ubl_add_delivery_terms(
            self, incoterm, parent_node, ns, version='2.1'):
        delivery_term = etree.SubElement(
            parent_node, ns['cac'] + 'DeliveryTerms')
        delivery_term_id = etree.SubElement(
            delivery_term, ns['cbc'] + 'ID',
            schemeAgencyID='6', schemeID='INCOTERM')
        delivery_term_id.text = incoterm.code
        return delivery_term

It would be a slightly better wording to use append -> _ubl_append_delivery_terms.

As order is relevant, this would help clarify what the method does and doesn't.

Related to #128 - it makes it specifically verbose to insert elements.

I have to work on these topics on UBL context (Odoo v8):

• Inventory Report (product stock in supplier warehouse)
• Prices and catalogue (exchange with suppliers)

My first module is Inventory Report but both module are with the same model product.supplierinfo.

I would like share opinions and experience on these topics with experts like @alexis-via @jbaudoux @lmignon @astirpe @wpichler or any other

Do you think I have to do one module depending the other or build modules strictly independent ?

For Inventory Report what module name should I choose ?

• supplier_stock_import_ubl
• ???

Only 2 fields for inventory report (supplier_stock_import_ubl) : stock_qty and last_stock (date)

docs:

• https://github.com/OCA/edi/blob/12.0/base_ubl/data/xsd-2.1/maindoc/UBL-InventoryReport-2.1.xsd (no difference with 2.2 version)
• https://github.com/Tradeshift/tradeshift-ubl-xsd/blob/master/src/test/resources/org/oasis-open/ubl/examples/UBL-InventoryReport-2.1-Example.xml

Regarding the module base_ubl:

In the code used to generate the customer section (the AccountingCustomerParty, the partner used for the address details is the partner's commercial partner, not the partner themselves.

We have noticed that this means that if the invoicing address is truly different from the company it is related to (perhaps the company has several different invoicing addresses), then the address selected onto the invoice is not respected: the invoice of the parent is used instead.

The decision is explicitly made here, but no comment or docstring has been supplied explaining why it is done like this.

The module was originally authored by @alexis-via : might he be able to shed some light on why things are done this way?

I am trying to figure out whether I need to hack some kind of patch into our own system or try to make a fix PR here. If this is the expected behaviour in the rest of the world, and I'd end up breaking everybody else's installations, I probably shouldn't go for it.

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-9.0

Modules to migrate

• account_invoice_import - By @hbrunn - #11
• account_invoice_import_invoice2data - By @hbrunn - #11
• account_invoice_import_ubl
• account_invoice_import_zugferd
• account_invoice_ubl
• account_invoice_zugferd
• base_business_document_import - By @hbrunn - #11
• base_business_document_import_phone
• base_business_document_import_stock
• base_ubl
• base_ubl_payment
• base_zugferd
• purchase_order_import
• purchase_order_import_ubl
• purchase_order_ubl
• sale_commercial_partner - By @thomaspaulb - #18
• sale_order_import
• sale_order_import_csv
• sale_order_import_ubl
• sale_order_ubl
• sale_stock_order_import - By @thomaspaulb - #18

Hello,

We have an error during installation with odoo.sh

Py3o are already installed on my odoo instance.

Thanks in advance

Who is supposed to create them? Should I just push something to 9 (I'm planning to migrate some of those modules), or does someone else need to run a script with elevated permissions?

When I tried to print a quotation, either the button or action menu, it will prompt an error:
Odoo Server Error Traceback (most recent call last): File "/opt/odoo/odoo-12/addons/web/controllers/main.py", line 1671, in report_download response = self.report_routes(reportname, docids=docids, converter=converter) File "/opt/odoo/odoo-12/odoo/http.py", line 519, in response_wrap response = f(*args, **kw) File "/opt/odoo/addons-test/report_xlsx/controllers/main.py", line 59, in report_routes reportname, docids, converter, **data File "/opt/odoo/odoo-12/odoo/http.py", line 519, in response_wrap response = f(*args, **kw) File "/opt/odoo/odoo-12/addons/web/controllers/main.py", line 1612, in report_routes pdf = report.with_context(context).render_qweb_pdf(docids, data=data)[0] File "/opt/odoo/addons-test/sale_order_ubl/models/report.py", line 22, in render_qweb_pdf pdf_content = order.embed_ubl_xml_in_pdf(pdf_content=pdf_content) File "/opt/odoo/addons-test/sale_order_ubl/models/sale.py", line 193, in embed_ubl_xml_in_pdf pdf_content=pdf_content, pdf_file=pdf_file) File "/opt/odoo/addons-test/base_ubl/models/ubl.py", line 529, in embed_xml_in_pdf original_pdf_file = BytesIO(pdf_content) TypeError: a bytes-like object is required, not 'tuple'

I went through the server debug log, there is nothing like this, the last lines of logs is like this:
2020-04-17 04:38:29,773 21872 DEBUG test odoo.addons.base_ubl.models.ubl: Starting to embed UBL-Quotation-2.1.xml in PDF file 2020-04-17 04:38:29,779 21872 INFO test werkzeug: 10.10.10.50 - - [17/Apr/2020 04:38:29] "POST /report/download HTTP/1.0" 200 - 453 0.815 8.514

I can't figure out why this is happening, can anyone help?

Can someone with the super-powers configure the default branch of this project to 10.0 (currently 8.0) ? @pedrobaeza ?

Thanks in advance.

I have a bunch of invoices from my company and want to use the account_invoice_import module to import these old invoices of my company.

Is this possible with the current app? What is needed to make this possible? Can someone point me in the right direction?

Thanks for your help.

Best Philipp

I get the following error while importing purchase_order_ubl-10.0.1.0.0

Successfully imported module 'base_vat_sanitized' Error while importing module 'base_ubl': u'Unmet module dependencies: product_uom_unece, account_tax_unece, base_vat_sanitized\nNone' Error while importing module 'purchase_order_ubl': u'Unmet module dependencies: base_ubl\nNone' Error while importing module 'account_tax_unece': u'Unmet module dependencies: base_unece\nNone' Error while importing module 'base_unece': '' Error while importing module 'product_uom_unece': ''

We are using: Odoo 10.0+e-20170519 (Enterprise Edition) is this a known error?

When importing account_e-invoice_generate-10.0.1.0.0.zip, we get the following error:

Error while importing module 'account_e-invoice_generate': ''

With a EU customer the VAT should be 0% but the UBL xml file shows 21% VAT (for NL) instead of 0% on the product item:

  <cac:ClassifiedTaxCategory>
    <cbc:ID schemeAgencyID="6" schemeID="UN/ECE 5305">S</cbc:ID>
    <cbc:Name>BTW(VAT) 21%</cbc:Name>
    <cbc:Percent>21.0</cbc:Percent>
    <cac:TaxScheme>
      <cbc:ID schemeAgencyID="6" schemeID="UN/ECE 5153">VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:ClassifiedTaxCategory>

_ubl_add_address(..., node_name, ...) is actually better named:
_ubl_add_address_type(..., node_name, ...), and so forth, see UBL types:
http://www.datypic.com/sc/ubl21/t-cac_AddressType.html

This introduces a consistent distinction between types and their concrete implementation.
Every type implementation should be linked to the docs (url in the docstring, both UBL 2.0 & UBL 2.1) for convenience for developers.

If this is ok, I can prepare a commit.

Although linting, consider the worthiness of strong conceptual foundations in the code base.

I try to fix EDI v8 but I don't understand some messages

https://travis-ci.org/github/OCA/edi/jobs/670139063

The command "sh -e /etc/init.d/xvfb start" failed and exited with 127 during .

Which changes are required in travis or else

#182

Please @sbidoul @gurneyalex @moylop260 could you have a look here. Thanks

Some branch are red because of code like here in v12

https://travis-ci.org/github/OCA/edi/jobs/663059314#L325-L328

base_ubl/models/ubl.py:57: [W0622(redefined-builtin), BaseUbl._ubl_add_address] Redefining built-in 'zip'

base_ubl/models/ubl.py:286: [W0622(redefined-builtin), BaseUbl._ubl_add_line_item] Redefining built-in 'type'

base_ubl/models/ubl.py:329: [W0622(redefined-builtin), BaseUbl._ubl_add_item] Redefining built-in 'type'

base_ubl/models/ubl.py:609: [W0622(redefined-builtin), BaseUbl.ubl_parse_address] Redefining built-in 'zip'

I propose to rename zip var or arg in zip_ and type in type_

It could break some method calls in case of named argument like here
https://github.com/OCA/edi/blob/12.0/base_ubl/models/ubl.py#L323-L329

but sure we'll at to fix it

What do you think ?

Thanks for sharing your ideas @astirpe @SimoRubi @lmignon @tarteo @alexis-via @joshuajan @feketemihai @acsonefho @rousseldenis @luc-demeyer @Cedric-Pigeon

@alexis-via Instead of taking custom invoice2data templates from a directory on the Odoo serverś file system, did you consider storing the templates in the database and caching their contents? Would you be interested in this feature?

Hello,

I create new database and install module account_e-invoice_generate
Error message :
Modules "Account e-invoice Generate" and "Import Vendor Bills From XML" are incompatible.

What am I mistake?

Thank you.

Installing account_invoice_ import_invoice2data via
pip install odoo10_addon_account_invoice_import_invoice2data
works well, but when I try to install the module in the Apps section of Odoo I get this error:
'module' object has no attribute 'in_pdftotext'

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-12.0

Modules to migrate

• account_e-invoice_generate - By @joshuajan - #83
• account_invoice_factur-x - By @joshuajan - #79
• account_invoice_import - By @rubdos - #93
• account_invoice_import_ubl - By @astirpe - #103
• account_invoice_ubl_email_attachment - By @astirpe - #109
• account_invoice_ubl - By @astirpe - #97
• base_business_document_import - By @alexis-via - #85
• base_ubl - By @mreficent - #94
• base_ubl_payment - By @mreficent - #95
• base_zugferd
• purchase_order_import
• purchase_order_import_ubl
• purchase_order_ubl - By @astirpe - #99
• sale_order_import - By @astirpe - #101
• sale_order_import_csv
• sale_order_import_ubl - By @astirpe - #102
• sale_order_ubl - By @astirpe - #98
• sale_stock_order_import