I have a request to go back into a “historical” Epicor ERP application so that our sourcing manager can print off a few POs related to a specific product build from 2012. At that time, we used Vantage. In 2016, we uplifted/converted Vantage data into the Epicor 10 platform and that application was deemed to be a “historical” copy, to be referenced only to look up data.
I was not involved in the configuration of the “historical” Epicor 10 application - so I have no idea how they locked it all down and made everything “read-only”.
I cannot add any authorized users to buyers so that those authorized users can print the POS created by a specific buyer from 2012. The menu options under [ File >> New ] are grayed-out and inaccessible.
The Main Menu (Module: XA, ID: MAINMENU), is also set to “read-only” along with every menu underneath that top-level node of the menu tree.
What part of the application administration controls this - OR - in more clear terms -----> How might I “unlock” the “historical” Epicor ERP application to gain access to the Buyer Maintenance module?
If Main is set to read only, it means they used DMT or some kind of direct update to set that flag. I don’t believe you can use the UI to set folders to read-only.
If you have DMT, then you can simply add a ReadOnly column to your import file and set it to zero. Process the file and you should be good to go.
If you don’t have DMT, then look for a UBAQ in the BAQ designer that they may have used for this. If not, they might have done a SQL update (which is generally frowned upon, but if they’re decommissioning a system, they might not have cared).
Either way, the menu records are stored in ICE.Menu table. If you go into that table, there is a field called “Arguments.” Items set to read-only have “-ro” somewhere in the arguments string. Removing the -ro will re-enable full functionality for that menu item.
I see where the “-ro” value is shown in the “Auguments” field.
I’ll do an export of the [Erp.Ice.Menu] table to make sure I have a record of the values set for all menu items - then perform a DMT to clear the “Arguments” field and give it a quick test.
I performed the DMT using the “Menu” data object (the only one that contained the “Arguments” field).
I just checked the SQL DB and the [Ice.Menu] table still indicates that the “Buyer” menu ID “PMMT1005” contains the “-ro” parameter. Yet - there is no indication from DMT error logs, or the “Reprocess” template, that there were any errors on that menu ID.
The DMT process was tried once more this morning on one record only. Even though there were no errors in the DMT process, the record in question did not change.
Instead, I had to perform a SQL update to change the record and log back into Epicor 10 to verify the change (which worked).
I’ll return the “Arguments” field back to its original state on that record via SQL once our sourcing manager prints out the POs she needs.
I meant that, if you look at the DMT template for Menu, there is an optional ReadOnly column that takes a bit value. DMT is reading that column and then manipulating the Arguments string.
You bypassed that with a SQL write, so the issue is solved. Just saying, for next time, check the DMT templates. There’s a wealth of useful stuff in there sometimes.
