List tickets by entity ID [Custom reports]

[mjb2000]

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.

@JTRTech

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.

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.

@emre

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?

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: