Support

November 8, 2021 at 9:30 am

Hi there,

Can you add a screenshot of the ‘Event Tickets & Datetimes’ section for that event, please?

https://eventespresso.com/wiki/troubleshooting-checklist/#screenshots

(Note you can mark your reply private so only EE staff can view it if preferred)

BTW, when this job runs, does it automatically trash the abandoned registrations?

EE doesn’t have ‘abandoned registrations’ but I’m guessing you mean registrations that have a transaction status of abandoned and the short answer is no, the above will not delete lost.

It will delete registration where the ticket submission was made but then nothing after that happened. To see this, select a Qty on a ticket, submit and then close tab or navigate away. In Event Espresso -> Registrations, under the filter links at the top of the table you’ll see ‘Incomplete’, there you’ll find the registration (and others) that you’ve just created and didn’t progress with).

November 9, 2021 at 4:07 am

Looking at that screenshot it looks like those first 4 tickets are all assigned to the Camp 2 datetime.

That DateTime has a limit of 12 and 12 are sold so the DateTime itself is sold out (Datetimes are the ‘instance’ of the event, tickets grant access to datetimes, meaning the DateTime limit is the overall limit across all tickets assigned to it).

If you could the sold values from those 4 tickets (3 + 5 + 1 + 3) you have a total of 12, which is where the 12 sold tickets on the single DateTime comes from.

Are you wanting to sell out all of the tickets you have available?

If so, set the Datetime limit to a combined total of the Qty fields from all of the tickets assigned to it (in your example that looks like 24) or remove the Datetime limit and use only the ticket limits.

November 22, 2021 at 7:50 am

No. 1) Pls refer to number 1 in picture.
Why is the number of sold = 4, but the number of Registered = 8?

Ok, so lets first define what those columns are.

‘Sold’ – The count of all registrations that apply to your sold counts, in short, that would be the registrations that have a status of ‘Approved’ for that ticket.

‘Rsrvd’ – The count of all registrations currently in ‘reserve’, this is a count of any registrations that have an active session against those tickets. Meaning the ticket has been selected and submitted to register, the session is currently active but EE has no way to know what is happening on that session. Meaning the user may be working through their registration/payment details or they may have closed the browser. Registrations remain in reserved for the duration of the ‘session’ that submitted them (by default that’s 1 hour) at which point they should then be released for sale again.

‘Regs’ – This is a count all ALL registrations linked to that ticket, not just sold registrations but every registration that submitted the ticket and got passed the ‘Attendee info’ step. It gives you an indication of how much interest there has been on any specific ticket and will very often NOT match your sold count.

So you have 4 sold tickets (the registrations for them are marked as ‘Approved’) and 8 ‘registrations’ in total (so also including the 4 sold tickets) against that ticket.

No. 2) Refer to Number 2 in picture
There are 7 reserved tickets. I have tried to “Reset Ticket and dateTime reserved counts”, but these tickets are still there, and it is affecting the number of tickets that my customers can register for. Pls help

Ok, so you have 7 reserved tickets, meaning there are 7 tickets in active sessions at this time. It is expected for those reserved tickets to alter the number of tickets customers can register onto as it’s there to prevent overselling.

To give an example, let’s say we don’t use a reservation system and you have 2 tickets left on a ticket (it can really be any number).

User A selects those 2 tickets and proceeds through to registration info. User A is a little slow getting all the details for your registration form and it takes them a few minutes to get everything together and submit.

Whilst User A is getting the details ready, User B see’s those same 2 tickets and submits the selection, then inputs their details. They are quicker than User A and get to the payment options step before they do.

User A now loads the payment options step and selects a payment method.

User B selects a payment method.

Both submit payment, who should get those tickets?

User A was first, User B was quicker and for the same argument let’s say both submitted payment at exactly the same time. Event Espresso can’t check for anything beforehand because they both submitted payment together.

It’s creating a race condition that either User A/B gets rejected right at the last second and has a bad experience, or both get accepted and the venue can’t accommodate for an additional seat, the admin now gets to contact User A/B (again, who do you chose?) and tell them they can’t attend.

With the reservation system the above doesn’t happen, User A gets time to submit the info and payment. User B can select the tickets in the first place so can’t jump in an shoehorn User A out of their selection.

—

Now, if the reserved count is not updating automatically as sessions expire that’s a different issue but from the above, I can’t tell if that is happening.

The fact that you are manually trying to clear the reserved count (clicking the ‘Reset Ticket and dateTime reserved counts’ button) suggests that those tickets are currently in an active session and nothing is ‘stuck’.

No.3) I am rather confused by the on event date times limits. I would actually like to ignore the limits set by the date times, but control the number of tickets by the absolute amount each ticket can sell. E.g. For “3A) Dec-6 to Dec-10, 8.30am – 10.30am”, I only want to sell 12 tickets in total and that is it. How do I change the settings to achieve that?

Ok, so a Datetime is an instance of the event and each instance can have its own limit.

Tickets give access to a Datetime and because you can have multiple different types of tickets on a single Datetime you can use Ticket Limits, Datetimes Limits and/or both.

In your example, you could have a Datetime limit of 12, that’s 12 sold registrations in any combination of the tickets assigned to it. You’re using 2 ticket types and both are set to a qty of 6 so you could just remove the Limit set on the datetime and update, you’ll then only use the ticket limits for each individual ticket. (Note, when I say remove the Datetime limit, set it to nothing, not 0 but an empty field)

However, looking at your setup I’d like to confirm which tickets are assigned to the datetimes.

For that Camp 3 datetime, can you click the icon and post a screenshot of what it shows, please?

Additionally, can you let me know after running “Reset Ticket and dateTime reserved counts”, what happens to those registrations, and what is their status?

Nothing, that button compares registrations with active sessions and updates the counts. It does not updates registrations themsevles.

November 23, 2021 at 5:37 am

Screenshot of Camp 3 as requested.

That’s a screenshot of the ticket settings rather than the DateTime settings 🙂

On the Datetime list click the <span class=”gear-icon dashicons dashicons-admin-generic”></span> icon for the Camp 3 DateTime, it will look a little similar to what you posted.

(1) Regarding Duration of reserved as 1 hour
Is there a way to change this default duration? 1 hour is too long to reserve a ticket so as to enter details or make payment, 15 minutes should be more than enough time. (I can ask a customer to wait 15 minutes to try again, but if I ask a customer to wait 1 hour, they will probably just buy from somewhere else.)

Yes, it’s possible to change it but I’ll prefix this with 15minutes is what we consider the bare minimum time for this. The session duration goes from the second they submit a ticket and they must complete the purchase before that time runs out or they’ll get an error and need to start over.

You can change that timeframe using a snippet like this:

https://gist.github.com/Pebblo/b6e20b03c57efe693bd86ebcf1b00ce9

You can add that to a custom functions plugin on your site, we have some documentation on creating one here:

https://eventespresso.com/wiki/create-site-specific-plugin-wordpress-site/

(2) Regarding “Registered” Status
It seems to me that this “Registered” status here is only showing who registered, but may include those that did not pay or complete the registration? Is this correct?

Without meaning to sound nit-picky here there is no ‘Registered’ status, it’s a Registered count, as in a count of ALL registrations on that ticket.

(The reason I’m pushing away from using the term status for the above is because Event Espresso has Registration Statues, Transaction Statuses (an others), adding a ‘Registered Status’ into that mix is just going to cause more confusion as its not a status)

If a person registered, but did not complete the payment, i.e. aborted the transaction. Does this contribute to the “Registered” count?

Yes, it’s a count of all registrations linked to that ticket.

From a business perspective, I am only interested in those that registered and made payment. Those who registered, but did not make payment could be dummy/fake sign-ups which will clutter the important customers and make it hard for me to serve my customers who are genuinely signed up.

From a business perspective, many EE users offer offline payment methods which they don’t want to automatically set to have a status of Approved (sold) so to manage those they need to see the regs count and an option to view all registrations.

It also allows the ability to trigger payment reminders and/or contact the users that didn’t pay (or had a problem with the registration) to continue on with the registration by sending them a link for that registration. Not all registrations that don’t instant pay will turn out to be dummy registrations so viewing those can help find additional registrants that are trying to register onto the event.

In short, there are more use cases suited to viewing all registrations (including Approved) than there are for just listing Approved registrations only so we list all regs and give you the ability to filter them down further for a specific status if needed.

On the event as a whole, you can filter registrations down further so you only see Approved registrations listed but we don’t currently have that available on a per DateTime basis.

(3) Regarding necessity of reservation

You’re most welcome.

(5) Regarding correct way to set limit for only the ticket, and NOT the datetime, is the attached screenshot the correct way?

Sure, no limit on the Datetime itself and only on the tickets.

(6) There are many confusing statuses in the system. Pls refer to attached

You’re mixing up Registrations and Transaction statuses plus some additional filters, so let’s first break down your questions:

a) When does a ticket go into the “Incomplete” and “Trash” at the top? Is “Trash the same as “Abandoned” ?

No, trash is not the same as abandoned, trash is the trash bin, its where registrations go when you deleted them and is a form of soft delete waiting for to be permanently deleted (Say you accidentally trash a registration, you can restore it back before perm delete).

The links at the top are filters, they filter the table to show registrations based on what you click, just to be clear I’m referring to these:

https://monosnap.com/file/OhFVRalFtqbAZFs8EPsz3RUST7xCO0

‘Incomplete’ lists all registrations that have a status of Incomplete.
(I’ll go into more details on what Incomplete means in your next question)

‘Trash’ list all registration that have been trashed, aka put in the Trashbin waiting to be deleted. Hover over a registration in the list table and you’ll see a link appear to trash it, that’s where registrations you trash go to.

‘Abandoned’ is a transaction status, you’re viewing the registration list, so your table is based on registration status. More on what abandoned is shortly.

and ‘Trash’ links are the top are filters, not statuses.

b) In the drop down, what is the difference between Approved, Cancelled, Declined, Incomplete, Not Approved, Pending Payment and Wait List?

Each of those are a registration statuses, they can either be manually set on a registration or EE will set them automatically based on various factors. The clue for most of those statuses is in the name so I’m not sure how much better I can explain these but I’ll try.

‘Approved’ – Registrations with a status of Approved are used for your sold counts, if a registration has been approved you can consider it ‘sold’. Registrations are automatically set to ‘Approved’ when:

1. The ticket is free and the registrant completed a registration.
2. The ticket has a price and the registrant paid in full using an online payment method through Event Espresso.
3. The ticket has a price and the admin manually applied a full payment through the admin.
4. The registrant completed a registration and the ‘Default Registration Status’ for the event has been set to ‘Approved’ (this basically tells Event Espresso that regardless of payment status all registrations are considered sold when the complete, most people want this to be the default value, which is ‘Pending Payment).
5. The admin manually set the status to Approved (you, the admin, can set any registration to any status at any time)

‘Cancelled’ – This is a cancelled registration, it no longer applies and has been removed from any group calculations for a transaction. Say you hav a group of 4 registrants purchased together and 1 drops out, you set that single registration to cancelled. You (the admin) have to manually set that status.

‘Declined’ – You (the admin) have manually rejected the registration and set the status to declined. This is often used for ‘Pre-Approval’ events, registrants must meet specific requirements to attend, they register onto the event and the admin reviews the registration and sets the status as needed (this is often used with the ‘Not Approved’ status explained below).

‘Incomplete’ – An incomplete registration is one where there is no registrant info attached to it, meaning the user selected a ticket and stopped at the attendee info screen and they may or may not be still processing the registration current. Those registrations are listed when you click on the ‘Incomplete’ filter link at the top of the table (explained above).

‘Not Approved’ – A Not Approved registration status is often used for Pre-Approval events, same as explained above but you set this as the Default Registration Status on the event so that registration stop after the attendee info step (no payment options are shown) and you (the admin) must review and set the registration status to something else (usually Approved or Pending payment) for them to continue.

‘Pending Payment’ – This is a registration that is awaiting payment to move to ‘Approved’, this is the default status used by Event Espresso. All registrations are assigned to a transaction (which is used to handle all payment related to its registration(s)) so these registrations have a transaction that has a status of incomplete (amount paid is less than amount owed). If the transaction is updated and becomes complete (amount paid equals amount owed) the registration will automatically be switched to ‘Approved’ (aka Sold).

‘Wait List’ – waitlist registration to go with the waitlist add-on:

https://eventespresso.com/wiki/wait-list-manager/

Are these the same as “Incomplete”, “Abandoned”, “Trash”? Or they mean a different thing?

Sort of, the Incomplete filter links list Incomplete registrations and I’ve explained trash.

Abandoned is a transaction status. We can move on to discuss transitions one you understand all of the above.

(c) Going back to the discussion above about “Registered”, which of these ticket status here will be “Registered” ?

With the exception of Incomplete registrations, all of them.

(d) Going back to the discussion above about “Reserved”, which of these ticket status here will be “Reserved” ?

The reserve count doesn’t really tie into the registration statuses that way, it’s based on a current session, not a status.

So all and none of them at the same time.