EPOS3

This page will serve as a technical overview of EPOS version 3 (EPOS3) (matching website version 3).

TicketClass and TicketType

The first and possibly the most confusing concept to get out of the way first is the difference between a Ticket "Class" and a Ticket "Type".

A Ticket Class is meant to represent a whole class of tickets over the life of EPOS3, for instance "Member Ticket", "Crew Guest" etc. It is not designed to encompass concepts such as tickets for individual events, but rather for every event of that particular kind, so for instance "AllNighter Member Ticket" is a valid ticket Class, but "The Butterfly Effect - Sponsored Event" is not. A Ticket Class has no concept of a price in it.

A Ticket Type is meant to represent the current incarnation of a Ticket Class. This includes the key information of price. This means that ticket price changes do not mean that a whole new set of tickets need to be created that only differ by price. This makes it much easier to for instance, track ticket sales for a particular type over a period of time, since one can track by Ticket Class which has a number of associated Ticket Types, possibly with different prices, but are essentially the same ticket. This also means that tables such as Ticket Requirements and Ticket Mutexes do not get bloated with superfluous data each time a ticket price changes, since these are based on Class rather than Type.

Some examples of the intended uses of Ticket Classes and Types:

Class: Members Ticket
  Type: £2.00 (Valid from: whenever this price was instigated...)
  Type: £2.50 (Valid from: Sep 30th 2011)
Class: Non-Members Ticket
  Type: £3.00 (Valid from: same as above...)
  Type: £3.50 (Valid from: Sep 30th 2011)
Class: Crew Ticket
  Type: £0.00 (Valid from: UNIX Epoch :P )
Class: AllNighter Members Ticket
  Type: £7.00 (Valid from: ...)
  Type: £8.50 (Valid from: Sep 30th 2011)

etc.

It should be noted that at any time, only one Ticket Type is valid for any given Ticket Class. This is based on the most recent "Valid from" time. Thus it is not possible for someone to purchase a Members Ticket at the price point of £2.00 after Sep 30th 2011. However, if they still have a credit for a Members Ticket, they are not required to pay the difference in order to redeem it (more on this below).

Credit and Debit

In order to make EPOS more flexible in the face of potentially new avenues of sale and to make administration work slightly easier, EPOS3 uses a system of Credits and Debits to keep track of who has bought what, when and whether they've spent it.

A Credit represents the fact that a Person is owed (by the society) a Ticket of the specified Ticket Class (as taken from the Ticket Type purchased). This can be from purchasing online for instance, credits applied for publicity work, prizes from an AllNighter, or (even!) buying a ticket at a show.

A Debit is created when a Person redeems a Credit for a Ticket. The Ticket is of the Class specified in the Credit, and is specific to a certain Show and is created simultaneously with the Debit. A Debit may also be created if the Credit expires (for instance at the end of the year or after AllNighters)

Thus we can see that every Debit has an associated Credit (not necessarily the other way though, a Credit may be unredeemed) and that every Ticket has an associated Debit (again, not necessarily vice-versa).

So, in the case that a Person buys a Ticket at one our physical tills, all three of a Credit, Debit and a Ticket are all created simultaneously. The Credit to represent that the prescribed amount of money was given to us, the Debit to represent that the Credit was redeemed and the Ticket the result of the redemption.

The generic nature of Ticket Class, Ticket Type, Credit and Debit also means that the system is not necessarily tied to a particular type of transaction. Shows for instance require a Ticket, but a Ticket is not necessarily generated for every Debit. For instance, the Credit system could be used for Clothing Orders to represent money paid towards Clothing, which could then require a Person to pay (and get the Credit) for a piece of clothing before they were able to redeem it for Clothing on the necessary page. (Note however that each piece of clothing would have a "Ticket Type" and "Ticket Class", a somewhat misleading description, but this can be hidden from the end-user!)

TicketRequirement

Each Ticket Class needs a set of requirements to restrict who an purchase it, for instance we wouldn't want a non-member to be able to "purchase" a Crew ticket would we?

epos_ticketrequirements is a one-to-many relationship table between Ticket Class and Ticket Requirement, that is, the entries in the table show which Requirements each ticket has. The epos_requirement table contains different requirements, each of which any number of Ticket Classes can use. It (at present) specifies two predicates, memberof and musthavecredit. memberof specifies that the Person must be a member of the group whose Id is specified in the object field. musthavecredit specifies that in order for a person to obtain a Ticket, they must already have a corresponding credit for that Class (e.g. this means that you cannot be sold publicity credits, but require them to be granted to you).

TicketMutex

There are certain tickets that should not be sold together in the same transaction, for instance, a Person can only bring one guest to a Show, and so should not be able to purchase both their Crew Guest and External Guest in the same transaction. TicketMutex provides for this requirement by listing for each Ticket Class the other Classes of Ticket it cannot be sold with. At present, the setup does require a relationship to be represented twice, with each Ticket Class represented in the left and right fields.

Show

A Show represents one of our Showings. This represents all showings of any size, whether a single film, an AllNighter or otherwise. Each Show has an associated set of Films via the show_films table. The vast majority of showings then, will have one entry in shows and one entry in show_films. The show_ticketclasses table represents which Ticket Classes are to be made available for sale. This means that for instance, you cannot buy an AllNighter ticket at a normal showing etc.