‎Sep 03, 2024 06:02 PM
Hi Simon,
There is no out-of-the-box process for this. While you can add a new status to the AssetStatus table, the asset status does have an impact on linked devices and I'm not sure how a new status will behave in this regard.
Instead, the "Retirement reason" field might be easier to customize and use.
Values are stored in the EndOfLifeReason table. Here is an example:
INSERT INTO ComplianceResourceString (ResourceString)
VALUES ('EndOfLifeReason.Unservicable')
INSERT INTO ResourceStringCultureType (ResourceString, CultureType, ResourceValue)
VALUES ('EndOfLifeReason.Unservicable', 'de-DE', 'betriebsunfähig'), ('EndOfLifeReason.Unservicable', 'en-US', 'Unserviceable')
INSERT INTO EndOfLifeReason (ResourceName, DefaultValue)
VALUES ('EndOfLifeReason.Unservicable', 'Unservicable')
Downside is, that this field is only available when the AssetStatus is set to Disposed or Retired. Of course, you can also go with a custom field, e.g. a checkbox.
‎Sep 04, 2024 04:54 AM
Hi Simon,
Fields like Retirement Reason are based on a table. They can be changed by adding new entries or removing existing one. As mentioned before, some risks and limitations do exist.
Custom drop-down-type fields are defined using a xml-like structure, but they are normally managed by existing Stored Procedures.
To do any of this, you'll need a SQL Client, of which SQL Server Management Studio is one. And you will need sufficient rights on the database server & databases. And maybe a hole in a firewall.
Yes, there's the risk of "damaging" your FNMS implementation and/or losing data. I would advise testing any changes in a dedicated test environment first. Alternatively, get some experienced consultant to develop and test your use case for you.
BR,
Markward
‎Sep 25, 2024 05:43 AM
Hi Simon,
There is no out-of-the-box process for this. While you can add a new status to the AssetStatus table, the asset status does have an impact on linked devices and I'm not sure how a new status will behave in this regard.
Instead, the "Retirement reason" field might be easier to customize and use.
Values are stored in the EndOfLifeReason table. Here is an example:
INSERT INTO ComplianceResourceString (ResourceString)
VALUES ('EndOfLifeReason.Unservicable')
INSERT INTO ResourceStringCultureType (ResourceString, CultureType, ResourceValue)
VALUES ('EndOfLifeReason.Unservicable', 'de-DE', 'betriebsunfähig'), ('EndOfLifeReason.Unservicable', 'en-US', 'Unserviceable')
INSERT INTO EndOfLifeReason (ResourceName, DefaultValue)
VALUES ('EndOfLifeReason.Unservicable', 'Unservicable')
Downside is, that this field is only available when the AssetStatus is set to Disposed or Retired. Of course, you can also go with a custom field, e.g. a checkbox.
‎Sep 04, 2024 04:54 AM
Thank you , that helps me out with my request. 😀
‎Sep 04, 2024 05:02 AM
‎Sep 24, 2024 03:19 PM
Hi Simon,
Fields like Retirement Reason are based on a table. They can be changed by adding new entries or removing existing one. As mentioned before, some risks and limitations do exist.
Custom drop-down-type fields are defined using a xml-like structure, but they are normally managed by existing Stored Procedures.
To do any of this, you'll need a SQL Client, of which SQL Server Management Studio is one. And you will need sufficient rights on the database server & databases. And maybe a hole in a firewall.
Yes, there's the risk of "damaging" your FNMS implementation and/or losing data. I would advise testing any changes in a dedicated test environment first. Alternatively, get some experienced consultant to develop and test your use case for you.
BR,
Markward
‎Sep 25, 2024 05:43 AM