My response was crafted with AI assistance, tailored to provide detailed and actionable guidance for your query.
The "Access Denied to Requisition Number" error in Microsoft Dynamics GP 2018 R2 suggests that there might be a security, company access, or workflow-related issue preventing your user from accessing the requisition. Since older accounts and the SA user can access them, but your account cannot (even with the Power User role), follow these steps to diagnose and resolve the issue:
Step 1: Verify Company Access
Even though you have the Power User role, confirm that your user is assigned to the correct company in User Access Setup:
- Navigate to Microsoft Dynamics GP > Tools > Setup > System > User Access.
- Select your user and verify that the correct company is checked/enabled.
Step 2: Check User Security Roles & Tasks
Even as a Power User, some roles or tasks might be missing for specific functionalities. Validate security access for Purchase Requisition Entry:
- Go to Microsoft Dynamics GP > Tools > Setup > System > Security Roles.
- Locate your Security Role and ensure it includes the following tasks:
- PURCHREQ_001 – Purchase Requisition Entry
- PURCHREQ_002 – Purchase Requisition Inquiry
- If missing, add the required security tasks and test again.
Step 3: Check Workflow Approval & Requisition Status
If your company is using workflow approvals, your user might be restricted from modifying requisitions based on workflow rules. To verify:
- Navigate to Microsoft Dynamics GP > Tools > Setup > Purchasing > Purchase Requisition Workflow.
- Review the workflow rules and ensure your user has permission to view and edit requisitions in the required workflow stage.
- If the requisition is already pending approval or fully approved, your user might not be able to edit it.
Step 4: Verify Purchasing User Defaults
- Go to Microsoft Dynamics GP > Tools > Setup > Purchasing > Purchase Requisition Setup.
- Check if there are restrictions based on users or approval limits that might block access to specific requisitions.
Step 5: Check Database-Level Permissions (SQL)
If everything appears correct in the GP UI, the issue might be with SQL-level access. To verify:
-
Run the following SQL query in SQL Server Management Studio (SSMS) to check user permissions:
sql
- Ensure your USERID is associated with the correct security roles.
-
Check requisition ownership in POP10200:
sql
- If the requisition is linked to a different user, permissions might be restricted.
-
If necessary, update ownership using:
sql
Step 6: Clear User Cache & Restart GP
If security changes were recently applied, they might not take effect immediately. Try:
- Have the user log out of GP.
- Delete the .SET and .DIC files from the GP Data folder.
- Restart GP and try accessing the requisition again.
Final Recommendation:
If none of the above steps work, try:
✅ Creating a new test user with the same security settings and see if the issue persists.
✅ Comparing security settings between a working user and the affected user.
✅ Checking for any third-party add-ons that might be restricting access.
