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.
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
Robert - I'm not being argumentative and I'm genuinely trying to help. There are already TWO unique identifiers.
1) DEAR generates a unique identifier for each Customer or Supplier. 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
This unique identifier is not manually setable or changeable and is too long to use as a reference on bank payments, however since it's randomly generated you could use, say, the first 8 characters with an extremely low chance of two of your customers having the same first 8 characters.
This unique identifier is NOT currently available through the available mailmerge fields, although I'm sure this would be a reasonably easy thing for DEAR to add.
You can access this via the API as well:
2) The Customer Name field. A few of the complaints here are that you cannot have two identical names - well that makes it a unique identifier. Could use the Customer Name field as your account identifier and then use Additional Attributes to store and display their non-unique company name, city, etc? The Additional Attributes are easy to access from the Mail Merge for using on invoice templates.
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
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
Having an account number would have ensured that customer details were not combined under the same first name...
"We’ve now send out invoices (legal documents) to the wrong people, this is just totally unacceptable."
Out of curiosity how would having another unique account number have negated this error?
On reading your reply this is “not by design” it is a total incompetent software development and in my opinion whoever scoped out the integration it should be questioned if they have the right skills to undertake this level of work.
You cannot base an index between two software solutions on a field that has potential of been duplicated and should where possible be based on at least two fields that would reference in this case a specific contact. An ideal combination would be company name, surname & email address, it is more appropriate to have more records of a client (That could be merged as a combined operation) than to have unknown complications in merging unrelated parties especially when information is ported to an accounting solution such as Xero. How can you allow records between unknown parties to be merged? We’ve now send out invoices (legal documents) to the wrong people, this is just totally unacceptable.
If this is the level of coding undertaken by Dear Systems you have to question the integrity.
So in conclusion: - To suggest this should be “voted on” is a joke, it’s a bug and it has a big impact right through your system onto accounting etc. Somebody within you organisation with some authority needs to grab hold of this issue and deal with it.
This is a great idea. Ideally we should be able to query Customers API with this parameter
Why not implement this DEAR? Seems like a no brainer. It is just a field and an important one for many businesses.
1 person likes this
One more question... If I have John Smith account and they have a credit hold on their account because they owe a bit of money - will any incoming purchases from a John Smith on Shopify merge into that same account even though they are totally different customers? Possibly triggering a hold on the order until pass due balances are resolved?
I understand the concept of wanting to use a "natural key", but that key should have a high level of uniqueness which it doesn't have when just using the Customer Name. By the same logic, why have invoice numbers - similarly you could use the Customer Name and Order Date.
Chirstine Lee -
I think you've nailed the crux of my problem. We have customers who have identical names, and we will need to resort to having a John Smith 1 and a John Smith 2 etc. We've also had XYZ Co get sold and become a stand alone branch under ABC Co that wants to use the ABC Co name only e.g. not ABC Co - 1 or ABC Co - Atlanta. It just makes it hard to maintain these separate accounts when the account key is the name only. Clearly, at least to me, John Smith (from Houston) is not the same as the John Smith (from Chicago).
How do other people handle this so it doesn't look so clunky to their customers?
I'm really struggling with this at the moment trying to get things setup because they are clearly two separate accounts that want to merge into one.
If additional attributes is the way to go (which is effectively how Xero handles Account IDs) it would be really great if they were visible/usable in DEAR POS. As a retailer with Customer Loyalty Cards it would simplify our processes immensely
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
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