Re: Deleting an Inventory Location

Warning, some of these mass delete programs need to have no one on BPCS
while they are running. Ditto backup.
So you need to know:
* How to keep people off the system while they are running;
* How to check if they are done, without getting on BPCS;
* Which of these tasks can run Ok with other people on the system, and
which not;
* About how long to expect they will run;
* How you know if they ran correctly.

I used to go to main console, shut down OS/400, the start up only selected
sub-systems, such as JOBQ & printer. No one could get onto BPCS except via
main console, until I was done.

Warning, do not do any deletions of zeroed inventory locations in an end
fiscal month when you are also doing a physical inventory, unless you have a
very good understanding of what is going on in all steps.

Before running INV973, use DSPFD with *MBRLIST, to get # records & #
deleted, in ILI and IWI. Compare vs. same statistics after completion.
SYS120 (another dedicated task), run later, will get rid of those deleted
records. If you have not gone thru this process in a while, it should take
several hours, but if you have been doing it as part of end fiscal
regularly, it may be done in 1/2 hour.

They can be launched from Menu SSAZ01 reorganizations.
SYS / 23 / 23 = INV973

We quit running INV970 because INV970 is on-line, cannot put on JOBQ, while
INV973 does 100% of what INV970 does, and more besides, and can go on JOBQ.
I was doing a lot of end fiscal work by VPN, which had a bad habit of
blanking out on me, and some on-line tasks are a royal pain to repair, if
they go down in the middle.

In other threads here, we might also discuss what can be done to address
your other challenges, such as improving identification of items to reduce
errors. We used to have a final operation, which was not for production
reporting, or inspection, or shipping. It was for shop order reporting
clean up before the shop order could be purged. Our problems had included:
labor tickets going into the computer in some sequence other than how the
work had been done; people causing operations to be closed, then additional
transactions coming along; how we handled scrap repair. Our labor tickets
had carbon copy. One copy remained with item, to identify it. One copy
went to data entry. We modified the data entry screen so the fields in same
sequence as stuff coming off the labor ticket, to lower volume of keystrokes
needed.

If I remember correctly, PR = Production Receipt, or inventory created
thanks to labor reporting via JIT600.
The PR transaction knows that the completed item goes into location BAN,
because it is told to do that by the FMA file, which gets its info from MBM
Bill of Materials file, at time of shop order creation. Before anything is
done with the shop order, shop order maintenance could correct the shop
order, to change any place where it calls for the use of some unwanted
location. But that is tedious. I also do not recommend modifying the shop
order release software, which is rather complicated . I had to modify that
at my former day job.

Rather, I think you ought to take a look at the MBM file. Does it call for
you to be involved in the non-valid locations? Where does BPCS say to use
them? In an old old version of BPCS, it went after locations in
alphabetical sequence.

There's also the FSO shop order summary file, making the item to satisfy
demand by MRP, which gets its info from customer order.

We had a production warehouse, a raw materials warehouse, and a shipping
warehouse.
BPCS had some bugs, where we had to run some correcting programs against the
automatically generated records, so MRP and other programs would work right.
Unfortunately many details have fallen out of my brain.

Depending on where we may have things messed up & not yet solved, such as
bugs in BPCS, bugs in our human operations, past errors not identified &
corrected, there are some standard BPCS programs that generate more
troubles.

A shop order purge can cause us to have negative allocations, which in turn
cause indigestion for other programs.
Thus some reorganization is wise both before and after, to clean up unwanted
discrepancies.

Some clerk get behind in their duties, so on a Monday, they key in stuff
which should have been done last week, so they give it Friday's date. If
the intervening weekend was an end-of-month, BPCS re-writes opening balance,
and other fields as if those transactions were in fact entered before
end-month was done.

During our end month and end week process, we had a number of reorganization
processes to get rid of unwanted obsolete records. Many of them were
already available for us on SSAZ menus. You need to check them out
carefully as some were flawed or useless in our version. (405 CD)

Checking what notes from my former day job, which I have not yet deleted, I
find the following sequence:
Menu SYSZ01
System Reorganizations
SYS120C
F6 to continue
It gets at a list of BPCS files
F18 (upper shift F6)
to select all for reorganization
flagging them all with 11
F6 twice
this puts BPCSFILES
on JOBQ which will check
all the files and reorg any
which need it

This means removal of
coded for deletion
resequence by primary
alternate indexing

These next options are
usually run Sunday after
the system has kicked off
people who never sign off

They are Safe with Bypass
See E DIST
They are all Interactive

SFC990C
ORD990C
SYS990C
INV971C
INV972C
ACR970C
ACR972C
MRP990C

The above list check and fix
any cases of files out of
synchronization with
each other


Be careful when doing deletions to use the BPCS provided software, because
there can be pointers from other files & you want all the pointers to be
re-sequenced properly. Some 3rd party outfits sell add-on software to
handle the clean ups needed which did not come with BPCS.

Here is from some of my day job notes, to peers, on challenges to be
avoided:
* Corrupted File Access = BPCS reads through some files, based on line
#, or sequence # of records within that file. BPCS programs start at 1 then
look for 2 then for 3, etc. If in our purging, we have killed records 2
thru 8, BPCS does not skip over that gap and find record 9, it finds that
record 2 does not exist, then stops there. Thus for BPCS access to work
correctly, the sequence #s of files must be continuous, without gaps.
* Purge Inventory History = BPCS comes with a program, run during EOM.
It eliminates oldest records, as per system parameters (currently we keep
this info for two years. If that time frame is ever to change, we will need
to change Archiving rules.) This software has a bug. It is reading through
items which have not been coded for deletion, then deleting the oldest
history on those items, then rewriting the sequence # system for the records
which are being kept. If an item has been coded for deletion, its history
never goes away, then when that item is restarted with a different meaning,
it starts its life with the unrelated history. We need a program to
identify and delete any inventory history records on items which have been
deleted, or have been coded for deletion.


The time to delete master locations for inventory, is at some point in
end-month processing, before people get back on the system, to do any normal
month activity. We habitually did mass deletes of empty inventory locations
(ILI file) and warehouses (IWI file). There was also a lot # file which we
did not use. We did this, once what was there had gone to all zeros, after
end-month INV900 program which did humongous activities.

We knew that any time some BPCS activity needed an inventory location in the
future, that it would be recreated. If later, someone griped that a
location was in error, we could do a query on ITH to find out what order
activity brought it back into existence, then go tackle that for
corrections.

Exception warning. For inventory reports to be accurate, they need to have
both the item in Item master (IIM file) and there's another file, I forget
its name, which has info on the item by facility.

During physical inventory, we would find items not in BPCS. Perhaps a
zeroed quantity item got removed, deleted. Perhaps the item # is wrong. We
don't know, but the expedient was for some one to add the item to the item
master, in which then the physical tag could be entered, and all the
physical inventory reports would appear to work Ok, since many are operating
off the O Tag transaction. But, for BPCS to add the correct records to the
item-facility file, there has to be a transaction other than physical
inventory activity.

Some BPCS inventory lists ignore the possibility of mismatching records.
Item is in item master, but not some other file, which is what the program
starts with, or it looks for record in file where record missing, and does
not show clarity on the report that there is a null.

The people, doing the item addition for physical, also have to know to
manually populate the item-facility file.

End month operations and clean-ups also include good places to have a
backup.

Not only do the locations need to have zero quantity on-hand, zero issues,
zero receipts, zero adj etc. they also have to have zero allocations, zero
requirements in any orders, zero nettable, zero non-nettable. You can get
to that reality, after end month has poured on-hand into opening balance,
and zeroed the rest of the formula.

To get the most benefit out of the end fiscal mass deletion of zeroed item
locations, there should be an effort shortly before end fiscal to zero out
unwanted locations, by adjusting inventory to the desired locations. To
help facilitate this effort, it would be useful to print what inventory
exists in the unwanted locations. I believe one of the INV26 series
programs could help with this.

It might also be practical to do a software modification to generate
transactions to do the moves for you.
Sequence #s are critical here, so it is best to modify an existing program,
which has the relevant details.

Deletion of most things in BPCS is at least a 2 part process.
Some command codes something for deletion, which gets a Z into the 1st or
second character of the record-id, then a later step is needed to remove all
the records coded that way.

If you have the BPCS source code, some programs are practical to modify, and
some are not.
If you can trace where the unwanted locations are being triggered from, it
may be practical to do a modification to divert movement of inventory
involving unwanted locations, to instead substitute relevant locations.

As you identify unwanted locations, which were unable to be removed by the
end-fiscal reorganization process, You can use some query to identify what
is there, and do history on what transactions are populating those
locations.

Once you get to the point that one of your no longer valid locations has no
more inventory there, you should try to delete the location. BPCS will
probably not let you, without giving a good error message.
The reality will be that the location is needed by some customer order, or
purchase order, or other darn thing.
So you will probably want some helpful queries:
* For the specified location, please list all records in specified
files, which reference this bad location.
So then you see what else needs to be cleaned up before you totally can
eliminate some location.
Don't forget your aechives. The IRS can ask to see your records from
several years ago, so you need to have some kinds of archives for stuff that
needs to be purged, deleted.

Be careful if transferring inventory from one facility to another which has
a different cost basis.
The "T" transaction drags all cost buckets across to the destination.
We had production facilities, where we made the end products to be shipped
to the customers, where the cost was based on production activities.
We had another facility where we purchased items, for resale. Their cost
basis was purchased items.
We had some items, where it could be more profitable us to make, and at
other times more profitable to buy, depending on the size of the customer
order quantity, or the lead time desired by customer.
So same items in different cost basis facilities.
If someone transferred one of those items across facilities, you would get
doubled up costs, both purchased and manufactured.
Instead of using T transaction, we had to use two A-equivalents, to downsize
in the from facility, and up quantity in the destination, so as to avoid
messing up the costs.
We had lots of reason codes, but found they did not show up on all reports,
so we also had copies of existing transactions for specialized purposes, so
easier to track why some things done.

I am now retired, but still have some BPCS documentation from version 4.0.5
CD with a bunch of upgrades.
The last few years of my day job was part time telecommuting. The day job
not want BPCS doc back from me cause they moved to a different ERP.

BPCS documentation is available from multiple locations, provided your
company is willing to purchase the manuals.

Even with the hard copy manuals discarded, there is on-line documentation
which can be printed out.
Look for a file called BPCSDOC.
Look for a PDM member in there called SSALOG00.
Using PDM to scroll thru BPCSDOC to see all the names of the members in
there .
Those with RUN inside their name, are manuals for each of the 3 letter
prefix areas.
There is a menu accessed via short cut DOC. You need to muck with BPCS
security for a person to be able to access it.

When you find whichever SSA RUN ## is for inventory, you can search for
particular strings.
INV zero something, and INV nine something, are dangerous programs
associated with end fiscal and file restructuring. This doc will tell you
what they are all supposed to do.

It can be useful to print all the help screens for heavily used programs,
and map out the available functions, since navigating the options of some
programs can be very difficult, using official documentation, or viewing
help screens available to standard options.

I am thoroughly disgusted with the number of times co-workers managers and
auditors have thrown away manuals for our company software products,
throughout my career.


Alister Wm Macintyre (Al Mac)
I am in Evansville Indiana.