Skip to Content
author's profile photo
Former Member

Validation for a extension field in the BAPI ( BAPI_ACC_DOCUMENT_CHECK)

Hi,

I am working on an in terface for upload of data in journal ledger(FB50)

Actually i need to validate a field which has been included in transaction FB50 as an enhancement based on customer need .

a function module was created as suggested in note 487722 earlier but now we require to validate that field(transaction type) as i am using this BAPI in an interface for journal ledger posting FB50 for data validation of the file data.

this field has been populated as a part of the extension parameter in the bapi -


(( BAPI_ACC_DOCUMENT_CHECK)

field values for this field have been passed in the business transaction.

but i am not sure where to code the validation for this field .

could anybody suggest if we need to do it in include ZXACCU15 .

if so then how do we populate the values for the return parameter.

i am post ing document using IDOC and need to generate the for the errors generated.

it already shows for all the standard fields of the transaction.

Its a bit urgent,

help wud be appreciated

jy

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

2 Answers

  • author's profile photo
    Former Member
    Posted on Aug 20, 2007 at 04:36 AM

    Hi,

    thanks for the reply.the custom code has been added in an function module

    Z_FI_INTERFACE_RWBAPI01.

    • transaction type

    READ TABLE IT_ACCIT INTO LS_ACCIT

    WITH KEY POSNR = LD_POSNR.

    CHECK SY-SUBRC EQ 0.

    LD_TABIX = SY-TABIX.

    LS_ACCIT-POSNR = LD_POSNR.

    LS_ACCIT-RMVCT = LS_BAPI_EXTENSION-FIELD3.

    MODIFY IT_ACCIT FROM LS_ACCIT INDEX LD_TABIX.

    • others

    i want to validate the field LS_BAPI_EXTENSION-FIELD3 before transferring.

    condition is like value shud exist in T856 table else the return tab shud be poplulated with error as i cud loop at it and display

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member

      Hello Jy

      The following coding shows how to evaluate the existence of the transaction type in table T856 and how to create the corresponding BAPI message (using function module <b>BALW_BAPIRETURN_GET2</b>):

      *&---------------------------------------------------------------------*
      *& Report  ZUS_SDN_BAPIRETURN_GET2
      *&
      *&---------------------------------------------------------------------*
      *&
      *&
      *&---------------------------------------------------------------------*
      
      REPORT  zus_sdn_bapireturn_get2.
      
      
      
      
      START-OF-SELECTION.
      
      
        " Call BTE function within BAPI (actually OPEN_FI_PERFORM_RWBAPI01_P
        " calls the z-function module)
      **  CALL FUNCTION 'Z_FI_INTERFACE_RWBAPI01'
      **    TABLES
      **      c_accit           =
      **      c_acccr           =
      **      c_return          =
      **      c_extension       =
      **      c_accwt           =
      **    changing
      **      c_acchd           =
      **            .
      
        " Coding within your BTE function module:
        DATA:
          ls_return    TYPE bapiret2.
      
      
      * transaction type
        READ TABLE it_accit INTO ls_accit
             WITH KEY posnr = ld_posnr.
        CHECK ( sy-subrc EQ 0 ).
        ld_tabix = sy-tabix.
        ls_accit-posnr = ld_posnr.
        ls_accit-rmvct = ls_bapi_extension-field3.
        MODIFY it_accit FROM ls_accit INDEX ld_tabix.
      
      " Validate existence of transaction type
        SELECT SINGLE * FROM  t856 into ls_t856
               WHERE  trtyp  = ls_accit-rmvct.
        if ( syst-subrc ne 0 ).
          " Note: the following IF condition looks apparently strange yet its primary
          "         use is to ensure that the Where-Used-List for message 014(GC)
          "         will find our function module
          if 1 = 2.  MESSAGE e014(gc) WITH ls_accit-rmvct.  endif.
      *   Transaction type & is not defined
      
          clear: ls_return.
          ls_return-message_v1 = ls_accit-rmvct.  " type conversion
          CALL FUNCTION 'BALW_BAPIRETURN_GET2'
            EXPORTING
              type             = 'E'
              cl               = 'GC'
              number           = '814'
              PAR1             = ls_return-message_v1
      *       PAR2             = ' '
      *       PAR3             = ' '
      *       PAR4             = ' '
      *       LOG_NO           = ' '
      *       LOG_MSG_NO       = ' '
      *       PARAMETER        = ' '
      *       ROW              = 0      " ld_tabix
      *       FIELD            = ' '    " RMVCT
            IMPORTING
              RETURN           = ls_return.
      
          APPEND ls_return TO c_return.
        ENDIF.
      
      
      END-OF-SELECTION.

      The advantage of using the function module over directly filling the BAPIRET2 message variable is that the function module generated the message text (field BAPIRET2-message = 'Transaction type '<type>' is not defined').

      Regards

      Uwe

  • author's profile photo
    Former Member
    Posted on Aug 20, 2007 at 04:17 AM

    Hello Jy

    It seems that there are two ways to validate extension data:

    FUNCTION bapi_acc_document_check.
    *"----------------------------------------------------------------------
    *"*"Lokale Schnittstelle:
    *"  IMPORTING
    *"     VALUE(DOCUMENTHEADER) LIKE  BAPIACHE09 STRUCTURE  BAPIACHE09
    *"     VALUE(CUSTOMERCPD) LIKE  BAPIACPA09 STRUCTURE  BAPIACPA09
    *"       OPTIONAL
    *"     VALUE(CONTRACTHEADER) LIKE  BAPIACCAHD STRUCTURE  BAPIACCAHD
    *"       OPTIONAL
    *"  TABLES
    *"      ACCOUNTGL STRUCTURE  BAPIACGL09 OPTIONAL
    *"      ACCOUNTRECEIVABLE STRUCTURE  BAPIACAR09 OPTIONAL
    *"      ACCOUNTPAYABLE STRUCTURE  BAPIACAP09 OPTIONAL
    *"      ACCOUNTTAX STRUCTURE  BAPIACTX09 OPTIONAL
    *"      CURRENCYAMOUNT STRUCTURE  BAPIACCR09 OPTIONAL
    *"      CRITERIA STRUCTURE  BAPIACKEC9 OPTIONAL
    *"      VALUEFIELD STRUCTURE  BAPIACKEV9 OPTIONAL
    *"      EXTENSION1 STRUCTURE  BAPIACEXTC OPTIONAL
    *"      RETURN STRUCTURE  BAPIRET2
    *"      PAYMENTCARD STRUCTURE  BAPIACPC09 OPTIONAL
    *"      CONTRACTITEM STRUCTURE  BAPIACCAIT OPTIONAL
    *"      EXTENSION2 STRUCTURE  BAPIPAREX OPTIONAL
    *"      REALESTATE STRUCTURE  BAPIACRE09 OPTIONAL
    *"----------------------------------------------------------------------
      DATA ld_currency.
    
    ...
      PERFORM fill_real_estate
              TABLES realestate.
    
      PERFORM call_customer_function
              TABLES extension1.  " BTE exit
    
      PERFORM call_badi
              TABLES extension2.  " BAdI exit
    ...

    In routine <b>CALL_CUSTOMER_FUNCTION</b> you can call the <b>BTE </b>function module for <b>'RWBAPI01' </b>and return appropriate BAPI messages in parameter C_RETURN. These messages are collected into the global itab IT_RETURN which is evaluated later in the BAPI processing.

    Alternatively, in routine <b>CALL_BADI</b> the implementation of <b>BAdI 'ACC_DOCUMENT'</b> is called. In method CHANGE we have the same message parameter C_RETURN. Again, these messages are collected globally.

    I assume that if you add an E-message to parameter C_RETURN due to a failed validation of the extension data then the BAPI will not allow to post the document.

    Since BTEs are an interim solution between the old-fashioned customer-exits (CMOD/SMOD) and the new BAdI technology (SE18 / SE19) I would recommend to implement the BAdI.

    Regards

    Uwe

    Add comment
    10|10000 characters needed characters exceeded