16 second delay after PhoneNumber change - Customer Entry - CheckDupPerCon method

When a phone number is added or changed to the Customer Contact in Customer Maintenance, Epicor takes 16+ seconds to respond. I did a trace, and see that the CheckDupPerCon method has an execution time of 16196ms! We currently have 834,933 records in the CustCnt table. Suggestions on how I we can speed this up?

We’re on 10.2.300.12, and testing our upgrade to 10.2.500 next month.


      <localTime>1/14/2020 09:43:39:1325599 AM</localTime>
      <executionTime total="16196" roundTrip="16184" channel="0" bpm="3" other="9" />
        <parameter name="vName" type="System.String"><![CDATA[]]></parameter>
        <parameter name="vEmail" type="System.String"><![CDATA[]]></parameter>
        <parameter name="vPhone" type="System.String"><![CDATA[redacted]]></parameter>
        <parameter name="vSysRowID" type="System.Guid"><![CDATA[00000000-0000-0000-0000-000000000000]]></parameter>
        <parameter name="CallContext" type="Ice.Bpm.Context.ContextDataSet">
          <ContextDataSet xmlns="http://www.epicor.com/Ice/300/Bpm/Context">

What does it do if it does find a duplicated Phone Num? Ask you about using the existing contact?

If you always ignore any message (and allow two contacts to have the same number), make a BPM on
PerConImpl.CheckDupPerCon to set param vPhone to null.

I’m assuming that would speed things up, as it shouldn’t be searching for records where vName, vEmail and vPhone are all blank/null.

Okay, I see that on just tabbing from the email or address field causes that method to execute. If a matching email or phone are found, it prompts you with the Partial Matching Contact dialog.

I assume you still want this functionality.


I do notice that it matches phone #’ regardless of the non-numeric symbols.
215-555-1212 matches 2155551212 and (215)555-1212

And a trace shows that the symbols are passed to the method

    <parameter name="vName" type="System.String"><![CDATA[]]></parameter>
    <parameter name="vEmail" type="System.String"><![CDATA[]]></parameter>
    <parameter name="vPhone" type="System.String"><![CDATA[(215)555-1211]]></parameter>
    <parameter name="vSysRowID" type="System.Guid"><![CDATA[00000000-0000-0000-0000-000000000000]]></parameter>

Does it take the same time to respond to checking for 2155551212 as it does 215-555-1212 ?

Thought about it some more…

Stripping of the non-numeric characters probably wont help. Because it has to strip them out of every existing record before each check.

An interesting test (in a test environment) would be to export the phone numbers, strip all non-numerics, then DMT them back in. The test is if the search is quicker if stored phone has no non-numerics.

Just for SnGs have you had a look at your indexes and if there is a more optimal way? Perhaps even manually running an update statistics. I’d be wanting to understand a bit more on how the CheckDupPerCon method works from a SQL query perspective, profiling it as well, it may not be the CustCnt table that’s slowing things down, it may be some other complementary one. You do ask why this method exists. If you have a unique index on the Custcnt table, you would never have a need to check for duplicates in the first place.

Now I’m interested why :thinking:

Anyway that’s my 2c

My guess is that it isn’t to absolutely prevent dupes (you can Hit OK on the Dupe found dialog and make the dupe anyway), but rather prevent accidental duplicate entries. So that only one contact record exists per real person

1 Like

Your probably right… I was going to follow up with a comment on the bad old days of E9, percon and custcnt, but I’d rather leave that nightmare in the dim distant past. :angry:

I have to say I’m so glad that the Primary Context checkbox in Person Contact Maintenance now functions.