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

["Tobey, Thomas N." <Thomas.Tobey@lfg.com>]

Jon et al,
I see that the capability exists to restrict limits. Partner to partner.
Let's say a vendor is building an application which outputs invoices:
where do they go to find out how long they should allow their invoice
number to be? Certainly they could take a poll of their customers. Or,
through trial and error they could discover they made a mistake when
their customers begin convulsing on their invoices, due no doubt to
legacy systems. Why not go to standards-setting organizations not only
to get what is possible, but also to get best practices or pitfalls
associated with current state systems?

Shouldn't a standard that is published which allows you to do anything
be coupled with information addressing the current state and the
possible road to get to the ideal state? Now, I'm not saying that you
should demote yourselves to writing user manuals. But for key fields,
which drive the mechanics of the whole thing, at least some advice
should be given. So you don't have to write a whole new limitations
doctrine for all fields. But please let people know what is important to
consider.

Maybe it is just common sense to keep an invoice number small. I can
write up a list of reasons why a smaller invoice number is better.
Should something be published somewhere or left to common sense?
1. You are requesting a payment, don't make it hard, stupid.
2. Companies are still doing manual data entry of invoices. More data
means more data entry errors.
3. Identity fields are the "phone numbers" for the subject. Meaning:
each time someone calls someone else to refer to an invoice, the second
person has to type in the identity number.
4. Customer legacy systems still have limits on invoice numbers.
5. Paper checks are still printed, which may have space limitations for
customers.

Ugh, I just read a little bit of who I'm talking to. Jon, one of the
creators of XML? Several other illustrious bios. OK, I'm going to go
ahead and slick send on this email. I'm sorry if I sound provincial...

-TNT


-----Original Message-----
From: jon.bosak@sun.com [mailto:jon.bosak@sun.com] 
Sent: Wednesday, February 13, 2008 10:11 AM
To: ubl-dev@lists.oasis-open.org
Subject: Re: [ubl-dev] How big can the invoice number field be?

[fulton.wilcox@coltsnecksolutions.com:]

| Perhaps UBL "best practices" should define typical field lengths,
| but not build hard edits into UBL itself.

Or perhaps people could use the XSLT validation pass built into
UBL 2.0 for this purpose.  As we point out in Appendix E of the
UBL 2.0 Standard,

   The validation framework provided in the val directory can be
   used to implement code list changes, define variant code lists
   to fit specific trading partner agreements, associate different
   versions of the same code list with different parts of the same
   UBL document, and even perform fairly sophisticated business
   rule checking, simply by building additional logic into the
   XSLT file that drives the second validation phase -- and
   without changing the standard UBL 2.0 schemas. Schematron-based
   techniques for creating a custom XSLT file to take the place of
   defaultCodeList.xsl are explained in the UBL Code List Value
   Validation Methodology, the latest draft of which is available
   from the UBL TC web site. Using these techniques, the business
   analyst can offload a large proportion of input filtering from
   the backend business application to a simpler input processing
   area. And, of course, additional XSLT scripts can be added to
   extract logical subtrees of incoming UBL documents for
   allocation to different downstream processes and to perform
   even more sophisticated front-end processing.

   (http://docs.oasis-open.org/ubl/os-UBL-2.0/UBL-2.0.html#d0e9684)

The mechanism needed to impose field length restrictions and a
whole lot more is already built into the UBL 2.0 framework; all
you have to do is use it.

If people want to see a predefined set of such rules provided in
the next release (2.1, due out next year), that's easy, too -- if
they will step up to doing the work of defining the rules and
creating the requisite Schematron assertions.  There's no end to
the "best practices" we could build into the package this way; all
that's needed are people willing to invest the effort.  UBL is a
volunteer initiative, and, as Ken Holman said, we're always open
to participation.  I'm sure that the UBL TC would be glad to
create a team to work on this if people were interested enough to
join the TC and sign up for it.

Jon


---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org




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.**