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

[Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>]

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