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

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

Thank you all for your wonderful responses!
For some background, we are using the Ariba suite of applications, which
has already been architected for the most part to be length agnostic.
So, yes it does come down to limitations on the sending or receiving
end. The data does eventually get stored or used somewhere. In an
electronic payment fashion there are probably fewer limitations. Most
organizations still print checks for at least some of their spend. I
checked with our Account Payable for experience on the largest invoice
number (or alphanumeric identifier) we've ever seen. LFG, which was
already a Fortune 500, recently merged with a company of the same size
so I checked with two places. Both came back with 15. LFG does not do as
much international business, so I'm not sure what a company like GE
would see. I could envision companies using prefixes, etc. in the
identifier to make identification and routing easier. So a longer length
is not necessarily absurd, even though I know that concatenating
meaningful information inside of an identifier is not a best practice in
modern application programming.
As a large financial company which uses mainframe programming for most
of the heavy lifting, LFG is slower to change and does still utilize
legacy applications for many things. These systems like field limits for
some reason ;-)
We use SunTrust CDS to cut our checks. One limitation we'd have is
answering the question "How much space do we want to reserve on a
printed check for the invoice number?" If you have an aggregated
payment, you may have 80+ invoice payments going out on one check. Add
to that invoice date, invoice amount, and maybe a description, then you
are running into a real world scenario where you would want to choose a
definite field limit. Couldn't it just be dynamic? Well, yes if you're
willing to replace your legacy systems.
It is unlikely that we would send a notice to every supplier we have
telling them that they can not send us an invoice number with a length
larger than x. My question was to see if there was a general understood
notion of how long the number should be. Or possibly, how big of a
number could LFG realistically get and properly prepare for (99.999% of
the time)? It doesn't seem like there is a published "best practice." So
far, I'm agreeing with what I'm seeing in the notes that it should only
be a suggestion for the purposes of UBL, or worked out specifically
between two companies who are architecting a solution in the... (CAM?).
Looks like I have some acronyms to brush up on! This is great!
Thanks again!
-Tom Tobey


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