Validataion does not work in batch mode

[Former Member]

Hello community,

We created an FI line item validation for transaction FBV1 that does a validation on a field and displays an error message if the validation fails. We have an RFC that uploads data from an Excel template and runs a BDC Call Transaction to upload and park the document. This worked well when we were on 4.6C but when we upgraded to ECC6.0, the Validation works fine when we manually call the FBV1 in SAP and the Validation DOES get triggered and displays a message if the line item validation fails but when we run FBV1 in batch mode, (RFC which contains a call transaction to FBV1) the validation does not work.

I set up break a point in the generated program GBTBOFID where the exception error gets triggered and traced the FI Validation. The program will not display the error Validation message when run in batch but when run online, the error message gets triggered.

[Former Member]

I'm not sure of the answer here. In the CALL TRANSACTION statement, you can try adding OPTIONS FROM and set NOBIEND to 'X'. This may not be the correct option, so try others if this doesn't work.

A shot in the dark.

Rob

[Former Member]

Thanks for the prompt reply. I tryied a combination of the following options and did not have much luck with this one.

Data: x_options type ctu_params.
     clear X_OPTIONS.
     X_OPTIONS-DISMODE = 'A'.
     X_OPTIONS-UPDMODE = 'S'.
     X_OPTIONS-CATTMODE = ' '.
     X_OPTIONS-DEFSIZE = ' '.
     X_OPTIONS-RACOMMIT = ' '.
     X_OPTIONS-NOBINPT = ' '.
     X_OPTIONS-NOBIEND = 'X'.

 CALL TRANSACTION 'FBV1' USING bdcdata options from X_OPTIONS

After the call transaction the program automatically triggers some SAP generated code for a Validation check for FBV1 line item that we have put in through IMG. The message that should be displayed is in the FI validation check of FBV1.

I put a break point in the SAP generated code for the Validation where the message should be displayed. The program executes the statement that should raise the exception and display the message. As soon as the statement is executed, conrol returns to the the the SAP transaction FBV1 program and the program continues to finish.

The statement that executes and does not display the error message is:

CASE valsevere.
        WHEN  'A'.
          MESSAGE ID msg_id    TYPE valsevere   NUMBER msg_nr
                  WITH msgv1 msgv2 msgv3 msgv4
                  RAISING abend_message.
        WHEN  'E'.    <=== *This option is true and the progam steps 
                    " through the following message but does not display it.*
          MESSAGE ID msg_id    TYPE valsevere   NUMBER msg_nr
                  WITH msgv1 msgv2 msgv3 msgv4
                  RAISING errormessage.
        WHEN  OTHERS.
          MESSAGE ID msg_id    TYPE valsevere   NUMBER msg_nr
                  WITH msgv1 msgv2 msgv3 msgv4.
      ENDCASE.

I should mention that in debug mode, I check the values of msg_id, msg_nr, msgv1 etc. and they all have values of a message class that we have created.

The above code is in a SAP generated program for FI Validation (GBTBOFI0, include FGBB100R).

-- We only have this issue when we use the FBV1 transaction in batch mode. Runing FBV1 directly online works fine.

-- The issue is unique to ECC 6.0 environemnt. We did not have this problem in 4.6C

Suggestions greatly appreciated.

Edited by: Rob Burbank on Jan 20, 2010 12:15 PM

[brad_bohn]

I can't see the rest of your code or how far the error is propagated and caught, but I can say that this is not normal and it does not happen in our ERP 6.0 system. We have many vals/subs but do not often park documents, so I was curious if it was an issue with parking. I tried it with FBV1 with both a header level and a line item level validation with data that should force a failure, and each time the error condition was triggered and the transaction stopped. The correct error message was recorded in the call transaction result, which is normal for display mode 'N'.

If you aren't seeing the error message in the message table, is the transaction actually successful? Have you debugged the generated code to the point at which the exception is handled?

It might be worth re-generating the code and/or looking for OSS notes. Unfortunately, I don't remember whether a forced re-gen was a step in the upgrade process or whether we implemented any related notes at that time.

[Former Member]

Thanks Brad,

The transaction is not successfull because we input values for FI line item validations that should display the error message and the transaction should not be successful.

I steped through the the SAP generated code where the actual exception message is triggered. When the statement

 
MESSAGE ID msg_id    TYPE valsevere   NUMBER msg_nr
                  WITH msgv1 msgv2 msgv3 msgv4
                  RAISING errormessage.

is executed the program returns control to the calling FBV1 transaction program without stoping at the error message. The exception 'errormessage' in the statment above is in the SAP generated program.

I know that in a function module, control returns to the calling program if the exception are handled in the callingn program but in this case the RAISING ERRORMESSAGE is in a program.

I inputed the same data in 4.6C environment same function, same objects and the program stops at the RAISING ERRORMESSAGE and displays the actual error message. It alsmost seems like the exception is not handled correctly in ECC6.0.

Edited by: Abey on Jan 20, 2010 4:10 PM

Thanks for the reminder Rob, Message was Edited.

[Former Member]

Abey - there is a 2,500 character posting limit to individual posts. Can you try to edit your last post so that it displays properly?

Rob

[Former Member]

 
FORM          <===*Program gets in here and steps through*
.....
    CASE valsevere.
      WHEN  'A'.
        g_msg_severity = 'A'.
      WHEN  'E'.
        IF NOT g_msg_severity = 'A'.
          g_msg_severity = 'E'.    <===*program sets g_msg_severity to 'E',
*      visible in debug mode*
        ENDIF.
      WHEN  'W'.
        IF NOT ( g_msg_severity = 'A' OR
                 g_msg_severity = 'E' ).
          g_msg_severity = 'W'.
        ENDIF.
      WHEN 'I'.
        IF NOT ( g_msg_severity = 'A' OR
                 g_msg_severity = 'E' OR
                 g_msg_severity = 'W' ).
          g_msg_severity = 'I'.
        ENDIF.
    ENDCASE.
    CALL FUNCTION 'MESSAGE_STORE'
      EXPORTING
        exception_if_not_active = 'X'    "Default! But state anyway.
        arbgb                   = msg_id
        txtnr                   = msg_nr
        msgty                   = valsevere
        msgv1                   = msgv1
        msgv2                   = msgv2
        msgv3                   = msgv3
        msgv4                   = msgv4
        zeile                   = g_msg_row
      IMPORTING
        max_severity            = nvalseverest
      EXCEPTIONS
        not_active              = 1.
*      If not active give out message yourself and raise exception.
    IF sy-subrc = 1. <====*sy-subrc is set to one, again I can see this in debug"
      CLEAR sy-subrc.
      CASE valsevere.
        WHEN  'A'.
          MESSAGE ID msg_id    TYPE valsevere   NUMBER msg_nr
                  WITH msgv1 msgv2 msgv3 msgv4
                  RAISING abend_message.
        WHEN  'E'.
          MESSAGE ID msg_id    TYPE valsevere   NUMBER msg_nr  <===*statement executed 
*                    but no message in batch mode*
                  WITH msgv1 msgv2 msgv3 msgv4
                  RAISING errormessage.
        WHEN  OTHERS.
          MESSAGE ID msg_id    TYPE valsevere   NUMBER msg_nr
                  WITH msgv1 msgv2 msgv3 msgv4.
      ENDCASE.

    ENDIF.
  ENDFORM.                    "MESSAGE_OUTPUT

[brad_bohn]

Unfortunately, no matter what I do, I can not get a line item level validation triggered in FBV1 to exhibit that behavior in our ERP 6.0 system. The generated error message and handling code is the same. Each time, the error message is triggered, the call transaction terminates, and the error message shows in the message table. By the way, the RAISING addition is ignored when not directly called from a function so the statement should be issued immediately.

Perhaps you are on a different enahncement pack level with some additional 'features' as we like to call them. I would check for notes and then go the OSS message route. That's about all I can suggest without being on your system firsthand. The behavior sounds similar to the usage of the generic ERROR_MESSAGE exception in function calls, where you can suppress and/or ignore improperly issued messages.

[Former Member]

Or raise an OSS mesage - the worst they can do is say that it's a consulting issue.

Rob

[kesavadas_thekkillath]

Once we raised the same .. But nothing positive.

[Former Member]

This issue was resolved.

The validation did get triggered but the message was not visible at the bottom of the screen as it had been over written or disappeared in the process.

What I did to resolve the issue was that in the BDC process, I entered BDC_OK of u2018/00u2019 after each field was populated. The trigger was activated on the field that had the validation check on.

It wasnu2019t working if I filled all BDC fields and then click enter BDC_OK of u2018/00u2019.

Thanks for the replies. Special thanks for Rob Burbank and Brad Bohn.

Edited by: Abey on Feb 1, 2010 1:42 PM