Richard
You're correct in that removing features that a customer is not planning on using now, but may want to use the features in the future, there are other places we would need to remove the objects from, besides just the Dynamics.set and DynUtils.set files.
This blog goes over that information:
community.dynamics.com/.../quot-problem-ascertaining-version-information-quot-error-when-installing-or-upgrading-microsoft-dynamics-gp
To use your example of Revenue Expense Deferrals/1045, with this blog, your steps would be the following:
A. Run these scripts against the GP system database:
1. Delete DB_Upgrade where PRODID = 1045
2. Delete DU000020 where PRODID = 1045
3. Delete DU000030 where PRODID = 1045 (NOTE: The DU000030 can be truncated completely, if not actively doing an upgrade)
B. Against each and every company database, as mentioned in the SY01500 table, run this script against them:
1. Drop Table PP000001
By not only removing the feature from the GP system tables, but also dropping the related sub-feature tables from the GP system and/or company databases, this sets up the databases so, should the customer decide in the future they want to begin using the feature again, they can install it and, instead of upgrading the feature which in your example you wouldn't be able to do from GP 9.x to 18.x anyway, it will install the feature anew, as if it had never been installed previously.
The other blog mentioned has the same information but the one above actually has the sub-feature tables listed for each and every feature.
Thank you,
