Customer account numbers

started a topic over 8 years ago

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.

52 people like this idea
  • Account Code is a standard feature in accounting systems and usually serves as a unique identifier for things like integrations to other systems. More importantly, customers usually use it in the payment's important and really can't be difficult to add, even if it is initially only to pull from Xero.

    1 person likes this
  • 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
  • You obviously don’t understand. Yes there are work around but these by nature are a solution to a problem. I’ll give you some examples. 1. I live in Adelaide, do you know how many businesses names start with “Adelaide”? 2. Business names change from time to time, a customer number would no have to. Sometimes we have to try multiple names to see what it’s under in our system 3. Some businesses trade with multiple entity names, same issue as above. 4. Sales screens do not allow for finding a customer by sir name or first name. 5. Some business offer a small key ring size credit card that contains customer no or barcode to load customer. How can we do this with Dear? Currently we have to open up the “customers” page to search by phone number or contact name to find the right customer name, then return to a sale to begin the sales process.
  • Did I mention that we currently receive at least 3 payments per month that we can’t allocate because the reference is to vague to select a customer. When we had customer numbers, they would be the reference number, so it was easily recognized as a customer number and applied accordingly. Also, heaps of our customers still come in and give us their account number from the old software. Also, is this is an obsolete requirement, why do businesses like xero offer it? It’s still standard practice in big businesses/software everywhere. Why are we being treated as a nuisance for asking for a neccissary feature because you have not understood its benefit? Further more, Tristan Thomas wants me to start a new request for each of 4 suggestions I made. Why can Dear staff instigate these improvement rather than create extra work for Dear users? Who’s serving who here? I’ve had the same issue with tech staff from Dear Support where they agree there is a valid issue that should be addressed and they instruct me to start a new request. I’m over it. Good luck. If my customers suggest an improvement to me on the phone or counter or email, I don’t send them away and ask them to start again on a website forum, that would be bad customer service.

    1 person likes this
  • Hi Michael - have you tried using the Additional Attributes for Customers and storing your account number in there?

    You could easily import / map your old customer numbers into an Additional Attribute field.  For new accounts you'd need to manually create an account number - however DEAR does automagically make a 32 character unique ID for the customer.  That's probably a little long for what you want but taking the first or last, say, 4 or 5 characters would be almost certainly unique with a database of less than 10,000 customers.  This unique ID can be seen when you visit a Customer in DEAR as everything after the # (in bold here:)

    When sending emails or documents these attributes can be referenced.  Page 18 of this doc shows the available mailmerge fields:

    I know it's not exactly what you are asking for but it's currently functional in DEAR and would be reasonably quick for you to implement and start using.

  • The above ideas are time consuming and are a bit of a joke to be honest. I guess we just sit tight until you listen to our requirements.

    1 person likes this
  • There's a workaround you possibly may not have considered. You can add codes to the customer name. eg Adelaide Carpet Cleaners becomes Adelaide Carpet Cleaners [00123] which solves the searching at least, and your question about old customer codes. It's a bit ugly. You can also work around that problem by using a custom attribute, which is what customers usually request if they are concerned about legacy codes. 
    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
  • 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
  • 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 

  • 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.

  • 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.

  • 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
  • This is a great idea. Ideally we should be able to query Customers API with this parameter

  • 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.

  • "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?  

Login or Signup to post a comment

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