Posts Tagged eBIS-XML
This afternoon, I received a comment to my original blog about reinventing standards from Ronald Duncan of @UK PLC.
I feel that Ronald’s reply builds significantly onto the original blog and therefore deserves a special mention in this new blog as opposed to being hidden in a comment:
BASDA are current in the process of updating BASDA XML. I know it is nice and stable and we have not needed a release for 5 years, but in the same way we were one of the first XML schemas in existence back in 1999, and are still the most widely adopted globally. BASDA Green XML released into pilot this summer and currently in interoperability testing.
Is the first XML format to support Carbon footprints, embedded water, waste and all the other things that need to tracked in a modern world.
BASDA Green XML link
Regarding reinventing the wheel, there are lots of standards out there. My company @UK PLC is one of the largest interoperability hubs in the world with over 1 million users, and the flavours that we see are as follows:-
Mainly BASDA XML with a reasonable amount of cXML
xCBL some messages slowed down after commerce one went bust and stopped when BT turned off their old commerce one server
UBL despite a lot of hype 0 messages so far
GS1 XML less hype but also 0 messages so far
US ANSI X12
and some EDIFACT
Who uses BASDA XML, well basda members
I am not going to try and list every single vendor, but it is pretty well every single major finance system vendor.
I do know a couple of non-basda members that we have used basda xml with Forte by Cyberscience and Finest by Software AG.
The other group that have standardised on BASDA XML are the Hub Alliance.
The hub alliance is a global association of order and invoice hubs http://www.huballiance.org/
The members all have high volumes of transactions and interoperate using BASDA XML.
Many thanks for your comments Ronald.
Dennis Howlett recently blogged here on how some of the newer entrants to the industry are collaborating on a new, Simple Universal Business Language (SUBL), initiative to send and receive orders and invoices electronically between heterogeneous applications.
This sounds highly desirable and will undoubtedly save users time and improve the accuracy of entering transactions into software.
The thing is, like many of today’s new innovations it isn’t new at all… this particular idea has been around for ten years, yes that’s right ten years.
Back in 2000, a recognised industry body called Business Application Software Developers Association (BASDA) developed a similar, if not more refined, schema called eBIS-XML, in collaboration with their members, who comprise most of the business software vendors in the UK.
The eBIS-XML schema http://www.basda.org/ebis-xml-35485.htm was created to cover the spectrum of large systems as well as small ones, it can be very easily applied, BASDA provide a toolkit to aid vendors in development, and it has additional validation built in to check the message hasn’t been tampered with during transport.
As someone who implemented the schema into a range of software products during 2002, I found it very easy to understand and easy to work with. However, creating and parsing XML is the easy bit. What also needs to be considered is the reliability, or not, of the transport mechanism, i.e. most people use email, but we need to remember it’s not guaranteed delivery, or receipt, and can be inadvertently deleted.
You must also trap spam, you must support a moderation process allowing the user to decide what’s sent and received, for larger systems you must support complex reconciliation rules to pair up an invoice with an order and a payment, known as “three way invoice matching”, unique supplier/customer identification can pose a problem (e.g. supplier reference numbers and transaction reference numbers can differ from what you hold in the system), there are multi part orders and invoices to cater for, and you need to be able to make adjustments when part of an order is cancelled or if the payment doesn’t match the invoice.
In addition, in the UK there are also standards that need to be met to adhere to HMRC rules on electronic invoicing http://www.hmrc.gov.uk/vat/managing/charging/e-invoices.htm you can’t just send XML from one app to another and that’s it… the process needs to conform with audit standards just as a paper invoice does today.
Now, all of that shouldn’t frighten anyone off, because all of these problems have been solved, it’s all been done before.
At this point it’s fair to say that whilst a good number of businesses in the UK are using eBIS-XML to transfer documents electronically, even after 8 years it hasn’t become a defacto standard. Technically it’s a proven solution, so you might look elsewhere for other reasons… was the concept ahead of its time? Is it more attractive to larger business that process more transactions? Are other methods such as PDF used instead? Are people more confident to key transactions? Or did the industry fail to articulate the benefits to users?
What puzzles me is why another schema is being proposed when a perfectly good one already exists and is pervasive across most software vendors… I can only think that the new entrants probably weren’t around in 2000, or that the SUBL initiative is originating from outside of the UK and they don’t have knowledge of the BASDA schema.
Circling back to the original blog from Dennis, he comments:
I really don’t get why eBIS-XML is being avoided. I hear something about paying for the documentation (is that right?) but given the relative size of the market and numbers of customer, is that such a big deal? Alternatively, it can’t take that much pressure to get BASDA (or whomever is the copyright owner) to release eBIS-XML as a freely available standard… Bottom line – I don’t really get why you all are re-inventing the wheel?
I have to agree with Dennis here, and in the pursuit of creating an industry standard, I would ask the new entrants, would it not be better to join with the other BASDA members and build on what they have already produced… that way we all have a better chance of delivering a defacto standard for our customers and for our industry?