Write access to Infotypes in the past

[former_member1130948]

Hi,

I've got a question and I hope this is the right place to ask 🙂

I've got a structured profile with read access to a few Infotypes except 1 customer IT with write access (which has the time restriction 2).

The read access works, only write access isn't working.

In PFCG is the Infotype with M,R,W registered and also SUIM lists him as W

But if the person who has this structured profile tries to write in the past in PA30 the message "No authority" appears.

We've got this profile because the customer want to see all time slices before the payment case has changed the personal section where he is not responsible for.

We called it "History Profile"

Tests showed us that no Infotype with time restriction 2 is working also standard IT's.

Can anybody give me an tip how I can solve this problem?

The customer says that they need this write access in the past because the files to this payment case comes so late that AUTHSW ADAYS and PLOGI ADAYS are expired, although the time is very high 🙂

Thanks for answering and have a nice day

Lars

[former_member74904]

Hi Lars,

What does your structural profile look like exactly? Have you defined the period indicator (PDATE)?

I have a hard time figuring out whether time constraint "2" has anything to do with your issue.  It seems more likely that the cause for your issue is related to the user not being authorized for the employee in that specific period of time.

Does the custom infotype have the VALDT (access auth.) switch activated?  (You can check this in V_T582A for that infotype).

FYI, this is the F1 help on the VALDT field, which I think pertains to your issue:

To simplify matters, the term 'period of responsibility' will be used in the following. If, during a particular period, a person has one (or more) organizational assignment(s) for which the administrator is responsible according to his/her authorization profile, then we refer to the entire validity period of this(these) organizational assignment(s) as the 'period of responsibility'.
There are three different cases.
1. The period of responsibility begins in the future.
If the administrator has write authorization for the infotype/subtype, this is valid for all infotype records whose validity period is within the period of responsibility. Read authorization is valid for infotype records which do not extend beyond the end of the period of responsibility.
2. The period of responsibility begins before the current date. Its end date is no more than a fixed number of days before the current date
In this case, write or read authorization is valid in all periods. There are no time restrictions on the authorizations of the administrator for the relevant infotype records.

The tolerance period enables the administrator to access infotype records that he/she was previously responsible for even if his period of responsibility has changed. You set up client-specific tolerance periods during the

HR: Authorization Main Switch
transaction.
3. The period of responsibility ends in the past. The end of the period of responsibility ends before the current date even if the tolerance period is taken into account.
In this case, the administrator does not have write authorization. Read authorization applies to infotype records which are not valid beyond the end of the period of responsibility.

[former_member1130948]

Hi D.

1. Thanks for yor answer but I'm not sure if my problem is now solved

2. PDATE... Where do I define it? In T77S0 is no entry and in the profile too

3. The user IS authorized in that time period. Only thing by this profile is, that we modified the end date of the time slice +1 day because some policies (IT0000) are applied to the employee 1 day after he switched the organizational assignment. So we got the fact that the user has 1 Profile for time 01.01. - 30.09 and 1 profile with time 01.01. - 01.10.

That's important for some reports which are accomplished 1 year later or so...

The History Profile is the last one so the write access should be given for example at the 01.02, right?

4. The switch for the custom Infotype is activated in V_T582A

5. Point 3 in the F1 Help is correct I think but I thought if the user has read or write access I can overwrite with my profile?

BTW: Infotypes with time period 3 are working fine...

[former_member74904]

Hi again Lars,

1. We will get there
2. the PDATE field is part of your structural profile. It's the field named Period:
   
   
   However, I don't think the period is causing the issue here.
3. You were saying the user is trying to write a record in the past. When trying to write this custom infotype, what's the record's begin and end date?
   Can you make a screenshot of both of the structural profiles (01.01 / 01.09 & 01.01 / 01.10). I think it will clarify things further.
4. OK. Do you have the possibility to turn off the VALDT switch and see if this results in your desired behavior? Even though this may not be a permanent solution, we can deduce and see whether we're on the right track.
5. If you mean the Maintenance checkbox in the structural profile (see the first red arrow in my screenshot) then no. When it comes to PA infotypes you cannot overwrite read or write access within a structural profile. This maintenance is only meant for PD objects.

Could you rule out this having to do with the standard role authorization by tracing the write action (ST01 or STAUTHTRACE). That way we have further reduced other possibilities being the cause.

[former_member1130948]

Hi D.

sorry for to being late with a reply.. Many things to do 😉

1.  I have to take back my statement for IT's with time period 3 are working. This isn't so but I swear there was a time where it went as planned 🙂

2. PDATE is blank so all time slices are entired

OOSP

HRAUTH

It's only a screenshot from the "history" Profile because there is no active IT0001 so it's no structural authorization with the other profile.

The records begin and end date is the 01.05.2012

Our programmer read something about notes which manipulate the methods CHECK_OM_MAX_LEVEL_AUTH and some other. Perhaps there's an error because while debugging the system says: No authority to write 🙂

Let us first test this out next week and I hope I can report back asap

Thank you in anticipation

Lars

[former_member1130948]

Hi again,

sorry... because of EHP Upgrade everything went longer as planned.

Here you can see P_ORGINCON:

and here the trace:

The OSS Note doesn't changed anything. We thought there would be an improvement in the class named in trace but it wasn't so...

So what next?

It must be possible to write Infotypes within structural authorizations in the past, or not?

Thanx a lot

[former_member74904]

Hi Lars,

I see you are using custom authorization class --> ZCL_HRPAD00AUTH2_CHECK_STD.

can't tell how customized this check actually is, but it does throw in a lot of unknown factors into the mix.

for example, it will be good to know whether method GET_CONTEXT_AUTH_PERIODS was adjusted at all.

[former_member1130948]

Hi D,

this method wasn't adjusted. All original

[Former Member]

Hi Lars,

Bit of a long shot here but... you mentioned there is no active IT0001 for this person. Did you check your settings for non-integrated Persons?

As your structural profile only contains the Person (screenshot from HRAUTH) and not the Org Unit then the system may be rejecting your access based on your settings for authorization switch DFCON (default 1: Evaluate Org Unit / Reject)

Try setting your DFCON switch to 4 (always allow) to see if that grants access. If so then you probably want to switch to 0, 1 or 3 and include the Org Unit in the profile.

Kind regards,

Brent

[former_member1130948]

Hi Brent,

in T77S0 the DFCON Switch is at 1

I clone the PNR to another System, where I can modificate the switch settings without crashing some other Tests

I tell you tomorrow if Number 3 works because the customer wants the "fallback" to orgunit test.

[Former Member]

Hi Lars,

For testing purposes I would advise you to set it to 4 first. Setting it to 0, 1 or 3 will still cause it to reject authorization if the Person has an Org Unit in his IT0001 (because your "history" profile doesn't contain any Org Unit).

Kind regards,

Brent

[former_member1130948]

Hi Brent,

there's no difference between DFCON 1 or 4...

Still the message: Keine Pflegeberechtigung für xxx vorhanden

In the history profile is no Orgunit but the person was found with O-O-S-P because the profile was assigned with O to the higher orgunit and the read access works really fine

The IT0001 has with date 01.08.2012 - 31.12.9999 as S 99999999 and C + O 00000000

In this time period there should be no read/write access but in 01.07.2010 to 31.07.2012

Any other ideas?

Thx

[Former Member]

Hi Lars,

It was worth a shot wasn't it? 😉

Here's a new idea: You can't give people write access to history records by using structural authorizations.

It's probably not what you want to hear but it appears that's how standard time logic works. The standard rule is that you (as the personnel administrator) will get write access to people no longer in your area of responsability if and only if the infotype record you want to write has a full overlap with the calculated period of responsabilty (PoR) for write access as computed by the system.

As you compute the PoR in your structural authorization profile to be 01.07.2010 - 31.07.2012 (HRAUTH screenshot), you will never have a full overlap with any "continuing" records and you will therefore never have write access for the history structural profile.

On the bright side, there's a specific BAdI for time logic (HRPAD00AUTH_TIME) and you can also modify the general authorization check BAdI (HRPAD00AUTH_CHECK, which appears to already be implemented) to get the behaviour you desire.

Best of luck,

Brent

[former_member1130948]

Hi Brent,

thank you very much. I also think that the behaviour I want is only working with modifying the BAdI's you wrote.

I give your answer the predicate helpful

I'll write again if it works