When the industry is crying out for standards, why reinvent the wheel?

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?

Advertisements

, ,

  1. #1 by Martijn Linssen on October 7, 2010 - 12:25 pm

    Hi Stuart, and where were you when X12 (http://en.wikipedia.org/wiki/ASC_X12) and EDIFACT (http://en.wikipedia.org/wiki/EDIFACT) saw the light – back in the ’80’s and 90’s?

    • #2 by Stuart Lynn on October 7, 2010 - 12:37 pm

      Actually, I was there… I used it when I worked for the Health Service back then, but it was always positioned as being difficult to understand and way out of reach of the man in the street… and because it predated XML, it was machine readable only, as shown by this example.

      UNB+IATB:1+6XPPC+LHPPC+940101:0950+1′
      UNH+1+PAORES:93:1:IA’
      MSG+1:45′
      IFT+3+XYZCOMPANY AVAILABILITY’
      ERC+A7V:1:AMD’
      IFT+3+NO MORE FLIGHTS’
      ODI’
      TVL+240493:1000::1220+FRA+JFK+DL+400+C’
      PDI++C:3+Y::3+F::1′
      APD+74C:0:::6++++++6X’
      TVL+240493:1740::2030+JFK+MIA+DL+081+C’
      PDI++C:4′
      APD+EM2:0:1630::6+++++++DA’
      UNT+13+1′
      UNZ+1+1′

      Whereas understanding XML is much easier, and by applying a simple style sheet XML is both machine readable and human readable.

      • #3 by Martijn Linssen on October 7, 2010 - 12:49 pm

        I can read that perfectly of course, but then again I’m not a man in the street – and I believe most things should be kept from him anyway, so he can just sip on his cocktail

        There has never been a business case for electronic messages having to be easily readable by the man on the street – that would be the same as making car engines “humanly-readable”

        Understanding XML is much, much harder really: try http://www.martijnlinssen.com/2010/10/dummys-guide-to-standardisation.html

        But, since you acknowledge the value of EDIFACT (thank you for being sincere) you’d like this one a lot, I think: http://www.stylusstudio.com/edifact_to_xml.html – combines the “readability” apparently much thought-after by the man in the street, with the great “proven business” and proven technology of EDIFACT

        How about that? That should be what it should be, right? Same business, just another language?

      • #4 by Stuart Lynn on October 7, 2010 - 1:04 pm

        I absolutely agree with you that technology should be hidden from the user…

        However, this may be the case for readability, i.e. in the scenario when the message (a Sales Invoice) fails import validation because something is wrong with the product reference number (you call it ABC123 and they call it 123ABC)… you can either bounce it back, or you can present what you have to the user in readable form and they can solve the problem and manually key the transaction… a very common occurrence in the world of small businesses where only a handful of transactions are taking place, its easy for a human to spot and fix the problem, and time is money.

      • #5 by Ronald Duncan on October 8, 2010 - 5:30 pm

        We get 100% of invoices to go through by making sure that the data is correct from the requisition point onwards.

        ie. NHS user goes out to supplier site and gets the correct part no, pricing, delivery charges and configures any thing like computers, orthotics or hearing aids at the time of requisition.

        The requisition is approved and turned into a PO with the correct information.

        Invoice comes back with the same information.

        No part no, price or other mess.

        The only question is the delivery receipting of did you get what was ordered, which again is automated, but requires either invoices that match the receipt or credit notes to correct invoices that do not match the receipt.

        The key part is ensuring that data is correct at the point of requisition and moving away from out of date catalogue push system to a pull system of getting the current data from the supplier at the point of requisition.

        We support both models but our preference and that of our suppliers is the pull system were the buyer is automatically connected to the suppliers current information.

        The process is called punchout, and there are 4 major implementations

        cXML (a open standard that has been implemented in multiple ways) – backed by Ariba
        sbxp (an open standard with reference implementations in all major languages) – backed by @UK PLC
        OCI (SAP method)
        OAGXML (Oracle method)

      • #6 by Stuart Lynn on October 8, 2010 - 5:47 pm

        Thanks Ronald, very interesting insight indeed… have you, or do you know of anyone who has, lobbied BASDA to comply with this method?

      • #7 by Ronald Duncan on October 12, 2010 - 7:19 pm

        Most of the major BASDA Vendors already support punchout.

        Agresso and Coda
        Cedar
        Civica (not sure on membership)
        Integra
        Oracle
        Sage (line 500 with an @UK PLC Toolkit)
        Sap

        So the Vendors are all on board, it is just a question of education for the customers.

        The major suppliers are in a similar place where they support and prefer punchout as a connection mechanism to ensure that the transaction is correct from the beginning.

        It is just a case of general education that this technology is around. We have been fully supporting it from about 2000, and I can not remember when I wrote sbxp, but we registered the domain in 2004 so it was some time in 2003. That we decided to provide a set of interoperable implementations in all the major languages.rather than a standard that people interpreted differently.

        So the pull method has been around for over 10 years.

        Some times good things take a while to get adopted.

  2. #8 by Martijn Linssen on October 7, 2010 - 1:16 pm

    Yes, that’s a real-life example indeed, I’ll give you that. But, it’s also an IRL example that the given interface fails with an error: “product reference number doesn’t have the agreed layout (e.g. ABC123)”

    You do touch a subtle field though: where is the frontier for automation? How many orders a day? SMB, enterprise, big partners / small partners, ah the pain, the agony!
    It is where EDI has failed over the last decades: http://www.martijnlinssen.com/2010/06/core-business-versus-business.html – and the question that remains, is the question of lock-in: http://www.martijnlinssen.com/2010/09/how-locked-in-are-you-really.html

    You’re not going to solve that with XML – you need expert knowledge to be an expert…

  3. #9 by Ronald Duncan on October 8, 2010 - 5:22 pm

    Hi,

    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
    http://www.basda.org/basda-green-xml-44089.htm

    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:-

    XML
    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

    EDI
    UK Tradacom
    US ANSI X12
    and some EDIFACT

    Who uses BASDA XML, well basda members

    SAGE
    Oracle
    SAP
    Microsoft
    Cedar
    Agresso
    Coda
    Infor
    Access Dimensions

    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.

  1. eBIS-XML v SUBL: it’s a stupid discussion AccMan
  2. When the industry is crying out for standards – customer validation « Stuart Lynn's Blog
  3. Changing your car could be a metaphor for software upgrade AccMan
  4. 2010 blog review « Stuart Lynn's Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: