Skip to main content

Chapter 4: Data Selection and Validation Engine

After learning how the Invoice Creation and Posting System transforms calculations into real invoices, you might wonder: "How does the system ensure it's working with accurate, complete data?" Welcome to the Data Selection and Validation Engine - the quality control librarian of our system!

What Problem Does This Solve?​

Imagine you're trying to calculate service charges, but you discover:

  • Some properties are missing area measurements
  • Contract dates don't make sense (end date before start date)
  • Tenant information is incomplete
  • Service rate tables have gaps for certain time periods

Without proper data validation, you could end up with incorrect calculations, failed invoices, or angry tenants. The Data Selection and Validation Engine acts like a meticulous librarian who not only finds the right information from multiple databases but also double-checks everything before passing it along.

A Real-World Example​

Let's say you want to calculate February 2025 service charges for Building A. Here's what the engine does:

Step 1: Find all active rental units in Building A Step 2: Verify each unit has complete property details (area, usage type) Step 3: Confirm tenants are properly assigned to each unit Step 4: Check that service rates exist for February 2025 Step 5: Validate that all dates are logical and consistent

Result: Only properties with complete, valid data proceed to calculation

Key Components of the Data Validation Engine​

The engine consists of four main parts:

1. User Input Validation​

This checks what you enter on the selection screen:

AT SELECTION-SCREEN.
  IF sy-ucomm = 'ONLI'.
    READ TABLE s_repper INTO DATA(ls_per) INDEX 1.
    IF ls_per-low(4) <> ls_per-high(4) AND ls_per-high IS NOT INITIAL.
      MESSAGE e000(ok) WITH 'Both From year and To year should be same'.
    ENDIF.
  ENDIF.

This code validates your date ranges - it makes sure you don't accidentally select February 2025 to March 2026, which would be invalid for monthly billing. It's like a librarian saying "You can't check out books from 2025 and return them in 2026!"

2. Database Query Logic​

This finds all the information needed from multiple tables:

SELECT FROM vibdro AS unit
  INNER JOIN vibdroocc AS occup
  ON unit~intreno EQ occup~intreno
  WHERE unit~bukrs IN @ms_input-bukrs[]
  INTO TABLE @DATA(lt_unit_occup).

This query joins property tables with occupancy tables to get complete information about which units are rented and who the tenants are. Think of it as cross-referencing multiple card catalogs to get the full story.

3. Data Completeness Checks​

This ensures all required information is present:

IF sy-subrc <> 0.
  MESSAGE 'No records are selected' TYPE 'S'.
  CHECK 1 = 2.
ENDIF.

If the query finds no matching records, the system stops processing and tells you why. This prevents the system from trying to calculate charges for non-existent properties.

4. Data Consistency Validation​

This checks that the data makes logical sense:

DELETE rt_results WHERE partner EQ ''.

This code removes any records where tenant information is missing, ensuring only complete property-tenant relationships proceed to calculation.

How to Use the Validation Engine​

The engine works automatically behind the scenes, but here's how you interact with it:

Step 1: Specify Your Selection Criteria​

SELECT-OPTIONS: s_bukrs FOR vibdro-bukrs OBLIGATORY,
                s_swenr FOR vibdro-swenr,
                s_repper FOR gv_repper OBLIGATORY.

You specify which properties and which time periods you want to process. The OBLIGATORY keyword means these fields are required - the system won't let you proceed without them.

Step 2: System Validates Your Input​

METHOD validate_input_data.
  " System checks that your selections make sense
  rv_valid = abap_true.
ENDMETHOD.

The system automatically validates your selections before doing any expensive database operations.

Step 3: Retrieve and Verify Data​

METHOD get_data_from_input.
  " Query multiple tables and cross-reference information
  " Return only complete, valid records
ENDMETHOD.

The engine queries multiple SAP tables simultaneously and returns only records that pass all validation checks.

What Happens Under the Hood?​

Let's trace through what happens when you request property data:

Here's what happens step by step:

Step 1: Input Validation​

IF ls_per-low(4) <> ls_per-high(4).
  MESSAGE e000(ok) WITH 'Both From year and To year should be same'.
ENDIF.

The system checks your date selections to ensure they make business sense. You can't calculate monthly charges across different years.

Step 2: Property Data Retrieval​

SELECT FROM vibdro AS unit
  LEFT OUTER JOIN vibdmeas ON vibdmeas~intreno EQ vibdro~intreno
  WHERE vibdro~intreno = @lt_unit_occup-intreno
  INTO TABLE @DATA(lt_vibdro).

The engine queries property tables to get basic information like area measurements and usage types for each unit.

Step 3: Occupancy Cross-Reference​

SELECT FROM vibdro AS unit
  INNER JOIN vibdroocc AS occup
  ON unit~intreno EQ occup~intreno
  WHERE occup~occfrom LE @sy-datum
    AND occup~occto   GE @sy-datum
  INTO TABLE @DATA(lt_unit_occup).

The system cross-references property data with occupancy records to ensure you're only processing currently rented units.

Step 4: Tenant Information Validation​

SELECT FROM vicncn INNER JOIN vibpobjrel
  ON vicncn~intreno EQ vibpobjrel~intreno
  WHERE vibpobjrel~role EQ 'ZS0001'
    AND vibpobjrel~validfrom LE @sy-datum
    AND vibpobjrel~validto GE @sy-datum
  INTO TABLE @DATA(lt_partner).

The engine validates that each property has a properly assigned tenant with valid contract dates.

Step 5: Data Quality Filtering​

DELETE rt_results WHERE partner EQ ''.

Finally, the system removes any incomplete records so only properties with full information proceed to the Service Charge Calculation Engine.

The Engine's Smart Validation Features​

1. Multi-Table Cross-Validation​

rt_results = VALUE #( FOR ls_vibdro IN lt_vibdro
  LET lv_recnnr = VALUE #( lt_unit_occup[ intreno = ls_vibdro-intreno ]-occrecnnr OPTIONAL )
      ls_partnr = VALUE #( lt_partner[ recnnr = lv_recnnr ] OPTIONAL ) IN
  ( bukrs = ls_vibdro-bukrs
    partner = ls_partnr-partner ) ).

The system automatically links information from multiple tables to create complete property records. It's like a librarian who checks multiple card catalogs to ensure every book reference is complete.

2. Business Logic Validation​

WHERE occup~occfrom LE @sy-datum
  AND occup~occto   GE @sy-datum

The engine applies business rules to ensure only currently valid contracts are included. Expired contracts are automatically excluded.

3. Data Consistency Checks​

IF sy-subrc <> 0.
  MESSAGE 'No records are selected' TYPE 'S'.
  RETURN.
ENDIF.

The system provides clear feedback when data is missing or invalid, helping you understand why certain properties might be excluded.

4. Optional vs. Required Data Handling​

LET ls_partnr = VALUE #( lt_partner[ recnnr = lv_recnnr ] OPTIONAL ) IN

The engine distinguishes between required and optional data, using the OPTIONAL keyword to handle cases where some information might legitimately be missing.

Real-World Validation Example​

Let's walk through a complete validation scenario:

Scenario: Calculate service charges for 10 apartments in Building C for March 2025

Step 1: User enters Building C and March 2025 Step 2: Engine validates that March 2025 is a valid single month period Step 3: Engine finds 12 total units in Building C Step 4: Engine cross-checks occupancy - finds 10 are currently rented, 2 are vacant Step 5: Engine validates tenant assignments - finds 1 unit missing tenant data Step 6: Engine checks property measurements - finds 1 unit missing area data

Result: Engine returns 8 complete, validated property records for calculation

User sees: Clear message explaining why 4 units were excluded (2 vacant, 1 missing tenant, 1 missing area)

Advanced Validation Features​

1. Domain Value Validation​

CALL FUNCTION 'GET_DOMAIN_VALUES'
  EXPORTING domname = 'ZZUSAGE'
  TABLES values_tab = lt_dom_value.

The system validates usage types against allowed values, ensuring only valid property types (residential, commercial, retail) are processed.

2. Date Range Logic​

WHERE vibdmeas~validfrom LE @sy-datum
  AND vibdmeas~validto   GE @sy-datum

The engine applies time-based validation to ensure you're using measurement data that was valid during your calculation period.

3. Conditional Data Requirements​

SELECT * FROM zre_serv_charge INTO TABLE @lt_serv
  WHERE perd_beg LE @ls_repper-low
    AND perd_end GE @ls_repper-high.
IF sy-subrc IS NOT INITIAL.
  " Use fallback rates if period-specific rates not found
ENDIF.

The system handles missing service rates gracefully by using fallback data when period-specific rates aren't available.

Integration with Other Components​

The validation engine works closely with:

Conclusion​

The Data Selection and Validation Engine serves as the quality control gatekeeper of our rental property system. Like a meticulous librarian who double-checks every reference before lending you a book, it ensures that only complete, accurate, and consistent data flows through to other system components.

Key benefits:

  • Input validation prevents user errors before expensive processing
  • Multi-table cross-referencing ensures data completeness
  • Business logic validation applies rental industry rules automatically
  • Clear error messages help users understand and fix data issues
  • Graceful fallback handling manages missing optional data

The engine acts as a trusted foundation that both the Service Charge Calculation Engine and Invoice Creation and Posting System depend on for reliable data quality.

In our next chapter, we'll explore the User Interface Integration Layer to understand how the system creates seamless user experiences by coordinating between different screens and user interactions.