The “name-space problem” - a huge issue that shouldn’t be…
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…
Written by Mitch Baxter - Visit Website
Mitch Baxter's Articles
Last 5 posts by Mitch Baxter
- The "name-space problem" - a huge issue that shouldn't be... - November 18th, 2007
- U.S. versus Europe - Leaders, Laggards and Automative Adoption - October 25th, 2007
- Mitch Baxter - January 1st, 2007
Related Posts
5 Responses to “The “name-space problem” - a huge issue that shouldn’t be…”
Leave a Reply
You must be logged in to post a comment.
November 19th, 2007 at 3:29 am
Mitch,
You are clearly underlining a crucial issue of our industry but I would not say that a solution is no where in sight.
There is at least one initiative driven by S.W.I.F.T, the mega co-operative established by and for the financial industry to provide secure financial (and now financial supply chain) messaging services, which solves at least part of it. It is called the SWIFTNet Trade Services Utility (TSU): http://www.swift.com/index.cfm?item_id=2327
S.W.I.F.T. is a well-known Standards body and the financial supply chain messaging part is submitted to ISO 20022 which helps with your lack of standards issue.
And in addition to the Standards for PO (baseline), Invoice (commercial data), transport data, etc. you also get a central matching and workflow engine, which are all interesting to help with your PO’d invoices line item matching issue.
Of course, the TSU is bank-to-bank only and it is up to the financial institutions to then develop their own corporate-to-bank services powered by the TSU (and complementary solutions like our own at Misys), but it is certainly an initiative which seems to go in the direction you are calling for.
Cheers,
Olivier.
November 19th, 2007 at 11:00 pm
Makes sense to me Olivier. I wish a standard like this set would take off and ease this problem. Thanks for the SWIFT links, I have checked them out and they look really interesting!
Mitch
November 30th, 2007 at 3:01 pm
Mitch,
As another player in the AP workflow space, we definitely agree with you that a standard would (will??) completely eliminate the name-space problem and all the other inefficiencies resulting from invoices coming to and from multiple vendors, systems and formats.
Although it may not make it go away, we feel our full-text indexing architecture, and resulting intelligent invoice identification, definitely makes the best out of a difficult situation.
If MetaViewer has received an invoice from a specific vendor or third party source previously, it can automatically identify where the invoice came from and full-text all the information according to each vendor regardless of whether it came on paper, from a private MetaViewer vendor network or from any standardized, open eInvoicing network such as EDI, OB10, Xign or Transcepta.
Once in our system this information can be properly routed, processed and posted into the payers ERP or Accounting system.
In short, although a standard would be the be-all, end-all solution to this problem, it is precisely the type of problem that our full-text architecture was designed to solve.
This is the same way that Google has solved the problem for sharing and indexing web-site information. A field-based solution simply WOULD NOT WORK. The MetaViewer “Google-like” full-text architecture is the only chance to standardize invoices from hundreds of very un-standard sources.
I also believe that it is this type normalization and ease of exchange that has help Transcepta successfully achieve the membership that it has and look forward to processing many more invoices from the Transcepta network.
Nick
December 3rd, 2007 at 5:56 pm
Nick,
I love the idea of a product like MetaViewer - I just never thought of applying it to a document like an invoice. Would it work for line-item details too, esp. when they repeat across pages, with headers and footers in between bottom-of-page and top-of-next-page line items?
Good stuff,
Mitch
December 4th, 2007 at 4:39 pm
Thanks Mitch,
You bring up another perfect example of how electronic invoices and a full-text architecture can make a significant difference. Assuming that the headers and footers are consistent, the MetaViewer system can be “taught” to ignore those when setting up that Vendor in the system. The line item detail can then be captured across successive pages.
A similar classic example that we see all the time is capturing a printed check run with line item detail on the stub. Whether the check is paying one item or hundreds, all that information can be easily captured and later searched if the solution is full-text capable.
Trying to capture all that information from paper or with a field-only index would not be possible.
Nick