Using party role codes / partner functions is a not so exotic use case, e.g. the entry for a certain function might be needed.
There is something special to consider:
The role codes / partner functions are actually language specific. E.g. when logged on in English, the Bill To Party is shown as BP. When logging on in German, it would be RE (which stands for Rechnungsempfänger, I assume). So, what is then stored on the database?
Actually, the German one, we all have our roots :-). Or to be more precise, the key value defined in table TPAUM as key. In our example, this is RE, and the German translation is RE as well ;-). Here is the table data:
After all this history and background, what does this mean for conditions and the data crawler?
The answer is slightly different for using the filter function in the condition itself (or more precise, in the data access definition in the fields "Filter definition for Data Access Definition" ) and the filter in the data crawler.
Filter defined in Condition Data Access Definition
In the condition maintenance, you can just use the F4-Help with the values (where you will also see the backend value besides the description) and the conversion is done. So for our example above, when logged in in English, you could maintain BP. The backend however considers the RE-value. So you are save here.
Filter defined in the Data Crawler Steps
When using a filter in the data crawler steps, it´s a bit more technical:
In there, you have to maintain the backend value, the described conversion is NOT considered. So in our case, you would need to maintain RE. This might change in the future, but if so we would of course have the existing values in mind when introducing conversions.
The broader picture:
This principle applies to all values where conversions are applied, you can check if this is the case by having a look at the domain behind the data element used. In our example, the domain PARVW behind the data element PARVW which is used in our partner function for the party node has a conversion routine maintained, which can be found in the definition tab. Here, it is PARVW which indicates that the function modules
CONVERSION_EXIT_PARVW_INPUT N
CONVERSION_EXIT_PARVW_OUTPUT N
are called for the conversions. More info about the concept can be found here.
This little GIF shows how to find out if the data element might be affected by a conversion or not, starting at the BO node.
Hopefully that explained some background and helps in effective usage of filters in conditions.
There is something special to consider:
The role codes / partner functions are actually language specific. E.g. when logged on in English, the Bill To Party is shown as BP. When logging on in German, it would be RE (which stands for Rechnungsempfänger, I assume). So, what is then stored on the database?
Actually, the German one, we all have our roots :-). Or to be more precise, the key value defined in table TPAUM as key. In our example, this is RE, and the German translation is RE as well ;-). Here is the table data:
After all this history and background, what does this mean for conditions and the data crawler?
The answer is slightly different for using the filter function in the condition itself (or more precise, in the data access definition in the fields "Filter definition for Data Access Definition" ) and the filter in the data crawler.
Filter defined in Condition Data Access Definition
In the condition maintenance, you can just use the F4-Help with the values (where you will also see the backend value besides the description) and the conversion is done. So for our example above, when logged in in English, you could maintain BP. The backend however considers the RE-value. So you are save here.
Filter defined in the Data Crawler Steps
When using a filter in the data crawler steps, it´s a bit more technical:
In there, you have to maintain the backend value, the described conversion is NOT considered. So in our case, you would need to maintain RE. This might change in the future, but if so we would of course have the existing values in mind when introducing conversions.
The broader picture:
This principle applies to all values where conversions are applied, you can check if this is the case by having a look at the domain behind the data element used. In our example, the domain PARVW behind the data element PARVW which is used in our partner function for the party node has a conversion routine maintained, which can be found in the definition tab. Here, it is PARVW which indicates that the function modules
CONVERSION_EXIT_PARVW_INPUT N
CONVERSION_EXIT_PARVW_OUTPUT N
are called for the conversions. More info about the concept can be found here.
This little GIF shows how to find out if the data element might be affected by a conversion or not, starting at the BO node.
Hopefully that explained some background and helps in effective usage of filters in conditions.
- SAP Managed Tags:
| User | Count |
|---|---|
| 10 | |
| 8 | |
| 8 | |
| 5 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 2 |
