In the past, changes made to data related to “actively engaged in farming”, cash rent tenant, member information, etc., simply overrode the previous information recorded. But since the determinations related to the information collected on CCC-902 are continuous, the concept of the Business File application is that the determinations are effective for a specific period of time until the plan is revised and new determinations are made by COC. At any point, users should be able to view the producer’s farm operating plans to get an historical view of the changes made to the operation.
This concept is similar to new functionality that is being developed through the MIDAS effort so it is important that State and County Office users understand the concept and how changes made in error affect the historical information available. The reason a “delete” option is not available in the system is because of the need to maintain the historical data.The problem in the data model always is mapping reality to program requirements. In the real world, a death, a change of ownership, etc. occurs at any time, which to me argues for specifying the date of such change. But then the question is how the event is applied to program requirements, which is another kettle of fish, and not an easy set of fish to fry.
When we automated operations on the System/36 we seemed to have two options offered by the IT types: continuous files (i.e., name and address, farm file) or year-specific files (acreage reporting, contracts). That meant the clerk/PA had to translate in her head the significance of new/changed data into the meaning for the applicable program and year. Experience showed those didn't work well enough, so we gradually added time data to some (beginning and end years in the farm producer file) and created year-specific records within others (eligibility file). That helped, but changing file structure was always a major commitment of programming and testing time, so it was hard to justify with our other priorities.
I wonder: is Ctrl-Z a standard in MIDAS, because while good data should be retained, there's always the need to back out bad data.
No comments:
Post a Comment