String loan custom fields that have date strings will get nulled out the second time they are set, date / integer / decimal loan custom fields get nulled out, and timestamp strings will have a date added.

[TimH-SL]

For custom fields that are strings where we set a date value as a string I see that Encompass will add a "dateValue" to the return from a GET Loan request after the string value has been set. After that, EncompassRest tries to deal with the custom field as a date instead of a string because it sees the "dateValue" field. I suspect this may be a bug.

The problem we are seeing is that string custom fields that have a value set to a string date will get nulled out the second time they are set because the "dateValue" is sent in the loan update, instead of the string value.

This also causes an issue with dates getting appended to timestamp-only string values.

I think we need to look at the custom field definition and use that to determine whether to utilize the value as a date.

We are a bit behind your code base right now since we have forked off of it. So, I might not do a pull request for this, but this is how I am currently solving this:

In Loans/CustomLoanField.cs I have line 14-30:

                if (Descriptor is NonStandardFieldDescriptor && (Descriptor?.Format == Schema.LoanFieldFormat.STRING))
                {
                    //If it is a string, just return the string
                    return customField.StringValue;
                }
                else
                {
                    if (customField.DateValue.HasValue)
                    {
                        return customField.DateValue;
                    }
                    if (customField.NumericValue.HasValue)
                    {
                        return customField.NumericValue;
                    }
                    return customField.StringValue;
                }

And, line 48-55 I have:

            if (Descriptor is NonStandardFieldDescriptor && (Descriptor?.Format == Schema.LoanFieldFormat.STRING))
            {
                //If it is a string, keep it as a string
                customField.StringValue = value?.ToString();
            }
            else
            if (customField.DateValue.HasValue || customField._dateValue?.Dirty == true)
            {

[TimH-SL]

I just tested custom fields that were formatted as "DATE", "INTEGER", and "DECIMAL_2" and in each case you have to set the "stringValue" in order to set them. Setting a "numericValue" or "dateValue" doesn't work.

Is no one updating non-string custom loan fields using EncompassRest? It's strange that this was not found before. I tend to wonder if it's something in our Encompass setup.

[TimH-SL]

To illustrate, this is an example of a patch request:

This is the definition of this field:

And this is the patch request call to the API:

PATCH https://api.elliemae.com/encompass/v1/loans/112f122e-f5cd-4c9a-80ac-ff26b1ee7341

{"customFields":[{"fieldName":"CX.APP.003","numericValue":2.0}],"encompassId":"112f122e-f5cd-4c9a-80ac-ff26b1ee7341"}

The custom field is defined as "INTEGER". When I pull the loan after doing this patch, the custom field comes back as this:

{
            "fieldName": "CX.APP.003",
            "id": "CustomField/1601"
},

Thus it is null. If instead I update the loan using "stringValue":

{"customFields":[{"fieldName":"CX.APP.003","stringValue":"2.0"}],"encompassId":"112f122e-f5cd-4c9a-80ac-ff26b1ee7341"}

It works:

{
            "id": "CustomField/1601",
            "fieldName": "CX.APP.003",
            "numericValue": 2.0,
            "stringValue": "2"
},

[TimH-SL]

Given what I found out, this is our latest version of CustomLoanField.cs that we are testing:

public override object? Value
{
    get
    {
        var customField = Loan.CustomFields.GetById(FieldId);
        if (customField != null)
        {
            if (Descriptor is NonStandardFieldDescriptor && (Descriptor?.Format == Schema.LoanFieldFormat.STRING))
            {
                //If it is a string, just return the string
                return customField.StringValue;
            }
            else
            if (Descriptor is NonStandardFieldDescriptor && (Descriptor?.Format == Schema.LoanFieldFormat.INTEGER))
            {
                //If it is an integer, don't return a double (NumericValue is a double)
                return Convert.ToInt32(customField.NumericValue);
            }
            else
            {
                if (customField.DateValue.HasValue)
                {
                    return customField.DateValue;
                }
                if (customField.NumericValue.HasValue)
                {
                    return customField.NumericValue;
                }
                return customField.StringValue;
            }
        }
        return null;
    }
    set
    {
        if (value is LoanField loanField)
        {
            value = loanField.Value;
        }

        var customField = Loan.CustomFields.GetById(FieldId);
        if (customField == null)
        {
            customField = new CustomField { FieldName = FieldId };
            Loan.CustomFields.Add(customField);
        }

        //Dates, numeric values, and strings should all be set as a stringValue without regard to the custom field definition.
        //Encompass doesn't work with setting a dateValue for a DATE or DATETIME custom field or numericValue for an INTEGER or DECIMAL_2 custom field, it will just null out the value if you try.
        customField.StringValue = value?.ToString();

        /*
        if (customField.DateValue.HasValue || customField._dateValue?.Dirty == true)
        {
            customField.DateValue = value != null ? Convert.ToDateTime(value) : (DateTime?)null;
            customField.StringValue = value?.ToString();
            customField._stringValue!.Dirty = false;
        }
        else if (customField.NumericValue.HasValue || customField._numericValue?.Dirty == true)
        {
            customField.NumericValue = value != null ? Convert.ToDecimal(value) : (decimal?)null;
            customField.StringValue = value != null ? FormattedValue : null;
            customField._stringValue!.Dirty = false;
        }
        else if (customField.StringValue != null || customField._stringValue?.Dirty == true)
        {
            customField.StringValue = value?.ToString();
        }
        else
        {
            switch (value)
            {
                case null:
                    customField.StringValue = null;
                    break;
                case string str:
                    customField.StringValue = str;
                    break;
                case DateTime dateTime:
                    customField.DateValue = dateTime;
                    break;
                default:
                    customField.NumericValue = Convert.ToDecimal(value);
                    break;
            }
        }
        */
    }
}

[mtucker6784]

Sorry, I know this is a very late bump -

@TimH-SL thanks for the code update. I was having a similar problem with custom fields, but updating the cs file and recompiling the DLL seemed to fix what I was observing.

Thanks again!

[paulmoseley]

Well, this was all very interesting. I just stumbled across this issue a few weeks ago. I've been using the .Value property instead of .stringValue/.dateValue/.numericValue to set these custom field values, and so was noticing that a custom field that already had a value in it was being nulled out when an update was attempted :(. My solution was to do a separate update that blanked out the fields that needed to be updated, so I ended up with two updates instead of one (blush). I'll go and refactor my code to use the recommendations above. Thanks @TimH-SL ! :)