SW vs MRP item number

[macPT]

Hi all

For management convenience, the item numbers in the MRP BOM are created 10 by 10 (don't ask me why, but it's a management team "tabu").

SW creates the item numbers 1 by 1. We don't use BOM's in SW (we create them in Excel and transfer the information to MRP), but we use balloons in the assembly drawings.

This create a problem that needs to be fixed by two alternatives:

1 - using a x10 correlation, which means that SW item number 25 will be the MRP item number 250 (this was used in the early days of our MRP implementation)
2 - creating balloons manually in SW (the present solution, very time consuming)

This also makes difficult an automatic import of the bom into the MRP (again, extra work to be done).

So I'm loking for a way to control the sequence of numbering items in SW (like "starting number", "increment", "numbers to skip",...). I didn't find anything related to this subject (apart from starting number, which implies creating a BOM in SW) . Am I missing something?

Thanks

 

[MadMango]

We had the same problem, MRP numbers by 10s, SW number by 1s.

We simply dealt with it by holding a training session to let everyone know if the drawing indicates Item 4, look for Item 40 in the MRP system (ie Add a zero mentally). It didn't fix the numbering issue in SW, but it got everyone on the same page, and we didn't have to hobble SW to conform to our antique MRP system. Maybe this will work for you as well.

[green]"I think there is a world market for maybe five computers."[/green]
Thomas Watson, chairman of IBM, 1943.
Have you read faq731-376 to make the best use of Eng-Tips Forums?

 

[CorBlimeyLimey]

I believe the x10s MRP numbering is a hang over from the "pen & paper" days of creating process documentation. The idea was to allow for additional processes to be added in, without having to bump-up the existing process numbers.

The MRP system could probably be changed to increment in 1s if so desired.

& all the best.

 

[pdybeck]

If your are using 2005, you could probably add another column and then use the new functionality in the BOM to multiply the item number by 10 in the newly created column. Calculations can now be made in the BOM. You may even be able to hide the original item number column when done - haven't tried that one though.

Pete

 

[macPT]

Yes, maybe I wil try again to convince management guys to change their way of thinking (hard task). The MRP can be configured the way I need.

Pdybeck: I will check this in 2005 (still running 2004, aging as I wait for 2005SP1.0). But I suppose that there's the need to create a SW BOM (which we don't do) and, from your words, I do not infer that the balloons will update according to new column.

I think a bigger control over the item numbers would be a good enhancement (if I remember well, back in the good old days of Pro/E, that could be done).

Regards

 

[Arlin]

I've heard of this before, but I am a little confused...

Why does MRP require an item number matching the drawing? That is what part numbers are for.

The Item number on a drawing is only local to the drawing. It is only relevant in the context of the drawing.

What happens when you add a component to your assembly and all of the item #s change? I assume you need to update MRP. Just seems like more work to me.

 

[macPT]

Arlin

For organization purposes and quality assurance, the MRP must be in accordance to technical specification. This is the only way to garantee that the production executes exactly as drawings. The product structure, within MRP, is the responsability of the design and development department. The relevant data is according to design.

The MPR also keeps track of drawing revisions, BOM revisions, distribution control and some other relevant properties (internal/external specs, national standards,...). That way the company only have one and consistent product/technical database and everyone that uses it has available all the correct updated information.

If a product is modified (like adding a new component to the assembly, or modifying a dimension), the MRP is updated accordingly.

We try to have (at least that is our goal)a product management system, in which the CAD is only one intermediate tool. Being an external tool to MRP, somethings must be forced to be consistent. Item numbering it's one of them.

Regards

 

[pdybeck]

Arlin,

I agree it is more work, but for macPT as well as my company, we are forced to bend to our MRP system. Our company is driven by whats in the MRP system. There have been discussions here about eliminating the BOMs on our assembly drawings so that users wouldn't have to fill out information twice (Yes this is a moot point with SolidWorks and the people here discussing this had been thinking AutoCAD and not SolidWorks). Nevertheless, it still makes it a pain to jostle the BOMs on the drawings so that the order matches the MRP system. Our MRP system is very in-flexible in in its BOM editing, and so re-ordering of the MRP BOM is not an option. When we make revisions to assemblies in SolidWorks - all items that existed in the previous revision must have the same item number. We often times need to not use an item number, because it has been removed from the assembly. To re-order the MRP BOM is quite a chore, as all entries after the deleted item have to be deleted and re-entered in order to not have a gap in the BOM order - so once a part has been removed from the assembly its item number is never used again. SolidWorks does not have the tools to efficiently handle the BOMs so that it accomodates our terrible MRP system (Avante from Epicor). As far as why the drawing BOM must match the MRP BOM I think people that have been here much longer than myself want it that way.

 

[pdybeck]

same reasons as what macPT said for our company - I just struggled a bit to put it in words...

As a side note, ERP/MRP systems (at least ours) don't seem to be created with engineering in mind, and certainly not MCAD packages like SolidWorks. I think this is where PLM products gain a lot of attention in that they can go between the MRP/ERP system and the CAD system to assure consistency in BOMS and other areas (at least in theory). Our ERP system seems like it does alot, but doesn't do much very well with out some custom programming. The customizing and data stored in a particualr format seems to create a marriage between the company and its MRP system - IMO much more so than an engineering department and its CAD system.

Pete

 

[macPT]

Arlin

Just one more thought.
The company must feed MRP with data in order to produce. You can do it in two ways:
1 - have a design and developemnt department, with it own organization, databases,BOMs,... and other department that picks the information created and translate it into MRP
2 - have a design and developemnt department with the organization integrated in the MRP and feeding it directly.

I think option 2 is best for quality and fro less work.

Regards

 

[Standing]

Arlin,
You have the same type of MRP we do. Very inflexible MRP, called MK for Manufacturing Knowledge. We work around the removal of a part by putting in a dummy part called "00001A" description “Do not Use”, next part is "00002A" and etc. This works very well for us. The MK also calls the item numbers out by 10’s. We trained every one looking at our drawings to mentally drop the last zero.


Bradley

 

[pdybeck]

Can anyone recommend ERP/MRP system that they like and integrates well with something like PDMWorks?

 

[macPT]

pdybeck

My last post was a little late related to yours. So it seams a little bit out of context.

I think we are in the same bot. Here, the MRP is ProdStar2, from ADONIX, and it as the same limitation that your's.

Some tasks of information transfer are being automated by macros and ODBC. I hope that, by the end of this year, the BOM creation will bw automated by a macro, if some issues like in this thread can be solved.

Regards

 

[pdybeck]

We have a macro that will batch import a new BOM from a txt file generated from the SolidWorks BOM. Works pretty well and somewhat silenced the discussion concering getting rid of our BOMs on the drawings due to double entry. It looks to save our drafting/detailing guys a bunch of work that they put up with for years.

 

[MadMango]

Bradly, good to see our company is not the only one using MK.

We use the SW BOM as a guide when creating the BOM structure in MRP, then Hide the BOM on the drawing to force people to refer back to teh MRP system.

I find rather easy to drag components in the Feature Manager up/down to match what is in MRP data.

[green]"I think there is a world market for maybe five computers."[/green]
Thomas Watson, chairman of IBM, 1943.
Have you read faq731-376 to make the best use of Eng-Tips Forums?

 

[Standing]

MadMango,
Sounds like your group, also enters the data in manually from SolidWorks into MK. Is this true?
When we first started MK the trainer told me that we could import data from SolidWorks directly into MK. Our supervisor that was pushing Engineering requirements into MK was fired before the link could happen. It became too political working with MK controllers, so we did not push the issue.


Bradley

 

[Arlin]

Well that certainly got more replys than I expected.

I agree that the MRP BOM needs to match the SWX BOM. Also the SWX should drive the MRP BOM (preferably automatically, but usually manually entered and updated, that the way we do it).

I'm not even sure our MRP has item numbers. Just a list of part numbers (and associated information like Rev, costing, mfg procedures, bin location, etc).

I was simply questioning the need to match item numbers. Over the years, I have learned that new (and better) tools (like SWX) often mean you should change practices and standards (like MRP), even though the change is hard (I want to emphasize that change is hard, but can be good). You developed MRP practices and Standards under AutoCad (I assume), and it worked very well. Now, you have upgraded AutoCad to SWX (a better tool). That means you may need to CHANGE your other practices and standards to better utilize SWX and your MRP together (but change is hard).

Well anyway, to each, his own. I cannot possibly understand 'your ways' (but I enjoy learning about them and helping).

 

[MadMango]

It's one thing to say "change your other practices" but entirely harder to do. In our company the MRP system (MK) runs everything: finance, shipping, receiving, purchasing, ECOs, product configurations, etc. To change to a newer system that would allow direct ODBC input from SW would require >$750k and 6-9 months of for what executives would see as very little ROI.

But it sure would make life grand.

[green]"I think there is a world market for maybe five computers."[/green]
Thomas Watson, chairman of IBM, 1943.
Have you read faq731-376 to make the best use of Eng-Tips Forums?

 

[pdybeck]

As I said earlier, its seems inevitable that companies become so tightly tied to ERP systems - somewhat un-nerving when you think about it.

 

[Arlin]

It's one thing to say "change your other practices" but entirely harder to do.

Yep, I agree completely.