/SAPCND/CL_MASTERDATA_UNIT_SRV - CT Masterdata unit testing

General Data in Customer Master   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
This documentation is copyright by SAP AG.

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 recordchange 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 recorddelete 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.

General Material Data   General Material Data  
This documentation is copyright by SAP AG.


Length: 5075 Date: 20120526 Time: 071710     triton ( 156 ms )