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

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2008-02-14 10:17 -0500, Tobey, Thomas N. wrote:
>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?

Shouldn't vendors build the same layers of constraints for the 
flexibility of as many customers as possible?

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

But some customers may change their systems requiring such things to 
be modified.  No one answer will be "correct" for everyone or for all time.

>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?

It is not up to standards organizations to guess the limitations 
needed by users, but to enable users to impose their own limitations.

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

That will be different in Italy than it is in Canada.  The system 
we've developed allow UBL to be used in both so that each can impose 
their own constraints on top of what is there.

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

All of the above are issues of import to communities of users.  The 
role of the standardization organization is to empower them to decide 
for themselves what they need.  The UBL TC can't decide what those 
limitations are for everyone, because there is no single community of 
users ... so the system is designed to be useful for everyone.

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

Not at all ... this query is not uncommon ... standards organizations 
are enablers, communities of users deploy standards to meet their 
requirements.  I have no problems helping people understand how the 
committee is enabling them to do their work and meet their needs.

Vendors should consider what we've done and consider how their own 
users' requirements may differ now, or may change over time.  I think 
what the UBL TC has done makes for a good model.

The committee is creating documentation and guidelines ... anyone 
willing to help will help the process for all.  There is only so much 
time in a day for volunteer work.

I hope this is considered helpful, Tobey.

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