SAP Library - Find your answers

Question: With the upgrade version to 4.7 regular transactions, do not work the
same way anymore.

Example transaction VL10H on the Tab ‘General Data’ there is column
named OriginDoc. When you click on one of these fields, it calls the
transaction VA03 (In version 4.6C) but now it is calls VA02 (In Version
4.7).

Why and how can I fix that without giving new roles with transactions
they did not have before and that used to run in the background without
requesting any S_TCODE check?

I have many requests for this kind of problem but for different roles
calling different S_TCODE. If I find a way to fix, one I will know for
all the other roles that call other S_TCODE’s.

Someone told me I could use SE97 to skip S_TCODE check BUT! What if the
transaction really require another transaction to work I do not want to
skip it otherwise we will have another kind of problem? Or I am wrong.

Please help

Nancy

Answer:
Sorry I did not find the one I posted yesterday and I thought I did not saved it.

Sorry for the duplicate of S_TCODE check after upgrade to 4.7

Nancy

Answer:
Dear Nancy,

In higher releases of SAP they are cleaning up their navigation paths. Upgrading, when you business process used a path which has changed (it became stricter to click on), does not mean that the process is any different.

You can call anything what you want. E.g. You can use SE97 to MAINTAIN the check on the CALLED tcode based on which tcode is CALLING it. But if the user can switch their sy-tcode, then the relationship changes. Take a look at table TCDCOUPLES.

SAP also provides other confusing messages though, which might be the case here. SU53 says "no auth tcode" ? But this may be caused by your having "BACK"ed (the ESC or OK problem) or the abap didn´t react sufficiently to the check and met a second auth fail, but gave you a message from either the one, or the other and a SU53 from the last check failed... i.e. the last one before '/nsu53'... not necessarily the one which gave you a "message" or caused your navigation path to change.

The change of the called transaction you mentioned (i.e. from VA03 -> VA02) may also be having an implication based on an application auth object check at tcode start, and not the tcode itself. Check SE93 for VA02.

For this you need to look beyond the tcode and compensate for SAP´s max-confusion-strategy. SU53, PFCG, ST01 and the SoD tools loitering around SAP are fully integrated into this strategy.

Kind regards,
Verne

Answer:
The only thing I found in the table TCDCOUPLES is an entry for
TCODE CALLED
VL10H VA03
VL10 VA02

But I am really in VL10H and I keeps having the message
You are not authorize to use the transaction VA02 !!!

I went in SE97 I created a list of called transactions for VL10H
Do not check VA02
Check Warning VA03
Do I have something else to do after what I did or when I use the role everything will work whitout any other configation.

I really need to know how to configure VL10H to call VA03 instead of VA02. Even with the table TCDCOUPLES or SE97 I am not able to change this setting !!!!

Need help
Nancy

Answer:
You will need to,
1. Call SAP and report the problem, or
2. Search on OSS for a fix
3. Debug the code and see if it is configurable in a table ( probably is not and TDCOUPLES has nothing to do with your want, It must be in the code).

Answer:
The last person who called SAP got 335277 - VL10: VA03 instead of VA02 in display of orders

You will need to work together with your developer and application person for the area.

An afterthought: That is also why, when you have outsourced your development work and application consulting, you will need to get yourself a Miles-and-More card and learn at least one exotic foreign language.

The following actions are subject to authorization checks that are performed

before the start of a program or table maintenance and which the SAP

applications cannot avoid:

* Starting SAP transactions (authorization object S_TCODE)

* starting reports (authorization object S_PROGRAM)

* Calling RFC function modules (authorization object S_RFC)

* Table maintenance with generic tools (S_TABU_DIS)

The authorization objects S_TCODE, S_PROGRAM, S_RFC, and S_TABU_DIS

are standard SAP provided.

Creating a new authorization object is not in the scope of ABAP developer. It will

be taken care by SAP BASIS team.

1. Open two sessions

2. Execute transaction ST01 in one of the sessions

3. Select the authorisation checkbox, note the other traces you can perform (SQL, RFC, Table Buffer etc)

4. Click the ‘Trace On’ button

5. Within your other session execte the transaction/report you want to trace or get the user in question to do it

6. Return to the session where you turned the trace on and click on ‘Trace Off’ otherwise it will continue to record all athorisation checks

7. Click on the ‘Analysis’ button

8. Enter appropriate data into selection screen such as Username, type of trace records (i.e. Authorization check)

9. Click on the Execute button.

10. Report displaying trace results will now be displayed

Question: If there is a message in SU53 saying "T-DV76526201 Exists in user buffer" for the role T-DV76526201, and then below I would find the list of the transaction codes affected, does that mean that there was an error or is it just an informational message?

Are all messages appearing in SU53 just error messages or even infomational messages?

Answer:
SU53 records the last authorisation failure for a user. The first block shows the system's authorisation requirement and the list below shows the authorisations present for that object for a particular user.

Answer:
I have seen the message you are talking about. The SU53 actually states something about an authorization existing in the user buffer but it still fails. I have found this is a throwback to pre-4.5 where the user must log off and back on again and it will usually work then. give it a shot.

For SD material Determination you can create a Substitution reason and on the Strategy field, the following info. is available:

Product selection in the background is performed on the basis of the availability check.

We want to have the material determination only in case on material shortage. We expect the Substitution reason to give us this functionallity. It does not hovever take the availabilty into account before substitution.

We thought the worse case is to create a ABAP which is linked to the "requirement" field in the Procedure (OV13).

Has anyone had the same requirement? Is this a bug or just incorrectly documented?

I also encountered this abnormally recently using material determination. In order to combat the problem, the first product substitution should be for the original material. I've illustrated this below:

Original Product: ABC
Substitutes: DEF, XYZ

In order to perform product substitution ONLY in the case of ATP failure for product ABC, structure the Material Determination record as follows:

Material Entered: ABC Substitutes: ABC
DEF
XYZ

There seems to be a devaition at availability check and or on a conceptual note still.

Availability check can be configured both at requiremnt class and at the schedule line categories level.

Whilst the availabilty check at the requirement class level via global and mandatory configuration the schedule line catgry availability check deals with the order.

It is mandatory that the reqmnt class is flagged off for avlblty check and the schdelu line cat need not be.

The following are the mandatory for Availability check to happen--

1. Must be swithced on at the requirment class level and at the schedule line level.

2. Reqmnt type must exist by which a requiremnt class can be found

3. There must exist a plant and is defined

4.Checking group must be defined in Material Master records(it controls whthr the system is to create individual or collective reqmnt)

A combination of checking gropup and checking rule will determine the scope of availbaility check.

How to Check Missing Authorisation for User

How to check the missing authorisation for the user not having the option "/nsu53 ?"

You can use the following procedures to determine which authorizations a user requires to carry out a transaction:

You can use Trace function, ST01, you can trace the user activity and from the log you can see the authorization missing.

Start an authorization trace using the ST01 transaction and carry out the transaction with a user who has full authorizations. On the basis of the trace, you can see which authorizations were checked.

This procedure generally works well. However, sometimes the result is very surprising because certain programs can and do ignore some authorization checks by using preliminary checks and buffered results. In such cases, these methods are not very effective. You can recognize these cases because certain fields of the corresponding programs are specified with * or DUMMY at some point of the authorization check.

Analyzing authorization problems in an unknown program

The most frequently used method to analyze authorization problems in an unknown program involves you setting the Debugger breakpoints to the AUTHORITY-CHECK and MESSAGE commands. Then execute the program and analyze its behavior.

Determining all the authorizations a user has for an authorization object

When troubleshooting, it is often helpful to find out all the authorizations a specified user has for a specific authorization object. A simple method of reading these authorizations as raw data from the user master record is to execute the GET_AUTH_VALUES function module in the SUSR function group. Use the SE37 transaction or SE80 in test mode to do so. The result table is not formatted for output, but is very compact and easy to understand for authorization experts.

Analyzing an authorization problem that occurs for only one user

It is often the case that a certain authorization problem occurs for only one specific user. This kind of authorization problem generally affects users with no Debugging authorization. If you want to assign a user Debugging authorization without changing the HR authorizations, you can add the S_A.DEVELOP authorization profile (if available) to the user’s authorization profiles. In production systems, note that changes such as these to authorizations enable users (with relevant knowledge of the development environment) to access any system data easily (especially in other clients).

SAP standard does not do an availability check on the quotation, as it is not a definite order, usually just a pricing quote.

When it is converted to an order, the first availability check is carried out, as well as credit checks. The system will check stock in the plant, plus what is contained in the availability checking rule (scope of check) eg: can add POs for replenishment, purchase reqs, different planned orders, and subtract sales orders, deliveries etc already created against that material in that plant (and possibly Storage location).

If there is enough stock in the plant/SLoc, the system will give you a confirmed date, or give you a date based on the production time or purchasing time from the material master. The date the system proposes is based on the customer's requested delivery date.

SAP first backward schedules looking at the required delivery date, less transportation time, less transportation lead time, less pick and pack time, less production/purchase time if applicable. If the date it calculates is equal or later than today’s date, then it will confirm the customer’s required date. If it falls in the past, SAP will then forward schedule for today’s date, plus the times listed above to get the date when the customer can actually have it.

ATP is the single most complex part of the SD module, depending upon how PP and MRP is set up.

MRP works semi-separately, depending on how it is set up. Basically, MRP looks at the demand on the plant, and if it the stock does not meet expected sales orders and deliveries, it will create a purchase requisition (outside purchase) or requirement or planned order (for production) to cover the shortfall. When MRP is started, it will turn the PR into a PO or the requirement into a production order.

The following actions are subject to authorization checks that are performed
before the start of a program or table maintenance and which the SAP
applications cannot avoid:

* Starting SAP transactions (authorization object S_TCODE)

* Starting reports (authorization object S_PROGRAM)

* Calling RFC function modules (authorization object S_RFC)

* Table maintenance with generic tools (S_TABU_DIS)

The authorization objects S_TCODE, S_PROGRAM, S_RFC, and S_TABU_DIS
are standard SAP provided.
Creating a new authorization object is not in the scope of ABAP developer. It will
be taken care by SAP BASIS team.

How to check the missing authorisation for the user not having the option "/nsu53 ?"

You can use the following procedures to determine which authorizations a user requires to carry out a transaction:

You can use Trace function, ST01, you can trace the user activity and from the log you can see the authorization missing.

Start an authorization trace using the ST01 transaction and carry out the transaction with a user who has full authorizations. On the basis of the trace, you can see which authorizations were checked.

This procedure generally works well. However, sometimes the result is very surprising because certain programs can and do ignore some authorization checks by using preliminary checks and buffered results. In such cases, these methods are not very effective. You can recognize these cases because certain fields of the corresponding programs are specified with * or DUMMY at some point of the authorization check.

Analyzing authorization problems in an unknown program

The most frequently used method to analyze authorization problems in an unknown program involves you setting the Debugger breakpoints to the AUTHORITY-CHECK and MESSAGE commands. Then execute the program and analyze its behavior.

Determining all the authorizations a user has for an authorization object

When troubleshooting, it is often helpful to find out all the authorizations a specified user has for a specific authorization object. A simple method of reading these authorizations as raw data from the user master record is to execute the GET_AUTH_VALUES function module in the SUSR function group. Use the SE37 transaction or SE80 in test mode to do so. The result table is not formatted for output, but is very compact and easy to understand for authorization experts.

Analyzing an authorization problem that occurs for only one user

It is often the case that a certain authorization problem occurs for only one specific user. This kind of authorization problem generally affects users with no Debugging authorization. If you want to assign a user Debugging authorization without changing the HR authorizations, you can add the S_A.DEVELOP authorization profile (if available) to the user’s authorization profiles. In production systems, note that changes such as these to authorizations enable users (with relevant knowledge of the development environment) to access any system data easily (especially in other clients).

1) How do we know if Central User Administration (CUA) is used in a system?
You can quickly run transaction SU01 and see if the "Systems" tab is available. If it is then CUA has been configured. Well there is another way to see whether CUA is used. Run transaction code SCUA to see if there are any distribution models defined. Run transaction code SCUL to see to view logs that are generated by CUA & if you have logged into a child system, then goto transaction code SU01 and see, there will be no CREATE activity.





2) How to find derived roles under the master roles

1) Goto transaction SE16
2) Enter the table name : agr_define
3) Enter the master role in the second role field ( this field is in the second row) and execute
4) Then you will see the derived roles based on the master roles

You can quickly run transaction SU01 and see if the "Systems" tab is available. If it is then CUA has been configured. Well there is another way to see whether CUA is used. Run transaction code SCUA to see if there are any distribution models defined. Run transaction code SCUL to see to view logs that are generated by CUA & if you have logged into a child system, then goto transaction code SU01 and see, there will be no CREATE activity.

You have to open a message in component XX-SER-TCC to find out if your installation is scheduled for a Go-Live check which is conducted by SAP and it’s partners.
Go-Live Functional Upgrade Analysis – ideally 6 months before Golive – basically checks your hardware requirement , will it be able to accommodate the increase in the functionalities caused by the Go-Live, also some parameter recommendations to fine-tune your system.

Go-Live Functional Upgrade Verification – This is normally 2 months after the Go-live which is to see e’thing is fine after the upgrade.

Then you have normal Earlywatch session , each installation is entitled for 2 free earlywatch session in a year, in this performance tuning is done for your system, hardware,memory, I/0 bottlenecks are identified.

Reports of all these sessions carried out by SAP is then sent to you in form a MS-Word document and you can follow the guidelines mentioned and call up SAP or mail the person who has done the session for you for any clarifications.
Usually once a session is scheduled.

SAP will contact you to open the connections for them, so that they can prepare the system before the actual session takes place , in which they see , if SDCC version is good enough so that they can download the data from your system into their internal system on which they carry out the analysis, see if SAPOSCOL is running and enough history data is there in ST03n for them to carry out reasonable analysis. If e’thing is set a download is scheduled on your system using SDCC for a day prior to the actual session , and on the day of the session you open the connections for them again and provide them with userid and password normally it is earlywatch in 066 client.

To check one's own Background Job's go to the TCode "SMX"

Keyword: SAP HR
Title : Time-Dependency of the Authorization Check

Prerequisites

Procedure

1. Choose Applicant master data
® Initial data entry.

The Initial Entry of Basic Data screen appears.

2. Enter data in the required fields, and choose Edit
® Check ex-app./ex-ee.

Result