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