Registration Software - Entities

The registration software using a NoSQL database. The entities of this system is described here.

Organisation

The Organisation entity describes the organisation responsible for an event. Each software installation is targeted to one, or sometimes more, organisations. The Organisation store will only list those organisations linked to the specific software installation. The server will host all records.

Person

The person entity store contains all knows Persons associated with the Organisation.

The Person entity contains only those properties required for registration. The server keeps all properties.

FulfilmentItem

Each entry, number or tag, when ordered, will appear as a fulfilment item. This is therefore items which is ready to be allocated to a person.

Each item will be linked to a person. Fulfilment items cannot exist without knowing who to issue it to.

An item may be linked to an event. These items are only relevant for the said event, such as an entry. Other items, such as numbers and tags that are paid, remain valid until collected. Therefore, unpaid numbers and tags should only ever be assigned to the event, as the requirement will need to be re-declared for the next event.

Each item will have one of the following entities linked;

  • Participant (the entry to a race)

  • Number

  • Tag

  • Day license

A fulfilment item can be unpaid. The reason for that is so that we know what was requested. For instance, a day license will be assigned to an entry (assume it is paid) when membership is expired/does not exist. In this way it is evident that the day license has still to be paid. The item will indicate the amount still due.

Barcode

A barcode can have a person associated with it. The conditions driving that is described below;

  • No person - This barcode can only be scanned after a person is selected.

  • With person - Such as an entry, pre-assigned number or pre-assigned tag. Note that the number and tag will not yet be assigned to the person, as this only happens one it is issued.

SHOULD WE NOT HAVE A START-PACK ENTITY, AND ONLY THAT ENTITY CAN EVER BE ASSIGNED TO A PERSON. THAT WAY BARCODE REMAINS INDEPENDENT OF PERSONS.

ARE WE SURE THAT NUMBERS SHOULD NOT BE ASSIGNED IN ADVANCE? WE HAVE A WAY TO OVERRIDE NUMBER OWNERSHIP (WARNING DISPLAYED WHEN ASSIGNING AN ALREADY ASSIGNED NUMBER). SURELY THE INTENTION HERE IS TO NOT ASSIGN, AND THEN HAVING TO UNASSIGN. BUT WE CAN HAVE AN INVALIDATE START PACK FUNCTION.

There should be an "Unpack" use case where we invalidate a start pack, returning the items in the pack back to the system. When this process is performed, ensure that items are only reset when the startpack person is the same as the item person. This will prevent situations where a start pack was opened at an event and its items used during an event. When it then gets "unpacked" later it will not reset those items assigned to others.