R09801 - Setting batches on F0011 not belonging to users MCU

johndanter

johndanter

Legendary Poster
Hi List,

I am on a multi company implementation of E1 and we use Row Security to control what a user sees/touches.

I have a problem with R09801 whereby certain users are running R09801 for a 'range' of batches on F0011.

F0011 doesn't have MCU but F0911 does. So the R09801 is flagging the F0011 before trying to process the F0911 and then obviously the F0911 batches isn't posted due to Row Security.

I've looked at the UBE and even if I hard code MCU into the various VERS of R09801 this problem still exists.

Now in an ideal world, they should only be posting batches that belong to their MCU, but how do you guys govern this kind of thing?
Do you have issues with your R09801 posters?

If R09801 updated F0011 AFTER trying to processes the F0911, there may not be an issue. Are there any ESUs to address this?

Thanks

John
 
Last edited:
John,

We have a similar/same issue. We have a user who has access to one specific company's cost centre and who runs a version of R09801, via a row exit, that picks up all unposted batches. Sometimes when the user runs the R09801 it picks up batches which contain cost centres to which they do not have any access.

If the batch contains only cost centres to which they do not have any access, the batch header is marked posted and the report says there were no F0911 records for the batch. The batch header t6hen needs to be revised and set to approved, before the batch can be posted by a user who has access to all the cost centres in the batch.

If the batch contains some transactions which contain only cost centres to which they do not have any access, and they have access to all the cost centre in all the other transactions, then the report show posted batches and the batch header is marked as posted, but not all the transactions in the batch are posted.

If the batch contains transactions which contain some cost centres to which they do not have any access, the batch will not post and reports "out of balance" issues. This is rare.

There is no fix for this, of which I am aware. I do not believe that a fix for this would be an easy thing to do.

Another, semi-related, issue we have is this:

Our Cost Centre security is set up with view and change access but without delete access for most users. A problem arises when a user without delete access to Cost Centre security deletes a transaction, only part of the transaction is deleted – leaving orphan rows that can cause problems in day to day activities, such as the batch cannot be posted.

To resolve this I have recommended the following options, one of which have been taken up, this we still have the same issue:

"There needs to be education that such users should not delete transactions and when transactions need to be deleted, this should be done by a user who has delete access to the Cost Centres involved. In addition, it should be seriously considered to remove the delete Application Action for all such users. This could be difficult to accomplish, as Cost Centre security is applied at the user level, but Application Action security is applied at the role level. Another option is to allow delete access to the Cost Centres, but this would be an audit issue."
 
A few solutions. Create custom posting versions that call the specific ranges as required. Restrict users to only their secured posting versions. Another solution, remove posting from their default login and create a specific role that only they use ONLY for posting and this role can allow all postings without row security.

Lastly, you may need to configure batch approval and post security so that you can control postings and eliminate this issue.
 
rsvconsulting,

Create custom posting versions that call the specific ranges as required. Restrict users to only their secured posting versions.

If I understand your suggestion properly, I do not believe that is possible, without modifying the R09801, as the only variables available for data selection are those in the F0011 which do not include the MCU. If you are referring to batch number ranges, there is no guarantee that there will not be a batch that would cause problems with the range. Using custom batch types, I believe. would also be out of the question as the posting process is different depending on the batch type.

remove posting from their default login and create a specific role that only they use ONLY for posting and this role can allow all postings without row security.

This may work, but involves setting up roles in a way that is mutually exclusive and switching roles, or possibly choosing roles at login. You do not want a user to run the R09801 when access to cost centres is limited, and you don't want users doing their "day jobs" with access to all cost centre. In addition any security could not be applied at the user level as it would take precedence over that applied to the roles. I would consider this a work-a-round.

you may need to configure batch approval and post security so that you can control postings and eliminate this issue.

I'm not sure that this would work. I believe that batch approval and post security only specifies that a batch must be approved before it is posted, and who can approve whose batches. I doubt it would not effect the posting of batches that contain cost centres to which the user does not have access.
 
All three will work.

Create custom posting versions that call the specific ranges as required. Restrict users to only their secured posting versions. ----- in the custom version you select by USER ID so only batches created by the user or other users in the pool of selected users will be in the allowable batched for posting.

Remove posting from their default login and create a specific role that only they use ONLY for posting and this role can allow all postings without row security. ---- To meet the requirement, users will have to log in with the role for Posting. It will work if configured properly and while it may be a work around, it will be vanilla out of the box without any customization.

You may need to configure batch approval and post security so that you can control postings and eliminate this issue. ---- Batches would require approval and those batches would be approved by a user who DOES HAVE access to all MCU, such as a Manager.
 
We had a similiar situation and wound up implementing batch approval / posting security. It's set so that user1 can post for user2 & user3, and user 4 can post for user 5. You're right that it doesn't have any effect if business units are included in the batch that the posting user doesn't have rights to. So we made a rule that the posting user had to have at least as much BU security as the person who entered it. We had our row security as separate roles so it was pretty easy to check when setting up / changing users.

Then we took away their ability to run the R09801 directly and forced them to go into P0011 and select the batches to post. They only see those that they have rights to, so it wasn't too much effort just to take a row exit to post.

There is still the odd batch that slips through, but that's what integrity reports are for, and you're only dealing with one batch instead of having to reset the whole population.
 
rsvconsulting,

Thanks for the further explanation - especially on the first suggestion - I did not understand it properly. The addition of User ID in the data selection was the missing piece.

The important point your further explanation highlights is that the poster needs to have greater cost centre access than the batch user ID.

There are a couple of other complications that probably need to be considered. The poster would also need to have access to accounts used by the automated entries created by the posting process. Additionally the possibility exists of another user, with different cost centre access, adding or changing transactions in the batch so that cost centres are included to which the batch user ID and the poster do not have access. In most circumstances this would be rare.
 
Thanks Peter, our collaboration is excellent! Thank you for your feedback.

I hope our commentary and solutioning has helped the poster, johndanter.

All the best! Al M.
 
I hope our commentary and solutioning has helped the poster, johndanter.

Hi, I've certainly passed it on and we have a meeting on this today :) So I'll let you know. Thanks to everyone for their posts :)
 
Last edited:
Quick question

How would the User ID approach for batches generated by the over night scheduler User Id?

Create specific scheduled IDs i guess?
 
Those batches created by job sched would require approval of the manager in order to be posted.
 
John,

If you have to have the batches approved, the poster can still use a P09801 version with the over night scheduler User Id in the data selection. The requirement for the poster to have the same (if automatic entry accounts are included) or broader (if they aren't) cost centre access, as the over night scheduler User Id, still applies.

Note: Automatic approval and posting may require access to automatic entry accounts if automatic entries are created by the post.
 
Automatic approval means that batches are set to approval status = A upon creation and then the posting program runs on scheduler and posts all batches = A. It is easy and very controllable based upon selection criteria and other aforementioned solutions.
 
I give up :)

We went through all the options and none are suitable....?

We are also hindered by the fact our USER IDs are random. If they were more structured we could ranges for each company, like C100001 - C199999 for Company 1.
We're in a pickle I'd say.
 
My suggestion is to design a solution that at least meets the critical mass test and brings the solution needed.
 
Back
Top