OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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

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.

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.

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.

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.

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). 

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


					Fulton Wilcox
					Colts Neck Solutions LLC
 

-----Original Message-----
From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk] 
Sent: Wednesday, February 13, 2008 2:11 AM
To: ubl-dev@lists.oasis-open.org
Subject: RE: [ubl-dev] How big can the invoice number field be?

Hi David

Not me that's asking. I guess Thomas would prefer it if all this
was packaged up and maybe distilled down into just a few links.
The question asked was pretty simple. It just looks a tad like
the UBL solution is even more complex than the EDI one. I don't
think it needed to be like this, shame it has gotten a bit like
this though. In short I would say Thomas and others would need
a rule like 'UBL doesn't provide datatype length restrictions
(for database storage, etc) - use EDI ones' and maybe some
helpful ready-made artefacts to that end to aid interoperability
and conformance across implementations to make it real.

-- 
Stephen D. Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice



Quoting "David RR Webber \(XML\)" <david@drrw.info>:

> Stephen,
>
> I that regard - ping Pim @ OASIS - he is working on some XML to   
> manage CPPA / XSD / CAM and MoU in a package that can then drive   
> partner agreement SW - see also draft postings to CPPA documents area.
>
> DW
>
>> -------- Original Message --------
>> Subject: Re: [ubl-dev] How big can the invoice number field be?
>> From: "Stephen Green" <stephengreenubl@gmail.com>
>> Date: Tue, February 12, 2008 12:06 pm
>> To: "David RR Webber (XML)" <david@drrw.info>
>> Cc: "G. Ken Holman" <gkholman@cranesoftwrights.com>,
>> ubl-dev@lists.oasis-open.org,  fulton.wilcox@coltsnecksolutions.com
>>
>> Yes, well caught David :-)
>>
>> And of course you also need a framework (like ebXML with ebBP and ebCPPA)
>> to properly document all this in a potentially machine-processable   
>> way. If not
>> using ebXML there might be some challenges e.g. with WSDL there doesn't
>> seem to be a way in WSDL itself to declare the extra datatype   
>> restrictions for
>> runtime use. You might have to rely on design-time documentation and
hard-
>> coding. I'm trying to see how far the OASIS TAG TC output might carry you
if
>> you need to declare the restrictions with prose first - a nice   
>> 'test assertion'
>> representation XML markup (if we produce one) should allow generation of
>> test suites (for conformance on a large scale warranting automated   
>> repeatable
>> testing of many endpoints/parties), CAM, Schematron, HTML prose,
whatever.
>> Worth keeping an eye on the OASIS TAMIE TC work too in this regard.
Depends
>> how far you need to go and how many expected parties, etc.
>>
>> On 12/02/2008, David RR Webber (XML) <david@drrw.info> wrote:
>> > Stephen,
>> >
>> > Just getting caught up on email here.
>> >
>> > This of course is EXACTLY why you should be using CAM templates   
>> to define the business interchange with your partners - overlayed   
>> from the UBL schemas.
>> >
>> > CAM provides you all the tools to share with your partners such   
>> constraints - contextually - so there are no surprises - and you   
>> can mitigate the information flows as you need them by using   
>> context variables so the processing knows exactly what template   
>> profile applies to what business process step with your partner(s).
>> >
>> > Also - unlike schema - where its really tough to find where   
>> contraints and definitions differ from the defaults - CAM makes it   
>> immediately apparent - you can search on any set-length() functions  
>>  to discover what items are effected - and the HTML documentation   
>> format includes field-by-field details so business analysts can   
>> verify the functional rules without having to know schema or XML.
>> >
>> > Cheers, DW.
>> >
>> > > -------- Original Message --------
>> > > Subject: Re: [ubl-dev] How big can the invoice number field be?
>> > > From: "Stephen Green" <stephengreenubl@gmail.com>
>> > > Date: Tue, February 12, 2008 12:35 am
>> > > To: fulton.wilcox@coltsnecksolutions.com
>> > > Cc: "G. Ken Holman" <gkholman@cranesoftwrights.com>,
>> > > ubl-dev@lists.oasis-open.org
>> > >
>> > > Plus, I have to confess to being a 'legacy' developer still working
>> > > on mainframes most of my time. But isn't it the fact that finance
>> > > systems all use a database. Surely there's nothing 'legacy' about
>> > > that. RDMS databases still all limit the field lengths don't they?
>> > >
>> > > On 12/02/2008, Stephen Green <stephengreenubl@gmail.com> wrote:
>> > > > I think it should be an issue for UBL that lack of a limit in UBL
>> > > > might encourage some to go over 35 characters. UBL should
>> > > > think about what problems that will lead to. Just how many
>> > > > systems out there are limited to something like 35 characters?
>> > > >  My guess is it is 'still' a high percentage.
>> > > >
>> > > > I've seen limits on amounts, etc added to documents as a type
>> > > > of document-header-level metadata. Maybe this is a candidate
>> > > > for the UBLExtension.
>> > > >
>> > > >
>> > > >
>> > > > On 12/02/2008, Fulton Wilcox
>> > > > <fulton.wilcox@coltsnecksolutions.com> wrote:
>> > > > > Edifact invoices have an invoice length of 35 alpha-numeric  
>>  characters, so
>> > > > > that is a pretty good answer to the question of how long an  
>>  invoice number
>> > > > > can be. It is unlikely that any (or at least many) trading   
>> partners will
>> > > > > have invoice-generating systems that create longer invoice
numbers.
>> > > > >
>> > > > > If invoice number were in fact merely an identifying   
>> number, 35 positions
>> > > > is
>> > > > > absurdly long - enough for each human being in the world to  
>>  generate 15
>> > > > > trillion trillion invoices with unique IDs. Unfortunately   
>> that field is
>> > > > > typically used as a composite string representing all sorts  
>>  of meaning,
>> > > > > hence the absurd length. If an invoice number has leading   
>> zeroes, those
>> > > > > leading zeroes should not be lost in the enterprise to   
>> enterprise handoff.
>> > > > >
>> > > > >                                                 Fulton
>> > > > Wilcox
>> > > > >                                                 Colts
>> > > > Neck Solutions LLC
>> > > > >
>> > > > >
>> > > > >
>> > > > > -----Original Message-----
>> > > > > From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com]
>> > > > > Sent: Monday, February 11, 2008 7:52 PM
>> > > > > To: ubl-dev@lists.oasis-open.org
>> > > > > Subject: Re: [ubl-dev] How big can the invoice number field be?
>> > > > >
>> > > > > At 2008-02-11 16:41 -0500, Tobey, Thomas N. wrote:
>> > > > > >Greetings!
>> > > > >
>> > > > > Welcome!
>> > > > >
>> > > > > >I've been trying to find a standard recommendation for how
>> > > > > >long the invoice number field can be. I tried to find it in the
UBI
>> > > > > >specification.
>> > > > >
>> > > > > UBL does not constrain the length of fields.  Any element and any
>> > > > > attribute can have any length, according to the schema.  Trading
>> > > > > partners can layer on top of the schema constraints   
>> whatever business
>> > > > > constraints they wish to have, including length-related
constraints.
>> > > > >
>> > > > > In the UBL committee there is a long-identified task (as yet
>> > > > > unfulfilled) to identify some length-related value   
>> constraints to add
>> > > > > to a layer separate from the schema.  It was thought these would
be
>> > > > > built into the second-pass Schematron constraints as they   
>> are ideally
>> > > > > suited for such validation.
>> > > > >
>> > > > > If you check at the bottom of this page:
>> > > > >
>> > > > >
>> > > > http://lists.oasis-open.org/archives/ubl/200801/msg00008.html
>> > > > >
>> > > > > ... you will see reference to consulting specifications such as
>> > > > > UNTDED, which does have length-related constraints, to add to the
>> > > > > second pass layered on top of the non-length-restricted schema
>> > > > constraints.
>> > > > >
>> > > > > >I'm sure my company will have a limitation in our payment
system.
>> > > > > >However, I was just wondering if there was a standard that  
>>  the "world"
>> > > > > >is moving toward.
>> > > > >
>> > > > > I'm more the geek than the business expert, so I'll let the
business
>> > > > > experts answer that aspect of your post.  Though you may find the
>> > > > > UNTDED may help:
>> > > > >
>> > > > >    http://www.unece.org/cefact/standar/docs/tded.htm
>> > > > >
>> > > > > But from my geek perspective, what more can you say about   
>> limitations
>> > > > > in the payment system?  Having worked with XML and SGML for many
>> > > > > years, my understand of length-related value constraints on
>> > > > > information fields are based on archaic legacy systems.  These
>> > > > > systems were typically supported by programming languages with
>> > > > > inherent field limitations, and I recall my work in COBOL when
>> > > > > thinking of this.  Programming languages and data sets   
>> these days may
>> > > > > not need length-related constraints, so I would not launch into
your
>> > > > > development assuming that these are obligatory.
>> > > > >
>> > > > > If you can share your requirements in this area, I'm confident
many
>> > > > > people on this list would be interested to know how relevant such
>> > > > > legacy constraints are these days in modern systems implemented
with
>> > > > > modern languages.
>> > > > >
>> > > > > >We're implementing a new procure to pay process now.
>> > > > >
>> > > > > Wonderful!  I hope you find UBL suits your needs!
>> > > > >
>> > > > > . . . . . . . . . . . . . Ken
>> > > > >
>> > > > > --
>> > > > > World-wide corporate, govt. & user group XML, XSL and UBL
training
>> > > > > RSS feeds:     publicly-available developer resources and
training
>> > > > > G. Ken Holman
mailto:gkholman@CraneSoftwrights.com
>> > > > > Crane Softwrights Ltd.
>> > > > http://www.CraneSoftwrights.com/u/
>> > > > > Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999
(F:-0995)
>> > > > > Male Cancer Awareness Nov'07
>> > > > http://www.CraneSoftwrights.com/u/bc
>> > > > > Legal business disclaimers:
>> > > > http://www.CraneSoftwrights.com/legal
>> > > > >
>> > > > >
>> > > > >
>> > > >
---------------------------------------------------------------------
>> > > > > To unsubscribe, e-mail:
>> > > > ubl-dev-unsubscribe@lists.oasis-open.org
>> > > > > For additional commands, e-mail:
>> > > > ubl-dev-help@lists.oasis-open.org
>> > > > >
>> > > > >
>> > > > >
>> > > >
---------------------------------------------------------------------
>> > > > > To unsubscribe, e-mail:
>> > > > ubl-dev-unsubscribe@lists.oasis-open.org
>> > > > > For additional commands, e-mail:
>> > > > ubl-dev-help@lists.oasis-open.org
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Stephen D. Green
>> > > >
>> > > > Partner
>> > > > SystML, http://www.systml.co.uk
>> > > > Tel: +44 (0) 117 9541606
>> > > >
>> > > > http://www.biblegateway.com/passage/?search=matthew+22:37
>> > > > .. and voice
>> > >
>> > >
>> > > --
>> > > Stephen D. Green
>> > >
>> > > Partner
>> > > SystML, http://www.systml.co.uk
>> > > Tel: +44 (0) 117 9541606
>> > >
>> > > http://www.biblegateway.com/passage/?search=matthew+22:37 .. and
voice
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
>> > > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>> >
>>
>>
>> --
>> Stephen D. Green
>>
>> Partner
>> SystML, http://www.systml.co.uk
>> Tel: +44 (0) 117 9541606
>>
>> http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>




---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]