- App Store
Bug Tracker Incident #8681
Having revision control to copy all the expired components to a new revision of a product sound odd, I would like to request the new revision do not carry expired components into the new one. This will reduce useless data to be copied to new rows where will never be used.
I''m not sure if this issue is genuinely still open or not. As of version 3.3.1 the behavior is a little bit different that described by the original reporter.
The PL/pgSQL function createbomrev(integer, text) will copy expired BOM items, but only under the circumstance where there is no prior revision for the BOM. An empty revision label is considered as having no prior revision. New revisions based from the first revision do not copy the expired BOM components and in the code there is a check for expired date. I''m not sure if this is the design or just a case of logic being added in one spot and not another.
I''ve got a client that I think is seeing this and not understanding the behavior (they have 3.2.2 and I can''t look at the commercial SCM to tell if the behavior changed since the time this was originally reported).
An associated issue which I would like to see is the ability to simply delete an expired item.
The reason for this is to make the ''copy BOM'' function much more useful. For instance if a company has 50 BOM''s, with 10 items on each, and they wish to copy these to create 50 new ones as the new BOM''s will share 9 of the 10 component items with the current. The issue is howver, that if copied, the one component not in common, although expired, will remain with the new BOM''s although it was never part of the BOM for these items to begin with. The ability to delete, rather than expire, would correct this.
|Project||XTUPLEAPPS||Ported From Mantis||x|
SubscribersYou do not have permission to view subscribers.
|12/16/10 09:13||acdrupal||New||Incident Added|