RE: Re: Dumb Numbering Question

Hi Wendy,

        Not sure what release you are on, nor do I have all the set up
information on the fundamentals of how this works. On 6. releases In
ACR100D2 you can make the packing group number = the Invoice number. You
will also need to be sure that you are not creating consolidated invoices
for these customers.

Good Luck 
Bill  

-----Original Message-----
From: Bunch, Wendy [mailto:wbunch@xxxxxxxxxxxxxx] 
Sent: Thursday, February 10, 2005 12:16 PM
To: bpcs-l@xxxxxxxxxxxx
Subject: [BPCS-L] Re: Dumb Numbering Question

Ok, I have a question as well.
Invoice numbers -- is it possible to use the BOL/Packlist number?  We have
been on BPCS since 1999.  Of course all that set it up are mostly gone by
now.  Currently have multiple Prefix's we use for different
Divisions/facilities, types, etc.  Numbering is set up in ACR160 with the
document sequences.  Most of our customers pay from BOL# sent from the ASN
and don't even receive a real invoice anymore.  One of the ladies thought
there had been a choice to use the BOL# -- but we can't find it.  Any ideas?

Wendy Bunch
Cost Accountant
Wabash Technologies
1375 Swan Street
PO Box 829
Huntington, IN  46750-0829
Direct (260) 355-4204
Main  (260) 355-4100
Fax    (260) 355-4265
wbunch@xxxxxxxxxxxxxx



-----Original Message-----
From: bpcs-l-bounces+wbunch=wabashtech.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+wbunch=wabashtech.com@xxxxxxxxxxxx]On Behalf Of
bpcs-l-request@xxxxxxxxxxxx
Sent: Thursday, February 10, 2005 1:05 PM
To: bpcs-l@xxxxxxxxxxxx
Subject: BPCS-L Digest, Vol 3, Issue 24


Send BPCS-L mailing list submissions to
        bpcs-l@xxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.midrange.com/mailman/listinfo/bpcs-l
or, via email, send a message with subject or body 'help' to
        bpcs-l-request@xxxxxxxxxxxx

You can reach the person managing the list at
        bpcs-l-owner@xxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific than
"Re: Contents of BPCS-L digest..."


Today's Topics:

   1. RE: Dumb Numbering Question (Steve Segerstrom)
   2. Re: Dumb Numbering Question (Clare Holtham)


----------------------------------------------------------------------

message: 1
date: Wed, 9 Feb 2005 13:26:06 -0600
from: "Steve Segerstrom" <SSegerstrom@xxxxxxxxxxxxxx>
subject: RE: [BPCS-L] Dumb Numbering Question

we are at version 6.0.04 heavily modified. We would modify the last number
used in the parameters generation in sys (I think that it was new for 6.04).

We do 300,000 orders a year - for incoming orders. We hit the wall awhile
ago.

I took that loop out you spoke of (you know, the 1,000 times) and put in
rollover logic (to set the order to 1; not 0) and did my own check (there
was none) for an order existing. Works great; no issues.

-----Original Message-----
From: bpcs-l-bounces+ssegerstrom=intermatic.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+ssegerstrom=intermatic.com@xxxxxxxxxxxx]On Behalf Of
Alister Wm Macintyre
Sent: Wednesday, February 09, 2005 9:57 AM
To: BPCS_L discussion
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: SSegerstrom@xxxxxxxxxxxxxx



------------------------------

message: 2
date: Thu, 10 Feb 2005 07:02:49 -0000
from: "Clare Holtham" <Clare.Holtham@xxxxxxxxxxxxxx>
subject: Re: [BPCS-L] Dumb Numbering Question

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
>




------------------------------

-- 
This is the SSA's BPCS ERP System (BPCS-L) digest 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.



End of BPCS-L Digest, Vol 3, Issue 24
*************************************
This is an e-mail from Wabash Technologies, Incorporated.  It is
confidential to the ordinary user of the above e-mail address.  It may
contain copyright and/or legally privileged information.  No other person
may read, print, store, copy, forward, or act in reliance on it or its
attachments.  If you received this in error, please e-mail to
humanresources@xxxxxxxxxxxxxx


-- 
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: bill.moy@xxxxxxxxxxxxxxxxxxxxxx