Unique Customer Names

started a topic over 2 years ago

DEAR has a fundamental issue when it comes to Customer Names when you aren't dealing with Businesses but in fact individuals. The Customer Name needs to be unique, but when you're selling to countless John Smiths you aren't able to manage this appropriately and are forced to create John Smith 1, John Smith 2 etc.

This is less than ideal and is causing a selection of our clients to become incredibly frustrated. Is there no chance that the Customer could use the DEAR Customer ID (Hidden from end-users) to distinguish uniqueness and therefore enable Customers of the same name to exist?

11 people like this idea
  • Absolutely agree, the current approach of the Customer Name needing to be unique is not acceptable and results in customer documents having incorrect details on them, which they object to for e.g. tax reasons.

    Given you already use UIDs, the only sensible solution is to allow duplicate names so that sales details, and thus customer documents, can be correct.

    1 person likes this
  • Agree there has to be a way of identifying each customer individually, as there is a Dear unique reference for each customer this does need to be on the face of all documentation related to that customer.

    1 person likes this
  • I've also run into this multiple times and end up just using the email address as the customer name.

    It is also hindered by the fact that you cannot query customers / contacts by email address using the API. So when trying to match up customers from an external system it is a nightmare.

    We've resorted to having to periodically fetch every single customer from their API and loop through, matching up email addresses on our side and storing Dear's ID against them.

    1 person likes this
  • Yeah the no searching by email is just bizarre.  (Can you even really call it an API if you can't do basic searches?!).  The API is also far, far too slow for realtime operations in many cases.  We started with the email as name approach but decided against it ultimately...we try not to go against the intention of fields wherever possible as it can lead to later tech-debt style issues where you are relying on something that you've essentially hacked into a different purpose.

    But seriously, what is the point of having UIDs for elements if you can't have more than one customer element with the same name?  Like any business, this is a very regular occurrence.

    Thus, we've essentially built a local cache of the DEAR JSON blobs for the major elements (so basically UID and JOSB blob is a DB), and do queries against that (MySQL and Postgres both have JSON query functions these days).

    ...the only time we hit the API is to periodically pull changed data and where we have to do writes.  It ends up very effective but it's needlessly complicated...if the API were more complete, and much quicker, it would dramatically reduce the needed code complexity.

    2 people like this
  • Agree fully on this issue - and being able to find customers in searching (POS specifically) by customer phone number, email address or similar.

    Although I understand that name is the unique identifier, this needs some re-think.

  • This is potentially data protection nightmare and should be considered a critical issue to be fixed immediately before any other developments.

    I am literally speechless at how poor this is.   

    1 person likes this
  • I agree it's a complete joke that Dear haven't done anything about this - it's been an issue for years and years, there have been countless discussions over the years and Dear just seem to think "meh it doesn't matter, let's launch another expensive new feature no one asked for rather than fixing the existing flaws".

    Dear Team - SORT IT OUT!

    1 person likes this
  • Please fix this DEAR, without customers, we are just shop keepers. 

    1 person likes this
  • The fact is customers already have a unique identifier that is not the customer name. But it is buried in the URL.

    How easy would it be to present this number on the customer page / reports / exports. It isn't for the customer's benefit, it is for the company's benefit.

    This would also eliminate forcing the Name to be unique.

Login or Signup to post a comment

11 people like this idea
Log in or Sign up to post a comment