Re: Physical Inventory in ERP-LX 8.3.04

We are still on 405 CD due to the high price for upgrading, and the legal
hassles we have previously had with SSA+Infor.

We use multi-step processes to get the job done, including modifications to
the paperwork, and also to the ticket software. We got help from UPI-Milt
in implementing some of this because sometimes management waited until a few
weeks before a physical to request something which the existing software
could not do, and I ran into unexpected hassles with rush project
modification testing.

A few months before physical, I run a query which counts ILI records which
have inventory on-hand, total by inventory type by warehouse and facility.
This shows how many tags we would need if:
1. We can assume inventory pretty accurate what items we have.
2. We do not process tags on items the computer thinks zero on hand.
This helps management see how many tags we need to have in stock, before
physical.

We use modified INV620 Physical Inventory Tag print software several ways.

INV620C-CL causes INV620-RPG to run twice, 2 different versions.
Version-1 uses ILIIMJ02 which joins ONLY IIM items which are NOT type 7
where IIM sequencing is class / item #
Version-2 uses ILIIMJ07 which joins ONLY IIM items which ARE type 7 where
IIM sequencing is class / description / extra description / item #
An OVRDBF tells INV620 which of the two versions to use.

We use our own custom forms.
There's space for "counted by whom" (initials)
We print info associated with the item# . description, extra, more.
Some items show parent customer . our factory layout is structured, so work
for major customers end up with their own locations.
Type-Class is printed on tags, because occasionally items are mis-coded.

INV620-RPG sets flags in initialization (indicator 99), for easy flipping.
Some years we do a complete physical.
Some years we only do particular types of inventory, such as finished goods,
and raw materials, skipping sub-assemblies.
The init flags say what the story is this year, and the program already
setup to deal with whatever combination of flags it is for this year
physical.

When we are not including type-2 in a physical:
We create YPH records for type-2 but do not print those tags.
The YPH records come with count value pre-recorded, and the status field
flagged as Y for posted, so they are ready to be dumped back into inventory
with no physical changes.

When it is time to key in physical, we can have the actual tag, and attached
to it is a manual form, with the actual counts, in excess of what BPCS form
designed to handle. Total of manual form is written on actual tag.

At conclusion of physical counting, there is a yellow carbon copy of tag,
still attached to the bins, to help with both identification of item, and
also what tag it was, if later discover that count could not possibly be
correct.

At conclusion of physical tag data entry, the auditor goes off with the tags
which got keyed in.

Before dumping tags, we have some extra reports to help identify potential
errors in the data, which maybe can be corrected at the last minute.
For example . a report showing variances, sorted by absolute value of
quantity variance, worst on top of report. This catches a problem with data
entry.
In the Tag data entry screen, you are supposed to key the count, then field
exit. The software allows someone to accidentally key the count left
justified, then get to next field without right justifying.
The vanilla report listing missing tags is not much help. We have our own.
We also have a report showing variances multiplied by cost, sorted by
absolute value of $ variance, worst on top of report. This catches other
kinds of problems, especially mis-identification of item, on hand written
tags, where the item was not in the computer inventory.

There are two reports:
UNPOSTED lists tags created, but never keyed against with whatever the
inventory was.

Before and after dumping tags into inventory balances, we make copies of
inventory balance file IWI into other libraries, so that later we can do
reports showing what changed.
Before dumping tags, which also erases tags, we make copy of IPH file, so
that later when questions come up, we can do reports based on what was in
the tags.

Later, if when we find, typically in middle of next month, some tag needs to
be corrected, we use a Z transaction (which we added) to take care of that.
We also have a special transaction for oops Z reversal.

At year end, in addition to EOM EOY Physical, we also have standard cost
replacement. There are a number of categories of items (such as
inter-division with other branches of our company using ERP other than BPCS,
and pricing associated with commodity projections), where we do not know new
cost until later into the year.

It is necessary to retroactively figure what the impact of those late
changes had on what the value of the physical inventory would have been, had
we known that info at the time.

Combination of Z adj, and late cost info, some of this number crunching has
to be done outside of BPCS.

We now do physical etc. over end-year holidays. There is a process people
are supposed to follow. Sometimes the process gets violated. I have some
reports for auditors to show how we know no violations this year, or if
there were, what impact it has on our accuracy.

In addition to reports showing value of inventory found by physical, we also
have reports showing value of inventory found, which we have not had
occasion to use in a year or two.

Al Mac (WOW) = Alister William Macintyre
via WOW WAY.com ISP
2012 April I had a serious PC melt down, from which I am still recovering
-----Original Message-----
From: bpcs-l-bounces@xxxxxxxxxxxx [mailto:bpcs-l-bounces@xxxxxxxxxxxx] On
Behalf Of Bunch, Wendy
Sent: Monday, September 24, 2012 9:13 AM
To: bpcs-l@xxxxxxxxxxxx
Subject: [BPCS-L] Physical Inventory in ERP-LX 8.3.04


Previously we had written a custom front end program for doing tag
entry/reports for Physical Inventory - that allowed us, among other
things, to have multiple tickets for a part in the same location. Last
step of the process combined the tickets so only had one part number per
location, then went to traditional BPCS Physical inventory - generated
tags. Ran a couple of custom programs that brought the inventory over
and booked/created tickets, ran other program that zeroed out any unused
traditional BPCS tags - ran some cross reference reports - (many tags
entered - to BPCS traditional tag#), then finished posting
inventory/reports through traditional BPCS programs.

Upgraded to 8.3.04, moved to new box. Tried to reduce "Custom" items.
Thought we could use plain regular BPCS physical inventory. Almost
could - but show stopper surprised me. Still can only have one tag per
part per location. Why do they not have some sort of front end on
traditional BPCS for multiple tags, that then combines down to the one
ticket location so can update the ILI file? We have several examples of
why we need more than one ticket for a part in a production location -
product may not be physically next to each other - same material may be
at several workstations - but is same production floor location. We
want to inventory it where it is - not move it all around and then move
it back. We also do not want to add finite locations to the production
floor - general areas, yes, but not finite like in our stores area...

How do all of you get around this? Does anyone use just the plain BPCS
version or has everyone had to modify or use custom to some degree? We
are going to bring back our old custom front end program for now.

Wendy Bunch
Cost Accountant
Wabash Technologies