Pre-validate Vendor Masters before transporting dependent transactional data

Jimbo's picture
Submitted by Jimbo on Wed, 07/06/2011 - 08:46

So often a disconnect appears between the Vendor Masters that are transported to SAP and the transactional data that follows. Vendors are a dependency for documents like accounts payable and purchase orders. If vendors aren't present in the new system or, if they're configured incorrectly, then the documents cannot post and a conversion project can grind to a standstill.

In some rare cases I've seen data conversion specialists transport the documents and then send a list of fallout to be resolved at another time. A far better approach is to pre-validate the Vendor Master and any other dependencies during the Convert Data phase in LSMW. By pre-validating and producing a list of errors that will occur, the person handling the dependencies can be made aware of changes that need to be made before transactions in the batch fail. This makes documentation and reconciliation so much simpler. Hopefully, the data conversion resource transporting the master data is the same person who transports all of the documents with related dependencies.

So simple a child could do it

Note: This paper is written with the assumption that your LSMW object has already been created.

There are only a few things to check on the Vendor Master to ensure that it is ready for posting:

  • That the vendor exists in the SAP system
  • That the vendor has been extended to the appropriate company code.
  • That the vendor hasn't been flagged for deletion.
  • That the vendor hasn't been blocked for posting (APs)
  • That the vendor hasn't been blocked for purchasing (POs)

A few lines of code are all that are needed to ensure that a vendor exists and is configured correctly to receive documents in LSMW.

Getting additional functionality from LSMW

Start by adding these lines to Global Data Definitions and Declarations. This line allows access to the LFA1 and LFB1 without the need to create internal tables or variables to hold the queried information. 

tables: LFA1, LFB1.

Now, in the LSMW object right after the translation has produce the SAP vendor number, add these lines to validate that vendor. These lines work already for APs, but can be modified easily enough to work with POs--see remarks in the source code. This code assumes that the vendor number provided is aligned with the LIFNR field in LFA1 and LFB1; if the vendor number is numeric then it should be 10-digits long with leading zeros. Ensuring the correct format of the vendor number is best handled by the translation routine. The SY-TABIX is added for convenience; it shows what record number from the source file the problem occurs in.

select single * from LFA1 where LIFNR eq BBSEG-NEWKO.
if sy-subrc ne 0.
  write: / BBSEG-NEWKO, 'Vendor not in LFA1.'.
else.
  if LFA1-LOEVM eq 'X'.
    write: / BBSEG-NEWKO, 'Vendor flagged for deletion.'.
  endif.
  if LFA1-SPERR eq 'X'.
    write: / BBSEG-NEWKO, 'Vendor blocked for posting.'.
  endif.
*  Un-remark these lines for purchase orders.
*  if LFA1-SPERM eq 'X'.
*    write: / BBSEG-NEWKO, 'Vendor blocked for purchasing.'.
*  endif.
  select single * from LFB1 where LIFNR eq BBSEG-NEWKO
   and BUKRS eq BBKPF-BUKRS.
  if SY-SUBRC ne 0.
    write: / BBKPF-BUKRS, 'Vendor not in CC', BBSEG-NEWKO.
  else.
    if LFB1-LOEVM eq 'X'.
      write: / BBSEG-NEWKO,
         'Vendor flagged for deletion in CC', LFB1-BUKRS.
    endif.
    if LFB1-SPERR eq 'X'.
      write: / BBSEG-NEWKO,
         'Vendor blocked for posting in CC', LFB1-BUKRS.
    endif.
*    Un-remark these lines for Purchase Orders.
*    if LFB1-SPERM eq 'X'.
*      write: / BBSEG-NEWKO,
*         'Vendor blocked for purhasing in CC', LFB1-BUKRS.
*    endif.
  endif.
endif.
Programming Language: 
ABAP