[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] ubiquitous UBLExtensions: a proposal
|
My comments inline.
On Tuesday, 27 August 2019 16:03:04 BST Kenneth Bengtsson wrote: > If (and I do not know the logistics of invoicing in Columbia) > the invoice were to be sent from the originator to the tax > administrator and then on to the recipient, then we have > or course just increased the number of parties to the conversation
That is how invoicing works in a clearance country. The supplier first sends a draft invoice to the tax administrator, the tax administrator validates the content of the issue and authorizes the invoice if its conformant, then the tax administrator sends an approval back to the supplier, and finally the supplier can send the approved invoice to his customer. My point stands, if the tax administrator can not be sure that they have read the whole invoice, would they be prepared to authorise the invoice. Lets say there is another extension in there, not theirs, surely they would want to be able to read it as well? > To take the Columbian example, do you suppose that the tax > administrators would be happy accepting an invoice if it was > pointed out to them that some bits of this document might be > unreadable using either the software the recipient was using or > using whatever software they (the tax admin) had available to > them
Well, in the case of Colombia, it is the tax administrator who requires the use of the extension within the UBL document. The information contained in the extension only applies to the relationship between the issuer (supplier party) and the tax administrator and is irrelevant for the recipient (buyer party) of the invoice. The buyer party may safely ignore the information in the extension. Here is an example: https://www.dian.gov.co/fizcalizacioncontrol/herramienconsulta/FacturaElectronica/Factura%20Electrnica/Ejemplos/Facturas%20firmadas.zip
But I think this is irrelevant to the discussion of extensions. It was just to give an example where extensions can be useful. My proposal is designed to enable extensions, while making sure they are used correctly and that everyone who needs to be able to read the content can do so. By designing it into the system it becomes more obvious when someone is trying to do things they should not. David Best regards,
Kenneth
From: David Goodenough <david.goodenough@broadwellmanor.co.uk>
I have to say that just putting in some warm words would not be enough in my option.
To take the Columbian example, do you suppose that the tax administrators would be happy accepting an invoice if it was pointed out to them that some bits of this document might be unreadable using either the software the recipient was using or using whatever software they (the tax admin) had available to them. Sure it would show the Columbian extension, but I am sure they would want to know what other extensions (or rather the data and intend behind it) were present. If (and I do not know the logistics of invoicing in Columbia) the invoice were to be sent from the originator to the tax administrator and then on to the recipient, then we have or course just increased the number of parties to the conversation, and the number of systems we need to keep in step when it comes to the software they are running. Making this part of the spec would simplify life in this respect.
In addition as a British company, at least a large one who would be expected to do due diligence with things like the money laundering legislation, I would expect that if this were a large invoice or an unusual one I should at least be aware that this extension is present, and that I (or my auditors or regulators) would want to be able to audit its content.
I had not considered the case where a PermittedExtension was required for a given DigitalAgreement, perhaps an additional field saying that this extension is required on some class of (up to and including all) UBL documents would be useful, which would allow a check by the receiving software that it is present. This would then be mandated by the Columbians for UBL invoices between Columbian businesses and would be auditable for compliance.
David
On Tuesday, 27 August 2019 13:39:47 BST Kenneth Bengtsson wrote: Hi David
Thank you for your valuable comments and input. I will try to clarify the extensions in the UBL 2.3 draft and in general:
UBL is recognized as an international standard for business documents (ISO/IEC 19845). Whether a business document is also a âlegal documentâ depends entirely on your definition of âlegal documentsâ as well as of the laws and practices of the specific jurisdiction where you would want your UBL document to have the value of a legal instrument.
In the UBL TC we obviously do not try to define legal practices and requirements. We define a technical format and vocabulary, which in many cases is adopted as de jure standard in individual jurisdictions, and in other cases simply adopted as de facto standard for exchanging information between two or many trading partners.
Whether used as a de jure or as a de facto standard, there may be situations where a UBL user or a group of users has the need to express information in a UBL document which cannot be expressed using the existing UBL library. This could be information so specific to the systems and circumstances of the user that we didnât find any reason to include it UBL.
Take a look at the Colombian e-invoice for example. Colombia is an invoice clearing country, meaning that before an invoice becomes a legal fiscal instrument, a supplier must first send it to the tax administrator to obtain a permission, and only then can he send the invoice to the buyer. The Colombian e-invoice contains all the usual information items that you would expect to find in an invoice (buyer party, supplier party, tax and VAT, line items, prices, and so on), all expressed as UBL, and it also contains information that is specific to the Colombian tax administratorâs issue approval process - reference to a previously obtained approval from the tax administrator for the issuer to use a certain range of invoice numbers for example.
In UBL we donât have a specific field where one can express the Colombian tax administratorâs authorization number that approves that a company can issue invoices numbered in the range 100 to 200, and it probably isnât very relevant to anyone except the Colombian tax administrator. So they have made a UBL extension to express that information. If you as a British entity were to receive an invoice from a Colombian supplier, you could safely ignore the information in the extension because the information you would usually need from the invoice is expressed in the âcommonâ UBL structure.
The intention of the UBL extensions is to allow implementors and users to express information that they canât express using existing UBL vocabulary. Itâs a flexibility that allows UBL to be used as a de facto or de jure standard even in situations where there are requirements not foreseen by the UBL TC or so specific that they donât âbelongâ in a global standard. In previous versions, these extensions could only be included at document level. But what if a user needs to include such information at line level? This is what we are trying to accommodate for in UBL 2.3.
Notwithstanding the above, I do understand and share your concern about extensions. They shouldnât be misused and they shouldnât be used to express information that is already contained and standardized in the UBL vocabulary itself. Perhaps we can emphasize this in the prose specification.
Best regards,
Kenneth
From: David Goodenough <david.goodenough@broadwellmanor.co.uk>
Following on from my comments on the UBL 2.3 draft I would like to offer a draft proposal which I think might solve the problem.
I appreciate that UBL is not a recognised international standard for legal documents, but it does replace what would otherwise be legal documents and for ease of end user comprehension it would be easier if the same basic rules applied to paper and electronic documents. In addition it seems a reasonably aspiration for UBL documents to be recognised as the same legal status as paper ones.
The problem arises because a generic client will not be able to read and therefore present to the user or to an API into other systems items that are encoded in the UBL extension for which it has no support. The extensions are therefore hidden from the user which is legally undesirable. Note that the Signature extension as described in the UBL documentation is not included in this discussion as it is well defined and publicly documented.
In the notes below upper cased words such as MUST or SHOULD are intended to be interpreted following the notes in IETF RFC 2119.
The proposed solution to this problem involves adding a single element to DigitalCapability and DigitalAgreement documents which describes the permitted extensions that can be used (and where they can be used) in document exchanges sanctioned by this DigitalAgreement. This element is tentatively called PermittedExtension, and is minOccurs="0" maxOccurs="unbounded". If there is no PermittedExtension object in the final DigitalAgreement then any document that is received which contains a UBLExtensions clause other than the Signature extension document in the UBL 2.3 documentation MUST be rejected by the receiver. This maintains the current behaviour on all but the document level tags. Whether it should apply immediately to the existing document level tags is an open question, my instinct is that it should as it will be difficult to increase the enforcement later.
I would suggest, but I have only given 18 hours thought to this, that these PermittedExtension objects could be included in the DigitalProcess or DigitalCollaboration objects as they are they are about a conversation and the same rules should apply to both ends of the conversation.
A PermittedExtension object MUST contain an ID which defines the name of this extension and the controlling agency. It MUST also include a URI for the schema of the extension and a URI for a narrative document describing the meaning of the extension. Both these URIs and the documents they point at MUST be publicly and freely accessible and usable - the rational for this is that if subsequent inspections of such documents by outside bodies (be they governmental, trade assurance schemes, or such as auditors ) must be possible without let or hindrance. A PermittedExtension MUST also include a minimum and maximum version number of the extension, so that the handling of the corresponding UBLExtension (I hope these are versioned if not they need to be) can be ensured. Finally the PermittedExtension object MUST contain a list of UBL objects within which the extension can be used. It might be useful for an extension to be used on for instance all Party objects where ever they are used, but it might be that they should only be used in a say DespatchAdvice object. Do we need a UBL version check in here as well?
If a receiver's software receives a DigitalCapability or draft DigitalAgreement (the one in response to a DigitalCapability) which requests a PermittedExtension that it is not equipped to handle the document MUST be rejected with an ApplicationResponse including the PermittedExtension that can not be accepted. The sender's system MAY then amend the DC or DA to remove the unacceptable PermittedExtension or it MAY terminate the conversation. The sender's system SHOULD NOT re-send a refused PermittedExtension unless the receiver's system has been updated to accept it. Coordinating this update notification is outside the scope of UBL communications.
If a receiver's software receive a UBL document which contains one or more UBLExtension objects that are not included in the list of PermittedExtension objects in the current DigitalAgreement the software MUST reject the document with an ApplicationResponse including the un-permitted UBLExtension.
One question that worries me is how we do schema validation in this environment. Doing schema validation is desirable as it makes the code easier to write if the datastream is known to obey the schema, but I am unsure (I simply have not had time to look) whether schema validating XML loaders have the ability to merge schemas in this fashion. This is an area that needs further research.
I hope that this document is a useful starting point (along with my original objection) to resolve this problem. My preference would be either to define and include a PermittedExtension like object in 2.3, or if it is to be deferred to 2.4 that the UBLExtension proliferation that occurs in the 2.3 draft be withdrawn until the PermittedExtension functionality can be included.
David
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]