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

["Stephen Green" <stephengreenubl@gmail.com>]

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