Hi
You should post how you call the fm updates CDHDR and CDPOS
Max
Michael,
What am I missing?
Which function module are you calling? <...>_WRITE_DOCUMENT ? Usually, the function module is called in the V2 update step, during COMMIT WORK, but it is possible to call it in other contexts, too.
Since you have CDPOS and CDHR entries, I suppose it's not the COMMIT WORK missing.
Can you isolate the problem and boil it down to a very small test report?
Regards,
Rüdiger
BTW: Try to avoid the database statement MODIFY. It's twice as expensive as UPDATE. Normally, you know in a transaction which entries are new and which are old ones that have to be updated (by keeping track of the changes with an update indicator or similar mechanisms).
Here is the function module being called and the parameters.
CALL FUNCTION 'Z_SD_MAINT_AVAI_WRITE_DOCUMENT'
EXPORTING
OBJECTID = '13000000000000000013120120511'
TCODE = SY-TCODE
UTIME = SY-UZEIT
UDATE = SY-DATUM
USERNAME = SY-UNAME
PLANNED_CHANGE_NUMBER = ' '
OBJECT_CHANGE_INDICATOR = 'U'
PLANNED_OR_REAL_CHANGES = ' '
* NO_CHANGE_POINTERS = ' '
UPD_ICDTXT_Z_SD_MAINT_AVAI = 'U'
O_ZDT_AVAIL = gs_old_final "old values
N_ZDT_AVAIL = gs_final "new values
UPD_ZDT_AVAIL = 'U'
* LV_OPT = ' '
TABLES
ICDTXT_Z_SD_MAINT_AVAI = T_CDTXT.
COMMIT WORK.
Hi
I suppose 13000000000000000013120120511 is the right key of the record you need to change, isnt' it?
Then you need to considere the change document elaborates the changing of he fields of your Z-table linked to data element with flag for CHANGE DOCUMENT set
Max
Thanks Max.....Yes, that is the right key.....There is one more field (which is the one I am changing).....Yes, I have the data element marked for "Log Changes"....so, the work area for "old" is 13000000000000000013120120511N and the work area for "new" is 13000000000000000013120120511Y. I am changing the field from "N" to "Y". Thanks, Mike
Hi
You don't call the fm in UPDATE TASK so I believe you don't need to use COMMIT statament, anyway a routine calling your fm should be created when you have generated your object in SCDO
Have you tried to check it?
Max
Hi Max....Yes, I have tested the FM in SE37 and still cannot get the old and new values to display.
Thanks,
Mike
Hi
Try to regenerate your object by SCDO
Max
Hi Max
I have re-generated the object in SCDO. I have re-tested the FM in SE37 and still does not display the old and new values. I'm wondering if I should delete the object and try to re-build it from scratch.
Thanks,
Mike
Hi Mike,
did you ever try to debug the function module? It's automatically generated, I know, but you wan't get a trauma when debugging it - it's still readable. Debugging is a thing which you would have to do on your own. It is no worth to discuss the single steps in the forum, no expert can give you the answer of a debugging session. If I were in your position, I would do it.
Another thing: Did you compare your call with the call of one of the standard modules, for example VERKBELEG_WRITE_DOCUMENT in module pool SAPMV45A. This is the call for the change documents of a sales order.
Regards,
Rüdiger
Hi Rudiger,
Thanks for the input. I have tried debugging the FM, but I tend to get lost in the routine for "Single Case"...It tends to call several functions....I may try it again though....I will try your second suggestion to compare with VERKBELEG_WRITE_DOCUMENT....Thanks, Mike
Hi
I've created several times custom objects for change document and no problem occurred, so iif you think all steps for generation were ok, yes....you should try to create it again,
Max
Hi,
Do the ObjectID fields (1 for the FM and 1 for ICDTXT) have to be the specific row key ? It seems like some documentation says you must provide the key and others seem to indicate you could put anything in there...........Also, when I specify the "Old" and "New" values do I need to provide all fields of the row or just the "Old" and "New" values ? Thanks....Mike
Hi
I've never transfered any value in CDTXT, both records (old and new) should be fully filled.
Max
Mike,
but I tend to get lost in the routine for "Single Case"...It tends to call several functions....I may try it again though....
When you reach the ...SINGLE_CASE, the following parameters have to be filled correctly:
When you come to ...SINGLE_CASE in the debugger: Are the fields filled in this way, in the expected way?
Also, when I specify the "Old" and "New" values do I need to provide all fields of the row or just the "Old" and "New" values ?
You always pass the complete structure, as it is/was after/before the user's change, as explained above.
Regards,
Rüdiger
Mike,
but I tend to get lost in the routine for "Single Case"...It tends to call several functions....I may try it again though....
When you reach the ...SINGLE_CASE, the following parameters have to be filled correctly:
When you come to ...SINGLE_CASE in the debugger: Are the fields filled in this way, in the expected way?
Also, when I specify the "Old" and "New" values do I need to provide all fields of the row or just the "Old" and "New" values ?
You always pass the complete structure, as it is/was after/before the user's change, as explained above.
Regards,
Rüdiger
Thanks Rudiger.....I will try the debugging again......Also, I noticed that after I test the FM using SE37 and run program RSSCD200 that the Table Name (in report RSSCD200) is always the name of the document change object and not the name of the specific Z-table.......Thanks, Mike
Rudiger.....I went back to debug the FM module again after your suggestion.....and....I found the problem !! I had changed the data element (the one for logging changes) to accept changes (in further characteristics), but did not ACTIVATE the element. I noticed it was inactive and as soon as i activated it, then the FM started working properly !!!......Thanks for your help....much appreciated !!
Max....Thanks for your input as well !!
Mike
