LOL, It say Name has to be only name.
What about SambaPOS is Restaurant POS? Why would you use for something else?
I agree primary field call Name kind of weird, unfit. Yes it should be UID.
SambaPOS works so well it is very adaptable for many different environments and this particular issue doesn’t exist because I am using it outside of a restaurant.
Food or not, my point on the unusual nature of the Primary Key remains true (as is only confirmed by the fact you weren’t able to identify any other system that works in the same way.
Yes, being called name is unfit, but requiring it at all is strange when it is not really the key that it used in the database (see my screenshot earlier i this thread).
All of your examples require a unique email or username?.. :-p
You don’t have to manually create a primary field (key) out can automate.
As for needing a quick account for customer in front of you, maybe take a look at my temp tabs tutorial rather than using entries/accounts…
Why would you give an account/credit to someone without taking some form of additional info beyond name??? If they are renting equipment or having a credit account surely you want something other than just name.
When you have two accounts for John Smith how you’ll know which John Smith owes $50? Maybe you keep it in memory but what will prevent random operator from unintentionally clicking New and creating a third account for John Smith? Is it for first John, second one? Maybe we have third John Smith? How you’ll know that?
Opening new account for a customer that already have an active balance is a serious issue that may lead to loss of money. Will people accept that just because it allowed in Facebook? I can’t understand how it relates.
1 Like
Facebook still needs a unique email address for each account. How is that any different to a telephone number?
One of my recurring points in this entire thread is about asking information from customers which is unnecessary. If we don’t need their email or phone then it seems a little strange to ask for it.
It makes sense for an email address to be required by facebook - But you can be sure that it is not what is used as a primary key.
We offer credit to people we hardly know because typically these people are leaving $1000’s of their own dive equipment in the shop overnight between dive days.
The credit only lasts for the few days they are diving with us and we are a small team so we will be aware of the people who are currently with us and owe us money (with the help of the custom report I am trying to write here)
I would like to have customer accounts for people so I can offer credit and track sales per customer. I typically will have more info than just the name, but I don’t want to be restrictive and always require one oarticular piece of information that might not be suitable for another (for example customers who book via email before arrival, we will have their email address. Whereas customers who come through an agency, we will know the dive shop they come from - These small pieces of info are enough to identify the customer without turning in to “big brother”).
For example, this is what we might have for a few customer records. As you can see, there is flexibility to enter what is suitable for the particular customer.
My point throughout all of this is that it’s an unusual requirement that doesn’t exist in many other software products. The example of customer records below is perfectly reasonable for a business to adopt and there is no technical reason why it couldn’t be implemented (since the thing to make these customers unique in the system would be a hidden unique ID). My issue is requiring the operator to create the unique ID themselves - It’s highly unusual.
Name: John Smith
Phone: 123-456-7890
Country: USA
Location:
Email: john@notreal.com
Agency:
Dive shop:
Notes:
Name: John Smith
Phone:
Country: Belgium
Location:
Email:
Agency:
Dive shop:
Notes: Marine biologist with Brussels uni
Name: John Smith
Phone:
Country:
Location:
Email:
Agency: A1 Scuba (Denver, CO)
Dive shop: SuperDivers, Denver, CO
Notes:
In the food business expecially when dealing with accounts, we need accurate speed and having 40 John Smiths pop up when trying to settle an account is simply not going to work.
Anyway your point is understood but it’s unlikely to change. What we need is to help you find an acceptable way to handle your unconventional use of Sambapos.
1 Like
It’s highly unlikely you would have that many, but if you genuinely did have 40 customers called John Smith who would benefit your business by working with them on an account basis are you seriously saying you would turn 39 of them away due to difficulties with your POS system???
I think you are missing the point. Your thinking in broad terms we are thinking specifically food restaurant business.
To answer your question I would force the users of my restaurant POS to set a unique key they wish to use that prevents exact duplicates. This means they would not be turning away anyone.
BTW most POS systems choose the unique key for you and you are forced to only use that, sambapos gives some flexibility here. Most restaurant POS does not use the actual DB unique key like your saying.
1 Like
No - It’s the exact opposite of that.
Currently, when you create an entity an ID is generated in the Database - I am saying this automatically created ID should be used as the unique customer identifier (This is how all other software products).
Right now, the ID that is created in the DB goes larger unused, instead, the operator is currently asked to provide a unique customer identifier (commonly the name, phone or email) - But This really isn’t a requirement because the unique identifier is already created behind the scenes.
What I would like is the flexibility to sometimes provide a phone number, sometimes an address or sometimes an email address.
Most POS systems I have used and experienced chose the unique ID used for Customer/Account setups and you were forced to use that scheme. You keep saying other software… that can mean anything and to be fair we need to compare to other Restaurant POS systems not all software that uses a database.
We can argue all day but its unlikely to change… instead lets focus our energy on helping you get something your satisfied with that works for you.
Fair enough - I must admit I haven’t looked in depth at other POS’s
To be honest, none if this is a major problem, I will just continue to use the customer name as the unique identifier and when we have one that already exists we’ll use things like:
John Smith
John Smith (Denver)
John Smith (UK)
It isn’t really a big problem, it’s not best practice from a database perspective and it threw me a little when building custom reports because it felt so strange looking up a ticket based on a field such as name, but it’s my issue and not something that needs changing.
You’re right, I should just focus on building the system that will work for what we need it for, rather than trying to tweak the entire POS.
1 Like
Just setup automation to automatically set a customer ID and use that as the primarry field… Problem solved.
The power of samba is we can create our own solutions…
The core of the software would not be changed on a single request but we have the capability to make it work for your senario in a way like what you describe…
1 Like
I totally agree @emre
Well, we do always ask if they are a repeat customer (because we offer discounts to repeat customers).
But the same situation you’ve described above would happen with Samba setup in the way it is now if John changed his telephone number or email address, so the suggestions around relying on phone or email wouldn’t actually solve the problem either.
Besides, when creating a new customer the operator would type in the name and while doing so would see if the same name already exists and use their own logic to work out if it’s a repeat. For example:
Example 1 - This is a new customer
A guy with an English accent walks in and says it’s his first time ever to experience diving (or eating a particular type of food that a restaurant specialises in - to keep this food friendly). His name is “John Smith” but there is already a John Smith with 20 previous tickets and an address in the USA… Probably this customer is not the same as the one already in the system - but it still might be worth checking by asking a simple question.
Example 2 - This is an existing customer
A guy walks in and says name is Nathaniel Higginbottomsworth and his email address is nate@gmail.com. It’s quite an unusual name, so when the operator sees we already have a Nathaniel Higginbottomsworth in the system, but the email address is nate@hotmail.com - common sense will tell them to ask the customer if perhaps they have changed their email address.
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)
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.