oca / edi Goto Github PK
View Code? Open in Web Editor NEWLicense: GNU Affero General Public License v3.0
License: GNU Affero General Public License v3.0
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'
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
Please @sbidoul @gurneyalex @moylop260 could you have a look here. Thanks
This is a meta issue to keep track of the current raid. All referenced issues are still WIP
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.)
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).
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.
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
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.
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
_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.
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 the XML file included when sending mail?
UBL 2 Guidelines for Customization,
First Edition
Committee Specification 01
25 December 2009
Validation is recommended to be a two step process:
.xsd
-files").xsl
-files) - as for example compiled from a schematronMany 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:
company
parameter within _ubl_add_party
is not correct.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
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
https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-11.0
Due to
and a contrario of the module README, it is not possible of 'simply' create a draft invoice with the file as attachment.The fallback with no parsing module installed leads to Exception.
@alexis-via Could you confirm ?
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:PartyType
s can use them as e-cac:PhysicalLocation
, see:
http://www.datypic.com/sc/ubl21/t-cac_PartyType.html
https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-9.0
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.
The main menu item will be located in menu item 'Settings'.
No new widgets are needed to implement the functionalities; the graphical interface will consist of default Odoo GUI components.
To grant access to the taxonomy builder features, a group (res.groups) is needed (something like "Manage XBRL Taxonomies").
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'.
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.
@alexis-via, last merge has discovered several problems on Travis. Can you please fix them?
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).
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?
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.
Can someone with the super-powers configure the default branch of this project to 10.0 (currently 8.0) ? @pedrobaeza ?
Thanks in advance.
@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?
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
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
https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-13.0
❓ Missing module ❓ Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list
from lxml.builder import ElementMaker
...
nsmap = {
None: 'urn:oasis:names:specification:ubl:schema:xsd:' + doc_name,
'cac': 'urn:oasis:names:specification:ubl:'
'schema:xsd:CommonAggregateComponents-2',
'cbc': 'urn:oasis:names:specification:ubl:schema:xsd:'
'CommonBasicComponents-2',
}
em = {
'cac': ElementMaker(namespace=nsmap['cac'], nsmap=nsmap),
'cbc': ElementMaker(namespace=nsmap['cbc'], nsmap=nsmap),
}
...
addresses = [
em['cac'].Address('foo'),
em['cac'].Address('bar')
]
locations = [
em['cac'].PyhtiscalLocation('foo'),
em['cac'].PyhtiscalLocation('bar')
]
em['cac'].PartyTaxScheme(
em['cbc'].RegistrationName(registration_name),
em['cbc'].CompanyID(commercial_partner.sanitized_vat, schemeID='11'),
*addresses,
*locations
)
...
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
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:
account_invoice_factur-x
.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 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).
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.
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?
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.
https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-12.0
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
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.
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
I have to work on these topics on UBL context (Odoo v8):
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 ?
Only 2 fields for inventory report (supplier_stock_import_ubl) : stock_qty and last_stock (date)
docs:
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
OrderResponseCode
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:
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
<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 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>
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 :
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
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
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>
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.
<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>
Tested with 11.0.
Here is the scenario:
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!
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 (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.
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.
<?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.
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>
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.