SAP® Documentation

Single view

/SAPCND/CL_MASTERDATA_UNIT_SRV - CT Masterdata unit testing

General Data in Customer Master   Vendor Master (General Section)  
This documentation is copyright by SAP AG.
SAP E-Book

Functionality

  1. Creation of condition records - CONDITION_CREATE
Condition records are created with the application and usage field values returned by the BADI's. The condition records created are committed to the database.
The validation of the condition technique condition record creation API's is achieved by validating against the actual number of condition records in database.
  1. Selection of condition records - CONDITION_SELECT
Condition records created in the step(1) above are selected with the condition technique condition record selection API's . Condition records are selected by only one fieldname at a time.
The validation of the condition technique condition record selection API's is achieved by validating every field of a condition record selected by the API with the actual value in the database.
  1. Modification of condition records - CONDITION_CHANGE
Condition records created in the step(1) above are changed with the condition technique condition record change API's . The fieldnames with the values to be changed are returned by GET_USAGE_CHANGE_VALUES method of /SAPCND/TST_UNIT_USG BADI. The changes made are committed to the database.
The validation of the condition technique condition record change API's is achieved by validating every field of a condition record changed by the API with the actual value in the database.
  1. Deletion of condition records - CONDITION_DELETE
Condition records created in the step(1) above are deleted with the condition technique condition record delete API's . The deletions made are not committed to the database. This helps in checking the overlapping condition records functionality.
The validation of the condition technique condition record deletion API's is achieved by checking if after deletion the release_status field is 'x' and the dbaction_tabl field is 'U'.
  1. Overlap detection and resolution in condition records - CONDITION_OVERLAP
Overlapping condition records scenario is simulated for every condition maintenance group and checked if the overlap is detected by condition technique APIs. This overlap is then resolved by two means:
  1. By changing the validity period of one of the overlapping condition records
  2. By deleting one of the overlapping condition records.
After both these methods it is checked if the overlap is resolved.
  1. Maintain Scales for the condition records - SCALES_MAINTAIN
The scales are maintained for the condition records.
  1. A scale is created for a condition record.
  2. Another scale line is added to the scale created sbove.
  3. The second scale line added above is then deleted.
  4. The complete scale is deleted.
  5. Finally the condition record is deleted.
  • KOPOS Check in Condition Records - KOPOS_CHECK
  • Check for sequence number of condition supplement (KOPOS) in Condition Records
    1. The kopos is set to 2, and then the record is created.
    2. The error '743' of message class '/SAPCND/MAINTENANCE' should be detected and record should be rejected.
    3. The kopos is set to 1.
    4. The record ahould be successfully maintained and saved.
    5. The kopos is set to 2 directly in the database bypassing the API.
    6. The record is selected in change mode.
    7. The error '743' of message class '/SAPCND/MAINTENANCE' should be reported as the record for which kopos = 2 cannot be selected in change mode, though the record is selected in display mode.
    8. The condition record is hard deleted.
  • Overlap of Condition Records - without Select Call - CONDITION_OVERLAP2
  • Overlapping condition records scenario is simulated for every condition maintenance group and checked if the overlap is detected by condition technique APIs.
    1. A condition record is created and persisted.
    2. Second record with the same semantic key needs to be created.We have two use cases here:
    ,, Use case 1: the record created above is moved to display mode.
    ,,Use case 2: clear the buffer. And also there is no explicit select call.
    1. The second record is created.
    2. Now both the records should be erroneous due to overlap.
    3. The first record is hard deleted as this could lead to inconsistency with the other methods in the class.
    4. Get the records from the working set buffer
    5. All the records in the working set buffer should be erroneous.






    BAL_S_LOG - Application Log: Log header data   rdisp/max_wprun_time - Maximum work process run time  
    This documentation is copyright by SAP AG.

    Length: 5419 Date: 20190620 Time: 092956     sap01-206 ( 24 ms )

    Our Service

    Looking for Support? Questions?

    The

    Consolut

    Callback-Service

    Leave us your contact details and we will call you back. Panels marked with * are mandatory.