Re: Limitation to lot/location -- BPCS-L

> Subj:  Limitation to lot/location
>  From:    MAX.Jiang@AlliedSignal.com (Jiang, Max (Suzhou Laminate))
>  
>  Dear all,
>                I'm new in BPCS world. Does anyone can tell me how to add a
>  rule to  inventory transactions:  No any Inventory transaction can make on
>  hand quantity of a  item/lot/location negative.  In BPCS my warehouse is
>  non-manage warehouse and all item have lot control.
>               Very appreciate your comments!
>  
>  Max

>From Al Macintyre

I think this is a BAD idea & try to explain why.  Hope you understand me.

If I understand you correctly, you want to prevent transactions from 
occurring that would drive your on-hand inventory negative.  In our case on 
BPCS 405 CD without lot control we consider this to be a good thing because 
it is a warning that only part of a collection of transactions have been 
posted & the rest need to go in ... we run regular reports listing negative 
inventory & use them as a check list to resolve the missing transactions.

Suppose someone is trying to ship inventory & the labor reporting that 
created that inventory has not yet been keyed in.  In our company, we go 
ahead and ship the merchandise, driving the inventory negative, then the 
labor gets keyed in & all is in balance, or the negative is a warning to help 
us catch what is missing.

What do you want to do in that scenario?

Tell the customer that the shipment will have to be a day late because you 
misplaced the labor transaction reporting, and your business rules prohibit 
inventory transaction float, or do an adjustment to force the inventory to be 
sufficient to cover the shipment, then reverse that adjustment when the labor 
reporting catches up?

You will probably need a special kind of adjustment transaction (separate 
code from regular adjustments) so that you can run reports listing the first 
adjustment to see if the reversal adjustment actually got made ... probably 
more trouble than doing the negatives the way we do them.

We also get negatives a lot in labor reporting, because our process is to 
gather up labor tickets from shop floor & key in a batch through JIT600 in 
which the actual transactions might not go into the system in the same 
sequence as the work was done ... operation 100 is partially done & people 
are moving the WIP to be used in operation 200 & at lunch or break time, the 
operation 200 work force turns in a few hours labor while the operation 100 
work is not reported until end-of-day, or sub-assemblies this way ... the 
labor reporting temporarily drives some components negative, while other 
transactions in the flow should cancel out in the long run.

Or one labor ticket cannot be entered because of some wrong info ... employee 
number is not right or something easily fixed, the data entry person sets 
that ticket aside to get a fix so that these tickets can go in the next 
batch, enters the batch, but the set aside tickets are creating inventory 
that other tickets are consuming, but in your case you don't want the 
inventory going negative until the set aside tickets are fixed, you want to 
stop everything that uses the inventory created by the set aside tickets.  Am 
I understanding you correctly?

What do you want done in that scenario?

Do you want to intercept the transactions in the JIT620 batch & say "we 
cannot accept these transactions because they would drive inventory negative, 
so create a new batch consisting of the transactions that were refused & 
while we are at it, also delay any operation order closure that was in this 
batch, hitting any places where we are blocking input, because we still need 
to enter these transactions when we get the rest of the story.

Other scenarios

You need to inventory all the scenarios that drive the inventory negative ... 
get a list of ILI records with on-hand negative, then INV300 check out 
history F21 to see how they got that way ... then consider the scenarios as I 
have done for your business case ... if you are going to prevent those 
transactions from being entered because they would drive some inventory 
negative, how are you going to handle those transactions that have not been 
entered because you have blocked them?

You could modify the programs ... calculate resulting on-hand for all parts 
involved & if any one of them would go negative, then back out the whole 
calculation, or possibly leave a zero quantity comment in the history ... we 
tried to do a production transaction on sub-assembly-A but since this would 
have driven raw material B & C negative, the whole transaction was blocked & 
you put the comment on A B C D E F G H I J K L M N O P ... each of the items 
whose transaction was blocked ... possibly a reason code would help here with 
the offending item in the comment feild.  This could set off a cascade ... 
for lack of enough material B & C, you cannot add A production, or deduct the 
other components of A, which some other transaction cannot consume, and of 
course the more inaccurate inventory you have the more trouble elsewhere in 
the system such as MRP.

Thus anyone looking at history on A D E F G H I J K L M N O P can see that 
the inventory on this item is not accurate because it is waiting on a fix due 
to some problem with item B C because of the company rule that we do not want 
any transaction to drive any item negative for any reason.

There is also the concept of a TRIGGER program ... basically you set up some 
rules at the FILE level saying that we will not permit ON-HAND to be negative 
... remembering that on-hand is not a field but a calculation from a 
collection of fields.  Then when any program updates the file, there is a 
check to see if that would make the value negative, and if it would, then 
some other program is launched.  At this point the trigger program has a copy 
of the image of the file before / after proposed & can roll back the change 
but it gets more complicated ... the original program is not just updating 
your inventory, it is doing a whole lot of other things that need to be 
rolled back to keep the files in sync.

If BPCS data entry was exclusively individual on-line transactions in which 
the trigger program could block just one transaction & the rest of the data 
entry run fine then it would not be so dangerous, but the reality is that 
BPCS runs a lot of batch stuff & reorgs, in which each program might be 
updating 20 files in sync with each other & you have to second guess all of 
that if you are going to block one transaction.

It might be safer for the trigger program to let the transaction go ahead & 
basically be used as an alert mechanism ... send a message or an audit trail 
... we just had something driven negative ... it was done by program-A 
transaction-type-B user-C on date-D time-E at workstation-F to 
item-warehouse-lot-location-G ... collect a bunch of statistics so that you 
can then mandate a roll-back of those drive negatives that do not cause more 
damage than they are worth.

Hope you find my thoughts constructive

Al Macintyre
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---