User keeps losing permission to Accounts Payable modules AP Vendors table

I have a Security Group set up as user AP Clerk.  It has all permissions except Clear Records and Year End Maintenance.  Many users are part of this group.

We set up a new user for a recent hire and added them to this group.  When they log in they can access the AP modules and open the AP Vendors table - Processing tab.  When they do so they don't have the option to edit any of the line items in this tab...they can only view them.  Again, other users have the same permission assigned and work fine.

As a test I changed the users permission group to the AP module to a more restricted permission set named View.  I saved the change, then went back and assigned this user the same AP Clerk group permission she had before.  When I did that the user had access to edit the AP vendors again.

Unfortunately that fix only worked for two days and then went to view only mode again.  This morning I once again assigned them to the View security group, then back to the AP Clerk group.  They now have access to edit the Processing tab again.

Has anyone else run into this?  What would cause the system to block them from editing the Processing tab, even though they are part of the correct security group?  Why does toggling them from one group to another, and back again seem to temporarily fix the issue?

  • 0

    I'd be tempted to run the scanisam utility to see if something's wrong with those files.

  • 0 in reply to Django

    I ran that utility but it didn't display any errors.

  • Hi  I've found over the years the most common cause of this problem is problems in Database Setup and the inability for permissions to propagate properly across all entities attached to a common system database, usually due to an invalid, empty or broken company listed in Database Setup sharing a common system database. For example, lets say you have three company databases and a System database in Database Setup:

    ABCDAT (a current company)
    DEFDAT (an old fomer company which actually points to an empty or missing database)
    GHIDAT (the current primary company most users use)
    TSTDAT (a test database containing a copy of GHIDAT)
    SYSDAT (the shared system database).

    In the above case each time you make changes to users and security groups in GHIDAT, you will notice a "Propagation" screen appears which propagates the changes across ABCDAT, DEFDAT, GHIDAT and TSTDAT in alphabetical order.  When the propagation hits DEFDAT, it bombs out failing to properly propagate though GHIDAT (the main company) and TSTDAT.  I've found this often to cause the problems you have.  To resolve it I would suggest:

    • Ensure every company database in your list of databases is valid, you can log into them and use them.  This means ensuring each entity has their system manager at the current version with at least Common Services activated.
    • Remove any companies listed in Database Setup that link to company databases that no longer exist or are broken (e.g. you can't log into them properly and use them)
    • Ensure you only have one main Sage 300 shared folder with one copy of Database Setup so there are no conflicting configurations.
    • I find its best to have a single system database for all company databases.

    One you've ensured your Database Setup and all company databases are valid and clean, open the System Database and click Propagate.  If you made changes to the linking of company databases to system databases, additionally open each company database changed and click Propagate too.

    You should now find your changes from now on propagate and save properly.

    If the above does not resolve the issue, let us know and we can investigate it further.

    Generally speaking I highly recommend engaging your Sage 300 Business Partner or Consultant to assist as they will be well versed in the these problems.  And please ensure all your databases are backed up before making any system database and propagation changes.

    Good luck!