The common task of changing the long text of a production order’s operation can bring some surprises that were discussed several times at Sapfans ABAP forum. Composing right text ID and key to feed the READ_TEXT and SAVE_TEXT functions is the first step. If you are unsure on that, some tips are provided in Sapfans ABAP FAQ, or you can use the debugger as an alternative. All that is relatively straightforward.
The first problem that is usually encountered is that after updating the long text with the function SAVE_TEXT, the new text is not visible in standard SAP transactions like CO03. The new text can be read with the function READ_TEXT though. The trick is that SAP uses the “long text exists” indicator, the field TXTSP in the table AFVC. To make the text “visible” to standard transactions, we have to set the TXTSP value to the current language (or the text’s language). Unfortunately, this has to be done with the direct UPDATE on the AFVC – there are no known workarounds.
Another problem can be seen when the same order is processed by users that use different languages. While SAP allows to store the long text for the same operation in several languages, actually, only one text object will be active at the same time in regard to standard transactions – the object in the last saved language. That means, when SAP writes the text back, the TXTSP will be overwritten with the current language (say, language A). If the next user is working in another language (language B), SAP will present the text in the “first” language (A) in the CO03 (even if the text in language B exists!). But after saving, the text will be written in the new language and TXTSP will be set accordingly.
So, when working with long texts directly, you have to read with READ_TEXT using the language stored in TXTSP, NOT with the current language. When saving, you save in the current language and set the TXTSP to the current language. This way you are consistent with what SAP does and this will prevent you from surprises in a multilingual environment.