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.
1 person likes this
1 person likes this
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
Thanks @David Wawicki.
I appreciate hearing that. I'm not asking for anything "special" or custom.
I thought it was a basic need.
the idea of managing it on an excel spreadsheet is just as bad as using additional attributes.
why have two systems that talk and share information and then use a separate excel spreadsheet? too many pieces in the system, considering this is a basic expectation within the industry.
Xero can handle an account being both a supplier and a customer which i think is great, but unnecessary for Dear.
It does seem to create some duplication issues between the two programs though when we try to sync.
I think unique identifiers could resolve this.
1 person likes this
1 person likes this
1 person likes this
This is a great idea. Ideally we should be able to query Customers API with this parameter
The CSV update issue is frustrating. I would expect to see just the Dear Customer ID in the first column though. So that the importer can check the ID to see if we have changed the name of the customer. Changing customer names in bulk can be really helpful. Much like updating products and syncing by SKU.
I'm really wondering how the most popular feature request, very simple to fix and created on this forum 7 years ago can still be completely ignored by Dear.
Can someone from the team reply?
Hi Tim. How do you 'get' the GUID without the API which is not given away for free? (Hence my skeptical world view.)
My guess is that we are all at different stages on our journey of becoming programmers... In the mean time, pragmatically, a visible account number would solve the issue for a lot of us.
You say the customer shouldn't have to remember their account number. I say it isn't necessarily for their benefit, but rather for internal administration of information that DEAR is not built do cater for.
Another argument for you. How much cleaner would it be if there was an option for DEAR and XERO to sync by an account number? Instead we have to diligently ensure the the Company names match in both systems. Or hope the fuzzy AI does a reasonable job.
I guess if we really desperately want to use Account number we can (as someone has previously noted). We'll just have to put up with using an additional attribute buried on the page for now.
YES! Additional Attribute are searched in both the Sale list and the Customer list through the DEAR front-end.
You CANNOT search for Additional Attributes through the API for either Sales or Customers (at this time; May 2017)
The fact that Dear uses the Customer Name as a unique identifier is a joke.
Even if you don't want to implement account numbers (noting that this feature request is marked as deferred), at very minimal it should use email address or phone number as the unique identifier in which to avoid duplicates.
In addition to our B2B customers, we have multiple B2C ecommerce shops connected to Dear, all of which are syncing customers to Dear, so the chances of duplicate customer names (e.g. John Smith!) are relatively high!
We've just had the exact situation happen whereby 2 completely separate customers with the same name have been merged into the same Customer by Dear....
Please guys, let's get this sorted.
Well I kept having my post rejected, so I will try to remove the concern the forum gatekeeper was possibly having with it.
Regarding having a separate unique CustomerID field and the shopify concerns here's one way to do it:
Accounts:
CustomerID: 1000,
Name: John Smith, Address: 123 Main St Unit 1, City: Houston, St: TX
Email: js@xyz.com, Phone: 811-555-1212
CustomerID: 5555,
Name: John Smith, Address: 500 Michigan Ave, City: Chicago, St: IL
Email: jonathan.smith@xyz.com, Phone: 313-222-5555
NOTE: Two John Smith accounts are allowed because the CustomerID field has the unique constraint.
Another order comes in from shopify: (using the mangled address example)
Order info:
Name: John Smith, Address: Unit 1, 123 Main St, City: Houston, St: TX
email: js@xyz.com, Phone: 111-111-2222
Check the "strong" indicators of the order first for a match.
"strong" match indicators would be: email, phone, Name/Address (including city, state, and zip)
This order matches on email -> the order is added to CustomerID 1000.
Now if the email wasn't provided, we no longer have an email, phone, or address match.
A new account is created:
CustomerID: 8787,
Name: John Smith, Address: Unit 1, 123 Main St, City: Houston, St: TX
Email: none Phone: 111-111-2222
Now later when our customer service rep searches on John Smith, all three accounts come up (1000, 5555, 8787) and hopefully our customer service rep can verify with the customer, assuming he/she is on the phone, that account 8787 is the same as account 1000 - e.g. maybe the cell phone was provide instead of the main number. Now our customer service person can merge the two accounts. If they are not the same person then there is no harm done, because all the accounts are separated appropriately.
I know this is a simplistic example, but hopefully it illustrates the reason why a non unique Name field and a unique CustomerID field would solve many issues.
This would also allow our customers to refer to their customer id (original request in thread). e.g This is John Smith, can you tell me if I have an account balance? My customer id is: 1000; no confusion, very simple and elegant.
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.