Stop users from entering data past a certain date

We’re moving away from Epicor and going to a different ERP.

One of the things that I’ve been asked to do is figure out a way to stop users from entering transactions past our Go Live date. I’ve tested deleting GL periods past the Go Live date, but Epicor will still let users enter Sales Orders and shipments up until AR Invoicing.

What I’d like to be able to do is to let users finish their month end, but disallow them from entering transactions (in all modules) past the Go Live date - is that possible?

Earliest Apply Date will accomplish this for you.

1 Like

Frankly, I would just remove all commands except trackers. DMT would work for you here.

1 Like

Earliest Apply date doesn’t stop users from entering data into the subledgers. I just tested by entering a SO & a Customer Shipment. Both go through.

Users will still need access to finish off Month End, I just want to stop them from entering anything into the next period.

If the fiscal periods for future periods do not exist, the financial transactions will not be able to occur. Can you delete the future periods? for some companies, I do not create periods in advance to prevent future dates.

you could also add a few BPMs to prevent update or posting for certain transactions if the date is greater than x.

I would still cut off everyone to begin with. As you identify users who REALLY needs access, use Earliest Apply date for financials and then control the remaining commands (as you release them) with a BPM that checks the dates and prevents any after the shutdown.

If cutoff is important (and I believe it is), you’re better off being too strict up front IMHO.

I poked around DMT but I can’t figure out how I can use that to completely remove everyone’s access?

Is it the User option with GroupList?

You got it.

1 Like

We use a combination of assigning users Security Groups as well as giving some users specific access to specific menus.

Is there an easy way to get rid of all the specific menu item security through DMT?

At a minimum, add BPM to PartTran, invoking an exception if the TranDate exceed’s your cutoff date.

1 Like

Example? How’s’ that different than the previous statement?

Unless you mean commands from the Actions Menu then look at Service/Method security.

Here’s an example. We have a Security Group called AR Senior. That group has all the menu items for AR under it.

But this user also does AP invoicing - just under the AP Invoice Entry screen. So instead of giving this user an AP Security Group, I just go under:
System Setup > Security Maintenance > Menu Maintenance

I find the AP Invoice Entry screen, and add the user to just that screen and no other AP screens.

So now the user has a combination of Security Groups on their profile, but also one specific menu item that doesn’t belong to any of the Security Groups that’s assigned to their profile.

Does that help?

Adding Users to a Menu Security is a little tricky, as the records employ a “list” in one field

Below is a BAQ of the Security table. User or Group IDs are comma separated, or an asterisk for all users and groups

For example:

  • Only members of groups AC002, AC003, AC001, and the user admin have access to menus using SecID “SEC467”.
  • The * in the Disallow filed means all other users and groups are disallowed
  • The “Financial Management” menu uses sec group SEC467

EDIT

The field names for the Allow and Disallow, are:

image

1 Like

Honestly, I would scrap the old security system and create new groups:
CanAddAPInvoices
CanAddJournal
CanRunAllocations

Blow all the others away and assign the new groups as needed. It’s an old system now, nothing to salvage.

1 Like

@ckrusen is absolutely correct. It’s UserFile.GroupLst PLUS what the Security ID is attached to the MENU items. The Security IDs can also be updated via DMT.