RE: [ubl-dev] How big can the invoice number field be?

["David RR Webber \(XML\)" <david@drrw.info>]

Fulton,

Excerpt and some notes to your good thoughts below.

Thanks, DW

> -------- Original Message --------
> 
> I'm not sure that UBL makes anything more complex, but rather that bridging
> dissimilar data worlds is inherently complex. 

 +1 on that!  

However what we have learned is controlling and managing and understanding the context involved in the use of the information is vital to success.  Data is not one dimensional - its 3D - and managing that 3rd "D" - context is key!

> 
> There are perhaps five points to be made:
> 
> 1. In the eBusiness world, the originator's systems and the receiver's
> systems probably each implement a maximum field length for a given data
> field. The two may differ from each other and from any standard.

Unfortunately systems evolved before XML provided better means to share metadata!

> 
> 2. A UBL transaction in effect serves as a shipping container, so it needs
> to offer enough space to accommodate the data that the originator intends to
> send to its trading partner, with no risk of data truncation. Effectively,
> XML does not impose field length limits, so it does not presently pose a
> truncation risk. It is not at all clear to me that UBL itself should impose
> field length limits.

Agreed!

> 
> 3. Both the sender and receiver (or a third party) will each have
> implemented a mapping process to put the originator's data into the UBL
> package and to unpack it for handoff to the receiver's system. The mapping
> systems typically straddle the UBL/XML world and conventional data base
> world, so the question "what field length should I expect" pertains to the
> conventional database leg of the straddle. This mapping straddle presumably
> is the domain of CAM.

Exactly.  Now that we know the world is ugly - you need to know when and how people have deviated from best-practice.  Having the means to spell out rules that contextually can be applied - so people can be alerted to potential incompatible details. What CAM allows you to do is build a template of your own practice rules and content model.  Then you can apply that automatically to another instance and know immediately where the differences are.  Similarly you can share that template so potential partners can assess the compatibility between their systems and your own.

> 4. In many cases, the receiver's mapping process discards a portion of what
> arrives, perhaps entire data fields or portions of data fields. However, the
> receiver's mapping process or internal systems needs to "remember" what was
> actually sent (e.g., an invoice field with 35 alpha numeric characters) even
> though the receiver's internal process has a different field length - for
> example, only eighteen. In any response (e.g., a remittance advice), the
> receiver needs to be able to retrieve or reconstruct and echo back to the
> sender the full data field sent.

Obviously once partners are aware of the issues - then they have to find ways to resolve those.  XML provides mechanisms they never had in EDI - unfortunately most implementations persist in using XML just as if its a veneer on top of EDI.

> 5. If UBL is used internally (and doing so is a great idea), odds are that
> data differences between outside facing and inside facing systems will
> require "mapping" between b2b transactions (e.g., a release order sent from
> a buyer to a supplier) and an internal transaction (e.g., as recently
> discussed, an internal warehouse picking ticket). 

Amen to that!  Clearly the more systems that can align to UBL - the less ugly there becomes!!

> Perhaps UBL "best practices" should define typical field lengths, but not
> build hard edits into UBL itself.
> 

Clearly these edits are local specialization rules - that relate to specific context.

Two that we've seen are "EDIFACT" and then "ACCOUNTING SYSTEM XYZ".  So those rules should be configurable based on such context - and only applied when that occurs - separate from the standard.  That is why the flexible approach based on CAM templates and the context mechanism that it has that can be linked to the partner profile and transaction details - is vital.

DW