READ_TEXT no data retrieved

[jeff_broodwar]

Hello Experts,

Good day,

I recently had a requirement using read_text FM. I tried several documents using objects like EKPO, AUFK and I didn't have issues getting text data. Now in production, we have new data using object VBBP but it doesn't return any text. I tried checking table STXH and found records for EKPO and AUFK objects... Now I tested the documents that used VBBP object but they don't have records in STXH... I tried to input VBBP only and found a lot of entries. The documents used in production don't have record in STXH..

Is there another table that we should validate other than STXH when calling READ_TEXT FM?

Thank you.

Jeffrey

[jeff_broodwar]

Hello Everyone,

I just received confirmation from my colleague functional that the zeroes must have been erased when they copied the batch of documents. Hence the added (2) zeroes before the document is the format for that object (VBBP) and ID (0001). No need for conversion exits. Case closed.

Thank you for all your suggestions and help. Appreciate it.

[Abinathsiva]

Hi,

share the code and check value of text ID passed in debug mode

[Sandra_Rossi]

I don't get you. Why do you think you have to work with "VBBP", if you don't find it in table STXH? Why do you say "don't have records in STXH...found a lot of entries"? Are you aware that object IDs are usually prefixed with zeroes? ("alpha" conversion)

[jeff_broodwar]

The report is a universal read_text report where it can input any document and fetch text data into alv output. I have test data having object as EKPO and AUFK during testing and they all returned value. Now in production we have data that uses VBBP...when I checked it didn't return any text data... I tried to check table STXH cause it's the first step in my validation where I check entries in selection screen and check STXH if it exists first 2 objects (EKPO and AUFK) didn't have issues, but when I used the data provided in QE (same with prod) VBBP didn't return any value in read_text and stxh...functional is expecting to get some data from the documents with VBBP as object.

the part when I said found a lot of entries is that, I tried to check STXH not using the document numbers provided but just checked if there are maintained entries having VBBP as object and found lots of entries. I just dont get it why the functional is expecting the program to retrieve text data even if trying to check STXH with those document numbers provided and runing FM read_text manually with those numbers didn't get any result...

[BaerbelWinkler]

Hi again Jeff,

READ_TEXT requires input for four fields: TDID, TDOBJECT, TDNAME and TDSPRAS.

What is in TDNAME depends on TDOBJECT. In many cases it's simply the key of that table, possibly with leading zeros and otherwise unformatted. But, with some TDOBJECTS - and IIRC than VBBP is one of them - TDNAME is actually a combination of several fields. I think it is a concatenation of client, sales-org and then the document number (I'm not 100% certain whether or not client is included but I'm sales-org for sure is).

Here is an example: you are looking for document number '1234567890' in client '111' and for sales-org '8888'. You'll then have to look for TDNAME '11188881234567890' and not just '1234567890' (or '88881234567890' if the client isn't relevant). In addition you'll have to know which language the sales document and therefore long text was stored, something which might not be readily apparent as it often depends on either who entered the text (i.e. a user logged in with German) or who needs to be able to read the text (i.e. the delivery service in the receiver's country which might require language French).

Hope this helps!

Cheers

Bärbel

[BaerbelWinkler]

jeff.broodwar

After checking in our system, here is some more information specifically about VBBP entries for long texts.

For TDOBJECT "VBBP" (which is for sales document line items) the value in TDNAME is a concatenation of the 10-character long VBELN and the 6 digits of the line item. This is how entries in STXH look like with VBELN highlighted in yellow and the line item number in red:

In order to find the actual long text for this entry you have to provide exactly this information like shown here via SE37 for READ_TEXT:

If you don't include the "000010" you'll get a "NOT FOUND" error, likewise if you look for an entry with another language than "EN" or ID "0001". READ_TEXT does not accept wildcards in these fields.

Here is some code to get around this by using READ_MULTIPLE_TEXTS instead:

SELECT-OPTIONS: s_obj         FOR stxh-tdobject OBLIGATORY,
                s_id          FOR stxh-tdid     OBLIGATORY,
                s_spras       FOR stxh-tdspras  OBLIGATORY,
                s_tdname      FOR stxh-tdname   OBLIGATORY.

  DATA: lt_name_ranges     TYPE tspsrname,
        ls_name_ranges     LIKE LINE OF lt_name_ranges,
        lt_object_ranges   TYPE tspsrobj,
        ls_object_ranges   LIKE LINE OF lt_object_ranges,
        lt_id_ranges       TYPE tspsrid,
        ls_id_ranges       LIKE LINE OF lt_id_ranges,
        lt_language_ranges TYPE tspsrlang,
        ls_language_ranges LIKE LINE OF lt_language_ranges.

  "Shift select-option content into FM-parameters
  LOOP AT s_tdname.
    ls_name_ranges-sign   = s_tdname-sign.
    ls_name_ranges-option = s_tdname-option.
    ls_name_ranges-low    = s_tdname-low.
    ls_name_ranges-high   = s_tdname-high.
    APPEND  ls_name_ranges TO lt_name_ranges.
  ENDLOOP.

  LOOP AT s_obj.
    ls_object_ranges-sign   = s_obj-sign.
    ls_object_ranges-option = s_obj-option.
    ls_object_ranges-low    = s_obj-low.
    ls_object_ranges-high   = s_obj-high.
    APPEND  ls_object_ranges TO lt_object_ranges.
  ENDLOOP.

  LOOP AT s_id.
    ls_id_ranges-sign   = s_id-sign.
    ls_id_ranges-option = s_id-option.
    ls_id_ranges-low    = s_id-low.
    ls_id_ranges-high   = s_id-high.
    APPEND  ls_id_ranges TO lt_id_ranges.
  ENDLOOP.

  LOOP AT s_spras.
    ls_language_ranges-sign   = s_spras-sign.
    ls_language_ranges-option = s_spras-option.
    ls_language_ranges-low    = s_spras-low.
    ls_language_ranges-high   = s_spras-high.
    APPEND  ls_language_ranges TO lt_language_ranges.
  ENDLOOP.

  CALL FUNCTION 'READ_MULTIPLE_TEXTS'
    EXPORTING
      name_ranges     = lt_name_ranges
      object_ranges   = lt_object_ranges
      id_ranges       = lt_id_ranges
      language_ranges = lt_language_ranges
    IMPORTING
      text_table      = gt_text_lh
      error_table     = gt_error_lh
    EXCEPTIONS
      OTHERS          = 2.

Any of these ranges used as importing parameters in READ_MULTIPLE_TEXTS can contain wildcards so you can provide TDNAME = '0000000001*" and it'll find the entry you are looking as long as you properly restrict by TDNAME and TDID (otherwise you might also get many false hits for completely different entities).

The returned table GT_TEXT_LH contains one item per corresponding entry in table STXH with the TDLINES available in table form with this deep structure. So you'll need to loop through both to build your ALV-output, something like this:

  DATA: ls_tdlines TYPE LINE OF text_line_tab.

  LOOP AT gt_text_lh INTO gs_text_lh.

    CLEAR gs_out.

    gs_out-tdname   =  gs_text_lh-header-tdname.
    gs_out-tdobject =  gs_text_lh-header-tdobject.
    gs_out-tdid     =  gs_text_lh-header-tdid.
    gs_out-tdspras  =  gs_text_lh-header-tdspras.
    gs_out-tdfuser  =  gs_text_lh-header-tdfuser.

    LOOP AT gs_text_lh-lines INTO ls_tdlines.

      IF ls_tdlines-tdline IS NOT INITIAL.

        ADD 1 TO gs_out-linenum.
        gs_out-tdline = ls_tdlines-tdline.

        APPEND gs_out TO gt_out.

      ENDIF.

    ENDLOOP.
  ENDLOOP.

Hope this helps!

Cheers

Bärbel

[jeff_broodwar]

Thanks Barbel, ours use 2 zeros aside from document and line item number.

[BaerbelWinkler]

jeff.broodwar

The "2 zeros" are most likely caused by your number range for the document number only needing 8 digits but internally, it is still stored with 10 digits. If you have e.g. SE16 set to respect conversion exits, SAP will strip these leading zeroes from what gets displayed in the list. In a case like this it's often a good idea to switch off the conversion exits to see the raw data as this is what is relevant for the content in TDNAME and what needs to be specified in the input parameter(s). Go to "Settings --> User parameters --> Data Browser to remove the flag (or set it again).

With "respect conversion exit", the document number looks like this in SE16 in VBAP for the example shown above as VBELN is a character field with a length of 10 and the conversion exit ALPHA is active:

When I switch conversion exits off in the user options, it looks like this:

"Your" users will see the document number without the leading zeroes in their transactions and therefore look for the wrong entries for the long texts and you'll have to make them aware of the "missing leading zeroes". In the program I created which utilizes READ_MULTIPLE_TEXTS I try to explain this in the online documentation:

"The field "Text Name" contains the actual key for the data you are interested in. This can for example be a material or equipment number, a sales order or anything else for which long texts exist. The key will need to be entered in the internal format which means that for example a material number needs to be entered as "000000000012345678" instead of as "1.234-567.8"."

I also explain this:

"You need to know the technical keys for the long texts you want to retrieve. This information can sometimes be found from within the transaction where they are entered or displayed. If this is not available, check with the IT-specialist for your process area."

[Dominik_Tylczynski]

Hello jeff.broodwar

If you don't know how to call READ_TEXT in a specific scenario .e.g to read a long text of an SD invoicing document, here is an approach that works for me. SAP standard transactions use READ_TEXT. So you can put a break-point in READ_TEXT and display a long text in a SAP standard transaction. Then the execution will stop on READ_TEXT and you can examine the input parameters under the debugger. That always helps me.

Best regards

Dominik Tylczynski

[jeff_broodwar]

Thank you for all your comments.. The issue is, the functional is trying some document numbers with ID VBBP and these documents don't exist in STXH reason why the program is not returning any values..I also checked calling the FM manually and none of these documents are found...

Is this still ABAP issue? did I miss something here? The logic is to get entries inputted in selection screen, validate it via table STXH and feed them to READ_TEXT. It passed tests and transported to Production. We just found some data in production that is not in table STXH nor returning value via FM call READ_TEXT..

[ponrajasekharan]

Hi

Check with functional for the particular combinations are configured . So that text could be maintained . Check the Text ID value , Language, Text Name through display T code . Check text maintained for the combinations if not maintain .

[BaerbelWinkler]

jeff.broodwar

Hi Jeff,

please see my comment above.

[jeff_broodwar]

Hello Thankaswamy,

Thanks for the info, ours use 2 zeros plus document plus item number. I tried SE75 where ID and objects are configured but didn't find the formatting. Is there a tcode where this can be seen?

Thanks.

[ponrajasekharan]

Hi Jeff,

Click the DETAIL Button and GOTO->CHANGEEDITOR to view .

Click the LOG button to view the Text logs.

[Sandra_Rossi]

I'm afraid nobody understands your issue. Could you add screenshots for one example please? (please show the screenshot of SE16 selection too)

[jeff_broodwar]

Thank you Sandra for your time, I was perplexed to but it was my only information at the time. I did some investigation and received further info from functional please see my feedback to all below. Thanks again appreciate it.

[jeff_broodwar]

Hi Everyone,

first of all thank you for spending time with me on this really appreciate the time. Going back to the topic. I learned that the document nos. exist in our QE environment. it has a different convention though. Example below:

Functional provided me this number format for documents having object VBBP:

70115689000010
70115690000010
70115694000010
70115695000010
70115696000010

normally it's just document + line item number, if I want to verify if it's existing i remove item number example

70115689 and go to va03 this will display the information there.

However I learned to see them in STXH and be able to get text data when running se37 READ_TEXT I need to add 2 zeros before the provided number ex: 0070115689000010. This format will get record from both STXH and SE37.

Now, I thought I can use ALPHA_CONVERSION FM for this, thead-tdobject is 70 characters (added 60+ zeros before document) and using vbeln is just 10 characters so truncated the document instead. (Both are not good solution so moving on..)

Question is, is there a transaction like SE75 where this format is being maintained? I see now that it's not always document number + item number. My case is using 2 zeros + document + line item number.

Hope to get feedback asap.. thanks friends.

Jeffrey

[BaerbelWinkler]

jeff.broodwar

See my response above - you'll have to make your users aware of the leading zeroes and that they always have to provide a document number with a length of 10 (as an aside, you shouldn't create new answers to respond to feedback received from others, but instead add comments to the answers already provided or as comments to your original question at the top).

[jeff_broodwar]

Thanks Barbel, I was going to "To All" comment but rules are rules right. Thanks.

[jeff_broodwar]

Hello Everyone,

I just received confirmation from my colleague functional that the zeroes must have been erased when they copied the batch of documents. Hence the added (2) zeroes before the document is the format for that object (VBBP) and ID (0001). No need for conversion exits. Case closed.

Thank you for all your suggestions and help. Appreciate it.