3CX Assist CMR Number recognizing Outlook

Discussion in 'Windows' started by JRB-LU, Nov 12, 2009.

Thread Status:
Not open for further replies.
  1. JRB-LU

    Joined:
    Nov 12, 2009
    Messages:
    3
    Likes Received:
    0
    Using last update 3CX Assistant v8.9924

    In the CRM module with Outlook 2007 Add-on
    the recognizing of incoming number is not working is there is some spaces between the digits.

    I use a Max digit length parameter of 11

    Example :

    +352 (26) 123456 is recognized

    +352 (26) 12 34 56 is NOT recognized

    My enhancement Request :

    Suppress any non numeric characters such as () + space and dots in the number found in Outlook before comparing it with the incoming number
    during mach search.

    Total 1 or 2 lines of code ...
    Feasible ?
     
  2. Vali_3CX

    Vali_3CX Well-Known Member
    Staff Member 3CX Support

    Joined:
    Dec 12, 2008
    Messages:
    1,476
    Likes Received:
    67
    I'm in love with people which know precisely number of required code lines :mrgreen:
    Now, my question is: direct SIP calls are allowed in Outlook? Or Skype accounts? Or outbound rules? I'm asking because I'm not involved in. If yes, dots and non numeric characters should be suppressed?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. JRB-LU

    Joined:
    Nov 12, 2009
    Messages:
    3
    Likes Received:
    0
    Yes direct SIP are allowed in Outlook, but I don't see how this question is related to mine and how skype could be involved in my question.

    Did you understand that, in my question, Outlook is just seen as the data source of 3CX Assistant CRM module in the incoming number recognizing process ?

    Furthermore, the incoming number recognizing process by 3CX CRM module with comparison with Outlook content is working,
    the problem is just that this comparison is done with Outlook number as it is stored with separator
    instead of doing minimum data cleansing with a replace of +, . () and spaces by empty chain. (1 or 2 lines guaranted in C++) ;-) before processing this comparison with incoming number.

    So, any hope to implement this enhancement that would greaty increase the hit ratio of CRM recognizing of incoming number ?
     
  4. Vali_3CX

    Vali_3CX Well-Known Member
    Staff Member 3CX Support

    Joined:
    Dec 12, 2008
    Messages:
    1,476
    Likes Received:
    67
    well, to see if it's a misunderstanding (english is not my native language) - if yes, post your request on "feature request" section.
    Now, sample of possible "numbers" (in fact, they are destinations)

    - direct sip call - contains non-numeric characters:
    "Vali, 3CX"<sip:101@3cx.com:5060>
    - non-numeric outbound rule prefixing a phone number:
    abc0035711111111
    - numeric outbound rule to call a Skype destination through Skype gateway:
    9echo123
    - non-numeric outbound rule on a dotted skype destination:
    skpvali.3cx
    - in some circumstances, the "+" sign needs to be converted to "00", while in others it should pe passed as is.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  5. polyphemos

    Joined:
    Feb 4, 2008
    Messages:
    16
    Likes Received:
    0
    I just spotted the same problem as JRB-LU. It is not about outgoing calls from Outlook, as Vali seems to suspect, but about the recognition of incoming numbers.

    As the issue does not seem to have been addressed since November, let me just restate the facts.

    The Outlook CRM plugin receives the caller ID as a string of numbers and tries to match it to the numbers in the Outlook database. But it will not match a number if it is grouped with spaces (like 12 34 56 78 for 12345678). As this is how numbers are frequently entered, the Assistant will often not find a match even though it exists.

    This seems to be a simple oversight and should - like JRB-LU says - be very easy to correct.

    It appears that spaces are the only thing that causes trouble. I tested various other symbols that commonly appear in phone numbers (dash, plus, parentheses) and all are handled OK. Also, spaces between the parts of a number (country code, area code, local number) work OK. It is only spaces inside the local number which don't work. If incoming string is 012345678, the Assistant will match to

    +46 12 345678
    +46 (12) 345678
    +46 12-345678
    012 345678

    but NOT to

    34 56 78

    in ANY of those cases.

    I will list this as a feature request as well - although it's really a bugfix, don't you think?

    /Peter
     
Thread Status:
Not open for further replies.