topic Re: Change Document in Application Development and Automation Discussions

Change Document

Former Member — Mon, 17 Mar 2008 21:32:01 GMT

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

Re: Change Document

Former Member — Tue, 18 Mar 2008 01:28:09 GMT

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 .

Re: Change Document

Former Member — Tue, 18 Mar 2008 14:33:41 GMT

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

Re: Change Document

Former Member — Tue, 18 Mar 2008 14:42:31 GMT

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

Re: Change Document

santhosh_patil — Tue, 18 Mar 2008 14:43:23 GMT

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, you’ll 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; you’ll 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, we’ll 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...

Re: Change Document

Former Member — Thu, 20 Mar 2008 21:25:57 GMT

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

Re: Change Document

Former Member — Mon, 24 Mar 2008 14:10:21 GMT

Can anyone respond to my questions?

Thank you,

Surya

Re: Change Document

eduardo_hinojosa — Tue, 25 Mar 2008 18:07:46 GMT

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