Predict a Field Status While Preparing Batch Input

Most fields in master data transactions can be set to suppressed, optional or required for the purpose of controlling the integrity and quality of the data as it is entered. During an SAP implementation, it is not uncommon for resources behind the scenes to discover the purpose of fields in master data and, with unfettered access to transactions like OBD2 and OBD3, change the status of fields such that LSMW objects written for loading and updating master data are rendered useless.

A field that is suddenly mandatory on screen will cause batch entry to stop and wait for the field to be populated. When a batch tries to populate a field that has been suppressed, the system throws a warning instead of an error, but that warning requires the batch to be run in foreground or "display errors only", usually with the coffee cup method.

Knowing in advance whether a screen field will be suppressed or required allows for the field to be left blank or populated so that batch loads are not interrupted by warnings or errors. LSMW objects that can predict the presence or absence of a screen field do not have to be hard-coded for every possible contingency.

For this example, the "Account Statement" field status was suppressed for the first half of the implementation, but was suddenly set to required. This rendered the LSMW object updating the Vendor Company Code data screens useless as the batch always hangs on this screen.

The first inclination was to hard-code a default value in this field for the one Vendor Account Group for which the field status has changed, but nobody has taken responsibility for setting the field to required and nobody has admitted to needing the field for any business requirement. By using a snippet of code to predict the field status in advance, the LSMW can be used for every Vendor Account group and will continue to work if the field status of "Account Statement" is set back to suppressed.

Finding out how and where the field status of a field is stored is the hardest part of this task, but it is still very easy. In this case, the field is XAUSZ in the LFB1 table and a quick search in the TMODU table for these values shows that the field status is stored in character 44 of the field T077K-FAUSF.

T077K is the table that stores all of the Vendor Account Groups and it has a field FAUSF, but that field is only 40-characters long. It took a little intuitive guessing, but it turns out that the first 40 characters of the string are saved in FAUSF and the remainder are saved in FAUSG so the 4th character of FAUSG should represent the field status of LFB1-XAUSZ for Vendor Account Group Z001.

A quick look at these tables in the development system and in the target system show a stark difference in the fourth character of the FAUSG table. In the development system, the fourth character is a minus sign representing a suppressed field and in the target system, the fourth character is a plus sign representing a required field.

An easy way to verify that the correct character in the correct field has been located is to pass the FAUNA value from the TMODU table into the PREPARE_FIELD_SELECT_STRING function (using transaction SE37) along with some dummy data and then examine the output. The text values do not matter and are only for show during the transaction, but the INCOMING_STRING value should be set to many periods for "optional" values and the XCHANGE value should be set to "X" for testing purposes.

Press F8 and then drill down to the screen where the field appears. In this case, double-clicking on "Correspondence" gets to the list of fields on the Correspondence screen and the appropriate field is set to Req. Entry for testing purposes.

Now click the F3 (not Save!) until the Test Function Module: Result Screen appears. Here the OUTGOING_STRING value is what will be written out to represent field statuses. Because only one field was set to required, it is easy to see where in the string the character for that field is stored and by copy-pasting it into Notepad, one can easily see that it is the 44th character in the string.

Writing a short snippet of code is all that remains to fix this LSMW object. First, in the Global Data area, declare three variables like this.

data: lLFA1 like LFA1, lT077K like T077K, lLIFNR like LFA1-LIFNR.

Insert the code that predicts the field status in the field whose status is to be predicted. In this case it is the XAUSZ field of LFB1.

* Target Field: BLFB1-XAUSZ Indicator for periodic account statements
move BLF00-LIFNR to lLIFNR.
if lLIFNR co '1234567890 '.
  shift lLIFNR right deleting trailing space.
  overlay lLIFNR with '0000000000'.
else.
  translate lLIFNR to UPPER CASE.
endif.
select single * from LFA1 into lLFA1 where LIFNR eq lLIFNR.
if sy-subrc ne 0.
  write: / BLF00-LIFNR color col_negative, 'Vendor not created.'.
  skip_transaction.
else.
  select * from T077K into lT077K where KTOKK eq lLFA1-KTOKK.
    if lT077K-FAUSG+3(1) eq '+'.  "XAUSZ field is mandatory.
      BLFB1-XAUSZ = 'N'.  "Per client.
    endif.
  endselect.
endif.

That is all there is to predicting if a field will be on a screen and if it is required. A little experimentation and research may be required to tease out of the system what character in what field of what table represents the status of a field for another master data object in another transaction.

This search tool was useful (along with a lot of debugging) when tracking down the tables where the esoteric details of field order on screens was concerned. It is free to download and use without guilt.