Unique Customer Names
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?
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.
Completely agree. In this day and age this is potentially a massive data protection issue.
This really does seem like an arbitrary limitation put in without proper thought.
We're currently building an eCommerce platform for a few customers who are currently using DEAR. We're now advising them to ditch DEAR and go with something else, mainly due to this limitation making integration too difficult (plus the fact that DEAR keep adding new UI features without adding API support).
Also worth noting that their own eCommerce connectors (WooCommerce etc.) handle customer names internally, and I'm fairly not sure they do not even have the 'unique' name requirement.
We're currently using Shopify and Dear and finding this to be an issue. Seems as though Dear isn't ideally set-up to manage retail customers.
This has been a problem since the year dot. There is another thread here from 2015: https://support.dearsystems.com/support/discussions/topics/1000063446/page/last
Basically they don't care and they are not going to fix it.
Best solution: migrate to a different system.
It's a shame if that's the only realistic solution at this point. We signed up to Dear with the understanding that they had a full integration with Shopify. However, it seems like there are a few critical areas where this is not the case.