Successfactors Employee Central Deep Validations

It was bit hard for me to find information related to Successfactors Employee Central Deep Validations, when I started searching the topic on internet. Finally, I was able to find the information in bits and pieces scattered across various KBAs and handbooks. With this blog post, I aim to provide you with an overview of Deep Validations and which SAP documents to look for, to find out more details.

What are Deep Validations?

• These validations are hard coded, back-end server validations which check for specific values that are allowed for a particular field for which Deep Validations are supported.
  
• These validations do not come from any standard or custom Business Rules.
  
• These validations cannot be customized.
  
• These validations once enabled, cannot by bypassed in any way.

Which objects/portlets support Deep Validations?

Below are 4 area for which Deep Validations can be enabled in the system:

1. Address Validations
   
2. National ID Validations
   
3. Bank Account Validations
   
4. Payment Information Validations

How to enable Deep Validations in the system?

Go to ‘Company System and Logo settings’ and enable desired Deep Validations as shown below

Deep Validations – Deep Dive

Let us now understand in detail about each of these 4 type of Deep Validations. This section will help to answer below questions:

• What do they do?
  
• Where can I find more details about each of these validations?

Also Read: SAP SuccessFactors for Employee Central Payroll Certification Preparation Guide

Address Validations: Without enabling this validation, Postal/Zip code field is just another regular string field in Employee Address Portlet. But, once Address Validations are enabled, system will ensure that the Postal/Zip Code field in Employee Address is always consistent as per country specific norms for supported countries. Below are more details:

• This Deep Validation applies only to Postal/Zip code field and not to any other field in Employee Address.
  
• A prerequisite for Address Validations to work is that Postal/Zip Code field is not a picklist.
  
• Address Validations not only ensure that the Postal/Zip Code is populated in right format/length for supported countries but will also validate the field against certain hard coded criteria specific to some countries like Canada, Ireland, Taiwan, UK etc.

For example, Address Validations will ensure that Postal Code field for Canada is in format ANA NAN (example Toronto, Ontario Postal Code is M2P 2B8) Where A represents a letter and N represents a number. Address validations in this case will ensure below:

• Format and length of Postal Code must be as per above format
  
• The space given after the 3rd character is mandatory.
  
• The leading character should correspond to the postal sorting code of the province.
  
  • For Alberta, first letter is T
    
  • For Ontario, first letter is either of K, L, M, N or P
    
  • For Quebec, first letter is either of G, H or J
    
  • For British Columbia, first letter is V
    
  • For New Brunswick, first letter is E
    And so on….

If any of above validations is not met, system will not accept the Postal Code entered and will throw an error.

NOTE: Even with Address Deep Validation disabled in Company System and Logo Settings, you will notice that the Post/Zip Code field in Dependents Portlet is subjected to Deep Validations. This is expected system behavior as the switch for Enabling/Disabling Address Deep Validation is only for Employee Address Postal Code field. Dependent Address Postal Code field will always be subjected to Deep Validations, however there is an open enhancement request to fix this system behavior.

National ID Validations: Once enabled, this type of Deep Validation checks National ID entered against certain country specific hard-coded criteria for supported countries when National ID record is saved, not when National ID is entered.

For example, below hard-coded validations are applied to United Kingdom National Insurance Number (NIN) which has the format AA NN NN NN A where N represents number and A represents letter:

• The first digit cannot be D, F, I, Q ,U or V.
  
• The second digits cannot be D, F, I, O, Q, U or V.
  
• The last digit must be A, B, C or D

Please note that the regular expression used in CSF Succession Data Model to validate NIN number for UK is [A-Z]{2} [\d]{2} [\d]{2} [\d]{2} [A-Z]{1} which cannot perform any of the above checks. Also, altering regular expression in CSF Succession Data Model will not impact deep validations being performed in any way, therefore if National ID needs to be customized, then it is recommended to disable National ID Deep Validations. I choose UK NIN as an example as it has one of the simplest hard-coded validations to understand. You can refer Employee Central Country/Region Specifics handbook to see more complex validation for countries like Austria, Belarus, Brazil etc.

Bank Account Validations: With Bank Account Deep Validations enabled, certain country specific checks are performed on below fields in Payment Information portlet:

• Account Number
  
• Routing Number
  
• International Bank Account Number (IBAN)
  
• Business Identifier Code (BIC / SWIFT code)
  
• Country specific fields if applicable

For example, for Brazil below validations are performed:

• Account number can have maximum of 15 alphanumeric characters
  
• Routing Number can have maximum of 13 digits
  
• IBAN can have maximum length of 29 without spaces
  
• Country Specific field Bank Control Key can have maximum of 2 alphanumeric characters

Please note that contrary to other type of Deep Validations, which are hard-coded/server side and can only be controlled globally, Bank Account Deep Validation once enabled globally, can be re-configured and switched on or off at country and field level as well as they are not hard-coded or server side validations. For fields Account Number, Routing Number, IBAN and BIC standard Successfactors provided validations can be re-configured for each country via Manage Data>Country Specific Validation Configuration. Apart from switching on or off the validation for these fields at Country level, you can change the validations being done.

Payment Information Validations: Once Payment Information Deep Validations are enabled, below hard-coded checks are performed in Payment Information Portlet:

• Percentage check: no more than 100% in Percentage field
  
• Percentage check: no more than 100% overall calculated within same Pay Type (for example two entries for Pay Type Bonus)
  
• Check for duplicate record with same values within same Pay Type
  
• Check for empty Pay Type (Pay Type is a mandatory field)

To understand, what above validations mean, consider an employee having more than one Payment Information records in one time slice/period. An example below:

When you edit above Payment Information of an employee for a Pay Type = Payroll for which there are two records and make total of value entered in Percentage field more than 100, system will throw an error message. Also, if you try to enter more than 100% in any of the Payment Information record, system will throw an error message. Rest of the Payment Information Validations can be easily understood.