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
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:)
https://inventory.dearsystems.com/Customer#e4d26737-fc52-442e-9709-3f06fa3d2194
When sending emails or documents these attributes can be referenced. Page 18 of this doc shows the available mailmerge fields:
http://dearsystems.com/inventory-software/wp-content/uploads/2014/10/MailMergeFields.pdf
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.
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
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
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
@Michael Davis I'm not suggesting you don't try to improve DEAR by logging requests for improvements. I'm just trying to show that it's often impossible to implement existing workflows with new software and sometimes there are functional work-arounds which you can use rather than waiting for the software to be built.
I'd love to see your (1) and (2) suggestions implemented. Why don't you start a new Feature Request for each of these and see if other DEAR users agree?
For (3) you can search a Sales by Product Details Report for a single SKU giving sales info on just that one product.
1 person likes 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
@Michael Davis I don't think it's always fair to want a system to conform to your particular workflow. Generally the idea behind a unique identifier like an account number is that it never changes.
Using DEAR, for example, you could assign one Additional Attribute field for a unique ID. Another Additional Attribute field could be assigned as a drop-down for your various account classes.
DEAR's in-built functionality allows you to edit a customers credit terms from the customer dashboard.
If you have 4000 customers it would be pretty simple and error-free to use a spreadsheet to update their details rather than do it manually.
2 people like this
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)