Logical OR in BW authorizations

Hi,
I am using BW 3.5. and have following authorizations issue:
My cube contains 2 country-related infoobjects, 'sender-country' and 'receiver-country'.
For simplification lets say the cube contains only 3 records:
Sender   Receiver   Amount
DE         FR           100,--
FR         GB            80.--
US         DE            70,--
The user access to this cube must be restricted like this:
User 1 should have access to all DE data, but regardless in which country field the value DE occurs, in other words, its a logical OR. if the value 'DE' appears in either field the record should be displayed. In the example above he would therefore see record 1 and record 3.
Likewise, another user with access to FR should only see record 1 and 2.
To my knowledge the authorizations usually work as a logical AND, that is, if I make both characteristics authorizationrelevant and create 2 roles with:
Role 1:                   
Sender: *                
Receiver: DE
and
Role 2:
Sender: DE
Receiver: *
then it will internally grant * to both sender and receiver which I dont want.
Any ideas how to design this?
Thanks for any insight.
Regards
Udo

Hi Olivier,
Thank you very much for your answer.
Unfortunately it does not work with this approach, or only partly.
I have set up the authorizations the way you mentioned, still I am getting a 'no authorization message' for records that should be accessible now.
On the other hand, the existing roles do work correctly if I put fixed filter values for the countries into the query.
For example a query with SENDER = DE, Reciever = ZZ is accessible, which is correct with the new roles.
However, the scenario does not work if the allowed filter values are retrieved via the authorization variables.
I think this behavious is due to the inability of the query to process logical OR filters.
The authorization variables retrieve the allowed values from the roles.
These roles contain now the allowed value set
Sender = DE, Receiver = *
and
Sender = *, Receiver = DE
These values cannot be applied meaningfully as it would lead to a logical OR in the query select statement which cannot be done.
So I dont see any further solution to this....do you?
Regards
Udo

Similar Messages

  • New Authorizations as a logical combination of other Authorizations

    Wondering if anybody else has encountered the need to create Authorization schemes as a logical combination of other Authorization scheme.
    For example, if I had the following authorization schemes
    Manager
    Supervisor
    User
    I should be able to create something like
    ManagerOrSupervisor
    whose definiton is a logical OR of the Manager and Supervisor Authorization schemes.
    There should be no need to repeat the code/conditions for the new scheme !

    Hi,
    you can use
    WWV_Flow.public_security_checkto check defined authorization schemes. That way you don't have to duplicate your code.
    Patrick
    My APEX Blog: http://www.inside-oracle-apex.com
    The ApexLib Framework: http://apexlib.sourceforge.net
    The APEX Builder Plugin: http://apexplugin.sourceforge.net/ New!

  • Logical Profiles in ISE 1.2.1

    I´m having trouble understanding the Logical Profiles. 
    What I understand from the user guide: http://www.cisco.com/c/en/us/td/docs/security/ise/1-2/user_guide/ise_user_guide/ise_prof_pol.html#58510
    for those to lazy to read: 
    You can use the logical profile in an authorization policy condition to help create an overall network access policy for a category of profiles. You can create a simple condition for authorization, which can be included in the authorization rule. The attribute-value pair that you can use in the authorization condition is the logical profile (attribute) and the name of the logical profile (value), which can be found in the EndPoints systems dictionary.
    so I thought that meant that I can group Different Profiles (Apple Iphone, Ipad, Ipod) together into a logical group e.g. "BYOD_Idevice" and use this logical profile in the Authorization. 
    But I can´t choose this freshly created Logical Group in the Authorization Condition. As for the fact, I can´t choose this logical group ANYWHERE. 
    Leaning back and thinking about it - it somehow makes sense. In the Authorization, you don´t pick Profiles, you choose Identity endpoints. So whats the point about the logical profiles? I was hoping to clean/lean up my authorization rules with them. But for what would I use them else? 
    Or is this a bug in ise 1.2.1? Not sure if I should call tac about this, or if I´m just not getting it :D
    Thanks alot for your help!  

    Nice username! :)
    So yes, you are correct, the logical profiles would allow you to group different type of dynamically profiled devices and then reference that profile in your authorization rules. However, you won't see those logical profiles under the "Identity Group Details" section. You will need to leave that field blank. Instead, you need to look in the "second" condition box: expression > Endpoint > LogicalProfile
    Hope this helps!
    Thank you for rating helpful posts!

  • Migrating Logic and all plug ins from old mac to new mac

    Hi,
    I understand Migration Assistant will bring over all my old files from my Macbook Pro to my new Mac Pro.  My question is, I have Logic Pro 7 and authorization key (USB), my new Mac Pro has Logic Pro 9, can I use all my old music files by just using Migration Assistant?  What about registration or authorization?  What about my 3rd Party Plug ins?  Do I have to re install all of them, or will they come over as well through the Migration?  Anyone with any experience actually doing a similiar migration to mine, all advice or tips would rock.

    some 3rd party plug ins you will have to reauthorize and it can be quite a pain but it does work. im not sure if your old logic files will work though

  • File to idoc scenario . how to create logical system

    logical system asking user authorization what should i do.
    what should be logical for whic we should degine partner profiles
    apoclnt800 or xi7clnt001

    Hi,
    The partner profile to be maintained in we20 (in backend systems -ECC/CRM etc) should be based on logical system for the sender.
    For ex: Src (File) -> PI -> Tgt(ECC)
    In SLD you have created Technical System(TS) and Business System(say BS) for Src. Also a Logical System name (Say LSNAME) is associated with BS.
    In ECC, goto tcode - sale, create a logical system of name LSNAME. Now goto we20 and create a partner profile of name LSNAME. Provide the message type of Idoc in the required place.
    Souvik

  • TOBJ Authorization Object Details

    Hi All,
    I am trying to see the logic of a Z-Authorization object. I can see an entry in the table TOBJ but am wandering about where to see the details for that Z-authorizations.
    Where can i get the details for any authorization objects?
    Please help.
    Thanks!

    Hi ,
    At run time/Debugging  Create a BreakPoint using key word 'authority-check'.
    The Debugger will stop at all those place where Authority check is done.
    See attached screen shot for reference.
    Regards,
    Vikas

  • Authorization LIST  -- OPRM Table

    I would like to know in which table the Authorization LIST is Stored ?
    I have checked through View System Information and as per that it shows - OPRM.
    But when i write a Select Query, it says me Invalid Object ???
    How to store the Authorization list . i want to view the list in data base . otherwise how to use the logic to store the Authorization list  in data . pls give the procedure for storing authorization in data base.
    Regards
    Madhu

    Hello Folks,
    You can export !
    See this blog
    /people/janos.nagy/blog/2010/01/25/exporting--importing-authorization-using-ms-excel-in-sap-b1
    You can also download a sample excel macro for this.
    Regards
    János

  • How to Restrict the users from changing the Default variant of report.

    Hello everybody,
    The requirement is to restrict the users to save and overwrite  the default layout variant (Layout for higher managenet)set for the report, but at the same time they should be able to change and save the other layouts for which they are having access.
    I have written the logic in the program which is working fine for all the scenario when we execute the report. But the logic doesnt work if the user is selecting the layout on the output screen of the report.
    for e.g if the user runs the report using the layout varaint for which he is having the authorization then he gets the all 4 options so he then he can select the layout for which he is not authorized and he can overwrite.
    i have debugged and check as i have found that after the report output is shown all the layout paramater is controllled by the statndard SAP objects.
    Can anyone help me out in this issue.
    Thankyou in advance.
    *to get the default layout variant.
      w_save = 'A'.
      if p_vari is initial.
        clear disvariant.
        disvariant-report = sy-repid.
        w_variant = disvariant.
        call function 'REUSE_ALV_VARIANT_DEFAULT_GET'
          exporting
            i_save     = w_save
          changing
            cs_variant = w_variant
          exceptions
            not_found  = 2.
        if sy-subrc = 0.
          p_vari = w_variant-variant.
        endif.
      endif.
    *logic to check user authorization to change the layout setting.
      if p_vari = c_layout.
        if not sy-uname is initial.
          select single * from agr_users
                  where agr_name = c_role
                  and   uname    = sy-uname.
          if sy-subrc = 0.
            w_save = 'A'.
          else.
            w_save = ' '.
          endif.
        endif.
      endif.
    Regards,
    Satish.

    Hi Maine,
    Thanks for your reply.
    As you mentioned for your own program, you can control the parameter "I_SAVE", when calling "REUSE_ALV_GRID_DISPLAY".
    so already i have use the same logic and control the parameter through I_SAVE and here i am calling method ALV_GRID->SET_TABLE_FOR_FIRST_DISPLAY instead of "REUSE_ALV_GRID_DISPLAY".
    and it works fine when we execute the report but the logic doesnt work when the user tries to change and save the layout variant on the output screen of the report.
    Regards,
    Satish

  • BADI for Address Check in PA30 in ECC6.0

    Hi Friends,
    Is there any BADI for Address Check in PA30 in ECC6.0 similar to what we have in BP transaction in ECC6.0.
    Thanks,
    Pradeep

    check these...
    Enhancement/ Business Add-in            Description
    Enhancement
    PBASRP01                                PA: User exit distributed reporting
    PBAS0002                                PA: Enhancements for Personnel Administration - Menu
    PBAS0001                                PA: Pers.Admin./Recruitment: Default values and checks
    PARA0002                                Enhancement for Calculating Annual Salary; IT0008,14,15
    PARA0001                                Enhancement for Determining the Number of Periods
    HRRPAI01                                User exit for FB HR_ENTRY_DATE and HR_LEAVING_DATE
    HRPC0001                                HR: PC download authorization
    HRPBAS01                                User Exit for HR Master Data
    Business Add-in
    HRPAD00_PREM                            Definition of User Exit for Collective Search Help PREM
    HRPAD00_RECOG_SCREEN                    Employee Recognition Screen
    HRPADUS_PBAS_0001                       Customer Exit for Message handling
    HRPAD_SUBTY_CHECK                       HR: Master Data, Subtype Check
    HR_F4_GET_SUBTYPE                       HR: Entry help for subtypes
    HR_FAST_ACTION_CHECK                    Check fields on the fast entry screen
    HR_INDVAL                               HR: Indirect wage type valuation
    HR_SET_PKGAB
    HRPAYXX_DELETE_PERNR                    BAdI for Reports Deleting Personnel Numbers
    HRPAD00_PAPM                            Definition of User Exit for Collective Search Help PAPM
    HRPAD00_GET_AF_0008                     Additional Fields for Basic Pay Infotype (0008)
    HRPAD00_ENTRY_LEAVE                     HR_ENTRY_DATE and HR_LEAVING_DATE
    HRPAD00_ADRS                            HR: Address formatting
    HRPAD00MGEACTIVATION                    Activation Action BAdI for Global Employees
    HRPAD00INFTY                            Update / Infotype maintenance
    HRPAD00AUTH_TIME                        Time Logic in the PA Authorization Check
    HRPAD00AUTH_RECORD                      Spanish Data Privacy Law: Exit for Recording
    HRPAD00AUTH_CHECK                       HR: Authorization Check
    HRIV_REDUCE_AMOUNT                      Reduction within Indirect Valuation
    No.of Exits:          8
    No.of BADis:         19

  • Attribute categorization in the category modeler - IC WebClient

    Hi,
    in a customer project, I have created customer-specific categorizations in SAP CRM 5.0 (catalog, code groups and codes).
    The first level contains in the category modeler the car brands (e.g. FIAT, BMW, AUDI; they are also assigned as subject codes).
    The second level contains the parts (e.g. seats, enginges; they are also assigned as subject codes).
    The last level contains the specific configuration of the parts in level 2.
    Example:
    Level 1: FIAT
    Level 2: SEATS
    Level 3: LEATHER
    Level 1: BMW
    Level 2: SEATS
    Level 3: LEATHER
    General settings are maintained on the tab General Data:
    Identifier: AUTOMOBILE
    Name: Automobile categories
    Description: Automobile categories
    Status: Draft
    Logical Structure: Attributive categorization
    Authorization Mode: AND combination
    Remark: In the CRM customizing following settings are in subject profile:
    Catalog: Y1 Car brands          Level 1
    Catalog: Y2 Parts               Level 2
    Catalog: Y3 Config               Level 3
    In the category modeler I can’t assign a duplicate entry. What must I do to make attributive categorization?
    Thanx and regards
    Alex

    Hi,
    I think you will have to maintain the same attributes at each level for duplicate selection .
    Main Node if say is Product>subnode>seat--->Leather
    Adjacent Node        Product 2 -->subnode >seat>Leather
    Status release and save (24hrs)
    with this you will be able to select seat and leather in both product categories
    Hope this helps
    Cheers!
    Raj

  • Credit Card Payment at time of SO creation - Basic questions

    Most of our customers pay by credit card at the time of Sales order creation. (80% of times)
    Now sometimes they pickup the order at the same time and sometimes we follow the normal delivery process and ship material to them.
    Now we are not sure what document type or process flow will fit this process.
    Should we be using two different document types/ process to meet this requirement.
    Thought of using standard order type but then as they have already paid at the time of order creation we Dont want to send Invoice at Billing stage
    Shall we use Rush order or cash order for our requirement. (But they dont pickup material all the time, sometime we ship)
    Also if we maintain credit card information at Customer Master level, will it flow down to sales order and Biiling process.
    Thanks in advance.

    Jeet,
    I have worked with over 350 SAP customers over the last 14 years who have implemented the SAP Payment Card Processing business logic.  The majority of them use an integrated solution so that SAP submits the Authorization requests through SAP's Cross Application Payment Card Interface (CA-PCI) during Sales Order Save.  Some of them use external devices\applications to perform the Authorizations outside of SAP and simply use the SAP business logic to record those transactions.
    I would recommend you consider continuing to use the SAP Payment Card Processing business logic with your external Authorization process so that you can take advantage of the GL posting automation that SAP performs when an Invoice is posted to Accounting.  Namely that SAP will CREDIT the Customer AR account and DEBIT the Credit Card Receivable account for the card type used.  This is of great benefit to the Merchant because it eliminates the need for someone to MANUALLY post the payments to clear the open items on the Customer AR account once the Settlement deposit is received.
    Another advantage is that, when researching customer orders in SAP, you'll be able to see the card details that were used for payment.  Just be certain to activate SAP's credit card encryption logic or use a third-party Tokenization solution to secure the data.
    Eric Bushman
    [www.paymetric.com|http://www.paymetric.com]

  • Transaction Variant for a Custom Report

    Hi Folks...
    I am trying to create a transaction variant for a custom report...and i am unable to do it. Have any one tried that before and got it worked..please let me know.
    Thanks in advance.
    Rajeev

    hi,
    i also used a different approach based on the requirement.  this might be helpful to someone:
    requirement: to make one of the parameter fields as display only.  other users should not be allowed to edit this field & make it modifiable again.
    _solution1:_ in the program, assign the parameter field to a modification id and make it protected (screen-input=0). 
    limitation: needs program modification incase there is a future requirement to change the parameter field value.
    solution2: [1]create & save a variant and protect that parameter field. [2] go to SE93 & create a report transaction, put your saved variant in the 'start with variant'. [3] go to SU21 & create an authorization object for controlling the access to the variant. [4] ask your basis to attach this authorization object to the user id responsible for maintaining the variants for that program. [5] add a logic to check the authorization object in your program whenever the user tries to save or delete variants.
    remarks: in production, make sure the authorization object & the update profile are transported.  create also the same variant name as what you have defined in your report transaction code.

  • Concurrent Employment

    We have concurrent employment maintained in our project. I need to develop reports based on PNPCE LDB. I wanted to know major differences between PNP and PNPCE and various pitfalls while using PNPCE LDB.

    hi,
    check the differences between pnp and pnpce in se36 transaction.
    RE SAPDBPNPCE
    Text
    HR Master Data (Incl. Concurrent Employment)
    Purpose
    The PNPCE logical database supports the evaluation of HR master data. It includes the functions of the PNP logical database and offers additional evaluation options. Therefore, you should use the PNPCE logical database instead of the PNP logical database for all new developments.
    The enhanced functionality of PNPCE in comparison to PNP essentially concerns the evaluation of Concurrent Employment, that is the possibility to group evaluate several assignments/personnel numbers of a person. The new events 'GET PERSON' and 'GET GROUP' as well as an enhanced syntax for the INFOTYPES statement (addition AS PERSON TABLE) for the procurement of infotype data enable you to use the new functionality. The use of these new functions is optional. You can run a PNPCE report that does not use the new events and the addition for the INFOTYPES statement in a PNP-compatible session. Since the PNPCE also has an improved selection screen, each report benefits from this even if the report does not use the functions for evaluating Concurrent Employment.
    Prerequisites
    A report that wants to use the PNPCE must enter this in its report attributes under Logical database.
    In addition, the PERNR structure must be declared in the report using the 'TABLES PERNR' statement. You can only use the PERNR structure again in certain circumstances. The use of the 'GET PERNR' event is therefore forbidden. Instead, use the 'GET PERAS' event. Except for the PERNR-PERNR component, all other components of the PERNR structure are no longer filled and have initial values. This kind of programming (with the exception of PERNR-PERNR) therefore not permitted.
    In addition to the 'GET PERAS' event, you can also use the GET PERSON' and 'GET GROUP' events. To be able to use these events, you must declare them using the NODES statement (NODES PERSON', 'NODES GROUP', or. NODES PERAS').
    Explanation of Terms
    If the 'GET PERSON' and 'GET GROUP events and the 'AS PERSON TABLE' addition for the INFOTYPES statement are not used, the report indicates that it does not require the functionality for evaluating Concurrent Employment. In this case, the report runs in a PNP-compatible session. This is referred to as PNP mode in the following documentation. On the other hand, if the report uses the functionality for evaluating Concurrent Employment we refer to CE mode.
    Features
    Process of an Evaluation
    The PNPCE selection screen offers you as standard a range of functions that you can use to restrict the personnel number and person selection. These are discussed in more detail in the following sections. The process is initially as follows regardless of whether the report runs in CE or PNP mode. All available functions and selection conditions leads to the selection of personnel numbers. If you use the sorting function, this set of personnel numbers is then sorted according to the sort criteria you selected. In PNP mode, the GET PERAS event is triggered as a result for each personnel number.
    In CE mode, the persons belonging to the personnel numbers are determined first for all personnel numbers selected. The GET PERSON event is then triggered for each person. The person ID is specified in the OBJID component of the PERSON structure. PERNR_NUM contains the total number of personnel assignments (= personnel numbers) that this person has and the ALL_PERNRS table, which contains a list of these personnel numbers regardless of whether they were actually selected or not. The SELECTED flag is set to X for the personnel numbers selected. The flag is initial for all personnel numbers that are not selected. The PROCESS flag specifies whether the personnel number should be processed in the rest of the process. This flag is set to X by default for the personnel numbers selected. However, the report can set or delete this flag at the GET PERSON event for all personnel numbers. In this way, report and logical database communicate with each other which enables the report to control the rest of the process.
    In the next step, the logical database groups all personnel numbers of a person that are to be processed (that is, all personnel numbers that have the PROCESS flag set). The report can control the type of grouping using the PNPCE_GROUPING_FROM_PAYROLL flag (normal or payroll grouping) and using the PNPGPRSN (grouping reason) and PNPGPVAL (grouping value) parameters of the selection screen. The GET GROUP event is triggered for each group of personnel numbers determined. The GROUPING_REASON and GROUPING_VALUE components contain the grouping reason and grouping value of this group. The number of personnel numbers that belong to this group and that are processed subsequently is in PERNR_NUM. The included ALL_PERNR table contains a list of these personnel numbers with additional information. The SELECTED flag specifies whether the current personnel number was originally selected (flag is set) or was marked by the report as to be processed. GROUPING_BEGDA and GROUPING_ENDDA contain the validity period that the personnel number has for this grouping. The NO_AUTHORITY flag is set if there is insufficient authorization for a personnel number. This personnel number is not processed further. The SORT component defines a standard sort order for the personnel numbers of a group. The report can change this by overwriting the values. In this way, report and logical database communicate with each other, which controls the further processing sequence of the personnel numbers.
    The GET PERAS event is then triggered for all personnel numbers of the group (with the exception of the personnel numbers for which no authorization exists) in the sequence defined by the SORT component (see above). The SELECTED, GROUPING_BEGDA, and GROUPING_ENDDA components have the same meaning here as with the GET GROUP event. The PROCESSED_BEFORE flag specifies whether the personnel number has already been processed once before (it is possible that the personnel number belongs to several groupings and has been therefore been processed several times).
    Sort Order
    You can sort the list of selected personnel numbers using the Sort function in the application toolbar. You can choose to include up to seven fields from infotype 0001 for the sort. Since several data records can exist for infotype 0001 for a personnel number, you also need to specify for period evaluations (not the case for key date evaluations) whether the sort should take place according to the values of the last or of the first data record in the person selection period.
    In PNP mode, the sorted sequence determines exactly the sequence in which the GET PERAS event is called. In CE mode, the sort determines the sequence in which the GET PERSON event is called. The list of persons is created based on the (sorted) sequence of personnel numbers. If only one person exist for each selected personnel number, the sequence of persons corresponds exactly to the sequence of personnel numbers. However, if several selected personnel numbers lead to the same person, only the first personnel number determines the sort sequence of persons. All other personnel numbers only determine the sequence in which the GET PERAS event is subsequently called. Provided that the report does not require the personnel numbers to be resorted by manipulating the SORT component at the GET GROUP event (see above), the GET PERAS event is called for the personnel numbers of a person in the sequence in which the personnel numbers were (originally) sorted.
    Retrieving Infotype Data Records
    As well as triggering the GET PERSON, GET GROUP, and GET PERAS events, the logical database also provides the data records of the infotypes that are requested using the INFOTYPES statement. In the report, you must specify the INFOTYPES statements where the variable declarations are made. You should do this in any case before the first code is entered.
    In principle, there are three types of INFOTYPES statements:
    INFOTYPES nnnn
    The nnnn infotype is provided with the data records of the current personnel number at the GET PERAS event. Only the data records that are in the evaluation period specified in the selection screen are provided ( this is different to PNP, which provides all data records by default). Alternatively, the report can specify which data records are to be provided using the RP_SET_DATA_INTERVAL, RP_SET_DATA_INTERVAL_INFTY, and RP_SET_DATA_INTERVAL_ALL macros.
    INFOTYPES nnnn AS PERSON TABLE
    The nnnn infotype is provided at the GET GROUP event with the data records of all personnel numbers that are in the included ALL_PERNRS table (of the GROUP structure) and for which authorization exists (NO_AUTHORITY flag is not set). Only the data records that are in the evaluation period specified in the selection screen are provided. Alternatively, the report can specify which data records are to be provided using the RP_SET_DATA_INTERVAL, RP_SET_DATA_INTERVAL_INFTY, and RP_SET_DATA_INTERVAL_ALL macros.
    INFOTYPES nnnn AS PERSON TABLE MODE P
    The nnnn infotype is provided at the GET PERSON event with the data records of all personnel numbers that are in the included ALL_PERNRS table (of the PERSON structure). No authorization check is performed and all existing data records are provided independent of how the evaluation period is defined in the selection screen. The use of the RP_SET_DATA_INTERVAL, RP_SET_DATA_INTERVAL_INFTY, and RP_SET_DATA_INTERVAL_AL macros also has no influence here.
    Selection Options
    You can use all the functions and selection options in the selection screen (initially) to select personnel numbers regardless of whether the report is running in PNP or CE mode. Only in CE mode, the persons belonging to these personnel numbers are then determined. The functions that PNPCE provides to restrict the selection are described in the following. The environment in which these functions are actually used depends on the report and its report category. You can assign a report category to a report in maintenance of report attributes (SE38, Attributes, Change button -> HR report category button). The customer can override this assignment. To do so, perform the  Customizing activity under 'Personnel Management' -> 'Human Resources Information System' -> 'Reporting' -> 'Adjusting the Standard Selection Screen'. Follow the same path to define and change report categories in the Customizing activity. Since the PNP logical database also uses the concept of report categories, ensure that you assign only one report category that is created specially for the PNPCE database to a PNPCE report.
    Selection Fields of the 0000 and 0001 Infotypes
    You can use all the standard fields of the 0000 and 0001 infotypes for selection. You can also use additional selection fields that are the concatenation of two or more of these infotype fields. If possible, do not use these concatenated fields because they do not play a significant role in the selection and can lead to long runtimes in certain circumstances. You can show and hide the required selection fields using the Selection Fields function in the application toolbar. The report category defines a preselection of fields that should be available.
    Dynamic Selections
    The dynamic selections enable you to select according to any infotype fields and, in particular, according to customer-specific infotype fields. You can show and hide the dynamic selections using the Dynamic Selections function in the application toolbar. The report category controls whether this appears as a dialog box or inplace, that is whether the dynamic selections are supported at all. The basis for the dynamic selections is a selection view that defines which infotypes and which fields can be used for selection. You can define the selection view in the ABAP Workbench. You must choose For any table as the type of selection view (the For logical database type is not permitted although you may have presumed differently at first). The report category is used to control which selection view is used for the dynamic selections. If you use the dynamic selections, the Restrict by OrgStructure, Search Help, and Selection ID functions are not available.
    Restrict by OrgStructure
    You can also select personnel numbers by their position in the organizational structure. To do so, you use the OrgStructure function in the application toolbar. This button displays the organizational structure. Here you can select the organizational units to which the personnel numbers to be selected should belong. It is insignificant if the personnel numbers are assigned to the selected organizational unit directly or to one of its subordinate organizational units. If you restrict the selection by organizational structure, the Dynamic Selections, Search Help, and Selection ID functions are not available.
    Search Help
    You can use the included search helps of the PREM collective search help by clicking Search Help function in the application toolbar. You can also add customer-specific search helps here. For a description of how to do this, see the Customizing for Personnel Management -> Personnel Administration -> Basic Settings -> . Ensure that you also generate the selection program using the DBPNPGMC report so that the search help actually exists in the PNPCE logical database. If you use a search help, the Dynamic Selections, Restrict by OrgStructure, and Selection ID functions are not available.
    Selection ID
    You can also restrict the number of personnel numbers to be selected using a predefined selection method called a Selection ID. For information on how to use and create selection IDs, see the Customizing activity under 'Personnel Management' -> 'Human Resources Information System' -> . How you  selection IDs is also described here. The selection IDs whose grouping is stored in the report category are available to you for selection on the PNPCE selection screen. When you select a selection ID, it is always performed. This happens either explicitly when you press the button (behind the selected selection ID), or implicitly when output starts (F8). If you use a selection ID, the Dynamic Selections, Restrict by OrgStructure, and Search Help functions are not available.
    Evaluation Period
    The PNPCE (and the PNP) differentiates between the data selection period and the person selection period. Both these periods are summarized in the term evaluation period. Whereas the person selection period affects the selection of personnel numbers, the data selection period controls the retrieval of data requested by the INFOTYPES statement. You can configure both separately on the selection screen by selecting an appropriate entry in each list box. Alternatively, you can set up both selection periods at the same time using a common list box. You can control which entries are in the list boxes (that is which evaluation intervals are supported) using the report category. The person selection period you have set up is taken into consideration when the personnel numbers are selected. Only the personnel numbers are selected that fulfill the selection conditions on at least one (key) date in the specified person selection period. All data records of the requested infotypes that are valid on at least one (key) date in the specified data selection period are retrieved by default for these personnel numbers. You can set up a different procedure using the RP_SET_DATA_INTERVAL, RP_SET_DATA_INTERVAL_INFTY, and RP_SET_DATA_INTERVAL_ALL macros. Retrieving data records for infotypes that were defined by the AS PERSON TABLE MODE P addition is an exception. In this case, all data records are retrieved independent of the data selection period.
    The payroll period should be considered as a special feature for the evaluation period. You can select either the current payroll period or another payroll period. You must enter the payroll area in both cases. The evaluation period is calculated from these specifications. This interval is used as evaluation period (as person selection period and as data selection period) for the further (internal) processing.
    The report can query the evaluation period used via the PN structure. The BEGDA and ENDDA contain the data selection period whereas BEGPS and ENDPS contain the person selection period. Inversely, the report can also set the data and person selection period explicitly. The report must also fill the relevant components of the PN structure at the START-OF-SELECTION event. This is only meaningful if the manual maintenance of the evaluation period was hidden using the report category.
    Communication Between Report and PNPCE
    The DBPNPCECOM include is an element of the PNPCE logical database. This is automatically included in each report that is based on PNPCE. The common part defined in this include means that the report and PNPCE have a common data area. This data area enables the data exchange for communication between the report and PNPCE. All switches that can be used by the report to control the process of PNPCE are defined here. The DBPNPCECOM include also contains a number of macros that PNPCE uses to make additional functions available to the report. Most of these macros were adopted by PNP and defined there in the DBPNPMAC include. Additional macros still exist in the TRMAC table, which has in the meanwhile become obsolete. Do not use these macros for any purpose. You can find all the macros defined in PNP that affect the functionality of the logical database in the DBPNPCECOM include. They have a slightly different spelling; underscore_ instead of hyphen-, for example RP_PROVIDE_FROM_LAST  instead of PROVIDE-FROM-LAST. Some of the TRMAC macros in the DBPNPCECOM include were redefined with the same spelling but without the functionality so that any incorrect use (of the TRMAC macros) leads to a syntax error and is therefore excluded.
    The following describes the functions made available by the switches and macros defined in the DBPNPCECOM include. For information about the exact syntax for calling a macro in view of its parameters and type specifications, see the definition of the macro in the DBPNPCECOM include.
    Evaluation Period in the PN Structure
    The PN structure contains information about the evaluation period for which the evaluation is started regardless of how this is specified on the selection screen. A report should access the fields of the PN structure only if it requires this information and should not access the PNPBEGDA, PNPENDDA, and other selection fields of the selection screen.
    The PN-BEGPS and PN-ENDPS fields contain the person selection period for which the personnel number selection was performed. The PN-BEGDA and PN-ENDDA fields contain the data selection period. If you have specified the evaluation period using a payroll period, PN-PABRP contains the payroll period, PN-PABRJ the payroll year, and PN-PERMO the period parameters. The payroll period and payroll year are also in PN-PAPER.
    The report can also fill the PN-BEGDA, PN-ENDDA, PN-BEGPS, and PN-ENDPS fields with values at the START-OF-SELECTION event and in doing so, specifies the evaluation period. In cases like this, it is not meaningful to have this setting option on the selection screen and it should therefore be hidden using the report category. In addition, the report must ensure that the values specified are valid since there is no longer a validation of these values.
    Setting the Data Selection Period: RP_SET_DATA_INTERVAL, RP_SET_DATA_INTERVAL_INFTY, RP_SET_DATA_INTERVAL_ALL
    The report uses the INFOTYPES statement to request infotype data records that are read and made available by PNPCE. The report can specify that it only requires data records that are valid in the specified period using the 'VALID FROM .. TO ..' addition. Unfortunately, you cannot use the 'VALID FROM .. TO ..' addition in most cases because it does not accept dynamic date specification. It only accepts constants. If you do not use the 'VALID FROM .. TO ..' addition, PNPCE returns all data records that are in the specified data selection period on the selection screen by default. If this is not required, the report can call the RP_SET_DATA_INTERVAL, RP_SET_DATA_INTERVAL_INFTY, and RP_SET_DATA_INTERVAL_ALL macros to restrict the infotype data records to a different validity period. The RP_SET_DATA_INTERVAL macro sets the validity period for an individual infotype whose name you specify in the first parameter. Do not confuse the name of the infotype, P0001 or PP0001 for example, with the number of the infotype 0001. You specify the validity period in the second and third parameters. You should use the RP_SET_DATA_INTERVAL_INFTY macro in the same way but instead of entering the name in the first parameter, enter the number of the infotype. Since the same infotype can be used several times (under different names) when you use the INFOTYPES additions 'AS PERSON TABLE' or 'NAME ...', this macro sets the validity period for all infotypes of the same number. In contrast, the RP_SET_DATA_INTERVAL_ALL macro only has the validity period as a parameter and sets this for all infotypes used.
    Setting the Mode of an Infotype: PNP_SET_INFTY_MODE_BY_NAME, PNP_SET_INFTY_MODE_BY_NUMBER
    The INFOTYPES statement can use the MODE addition to control whether the infotype should be processed and how this should proceed. If the addition is not used, this corresponds to a MODE Y and the PNPCE logical database reads the infotype and places it in the internal infotype table. MODE N enables the internal infotype table to be declared but no infotype data records are read by the PNPCE logical database. MODE P can only be used together with the 'AS PERSON TABLE' addition and causes all infotype data records of all personnel numbers of a person to be read at the GET PERSON event without authorization check or period restriction. The report can use the PNP_SET_INFTY_MODE_BY_NAME and PNP_SET_INFTY_MODE_BY_NUMBER macros to change the MODE specified by the INFOTYPES statement (dynamically) at runtime. The macros must be called at the INITIALIZATION or START-OF-SELECTION events. The PNP_SET_INFTY_MODE_BY_NAME macro sets the MODE for an individual infotype whose name you specify in the first parameter. Do not confuse the name of the infotype, P0001 or PP0001 for example, with the number of the infotype 0001 You should use the RP_SET_INFTY_MODE_BY_NUMBER macro in the same way but instead of entering the name in the first parameter, enter the number of the infotype. Since the same infotype can be used several times (under different names) when you use the INFOTYPES additions 'AS PERSON TABLE' or 'NAME ...', this macro sets the MODE for all infotypes of the same number.
    Reading Time Management Infotypes: RP_READ_ALL_TIME_ITY, RP_READ_ALL_PERSON_TIME_ITY
    Time management infotypes (2000-2999) often contain a large number of data records, particularly if positive recording is implemented. If a dataset that is too large is requested using the INFOTYPES statements, this can lead to performance problems or in an extreme case, to memory overflow. For this reason, there are the RP_READ_ALL_TIME_ITY and RP_READ_ALL_PERSON_TIME_ITY macros, which can be used to read time management data in a targeted manner. The time management infotypes are defined by the INFOTYPES statement with the MODE N addition. This enables the internal infotype table to be declared but no data is read (at the moment) by the PNPCE logical database. The report can then decide at the GET GROUP and GET PERAS events whether it wants to read the time management data and for which period. At the GET GROUP event, the report can call the RP_READ_ALL_PERSON_TIME_ITY macro to read all time management data on the personnel numbers of a person that should be processed. In other words, the time management data that is in the included ALL_PERNRS table of the GROUP structure. The data is then written to the infotypes that were declared by the INFOTYPES statement with the AS PERSON TABLE addition.
    However, at the GET PERAS event, the report can call the RP_READ_ALL_TIME_ITY macro to read the time management data on the current personnel number. In both cases, you must specify the period in which the data records should be valid when the macro is called. The PNP-SW-IGNORELOCKEDRECORDS switch is also taken account of in both cases and controls whether locked data records are read or not. In addition, an authorization check is performed for all data records. If no authorization exists for a data record, this data record is rejected (that is, it is not placed in the infotype table). If data records are rejected because of missing authorization, the PNP-SW-AUTH-SKIPPED-RECORD global switch is set to 1. This switch is otherwise set to 0.
    Locked Data Records: PNP-SW-IGNORELOCKEDRECORDS
    In HR master data maintenance, you can lock individual infotype data records. These data records are normally ignored during evaluations using PNPCE. If you set the PNP-SW-IGNORELOCKEDRECORDS switch to N (at the INITIALIZATION or START-OF-SELECTION events), the report can however instruct PNPCE to read locked data records too.
    Authorization Check: PNP_SW_SKIP_PERNR, PNP_GET_AUTH_SKIPPED_PERNRS
    The PNPCE logical database performs an authorization check for all infotype data records that are requested by the report using the INFOTYPES statement. If no authorization exists for even one individual data record of one of the infotypes used, processing of the personnel numbers is terminated by default. In PNP mode, this means that the GET PERAS event (for the personnel number) is skipped. The report is only aware of this if it then (if possible at the END-OF-SELECTION event) calls the PNP_GET_AUTH_SKIPPED_PERNRS macro, which returns a list of the skipped personnel numbers.
    In CE mode, the NO_AUTHORITY flag is set in the included ALL_PERNRS table at the GET GROUP event, which indicates to the report that no authorization exists. The following event, GET PERAS, is also not executed for this personnel number. As in PNP mode, the report can get a list of the personnel numbers for which no authorization exists using the PNP_GET_AUTH_SKIPPED_PERNRS macro.
    You can enter different settings using the PNP_SW_SKIP_PERNR switch. If you set this switch (at the INITIALIZATION or START-OF-SELECTION events) to N, no more personnel numbers (without authorization) are skipped. Only the data records for which no authorization exists are rejected (that is, not made available). The report has no way of knowing that data records are being withheld from it.
    Mass Access By Array-Fetch: PNPCE_ARRAY_FETCH_SIZE
    The infotype data records are not read for each personnel number individually but in a mass access for several personnel numbers simultaneously. This reduces the number of database accesses and performance can be considerably improved. You cannot read the infotype data records of all personnel numbers at once since this can lead to problems with memory space depending on the number of selected personnel numbers and existing data records. For this reason, the personnel numbers are segmented into blocks of a fixed size and the personnel numbers of a block are always read together. The size of the block is set to 100 by default (this means that the personnel numbers from 100 persons are processed at the same time). The report can change this setting using the PNPCE_ARRAY_FETCH_SIZE switch at the INITIALIZATION or START-OF-SELECTION event. Be very careful if you change this value. If the value is set too high, it can lead to a memory overflow. If the value is too low, performance is affected. You must choose a suitable value based on the number of requested infotypes and their expected datasets.
    Locking Persons/Personnel Numbers
    By default, the logical database does not lock any personnel numbers or persons. However, the report can request this. In CE mode, the report must set the PNPCE_ENQUEUE_PERSONS switch to X. This enables the LDB to set locks for all personnel numbers of a person. The person is regarded as locked and is processed further only if all personnel numbers have been successfully locked. Otherwise, they are skipped. It is the reports task to remove this lock. To do so, the report calls the PNPCE_DEQUEUE_PERSON macro by specifying the person ID. Persons that could not be locked and were skipped are logged by the logical database. After processing has finished, the report can query this list using the PNPCE_GET_ENQ_FAILED_PERSONS macro. However, not all persons are logged, only the first N persons. The report can find out how many this is exactly using the PNPCE_LOG_ENQ_FAILED_PERSONS switch. 1 means that all persons should be logged. If the report calls the PNPCE_GET_ENQ_FAILED_PERSONS macro, the total number of skipped persons is returned with the first N logged persons.
    In PNP mode, individual personnel numbers can be locked. The report (and PNP) must set the PNP-SW-ENQUEUPERNR switch to Y to enable this.  The report is here also responsible for unlocking the personnel numbers and can call the PNP_DEQUEUE_PERNR macro for this by specifying the personnel number. The report can get a list of the personnel numbers that could not be locked by calling the PNP_GET_ENQ_FAILED_PERNRS macro. Only the first N personnel numbers and the total number of skipped personnel numbers are returned. The number of personnel numbers that should be logged can be specified using the PNP_LOG_ENQ_FAILED_PERNRS switch. 1 means that all personnel numbers should be logged.
    Determining the First Data Record in the Period: RP_PROVIDE_FROM_FRST
    The RP_PROVIDE_FROM_FRST macro analyzes the infotype data records that were transferred in an internal table to the macro with regard to the specified period. It places the first data record that is valid in the specified period (the data record with the lowest ENDDA) in the header of the internal table. If no data record exists in the specified period, the PNP-SW-FOUND global switch is set to 0. Otherwise it has the value 1. If the infotype contains subtypes, you also need to specify the subtype for which the last valid data record should be determined. If you do not specify the subtype, the result is undefined. In addition, the data records of the internal table must be sorted according to primary key. The data records are sorted if the data records were determined by PNPCE logical database using the INFOTYPES statement. Analyze the implementation of the macro if the exact functions of the macro are unclear. If in doubt, do not use the macro. Instead implement a suitable solution for the report in question.
    Determining the Last Data Record in the Period: RP_PROVIDE_FROM_LAST
    The RP_PROVIDE_FROM_LAST macro analyzes the infotype data records that were transferred in an internal table to the macro with regard to the specified period. It places the last data record that is valid in the specified period (the data record with the highest ENDDA) in the header of the internal table. If no data record exists in the specified period, the PNP-SW-FOUND global switch is set to 0. Otherwise it has the value 1. If the infotype contains subtypes, you also need to specify the subtype for which the last valid data record should be determined. If you do not specify the subtype, the result is undefined. In addition, the data records of the internal table must be sorted according to primary key. The data records are sorted if the data records were determined by PNPCE logical database using the INFOTYPES statement. A special feature of infotypes with time constraint 3 in this case is that the data record with the highest ENDDA is not necessarily returned, but the first data record (if it exists) that is valid on the end date of the specified period. Analyze the implementation of the macro if the exact functions of the macro are unclear. If in doubt, do not use the macro. Instead implement a suitable solution for the report in question.
    Reading Infotypes: RP_READ_INFOTYPE
    The RP_READ_INFOTYPE macro reads the data records of an infotype for the specified personnel numbers that are valid in the specified period, and writes these to the internal table specified. This table must be completed correctly. If no data records exist in the specified period, the PNP-SW-FOUND global switch is set to 0. Otherwise it has the value 1. In addition, an authorization check is performed for all data records. If no authorization exists for a data record, this data record is rejected (that is, it is not placed in the internal table). If data records are rejected because of missing authorization, the PNP-SW-AUTH-SKIPPED-RECORD global switch is set to 1. This switch is otherwise set to 0. The PNP-SW-IGNORELOCKEDRECORDS switch is also taken account of when the data records are read and controls whether locked data records are read or not.
    Normally, infotypes are read using the HR_READ_INFOTYPE function module. The RP_READ_INFOTYPE macro can improve performance when the data records have already been read by PNPCE and are in the internal buffer. PNPCE only read the data records that were requested by the report using the INFOTYPES statement. In addition, the buffer is deleted again at the latest after 100 processed personnel numbers. If however the report requests the data records using an INFOTYPES statement, it is not particularly meaningful to request the data records again for the same personnel number using the RP_READ_INFOTYPE macro. The buffer is only useful when the data records are called for a different personnel number if these personnel numbers belong to the block of the 100 current buffered personnel numbers. Always weigh up the advantages of this macro against the consequences of its use for performance.
    Excluding Withdrawn Employees: RP_SEL_EIN_AUS_INIT
    If this macro is called at the INITIALIZATION event, only personnel numbers are selected that do not have the status withdrawn in the specified person selection period. From a technical point of view, the select option PNPSTAT2 (STAT2 from infotype 0000) is filled with '   0' for this. This is a default value for the selection condition displayed on the selection screen that the user can change or delete at a later date.
    Progress Indicator: PNPCE_NO_PROGRESS_INDICATOR, PNPCE_PROGRESS_BLOCK_SIZE
    The PNPCE logical database uses the standard technique of displaying processing progress (process indicator). If the report wants to set up its own progress indicator or does not want to have a progress indicator displayed, it can switch this indicator off by setting the PNPCE_NO_PROGRESS_INDICATOR switch to X. The PNPCE_PROGRESS_BLOCK_SIZE switch enables the report to control how often (that is, after how many processed persons) the progress indicator should be updated. If the progress indicator is updated too often, performance suffers.
    Payroll Grouping: PNPCE_GROUPING_FROM_PAYROLL
    If you set the switch to X, the grouping of personnel numbers (as returned at the GET GROUP event) should be performed on the basis of payroll data.
    Personnel Numbers Skipped Due to Error: PNP_GET_ERR_SKIPPED_PERNRS
    A special logic for determining data records is implemented in PNPCE for certain infotypes. This is performed using a function module (HR_COST_DISTRIBUTION_GET) for infotypes 0027 and 0266. In the case of an error, the function module can trigger an exception. PNPCE reacts to an exception by terminating processing of the personnel numbers for which the error occurred (that is, the PUT PERAS event is not triggered). If the report wants to know which personnel numbers were skipped due to this error, it can call the PNP_GET_ERR_SKIPPED_PERNRS macro.
    Comments
    Headers of Infotype Tables
    PNPCE fills the table body with infotypes defined by INFOTYPES. It does not fill headers. These are initialized. Therefore, it is not permitted to program headers. This is in part different in the PNP logical database. In certain cases, the header is also filled but in many cases it is not filled. Since this depends on various factors, which, in particular, cannot be traced or controlled by the report, you are also not permitted to program headers.
    Infotype Administration Table $RINFO$
    In the $RINFO$ table, infotypes are managed that the report defines using the INFOTYPES statement. It is defined in the DBPNPCECOM include so that the report also has access to this table. You are forbidden to manually modify this table for the purpose of changing infotype characteristics by the report. Instead, use the macros that enable you to set the infotype characteristics (set the MODE by PNP_SET_INFTY_MODE_BY_NAME and PNP_SET_INFTY_MODE_BY_NUMBER; set the validity period by RP_SET_DATA_INTERVAL, RP_SET_DATA_INTERVAL_INFTY, and RP_SET_DATA_INTERVAL_ALL).
    Starting a PNPCE Report Using Preselected Personnel Number Set/Person Set
    You can also start a PNPCE report using an externally predefined personnel number set. You must provide the PNPINDEX parameter with the relevant personnel number when you call the report using SUBMIT. Since, technically speaking, the select option for PNPINDEX is hidden, you must specify the personnel numbers in a RANGE structure that consists of SIGN, OPTION, and LOW. For each personnel number, SIGN must contain the value I, OPTION the value EQ, and LOW the personnel number. For SUBMIT, the range table should be transferred to PNPINDEX by the IN operator.
    Example:
    RANGES: pernr_index FOR pernr-pernr.
    CLEAR pernr_index.
    pernr_index-sign = 'I'.
    pernr_index-option = 'EQ'.
    pernr_index-low = '00000815'.
    APPEND pernr_index.
    SUBMIT pnpce_report WITH pnpindex IN pernr_index.
    If a set of personnel numbers is defined in this way, you cannot use the Dynamic Selections, Restrict by OrgStructure, Search Help, and Selection ID functions to (further) restrict the set of personnel numbers. However, the conditions entered for the selection fields of infotypes 0000 and 0001 are taken into account.
    Similarly, you can start a PNPCE report with a specified set of persons. You must provide the PNPPERID parameter with the relevant person IDs when you call the report using SUBMIT. Unlike PNPINDEX, PNPPERID is not a range but is an internal table whose row type is the PERSONID data element.
    Example:
    DATA: personid_index TYPE STANDARD TABLE OF personid.
    APPEND '00000815' TO personid_index.
    SUBMIT pnpce_rerpot WITH pnpperid = personid_index.
    If a set of persons is defined in this way, you cannot define a set of personnel numbers (using PNPINDEX) at the same time. Also in this case, you cannot use the Dynamic Selections, Restrict by OrgStructure, Search Help, and Selection ID functions to (further) restrict the set of personnel numbers.
    Using Several Selection Options Simultaneously
    In addition to selecting fields of infotypes 0000 and 0001 as described above, PNPCE offers six other options for selecting personnel numbers. They are selection using dynamic selections, using organizational structure, using search help, using selection ID, and by explicitly specifying a personnel number set in PNPINDEX or a person set in PNPPERID when you call the report. These six options exclude each other, that is you can only use one of these options at a time. Appropriate queries on the selection screen attempt to ensure this. It can happen in certain cases, however, that more than one of these functions is used (for example, when you call the PNPCE report by explicitly specifying a personnel number set in PNPINDEX as well as one of the variants to be used in which dynamic selections were also stored). In this case, only one function, which is the first function used, is taken into account with regard to the following sequence:
    1.     Dynamic Selections
    2.     Restrict by OrgStructure
    3.     Search Help
    4.     Selection ID
    5.     Explicit Specification or Personnel Numbers in PNPINDEX
    6.     Explicit Specification or Persons in PNPPERID
    The personnel number set found this way is always restricted further by the selection conditions specified in the 0000 and 0001 infotypes.
    Example
    PNP Mode (without functions for evaluating concurrent employment)
    TABLES: PERNR.
    NODES: PERAS.
    INFOTYPES: 0006 NAME P0006.
    GET PERAS.
    table P0006 is filled with infotype 0006 data of PERNR
    stored in PERAS-PERNR
      WRITE :/ PERAS-PERNR.
    CE Mode (with function for evaluating concurrent employment)
    TABLES: PERNR.
    NODES: PERSON, GROUP, PERAS.
    INFOTYPES: 0001 NAME ALL_0001 AS PERSON TABLE MODE P.
    INFOTYPES: 0001 NAME PP0001 AS PERSON TABLE.
    INFOTYPES: 0006 NAME P0006.
    GET PERSON.
    table ALL_0001 is filled with infotype 0001 data of all PERNRs
    stored in PERSON-ALL_PERNRS without authority check !!!
      WRITE :/ PERSON-OBJID.
    GET GROUP.
    table P0001 is filled with infotype 0001 data of all PERNRs
    stored in GROUP-ALL_PERNRS
      WRITE :/ GROUP-GROUPING_REASON, GROUP-GROUPING_VALUE.
    GET PERAS.
    table P0006 is filled with infotype 0006 data of PERNR
    stored in PERAS-PERNR
      WRITE :/ PERAS-PERNR.

  • PA40 Exit

    Hi Experts,
      When we execute the transaction PA40, we also provide a reason for action.
      I require an exit in which that value is caught.
      Is that value there in PBAS0001?
      If not any other exit??
    Thanks and Regards,
    Ravi

    Here are the BADI and EXIT for the dev class of PA40
    SAP extension name/Enhanced               
         BADI          
              HR_F4_GET_SUBTYPE     HR: Entry help for subtypes
              HR_FAST_ACTION_CHECK     Check fields on the fast entry screen
              HR_INDVAL     HR: Indirect wage type valuation
              HR_SET_PKGAB     
              HRPAD00_ADRS     HR: Address formatting
              HRPAD00_PAPM     Definition of User Exit for Collective Search Help PAPM
              HRPAD00_PREM     Definition of User Exit for Collective Search Help PREM
              HRPAD00AUTH_CHECK     HR: Authorization Check
              HRPAD00AUTH_RECORD     Spanish Data Privacy Law: Exit for Recording
              HRPAD00AUTH_TIME     Time logic in the PA authorization check
              HRPAD00INFTY     Update / Infotype maintenance
              HRPADUS_PBAS_0001     Customer Exit for Message handling
         HRPBAS01          
              EXIT_SAPLRPIN_001     User Exit for HR Master Data
         HRPC0001          
              EXIT_RPDBPC00_001     PC Download Authorization for HR Reports with Log. Database PNP or PCH
         HRRPAI01          
              EXIT_SAPLRPAI_001     User Exit for HR_ENTRY_DATE
              EXIT_SAPLRPAI_002     User Exit for HR_LEAVING_DATE
         PARA0001          
              EXIT_SAPLPARA_001     Exit to Determine the Number of Periods (Feature 'PFREQ')
         PARA0002          
              EXIT_SAPLPARA_002     Exit for Calculating Salary Percentage from IT0008 "Basic Pay"
              EXIT_SAPLPARA_003     Exit for Calculating Salary Percentage from IT0014 "Recurr. Payments/Ded."
              EXIT_SAPLPARA_004     Exit for Calculating Salary Percentage from IT0015 "Additional Payments"
         PBAS0001          
              EXIT_SAPFP50M_001     Customer Default Values for Personnel Administration and Recruitment
              EXIT_SAPFP50M_002     Customer Checks for Personnel Administration and Recruitment
         PBAS0002          
              EXIT_SAPMP50A_001     Personnel Administration Menu: Function for Input of Personnel Number
         PBASRP01          
              EXIT_RPMREP00_001     Determine Log Report
    Check action type in table T529A, reason in table T530.
    Regards

  • User Exit that triggers for Change operation

    Hi All..
    I want a user exit which triggers when I enter into an infotype(2001) from tcode PA30.
    My actual requirement is to show the field REFNR in display mode.
    By using the exit PBAS0001 exit0001 I can make the field REFNR in displaymode for create operation.
    But in change operation of the infotype the exit is not getting triggered.
    Regards,
    Anji.

    chk these
    Transaction Code - PA30                     Maintain HR Master Data
    Enhancement/ Business Add-in            Description
    Enhancement
    PBASRP01                                PA: User exit distributed reporting
    PBAS0002                                PA: Enhancements for Personnel Administration - Menu
    PBAS0001                                PA: Pers.Admin./Recruitment: Default values and checks
    PARA0002                                Enhancement for Calculating Annual Salary; IT0008,14,15
    PARA0001                                Enhancement for Determining the Number of Periods
    HRRPAI01                                User exit for FB HR_ENTRY_DATE and HR_LEAVING_DATE
    HRPC0001                                HR: PC download authorization
    HRPBAS01                                User Exit for HR Master Data
      Business Add-in
    HRPAD00_PREM                            Definition of User Exit for Collective Search Help PREM
    HRPADUS_PBAS_0001                       Customer Exit for Message handling
    HRPAD_SUBTY_CHECK
    HR_F4_GET_SUBTYPE                       HR: Entry help for subtypes
    HR_FAST_ACTION_CHECK                    Check fields on the fast entry screen
    HR_INDVAL                               HR: Indirect wage type valuation
    HR_SET_PKGAB
    HRPAD00_RECOG_SCREEN                    Employee - Recognition Screen
    HRPAYXX_DELETE_PERNR                    BAdI for Reports Deleting Personnel Numbers
    HRPAD00_PAPM                            Definition of User Exit for Collective Search Help PAPM
    HRPAD00_GET_AF_0008                     Additional Fields for Basic Pay Infotype (0008)
    HRPAD00_ENTRY_LEAVE                     HR_ENTRY_DATE and HR_LEAVING_DATE
    HRPAD00_ADRS                            HR: Address formatting
    HRPAD00MGEACTIVATION                    Activation Action BAdI for Global Employees
    HRPAD00INFTY                            Update / Infotype maintenance
    HRPAD00AUTH_TIME                        Time Logic in the PA Authorization Check
    HRPAD00AUTH_RECORD                      Spanish Data Privacy Law: Exit for Recording
    HRPAD00AUTH_CHECK                       HR: Authorization Check
    HRIV_REDUCE_AMOUNT                      Reduction within Indirect Valuation

Maybe you are looking for

  • Calendar Display - resolved

    I've recently switched to the "BB Dimension Today" theme on my BB and fell in love with it.  I especially love the portion of the main screen that shows my upcoming events as entered in the calendar.  I enter a majority of my events using my email ad

  • Lock objects

    Hi experts, My requirement is to create lock for parent table and its child tables.Each and every child tables is having relation with the parent table.   When iam creating the lock for parent table, in this process iam adding the child tables in the

  • Need help in transcation code ime0

    I need help in transaction code ime0. I mean to say what is this TCode doing? What different Drill-down program means? Where I can use this report? Regards, Subhasish

  • Is it worth getting the airport extreme in your experience?

    hi all, my first wireless setup was the original airport base station eight or nine years ago, and the reliability was fantastic - plug it in and forget it. but when newer, faster protocols came out, i went with a netgear, then got fed up with having

  • Changing the color of the link to the current page

    How can I change the link on the current page to display a different color until the user redirects to another page. I am wanting to keep all my links visible and simply change the color of the link that the user is on. I think I am going to use the