List tickets by entity ID [Custom reports]

So you can depend on operator’s common sense. That is great but if we add that option we’ll add that for all SambaPOS users. Someone else may also think there are a lot of John Smith’s and allowing that is a good idea. But his operator is a new guy and he mistakenly created duplicate accounts.

How can we resolve that?

1 Like

But at the moment, you can’t add a second John Smith account at all (even if we really do have a 2nd John Smith)

I know my English fails… I mean “if we optionally allow that”.

No - I understood what you mean. But at the moment if you use the customer name as the Primary Key you can’t have two customers who really do have the same name. Also, if you decide to use phone or email as the primary key, then if a customer changes those details and walks in to speak to an operator who doesn’t recognise them, then they will end up with a duplicate account (which is your concern about what I am saying anyway).

Honestly, I have wasted enough of your time on this. I am sorry to have hijacked this thread, I should have kept my mouth shut! Sorry!

As @Jesse said, although this is an unusual approach compared to most database driven software, this is apparently pretty normal in the restaurant POS environment.

At the moment, you cannot add a duplicate Entity using the default Entity Search screen with the default mechanisms in place.

However, if you build your own Entity Search screen that contains background Automation for listing and creating new Customers, you could easily auto-generate a Customer ID and assign that to the Primary Field, having configured that field in the Entity Type. This can be completely invisible to the operator, and they can search and list, then either select a Customer based on prior details, or create duplicate Customer Names as they want.

This is what @JTRTech is talking about, so rather than beating a dead horse that is not going to change (for reasons already explained), we should talk about how to create that system. We have the tools to do it now, and it is not that complex to set up. I think many would actually use a system like that.

I’m honestly not. My last few posts, I have acknowledged, if it works for people that’s great, and I can train my staff around any issues that might come up.

It’s a minor issue that I thought it wouldn’t hurt to float. I didn’t mean to take up so much of everyone’s time.

I’m sorry.

Why not of retail/restaurant use Name and Phone number even tho they may have member ID.
Most of vendor ask for phone number because it is easier for customer to tell their phone number and phone number is unique they don’t even have to ask their name (I mean only have to ask name once) and name is hard if you mis-spell it you cant find it especially in country that have foreign name to spell in your own language. Most important thing key in number (or callerid) is fastest to get into the right account then what is your name (if you are spell it right) then where your from or email

The way you want you ask the name and have to ask one or more info to identify account. I don’t see any good with your idea. Sorry!