Skip to end of metadata
Go to start of metadata

SAP Screen Personas

Implementing custom validations

SAP SCREEN PERSONAS KNOWLEDGE BASE - by Tamas Hoznek , Regina Sheynblat


This article will explain how to implement custom validations in a flavor.


In certain scenarios it is necessary to add some validations to input fields and prevent the transaction from continuing if the specified criteria is not fulfilled. For instance, it can be necessary to turn an optional field into a required one using a Personas flavor. Many times this is not possible via backend configuration or it would be cumbersome to do so, especially if different use cases would need the same field to be required in one scenario and remain optional in another one. With the use of some visual change and scripting, it is possible to make fields to look like required, then evaluate their content and prevent the transaction from continuing if they are not populated.

Use case

Let’s take the first screen of transaction VA01 (sales order creation) as an example and assume that our requirement is to make the Sales Organization field required in our flavor.


First, let’s go into the Editor and select the field, then click on “More Options”, and “Suggested”. This will make the field appear as required, putting the * in the beginning like in case of required fields in the backend. This is, however, not enforced, so this is where a script is needed to do that. 


The script has to check the content of the Sales Organization field and we want to issue an error message if it is left empty. There are some other events that must be considered though. For instance, we wouldn’t want to check the field content if the user requestts the possible values (F4 help) for a field. Similarly, if certain standard navigation functions are selected (such as F3 – Back, F12 – Cancel or F15 – Exit), we also don’t want our check to kick in and would let the regular backend logic to handle these. There may be also other navigation options or menu functions that you need to define as an exemption.

The required check script is assigned to the onBeforeRefresh screen event, which provides the opportunity to interrupt the selected action to reach the backend in case of an error (missing value) or let the transaction to continue processing like the standard transaction flow.

The script could look like the following:

 switch(triggerType) {   
	case session.findById("wnd[0]").EVENT_VCOMP:       
		// If Back, Cancel or Exit pressed:       
		if (caller && ( === "wnd[0]/tbar[0]/btn[12]" || === "wnd[0]/tbar[0]/btn[15]" || === "wnd[0]/tbar[0]/btn[3]")) {          
			// leave it to backend processing          
	case session.findById("wnd[0]").EVENT_VKEY:       
		if (typeof vkey == “string” && vkey === "4")           
			// F4 Search Help             
// Check Sales Organization field 
var sorg=session.findById("wnd[0]/usr/ctxtVBAK-VKORG").text; 
if (sorg=="") {   
	session.findById("wnd[0]/sbar").setMessage("Fill in all required entry fields", "E");    
	return true; 

The first block will check whether a certain standard navigation button (like Back, Cancel or Exit) is pressed, the next one takes care of the F4 Help request. In these cases the script will be stopped and the standard transaction processing will take over.  

In any other case (like pressing ENTER or another navigation button such as Sales, Item Overview etc.), the content of the Sales Organization field is checked and if it is empty, an error message is displayed, exactly how the standard required field check is done.

If now the Sales Organization is left blank and ENTER is pressed, the result will be: 


With the above method, it is certainly possible to check other conditions as well. For instance, ensuring that the entered sales organization is numeric could be done with:

if (isNaN(sorg)) {    
	session.findById("wnd[0]/sbar").setMessage("Entry is not numeric", "E");    
	return true; 

 Or if only a certain maximum string length input should be allowed, then: 

if (sorg.length > 3) {    
	session.findById("wnd[0]/sbar").setMessage("Sales organization entry is too long", "E");    
	return true; 


This would certainly allow implementing a lot of different validation options in a flavor. In general however, it is probably not a good idea to include significant business logic this way. Simple “sanity checks” or verifications are OK, but anything more than that is not advisable. The reason is that a business process cannot rely on these validations being always enforced since if the transaction runs using the original screen, the flavor logic is not performed which may result in unexpected data in the database. The end result is thus not necessarily consistent from a business data point of view.

Related Content

Related Search Terms:

SAP Screen Personas, validation, input check

Related SAP Notes/KBAs