eric_h - Friday, May 20, 2011 4:13 PM:
Shoot down my thinking here, but I would maybe want to track revisions but don't really care about generations. In particular, I would like any rev (or revless) of a part number that is at Preliminary to be able to be modified however many times without every time tracking a generation. Some revs (or when revless) might be works in progress that get lots of changes and I really don't know if we care if we track this (we would lock in once routed.)
So questions is, is this possible? Also, I have not seen the minor rev stuff being used yet. Is that something that can be set up, or it that a field that really is not used. Caveat, I am new to Aras and still learning. I intend to know it well, and training is in the works. I do have previous PLM experience on another system, but right now the Aras "way" is new to me.
Thanks,
Eric
eric_h - Friday, May 20, 2011 4:31 PM:
Here is an example of where I came across an issue on our test system. Again, this is new to me so maybe this really is a non-issue and I am not getting it yet:
Lets say you create a part number and tie a BOM to that part number. It saves at gen1. Then you modify BOM, which creates gen2. You modify BOM again and release to rev A, which is gen3.
Turns out a bunch of part numbers you created for the gen1 and gen2 BOMs are no longer needed and were never released. But if you try and delete them from the system, you can't because the DB referential integrity sees them tied to the useless gen1 and gen2 BOMs.
Again, I am new to this, and at least thought this was the behavior I was observing. I know some of these questions could wait for training, but thought I would see if anyone had any feedback so I can think about the issue more before steps advance.
Thanks,
Eric
authentic - Monday, August 15, 2011 4:00 AM:
1888Tiger4:
Moncler name came from the abbreviation in Monestier de Clermon. Our Moncler Outlet specializes in the production of outdoor sports equipment. We provide the Cheap Moncler Jackets you will just love. Our Moncler Jackets Outlet is secured and trusted by the world. Our products reach a large variety, including vests for all ages, such as the Kids Moncler Jackets which looks wonderful on the little boys and girls. Also, come and take a look, you will find the one Moncler Jackets For Women made just for you. Moncler went through a long history to reach its place today. Our Moncler Jackets Men and Moncler Shirt Women are up to date with the latest fashion trends. At the same time, Moncler Vest Men and the Moncler Vest Womens is made from the best materials and can keep you away from the harms of the bitter cold this coming winter. If you are a person extremely afraid of the cold like me, I would recommend you the Moncler Scarf which will keep your neck cosy and warm in the snow. Another one of my favorites is the Women Moncler Long Down Jacket which can give you the mysterious look as you stroll down the path in the white snow.
Brian - Saturday, May 21, 2011 8:30 AM:
Hi Eric,
The behaviour you are describing is accurate in Innovator.
It is really a question of philosophy and to some degree database space.
You might well have a number of "irrelevant" generations that are created as you go and think to yourself why bother keeping this but to put additional rules in to allow you to bypass the generation tracking just gives you more opportunity to lose vital data down the track. There will come a time when some of this "irrelevant" data turns out to be very valuable or at least saves you time later when you go to re-create the same part that you decided you actually didn't need.
In short you can't easily turn off the generation tracking for Versionable Item Types.
You could code some server events to delete unwanted generations when you save but you would have to take account of all the permutations of items and relationships that you wanted to delete.
As a rule, of course, you want it to be difficult to delete data especially data that is linked to multiple places.
I have often followed the view that part numbers are "free" or at least very cheap. You may define a part now, then decide you possibly don't need it. Well in that case just leave the part at "preliminary" in it's lifecycle. This makes it pretty obvious that the part is not ready to be used. It doesn't wast much time/effort and at least you have captured all the data that the designers used to come to their decision. For example you now know that the assembly doesn't need part X or Y because you have already tried it.
You can reduce the number of generations that are being created by not Unlocking the item. If you leave it locked then the edits will all appear in the same generation. Of course if multiple people are updating the same part/assembly/bom then you probably wont be able to do this.
Over time a database will accumulate a number of irrelevant parts but really it is unlikely to cause a problem unless your processes are such that you are routinely creating lots of unneccessary part numbers. In that case it is the process that needs to be looked at. Not the database.
Cheers,
Brian
eric_h - Monday, May 23, 2011 11:52 AM:
Thanks Brian. I get what you are saying in that part numbers are cheap, and there might be future use if the data anyways. Once I get to training, I will work to better understand all the versioning details and options. This is very helpful.
Eric
eric_h - Tuesday, May 24, 2011 11:56 AM:
Brian or anyone else,
I realized there was another issue related to this that I thought I'd try and see if anyone had any input. I guess I don't care about trapping part numbers in unreleased generation BOMs, but this part could be confusing to users: when they see multiple generations for a single revision, they might not intuitively know which to use. I guess I can deal with the generation tracking, and see its value, but I'd rather only expose the latest generation for each revision to the end user (and locking the ability to change anything that is in a released or pending to be released state). The previous PLM software I used did not do this type of generational tracking, but also stored things in a more convoluted way at the data level. Internally, it appears that Aras can store major and minor revisions, and also generations. It would be cool if you could pick more fine-grained ways of utilizing these, though I'm still new at this and might learn more at training. Certainly I'll have a chance to ask some questions related to this and see what others are doing.
Thanks,
Eric
