Tuesday, February 10, 2009

Backward scheduling is the calculation of deadline dates: the arrival time at the customer site is calculated as the earliest possible goods receipt time at the customers unloading point on the requested delivery date. All four of the delivery and transportation scheduling lead times are subtracted from the customer's requested delivery date to determine if this date can be met.

The transit time, loading time, and pick/pack time are subtracted from the customer’s requested delivery date to calculate the required material availability date.

The system calculates backward scheduling as follows:

Requested delivery date minus transit time = Goods issue date
Goods issue date minus loading time = Loading date
Loading date minus transportation lead time = Transportation scheduling date
Loading date minus pick/pack time = Material availability date

By default, the system will calculate delivery dates the closest day, taking into consideration the working days of the shipping point and a rounding profile. In this case the system assumes a 24 hour work day and lead times can be entered in days up to 2 decimal points. This is referred to as daily scheduling.

Precise scheduling calculated down to the day, hour and minute is supported. This allows the scheduling of a delivery within a single day. It is activated by maintaining the working hours for a particular shipping point.

Backward scheduling is always carried out first. If the material availability date or transportation scheduling date is calculated to be in the past, the system must then use forward scheduling.

Forward scheduling is also done if no product is available on the material availability date calculated by backward scheduling. The system does an availability check to determine the first possible date when product will be available. This new material availability date forms the starting point for scheduling the remaining activities. The loading time, pick/pack time, transit time, and transportation lead time are added to the new material availability date to calculate the confirmed delivery date.

The SAP authorization concept is based upon the logical relationship between a user ID and the range of system authorizations with which it can be associated. The architecture of the authorization system is based upon the utilization of several individuals but related logical components: Profiles, Objects, Fields, and Authorizations. The user ID refers exclusively to profiles. Each profile grants a set of specific system access authorizations to user. Figure 2 illustrates the hierarchical authorization concept in SAP.

Figure 2

Composite profiles refer to the various employee roles available in the corporation (for instance: Purchasing / Receiving Clerk or Accounts Agent). As the name suggests, composite profiles may contain multiple user IDs necessary to perform all the business operations associated with a particular role. A composite profile may encapsulate another composite profile(s). In practice, a model composite profile should be recognized for each possible role in the organization, which may be used to produce hybrid composite profiles. The over-existence of the hybrids can defy the very purpose of composite profiles and they should be created only when specific needs arise.

User ids allow access to SAP applications. Each user must have a corresponding profile specifically assigned. In many situations, multiple composite profiles can be assigned to a user ID, depending on the role(s) an individual user is responsible for, in the business processes.

Authorizations are the key building blocks of SAP security. Authorization is the process of assigning values to fields present in authorization objects. In SAP, access to all system functionality is achieved through a complex array of authorizations. Sometimes users find that they lack the necessary authorizations to perform a certain function in the system, in which case the message: "You are not authorized..." is displayed at the bottom of the screen.

An authorization process may ask for second associated authorization process which in turn asks for third and so on. For example, the task of paying a vendor invoice may require 10 different authorizations.

What are the checks that the SAP authorization tool performs when a TCODE is executed in order to ensure authorization of that user?

EXPERT RESPONSE

When initiating a transaction, a system program performs a series of checks to ensure the user is authorized.

1. The program checks whether the transaction code exists in table TSTC.

2. The program checks whether the transaction code is locked by the administrator (transaction code SM01).

3. The program checks whether the user has the authority to start the transaction. Authorization object S_TCODE (transaction start) contains the authorization field TCD (transaction code). The user must have the appropriate authorization for the transaction code to be started (for example, FK01, Create Vendor).

4. The program checks whether an authorization object is assigned to the transaction code. If this is the case, the program checks whether the user has an authorization for this authorization object. The transaction code/authorization object assignment is stored in table TSTCA.
Note: An SAP program controls steps 1 through 4. It displays an automatic message to the user if an authorization attempt fails in the step.

5. The system performs authorization checks in the ABAP program using the ABAP statement AUTHORITY-CHECK.

I want to get a list of all transactions used per user in a specific time period. Basically I’m looking for a list of all users logged in SAP and the details of the tcodes they used. Is there any standard report or tcode available to view this info?

EXPERT RESPONSE

There is no standard transaction. The information is available for configurable time periods using transaction ST05N but it is not organized to readily provide a report of users and transactions. Also the information available summarizes a user’s use of a transaction. There will be one entry (with count data) per user per time period. Daily, weekly and monthly summaries can be created and they are stored for configurable durations.
The information is summarized into a cluster table called MONI based on the STAT files that are written in the file system and regularly refreshed. MONI cannot be queried via SE16 etc., but SAP delivers a number of function modules that retrieve data from these tables.

It is also possible to configure audit logging via SM19 and read the log files via SM20. This will provide more detail but it also introduces new file management issues and requires a change to system settings.

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.

This is a preview of Authorization Check:

My admin user ID has been locked out. Is there a table I can update in Oracle to reset the flag and enable myself to log in?

EXPERT RESPONSE

Select all entries of table USR02 where ‘UFLAG’=128. These users are locked by reason of incorrect logons. ‘UFLAG’=64 will give you the users that are blocked by Administrator. Set ‘UFLAG’ to 0, to unlock your account.

SAP Authorization Concept

The SAP authorization concept is based upon the logical relationship between a user ID and the range of system authorizations with which it can be associated. The architecture of the authorization system is based upon the utilization of several individuals but related logical components: Profiles, Objects, Fields, and Authorizations. The user ID refers exclusively to profiles. Each profile grants a set of specific system access authorizations to user.

Composite Profiles

Composite profiles refer to the various employee roles available in the corporation (for instance: Purchasing / Receiving Clerk or Accounts Agent). As the name suggests, composite profiles may contain multiple user IDs necessary to perform all the business operations associated with a particular role. A composite profile may encapsulate another composite profile(s). In practice, a model composite profile should be recognized for each possible role in the organization, which may be used to produce hybrid composite profiles. The over-existence of the hybrids can defy the very purpose of composite profiles and they should be created only when specific needs arise.

User Ids

User ids allow access to SAP applications. Each user must have a corresponding profile specifically assigned. In many situations, multiple composite profiles can be assigned to a user ID, depending on the role(s) an individual user is responsible for, in the business processes.

Authorizations

Authorizations are the key building blocks of SAP security. Authorization is the process of assigning values to fields present in authorization objects. In SAP, access to all system functionality is achieved through a complex array of authorizations. Sometimes users find that they lack the necessary authorizations to perform a certain function in the system, in which case the message: “You are not authorized…” is displayed at the bottom of the screen.

An authorization process may ask for second associated authorization process which in turn asks for third and so on. For example, the task of paying a vendor invoice may require 10 different authorizations.

;;