× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



You should be able to use the IUM file (Item Conversion Maintenance)
THis allow you to set up conversion factor that is customer and/ or
warehouse specific, from any units of any units.

BPCS however will require that the internal stocking unit  of measures
is the unit of measure set up in IIM. 

In ORD or in PUR , the user may be able to enter any of the defined
Unit of measure and the system will make the appropriate conversion.




 --- Jose Torres <jjtorres63@xxxxxxxxxxx> wrote: > Fred,
> 
> To this day, I don't believe BPCS is able to stock the same item as
> defined 
> by a unique item number (or SKU) in multiple units of measure.  I
> have been 
> in contact with BPCS since version 1.0 on the AS/400 and don't
> believe this 
> is doable.
> 
> Please consider the following points...
> A. The item master (INV100 - file IIM) only contains one (1) stocking
> unit 
> of measure.
> B. Conversion factors on the same INV100 for purchasing, pricing, and
> 
> default selling units of measure reffer back to that one stocking
> unit of 
> measure via the respective conversion factor.
> C. The planning by facility does provide for multiple planning
> methods, 
> policies, lot sizes, etc, etc., but still reffer back to INV100 for
> stocking 
> unit of measure.
> D. None of the inventory balance files (container, lot, location,
> warehouse 
> and item) carry the stocking unit of measure.  In order to handle
> inventory 
> movements, BPCS goes to the item master for the stocking unit of
> measure and 
> that is how it knows if it is dealing with EA, LP, KG, etc, etc.
> E. The bills of material maintenance program, and associated
> qantities per, 
> is based on the stocking unit of measures stored on the item master.
> 
> The above is what comes to mind quickly...There may be others...
> 
> The way I understand item x-reference works is that you specify this
> on a 
> customer-by-customer basis. However, if you look at the order line
> (ECL) 
> file, for example, you will see that there is an item x-reference
> field 
> which is different than the normal (or your internal) item number. 
> BPCS 
> will use the x-reference item for shipping/billing documentation and 
> displaying it on screens, but NOT for inventory movements.  It only
> looks at 
> the internal item number for any inventory transactions.
> 
> Your requirements of having multiple stocking units of measure for
> the same 
> item may be well justified based of the business practice differences
> that 
> exist between the US and Canada (one of which is units of measure).  
> However, you could be complicating matters for your customers and
> everyone 
> that deals with inventories on either side of the border.  Maybe;
> maybe not.
> 
> For example...
> 1. Are you going to have a single product catalog for customers ?
> Different 
> item numbers for the same "stuff" would be confusing to most people. 
> On the 
> other hand, if you do have a single item number on the catalog, how
> are your 
> people going to know what their specific item number (in LB or KG) is
> ?  May 
> need to implement some "suffix or prefix" scheme.
> 
> 2. Will customers on either side of the border be able to order the
> product 
> from any plant ?  Again, the fact that you have more than one
> identifier 
> will confuse things.
> 
> 3. How about customer pricing and discounts ? If you have two
> products, you 
> can keep things separate but when it comes time to price changes and
> things 
> of the nature, complications again.
> 
> 4. Do consider that this is not just at the finished good level.
> Quantity 
> pers in the bill of material are going to be different so you will
> have to 
> have different bills for the items in the different units of measure.
> 
> 5. Of couse, because you will be duplicating items; some file sizes
> will 
> pretty much duplicate.  This will make daily, monthly and yearly
> processes 
> run slower.  People say disk space is cheap, but I rather keep my
> money 
> invested than having to spend it on additional capacity.
> 
> 6. Of course, I could not leave out what we get asked all the time by
> our 
> senior executives.  How much of "that stuff" we sold ? Or, how many
> weeks of 
> inventory do we have ???  If you have different items to track the
> same 
> finished good, you will always have to be adding things to come up
> with the 
> numbers.
> 
> Most of the things above are minimal or insignificant when you look
> at them 
> individually.  However, put them together and they add quite a bid of
> 
> "excess burden" to the people dealing with them.
> 
> I hope this helps.
> 
> Regards,
> Jose J. Torres - MS, CISA
> Phelps Dodge International Corporation
> 
> >From: <fberger@xxxxxxx>
> >Reply-To: "SSA's BPCS ERP System" <bpcs-l@xxxxxxxxxxxx>
> >To: "SSA's BPCS ERP System" <bpcs-l@xxxxxxxxxxxx>,
> bpcs-l@xxxxxxxxxxxx
> >Subject: Re: Multiple Units of measure for one item
> >Date: Thu, 31 Jul 2003 9:50:35 -0400
> >
> >Jose,
> >We are indeed already using the U/M conversion factors from IIM and
> ORD 
> >when we sell to the customers or buy from foreign vendors. However
> my 
> >problem has to do with stocking and manufacturing the same item in
> two 
> >different Units of Measure. We also need to resupply our Canadian
> facility 
> >with items made in pounds. For that we usually use Resupply Orders
> in ORD 
> >with our other US facilities. Then they will have to receive them
> into the 
> >same BPCS environment, which already contains the item defined as
> LB, but 
> >they need to be able to stock it and sell it in KG.
> >Does this make sense?
> >SSA's Catch Weight module is available at 6.04 (where we are) and
> now 
> >integrated into version 8.2. It was designed for the food processing
> 
> >industry for example, where the same item is managed by weight and
> piece. 
> >Something I have to look into.
> >Thank you and best regards,
> >
> >Fred Berger
> > >
> > > From: "Jose Torres" <jjtorres63@xxxxxxxxxxx>
> > > Date: 2003/07/30 Wed PM 05:38:43 EDT
> > > To: bpcs-l@xxxxxxxxxxxx
> > > Subject: Re: Multiple Units of measure for one item
> > >
> > > Fred,
> > >
> > > Not need to setup duplicate item numbers to do this.  BPCS allows
> you to
> > > sell a given item on any unit of measure you setup in the system.
>  If 
> >the
> > > selling unit of measure is different that the stocking unit of
> measure, 
> >then
> > > all you have to do is setup conversion factors between them using
> the
> > > appropriate program which is part of the inventory module.  BPCS
> will 
> >track
> > > customer order pricings and quantities in both units of measures.
> > >
> > > But, there is a catch... Which we are facing right now...
> > >
> > > If product weight is critical for you and it varies from
> production run 
> >to
> > > production run (of the same finished good item that is) then you
> might 
> >have
> > > problems.  In our industry, some customers purchase in "weight"
> units of
> > > measures.  Others buy in "Length" units of measure.  If the
> production 
> >runs
> > > are not always the same in terms of the stocking unit of measure,
> this 
> >will
> > > bring conversion issues.
> > >
> > > We called SSA about this and they don't have a solution.  We
> track 
> >inventory
> > > by lot and yes, you can track quantities (issues, adjustments, 
> >available) by
> > > lot.  But you cannot track tare, gross and net weights.  SSA also
> talked
> 
=== message truncated === 

________________________________________________________________________
Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.