Posted: November 7, 2021 at 8:40 pm
Hi, need help
this is my website http://www.computhink.com.sg, and sometimes tickets are shown as sold out when there are still slots >> https://www.computhink.com.sg/classes/2021-yearend-minecraft/ >> for the 1st 4 slots its full
I have checked a few things as per the forum
BTW, when this job runs, does it automatically trash the abandoned registrations?
Not sure what else to do, can you help?
Can you add a screenshot of the ‘Event Tickets & Datetimes’ section for that event, please?
(Note you can mark your reply private so only EE staff can view it if preferred)
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).
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.
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.
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’.
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
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?
Nothing, that button compares registrations with active sessions and updates the counts. It does not updates registrations themsevles.
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.
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:
You can add that to a custom functions plugin on your site, we have some documentation on creating one here:
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)
Yes, it’s a count of all registrations linked to that ticket.
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.
You’re most welcome.
Sure, no limit on the Datetime itself and only on the tickets.
You’re mixing up Registrations and Transaction statuses plus some additional filters, so let’s first break down your questions:
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:
‘Incomplete’ lists all registrations that have a status of Incomplete.
‘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.
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.
‘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:
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.
With the exception of Incomplete registrations, all of them.
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.