When we started Transcepta, my co-founder Ray Parsons and I talked alot about the “name-space problem” and how much it has set back our attempts around the world to move to paperless B2B eCommerce.
This problem goes something like this:
- The accounting system of a buyer has a purchase order, ready to send to one of their suppliers. Unless they have pre-established EDI relationships with that supplier, they probably mail or fax the PO. Larger buyers almost always have the ability to send the PO to the supplier in electronic form (i.e. XML), but if they did, the supplier couldn’t read it. Why? You guessed it: the namespace problem. The buyer orders part number AD7823, but the supplier knows it as something else. Note that name-space problems aren’t just for part numbers; they also apply to simple fields like company name, address, PO number etc.
- Now the supplier receives this PO, and types it into their system as a sales order, translating buyer information into information that they understand.
- Once the good are shipped, we have all kinds of documents that are sent (advance shipping notifications, proofs of delivery, invoices, statements, credit memos); all of these are handled manually, because of the namespace problems. Note that even PO’d invoices still have the problem – because a supplier’s invoice often won’t have on it PO line item detail and other information required for the buyer to match.
- The payment process completes this mess – once the invoice is approved by the buyer, the payment is made and remittance data is passed in a way that the supplier almost always has to do some manual handling.
Is there a solution? Possibly, but it is no where in sight. In the late 1990′s and early 2000′s, there were initiatives to form standards, but the bodies couldn’t even agree on a schema to describe company name/ID and address! We also had groups like RosettaNet who were trying to become universal translators for us all, but when’s the last time any of us were asked by a customer to map to a RosettaNet standard?
There is one possibility: those of us in the financial supply chain automation business could get together and create interoperabilty standard to pass transactions back and forth. Why shouldn’t a Transcepta generated invoice, that came from one of our lightweight print-driver installations, feed transactions into an American Express/Harbor Payments system? Why shouldn’t all the A/P workflow vendors like 170 Systems, BasWare, Dolphin, & ReadSoft be able to handle eInvoices from all the eInvoicing solution providers?
Just thinking out loud here…