Security on Batch Type in P0911



Active Member
We recently had an issue whereby a user accessed the journal entries created by an Inventory Adjustment via the P0911 and then modified/manipulated the amounts.
This obviously then cause an imbalance between Inventory and the GL as well as highlighted a huge security risk.
We are therefore looking for a way to prevent users accessing transactions that don't originate from the general ledger through this application. Viewing them is one thing but not to be able to change them.

The only way I can possibly think of is to put Batch Type security over the P0911 but was wondering if this could have any unintended consequences or if there is a better way (and no Batch Control is not an option due to the volume of batches).

Any advice is greatly appreciated
Require batch approval?
Add batch approval/post security (if user modifies "Approved" batch it goes back to "Pending")
Column security on P0011/P0911 for batch type? They can run report instead of inquiring?

Thanks for your reply.
Unfortunately Batch Approval (sorry I said Batch Control) is not an option. We have tens of thousands of batches per day and in reality absolutely any batch type can be modified via the P0911 if they want to and some of our subsidiary companies have a single person in the Accounting Department so segregation of duties is always a problem as well as staffing levels to implement batch approval (the problems of living in the real world versus an auditors utopia).
I am not sure what impact column security might have but that might be an option I will look into.
My thoughts were using Row Security on the Batch Type field over the P0911 program. This would only enable them to add/change/delete a G type batch but view only other batch types.
We use the same concept over our address book where users can only add/change certain search types (say add a Vendor address book record but only view an Employees address book) so we know we can do that sort of security and how to do it and I am going to test it extensively but I was hoping there were other options.
Normally you will have batch review application for AR, AP, GL and likewise. It is basically same application - P0011 used with default of different batch type based on which menu it is in.
So, you should avoid change of Batch type in P0011. You can set up Column Security on F0011 ICUT - View - Y, Add - N and Change - N.

P0911 should be restricted based on user.
Another possibility to avoid having to use security: On some of the journal entry creation programs like PO Receipts, you can turn on automatic posting in the processing options. If there is no need to review these entries, set them up to be posted immediately. For other programs like Inventory Adjustment where this processing option does not exist, you can setup the scheduler to pick up these entries to post during the course of the day. Just a suggestion that might work for some.

That is the direction we are testing at the moment. We only have 3 document types whereby anyone should be allowed to add/change/delete the entries via the P0911 program and so we are testing Row Security over the document type field. It's working, but is giving a Commit Fail error when they try and change anything other theses document type (and won't save anything anyone has tried to do) whereas ideally I'd like it to disable the Save button for anything other than these document types (we aren't allowed to customize anything).
In some ways maybe the Commit Fail will highlight who is trying to do what as opposed to just stopping them...

We do use scheduler jobs to post batches but they have to run overnight due to the volume of transactions we have and so users have a chance to do things before the scheduler jobs kick in.

Firstly, the only way to disable the "save" button is via action security on the application, which is an all transactions or none by role/user. So without modification to the P0911 application, I don't think that is practical for you.

Secondly, I agree with Luke (AllOut Security), row security would be your best option, but you may need to include/set up roles as well as application (run or not run) and possibly action (view/add/change/delete by application) security depending on the complications of your user required access (see points 3 and 4 below).

Thirdly, you haven't provided the details of the security you have set up to resolve the problem so diagnoses of the commit fail is not possible (at least for me). I would recommend creating a debug log to capture what is/not happening.

There are a number of things of which you need to be aware and probably already are:

1) Whenever a batch is entered - even if it is for viewing only and no changes are being made, the batch table (F0011) is updated on batch entry (the batch status is changed to "U" - in use) and exit (the batch status is returned to what it was). Therefor any row security should not include the F0011.

2) GL documents need to balance. Some documents (created by other JDE modules/applications - e.g. AP, AR, FA) have the balancing entries automatically created when posting. These automatically created entries have a document type of "AE" and thus care should be taken with security involving the document type. However you said in your opening post when creating this thread that you basically want view access of all GL entries, and add/change/delete access to GL entries created in the P0911. This being the case, I don't think there will be any problem relating to the "AE" document type unless the user posts batches that create them. I would assume that a separate user id is used to run the post program (P09801) on the Scheduler.

3) Without detailed (Auditors Utopia) segregation of duties, the situation may occur when the same user will create documents in other JDE modules/applications (e.g. AP, AR, FA) as well as using the P0911. To handle this situation a combination of multiple roles, application and action security.

4) The solution to your problem will have to fit in with existing security so that existing security is not compromised and so that existing security does not compromise your solution.

5) Beware of unintended consequences to (apparently) unrelated situations - test thoroughly

In view of the foregoing, where points 3 and 4 above do not apply, I would suggest document type row security restricting add/change/delete access set up on only the GL table (F0911) for users who have access to the P0911 application. HOWEVER, any complications caused by the situations mentioned in points 3 and 4 above will probably mean a more extensive solution is required.

Thank you so much for the detailed reply.

The biggest hurdle I face in trying to come up with a solution is remaining within the business requirements of the company as well as satisfying auditors segregation of duties (SoD) requirements.
The specific issue came about at one of our small plants where there is a single Accounting user, which in itself raised SoD issues. We came up with a multitude of reports and reconciliation requirements which management signed off on and thereby satisfied the auditors.

This user has multiple roles within security such a the ability to do Journal Entries, AP, and AR as well as being able to Post his own batches. This ability to post his own batches is required at the month end when they can't wait for the overnight job to post for them (business requirement and very tight closing deadlines).

The AE documents themselves are actually not the ones we had the problem with. We had 2 separate issues.

The first arose when another user did an Inventory Adjustment. This create a batch with balancing journal entries in it (Document Type IA). The accounting user then went into the journal entries that were automatically created by the Inventory Adjustment (through the journal entries program) and changed the amounts but leaving it still in balance. The overnight job kicked in that night and went ahead and posted the batch and no-one knew he had changed the amounts.

The other issue was when the accounting user ran the Frozen Cost update, which also creates a batch of Journal Entries. This is fine as it's part of his job and therefore he needs the ability to add entries into the F0911 file within this document type (IB in this case).
However, once the batch of entries was created, he went into them (again through the journal entry program) and changed the amounts but still leaving them in balance. In this case he needs the ability to add to the F0911 with this document type, but he should never be able to change them.
This is where the problem with Row Security comes in, although we can get round this but it would require a document type by document type detailed solution.

Obviously these are 2 situations whereby the user is doing things he shouldn't by changing amounts, but all the programs he has and the existing security he has all fall within the requirements for the job.

In reality, these issues should have both been picked up by the reports and reconciliations we run to monitor SoD's and this technically is where the failure happened, however their requirement is now to put a system oriented solution in place. One of those "blame the system for allowing it not the user or the failure to monitor the countermeasures" situations.

Trying to convince the powers that be, that if you want the users to do their job, they have to have certain capabilities within the system and you need to utilize the countermeasures we put in place is met with a brick wall of silence.

I have also been testing a custom change I put in place onto the P0911 application in a test environment (just to prove to them that this is what is really required to do what they want) and so far everything is working as I want/need, but whether they will go for it or not I don't know.

The situation you describe falls in point 3 of my previous post:

3) Without detailed (Auditors Utopia) segregation of duties, the situation may occur when the same user will create documents in other JDE modules/applications (e.g. AP, AR, FA) as well as using the P0911. To handle this situation a combination of multiple roles, application and action security.

We have a similar situation where some users have dual access requirements: 1) Normal activities with access to limited accounts, but broader access to applications; and 2) Occasional activities with access to all accounts but limited applications (not much more than P0911). I have set up two roles - one each for the activity sets described. There is no security at the user level. When applying the roles to the user, I include only the normal role in the *ALL roles. This means that the user only uses one role at a time. I think the user has to sign out of JDE to change roles, but I'm not certain about that.

This same method for setting up security may work in your case. There would be two basic access requirements: 1) add all documents types to the F0911 table, but read only access to the P0911 application (disabling the "save" button which you wanted to do) and able to run the post program (R09801); and 2) add/change/delete limited document types in the F0911 table with full unrestricted access to the P0911 application but not able to run the post program (R09801). Create roles for each activity set, and ensure that any security applied at the user level does not compromise either role. When applying the roles to the user include only the role that the user uses most in the *ALL roles (probably the "all documents" role). Also ensure that any other roles included in the *ALL roles do not compromise the security. The other role (probably the "limited documents" role) will not be included in the *ALL roles and as such concurrent use with other roles is not possible.

I hope I've explained this clearly. If you require any clarification or if you have any questions please ask.

That's my AUD 0.02 worth, I hope it helps.
Last edited: