Produce meaningful pre-load validation reports using LSMW

The whole point of validating data prior to loading is to give functional team members a chance to fix the data by preparing it again in a way that can be loaded into SAP or by configuring SAP to allow for the data. A meaningful report comes with all of the relevant source data along with a detailed explanation of why the record cannot be loaded to SAP.

Many conversion specialists prefer a method of error correction that calls for the data to be loaded to SAP followed by a complex process of combing through the batch log for error messages. Seldom are these error messages meaningful enough to tell why the record failed--especially when the batch is run in the background or as IDOCs. By validating the data against check tables or by calling validating functions provided by SAP, a report that documents each and every potential problem with the data can be produced for use by the functional team. This data is invaluable when coupled with instructions on how to fix the problems.

Some examples of problems with data that can be caught with validating ABAP code along with their solution are:

• Missing Vendor, Customer or Material -- Create the dependency master data.
• Externally assigned number falls outside the predefined number range -- Provide a new number or expand the allowable number range.
• Master data not extended to requisite Company Code, Purchasing Org, Sales Org, Plant, Storage Location, Warehouse . . . -- Extend the dependency master data.
• Date and number formats incompatible with configuration of SAP -- Transform the data to be aligned with SAP standards.
• Master data flagged for deletion or in blocked status -- Remove deletion flag or blocked status.
• Master data or transactional data already exists -- Skip loading the redundant data.

Reports don't need to be overly complicated.

The easiest way to present the data to the functional team member is as an Excel spreadsheet. By exporting directly to Excel in an easy-to-read format, one eliminates errors caused by manual transformations into Excel and improves the chance that some action will be taken on the reported errors.

An internal table with the significant fields from the source data, an error type and a detailed error message is a great way to store data as the conversion runs so that it can be written out as a fixed-width report. If each field is just big enough to hold the needed data, then the report need not wrap lines of text. Here is a great example of code used to produce an error report during the conversion of inventory records.

In the GLOBAL_DATA section of the LMSW Field Mapping and Conversion Rules, this snippet of code creates a structure to hold the error log, an internal table called it_ErrorLog and a working area called wa_ErrorLog that acts as a holding area for data to be added to the internal table or read from it.

types: begin of t_ErrorLog,
        Index type i,
        BKTXT(10) type c,
        MATNR(18) type c,
        WERKS(4) type c,
        CHARG(10) type c,
        LGORT(4) type c,
        ErrorType(15) type c,
        ErrorMessage(60) type c,
       end of t_ErrorLog.
data: it_ErrorLog type standard table of t_ErrorLog initial size 0.
data: wa_ErrorLog type t_ErrorLog, cErrorMessage(60) type c.

Here is an example of a validation that is performed on the data as it is being converted in LSMW. Each material must be maintained in the plant where it is being created or moved to and this code provides an easy way to check that it is. When the material is not maintained in a plant then a record is added to the internal table with all of the necessary information needed to explain why the record cannot be created. Then the skip_transaction statement ensures that this record is not loaded. Note that MB11S is the structure of the source data.

select single * from MARC into lMARC
 where MATNR eq MB11S-MATNR
   and WERKS eq MB11S-WERKS.
if sy-subrc ne 0.
    concatenate 'Not maintained in plant' MB11S-WERKS
     into cErrorMessage separated by space.
    perform AppendErrorLog using 'Missing Plant' cErrorMessage.
  add 1 to nWERKS.
  skip_transaction.
endif.

The inventory load conversion should have more than one dozen validations like this. After the records have been converted and the internal table is full of information to be loaded, a simple loop produces a perfect fixed-width report for easy use in Excel. This code goes in the END_OF_PROCESSING section of the LMSW Field Mapping and Conversion Rules.

Note: Later revisions of this report included code designed to obviate the need to copy-past or import fixed-width text into Excel.

 
loop at it_ErrorLog into wa_ErrorLog.
  write: / wa_ErrorLog-Index, wa_ErrorLog-MATNR, wa_ErrorLog-WERKS,
   wa_ErrorLog-BKTXT, wa_ErrorLog-ErrorType, wa_ErrorLog-ErrorMessage.
endloop.

Finally, this short form adds the data to the internal table without having to be passed each and every field. This goes in the FORM_ROUTINES section of the LMSW Field Mapping and Conversion Rules.

form AppendErrorLog using cErrorType cErrorMessage.
    wa_ErrorLog-Index = nIndex.
    wa_ErrorLog-BKTXT = MB11S-BKTXT.
    wa_ErrorLog-MATNR = MB11S-MATNR.
    wa_ErrorLog-WERKS = MB11S-WERKS.
    wa_ErrorLog-LGORT = MB11S-LGORT.
    wa_ErrorLog-CHARG = MB11S-CHARG.
    wa_ErrorLog-ErrorType = cErrorType.
    wa_ErrorLog-ErrorMessage = cErrorMessage.
    append wa_ErrorLog to it_ErrorLog.
endform.

The finished report should look like this and be easy for the functional team to understand. Be sure to add an index so that it is clear what line in the source code the error relates to.