Problem in modifying internal table

[Former Member]

Hi,

This is my requirement...

XVBRK is an internal table .

If there are three XVBRK lines which has same PIN ( XVBRK-ZUKRI) then for the 1st line modify XVBRK-VBELN with XVBRK-ZUKRI. Do not modify the XVBRK-VBELN field of 2nd / 3rd line.

Please suggest how to handle this kind of requirement...I need to update the internal table rows but cannot use sort in this case as XVBRK is a system internal table. Hence, sorting that is giving a warning....

Please also note that, this particular situation comes in an enhancement when VF01 is triggered. Hence, XVBRK has VBELN empty when i encounter it... all the rows have vbeln value of $0001 like this...So cannot use that as key aswell.

Some piece of code will be very helpful....

[Former Member]

Hi

You can create a line type of xvbrk which will act as work area .Now you can read the line of xvbrk for the given PIN in this workarea.Since work area can hold a single line it will contain only the fisrt line out of three lines with same pin.Modify vbeln and then you can modify the internal table using this work area.

Thanks!!

[Former Member]

Hi Subhajit,

Create another table with the same structure of XVBRK i.e. XXVBRK.

Please check the below peice of code.

XXVBRK[] = XVBRK[].
SORT XXVBRK BY ZUKRI.
LOOP AT XXVBRK.
ON CHANGE OF ZUKRI.
XXVBRK-VBELN = XXVBRK-ZUKRI.
MODIFY XXVBRK TRANSPORTING VBELN.
ENDON.
ENDLOOP
XVBRK[] = XXVBRK[].
REFRESH XXVBRK.

Regards

DKS

[Former Member]

NEVER sort an internal table in SD/LE...there are I versions of those tables and when the X, Y and Index versions no longer match up you will get an ABEND. A SORT is to be avoided!

VBELN will be internal order number, like $00000000n, before user commits to SAVE... loop at XVBRK and collect the possibilities for your field ZUKRI into another internal table in your exit... Then loop at XVBRK again. Read your internal table with ZUKRI...update XVBRK. Delete the row from your internal table, so that when another row in XVBRK has the same value, it will find nothing in your internal table, and your code can skip the modification of the XVBRK row.

Of course, what you're doing will probably actually be replaced by SAP with the real document number during SAVE, so it's a moot point....If SAP doesn't replace it, you'll probably get an abend...we don't/should NOT mess with SAP document numbers!