Golden tips while transporting substitutions/validations
Reader Note: Below tips are by assuming, reader is aware of substitution/validation concept in SAP.
Substitution and validation is one of the most important function which many functional consultants are not comfortable with.
Substitutions are used to substitute the transaction data based on custom business logic. Data source can be a constant value, field to field assignment or user exit.
Validations are used to do custom business specific validations (Which is not covered by standard SAP).
Both are called during document posting.
There are already couple of articles in SCN explaining the details of substitution and validation. So, I will not go into details on what is the purpose and how to use them.
I would like to stress on points to be considered while transporting the changes related to Substitution/Validation.
1. Compare the existing steps in production system with development system. This has to be done manually for each step as there is no version comparison option. There is a high risk that someone can do change in development and leave it without reverting. As the change is not automatically recorded in TR, unintentional changes would get moved to production system when a new change is moved.
2. Only one step in validation/substitution can’t be included in TR. When we transport a validation/substitution, all the steps included in a folder would get transported (Even though there are no changes). Due to this, before releasing the TR, we need to make sure that all the steps in validation/substitution in production system and in the development system are in Sync. If this is not done, there is chance that unintentional validation/substitution steps will get transported to production system which may have serious implications as these are called for every FI document creation.
Other alternative could be to delete the entries manually from TR which are not related to our change (Best option I feel). But, this has to be done with utmost care as required entries shouldn’t be deleted.
3. If, any change is being made in user exit (for validation/substitution), make sure that all the related transports move to production system at same time. This avoids any dumps that can occur due to syntax errors.
4. When validation/substitution is moved from one system to another system, it is advised to run the program RGUGBR00 (validations/substitutions regeneration). This ensures proper linking of the changes done in customization/user exits.
5. After moving the TR, do monitor the system proactively to see if any dumps are happening because of substitution/validation changes.
Please feel free to comment/add any other suggestions which are missed here