RE: physical inventory SKIP WIP

Hi Al,

The process wont be as complicated as you mentionned below. 

INV650 reads the records in IPH, and creates an ITH record for the
difference between IPH.phqty and ILI.lpob, and writes to ILI.lopb the new
quantity.  INV650 does not change ILI.lopb where no matching IPH record
could not be found. It will create an ITH record, but with a zero quantity:
meaning no quantity variance. This feature enables you to delete all the
undesired IPH records, just before running INV650, and the on hand quantity
in matching ILI records of these deleted IPH items (key = warehouse,
location, item) will remain unchanged: bingo! The ILI.lopb wont be zeroed
because no tags were found in IPH. I think this is what you are looking for.


A simple test will be to create tags (INV620D), that will populate IPH.
Delete all the records in IPH to the exception of one single record for your
test. Enter a count quantity in that single record either through BPCS
INV600D1, or write directly in the file with FEU, SQL,  or any other
database utility  you might have. If you do write directly into IPH, also
write the value "Y" in IPH.phpost and your unit of measure in IPH.phum. The
tag number IPH.phtag does not even have to be populated. If you do, the
value in IPH.phtag  will be copied into ITH.tcom for reference. Post
(INV650D) for the warehouse of your single record in IPH. Check the ITH
records created. Check the ILI before and after the post. The ILI records
for the posted warehouse where no matching tag in IPH exist, will remain
unchanged. Voilà! INV650D also deletes the records in IPH, after it
processed them.

The description I wrote here is very detailed, not because I think you need
all these details, I know you don't, but for future reference and for the
benefit of other members on this forum.

I might be fearless, but I performed this test before in the production
environment. You may create a dummy test warehouse, and a few dummy ILI
records belonging to the same dummy warehouse, just for your test. Delete
these after youre done. You would be wise to back up ILI just before your
test, just in case. To revert to the original quantities before your test,
repeat the test, but this time with a quantity in IPH.phqty that will bring
the original ILI.lopb back to what it was.


As far as the WIP items that are almost identical to the finished items, and
the possibility they might be mistakenly counted, this is a whole and larger
different issue dealing with part numbering, part identification and
labelling, employee training, physical organization of the plant, physical
organization of the work centers, plant housekeeping, etc. This is a
different topic of discussion, a management chapter in itself, if not an
entire book!


Good luck!

> Daniel Warthold eng, CPIM
Business Analyst
> Eicon Networks Corporation            
>                                       
> 9800 Cavendish blvd                   
> Montreal (Quebec)                     
> Canada H4M 2V9                        
>                                       
> Tel:   (514) 832-3839                 
> Fax: (514) 745-5588
> Email: daniel.warthold@xxxxxxxxx      
> 






-----Original Message-----
From: Alister Wm Macintyre [mailto:macwheel99@xxxxxxxxxxx]
Sent: Thursday, November 11, 2004 21:47
To: BPCS_L discussion
Subject: RE: physical inventory SKIP WIP



Thanks

I am a programmer.
But we do not have AS/Set
We are not using the test environment effectively.

At the moment I am NOT doing ANY programming modifications on this.
I am just researching what seems possible, practical, etc. and potential 
implications.

I can do JOIN files where data in some other file is used to determine 
sequencing and what is included or not included.  However, that is not a 
practicality with INV650 which is updating ILI and IPH ... You cannot 
update a JOIN file, you can only use it for input controls.

A major unresolved problem for me is that it is my understanding that when 
we inventory a WAREHOUSE in BPCS, the physical inventory alters what is in 
BPCS to agree with what comes back from the tags.  If the tags in aggregate 
say that there was ZERO quantity of this item, because we did not count it, 
then the result is that BPCS now says that quantity is ZERO.  But 
management not want that ... they want to selectively ignore some items in 
the counting, and have the BPCS ALSO selectively ignore those items from 
perspective of updating them ... NOT zero what we did not count, but DO 
zero what we checked and found to be zero.

In other words suppose we have in the computer
Part ABC ... and this is an end item ... and in reality we not have it, 
because some transaction got missed ... the purpose of the physical is to 
find that out, and zero what is in the computer for part ABC

We would also have in the computer
Part ABC-2 ... and this is a WIP step for making part ABC
Management wants whatever is in the computer for ABC-2 to be left alone
not zeroed because we did not count anything there
not zeroed because we did not report anything there
but left intact with whatever data was in the computer before the physical, 
right or wrong

We would also have in the computer
Parts A B and C that are raw materials used to make end item ABC
We do want the physical counting of whatever we have there to get processed 
same way as ABC itself

I agree that IPH "tags" file could be manipulated after INV620 create the
tags.
That is an obvious idea that I had not thought of until you brought it up.
I would need to research what is supposed to get populated there, and 
perhaps could use the test environment to help with that effort.

We also do not use lot control / containers / pallet deal / warehouse 
management

BPCS Physical in 405 CD apparently is BY WAREHOUSE
You can choose to physical inventory or not inventory a warehouse.
If you inventory only SOME of the parts there, then all the OTHER parts 
will be zeroed in BPCS, as if they not exist.
That is NOT what management wants.
They want to pick and choose which TYPES of parts get inventoried in a 
warehouse.

They want to inventory warehouses that contain
RAW MATERIALS and WIP and END ITEMS
and ONLY count the RAW and END
not count the WIP
and not have BPCS zero out the WIP.

I am saying this is impossible with vanilla BPCS, as I understand it.
Some modification essential, the only question is how structured.

We have 4 warehouses per facility
    * END items Shipping Warehouse theoretically only contains END items 
but in reality contains END RAW and WIP (mainly END items here) ... The RAW 
is because we import some raw materials for resale to our customers ... 
there are customers that want both what we make, and spare replacement 
materials.  The WIP U believe got there in error, but I believe that some 
of it REALLY is there and should not be zeroed if in fact we are not going 
to be counting WIP items in this physical.
    * RAW Materials Warehouse originally intended to store materials not 
currently being used in WIP but in the last year this concept is being 
phased out, and what is there is a shadow of what used to be there, but I 
see that it has END RAW and WIP ...(mainly RAW).  So for example, we might 
have made more of some item than needed to go to the customer, due to Order 
Policy "I", or fluctuating customer wants, so now we are storing extra WIP 
until the next time we have an order from that customer.  We not want to 
zero this WIP just because the decision is not to count the WIP.
    * WIP items which include RAW used to make the WIP ... in theory upon 
completion the END items end up in the shipping warehouse, but I see that 
some of them do not.  I suspect this is related to errors in releasing shop 
orders due to errors in how the parts are identified which can lead to all 
kinds of confusion.
    * REJECTS warehouse that need QC determination what to do about RETURNS 
from customers, RAW from vendors that did not meet standards, WIP that got 
scrapped but may be repairable ... some stuff goes there then gets
forgotten.

Thus we have these 4 warehouses that are theoretically mainly one kind of 
item, but in reality is a mixture of END RAW and WIP.  Now if the company 
was to use vanilla BPCS to physically inventory this and ignore the WIP ... 
when we get all done, BPCS would have zeroed the WIP and shown a humongous 
variance for the fact that we have LOTS of $ tied up in the pipeline, but 
the physical found nothing there.  But that is not the result that 
management wants.

I also do not believe it has yet dawned on management what the physical 
inventory reports are going to show ... BOOK inventory is this ... PHYSCIAL 
inventory is that ... and because we are not counting the WIP we either 
have huge variance due to WIP, or because of how we modified, we have 
reports that are effectively a LIE which can have legal consequences.  As 
soon as these implications sink in, I am going to have significant mission 
creep.

A related topic that has grown in the last few months.
We have tons of reports that show various discrepancies by item.
Most of our people no longer want to work on discrepancies where we have 
not manufactured or sold the item for some time.
Many discrepancies are because we used to make some item in facility-2 but 
now we make it in facility-4 or vica versa ... the former facility has an 
old story that perhaps ought to be deleted some day.

I think the INV7 reports are going to be this reality on steroids.

I think I need guidance from our auditors with respect to which kind of LIE 
is most desirable.
Do we want the reports to show that BOOK was EQUAL to PHYSICAL for WIP 
because we created phony baloney WIP TAGS whose counts equalled the on-hand 
for those items?  This is the approach I currently am leaning towards being 
the most practical for me to program.
Do we want the reports to show that we had a variance equal whatever it is 
for what we counted plus the total value of WIP because we ignored the 
reports when doing these modifications?
Do we want the reports to only show RAW and END items and exclude WIP so 
that the total BOOK value excludes WIP, accomplished by modifying the INV7 
reports?

We really do have LOTS of $ tied up in the WIP pipeline.
I have not yet looked at the logic of the INV7 reports.

But thanks to your shaking my brain on this.
Let's suppose I did not modify INV650 logic OTHER than to substitute for
ILI-L7
where the current logical looks at ALL inventory by WAREHOUSE ITEM LOCATION
and matches with what it found in the IPH file
and if the physical found nothing for some WIP item, but the ILI file did 
in fact have inventory
BPCS zeros the WIP and says NO TAG
Nice theory, except you cannot update a JOIN file, so I would have to 
modify INV650 to examine the item type of both ILI and IPH records read in, 
and if EITHER is a type 2 item, tell the program to ignore that record and 
continue on to the next one in that file
and the sheer complexity of INV650 is why I want to find another way of 
doing this

INV650 is heavily spaggetti code, in which it is not clear where the coding 
ends for stuff that is not relevant to us, subroutines not in alphabetical 
sequence, routines that run to many pages.

Suppose I used a new logical that says to ignore items that are type-2.
That way INV650 would never find a type-2 item to zero, unless it was in 
the TAGS.
What I not know is what would happen at that point ... it might be trying 
to add a record that does exist.

I think it would be neccessary to add something up front before INV650 to 
say if we going this way (not updating items that are type-2) that if any 
type-2 items got added to the tags by people doing the counting (which I 
would expect due to errors in how items are engineered, or identified) 
there would then be a list of those items ... we would need to either 
change those items so they are no longer type-2 so that the logical not 
ignore them, or we would need to delete those tags before going to INV650.

We would also have to do something about those INV7 reports that compare 
book inventory to physical inventory and say we have a humongous variance 
due to WIP being in BOOK and not in physical.

Because of that reality, I am leaning towards the idea of one way or the 
other, feeding into the IPH file either tags from INV620, or tags from SQL 
that CLAIM that we counted all this type-2 stuff in each of the warehouses, 
and what we found is what was in BPCS on those type-2 items.

The SQL approach has some advantages over the INV620 approach, from the 
self discipline and GAAP-NOT perspectives.

Typically in the past, after the physical has started, our people for 
several days are getting caught up on transactions into the month for what 
actually happened in the facility before the physical started, and there 
are parts of warehouses kind of roped off ... this is quarantined by 
physical ... this is still in production ... production has to raid the 
quarantined area, so the tags there have to be corrected after the raid.

If INV620 was modified in such a way that we could reverse the 
modifications when this is over, so as not to generate type 2 tags, then we 
would have INV7 reports showing humongous variances between what we really 
counted and what was really there with respect to the type-2 items.

Then when the personnel REALLY are finished doing transactions for the 
month, and we have all the INV7* reports with humongous variances due to 
BOOK value of WIP being whatever, and TAGS being zero, then we would do the 
SQL deal to create IPH records based on the aggregate of ILI where IIM type 
is 2

At this point the INV7 reports would show zero variance for the type-2 
parts because we are now lying to BPCS by saying that type-2 parts were 
counted and found to be identical to what is in the computer for those
parts.

There is also a potential problem with respect to outstanding shop orders.
The way we have them structured ... raw materials actually consumed by BPCS 
when we report the completion of some operation, that uses the materials.
The physical comes along and says that raw materials not there, because it 
got consumed by the WIP that we are not counting, then after the physical 
and that WIP gets completed, it drives the raw material negative by the 
amount of raw materials inside the WIP that we did not count.  So the 
result of the exercise will be to make our RAW inaccurate by the amount of 
it that was inside unfinished WIP at the time of the physical.

I will also be suggesting that management ask our tech support about this 
topic.

I think this is a major diversion from ERP logic, especially since we have 
all different kinds of item types in each of our warehouses, and the way 
the parts are labeled for the users, item type is not part of their picture 
... for example we have LEADS ... these are individual wires that go into a 
wiring harness.  For some customers we sell them the individual leads or 
wires ... those wires are type-1.  When a lead is part of a harness, it is 
type-2.  Until now, it was not important for the material to be labeled or 
identified whether it is type-1 or type-2.  In some cases they are almost 
physically identical.  I don't see how the people doing the counting are 
going to know that some leads are not to be counted because they are WIP 
sub-assemblies, and other leads are to be counted because they are sold to 
the customer as end items.

-
Al Macintyre  http://www.ryze.com/go/Al9Mac


_______________________________________________
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: daniel.warthold@xxxxxxxxx