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

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

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