Purpose |
Questions and Answers |
Question 1: How do I activate the Batch Approval and Post Security setup (P00241)? |
Question 2: Which modules apart from AR, AP, GL can be implemented using Batch Approval and Post Security setup (P00241)? |
Question 3: What different batch types can be secured using Batch Approval/Post Security setup(P00241)? |
Question 4: How is the workflow functionality for JDEBCHAPPR related to Batch Approval and Post Security setup (P00241)? |
Question 5: How can we allow a user to post an A/P batch but not a G/L Batch considering Batch Approval/Post Security is enabled for both G/L and A/P? |
Question 6: How can we setup a user to be able to view/approve/post batches for all other users with the Batch Approval and Post Security (P00241) setup? |
Question 7: After setting up USER1 as an Approved By User why can USER1 not approve and post their own batches? |
Question 8: Is it possible to configure Post Security (P00241) based on Roles rather than each individual user? |
Question 9: Can a Secured user post his own batch by running R09801 post report from Batch Versions? |
Question 10: While approving a batch in P0011, why does the user get an error message "Address Number - Invalid"? |
Question 11: While trying to approve a batch in P0011, why does user receives error: "Not Authorized to Change Batch Status"? |
Question 12: Why are all users unable to approve and post batches after setting up Batch Security in Batch Approval/Post Security Constants (P00241)? |
Question 13: What is the significance of using "*ALL" for Secured Users? |
Question 14: Why do I get "You are not authorized to run this report" error intermittently while trying to submit R09801 using P0011 Row Exit? |
Question 15: Why does an user having batch review security setup is able to view other users transactions from originating programs (P03B2002, P0411)? |
Question 16: Is a secured user restricted from both batch approval and batch posting, or just batch approval? |
Question 17: Is there a way to prevent posted batches from being changed? |
This document contains some frequently asked questions and answers on the Batch Approval and Post Security Setup (P00241).
Answer 1: You can activate the Batch Approval and Post Security setup as follows:
Fore more information, please refer to Overview of Batch Approval and Post Security Setup.
Answer 2: Based on the Application Constants application (P41001) setup, the following modules can be implemented:
Open Work With Branch/Plant Constants application (P41001), form exit "App. Constants" to access the above form.
Answer 3: You use the Batch Approval/Post program to establish both batch approval and post security; however, the batch types that are secured are different for each type of security. The following table outlines the system and corresponding batch types for the both batch and post security:
System | Batch Types for Batch Approval Security and Batch Review Security | Batch Type for Post Security |
---|---|---|
General Ledger |
|
|
Accounts Payable |
|
|
Accounts Receivable |
|
|
Answer 4: Both are mutually exclusive as its not mandatory to setup Batch Approval and Post Security setup (P00241) for using workflow since the address number of approver is always hard coded inside the workflow recipient rules and irrespective of what is setup in Approved by User (P00241), it will always direct the workflow for approval to the hard coded user.
Answer 5: It is not possible to restrict Batch Approval/Post Security by batch type. Segregation of duties and setting up who can approve and post whose batches would accomplish the restriction, so an approver for A/P would not be able to post G type batches.
Answer 6: Add an Approved by user with the user id of the user that needs to be able to review/post/approve all the other user's batches and then in the secured by, specify *ALL.
Answer 7: USER1 needs to include their User ID in the Secured Users list under the Approved By record to have the authority to approve and post their own batches.
Answer 8: This functionality is currently unavailable. However, an enhancement request was entered for this functionality under Bug 10744603.
Answer 9: The system will validate the Batch Approval and Post Security setup and displays an error on the report "Error: Batch Not Approved for Posting".
Answer 10: It is required that the User Profile for the user approving the batches is setup with a valid address book number in the User Profiles (P0092) application.
Answer 11: This is because the Post Security Constants (P00241) has been set up to secure the user from approving or posting batches. To rectify this issue, the user needs to be removed from the list of Secured Users or post security needs to be turned off. After either adjustment is made, the cache must be cleared for the changes to take effect.
Answer 12: Approved By users and Secured users must also be configured to complete the setup of the Batch Approval/Post Security. These are defined through the Batch Approval / Post Security Constants (P00241), under the Form exit.
Answer 13: If the person has authority to approve and post all the user batches, enter *ALL in the Secured User field instead of identifying each user individually. Lets take an example to understand the same:
Approved by Users | Secured User |
---|---|
Manager1 | User1 |
Manager2 | User2 |
Manager3 | *ALL |
In this case, both Manager1 and Manager3 can approve the batches created by User1 and both Manager2 and Manager3 can approve the batches created by User2. In case you want to restrict Manager3 to approve the batches created by User1 and User2, do no use *ALL as secured users while setting up approved by user Manager3, rather it is advisable to list the specific list of secured users under Manager3.
NOTE: Specifying *ALL as secured users while setting up approved by user Manager3 will imply that Manager3 can approve all the batches created by all:
Users - User1, User2
Managers - Manager1, Manager2, Manager3 (himself)
If you may not want Manager3 to approve his own batches but rest all for everyone else, it would be required to list all the secured users one by one and not *ALL.
Answer 14: This behavior appears to be related to the caching of security records on the JAS server when report is submitted via report interconnect from interactive application. The issue is being currently investigated by development under Bug 16294479. While the issue is reviewed by development you may use one of the following workarounds:
For more information, you may refer to Document 789853.1 E1: SEC: Random Erroneous Message of "You are Not Authorized to Run this Report" upon Submitting a UBE Report From Interactive Application.
Answer 15: Please note that the Batch Review Security functionality is only applicable to restricting unauthorized users from viewing batches other than their own in the General Journal Review program (P0011). It does not apply to other JDE applications where the transactions are entered or viewed. You may like to setup relevant Row or Application Security in order to restrict access to other related programs.
Answer 16: When a user is set up as secured, the user is restricted from (unable to perform) both the approval and the posting of a batch. This remains true even if an approved user approves a batch - the secured user will not be able to post the batch that is in "approved" status.
Answer 17: There is no setting to prevent posted batches from being changed. When a posted batch is changed, the batch will show as unposted and will need to be posted once again. Posting of batches can be restricted through batch approval and post security.