No, a dive shop. On my other posts I have always acknowledged that I am in a non-food industry, but I don’t think this is particularly a food / non-food debate. If I was running a restaurant and someone walks in every day and I want to make an account for them, there is no real need for me to store their phone number. I just need a customer account for the person in front of me.
The only reason I mention CMS and CRM systems is that these are examples of typical systems can contain similar data “Customers”. Those systems use a standard database structure that I have described above and work very well.
I think my main gripe is that SamaPOS requires the operator to create a unique primary key which is a very database/techy thing which means little to the operator. In comparison, other systems typically ask for a piece of user data and it can be entered by the operator without having to over-think or enter information that is not actually required for the business.
If customer walkin, I use Entity Tables name Take Out 1, 2… I don’t ask for any personal info.
If customer phone, I use Entity Customers with Phone number. You need phone if customers are not in front of you in case any issue may arise.
You don’t need any customer info why you need customer account and He is John 1 or John 100. Or you can just use Fast food mode (Tikcet Create instead of Entity Select)
That is my point. His name is John, not John100, so why require the operator to add an arbitrary number?
My point in all of this, is that it is an unusual way to use a database which already has a unique identifier int he DB structure.
Plus, if you have the same guy walk in each day, it might be handy to set-up a customer account for him, rather than using tables, then he can just pay at convenient times. But, if he walks in every day there is no reason to take his phone number - The fact that phone number is being asked for just to satisfy a requirement of the system would tell any systems analyst the the system is not representing the needs of the customer workflow.
Assuming you have a Facebook account you weren’t restricted when you entered your name (they didn’t tell you that someone already has the same name). Instead, they use a DB structure that generates a unique ID for you account, rather than creating based on the data you are actually providing.
Yes, that is my point. If you have a field called “Name” you should expect to only enter the name in that field. You should not have to alter the name to suit the system (the system should work)
If in your business nothing more than a name is required for certain customers, then that should be supported by the system. On Facebook you can tell them just your name and DOB (probably not globally unique) but that is all you need to provide. The customer ID is a unique value that is not exposed to the user or never asked for by the user. Instead, the front-end is programmed around that ID.
The reason I ask is because that is how the business currently runs. It is a useful practice for the business and the best computer systems integrate well with the way in which the business already runs, rather than forcing a change in business processes just to satisfy an unnecessary requirement of the software.
Let me reiterate, I really appreciate how great SambaPOS is, and this may be something that can be easily worked around by getting the operator to enter any random data as the Primary Key… But this is far from best practice when it comes to a computer system based on a relational database. The SambaPOS way of handling a primary key is not implemented by:
Google
Facebook
Yahoo
Microsoft
Apple
WordPress
DotNetNuke
SugarCRM
Salesforce
Github
Sourceforge
Many more…
And these are pretty well respected developers and software products, so I do find it strange that my views are so surprising. Am I missing something? Do you know of many other software products that work in the SambaPOS way?
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.
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.
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.
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.
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…
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.
