Re: Dumb Numbering Question -- BPCS-L

Hi Al,

This is why some people buy the Archiving!

cheers,

Clare

Clare Holtham
Director, Small Blue Ltd - Archiving for BPCS
Web: www.smallblue.co.uk
IBM Certified iSeries Systems Professional
Email: Clare.Holtham@xxxxxxxxxxxxxxx

----- Original Message ----- 
From: "Alister Wm Macintyre" <macwheel99@xxxxxxxxxxx>
To: "BPCS_L discussion" <bpcs-l@xxxxxxxxxxxx>
Sent: Wednesday, February 09, 2005 3:56 PM
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: Clare.Holtham@xxxxxxxxxxxxxx
>