eaDirect maintains a copy of each version set you publish; it does not replace or delete version sets. This lets you maintain a chronological history of application design modifications over time.
Maintaining old version sets also creates a "snapshot" of a statement, freezing the original presentation to enable users to view it unchanged in the future. When a user retrieves an old, or historical statement, eaDirect displays the data for that month’s statement using the version set that was in effect when the data file was indexed.
Warning: Leave old version sets in place to enable the display of historical statements with the original formatting.
For example, if on June 20th, a user retrieves a statement for April 20th, that statement would appear just as it did when originally viewed in April. No data or design changes made to the application after April 20th would apply to the April statement, regardless of when it is viewed. As long as you leave the original version set in place, the original format and content of the April statement remain unchanged.
Because eaDirect looks for a version set using the logic described above, it means you cannot make adjustments to a version set published and used with an old statement. For example, if you have version 2.0 of an application in production, and found issues with your version 1.0 application statements, you cannot make adjustments to the version 1.0 version set retroactively. You would only have viewing access to the "snapshot in time" of the version 1.0 statements. If you were to delete the version set published for version 1.0, eaDirect would look for another version set in accordance with the logic described in How eaDirect Determines Which Version Set to Use for Live Retrieval, and inevitably use a version set not intended for that statement, likely displaying it improperly.