I would like the ability to remove the [(Co?)List(Buyer?)[Agent|Office]][Field] fields in favor of expanding the associated members and offices. My main hesitance with this is that it will likely negatively impact our availability reports. I believe these fields are pulled forward from RETS because RETS had a flat structure. Now that we are leveraging a standard with relational support, I think we should decide if these fields should be included in any of the APIs today. There is a need for historical data. Some data does belong on the listing and should not change after a listing closes.
My hope with bringing this up is that we can act by doing one of or both of the following:
not disincentivizing FBS from doing this work with RESO reporting. Lower standards counts should not be a reason for proceeding with this.
Make this behavior the industry standard and identify the fields that are significant for historical purposes.
I would like the ability to remove the [(Co?)List(Buyer?)[Agent|Office]][Field] fields in favor of expanding the associated members and offices. My main hesitance with this is that it will likely negatively impact our availability reports. I believe these fields are pulled forward from RETS because RETS had a flat structure. Now that we are leveraging a standard with relational support, I think we should decide if these fields should be included in any of the APIs today. There is a need for historical data. Some data does belong on the listing and should not change after a listing closes.
My hope with bringing this up is that we can act by doing one of or both of the following: