OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ubl-dev] UBL / XBRL / ebXML / UN-CEFACT


Mark,

 

UBL documents are an XML representation of document that you exchange between business partners. This documents are then received in the accounting systems of the businesses, and there they are resulting in entries in the appropriate ledgers. XBRL is specifically designed for generating reports based on those ledgers to show cumulative figures based on those individual entries. In the past business were creating those reports using their own standards, rules and layouts. XBRL is now changing that to a more formalized approach that are no longer system specific.

 

So you can see that UBL and XBRL are really used at the two opposite ends of business systems. If I need to report spending then I do not send out a documents with all the individual invoices that I received but a summary per some categorie with what I have spend.

 

That is also why I always refer to UBL documents as ¨transactional¨ because they generally apply to a specific business transaction. An ¨Award Notice¨ is not really a report but more the conclusion of a business transaction (the tendering process) where the final outcome if communicated to the business that was awarded the tender with a ¨Award Notice¨ transactional document.

If I need to report how many tenders I have been awarded then as a business I need to prepare a XBRL report that will show the cumulative value of all the awards and maybe a number specifying how many awards I have won etc etc. But again … that is a report, not the individual award itself.

So the requirements of the data elements that should be included in a transactional UBL document is much more detailed then what would be required in a report and at a completely different detail level then required in report.

 

Then about ebXML Core Specifications.  There can be many standards that are using ebXML Core specifications to define XML structures. You can even use it to define data structures that will never be used in an XML context based on that standard. (like designing database tables) The reverse is also true. I can define a standard based on ebXML Core specification but never use that within a ebXML infrastructure, just like UBL is doing. At my employer we are exchanging thousands and thousands of UBL documents, but we do not use an ebXML infrastructure to do that. We even use SFTP file transfers when that was appropriate to use. So they are exclusive and therefor the use of UBL in an ebXML infrastructure is optional (you can use a different standard) and also not a requirement to exchange UBL documents.

 

As far as I can tell the development of UBL was never ¨taken over¨ by UN-CEFACT and it has always been an OASIS managed project. But I´m only actively involved in UBL since a couple of years.

 

ebXML and UBL will not converge as you state because they are at different levels. They both cover different needs and therefor will remain separate. ebXML can be seen as something that defines how far apart the railtracks are (or maybe even that you might need railtracks, but you can decide how far apart they are). The UBL TC defined the railcar that can ride on those railtracks. But I can take a different railcar not designed by the UBL TC and still ride over those tracks. And I can take a UBL railcar and let it roll down the street without railtracks, or I can take the metal wheels off and replace them with car tires, but keep the same top structure (the UBL Document)

 

I hope this explains at least my view on these subjects and why I feel that XBRL and UBL are two separate things, and also why UBL and ebXML are separate.

 

Kees Duvekot

 

 

Van: Mark Ballard [mailto:markjballard@googlemail.com]
Verzonden: dinsdag 1 maart 2016 13:49
Aan: Duvekot, Kees
CC: ubl-dev@lists.oasis-open.org
Onderwerp: Re: [ubl-dev] UBL / XBRL / ebXML / UN-CEFACT

 

 

Thank you, Kees.

Would you be kind enough to clarify further?

 

XBRL stand for eXtensible Business Reporting Language and is by definition used for REPORTING.

 

The US Data Act stipulated last year that federal agencies report spending using given xbrl schema.

The Data Act said ongoing incompatibility "between financial information systems and data sources" had prompted it to take a data-centric approach to implementation. It said public bodies could export data in "XBRL, JSON, Protocol Buffer, CSV, or other formats". But public awards had to be reported to the Treasuty in a given xbrl schema. A look at a few federal, and state-level transparency systems show a variety of notice types and forms.

Does OASIS happen to know whether UBL has been used in any of these existing scenarios, perhaps in the Federal Procurement Data System (FDPS publishes forms that look like they were generated from XML).

 

UBL is more based on interactions between business entities so it is more of a transaction basis and not so much for reporting.


UBL has produced standard documents for reporting (e.g. award notice).

Regarding what you say about transactions, though, what does this mean in layman's terms? What data elements do you get in a transactional document that you don't get in a notice?

 

So I feel these two standards cover two different requirements and it does not make sense to try to use XBRL for these transaction interactions.

 

What difference does it make?

 

 

ebXML is a OASIS standard (just like UBL) that was created in cooperation with UN-CEFACT. UBL document can be used within an ebXML infrastructure, but it is not a requirement.

 

Ah...
 

While creating UBL the ebXML Core Components Technical Specification was used for creating the Business Information Entities.
for more information please see: http://ubl.xml.org/ebXML

 

I thought the point of UBL was that it implemented ebXML Core Components. How then could its "use within an ebXML infrastructure" be optional?

 

UN-CEFACT is a organisation that defines standards and recommendations just like OASIS is doing, so there is no direct relation between UBL and UN-CEFACT.

 

Apart from the fact that UN-CEFACT took over development of UBL in 2005?

 

If by UN-CEFACT you actually mean UN/EDIFACT then there will be by definition overlap and similarities between EDIFACT and UBL because they try to describe the same business ifnroamtion entities in different "languages".

 

As I understand it, ebXML grew out of EDIFCACT and UBL grew out of ebXML, roughtly speaking. And in fact, ebXML and UBL were to be converged under UN-CEFACT?
 

What you see happening is that specific trading communities try to bridge this. CEN/BII is now publishing both a UBL and EDIFACT mapping for their specifications:
http://www.cenbii.eu/deliverables/cen-bii-2/cwa-16562-post-award/

So there you have all the requirements to be able to map from one language to the other, but that does not mean you can just apply that to any UBL or EDIFACT document

So you will always have translators that will use a different interpretation of the language to come to a different translation from one to the other and there is no single truth. So I think both your statements will be just as inaccurate as saying English and Dutch should converge because we both have words to describe the same things. And because both languages uses words that were derived from each other (eg Ship vs Schip etc https://en.wikipedia.org/wiki/List_of_English_words_of_Dutch_origin) does mean it is easier to translate.

 

The original purpose of UBL was stated to be twofold: the extend the use of EDI to small businesses, and to remove the need to have multiple translators to handle business documents from different sources. This implies a single syntax, although it is possible to imagine a continuing need to translate between EDI and UBL.

So bearing in mind the growth of xbrl for financial reporting, and UBL's stated common-sense aims, it seemed reasonable to ask whether xbrl might become the dominant method of expressing procurement data, since it all ultimately is about finance.

Mark.


 

Kees Duvekot


________________________________________
Van: Mark Ballard [markjballard@googlemail.com]
Verzonden: donderdag 18 februari 2016 19:19
Aan: ubl-dev@lists.oasis-open.org
Onderwerp: [ubl-dev] UBL / XBRL / ebXML / UN-CEFACT


Would the list please tell me how UBL has been related to XBRL, ebXML and UN-CEFACT?

From what I have read around the topic, it seems work has been done to converge these different standards/formats. But I have found no ready statements on how this has been done and to what end.

So would I be correct to assume that:

(i) in those areas where UBL, ebXML, xbrl and UN-CEFACT map, they will or have been made syntactically identical, and
(ii) in those areas where they merely overlap, they would be / have been made as semantically identical as possible?

Assuming, that is, that everyone agrees it is desirable to have the least translation as possible when matching data from different sources...

So if you have an invoice (or indeed a contract award notice) in UBL, would it be as sensible as I imagine to to make it identical *in those parts of each data set in each language that overlap*? So a supplier or contractor or business entity field is always the same name, in the same place, with the same characteristics?

I have retained from what I had read of UBL's relationship with UN-CEFACT and ebXML the impression that they are identical where they overlap. How accurate is this?

I understand from what I've read of xbrl, however, that it contains the facility for referring elements to different regulatory schema or whatever, so that at least it can be recorded that a contract value, eg, has been entered according to particular accounting rules. Looks complicated. But since the world (the accounting profession and the US government, at least) is adopting XBRL, wouldn't it make sense for UBL to simply to describe everything in XBRL?

If these questions are clearly the product of utter ignorance, I would be very grateful if you would say so and how.

Mark Ballard.

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]