[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?
Hi David Not me that's asking. I guess Thomas would prefer it if all this was packaged up and maybe distilled down into just a few links. The question asked was pretty simple. It just looks a tad like the UBL solution is even more complex than the EDI one. I don't think it needed to be like this, shame it has gotten a bit like this though. In short I would say Thomas and others would need a rule like 'UBL doesn't provide datatype length restrictions (for database storage, etc) - use EDI ones' and maybe some helpful ready-made artefacts to that end to aid interoperability and conformance across implementations to make it real. -- 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 Quoting "David RR Webber \(XML\)" <david@drrw.info>: > Stephen, > > I that regard - ping Pim @ OASIS - he is working on some XML to > manage CPPA / XSD / CAM and MoU in a package that can then drive > partner agreement SW - see also draft postings to CPPA documents area. > > 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:06 pm >> To: "David RR Webber (XML)" <david@drrw.info> >> Cc: "G. Ken Holman" <gkholman@cranesoftwrights.com>, >> ubl-dev@lists.oasis-open.org, fulton.wilcox@coltsnecksolutions.com >> >> 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 >> >> --------------------------------------------------------------------- >> 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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]