Deferred Customer account numbers
It would be nice to be able to add a customer account number when creating a new customer as well as just their name. Xero has an option to assign account numbers to customers which is handy when sending out statements as customers can use their account number as a reference when making payment. Right now I have to add account numbers manually in xero once the customer has been created in DEAR.
There is a unique identifier. The customer name must be unique (but it is not case sensitive). Customer codes are a legacy from days of very expensive storage. They are not very friendly, generally speaking ,and in practice I don't have a single client who is missing them (technical users are perfectly happy with the guid provided by the API) which suggests there are good workarounds. When I first started with migrations I suggested appending the customer code of the old system to the customer name e.g. in []s, so searchable, but no one was ever interested.
Xero, by the way, treats contact names in the same way as Dear. Xero did eventually add an account code field (optional). I should survey my users to see how many use it ... not many, I think.
The generalised feature request would be for additional attributes to be optionally mandatory and optionally unique. I would like this, particularly being able to make a field mandatory, and I think I already requested this (Unleashed now has 'required' extra fields, but only for products and they are not yet integrated into reporting: Dear is still miles ahead.)
As for payment references, it would be much better for customers to reference an invoice number when making payments, rather than an account code, which wouldn't tell you which invoice is being paid, a funny point when you consider this is a topic about unique identifiers.
4 people like this
4 people like this
This would also be helpful when using your integrated POS and setting up a loyalty program. I could offer a loyalty card to customers with a unique barcode or number sequence that represents that customers account number.
3 people like this
@Tristan Thomas, I agree about solving problems for the market rather than custom specific requests.
However, the heart of the issue here, is that DEAR does not create or use a unique identifier for Customers. Using customer name as the uniqueness constraint prevents it from syncing properly with QBO.
While using Additional Attributes as you outlined above is interesting, there is no way to enforce a uniqueness constraint in an Additional Attribute.
3 people like this
Using the Customer Name as a unique identifier is frustrating from a data migration perspective. Would be nice to generate a unique account number of 8-12 characters for each customer (similar to Vend POS for example eg. John-39CM)
eg. we've got 5000 customer records to import into DEAR (converting from an older CRM system). I've got two retail customers called "John Smith" who have different addresses and contact details.
However, when importing into DEAR - I've got to make their names different so they import as separate customers. And really, "John Smith 1" and "John Smith 2" just looks unprofessional in the system. Thought about using middle initial, but there is still the possibility that that will be the same.
3 people like this
2 people like this
I have implemented half a dozen systems both SaaS and server based and have yet to see one, apart from Dear, that doesn't have a searchable vendor/customer code that is unique for every entry.
While your work-around is fine for a small number of customers it is still time-consuming and not really workable for a large customer database.
2 people like this
i have also asked for this feature. an additional field that can be searched for where we can have a unique number for assiging to that account.
i have had customers ask what is their account number so that they can include it in EFT payments so that their payment is allocated to their account correctly.
so far we have not had an issue but with well over 1000 active accounts, we expect sooner or later a payment received might be allocated to the wrong account without this simple data.
further more, when i pay all our suppliers, i put in the account number that is on their statement, it helps temp staff allocate payments correctly.
also, lots of our customers still come in and say their old account number because it's quicker for me to put in an account code that search through all the businesses, whose name starts with the town we are opperating in.
in Retail manager that we came from, we used to have letters like "RSSW" as an account code for customers with an account and numbers like "180" for COD customers.
2 people like this
It's interesting to hear you say that customers prefer to work with their account number. It's difficult to understand how this is more convenient than actually providing the name of their business. Some of your problems are hard to grasp when there seem such obvious alternatives.
For example, for finding customers quickly, it doesn't really matter that you have many business with names starting with Adelaide, because you don't have to match customer names from the start ("carpet" would find Adelaide Carpet Cleaners). Business names do change (rarely), but you can change names in Dear. In practice a business which does change its name seems unlikely to use the old name; usually the struggle is to get business partners to use the new name.
There is some reference in this thread to QBO syncing not working reliably, which is attributed to the missing account code. I do API work, and I can't see how you could improve on the GUID already provided (which is the industry-standard approach). If the QBO integration has sync problems, it is not due to a missing unique identifier.
I point these things out to perhaps give you some understanding of why I guess Dear is prioritising other improvements, although it wouldn't hurt to have a new field. As you say, Xero has done it, although i do not observe it widely used among my clients. Actually, I can't think of anyone using it. Those who moved from legacy systems relying on account codes show no desire to go back to the good old days as far as this feature goes.
2 people like this
HI Steve, your speculation is wrong, which I hope makes you feel a bit better about the world . Of course Dear uses unique identifiers, they are GUIDs and are exposed everywhere in the API. Every integration uses them, not just for customers, but for everything. See the API docs. GUIDs are very cool, they are account numbers on steroids, but they are very big. They solve a lot of problems for programmers, but they are not remotely human friendly.
Robert Thomson's post is a good one. The current situation causes problems in the B2C world. But this problem is quite hard to solve. Account numbers don't help very much. For sure, customer names should not have uniqueness forced upon them, but then what? I don't want my B2C customers to have to remember their Dear account number, it's of no value to them.
1 person likes this
Steve - the GUID (dear calls it the Customer ID) is covered in a few other posts so it might be worth re-reading this thread from the start.
This identifier is the characters after the # in the Customers URL (in bold below) and can be found by visiting the Customer (Sale > View All Customers then select a customer) and looking at the URL.
ie: https://inventory.dearsystems.com/Customer#e4d26737-fc52-442e-9709-3f06fa3d2194
The way these are generated means you could use the first or last blocks and still be extremely confident you'll never have a duplicate. In the above example e4d26737 or 3f06fa3d2194 are both essentially unique.
The Customer ID is not available through any of the Mail Merge fields but it would be pretty easy to assign the same GUID as an Additional Attribute, or I'm sure it would be fairly easy for DEAR to add the ability to reference the Customer ID through the Mail Merge.
Another option if you're wedded to the idea of having the Customer Name as unique if for you to use that as your customer ID and type your manually created account number when you create the customer. Then use the "Contact" aspect of the customer to add their real name.
1 person likes this
ecommerce orders place in Woo with unique customer record
imported into DEAR, where customer record is combined into existing record with same name
passed to XERO where invoice is raises and emailed to the original default contact.
Woo deals with the customer record correctly - Xero deals with the information passed from Dear correctly.
Dear incorrectly combines customer record as it is not qualifying the customer recorde correctly.
Hope this helps...
1 person likes this
Tristan -
You ask: "Out of curiosity how would having another unique account number have negated this error?"
That is the crux of the problem. A unique account number is NOT currently available. The account number is currently based on the customer name. Having a "John Smith" in Houston, TX is considered as the same customer as a "John Smith" in Chicago, IL - when they are obviously not the same.
1 person likes this
Hi Tristan -
I appreciate that you are trying to take the time to understand our problem. Unfortunately, the Dear generated number is not really usable in under most circumstances.
Regarding the Customer Name field, you are technically correct that it is specified as a unique constraint and does not allow for duplicates just like you state. However just because a field in the database is constrained as being unique, it does not meant that it uniquely identifies the data that it is supposed to represent. If you add a unique constraint on the zip code field you would guarantee that only unique zip codes are entered, but it's obvious that there will be multiple address that need to be represented by that zip code - hence the zip code field is a bad choice as a unique constraint.
As an example, let’s use you: Tristan Thomas
1) You place an order on Shopify for a large screen TV.
2) Dear Systems downloads the order
a) a Tristan Thomas customer is created (located lets say in New Zealand).
3) Tristan Thomas (the basketball player from upstate SC) places an order on Shopify for 5 pairs of shorts
4) Dear Systems downloads the order
a) the Tristan Thomas customer is found based on the Full Name match
i) the account is updated to show the new purchase.
5) Now you call us and ask us what your last purchase was, because you want to duplicate it
a) we will gladly tell you that you ordered 5 pairs of shorts.
b) you tell us that you never ordered shorts
i) now we need to figure out what happened and take time to correct the integrity of our data.
c) I finally find that it was a large screen TV that you ordered (it's not easy in Dear to see what was shipped to New Zeeland)
d) I ask you to place all future orders as “Tristan Thomas – NZ” or “Tristan Thomas #1
i) You basically LYAO at us.
How would you suggest that I handle the above scenario - it's happens in our line of business (especially with company names)?
Really, there are two issues at play here:
1) Not being able to have two Tristan Thomas accounts - that could be differentiated by a customer account code
and
2) The Shopify account matching logic - it would need to match on more than just full name and create an account if a strong match was not identified - e.g. email, phone, or address
(the accounts could be combined later if they were as being the same customer).
The issue shown in the above example is really keeping me from moving forward with fully implementing this system – even though I’ve been paying for it during the last few months.
Thanks for your time.
Bob
1 person likes this
Completely agree Account numbers are needed. Every system I have ever used has account numbers.
1 person likes this