|
Contact me offline regarding this topic.
Charlie Borill 804-750-1480
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: zborill@xxxxxxxxxxx
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
