We've ended up with a situation where one of our attendees has a single cart linked to two paid invoices.
The invoices have successive numbers, so I suspect they've double-clicked the submit button or something similar.
This was the cart had that had their TICKET_PRODUCT_CATEGORY item in - so they now have two tickets for the conference.
We've refunded one of the invoices - fortunately, this was a speaker so there's no money involved. But that now means that the cart is linked to a VOID invoice so the items are listed as cancelled rather than paid.
I think this would be better with some db-level integrity checking. I haven't looked at the models yet, but I don't imagine it's as simple as making the invoice<-> cart relationship 1:1 - a cart might be on several VOID invoices but should only have one PAID invoice. I don't think a UNIQUE_TOGETHER constraint is going to help either, as a cart might be on two VOID invoices
We've ended up with a situation where one of our attendees has a single cart linked to two paid invoices.
The invoices have successive numbers, so I suspect they've double-clicked the submit button or something similar.
This was the cart had that had their TICKET_PRODUCT_CATEGORY item in - so they now have two tickets for the conference.
We've refunded one of the invoices - fortunately, this was a speaker so there's no money involved. But that now means that the cart is linked to a VOID invoice so the items are listed as cancelled rather than paid.
I think this would be better with some db-level integrity checking. I haven't looked at the models yet, but I don't imagine it's as simple as making the invoice<-> cart relationship 1:1 - a cart might be on several VOID invoices but should only have one PAID invoice. I don't think a UNIQUE_TOGETHER constraint is going to help either, as a cart might be on two VOID invoices