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



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
> about the weigthcatch product but we are not licensed for it in versio 6 (it
> because available after we signed the license agreement) and don't know much
> about it.
>
> In summary, if you production runs are same in terms of weight, I think you
> will be ok by setting up the conversion factors in the inventory module. If
> the weights are different, you will be able to get about 90% of the job done
> with base-BPCS functionality. You may have to do some additional
> development to get the rest done.
>
> I hope this helps.
>
> Regards,
> Jose J. Torres - MS, CISA


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


_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.