03-17-2008 9:32 PM
Hi,
I have requirement to track changes of some fields of couple of custom tables.
When I looked at the SAP help, I found the following...link
http://help.sap.com/saphelp_erp2004/helpdata/EN/2a/fa015b493111d182b70000e829fbfe/frameset.htm
Here under Change Documents > Procedure I found the following
To use the change document functionality in your application, proceed as follows:
1. Define the change document object
2. Check in the Dictionary, whether the data elements of the fields which are to be logged are flagged appropriately.
3. Generate the update.
4. Program the appropriate calls in your program.
I understood the first two steps and I am assuming that the first two steps are OK for my requirement.(Please confirm )
What are 3 and 4 ? When they will be used ?
Your help will be appreciated.
Thank you,
Surya
03-18-2008 1:28 AM
okay,
How do you change the values in fields of Z-Table , I am assuming you are going to do it with some Z-transaction. It is there in that Z-transaction , you will need to call the change objects ( step 3 & 4) .
Yes you will need to program it yourself , so that the change docs are created whenever the values of certain fields are changed.
SAP does not create those automatically .
03-18-2008 2:33 PM
Hi Vaibhav,
Thanks for you quick response. I am not sure of how these tables are changed. I need ask my BA about this. I assummed that by doing steps 1 & 2, SAP will automatically record changes like update, delete, insert of field values in tables CDHDR and CDPOS.
I have 3 tables to track:
Should I create one change document object for all the three tables or seperate change document objects for each table ?
Also, Is there any check list of items that I should know from the BA, before starting this work ?
Thank you,
Surya
03-18-2008 2:42 PM
Hi
How to create your change document object depends on how you update the records of your Z-TABLE.
So u need to run the trx SCDO in order to create your Z-object, after generating it the system'll create a function module in order to insert the modification in CDHDR e CDPOS tables.
Anaway the system doesn't call that fm automatically, but you need to insert the calling in all your programs where the Z-TABLES are updated.
Max
03-18-2008 2:43 PM
Check this....
Basically, there are 2 main tables (not enough well known) which can be accessed through ABAP or Function Module.
So nothing technically pointed in this blog, only just very useful!
Following the classical SAP table structure, youll find CDHDR (Change document header) and CDPOS (Change document items). ( HR Module: PCDHDR and PCDPOS )
They can be read using a classical Select statement or using respectively the following FM
'CHANGEDOCUMENT_READ_HEADERS'
'CHANGEDOCUMENT_READ_POSITIONS'
As those tables log the SAP document changes, we can imagine how much large they are, especially CDPOS ! And unfortunately, as this one is a cluster table, no Join query is possible.
And this is the main inconvenient; youll have to be very careful in building your query, filling the key field the better you can. ( Tips : Use the For All entries Statement )
Now in order to illustrate, well see through 2 different examples, how being aware of the utility of these tables can be interesting and useful.
Sample Code
1 - I want to know, for statistic reasons, how many sales orders were blocked for Credit limit ( Delivery block status to 01 ) and then released during a period.( using Select Statement )
REPORT z_stat_so_blocked .
TABLES : cdhdr, cdpos.
DATA : BEGIN OF t_cdhdr OCCURS 0,
objectid LIKE cdhdr-objectid,
changenr LIKE cdhdr-changenr,
udate LIKE cdhdr-udate,
username LIKE cdhdr-username,
END OF t_cdhdr.
DATA : BEGIN OF t_cdpos OCCURS 0,
objectid LIKE vbap-vbeln,
END OF t_cdpos.
*-
SELECT-OPTIONS : period FOR cdhdr-udate OBLIGATORY.
*-
START-OF-SELECTION.
CLEAR cdhdr.
SELECT objectid
changenr
udate
username
INTO TABLE t_cdhdr
FROM cdhdr
WHERE objectclas EQ 'VERKBELEG' "This is the Class
"for Sales Order
AND udate IN period
AND tcode EQ 'VA02' " T-code
AND change_ind EQ 'U'. " Update
SORT t_cdhdr BY objectid.
CHECK NOT t_cdhdr[] IS INITIAL.
CLEAR cdpos.
SELECT objectid
INTO TABLE t_cdpos
FROM cdpos
FOR ALL ENTRIES IN t_cdhdr
WHERE objectclas EQ 'VERKBELEG'
AND objectid EQ t_cdhdr-objectid
AND changenr EQ t_cdhdr-changenr
AND tabname EQ 'VBAK'
AND fname EQ 'LIFSK' " Field name for Delivery Block
AND chngind EQ 'U' " Update
AND value_old EQ '01'.
SORT t_cdpos BY objectid.
LOOP AT t_cdpos.
WRITE : / t_cdpos-objectid.
ENDLOOP.
END-OF-SELECTION.
*2 - I want to display Material Master changes occured in a period( using FM's *
REPORT ztrace_material.
TABLES: mara,
cdhdr,
cdpos.
SELECT-OPTIONS: period FOR cdhdr-udate,
name FOR cdhdr-username,
material FOR mara-matnr.
DATA: wchangenr LIKE cdhdr-changenr.
DATA: wtext(80) TYPE c.
DATA : BEGIN OF t_mara OCCURS 0,
matnr LIKE mara-matnr,
END OF t_mara.
DATA: BEGIN OF icdhdr OCCURS 50.
INCLUDE STRUCTURE cdhdr.
DATA: END OF icdhdr.
DATA: BEGIN OF icdshw OCCURS 50.
INCLUDE STRUCTURE cdshw.
DATA: END OF icdshw.
DATA : w_matnr LIKE mara-matnr.
DATA: BEGIN OF itab OCCURS 50,
matnr LIKE mara-matnr,
changenr LIKE cdhdr-changenr,
udate LIKE cdhdr-udate,
utime LIKE cdhdr-utime,
username LIKE cdhdr-username,
chngind LIKE cdshw-chngind,
ftext LIKE cdshw-ftext,
outlen LIKE cdshw-outlen,
f_old LIKE cdshw-f_old,
f_new LIKE cdshw-f_new,
END OF itab.
FIELD-SYMBOLS: <value_old>, <value_new>.
SELECT matnr
INTO TABLE t_mara
FROM mara WHERE matnr IN material.
clear t_mara.
LOOP AT t_mara.
* Get Changes
PERFORM changedocument_read.
ENDLOOP.
LOOP AT itab.
CLEAR: wtext, w_matnr.
CASE itab-chngind.
WHEN 'U'.
wtext(50) = 'Updated field'.
wtext+51 = itab-ftext.
CONDENSE wtext.
WHEN 'D'.
wtext = text-021.
WHEN 'E'.
wtext(5) = itab-ftext.
wtext+51 = ' text : E'.
CONDENSE wtext.
WHEN 'I'.
wtext = ' text : I'.
ENDCASE.
RESERVE 5 LINES.
IF wchangenr NE itab-changenr.
wchangenr = itab-changenr.
w_matnr = itab-matnr.
WRITE:/ itab-udate UNDER 'Change Date',
itab-utime UNDER 'Time',
itab-username UNDER 'User Name',
itab-matnr UNDER 'Material No',
wtext UNDER 'Changes'.
ELSEIF itab-matnr NE w_matnr.
WRITE:/ wtext UNDER 'Changes'.
ENDIF.
CASE itab-chngind.
WHEN 'U'.
ASSIGN itab-f_old(itab-outlen) TO <value_old>.
ASSIGN itab-f_new(itab-outlen) TO <value_new>.
WRITE: / text-023 UNDER 'Changes',
<value_old>.
WRITE: / text-024 UNDER 'Changes',
<value_new>.
WHEN 'E'.
ASSIGN itab-f_old(itab-outlen) TO <value_old>.
WRITE: text-023 UNDER 'Changes',
<value_old>.
ENDCASE.
SKIP.
ENDLOOP.
TOP-OF-PAGE.
WRITE: / sy-repid,
50 'Material Changes'.
Skip to line 4.
ULINE.
WRITE:/01 'Change Date',
15 'Time',
30 'User Name',
45 'Material No',
70 'Changes'.
ULINE.
*&--------------------------------------------------------------------*
*& Form CHANGEDOCUMENT_READ
*&--------------------------------------------------------------------*
* text
*---------------------------------------------------------------------*
FORM changedocument_read.
CLEAR cdhdr.
CLEAR cdpos.
cdhdr-objectclas = 'MATERIAL'.
cdhdr-objectid = t_mara-matnr.
CALL FUNCTION 'CHANGEDOCUMENT_READ_HEADERS'
EXPORTING
date_of_change = cdhdr-udate
objectclass = cdhdr-objectclas
objectid = cdhdr-objectid
time_of_change = cdhdr-utime
username = cdhdr-username
TABLES
i_cdhdr = icdhdr
EXCEPTIONS
no_position_found = 1
OTHERS = 2.
CHECK sy-subrc EQ 0.
DELETE icdhdr WHERE change_ind EQ 'I'.
CHECK NOT icdhdr[] IS INITIAL.
LOOP AT icdhdr.
CHECK icdhdr-udate IN period.
CHECK icdhdr-username IN name.
CALL FUNCTION 'CHANGEDOCUMENT_READ_POSITIONS'
EXPORTING
changenumber = icdhdr-changenr
IMPORTING
header = cdhdr
TABLES
editpos = icdshw
EXCEPTIONS
no_position_found = 1
OTHERS = 2.
CHECK sy-subrc EQ 0.
LOOP AT icdshw.
CHECK icdshw-text_case EQ space.
MOVE-CORRESPONDING icdshw TO itab.
MOVE-CORRESPONDING icdhdr TO itab.
MOVE icdshw-tabkey+3 TO itab-matnr.
APPEND itab.
ENDLOOP.
ENDLOOP.
ENDFORM. "CHANGEDOCUMENT_READ
Final Words
This concept of change documents log is applicable to different type of SAP documents. But it depends on your SAP customization.
At a technical level, we can notice that only changes to fields whose data elements are marked as relevant for the creation of change documents in SE11 lead to the creation of change documents. Modifications logging only takes place if the fields whose contents were changed refer to a data element that was flagged as relevant for the change document.
For those who want to go further on this topic, I invite them to check out function group SCD0, SCD1, SCD2 ( contains all the document handling FM's ). This means you can also use this functionality in your own application...
03-20-2008 9:25 PM
Hi Satosh,
Thanks for your response. I have some more info and questions.
I came to know that there is another options at table technical sttings level. If we check Log data changes box. But this is good only when there are very rare changes to the table.
My business said the changes to these custom tables is going to be few times in a month, but if changes are made there can be many. I am not able to take decision of recomonding the first option or creating change document object option. Upto how many changes in an year we can consider 1st option ? Please help me.
Following are some more questions:
1. Should I create CDO for each table or one CDO for all the tables?
2. There is a z...field in a table whose data element is MBLNR, change document check box is not checked in its propertis(Further Characters)
In this situation I assume that copy this data element to a z...data element and check change document check box. Please confirm this.
3. If there is a data element whose change document property is not checked. I assume that we need to check it. Suppose assume that I made this change then what will happen if this data element is used in another z..table ?
4. If I choose 2nd option, how and where the generated FMs should be used?
5. If something goes wrong, What will be the potential impact on the system ?
your help is appreciated.
Thank you,
Surya
Edited by: Surya on Mar 20, 2008 5:36 PM
03-24-2008 2:10 PM
03-25-2008 6:07 PM
Hi Surya,
I think that you know it, but check the note 103358 and related. Additional info (I copy paste documentation from SAP):
Concept
For changes to a commercial object to be able to be logged in a change document, the object must have been defined in the system as a change document object. A change document object definition contains the tables which represent a commercial object in the system. The definition can also specify whether the deletion of individual fields is to be documented. If a table contains fields whose values refer to units and currency fields, the associated table, containing the units and currencies, can also be specified.
It must be specified for each table, whether a commercial object contains only one (single case) or several (multiple case) records. For example, an order contains an order header and several order items. Normally one record for the order header and several records for the order items are passed to the change document creation when an order is changed.
The name under which a change document object is created is an object class.
The object class BANF was defined for the change document object "Purchase requisition", which consists of the tables EBAN (purchase requisition) and EBKN (purchase requisition account assignment).
Changes to this commercial object can then be saved in the system under the object values of this change document object, i.e. the object ID and a change document number. The object ID is the key to the object value, i.e. all records which are defined as belonging to a given change document object.
All changes to a commercial object constitute an object value under this key. This is for example the order number for orders or the number range object name for number range objects. All changes to a given order or to a given number range object can be accessed in this way.
The object value BANF with the object ID "3000000000" consists of the records of the tables EBAN and EBKN with the order number "3000000000".
If changes are not yet to be made, but are planned, they can be logged as planned changes. A planned date for the changes can be specified. The planned changes can be analyzed and copied into the tables. You must program the copy yourself.
All logging functions are supported by SAP function modules. The application development must contain certain INCLUDE programs. Old and new status are passed to the change document creation. The included function modules determine the changes for all table fields which are flagged as being change-relevant in the Dictionary.
Change document
A change document logs changes to a commercial object. The document is created independently of the actual database change. The change document structure is as follows:
· Change document header
The header data of the change to an object ID in a particular object class are stored in the change document header. The change document number is automatically issued.
· Change document item
The change document item contains the old and new values of a field for a particular change, and a change flag.
The change flag can take the following values:
o U(pdate)
Changed data. (Log entry for each changed field which was flagged in the Dictionary as "change document-relevant")
o I(nsert)
Data inserted.
Changes: Log entry for the whole table record
Planned changes: Log entry for each table record field
o D(elete)
Data were deleted (log entry for the whole table record)
o I(ndividual field documentation)
Delete a table record with field documentation
1 log entry per field of the deleted table entry, the deleted text is saved
· Change document number
The change document number is issued when a change is logged, i.e. when the change document header is created by the change document creation function module (function group SCD0).
The change number is not the same as the change document number. The change document number is issued automatically by the function group SCD0 function modules when a change document is created for a change document object. The change number is issued by the user when changes are planned. The same change number can be used for various change document objects.
Internal processing
When the object-specific update is called, the object-specific change document creation is called. The object-specific change document header is written with a change document number. The Dictionary is searched for which fields are to be logged for each table in the object definition. The log records for these fields are then created as change document items according to the object definition.
Procedure
To use the change document functionality in your application, proceed as follows:
1. Define the change document object
2. Check in the Dictionary, whether the data elements of the fields which are to be logged are flagged appropriately.
3. Generate the update.
4. Program the appropriate calls in your program.
Define change document object
Proceed as follows:
1. Call the change document maintenance transaction (Tools ® ABAP/4 Workbench ® Development ® Other tools ® Change doc. object). An overview of existing change document objects is displayed.
2. Choose the menu option Create.
3. Enter a name for the change document object which is to be created. It can be any name starting with "Y" or "Z" (customer name area).
4. Choose Continue. A new window for inputting the associated tables appears.
5. Enter a descriptive short text for the change document object.
6. Make the following entries for each table whose changes are to be logged in the change document for this change document object:
- Table name
Name of the table, as defined in the Dictionary
- Copy as internal table flag.
If the change data are to be passed in an internal table (multiple case), mark this field. If it is not marked, the change data are passed in a work area (single case).
- Doc. for individual fields at delete flag
If you want separate log entries for each field when data are deleted, mark this field. If it is not marked, the deletion of all relevant fields is entered in one document item.
- Ref. table name. (Name of the reference table)
If the currency and unit fields are defined in a reference table, rather than in the table passed, you must pass the name of the reference table, and the field referred to, to the function module. Create an INTTAB structure in the Dictionary, and define fields for this structure, which are made up of the names of the associated reference table and the reference fields.
Enter the name of this structure here.
In the individual case, the reference information is passed in the form of two extra work areas (old, new). In the collective case, the internal tables are extended to include the reference structure.
- Name of the old record fields
Only possible for single case, i.e. when passing change data in a work area: If you do not want to use the * work area, enter an alternative work area name here.
7. After inputting all relevant tables, choose Insert entries. The new entries are copied into the display.
8. Save your entries.
Transport change document object
The change document objects are a transport object type, a change request is made when the object is created.
During transport the object-specific update is generated in the target system.
Set change document flag
Now check whether the change document flag is set for the corresponding data element in the Dictionary for the fields whose changes are to be logged. This is necessary so that the object-specific function modules can identify which field of the defined object should be entered in the change document during logging.
If the flag is not set, you can change it. The flag becomes effective after the activation.
If the flag is set by hand, it can have undesirable side-effects: If a table field in another application, which is based on the data element in question, belongs to a change document object, but was not previously logged, setting the flag will start logging in this application as well.
It is therefore important to consider whether data elements are, or could be, change-relevant when creating them, and to set the flag accordingly. If the data element is not in any change document object via a table field, this has no negative effect on the system.
Generate Update and INCLUDE Objects
The generation creates INCLUDE objects, which contain general and specific data definitions and the program logic for the update function module. Proceed as follows:
1. Call the change document maintenance transaction (Tools ® ABAP/4 Workbench ® Development ® Other tools ® Change documents).
2. Position the cursor on a change document object and choose the menu option Generate update pgm. A dialog box, in which you must make the following entries, is displayed:
maximum 26 character INCLUDE name
This 26-character name (CDF parameters:
· CDOC_PLANNED_OR_REAL
With this parameter you control whether the changes to be logged are actual or planned changes.
Possible values
o "R" actual (real) changes
o "P" planned changes
o " "(space) if no plan number exists: actual change
if a plan number exists: planned change
· CDOC_UPD_OBJECT
If the change document is relevant for determining which change action was performed for the object, you can pass the action performed here.
Possible values:
o "I" the object was inserted.
o "U" the object was changed.
o "D" the object was deleted.
Creating change documents
Function group SCD0
Object-specific update change documents for a particular object ID are created with the function modules in this function group.
These function modules are called, in the right order, by the object-specifically generated update program, as soon as it is called. They are generally not required for application developments. Only in exceptional cases, in which an individual update is to be programmed, should the change document creation be programmed by the user with these function modules.
· CHANGEDOCUMENT_OPEN
This function module is required by every change document creation. It initializes the internal fields for a particular change document object ID.
· CHANGEDOCUMENT_MULTIPLE_CASE
This function module creates change document items. The change data are passed in tables.
· CHANGEDOCUMENT_SINGLE_CASE
This function module creates change document items. The change data are passed in a work area.
· CHANGEDOCUMENT_TEXT_CASE
Change document-relevant texts are passed in a structure with this function module.
· CHANGEDOCUMENT_CLOSE
This function module is required for every change document creation. It writes the change document header for a particular change document ID, and closes the document creation.
· CHANGEDOCUMENT_PREPARE_TABLES
With this function module, you compare the records in two tables, which you pass as TABLE_OLD and TABLE_NEW.
You can specify via a parameter, whether these internal tables should be prepared for the multiple case. Identical records are then deleted, and a processing flag is set in changed records.
Read and format change documents
Two function groups exist for these tasks:
Function group SCD1
With the function modules in this function group, you can read change documents.
· CHANGEDOCUMENT_READ_HEADERS
This function module reads the change document numbers, with the associated header information, for a particular change document object. The search can be restricted by various parameters (changed by, date, time).
You can use this function module in the database and in the archive.
· CHANGEDOCUMENT_READ_POSITIONS
This function module reads the change document items for a given change document object number, and formats the old and new values according to their type.
You can use this function module in the database and in the archive.
· CHANGEDOCUMENT_PREPARE_POS
You format a previously read change document item for printing with this function module.
Function group SCD2
You can process change document objects by classes with the function modules in this group.
· CHANGEDOCUMENT_READ
With this function module, you read change document headers and the associated items for a given object class and format the old and new values according to their type. The search can be restricted by various parameters (changed by, date, time).
You can use this function module in the database and in the archive.
Read and format planned changes
Function group SCD3
With the function modules in this function group, you find the planned changes.
· PLANNED_CHANGES_READ_HEADERS
With this function module, you find the document headers of planned changes for a given change document object. The search can be restricted by various parameters (changed by, date, time, change number).
The change number is not the same as the change document number. The change document number is automatically issued by the function group SCD0 function modules when a change document object change document is created. The change number is assigned by the user when changes are planned. The same change number can be used for various change document objects.
· PLANNED_CHANGES_READ_POSITIONS
This function module reads the change document items for a given change document number, and formats the old and new values according to their type.
Delete change documents and planned changes
Function group SCD4
With the function modules in this function group, you delete log entries of changes or planned changes.
· CHANGEDOCUMENT_DELETE
This function module deletes the change documents for a given change document object. The deletion can be restricted to a given change document number and/or a change date.
An authorization check is made before the deletion.
· PLANNED_CHANGES_DELETE
With this function module, you delete planned changes. The deletion can be restricted to a given change document object, a change document number, or specified change numbers.
The change number is not the same as the change document number. The change document number is issued automatically by the function group SCD0 function modules when a change document object change document is created. The change number is issued by the user when changes are planned. The same change number can be used for various change document objects.
Archived change documents management
Function group SCD5
This function module is the archiving class for the change document (see also Archiving in the archiving section in this document):
· CHANGEDOCU_ARCHIVE_OBJECT
With this function module, you pass the objects for which change documents are to be archived, to the archiving.
In response to your questions:
1. My suggestion is a single table, if you have more tables, resume them in an structure (in your z-report populate it before you call the FM that populate CDHDR/CDPOS). Examples in standard: VBAPVB, VBEPVB and so on.
2. If you use an standard data element without the indicator, copy it and change the indicator (I made it and it works).
3. I'm sorry, but I dont understand the question.
4. One example. I want to control the modifications in a Z-table (ZVT_LIQ_X). I transfer it like internal table (ie: multidim.) and SCDO generate FM Z_VT_LIQ_WRITE_DOCUMENT. The structure is ZZVT_LIQ_X.
So in my coding, before modification I call two subroutines:
form export_liq using optionx.
refresh xvt_liq.
select * from zvt_liq_x
into corresponding fields of table xvt_liq
where werks = i_listado-werks
and fecha = i_listado-fecha.
loop at xvt_liq.
xvt_liq-kz = optionx.
modify xvt_liq.
endloop.
endform. " export_liq
And after the modifciation:
form import_liq using optiony.
data: wx_liq like zvt_liq_x,
wy_liq like zvt_liq_x.
refresh yvt_liq..
select * from zvt_liq_x
into corresponding fields of table yvt_liq
where werks = i_listado-werks
and fecha = i_listado-fecha.
loop at yvt_liq.
yvt_liq-kz = optiony.
modify yvt_liq.
endloop.
concatenate yvt_liq-mandt
yvt_liq-werks
yvt_liq-fecha
into change_texto-teilobjid.
CONDENSE change_texto-teilobjid NO-GAPS.
change_texto-textart = ' '.
change_texto-textspr = sy-langu.
change_texto-updkz = optiony.
append change_texto.
read table xvt_liq index 1.
move-corresponding xvt_liq to wx_liq.
read table yvt_liq index 1.
move-corresponding yvt_liq to wy_liq.
call function 'Z_VTLIQ_REG_MODIFICACION'
exporting
i_werks = i_listado-werks
i_fecha = i_listado-fecha
i_kz = optiony
y_liq = wy_liq
x_liq = wx_liq
tables
t_txt = change_texto
t_init = xvt_liq
t_save = yvt_liq
exceptions
no_liquidacion = 1
others = 2.
if sy-subrc <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
endif.
endform. " import_liq
The FM
function z_vtliq_reg_modificacion.
*"----
-
""Interfase local
*" IMPORTING
*" REFERENCE(I_WERKS) LIKE ZVT_LIQ_TIENDAS-WERKS
*" REFERENCE(I_FECHA) LIKE ZVT_LIQ_TIENDAS-FECHA
*" REFERENCE(I_KZ) TYPE CDCHNGIND
*" REFERENCE(Y_LIQ) LIKE ZVT_LIQ_x STRUCTURE
*" ZVT_LIQ_x
*" REFERENCE(X_LIQ) LIKE ZVT_LIQ_x STRUCTURE
*" ZVT_LIQ_x
*" TABLES
*" T_TXT STRUCTURE CDTXT
*" T_INIT STRUCTURE ZZVT_LIQ_x
*" T_SAVE STRUCTURE ZZVT_LIQ_x
*" EXCEPTIONS
*" NO_LIQUIDACION
*"----
-
data: objeto like cdhdr-objectid.
clear objeto.
concatenate i_fecha i_werks into objeto.
*CONDENSE objeto NO-GAPS.
call function 'Z_VTLIQ_WRITE_DOCUMENT' "IN UPDATE TASK
exporting
objectid = objeto
tcode = sy-tcode
utime = sy-uzeit
udate = sy-datum
username = sy-uname
PLANNED_CHANGE_NUMBER = ' '
object_change_indicator = i_kz
PLANNED_OR_REAL_CHANGES = ' '
NO_CHANGE_POINTERS = ' '
UPD_ICDTXT_Z_VTLIQ = ' '
upd_zvt_liq_x = i_kz
IMPORTING
CHANGENUMBER =
tables
icdtxt_z_vtliq = t_txt
xzvt_liq_tiendas = t_save
yzvt_liq_tiendas = t_init
.
endfunction.
5. Perhaps I dont understand you, but if you manage the rolling procedures (COMMIT and so on), in CDHDR/CDPOS the commit works too.
I hope this helps you,
Regards,
Eduardo
Edited by: Eduardo Hinojosa Muñoz on Apr 17, 2008 4:40 PM