How to fire object dependency in BAPI_OBJCL_CHANGE

[Former Member]

I have a program that calls BAPI_OBJCL_CHANGE to update the classification of materials.  I recently added an object dependency to a characteristic to set the value of another characteristic based on the value of the characteristic.  This works fine when updating the material via CL20N.  However, when updating a material using the bapi the object dependency fails to fire and characteristic value is not set.  How can I get the bapi to fire the dependency?  Or is there another bapi I need to call to get it to fire?

Thanks for looking!

[Former Member]

UPDATE:

After much trial and error along with SDN searchs, I finally determined what my problem was.  My update program was attempting to modify the 1st characteristic value with the same value it already had in an attempt to trigger the dependency logic.  For some reason this was actually working against me.  When I removed the attempt to modify the value and just save the classification without any change it actually updated the 2nd characteristic properly!  Yeah! there is joy in Mudville today!

[bastinvinoth]

Larry Browning

Pass your dependency name to CUKB table field name is KNNAM then you will get KNNUM , pass that one to FM 'CUKD_GET_KNOWLEDGE'.

below code for your reference.

SELECT * FROM cukb INTO CORRESPONDING FIELDS OF TABLE it_cukb
     WHERE knnam IN s_knnam.
   LOOP AT it_cukb INTO wa_cukb.
     CALL FUNCTION 'CUKD_GET_KNOWLEDGE'
       EXPORTING
         knowledge_type     = 'S'
         relation_nr        = wa_cukb-knnum
       TABLES
         knowledge_tab      = itab
       EXCEPTIONS
         no_knowledge_found = 1
         no_relation_found  = 2
         OTHERS             = 3.
     IF sy-subrc <> 0.
 * Implement suitable error handling here
ENDIF.

Regards,

Bastin.G

[Former Member]

Bastin,

Thanks for your reply.  Are you suggesting that once I get the source of the dependency that I look through it to get the value to use to set the value of my target characteristic?  That seems like it would would not be very accurate and a pretty messy way to do it.  I would much prefer finding a way to get the dependency to fire and let SAP handle it.

BTW:  There is another FM  to return the dependency source code that is probably better: CARD_DEPENDENCY_READ.  This will return the source that is effective for a given date or change number along with other info about it. (like whether it is active or not)

[bastinvinoth]

Hi Larry Browning

Both are same only right anyway you have to get the KNNUM field from cukb table only.

if you pass Dependency name with change number to FM 'CARD_DEPENDENCY_READ' means you will get the dependency code details .correct me if am wrong

Regards,

Bastin.G

[Former Member]

Bastin Vinoth wrote:
Hi Larry Browning
if you pass Dependency name with change number to FM 'CARD_DEPENDENCY_READ' means you will get the dependency code details .correct me if am wrong 
Regards,
Bastin.G

I believe passing the change number sets the effective date used to select the data.  When using this FM, you do not have to read CUKB to get the internal number.  However, this does not really answer my question.

Also, another off topic question.  How did you manage to insert ABAP code into your post?  I can't seem to figure out how to do that.

[bastinvinoth]

How did you manage to insert ABAP code into your post?  I can't seem to figure out how to do that.

Use advanced editor(top right) while reply back.

[bastinvinoth]

Thanks Larry Browningfor that info ('CARD_DEPENDENCY_READ').

[Former Member]

Ok, thanks for that.  Now let's see if I can do it.

CALL FUNCTION 'BAPI_OBJCL_CHANGE'
         EXPORTING
         objectkey                = w_objcl-key-object
         objecttable              = 'MARA'
         classnum                 = f_classnum
         classtype                = f_classtype
 **     STATUS                   = '1'
 **     STANDARDCLASS            =
         changenumber             = f_chg_number
         keydate                  = f_keydate
 **     NO_DEFAULT_VALUES        = ' '
 **   IMPORTING
 **     CLASSIF_STATUS           =
       TABLES
         allocvaluesnumnew        = t_allocnumval_detail
         allocvaluescharnew       = t_alloccharval_detail
         allocvaluescurrnew       = t_alloccurrval_detail
         return                   = t_bapiret2.
 

I did it!   He can be taught!

[bastinvinoth]

ha Larry Browning that's so funny

[Former Member]

UPDATE:

After much trial and error along with SDN searchs, I finally determined what my problem was.  My update program was attempting to modify the 1st characteristic value with the same value it already had in an attempt to trigger the dependency logic.  For some reason this was actually working against me.  When I removed the attempt to modify the value and just save the classification without any change it actually updated the 2nd characteristic properly!  Yeah! there is joy in Mudville today!