Is Mp3 Obsolete
Author Metcalfe
We went live in January. I am trying to determine parts for our annual obsolete inventory. In our old system we had a report that showed usage for the past 2 years, 1 year, quarter and month - even if that usage was 0. That allowed me to narrow down the field to 0 usage parts and consider from there.
I tried setting up the Slow Moving Inventory report in Epicor, but that only shows parts WITH transactions. If there are no transactions the part doesnt show up on the report at all. We have a lot of stock parts and I dont have them all memorized. Obsolete inventory report only works for lot tracked items - we dont lot track. Any ideas on what report to use or how to set one up? Thank you!
If you go about making your own, it would involved making a BAQ that looks at the last transaction for your specific part (Subquery). Whether you want that to be receiving into inventory (RcvDtl) or a specific transaction (PartTran). Depends on how you consider something to be slow/obsolete.
Thanks. Unfortunately, neither of those out of box reports work for us, because Slow Moving Stock only shows transactions (if a part has no transactions - it doesnt show up on the report) and obsolete stock is for lot tracked items only and we dont lot track. We need a report that shows a part that has had no transactions against it during specific time periods.
I managed to scrape together a dashboard that calcs the last stock related transaction, last job, purchased (12mths) and issued (12mths) to give a bit more background to each part on hand. We also link the customer on our build to order jobs, so we can then use it as a MOQ or slow moving by customer and finished goods part.
We are using Obsolete as a lifestyle state. Yet in doing this, the user doesn't have a way to access an assembly containing an obsolete item. The assembly simply won't open at all. My hunch is that there is a quick setting for the user to access assembly files containing obsolete items, yet am uncertain of the settings or adjustments required to allow this to happen.
You can change the permission on the lifecycle state to ALLOW for Read-access.
However, this is always the issue with Obsolete states: you hide those because you want the designers NOT to use them, but if an assembly/drawing still consumes any obsoleted file, they will open Unresolved. Then you require a senior or higher-access user to re-release or move those obsoleted files out of that state to allow work to continue with the assemblies. Until someone swaps out all the obsolete content. The problem here lies in the fact that switching a state in Vault is never enough to truly obsolete the content, because it also requires replacing that content wherever it is used (if you don't do it, your workflow breaks as you saw).
In my experience, we had to create a specific "Do Not Use" state that was still visible (Read-ALLOW) to all designers and that should not be a Released-type state (and you can also prevent the lifecycle transition to a released state from this one). Eventually, in that team even "Do Not Use" had to be set as a RELEASED type state because many projects were rushed to release and the very condition we set had to be circumvented when needed (not good!).
You've defined the scenario as we have it. We were unaware that an obsolete item would cause this much "fun" for us. Now knowing this, I will have to meet with our group here and see how we might want to approach this. Certainly, the idea of an obsolete item is something we want, yet the ramifications of how it's (currently) set up in Vault is not something we want.
We do give engineering the ability to read the obsoleted parts, so I'm wondering if the setting that I need to have toggled on is in another location. Do I need to assign Deny to the Modify, Delete, and Download categories or are those fine as remaining blank?
My apology. I need to clarify that these are parts and not items. We haven't established the items yet, since we are still working through our implementation. We're only two months into this process and are attempting to catch all of our hiccups prior to building on what we have.
Right-click your inaccessible file (while logged as a Vault admin) and go into Details to check what Effective Access is like for a specific user that has this issue (that tab is used for sampling/testing, where you can add a user/group and check, without any sticking/lasting changes). When in doubt, because folder permissions and group permissions overlap, it is always best to check a sample's effective permissions to make sure it is what you expect.
From what I understand, Vault sees Obsolete and has its own process for working with files with this designation. Would it be better for me to create a lifecycle state called "Legacy" and just allow that state to be read only for the engineers and designers? It's appearing that Obsolete has its own personality within Vault, if we were to implement it "as is" (out of the box).
The main reason I see for tagging states as "Obsolete" is to set those aside when you perform a purge. I do agree that Legacy or another name is more suitable at times, especially where "Obsolete" is applied to individual files instead of entire projects/assemblies.
I think there is something else at play here that is preventing your users from opening the Obsolete files. Without the "Download" permission set to "ALLOW" in the lifecycle state table, your users are not downloading/Getting the needed obsolete parts to open the assembly/assemblies fully resolved. Test changing that.
I tested out that scenario of obsoleting the part, then completing a "Get" of the assembly again. In this instance, I was able to get the desired result that everyone was expecting to see. Even the associated icon for the obsolete part was changed and obvious in the Vault browser tab in Inventor. It's not so apparent to need to know to perform the Get after the change to obsolete, yet that is the key we were looking for. Logically, this is no different than updating during any state change.
Looks like that Obsolete Software Key 'ChangeTracker' notification is probably going to be one of those ongoing registry detections in CCleaner like the 'ToastNotifier' one which has now been there for months & months.
I'm having the same problem, and as for the idea that I shouldn't clean my registry because Microsoft changes the registry a lot, I'd prefer NOT to have Microsoft or anyone else messing with my computer unless I specifically want them to, and I don't see why I should let my registry pile up a bunch of garbage entries, slowing down my computer, just because some intrusive mega-corporation wants to control it. And when my computer is running slower than usual, that IS something that's already broken.
Dude, you're the one telling us not to use CCleaner to remove files CCleaner thinks are unnecessary, but which you're assuring us are actually necessary. So - by your own admission, this IS a CCleaner problem. If the file is necessary, then maybe the CCleaner software should be amended so it knows not to delete that registry entry.
When MS add new registry entries that the current CCleaner reg cleaner doesn't recognise then it takes time for CCleaner to be changed to ignore them - if it is decided to ignore them.
The developers may decide that clearing the new entry is required anyway, even though Windows will create it again.
Have a read of the link in my signature;
There's an explanation of why CCleaner will remove certain files even though it's known that Windows will put new ones straight back to replace them.
That isn't an error, CCleaner does it deliberately to 'refresh' the files.
(Whilst not quite the same thing for a registry entry as a file, doing that can still be relevant to reset some entries that may have been modified).
I 100% agree with Ian Cooper and his April 10 comment. If this is a CCleaner issue - then CCleaner needs to fix it. As a licensed and paid user of these tools, Moderators, like nukecad, need to understand the customer's perspective and use their Moderator position to drive the company we pay to be better and not slide down the slope of "it is ok" - recognize a problem and drive a fix. This goes back to April - 6 months later the registry item is still showing as an issue. Drive the solution versus perpetuating the problem. I don't need to read an excuse, the software needs to work after 1/2 a year.
...When MS add new registry entries that the current CCleaner reg cleaner doesn't recognise then it takes time for CCleaner to be changed to ignore them - if it is decided to ignore them.
The developers may decide that clearing the new entry is required anyway, even though Windows will create it again.
...There's an explanation of why CCleaner will remove certain files even though it's known that Windows will put new ones straight back to replace them.
That isn't an error, CCleaner does it deliberately to 'refresh' the files.
I get that sometimes it takes time to update the program, but so what? It's been months, and you're still saying "may decide". If the program thinks the files should be deleted, then when people complain, simply tell them that this is the case, instead of waffling on about it being a Windows problem and telling them not to use ccleaner's registry cleaner (let's not forget, you said " it's unwise to use a Registry Cleaner unless you are trying to fix a specific problem." - I view any junk in my registry to be "a specific problem" because ccleaner TELLS ME IT IS!). The fact that you haven't given us any definitive answer on this issue, and you're still using words like "may" indicates that this issue STILL hasn't been addressed either way, and you're just making excuses.
Whilst we might get a few extra insights into what is happening at the company we can only know what we are told by the company.
We have no influence over what the company is doing, other than complaining if we think what they are doing is wrong (and believe me, we do).
Just like you are complaining here.