A couple changes that were seen in the validation results of our test with BoTW (though in re-reading the various bank spec sheets these changes seem to be correct for all banks. If that is not so then we can revert some of these changes and move them into the BankOfTheWest subclass).
Also, changed how we search for pre-existing records. This should better support subclassing record types as well as support for a "non-standard" record types for specific banks (example if Bank C makes use of the Reserved field space and a custom record type is needed that cannot be a subclass of the existing standard record).
Currently, when dealing with the CheckDetail records we cast to dynamic and access the ItemAmount property, hoping it exists and is defined as a decimal. We might want to look at a few of these records and the "bare minimum, required fields" and create interfaces out of them. This would only be needed if a custom record cannot be a subclass of the CheckDetail record type so we'll leave it for later.
A couple changes that were seen in the validation results of our test with BoTW (though in re-reading the various bank spec sheets these changes seem to be correct for all banks. If that is not so then we can revert some of these changes and move them into the BankOfTheWest subclass).
Also, changed how we search for pre-existing records. This should better support subclassing record types as well as support for a "non-standard" record types for specific banks (example if Bank C makes use of the Reserved field space and a custom record type is needed that cannot be a subclass of the existing standard record).
Currently, when dealing with the CheckDetail records we cast to
dynamicand access theItemAmountproperty, hoping it exists and is defined as a decimal. We might want to look at a few of these records and the "bare minimum, required fields" and create interfaces out of them. This would only be needed if a custom record cannot be a subclass of the CheckDetail record type so we'll leave it for later.