Substitutions and validations are an inevitable part of a SAP project. You always need to chec
k that the document is entered correctly, or replace values in certain fields.
SAP allows you to write subs and vals in an easy-to-use interface similar to the constructor. A few mouse clicks, a few keystrokes and you’re sorted.
But how often do you need to amend validations or substitutions back and forth to allow something restricted to happen? Often? Then probably we need to look at the way your subs and vals are coded.
Say your validation is about tax codes which you created after the tax rate change. It says
Obviously, V1, V2 and V3 are old tax codes which you should not use after the tax switch date.
But now and then an odd invoice comes for services which were provided when the old tax rate was in use. It should be posted with one of the old tax codes. What do you do in this case? You need to create another transport, change validation and move the new validation across the systems’ landscape to the Production system. Then you need to do same process again to put the restrictions back.
Is it possible to optimize the process and simplify both the support process and your own life?
SAP allows you to use sets in validations. The benefit of using sets is that they can be changed directly in the Production system without any transports.
First, you need to create sets in Development: transaction code GS01 helps you here.
Second, you use sets in your validations. For the example above, you can rewrite the validation like this:
Third, you move your validation across to Production. Once only!
Then you only need to maintain sets in the transaction code GS02 if restrictions are to be temporary lifted, or more document types or tax codes added.
Clear? Surely yes!