CSAP_BOM_ITEM_MAINTAIN - Problems while clearing custom fields

Question

Hi, I try to modify some bom items, it works fine so far, but I get into trouble when trying to update previosly filled fields with empty ones.
First, I check my structure and insert a 'delete field character' into initial fields:
LOOP AT fieldcat INTO wa_fieldcat.
        IF wa_fieldcat-fieldname EQ 'FLDELETE'.
          CONTINUE.
        ENDIF.
        ASSIGN COMPONENT wa_fieldcat-fieldname OF STRUCTURE bomline TO <field>.
        IF sy-subrc IS INITIAL.
          IF <field> IS INITIAL OR <field> EQ space.
            <field> = '!'.
          ENDIF.
        ELSE.
          MESSAGE 'Error while looping thru bomline structure to update fields' TYPE 'E'.
        ENDIF.
     ENDLOOP.
Then, I use CSAP_BOM_ITEM_MAINTAIN to update bom
CALL FUNCTION 'CSAP_BOM_ITEM_MAINTAIN'
    EXPORTING
      i_stpo                   = bomline
*         FL_DEP_ALE_CONFORM       = ' '
    IMPORTING
      o_stpo                   = bomline_out
      fl_warning               = warning
*       TABLES
*         T_DEP_DATA               =
*         T_DEP_DESCR              =
*         T_DEP_ORDER              =
*         T_DEP_SOURCE             =
*         T_DEP_DOC                =
    EXCEPTIONS
      error                    = 1
      OTHERS                   = 2
So, this works out fine, but not for my custom fields in the stpo_api02's .INCLUDE structure. While the standard fields are deleted when I fill them with '!', the custom ones just contain '!' afterwards.
When I dont put '!' into my custom fields and make them initial prior invoking CSAP_BOM_ITEM_MAINTAIN, their contents stay untouched.
However, real updates, where field contents are changed to some value but initial work flawlessly, on both, the stock and my custom fields.
Any Idea on this?

Answer 1

Hi,
  Can you try to read the BOM items before changes and use the same structure in change BAPI by modifying the structure with only the changes. I guess this will support the clearing of the custom fields.
With Regards,
Rajesh V.