problem after END-OF-SELECTION statement

[ILIAN_Grigorov]

He gurus,

There is an Y program in our system, which reads the standard logical database PYF.

PYF is in its original variant, and has never been modified.

After the statement END-OF-SELECTION. several variables became filled with ####.

For example reguh-waers is filled with the correct currency, but after the statement

becomes ####.

It was not like that before. It happened after implementing some SAP notes.

The SAP supports does not tell me, wheather we should change the program, or there

is another problem, which should be fixed by SAP.

Please advise

10x in advance

[ILIAN_Grigorov]

He gurus,

There is an Y program in our system, which reads the standard logical database PYF.

PYF is in its original variant, and has never been modified.

After the statement END-OF-SELECTION. several variables became filled with ####.

For example reguh-waers is filled with the correct currency, but after the statement

becomes ####.

It was not like that before. It happened after implementing some SAP notes.

The SAP supports does not tell me, wheather we should change the program, or there

is another problem, which should be fixed by SAP.

Please advise

10x in advance

[Former Member]

Ilian,

Just check the part of the code after END-OF-SELECTION. There will be LOOP statement and in this check if there are any AT commands. If you want, just transfer the data from the LDB statement to WA and manupulate with this WA.

Regards,

Hardik Mehta

[ILIAN_Grigorov]

Hi Hardik Mehta,

Thank you very much for the reply. I am not very familiar with ABAP, so I just considered a

workaround like:

reguh-waers = 'BGN'.

just after the statement END-OF-SELECTION, and now it works OK.

Thanks

Ilian

[RaymondGiuseppi]

Why do you access the REGUH (or REGUP) structure in the END-OF-SELECTION. Your report MUST have stored the related data in an internal table in the GET events, read Example for Reporting Events.

GET REGUH.
" Here do something when new run of payment was read
" use fields of REGUH, not REGUP
GET REGUP.
" Here do something with the line itels of the run
" use fields of REGUH and REGUP
GET REGUH LATE.
" Here do something at end of run
" use fields of REGUH, not REGUP
END-OF-SELECTION.
" Her do something general like display of internal table in ALV or switch to LIST PROCESSING
" don't use fields of REGUH or REGUP

Regards,

Raymond

[ILIAN_Grigorov]

This is not my code. After the END-OF-SELECTION statement there is a call to a sapscript form:

CALL FUNCTION 'OPEN_FORM'
            EXPORTING
                 form     = t042e-zforn
                 dialog   = 'X'
                 device   = 'PRINTER'
                 language = 'W'
            EXCEPTIONS
                 form     = 1.

This form does not print a currency correctly if reguh-waers is not filled with BGN. It does not know where to put the decimal dot, and shows 100x bigger amount. Actually it was working before we implement sap notes 1138346  1267192.

Regards

Ilian

[RaymondGiuseppi]

Better than using a hard-coded value, better save the REGUH structure in GET REGUH (or GET REGUH LATE) and recover it from saved structure when required.

What is your R3/ECC6 version, as I don't see anything in those notes that could cause your problem (FM J_1B_SD_BI_SPLIT_NEW_DOC) ?

Regards,

Raymond

[kiran_k8]

ILIAN,

If I not wrong this program is related to Payment run,Payment Methods-BOLETO and should be a copy of the Standard Program.It should not be because of applying SAP Notes and is the expected behaviour when we use GET statements while reading logical databases.As suggested by Raymond,you can have a workaround as anyway it is a Y program.

Frankly speaking never copy SAP standard programs related to Payments as internally it updates a few standard database tables.And we will never know if they are getting updated incorrectly unless we encounter a issue.If the objective is to create a Payment file (not DMEE) for bank processing then this can be very well achieved by a Z program (without copying the standard prog).

K.Kiran.