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

["David RR Webber \(XML\)" <david@drrw.info>]

Andrew and Tom,

This introduces a concept that XSD does not support - contextual validation.

What you really need is a template that says:

if (trading_partner="XYZ") then - apply these rules.

Amazingly CAM templates support these notions and allow you to build reference templates to describe the usage patterns that you need.

So as Stephen was noting - creating UBL-for-EDIFACT - template that applies formatting rules consistent with EDI POs et al.

Here's some samples from the current Emergency Management hospital facilities reporting so you can see just what CAM template can offer in terms of building the implementation model, the documentation and end user reporting.

This could easily be adapted to UBL - to show EDIFACT formatting compatiblity rules - the documentation and a sample UN form output too...

Cheers, DW

> You can view these directly here:
> 
> XML sample -
> 
> http://www.drrw.net/CAM/samples/EDXL/EDXL-sample-small-hospital.xml
> 
> CAM template -
> 
> http://www.drrw.net/CAM/samples/EDXL/EDXL-subset-template.cam
> 
> Rules documentation -
> 
> http://www.drrw.net/CAM/samples/EDXL/content-usage-report.html
> 
> XSLT -
> 
> http://www.drrw.net/CAM/samples/EDXL/EDXL-report.xsl
> 
> Final resulting report -
> 
> http://www.drrw.net/CAM/samples/EDXL/results.html
>

> -------- Original Message --------
> Subject: RE: [ubl-dev] How big can the invoice number field be?
> From: "Andrew Schoka" <AMSchoka@comcast.net>
> Date: Wed, February 13, 2008 10:46 am
> To: "'Stephen Green'" <stephengreenubl@gmail.com>,  "'Tobey,  Thomas
> N.'" <Thomas.Tobey@lfg.com>
> Cc: <ubl-dev@lists.oasis-open.org>
> 
> Tom, etal,
> Along with Stephen's identifying UUID, I would also like to identify another
> element with seems to be gaining visibility and utility the transport and
> procurement business communities. That is the Consignment Identifier or
> Unique Consignment Reference (UCR). Tag Number 1202. See the UN Trade Data
> Element Directory (UNTDED) http://www.unece.org/trade/untdid/UNTDED2005.pdf)
> which defines it as "Unique reference identifying a particular consignment
> of goods." This element has been promoted by the World Customs Organization
> (WCO) as an element that may be useful in tracking goods all the way up and
> down the supply chain and therefore may be strongly coupled to an invoice
> number. The length of the UCR is specified as AN..35.
> 
> Regards,
> Andy Schoka
> 
> 
> 
> -----Original Message-----
> From: Stephen Green [mailto:stephengreenubl@gmail.com] 
> Sent: Tuesday, February 12, 2008 12:49 AM
> To: Tobey, Thomas N.
> Cc: ubl-dev@lists.oasis-open.org
> Subject: Re: [ubl-dev] How big can the invoice number field be?
> 
> Another field in UBL which might be used along with Invoice ID
> is the UUID, the universally unique ID. This would have unlimited
> length in case folk use a uri as part of it but it would probably
> best be limited to 256 characters, again so it can be stored in
> the lowest common denominator of databases (amazing how
> long people keep using the same old database when it stores
> finance data). Maybe the real limit for the Invoice ID is 256 char
> in practice for many systems but probably best to keep to the
> 35 characters Fulton mentions. Even UBL seeks to preserve
> 'backwards' compatibility with EDI (through common adherence
> to the UN/CEFACT CCTS standard). I'm not sure why it doesn't
> do as CEFACT seems to be doing and limit string and number
> lengths at its datatypes level.
> 
> On 11/02/2008, Tobey, Thomas N. <Thomas.Tobey@lfg.com> wrote:
> > Greetings! 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.
> >
> > 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. We're implementing a new procure to pay process now.
> >
> >
> >
> > Any help would be greatly appreciated!
> >
> > Thanks,
> >
> > -Tom T.
> >
> >
> >
> >
> >
> > =================================
> > Thomas N. Tobey
> > Systems Analyst
> > Lincoln Financial Group
> > 1300 S. Clinton St.
> > Fort Wayne, IN 46805
> > 260-455-3704
> > Thomas.Tobey@LFG.com
> >
> >
> >
> >
> >
> >
> >
> > Notice of Confidentiality: **This E-mail and any of its attachments may
> contain
> > Lincoln National Corporation proprietary information, which is privileged,
> confidential,
> > or subject to copyright belonging to the Lincoln National Corporation
> family of
> > companies. This E-mail is intended solely for the use of the individual or
> entity to
> > which it is addressed. If you are not the intended recipient of this
> E-mail, you are
> > hereby notified that any dissemination, distribution, copying, or action
> taken in
> > relation to the contents of and attachments to this E-mail is strictly
> prohibited
> > and may be unlawful. If you have received this E-mail in error, please
> notify the
> > sender immediately and permanently delete the original and any copy of
> this E-mail
> > and any printout. Thank You.**
> >
> 
> 
> -- 
> 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
> 
> No virus found in this incoming message.
> Checked by AVG Free Edition. 
> Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: 2/11/2008
> 8:16 AM
>  
> 
> No virus found in this outgoing message.
> Checked by AVG Free Edition. 
> Version: 7.5.516 / Virus Database: 269.20.4/1276 - Release Date: 2/13/2008
> 9:41 AM
>  
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org