F110 - S_BTCH_ADM

[Former Member]

Hi All,

Some of our users are facing an issue when using tcode F110. The missing authorization (SU53 screen) indicates S_BTCH_ADM 'Y" is required. We are hesistant assigning this object because of the sensitive nature. Please advise. Thank you

Regards

Vijaya

[Former Member]

Running a trace will be helpful. SU53 is only picking up the last missed authorization when SAP is desperately trying to run the tcode

You are correct, you do not need batch admin Y access for this object.

[jurjen_heeck]

Another investigation method (as the trace might also give false indications in some transactions) is to create a temporary bugfix role with S_BTCH_ADM and assign it to the user. In this temporary role you add all missing objects and once the process runs smoothly you can take away S_BTCH_ADM and see if still works.

[Former Member]

>

> Another investigation method (as the trace might also give false indications in some transactions) is to create a temporary bugfix role with S_BTCH_ADM and assign it to the user.

That would be helpfull to be able to use SU53 a second time => to evaluate the last failed authority check immediately prior to the S_BTCH_ADM check.

But in this case (from a trace) you only need to look once at how the authority-check is performed in the job scheduler and you understand it forever...

https://forums.sdn.sap.com/search.jspa?threadID=&q=S_BTCH_ADMANDSU53&objID=f208&dateRange=all&numResults=15&rankBy=10001

Basically, S_BTCH_ADM is an "override" for S_BTCH_JOB. Probably S_BTCH_JOB job_action "RELE" is missing.

Cheers,

Julius

[jurjen_heeck]

> But in this case (from a trace) you only need to look once at how the authority-check is performed in the job scheduler and you understand it forever...

Agreed. I pointed out the other way since the trace can sometimes be misleading. Some transactions format/build the screen based on authorizations. Simply granting everything the trace reports as RC <> 0 can lead to very wide authorizations.

That's why I sometimes prefer the trial-and-error method with a bugfixrole.

[Bernhard_SAP]

Hi Vijaya,

my colleagues from FI told me, that:

Since there is no check for vendors, there are 2 authorizations which

are necessary to start the payment run:

1) F_REGU_BUK (company code) and F_REGU_KOA (account type).

2) Basis administration objects S_BTCH_ADM and S_BTCH_JOB.

The program design assumes that 2 different people are responsible for

creating the payment run and for releasing the jobs. Please review the

documentation for object S_BTCH_JOB. In addition, please review the

source code for program SAPF110V via trans SE38; click on Display and

select Edit -> Find using "authority-check". This will provide you with

the authorization objects which are checked in program SAPF110V.

I assume, that there shall be some documentation for that (notes or help.sap.com)....

b.rgds, Bernhard

[former_member248712]

The missing authorization (SU53 screen) indicates S_BTCH_ADM 'Y" is required. We are hesistant assigning this object because of the sensitive nature.

Access to an Auth Object like S_BTCH_ADM, in itself would not become a critical access. SAP Authorization is complex enough to control the critical access.

You are correct, you do not need batch admin Y access for this object.

By default S_BTCH_ADM is a Check/Maintain for F110 with default value 'Y'. S_BTCH_JOB by default has values JOBACTION RELE , JOBGROUP ' ' for the same T-code. This combination alone would not be critical.

AB.

[Former Member]

You do not need S_BTCH_ADM for F110. The SU24 defaults that SAP defines is not always correct. In my SAP version,

ECC 6.0 (Basis 7.0 - support pack 14) the only defaults for F110 are:

F_REGU_BUK

F_REGU_KOA

[former_member248712]

Look at her stmt -

. The missing authorization (SU53 screen) indicates S_BTCH_ADM 'Y" is required.

Which means SAP is checks for this object. May be SAP deactivated in higher versions due changes/replacement in functionality of F110.

AB.

[Former Member]

It might be a surprise to some but SU53 messages are not always reliable. As someone already mentioned, test it out with some test ids with and without the access.

I can say for certain that I have implemented F110 without S_BTCH_ADM in earlier versions of SAP.

[Former Member]

My understanding of this confusion is the way in which SAP builds the default indicator values when testing the application and the way in which the check is coded in these cases (the job scheduler).

The check uses an IF - THEN - ELSE logic for S_BTCH_ADM to override a (prior) failed S_BTCH_JOB check.

As SAP's development systems deem an "unknown" check to be successfull until specifiied for a check (this is different in customer systems - which leads many to believe that adding and removing check indicators from SU24 will add and remove authority-checks....), the developers can then restrict the authority until sy-subrc NE 0 to find out what it needs.

However in these cases in this specific check, if S_BTCH_ADM is restricted before S_BTCH_JOB, then the above approach produces an inconsistency with the logic of the authority-check coding => so (it would appear...) the user needs S_BTCH_ADM to run the tcode but but no authority for S_BTCH_JOB...

This problem then reproduces itself both in SU53 and ST01 once the SU22 / SU24 error has been made.

It is one of those things which you need to know or find on your own (not too difficult), otherwise you simple don't know it.

Cheers,

Julius

[former_member248712]

S_BTCH_ADM is checked when a user try to DELETE a PAYMENT PROPOSAL. This include checking access to S_BTCH_JOB with DELE Access.

AB.

[Former Member]

Hi AB,

Which release and SP are you on?

Is this only from the trace, or did you test it without S_BTCH_ADM but enough S_BTCH_JOB (RELE and DELE)?

Cheers,

Julius

[Former Member]

Well said ...Julius.

[former_member248712]

>

> Hi AB,
> 
> Which release and SP are you on?
> 
> Is this only from the trace, or did you test it without S_BTCH_ADM but enough S_BTCH_JOB (RELE and DELE)?
> 
> Cheers,
> Julius

This is from the ABAP Authority-Check Code.

CALL FUNCTION 'DELETE_PAYMENT_PROPOSAL'

CALL FUNCTION 'BP_JOB_DELETE'

AUTHORITY-CHECK OBJECT 'S_BTCH_JOB' ID 'JOBGROUP' FIELD '*' ID 'JOBACTION' FIELD 'DELE'

PERFORM CHECK_BATCH_ADMIN_PRIVILEGE

AUTHORITY-CHECK OBJECT 'S_BTCH_ADM' ID 'BTCADMIN' FIELD 'Y'

Again this is valid only if the 'Delele Payment Proposal' function is part of F110.

AB.

[Former Member]

Hi AB,

See and how the system reacts to the failed S_BTCH_JOB check by performing the S_BTCH_ADM check... and then reacting, ELSE => S_BTCH_JOB....

Cheers,

Julius

[Former Member]

Thank you all for the valuable inputs. S_BTCH_JOB - RELE solved the problem

Regards

Vijaya

[muhammad_haddad]

Dear All,

Happy New Year!

We have the Payment run process split between two users, the process fails when the second user tries to make a printout that calls two Z transactions (one for sending email to the vendor and the other for sending an email to the user) and the user's SU53 contained the S_BTCH_ADM.

When I ran a trace, I found that S_BTCH_JOB had RC=0 while still S_BTCH_ADM had RC=12, and I got several authorization objects with other RC<>0,i.e. S_USER_GRP, S_OC_SEND and S_OC_DOC.

After giving all authorizations one by one, the process was completed successfully and the print job was sent to SOST.

I then deactivated the authorization objects (S_BTCH_ADM, S_USER_GRP, S_OC_DOC) one by one until I found that the one that worked was S_OC_SEND, although the rest of objects are still returning NON ZERO RCs.

Despite the fact that it worked, can someone explain how and why it worked with activating S_OC_SEND however it was called after the S_BTCH_ADM and S_USER_GRP (which both had RC<>0).