[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?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]