Skip to end of metadata
Go to start of metadata


Since my initial days, in SD consulting, condition technique has been my area of interest and I wonder at what state of mind the guy could have been when he was conceptualizing the condition technique. A great tool, technique and beyond these, a state of mind to bring such a technique into SD has helped in enabling various functionalities in SD. Here is one scenario where we have achieved the functionality demanded by the customer using the same concept.

Requirement and the Challenge

Actually we were working on outputs, the email ones. We were taking it easy until the customer came one day and said that he would like to send the PDF of the invoice through an email with a content in the email. By our conventional thinking, we automatically got into the text element concept and to fill the text element in the email. We intimated the same to the customer and he saw us with his characteristic sarcasm. He expressed his requirement in detail. He said the content is not a constant text, it has to vary. The problem is that it has to vary based on certain criteria!!!. He said he would like to maintain one text for a specific customer, another text for a sales area, a third text for a sales organization and a fourth text when the sales order is for a specific sales order with a specific distribution channel. Customer was happy that he has told the exact requirement and we were clueless. How can one enable a email text in an output type which actually is variable based on certain criteria. We thought of hard-coding the criteria in the program and for each criteria we will fetch a different text element and print the same as email body text. We decided on the solution and calculated how many text elements we would be requiring. For 17 sales organizations (whole of Europe), multiple distribution channels, various sales groups, we arrived at a total of 540+ text elements to be created!! 

Design and Development

We decided that the text element approach is not going to help. That was when we brainstormed and arrived at a solution which is still used as a benchmark by the customer to show to the new resources on how a design should be. We looked into the concept of condition technique, the capability of the output program, and the use of text determination, hybridized all of them to provide the solution for the requirement.  
We created a pricing condition type, but the pricing condition type was not assigned to any of the pricing procedures. Because of this there is no impact on pricing due to this condition type.

We have created a text id for the condition type in VOTXN. Assigned the text ID to the procedure assigned to the condition type and ensured that the configuration of text determination for condition type is error free.

An access sequence is assigned to a condition type and the access sequence had all the combinations of fields for which the text had to be different in the email. We had one condition table which had Sales org / Distribution Channel / Division / Sales Office / Customer and all these fields were mapped as item fields in the condition tables. The table was named as say 832.

Now we have created the condition record for the condition type with the correct validity dates with a junk value. The value is not going to have any implication as it is not there in any of the pricing procedures. Once the value is maintained, we went to the condition texts area and maintained the texts. 

Now comes the beauty of the design

In the program, we have checked whether a condition record exists for various combinations of the fields in the condition table 832.  For example, first Sales Org/ Distribution channel /Division combination was checked. If it is not there, then sales org / customer was checked, if again not available, sales area / sales office is checked. Beyond this any other combination is considered to be invalid and hence for those combinations, the data was not maintained. For the transaction data, if the table A832 has the condition record, we just picked up the condition record number and the text maintained for that record is just fetched using the function module READ_TEXT. The technical aspects of fetching the text ID, object , text name was comfortably handled by the technical consultants.

So now whenever the output type is triggered in the application, the program will fill all the details and before sending the email, it will look into the table A832 for condition record for the possible valid combinations of transaction data and if found, will fetch the text maintained for that combination and then trigger the email with this text as the email text and the document output as the PDF attachment. 


The advantages of this approach over the traditional text element approach are

1.      Very less data maintenance and coding

2.     Extremely effective solution considering the development and testing effort required for enabling the functionality

3.     It is an ideal hybridization of the standard SAP functionalities to an unthinkable extend to fulfill the customer requirement.

4.      This approach was further extended to various other applications (V2, V3) by just changing the text ID and the valid combinations

5.      One reusable function module was created to fetch the text for the valid combination and it could be called wherever possible. This could not have been possible with text element approach.

1 Comment

  1. Hi,

    Really appreciate the approach taken to resolve the issue.

    Thanks for sharing this with community.



    Amitesh Anand