Chapter 3: Frontend Data Validation
In the previous chapter, we learned how MassUpload reads your file and populates the workbench. The data is now loaded, but is it correct? Is it safe to send to SAP? Sending incorrect data can cause confusing errors or, worse, create bad financial records.
This is where Frontend Data Validation comes in. It's the program's built-in quality control inspector.
Your Digital Proofreader
Imagine you've just written a long, important document. Before you publish it, you'd give it to a proofreader. They would check for spelling mistakes, grammatical errors, and factual inaccuracies. They would mark up the document with helpful corrections so you can fix everything before it goes public.
Frontend Data Validation is that proofreader for your data. Before attempting to post a single line item, it meticulously inspects every row in itab1 to catch problems early. This process turns a potential "upload and pray" scenario into a confident, "check and correct" workflow.
This validation step checks for three main types of errors:
- Existence Checks: Does the Company Code
1234actually exist in SAP? Is this GL Account a real account? - Format Checks: Is the date
2023-01-15written in the requiredDD.MM.YYYYformat? Is the amount a valid number? - Business Rule Checks: Does a line item follow complex company policies, like requiring a Cost Center for certain types of expenses?
How Validation Works: A Step-by-Step Inspection
The validation process is triggered right after the data is ingested. The program systematically checks every row, one by one, against SAP's master data and rules.
Let's look at the code that brings this inspection process to life.
1. The VALIDATIONS Routine
The entire process is managed within a central routine (a FORM) called validations. This routine is called immediately after the data is loaded from your file.
START-OF-SELECTION.
IF NOT header IS INITIAL .
IF exc_file EQ 'X'.
PERFORM excel_to_internal.
ELSEIF txt_file EQ 'X'.
PERFORM text_to_internal.
ENDIF.
PERFORM validations. " <-- The quality check starts here!
" ... code to display the grid ...
PERFORM display.
ELSE.
MESSAGE 'Please select the file' TYPE 'E'.
ENDIF.
Inside the validations routine, the program performs its checks.
2. Gathering the "Answer Key" (Master Data Caching)
To check if a Company Code from your file is valid, the program needs a list of all correct company codes. It could ask the SAP database for every single row, but that would be very slow.
Instead, it does something much smarter: it gathers all the unique values from your file (e.g., all company codes, all GL accounts) and fetches the master data for them only once. This information is stored in temporary internal tables, creating a fast, local "answer key". This powerful technique is covered in detail in the Master Data Caching chapter.
* Inside FORM validations
FORM validations.
DATA: t_bukrs TYPE TABLE OF t001.
" Get a list of all valid Company Codes from the database
" for all the company codes mentioned in our upload file.
SELECT * FROM t001
INTO TABLE t_bukrs
FOR ALL ENTRIES IN itab1
WHERE bukrs = itab1-company_code.
" ... more SELECT statements for other master data ...
ENDFORM.
3. Checking Each Row and Field
With the "answer key" ready, the program loops through every single line item in itab1 and starts checking.
* Inside FORM validations, after the SELECTs
LOOP AT itab1.
" ... validation checks for the current row happen here ...
ENDLOOP.
Let's look at a few examples of checks performed inside this loop.
Example 1: Existence Check (Company Code)
The program reads our cached table of valid company codes (t_bukrs) to see if the one from the current row exists.
* Check if the Company Code is valid
READ TABLE t_bukrs WITH KEY bukrs = itab1-company_code.
IF sy-subrc NE 0. " sy-subrc is 0 if it's found, non-zero if not
itab1-flag = 'X'. " 'X' marks the row as having an error
itab1-message = 'CO'. " A shortcode for the error type
itab1-message_err = 'Company Code is not valid!!!'.
MODIFY itab1.
ENDIF.
If the READ TABLE fails, it means the company code is invalid. The program then sets the flag field to 'X' and populates the error message fields.
Example 2: Format Check (Date)
SAP expects dates in a specific format. This check ensures the user provided it correctly.
* Check if the Document Date is in DD.MM.YYYY format
SPLIT itab1-document_date AT '.' INTO DATA(mm) DATA(dd) DATA(yyyy).
IF strlen(mm) NE 2 OR strlen(dd) NE 2 OR strlen(yyyy) NE 4.
itab1-flag = 'X'.
itab1-message = 'DD'. " Date Document error code
itab1-message_err = 'Document date should be DD.MM.YYYY!!!'.
MODIFY itab1.
ENDIF.
Example 3: Business Rule Check (Cost Center)
This is a more complex check. A common business rule is that if you post to an expense account (in this company, accounts starting with '6'), you must provide a Cost Center to track where the money was spent.
* If it's an expense account, a Cost Center is mandatory
IF itab1-account+0(1) EQ '6' AND itab1-cost_center IS INITIAL.
itab1-flag = 'X'.
itab1-message = 'CC'. " Cost Center error code
itab1-message_err = 'Cost Center is required for this account'.
MODIFY itab1.
ENDIF.
This check prevents postings that would violate the company's financial tracking policies.
4. Highlighting the Errors
After the validations loop is complete, many rows in itab1 might be flagged with an 'X' and have error messages. The program then uses this information to color the cells red in the Interactive ALV Workbench, providing instant visual feedback to the user.
* This code runs just before displaying the grid
FORM set_cell_colours.
DATA: t_cellcolor TYPE lvc_s_scol.
LOOP AT itab1.
IF itab1-flag EQ 'X'. " If there's an error in this row
" Check which field has the error (e.g., Company Code)
IF itab1-message CS 'CO'.
t_cellcolor-fname = 'COMPANY_CODE'.
t_cellcolor-color-col = 6. " 6 is the code for Red
APPEND t_cellcolor TO itab1-color_cell.
MODIFY itab1 TRANSPORTING color_cell.
ENDIF.
" ... more checks for other fields ...
ENDIF.
ENDLOOP.
ENDFORM.
Conclusion
Frontend Data Validation is a critical, proactive step that ensures the integrity of your data. By acting as a strict but helpful proofreader, it inspects every field for existence, correct formatting, and compliance with business rules. It catches errors at the earliest possible moment and presents them clearly to the user, turning a potentially frustrating process into a simple one of "review, correct, and upload."
Now that we understand how the data is ingested and validated, let's take a closer look at the central data structure that holds everything together.