Validation and Substitution

Validation(OB28) A validation rule is basically a check on a certain field's data. When a user is entering a transaction and enters data in that certain field which violates the validation rule, a error message appears for the user and generally will not allow the transaction to continue. The functional analyst designs the validation rule in one of several transactions. You can set them up to be called at the Document Header level, at the Line Item level. These checks are created in transaction GGB0 and activated for FI in transaction OB28 Substitution(OBBH) The substitution rule also checks a certain field's data (that you design in configuration). If the field's data matches what has been configured in the substitution rule, the data will be removed. Then specific other data will be substituted into that field. Substitutions can also be set up at the header, line item, or complete document level, and if a certain set of user-defined criteria are met, then a new value is put into a specific field. For instance, if Company = X and Cost Center = Y, then change Profit Center to be Z. It doesn't work on all fields, but can come in handy for Profit Centers or Allocations, and sometimes Texts such as SGTXT. Substitutions are set up using GGB1 transaction and are activated in FI using transaction OBBH.
Validation is a little trick ( rather a technique ) which acts like a watchdog and ensures that incorrect data does not get posted while posting a transaction. A validation is a procedure which is on the look out for incorrect data; if incorrect data is entered by the end-user during document posting, the validation spews out an error message and cautions the end-user. The severity of the message can be mild which only warns but lets the end-user post the document. On the other hand, a validation can be configured to throw a serious error message and prevent incorrect posting. A Validation is given a name and is assigned to a company code. A validation may checks data at document header level only (called as callup point 1) or at line item level ( called as callup point 2) or at the full document level ( call up point 3). A given validation uses one of the above call up points. A validation , at the minimum, contains three steps: Step 1: a pre-requisite ( validation will happen if the pre-requisite is met). If the pre-requisite is not met by the document under posting, the system ignores the validation technique and posts the document.

Step 2: If the pre-requisite is met a check is made for compliance of an extra condition (over and above the pre-requisite). If the condition is also complied with by the document, then posting happens. Step 3: On the other hand, if the check activity is not complied with, then the system smells a rat and throws an appropriate error/warning message ( depending on the severity of error as configured by you ). Let me give you an example of validation from daily life: Pre Requisite: If You want to Go outside Check : It is raining outside and you do not carry an umbrella Your Mom delivers a Message:"Take an umbrella while going as it is raining outside" Let us test this procedure: 1. If you do not want to go outside, then the check as well as the message are not required. Therefore validation does not happen 2. If you want to go outside but it is not raining outside,You do not need a warning message. Validation does not happen 3. If you want to go outside and it is raining outside and you have an umbrella, then you do not need any warning message. Therefore validation does not happen 4. If you want to go outside and it is raining outside and you DO NOT HAVE AN UMBRELLA, then you are warned to take an umbrella. Your Mom delivers a message "Take an Umbrella while going outside since it is raining " This is validation. Substitution is also similar. There is no message. Instead of your mom delivering a message, she thrusts an umbrella into your hand. That is substitution. This is what happens during document posting: Your validation contains a pre-requisite, Check and Message. Your substitution contains a check and substitution

User Exits in Validations/Substitutions/Rules

User exits are user-defined FORM routines that are used to calculate and/or replace values within a validation, substitution, or rule. User exits have the following format: U (for a user-defined user exit) or S (for a standard user exit) The user exit number (three digits)

For example, U123 is a user exit. You can configure the form pool name of the user exits and must store it in the table for client-dependent user exits (T80D) in Customizing. Table T80D contains the form pool names for the user exits used in validations, substitutions, and rules. Each validation/substitution form pool is client-dependent. (For more information, refer to the Maintain Client-Dependent User Exits activity in the Implementation Guide (IMG) forSpecial Purpose Ledger.) Example form pools RGGBS000 and RGGBR000 for client 000 are shipped with the SAP R/3 System. You must copy these form pools and configure them in T80D. The new form pool name should conform to the customers naming convention (beginning with the letter Z ) so that is not overwritten when the next SAP upgrade is installed (for example, ZGGBR000).

Example FORM routine for substitution exit 001 (U001). TABLES: COBL. FORM U001. COBL-KOSTL = COBL-BUKRS. ENDFORM. Tables and structures should not be declared in the FORM routines so that the contents can be used together with the calling transaction. SAP exits are FORM routines that have been programmed by SAP. The name of the form pool for SAP exits is SAPFGBEB.

If you still store your rules in table T890 (interpreted rules), you cannot use user exits in your rule definition. It is recommended that you use report program RGUGBR10 to convert interpreted rules into generated rules so that you can use the Customizing function for maintaining rules. For more information, see Using the Rule Manager Reports. The following table shows the types of user exits that can be used in validations, substitutions, and rules. User exit type 1 Description Application Example

No parameters are defined for the user exit.

Rules, validations, and See form pool substitutions RGGBR000, parameter (prerequisite) type C_EXIT_PARAM_NONE Same as user exit type 1, except one Substitution See form pool parameter (the field to be substituted) is RGGBS000, parameter defined in the user exit. For example, you can type create a substitution routine that analyzes the C_EXIT_PARAM_FIELD

cost center irrespective of the field used. All data is passed as one parameter; this exit Rules, validations, and See form pool type can only be used in matrix validations substitutions RGGBR000, parameter and substitutions. (prerequisite) type C_EXIT_PARAM_CLASS

Validations and rules use exit numbers 1 and 3 from the above table. Substitutions use all of the exit numbers from the above table. For substitutions, you can also create user exits that accept a field as one parameter and then return the changed value in this parameter. This allows you to create a user exit that can be used independently of the field and table name. This type of user exit cannot be used as an entry in the Exit only field in the list of values to be substituted; you can only use this exit type in conjunction with a field name. An example of this user exit type is in form pool RGGBS000. If you want to define a parameter for your user exit that is different from the result of a validation (B_RESULT), you must make an entry for your user exit in the FORM routine GET_EXIT_TITLES in the form pool you defined. It is recommended that you copy the SAP example form pool RGGBR000 for validation exits or RGGBS000 for substitution exits. These example form pools already contain entries in the FORM routine GET_EXIT_TITLES for the examples delivered by SAP. Settting up the FI Validations You can use additional validation to supplement the existing SAP logic to fit you into your businness needs. For e.g. to allow postings from company code 0001 to business area AA only. GGB0 - To maintain the validations Validation - Enter a validation name e.g. VBUS Applicaion Area - SAP module e.g. FI Calling Point - Dependent upon the application area that is selected. - Document Header - validate enteries at document header, e.g BKPF table - Line Items - check line item entris within a document, e.g. BSEG table - Complete Document - check settings for the whole documents. e.g. Validation step 001 Allowed company code '0001' to post to business area AA only. 'FI00' checks that line item is from FI. If checks failed, the error message number 14 is displayed to stop the transaction. Prerequisite <BSEG> $BUKRS = '0001' AND <BKPF> $GLVOR = 'FI00' Check <BSEG> $GSBER = 'AA'

Message Type E No. 14 - Business Area not allowed for company 0001 Output fields 1 - BSEG - GSBER 2 - BSEG - BUKRS 34 OB28 - Define Validations for Posting CC CallPnt Validation 0001 2 VBUS Description Business Area Validation 1 - Activated Activtn Level 1

Activtn Level - 0 - Not Active

2 - Activated for all except batch input

GGB4 - Manage the activation of all validations in the SAP system.

Functional Area Substitution GGB1

In order to populate your postings with functional areas, you must setup a substitution. Substitutions are similar to validations. Unlike validations that create on-screen messages to the user, substitutions actually replace and fill in field values behind the scenes without the user's knowledge. Similar to validations, substitutions can be setup for a number of different application areas and callup points. Substitutions are activated on the company code level, so it is important to ensure that you have followed all steps for each company code. Financial Accounting >> Special Purpose Ledger >> Tools >> Maintain Validation/Substitution/Rules >> Maintain Substitution Transaction code: GGB1 The fields in Create Substitution screen are: Application Area: Enter the appropriate area is the module or submodule that you wish to create the substitution for. The available options are: AM CO FI GL JV KC PC PS Asset Management Controlling Financial Accounting Special Ledger Joint Venture Accounting Enterprise Controlling SAP EIS Profit Center Accounting Project Systems

Callup Point: Callup points determine when the substitution is run. For FI application area, the following callup points are available 0001 Document header: Use this callup point to substitute entires at the document header level. The entries that are usually available substitution at this point are stored in the BKPF table. 0002 Line Item: Use this callup point to substitute line item entries within a document. The entries that are usually available for substitution at this point are stored in BSEG table. 0003 Complete Document: This callup point substitutes settings for the document as a whole. This activity is also known as matrix substitution. 0005 Cost of Sales Accounting: This callup point is used for functional area substitutions On the next screen add a description. To add a step to substitution, click on insert entry button. Specify of you are using a user-exit or select the field you wish to substitute. For field substitution, you need enter the following Perquisite: The perquisite uses Boolean logic to determine if a condition is true. If the condition is true, the substitution is carried out. If the condition is not true, no further processing occurs. The valid Boolean logic operators are =, <, > and <>. The entry immediately following the Boolean statement must be put in single quotation marks unless a set is being used. Sets group together of a number of entries. When you use sets, the system needs to match only one of the entries. When you use sets, the system needs to match only one of the entries in the set for the prerequisite to be true. Sets are defined using Report Writer. The creation of sets will be covered later in this section. To link multiple logic steps together, either an AND or an OR is required at the end of each statement line. Substitutions: This is the section where you tell the system what values to replace. You have the option of either using constant values or using a user-exit to specify values or carry out other logic statements. Validations and substitutions are case sensitive make sure you type in all your logic in CAPS Check syntax does not find errors in small case. Run the check syntax function to see if the Boolean logic has errors. Saving creates the ABAP code run your substitution.