Support

August 15, 2024 at 4:56 pm

What is the Default Registration Status of the event? did you set it to Approved? pending? or not approved.
https://monosnap.com/file/CHzMMlUXzU0dd0xXIpxwBgsSQrdFtx

Registrations that have the Pending Payment status do not count toward the total ticket sales.

While approve will set be counted whether they pay or not.

Can this lead to a mismatch or error in ticket tracking
no, the number of sold ticket was not included during the duplication of events/tickets.

thanks

August 16, 2024 at 6:32 am

Hi There,

2. Thank you for reporting that. I’ve added a note regarding that for our developers to check.

3. Can you please share a screenshot of the issue you are facing?

4. Discount products might not be the issue as they are still recorded as a sold ticket.

However, you can perform a troubleshooting to see if you have any errors or conflicts:
https://eventespresso.com/wiki/troubleshooting-checklist/

August 16, 2024 at 7:12 am

Sure, please let us know if any other help is needed.

Regarding the Mollie, the plugin is already updated with a fix. You can download the V 1.1.6 from your account page.

August 19, 2024 at 6:02 am

Hi there,

Which payment method are you using for these registrations? (I’m assuming Mollie but want to double-check).

AHEE__EE_Transaction_Processor__update_transaction_and_registrations_after_checkout_or_payment
AHEE__EE_Soft_Delete_Base_Class__delete_or_restore__after

Those 2 hooks, whatever is running on those has the potential to cause the issues mentioned. I’d lean more towards AHEE__EE_Transaction_Processor__update_transaction_and_registrations_after_checkout_or_payment but we would need to know what code is being run (yes, I’m aware your developer stats they are not writing, just reading).

AHEE__EventEspresso_core_domain_services_graphql_mutators_event_update
AHEE__EventEspresso_core_domain_services_graphql_mutators_datetime_update
AHEE__EventEspresso_core_domain_services_graphql_mutators_ticket_update
AHEE__EventEspresso_core_domain_services_graphql_mutators_ticket_delete

Those run within the admin so I would not expect those to cause this, possible but IMO unlikely.

We seem to have fixed this by moving the live API calls out of the execution flow, by queueing them for out-of-band processing in a cron job. We did not expect this anomalous behavior, and although we seem to have fixed it, we would still like to understand what happened.

What you see here isn’t expected, so I can’t tell you what is happening. The only time I’ve seen the sold values go out of sync with a payment method is when using PayPal Standard and that was caused by a whole bunch of weird and wonderful steps PPS uses where the user and IPN could hit the site at exactly the same time.

Actually, that may be a clue here if you’re using Mollie.

If the processing you’re doing on AHEE__EE_Transaction_Processor__update_transaction_and_registrations_after_checkout_or_payment with your custom code forces the request to take longer than expected it could mean that the request which returns the user from Mollie takes a while to complete. The thank you page also initiates an Ajax request which will load the payments and with the Mollie payment method we have code within that request to confirm the payment. It’s possible the request to update the transaction/registrations and the request to confirm the payment are running simultaneously and both updating the sold values.

But to be really clear here… we don’t have enough information to say what is happening as it stands so I’m guessing based on knowing how SPCO and the Mollie payment method work.. then trying to pick holes in it that could make sense here.

—

2) When we cancel a ticket – registration, there is a difference between the new status / report for those tickets in the new editor nr and the legacacy editor ( the legacy editor doesn’t change its shown numbers of registration, while new editor does reduce the nr shown with the cancelled tickets,

So for example old editor shows all registration ( say 4)
afterwards 1 is cancelled
The old editor still shows 4
The new Editor shows 3

For this I’m going to refer to the new editor as the Advanced Editor (internally we refer to is as EDTR so if you see that anywhere, it’s referring to Advanced Editor)

‘Legacy Editor’ is the ‘old’/previous editor.

With the difference in counts you mean between ‘Reg List’ in the Advanced Editor and ‘Regs’ in Legacy, correct?

Like this: https://monosnap.com/file/CEMF5FQXjY9z3VSKVaazzB7TABdQ9J

That’s exactly the same event with 2 registrations on it, one sold and one was Pendng Payment, but I set it to cancelled and reloaded Advanced and Legacy in separate windows.

This isn’t related to your issue here, it’s a choice in which registration statuses we include in the count. There is an argument that a cancelled registration is still a registration linked to the event (it’s a valid argument from multiple views) and the legacy editor includes those within the count. However, there is also an argument for NOT including those in the reg list, the main one being that if a registration has a status of cancelled it was intentionally set to be that status (we don’t set a reg status of cancelled automatically unless moving the registration) so then the count can be cluttered with those regs.

In the Advanced Editor those ‘additional’ registrations are not included in the count. This is based on feedback taken from the usage of the Legacy Editor and its likely a count that just wont suit everyone either way.

To give an example say a you have 50 registrations on Event A, 15 of them cancel for reasons related to the event/ticket itself and the count remains at 50…. that event/ticket looks like a popular choice but also has a high cancellation rate… so is it actually popular?

Or if you use the attendee mover add on to move registrations around from Event A to Event B, the original registrations are cancelled and new ones generated on the new selection. If that was a ticket change on the same event your reg list now has a double count for those groups if it includes cancelled regs.

So the count interested in the majority of the time is active regs, not cancelled, so thats what we have gone with.