RE: Backflushed Location Headaches -- BPCS-L

Al you wrote: BPCS does not care what the human significance is of
various locations ... 
it just grabs inventory from next alphabetically named location that has

enough inventory to meet needs of current transaction.

But that is not necessarily the case because there are some parameters
to control it. There is a forced location flag in Location-Master
maintenance along with a Pick (and allocate) sequence. This latter flag
in conjunction with the Zone/Pick Sequence in Warehouse master
maintenance will control how BPCS uses material from locations and
warehouses.

Paul

-----Original Message-----
From: bpcs-l-bounces@xxxxxxxxxxxx [mailto:bpcs-l-bounces@xxxxxxxxxxxx]
On Behalf Of Alister Wm Macintyre
Sent: Monday, January 26, 2004 4:19 PM
To: SSA's BPCS ERP System
Subject: RE: Backflushed Location Headaches


Al Mac is 405 CD now ... was BPCS on S/36 for many years Sometimes it
runs together in my head how BPCS behaved different on which 
release.

Basically the allocations of inventory to be consumed from what
warehouse 
and location, this aspect of BPCS software lacks the granularity of
control 
that is desired by many companies.
This is an area where some of the 3rd party vendor add-on solutions
might 
find a potential market.

BPCS does not care what the human significance is of various locations
... 
it just grabs inventory from next alphabetically named location that has

enough inventory to meet needs of current transaction. Off-topic for me
to share Robotic Laws that Isaac Asimov got wrong, where 
BPCS same pattern.

Our locations are named after the customers for whom the final product
is 
to be delivered.
That's in reality.
In BPCS we have to use a different naming convention because of BPCS 
inadequacies.

We want to have enforceable rules what inventory is to be consumed
where, 
but often BPCS does not care about our rules, it just grabs the
inventory 
wherever it can find it, sometimes driving some fields negative, and 
sometimes not able to handle all files in sync, so we end up having to
do 
reorgs not because of anything any human did wrong.

In the absence of BPCS ability to adhere to our rules, we have to map
out 
all files that contain whatever rules BPCS is really obeying, such as 
contents of ELA file, allocations of relevant orders, and how they get
that 
way such as from MRP planning files, then at some strategic point in the

processing of those files, such as labor reporting, impose our changes
to 
the BPCS rules, with the rules of our company, sometimes with
modification 
programs into BPCS job-streams, sometimes with instructions to end users
of 
an extra step to follow when releasing orders, and also we have to know
how 
to cope when users miss that step.

We have had massive modifications to this area, very poorly documented, 
because most of them arrived during a Y2K conversion that had us
drowning 
in glitches needing fixing ... typically 50 glitches a week to be fixed.

God forbid that we ever have to go through this process again, if the
rules 
of our company evolve.

Our finished goods end up in warehouse 21 for factory # 2, warehouse 41
for 
factory # 4 etc. so named because "1" is item type "1".
Our WIP is in warehouse 22 42 etc. because "2" is item type "2". Our raw
materials and sub-assemblies are correctly consumed from the *2 WIP 
warehouses, while the FG correctly received into the *1 warehouse.

We do not use lot control.
Sounds to me like you want to explore whether BPCS will let you use lot 
control ONLY on the items that need this greater granularity, without 
messing you up with the rest of your production.

Dave Parnin wrote:

>Paul,
>
>Thanks for the reply.  I've worked with 4.05CD before at a place that I

>used to work at although it's been awhile since I've dealt with 
>material planning, backflushing, shop orders, etc.  The shop orders for

>both the kits and the component FG parts are going to warehouse 21.  
>The actual location names are DWIP and FGDI.  When the FG components 
>are produced we want their components to backflush from DWIP.  When the

>kits are assembled we want them to backflush from FGDI.
>
>There is no ILM default location set for warehouse 21.  There is also 
>no default location assigned in the Item Master for either the FG or 
>kit parts.  Is it just backflushing the kits from the first location 
>that it finds for warehouse 21?  The IWI default location for the kit 
>part is FGDI and the Default/Forced location flag is set to zero.  Does

>this give you a better picture?
>
>
>Dave Parnin
>Nishikawa Standard Company
>Topeka, IN  46571
>daparnin@xxxxxxxxxxxxxxxxxx
>
>
>                       Paul
> LaFlamme 
>
>
>Hi Dave,
>
>We're on 405CD, very similar to what you're running. I have a couple of
>questions: What warehouse are your FG item shop orders issued to? The 
>warehouse the shop order is "cut" to will be the warehouse location the

>components are allocated to for later backflush and it has precedence 
>over any item master, facility or system parameter default.
>
>My next question is To what warehouse is the kitted item being issued?
>
>Paul
>
>-----Original Message-----
>From:  David A Parnin
>
>Greetings everyone,
>
>I've got a situation where one of our facilities is starting to make 
>"kits" that consist of two finished good parts.  The two finished good 
>parts will also continue to be stocked and sold as individual items. 
>When these two parts are produced their production is posted to the FG 
>location for the warehouse and their components are backflushed from 
>the WIP location.  When the kit item is produced its component finished

>good parts are getting backflushed from the WIP location instead of the

>FG location.  This requires a corresponding transfer from FG to WIP to 
>correct the inventory balances in both locations.  Another bit of 
>information is that shop orders are downloaded from BPCS to a PC-based 
>production reporting/barcode labeling/shipping system and then uploaded

>back to BPCS.  They are batch posted through JIT (JIT500?), I believe.
>
>I've tried setting the override location in JIT110 to be FG.  There are

>two operations for the kit--"finish" and "report".  I've copied the 
>workcenters and changed the new workcenter "from" and "to" location 
>values to both be "FG".  The routing for the kit item was then changed 
>to use the new workcenters.  Still, when I've tested posting 
>transactions with JIT600 it backflushes the kit components from WIP. 
>Can this be set up?  Is there a program fix that we are missing?  Am I 
>crazy?  (I feel like I'm going
>crazy!)
>
>We are on 4.0.2 that was modified for Y2K by 3rd party software long 
>before I started working here.  Thanks in advance for any advice and 
>suggestions.
>
>Dave Parnin
>Nishikawa Standard Company
>Topeka, IN  46571
>daparnin@xxxxxxxxxxxxxxxxxx


_______________________________________________
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.