Re: Dumb Numbering Question

Dear Al,

There is always a chance of gotchas associated with reusing
document numbers.  That's true whether you wait for the automatic
roll-over from 999,999 to 1 or you reset to 1 after 5,000. If a
record for that number already exists in your production files
there will most likely be gotchas.

One of the easiest ways to address this potential issue is to remove
the older data from your production files.  Our Locksmith (tm) for
BPCS software does just that.  It archives your older data out of your
production database so document numbers can be re-used, while
still making that archived information available to your users
through the standard BPCS Inquire programs.

Additionally, removing this older data from you production files
can increase you system performance by up to 40%. A free demo
of the software is available. More information:
http://www.unbeatenpathintl.com/locksmith_bpcs.htm.

Peace to you,

Dean Olson
Unbeaten Path International
North America: (888) 874-8008
International: (262) 681-3151
contactus@xxxxxxxxxx
www.upisox.com





----- Original Message ----- 
From: "Alister Wm Macintyre" <macwheel99@xxxxxxxxxxx>
To: "BPCS_L discussion" <bpcs-l@xxxxxxxxxxxx>
Sent: Wednesday, February 09, 2005 9:56 AM
Subject: [BPCS-L] Dumb Numbering Question


> BPCS assigns sequentially various order #s ... customer, purchase, shop,
> RMA ... invoices, checks ... they get to 999,999 then roll over to 1 again
>
> There are also places where we can reset the last # so that we can start
> over at 1 again without waiting on it getting to 999,999 ... a reason why
> we might want to do this is in those areas where many co-workers are
keying
> in the order # hundreds of times a day ... if they can be keying a 4 digit
> # rather than a 6 digit #, there is an aggregate enhancement for their
> productivity, and when there is a risk of el typo ... less digits means
> less risk, per unit transaction.
>
> Also, we use query/400 a lot ... some people may have created a query
where
> they see ... this or that # in BPCS can go up to xxx,xxx but we are only
> using up to x,xxx so let's chop off the high order digits so we can cram
> more stuff sideways on this report ... then many people using the report
> not realizing this has been done, then the company business gets to the
> point that 9,999 becomes 10,xxx and now we have a report that is losing
the
> high order digit, and who knows it?
>
> Now my question is if there is any place in BPCS where there is risk of
> collision between old #s and new #s ... let's suppose the last order #
> issued is 1233 and we have a real old order sitting out there by # 1234
...
> then we want the next order # to be released to be 1235 assuming not have
> one like that, as opposed to it trying to create a duplicate 1234 and
> perhaps bombing.  Is there any type of order invoice check etc. for which
> this is a risk?  We are 405 CD.
>
> I already know about a couple gotchas with shop orders and customer
orders.
>
> When we look at the detail on a shop order, such as with SFC300, some of
> that detail is coming from inventory history or labor history.  Suppose we
> had a shop order 6 months ago for 123 then we restarted the #s again and
we
> get to 123 again ... not a duplicate order # ... but 6 months ago we had
> another shop order 123 for a different item # different facility nothing
> similar, but when we look at the latest order 123 data it has the earlier
> 123 data cluttered in ... thus, it is smart not to be reusing shop orders
> within the time frame that we keep labor and inventory history on line.
>
> When customer orders #s are assigned, they take the last # issued, add
one,
> check to see if that # in use, if not assign it as next order, if that
> taken, then add one and try again ... this loop only goes so far, after
> trying like 1,000 times, it gives up and bombs ... thus it would be
prudent
> not to be restarting this # system such that we going to run into a batch
> of old order #s where many consecutive #s used up.
>
> Are there any other gotchas associated with restarting #s before they get
> to the natural 999,999 roll-over point?
>
> -
> Al Macintyre  http://www.ryze.com/go/Al9Mac
> Find BPCS Documentation Suppliers
> http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
>
> -- 
> This is the SSA's BPCS ERP System (BPCS-L) mailing list
> To post a message email: BPCS-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
> or email: BPCS-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/bpcs-l.
>
> Delivered-To: dolson2@xxxxxxxxxx
>
>
>