Interesting error, during insert an transaction with PFCG

[Former Member]

Hi everybody!

I find an interesting problem.

I made a test role, and I put a transaction (F-48) in it with PFCG.

After that, in the role, the following objects appears:

F_BKPF_BUK

F_BKPF_BUP

F_BKPF_GSB

F_BKPF_KOA

K_TP_VALU

I see the table USOBT_C (and USOBT) and i realized, that only:

F_BKPF_KOA is in the table (or see in SU24).

I investigate, and find that FBA7 transaction starts the same program than F-48. And FBA7 consist the objects:

F_BKPF_BUK

F_BKPF_BUP

F_BKPF_GSB

F_BKPF_KOA

K_TP_VALU

So, it seems that when I insert the F-48 transaction the PFCG inserts the objects for FBA7

How can it be?

Thanks for the answers.

[sdipanjan]

Are you sure about the Maintain proposals for the Objects to be checked for F-48? From SU24, I can see the following are the Objects which will be pulled into PFCG:

@5B\QMaintained@ F_BKPF_BEK Accounting Document: Account Authorization for Vendors Check YS

@5B\QMaintained@ F_BKPF_BES Accounting Document: Account Authorization for G/L Accounts Check YS

@5B\QMaintained@ F_BKPF_BUK Accounting Document: Authorization for Company Codes Check YS

@5B\QMaintained@ F_BKPF_GSB Accounting Document: Authorization for Business Areas Check YS

@5B\QMaintained@ F_BKPF_KOA Accounting Document: Authorization for Account Types Check YS

@5B\QMaintained@ F_FAGL_LDR General Ledger: Authorization for Ledger Check YS

@5B\QMaintained@ F_FAGL_SEG General Ledger: Authorization for Segment Check YS

Which release you are working and what did you check for the proposals of the objects? The table which gives the details of check proposals is USOBX_C.

Regards,

Dipanjan

[Former Member]

We use SAP 4.6C.

In SU24:

. . . not maintained A_B_ANLKL

. . . not maintained A_B_BWART

. . . not maintained F_BKPF_BEK

. . . not maintained F_BKPF_BUK

. . . Check/maintain F_BKPF_KOA

. . . Check S_DEVELOP

. . . Check S_PRO_AUTH

. . . Check S_TCODE

. . . Check S_WFAR_OBJ

So, just F_BKPF_KOA had to be appeared in PFCG.

USOBX_C:

A_B_ANLKL U

A_B_BWART U

F_BKPF_BEK U

F_BKPF_BUK U

F_BKPF_KOA Y

S_DEVELOP X

S_PRO_AUTH X

S_TCODE X

S_WFAR_OBJ X

You can see, that only F_BKPF_KOA has to be proposed.

And if you change an object check indicator to Check/Maintain in SU24 this object appears in USOBT_X.

[sdipanjan]

Please check the SAP Data in SU24 to find out the changes performed in check proposals for the Tcode. You can get the details in the Tables USOBT_CD and USOBX_CD tables.

Also you may need to check the entries in the table CDPOS. Put the table name USOBX_C in the Table Name field.

It's clear that your SU24 settings for this is not correct.

regards,

Dipanjan

[Former Member]

My guess is that this is neither SAP Data nor Customer Data, but rather Original Data from the special tracing function auth/authorization_trace.

That it is pulling the proposals which are still in "unmaintained" status into PFCG sounds like a bug to me, but hey 46C was quite some time ago. Probably a Check/Maintain indicator for 1 object is enough to send PFCG off looking for everything.

I cannot remember the exact name of the table, but it wasn't USOB* - anything.

Lower down in the alphabet -> USVAL*-something I think.

Cheers,

Julius

[sdipanjan]

>

> I cannot remember the exact name of the table, but it wasn't USOB* - anything.

> Lower down in the alphabet -> USVAL*-something I think.

>

> Cheers,

> Julius

Are u talking about USOTT?

Regards,

Dipanjan

[Former Member]

> > I cannot remember the exact name of the table, but it wasn't USOB* - anything.

> > Lower down in the alphabet -> USVAL*-something I think.

> >

>

> Are u talking about USOTT?

The name is USOB_AUTHVALTRC.

If there is data in there, then it is "Original data" and will be in SU22. You will need to run the steps of SU25 before you will see it in SU24.

But that is irrelevant here, as it does not seem to be related to the problem.

Cheers,

Julius

[Former Member]

A possible explanation for exactly this behaviour would have been in the case of parameter transactions with no SU24 data. These then propose the data from the parameterized (core) transaction.

However in this case it appears that you are not looking in the correct table.

That is one of the buggers with using tables...

Cheers,

Julius

[Former Member]

>

> So, it seems that when I insert the F-48 transaction the PFCG inserts the objects for FBA7
> How can it be?
> Thanks for the answers.

Hi Peter,

This is SAP Standard functionalaity . When you look at SU24 for t-code F-48 and execute, it will say FBA7 as its Original t-code. So it has to pull the Auth objects for FBA7.

It happens all the time when an ABAPER creates a custom t-code for some kind of table maintenance where the original t-code is SM30. I used to see S_TABU_DIS being pulled in the role even though for that custom t-code S_TCODE was the only one in check/maintain. But then when I saw the original t-code on which this Custom t-code was built, i found the other objects that were pulled.

Hope that answers ur question.

[Former Member]

> It happens all the time when an ABAPER creates a custom t-code for some kind of table maintenance where the original t-code is SM30.

Yes, this is correct. But it does not have to pull the authorization proposals for the "original transaction" for which they were traced.

If you maintain them for the parameter transaction then these will be pulled.

That is why a well maintained Su24 is not only usefull, it is also important to help keep your roles in "green" and excessive (e.g. wildcard) authorization values out.

Cheers,

Julius

[Former Member]

>

> >  But it does not have to pull the authorization proposals for the "original transaction" for which they were traced.
> Julius

Hi Julius,

Now wouldn't that we would want ? I think it is better if we have these auth objects as well so that we can maintain it.

For example : I have custom parameter t-code for which original t-code was SM30. So in my case S_TABU_DIS will be pulled and I can now maintain the Authorization group as well for this Custom t-code. So it has two level of Security right. S_TCODE and S_TABU_DIS for Auth group.

But if the Auth object for Original t-code (SM30 in my case ) is not pulled then the only object pulled is S_TCODE where you have the custom t-code.

Help me understanding why is it not better if we have the auth objects for the original t-code pulled as well if the t-code is bulit from it.

[Former Member]

The disadvantage is that the orginal (a.k.a. "core") tcode is often a generic one, like SM30 in your example - so you cannot maintain SU24 to feed granular proposal values such as the authorization group name to PFCG because it will then do so for all transactions using SM30.

For this reason PFCG first looks in the parameter transaction to see whether there are proposals.

It is less error prone to maintain the value once in SU24 for the parameter transaction and keep the authorizations standard and correct each time the transaction is used, than what it is to leave it yellow and expect the authorizations admin to go find the auth group of the table or view in the parameter - namely each time the transaction is used.

Also, because the authorization will be standard, you can optionally set it to "Inactive". This way PFCG will not bother you with the S_TABU_DIS again, and again, and again....

It only requires some discipline in the beginning.

Cheers,

Julius

[Former Member]

>

> The disadvantage is that the orginal (a.k.a. "core") tcode is often a generic one, like SM30 in your example - so you cannot maintain SU24 to feed granular proposal values such as the authorization group name to PFCG because it will then do so for all transactions using SM30.
>  
> It is less error prone to maintain the value once in SU24 for the parameter transaction and keep the authorizations standard and correct each time the transaction is used, than what it is to leave it yellow and expect the authorizations admin to go find the auth group of the table or view in the parameter - namely each time the transaction is used. 
> Cheers,
> Julius

For a parameter transaction the Auth obejcts that are pulled from the core t-code are standard only and once you maintain it they change to Maintained state in PFCG.

It is not in Changed state and until the auth object has Changed status you do not see Yellow trafic light problem.

but i do see advantage of maintaining the proposals for custom t-code itself as you said if we are careful enough to take in to account all the auth objects that this parameter t-code will require which for me I would again get from the original t-code.

[ashley_kenealy]

Hi All,

The link between the two transactions (F-48 and FBA7) is maintained in SE93. Once the relationship is established in SE93, transactions such as PFCG will interrogate the values maintained in SU24 for both transactions in order to populate roles.

F-48 will inherite all authorisations of the underlying transaction (FBA7) that are in "Check/Maintain" status, as well as any SU24 entries that are direct attached to F-48.

Regards

Ashley

Edited by: Ashley Kenealy on Sep 15, 2009 10:36 AM

[Former Member]

> The link between the two transactions (F-48 and FBA7) is maintained in SE93. Once the relationship is established in SE93, transactions such as PFCG will interrogate the values maintained in SU24 for both transactions in order to populate roles.

This is correct - it "interogates" both the transaction's proposals.

> F-48 will inherite all authorisations of the underlying transaction (FBA7) that are in "Check/Maintain" status, as well as any SU24 entries that are direct attached to F-48.

This is not correct. If the parameter transaction has maintained Su24 data, then the original transaction's SU24 data is ignored.

Cheers,

Julius