|
We should never change any business rules in BPCS without first studying and understanding all the associated documentation, which can be quite extensive. Those of us on BPCS-L are with companies with different needs, so solutions for any one of us may not be a good fit to another company.
Some aspects of BPCS are so complex, that reading the documentation is not enough, need to go to some BPCS classes.
Some error messages can be misleading. The programmer is playing a guessing game what the user is really trying to do. Sometimes we guess wrong. Also, only one line on bottom of screen is available for summary of message. I not know about your company, but we find it impossible to get people to put cursor on summary, do F1 (help) to read the entire detail.
I have managed to get a handful of my users to send me screen print of the message they got. They all start with some code #. I can then look up that code # to get at the additional detail the user is not reading. If the user calls me when still signed on since the incident, I can look at the AS/400 joblog on their session to see circumstances of them getting what error message & what actions they took. But more usually, the end user has done an incomplete job of communicating the circumstances.
One concept is a user having no business trying to issue a item that is not related to the part being made ... some kind of human error there, not neccessarily with the person trying to do the transaction. From your earlier post, I thought that was what was going on.
Another concept is that a factory can have more than one warehouse ... one from which inventory is to be shipped, one holding received inventory that has not yet been inspected, one holding inventory that is Ok to use in production, and so forth.
Now if you got production in a WIP warehouse, and you have a new user who is unfamiliar with the reasons for the different warehouses, you could have a scenario where some raw materials is both sold to end customers, and is in shipping warehouse for that purpose, and also has some in production warehouse to be consumed into parent parts, then your new user tried to issue the inventory that is supposed to be sent to a customer, instead of trying to issue the inventory that is supposed to be used in production. So it is important to know what warehouse the user tried to issue from, and what warehouse is supposed to be used for issues.
Another concept is the user has the right item # but the inventory involved has been allocated for some other purpose, that a user tries to issue contrarywise. It now sounds like this is your situation. We never have this problem because we use BPCS a different way than you.
Allocations are needed in some companies due to lot control where the exact same item needs to be tracked throughout the process to meet government regulations. In our case, we have no such requirements. We treat all inventory of the same item as interchangeable, except where some QC problem & that stuff is moved to a special warehouse of all problems to block usage of the problem items until QC has determined whether it is repairable.
Remember that you have system-wide rules, then provisions in BPCS to have exceptions for individual items. In some cases, there could be errors in how the items were entered to your system, such that the rules were not intentional.
It is important to identify what item # the user was trying to issue to be consumed by what other item#, so that you can check the coding on those items to see if they setup incorrectly.
Over the years BPCS software has evolved, but some logic is still out there associated with needs of earlier versions of the software, needs which may have evaporated.
Once upon a time, many versions ago, it was neccessary to allocate 100% items to orders, before doing transactions on them. So we'd run a mass allocation & the BPCS methodology (poor design) was not to allocate based on first order due, but on basis of first inventory location alphabetical naming, so 90% of the allocations inappropriate. Then as more items made, received, we'd have to run mass allocation on them, and manual corrections. Someone goes to do a transaction, the inventory allocated some place else. You had to figure out where that was, unallocate there, reallocate to where you needed it, then do the transaction.
We do not use "I" transactions today.We report 99% of our labor via JIT600 which backflushes relevant issues & has screens where we can make adjustments if need be. Occasionally, after entering transactions, we find there was some mistake, requiring corrections.
An advantage of JIT600 approach is that it lets you drive BPCS inventory negative. You see, we are making sub-assemblies, then using them up on other parts very rapidly, same day many components are created, then used up. It is not practical for us to enter the labor tickets in the exact same sequence as the work was done. Anyway, JIT updates the work in the sequence of shop order # in each batch.
Thus the updating may issue materials before processing the transaction that created that material. It does not matter what is allocated, if the material is not there, the on-hand goes negative, to reflect what was consumed. Then at end day, end week, etc. we get a list of what inventory on-hand is negative, which tells us where to look for need of corrections. We always have dozens of items whose allocations have been driven negative. This gets fixed in the weekend allocations reorganizations.
Because JIT600 does not accept negative action impacting inventory, we use SFC600 to correct the labor and INV500 to correct the inventory. But we use a negative M because with a single data entry, we fix all the issues. Some of our parts can have scores of components, all fixed with a single M.
Our ITE rules are setup so that any of these shop order related transactions must be against a valid shop order.
The system is not perfect. BPCS math gets screwy with scrap, because the BPCS programmers made assumptions that are contrary to how we operate.
Hi Mac, Thanks for your response. I have setup in system parameter for " Allow Issue of Non Allocated Components to Shop Orders = *NO ' ( does 405 CD have this system parameter too ? ) But when user did inventory transaction type I ( single issue ) for WH which isn't same with FMA/MWHS, program gives error message " Item number, warehouse, or sequence number incorrect for this shop order. " This error message urges user to do Shop Order allocation. User asked me " Why he must allocate for items have no allocation required at facility planning data." Do you ever facing experience for this issue ..? Thanks. -- 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: macwheel99@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
