Re: Roll-over of BPCS Shop Order #

We are on 405 CD and were formerly on a BPCS version on S/36.

We have experienced the phenomena of which you speak.



Like you, BPCS does a good job for our people, and our leadership is not
motivated to advance to a more modern version. We also have some solutions
to this and related issues, which might not work for everyone.



When shop orders hit their maximum value of 999,999, they automatically go
back to zero, and resume counting.

This same phenomena is true for purchase orders, customer orders, invoice
#s, etc.

There are several concerns, and data management issues associated with this.



There are values in the system parameters (ZPA file) which can be updated
via SYS menu, to keep track of the last # issued. When BPCS creates a new
shop order #, it checks what is out there, and does not issue a duplicate
order, but if there is prior history on that order, when someone does
inquiry into the order, BPCS accesses both the history dated before the
order was re-launched, and anything since, which makes it practically
impossible to figure out what is going on.



If we were to do a modification to deal with this, I would find where BPCS
stores the date the shop order was created, then exclude any activity,
allegedly on that shop order, dated before that date.



We did not go that route, because each year, at most we have 99,999 unique
shop orders.



There is data that people do not need to see on a daily basis, so we have an
archiving system, to keep data needed for auditors, and annual reports, but
not cluttering up access for the bulk of users. Historically, I was only
keeping archives for as long as our auditors (companies we contract with to
do audits) needed access (2 years prior to current year), but at the end of
last year, accounting informed me that we needed to keep archives for 5
years. I also have a concern about IRS audits. One year I got permission
to delete the oldest year from archives, to solve a disk space problem, but
I had not actually done so yet, when along came an IRS audit which needed
access to that oldest year. We have since got more disk space.



There is some legislation in the works which may mandate government audits,
other than by the IRS, which can require longer archives for some types of
data. My business (non IT) colleagues seem unconcerned about this topic.



We have done some purging, and have encountered some gotchas there.



During end-fiscal-month, the oldest inventory history ITH records get
removed, but the process accesses item master file IIM to update a count of
records per item, to facilitate INV300 chaining backwards from oldest date,
and for other reasons. We managed to delete some ancient items no longer
needed, from IIM, only to discover that means those items will NEVER get
purged from ITH under normal BPCS processing.



3rd party outfits have add-on solutions for this, but they might not support
older versions of BPCS.



There are BPCS files accessed using a sequence # for related entries, such
as customer orders (ECL detail). We can have hundreds of order lines on
blanket orders, where we are done with those lines. You better not remove
those lines without resequencing the sequence#, and all the files which
point at them. This is because some BPCS programs look at # 1 # 2 # 3 etc.
sequence # then if they hit # 4 and it aint there, because we deleted that
line, the program does not read the next record, past the deletions. Also,
there are other files, all over the place, which reference some order line
by its sequence #.



Does your company consider ZERO to be a valid number to use, especially when
zero suppress makes it invisible on most reports and inquiries?



If any data is manual entry, like labor tickets, then the less keying people
have to do, the more productive the operation. We modified some input
screens, so rarely need to enter data towards the bottom, and some alpha
values accept code #s, so having a numeric key pad means faster input. We
altered forms, so the arrangement of data to key in, matches the input
screen layout.



We now do physical inventory at end fiscal year, which includes two kinds of
WIP (work in process). There are the sub-assemblies (item type 2) with
discrete item #s. There is also production which might have step 1 2 3 4 5,
and at physical inventory time, there can be a lot of work sitting at step
3, between discrete item #s. Part of our process to deal with this, is to
move data related to shop orders, which we want to keep, into archives, and
then wipe out current data. We do an analysis of the past year history, and
on that basis, reset what shop order # we shall start with for the new year.
Dummy shop orders are created for the WIP which is between discrete items,
in which those orders reflect what inventory has been issued so far.



Al Mac = Alister William Macintyre

-----Original Message-----
From: bpcs-l-bounces@xxxxxxxxxxxx [mailto:bpcs-l-bounces@xxxxxxxxxxxx] On
Behalf Of Kelly, John (Limerick)
Sent: Thursday, September 19, 2013 1:50 PM
To: bpcs-l@xxxxxxxxxxxx
Subject: [BPCS-L] Roll-over of BPCS Shop Order #



Hi BPCS-L members,



The company I work for are running BPCS 3.6. Pretty old right! It has been
heavily customized over the years with the result that it continues to
support the business here in our facility.



By the very nature of its age we are on the verge of seeing our Shop Order
number hit its maximum possible value of 999,999. The relevant field is six
numeric in length.



With the roll-over date likely to occur within the next couple of weeks we
do not have the scope to implement an update to increase the Shop Order
number field size.



My business (i.e. non IT) colleagues do not have a major concern about this
event, as the Lot/Trace Code is the unique ID of choice for our product
range as opposed to the Shop Order #. From an IT perspective though we do
have a number of risks associated with the roll-over, as we will start
generating Shop Order numbers we have already used in the past once the
roll-over happens. We will see duplicate Shop Order numbers in our Shop
Order historical files which if referenced by program could cause problems
if the incorrect version is selected for processing.



I would like to ask the BPCS_L group have you experienced this event in the
past and if so can you provide any information on how you worked through it,
lessons learned etc.





Kind regards,

John.







________________________________

The information contained in this e-mail message and any attachments may
contain proprietary and confidential information and is intended only for
the individual or entity to whom it is addressed. Any use, interception,
dissemination, distribution, publication, copying or disclosure by any other
person is strictly prohibited. If you are not the intended recipient, you
should delete this message and kindly notify the sender via reply e-mail and
confirm that you will destroy or delete all copies of the email message and
any attachments from your system.