|
************************************************************************ * CHANGE DOCUMENT DISPLAY FOR CONDITION RECORDS************************************************************************ GENERAL INFORMATION: This program is used for the display of change documents for conditionrecords. First, the program RV16xCHD (x = condition usage) is invoked. Uponexecution, the function module SD_CONDITION_CHANGE_DOCS_LOAD is called.The purpose of this function module is to read the change documenttables CDHDR and CDPOS and load 2 internal tables that will be usedwhen writing change document data to the screen. These tables are: I_LEVEL1: This table consists of "change header" data: - the date and time of the change - the user & transaction code making the change - info about the condition (type, table, etc.) I_LEVEL2: This table consists of "change item" data: - the table and fieldname that was changed - a text description of the change - the "before" and "after" values for the field Each record in table I_LEVEL1 may have 1 or many associated records intable I_LEVEL2. Each record in table I_LEVEL2 must have at least 1associated record in table I_LEVEL1. After loading the tables, controlis returned to RV16xCHD. Upon initial execution of RVxCHD and anytime thereafter when the userinvokes an action (double click on a line, sort, print, etc.) thefunction module SD_CONDITION_CHANGE_DOCS_DISPL is executed. Thisfunction module reads the internal tables: I_LEVEL1, I_LEVEL2 andI_LEVEL3 and writes change document data to the screen in a hierarchialformat. Also in this function module, the internal table I_LEVEL3 isloaded with data from "related changes". A related change means thatthe validity period of 1 condition was changed and this resulted in thesystem automatically making a change to the validity period of anothercondition record. This philosophy of "related changes" stems from thefact that only 1 condition record can be active for any 1 date.Currently, there are 4 ways in which the validity period for 1condition record can be automatically changed by another: 1) The validity period of the new (or changed) condition record fullyoverlaps an existing record. EXISTING (valid 7/1/95-07/31/95) /-----/ NEW (valid 1/1/95-12/31/95) /-----------------/ The existing condition record will be deleted, resulting in: RESULT (valid 1/1/95-12/31/95) /-----------------/ 2) The validity period of the new (or changed) condition is fullyoverlapped by an existing record. EXISTING (valid 1/1/95-12/31/95) /-----------------/ NEW (valid 7/1/95-07/31/95) /-----/ The existing condition record will be split, resulting in: RESULT (valid 1/1/95-06/31/95) /---//------//----/ valid 7/1/95-07/31/95 valid 8/1/95-12/31/95 3) The starting date of the new (or changed) condition overlaps intothe validity period of an existing record. EXISTING (valid 1/1/95-12/31/95) /-----------------/ NEW (valid 7/1/95-07/01/96) /---------------/ The ending date of the existing condition is moved: RESULT (valid 1/1/95-06/31/95) /---//----------------/ valid 7/1/95-07/01/96 4) The ending date of the new (or changed) condition overlaps into thevalidity period of an existing record. EXISTING (valid 7/1/95-07/01/96) /---------------/ NEW (valid 1/1/95-12/31/95) /-----------------/ The begin date of the existing condition is moved: RESULT (valid 1/1/95-12/31/95) /-----------------//--/ valid 1/1/96-07/01/96 The data written to the screen consists of 3 levels which can bedisplayed in a hierarchial format. Each of the 3 levels has its ownassociated internal table, from which the data is retrieved whenwriting to the screen. level 1 = i_level1 - date of change, time, variable key... level 2 = i_level2 - fields changed, old/new value level 3 = i_level3 - changes made to/by other recs **************** END OF DOCUMENTATION ******************************** |