NP Entertainment Support

Search




Table of Contents
Product Stack
Ticket Module – Highlights
Key Entities and Definitions
Ticket Type
Ticket
Admission
Ticket Admission BOM
Schedules
Admission Schedules
High Level Entity Model
Details
Item
Ticket Type
Admission
Ticket Admission BOM
Schedule
Admission Schedule Lines
Ticket
Ticket Access Entry
Detailed Ticket Access Entry
Setup
POS Setup
Ticketholder Notification
Notifying Ticketholders
Internal Ticket Registration Process
Overview
Statistics
Known limits and discrepancies
Quick Statistics
Access Statistics Matrix
Access Control
Reservation Request Workflow
Web Services
MakeTicketReservation
MakeTicketReservation Confirm- And ValidateArrival
PreConfirmTicketReservation
ConfirmTicketReservation
CancelTicketReservation
ValidateTicketArrival
ValidateTicketDeparture



Product Stack


Ticket Module – Highlights

Items are used in NP Retail to sell tickets:

  • Variants of items are supported
  • Variants are identified with either Item Cross Reference or Alternative Numbers. Admission objects represent either locations or events



Access Control – a ticket can grant access to any number of different admission objects:

  • A ticket can be setup to be valid for any amount of time
  • A ticket can grant single or multiple accesses over any amount of time.


Dependencies can be defined for admission objects such as a ticket grants access:

  • To either of two admission objects, but not both
  • To an admission objects within a timeframe relative of a previous granted access
  • To admission objects in a defined sequence.


Schedules define when admission objects are accessible as either open or closed

  • Multiple schedules can be applied to the same admission object
  • Schedule definitions can be reused across multiple admission objects. Reservations- selling tickets for an upcoming event
  • Reservation with capacity control
  • Re-scheduling.


Capacity Control – admission objects define capacity, access can be declined based on:

  • Sales for a specific time slot (schedule)
  • Admissions for a specific time slot (schedule) (requires ticket scan on entry)
  • True capacity per time slot (schedule) (requires ticket scan on entry and exit). Stand-alone ticket scan solution (optional)


  • Scan ticket on entry
  • Scan ticket on exit.


Magento Web integration (optional)

  1. Ticket synchronization
  • Admission Objects
  • schedules.

2. Online ticket sales

3. Real-time capacity control.


Key Entities and Definitions

Ticket Type


The ticket type defines the characteristics of the ticket, such as
Timeframe for validity:

  • Number series (internal) and External Ticket Pattern

Printing and design

  • How access control is maintained.


The same ticket type can be reused on multiple ticket items.

Ticket


Items are used to sell tickets, when an item has a ticket type defined, it will behave like a ticket.
The ticket consists of 3 entities:

  • Ticket, which represents the physical ticket that is printed
  • Ticket Access Entry, which is the "ticket" for each admission object the ticket will grant access to
  • Detailed Ticket Access Entry, which captures all the different actions the ticket access entry is subjected to.

- Initial Entry

- Reservation

- Admission

- Departure

- Payment

Admission


Admission objects define what tickets are valid for. Admission objects can be either a type location or an event. Locations are typically physical, such as a museum, while events is something within the location, such as a guided tour.
With a few exceptions they work the same. Events admissions, for example, are valid for specific time, while location admissions are valid for any time within a timeframe.
The access control engine can check for dependencies when granting access to a specific admission object. Validations include:

  • Sequence – a specified admission objects need to be visited prior to this one
  • Within a given timeframe – this admission object needs to be visited within a specified timeframe relative to the previous recorded admission.
  • Mutual exclusion – visit either, but not both.

Ticket Admission BOM


Ticket Admission BOM define which admission objects will be managed by a specific ticket. A single ticket item must specify at least one admission object.
It may also include any number of admission objects. When having multiple admission objects per ticket, it may be convenient to specify which admission object should be the default.
When tickets are sold and active directly in the POS, the default admission object will be selected.

Schedules


Schedules define when a location is accessible or when an event occurs. Schedules themselves can be shared among many admission objects.

Admission Schedules


Combining the admission object with schedule definitions, makes it possible to define when a specific admission object is accessible. Admission objects may have many schedule objects to create the timeslots. The schedules have a processing sequence so that exception to a general rule can be handled easily.
The generated timeslots are stored in the Admission Schedule Entry table.
The instance can inherit certain properties from the either the Admission or the Schedule objects, or override the value on the admission schedule. The inheritance rule is defined on the Admission object.

High Level Entity Model


Details

Item

The item card has a few important fields in conjunctions with ticketing.

FIELD NAME

DESCRIPTION

No.

The item representing the ticket being sold.

Description

A useful description of the ticket.

Label barcode

AKA "Alternative No."


All tickets are required to have a "Label Barcode". Use the


"Create Barcode" field on the top of the page to create a


barcode for this item.


Rational:


The barcode encapsulates the item when there is a


variant attached


The web integration can only handle one item number


("external item no."). Internal code transposes


between barcode and item / variants seamlessly


Member Module also uses a single field for ticket item


number registration.


Item Cross Reference will work the same as Alternative


No. but is not fully supported in web integration

Ticket Type

When the ticket type finds the corresponding setup, the


item is considered a ticket.



Ticket Type


Ticket type controls how the ticket should behave.

FIELD NAME

 DESCRIPTION

Code

 The ticket type code.

Description

 A useful description of the ticket type.

Print Ticket

 If you wish to print an admission ticket on the POS receipt printer, this needs to be ticked.

Print Object ID

The object ID used for generating the printout. The system supplied code unit for printing tickets is 6014571.

Print Object Type

The type of object used for printing.

No. Series

Tickets have to 2 identification values – ticket numbers. The ticket primary key will be generated from this number series.

When multiple number series are used, it is crucial that they do not overlap.

External Ticket Pattern

This field is a pattern field to generate the external ticket number.

The pattern can include fixed text, the original ticket number and random characters.

Any characters not within the [ and ] will be treated as fixed text.

[S] – Will be substituted with the original ticket number from series.


[N] – Random number


[N*4] – 4 random numbers


[A] – Random character


[A*4] – 4 random characters


Example:


TK-[S]-[N*4]


Would result in TK-<ticket number>-<four random numbers>

Ticket

Should be checked as TRUE for tickets. This field will


become deprecated in future versions.

Ticket Entry Validation

Determines how admission control engine will validate the admissions;


Single – This ticket is valid for 1 admission only


Same Day – This ticket is valid for unlimited re-admissions on the same date as the first admission was recorded.


Multiple – the ticket allow as many admissions as specified in the "Max No. Of Entries" field, not related to date of first admission recorded

Max No. of Entries

 Used in combination with "Ticket Entry Validation", option Multiple to specify max number of admissions.

Duration Formula

 The Duration Formula specifies the timeframe for which a ticket is valid for admission.

Activation Method

 This option defines when the admission entry should be created;


 Scan – This option indicates that the admission is recorded by a scanning station when entering the location or event.


 POS – This option indicates that admission is recorded when the ticket is sold in the POS.


 Invoice – Reserved for future use.

Admission Registration

 This option controls the ticket creation. When multiple tickets are sold on the same line in the POS, the ticket can be either created as a group ticket or individual tickets.


 Individual – Ticket printed will correspond to quantity of tickets sold.


 Group – One ticket will be printed per line in the POS with the quantity as per quantity sold.

Ticket Configuration

 With this option it is possible to differentiate ticket

Source

Configuration and push and to use the setup from the Ticket BOM table. Fields that are affected are

  • Duration Formula
  • Max No. Of Entries
  • Activation Method
  • Ticket Entry Validation (AKA Admission Entry Validation)

Admission


Admission controls what a ticket is allowing entry for.

FIELD NAME

DESCRIPTION

Code

The admission code

Type

Admissions can be of either


Location – location represents a physical location,


such as the museum itself, or a special exhibition.


Event – scheduled events such as tours, or lectures.

Description

A useful description of the admission code

Location Admission

A helpful way of organizing / grouping admissions

Capacity Limits By

This option manages which capacity control setting should be applied. These numbers can be defined on either

Admission, Schedule or overridden on the Admission Schedule.

Admission – use the settings from the Admission objects.

Schedule – capacity varies depending on when it occurs.

Override – capacity is managed on the lowest level,the combinations of admission and schedule

Default Schedule

To have the admission engine ask less questions during sales, it is allowed to make certain assumptions as which event or schedule should be applied to the sales.


Today – when no schedule is supplied, assumes


Today's schedule is the correct one. If no schedule is found for today, or mora than one schedule is available, a user input dialog is presented to the teller for schedule selection.


Next Available – with (multiple) options, the next available schedule will be selected. Today or some future schedule.


Schedule Entry Required – Events for which a reservation is required and there is no logical or preferred time to select, should specify this value,

During ticket sales a dialog will pop-up for time selection

None - don't make an automatic selection

Prebook is Required

With this setting, a reservation is required and will be


created on sales. Admission will only be allowed at the


time specified on the reservation entry, Default schedule


rule applies.

Max Capacity Per Sch.

This number defines the max capacity for the admission

Entry

objects. The actual number used can be overridden based on the "Capacity Limits By" option.

Reserved for Web

Reserved for future use.

Reserved for Members

Reserved for future use.

Capacity Control

With this option, the method for admission control is selected.


None – No capacity control is checked when admission is recorded.


Sales – On sales, the sum of sold tickets is compared to the "Max Capacity Per Sch. Entry" value


Admitted – When admission is recorded the sum is compared to the "Max Capacity Per Sch. Entry" value 


Full – Also takes number of departed into account when calculating the current number of admitted.The actual value used can be overridden based on the "Capacity Limits By" option.

Prebook From

Date formula


Determines how far into the future timeslot should be generated. This in turn will control how far ahead reservation can be made. The actual value used can be overridden based on the "Capacity Limits By" option.

Dependent Admission

Admissions can be dependent on other admissions. With this field it is possible to setup a simple dependency.

Dependency Type

This option controls the type of dependency; 

<blank> - The Dependent Admission must have been visited first.

Within Timeframe – The difference in time must not be greater than specified in the Dependency Timeframe when visiting this admission compared to the dependent admission arrival entry.

Exclude – The Dependent Admission code must NOT have been visited, when this admission is entered

Dependency Timeframe

Date formula to calculate a timeframe for admission dependencies.

Ticketholder Notification Type

This options control if we need to collect the ticketholder email or phone number for a possible notification at some later point.

The options are:

NOT_REQUIRED – there is no automatic popup
during ticket sales. There is no error if the popup is
triggered manually using the EDIT_TICKETHOLDER
POS functions.
OPTIONAL – The popup is display to collect the
ticketholder notification address. Email address is
evaluated to be correct, but invalid emails are
allowed. The dialog can be canceled.
REQUIRED – Like optional above, but when dialog is
canceled an additional confirm dialog is show if the
notification address is empty. It is possible to leave
the dialog without entering a valid notification
address.


Ticket Admission BOM


Ticket Admission BOM define which admission objects will be managed by a specific ticket. A single ticket item must specify at least one admission object.

FIELD

DESCRIPTION

Item No.

The Item Number used for sales in the POS

Variant Code

Advanced ticket setup can use item variants to create a family of tickets. This is usually used when setting a web ticket. The variants of the ticket might then be Adult, Child,Senior, etc.

Admission Code

The admission code the ticket should be valid for. The same Item can allow access to multiple admission objects.

Default

When multiple admission objects are defined, and, for example, the POS is setup to create admission on sales.

The POS will then select the default admission code. This feature is used trough out the solution, when no code is specified and there are multiple to select from, the default is selected.

An error is raised when no default admission is defined and there are more than one to select.

Quantity

Advanced Capacity Control, ticket quantity is multiplied by this number to calculate the capacity cost. Should be 1 for normal use.

For group tickets, it could be the number of participants in the group.

For a person in a wheelchair with an accompanying person, it could be 2.

Description

Useful for ticket printing

Admission Description

Useful for ticket printing

Duration Formula

When the field "Ticket Configuration Source" on "Ticket


Type" specifies option TICKET_BOM, this fields value is used instead of the corresponding field in Ticket Type

Max No. Of Entries

When the field "Ticket Configuration Source" on "Ticket

Type" specifies option TICKET_BOM, this fields value is used instead of the corresponding field in Ticket Type

Activation Method

When the field "Ticket Configuration Source" on "Ticket


Type" specifies option TICKET_BOM, this fields value is used instead of the corresponding field in Ticket Type

Admission Entry Validation

When the field "Ticket Configuration Source" on "Ticket

Type" specifies option TICKET_BOM, this fields value is used instead of the corresponding field in Ticket Type



Schedule


Schedules define when a location is accessible or when an event occurs. Schedules themselves can be shared among many admission objects. The setup defines how these entries should be generated based on some rules available. The scheduler will only allow one entry per date. This is to allow automatic rescheduling if the schedule definition would change. To have multiple timeslots for the same admission on the same date, multiple schedules must be created.

FIELD

DESCRIPTION

Schedule Code

Schedule Code

Schedule Type

For future use, will be used for handling rescheduling

  • Location
  • Event

Admission Is

Option to define whether this schedules generates 

timeslots representing Open or Closed.

Open

Closed (most likely used in connection with multiple schedules, to make sure admission is closed on Christmas or similar)

Description

A useful description of this schedule

Start From

The start date / base date for this schedule.

Recurrence Until Pattern

How this schedule should stop generating entries

No End Date

End After N Occurrences – Limit in "End After Occurrences" field

End By – Limit in "End After Date" Field

End After Occurrences

Number of occurrences

End After Date

Last date for timeslots

Recurrence Pattern

  • Weekly
  • Daily

Recur Every N on

Number, used in connection with Recurrence Pattern.

Start Time

When the event starts or location opens

Stop Time

When the event ends or location closes

Event Duration

Used to specify a stop time, on the next day.4:3

Monday

Generates an entry of type "Admission Is", if the date corresponds to the weekday Monday
TuesdayGenerates an entry of type "Admission Is", if the date corresponds to the weekday Tuesday
WednesdayGenerates an entry of type "Admission Is", if the date corresponds to the weekday Wednesday
ThursdayGenerates an entry of type "Admission Is", if the date corresponds to the weekday Thursday
FridayGenerates an entry of type "Admission Is", if the date corresponds to the weekday Friday

Saturday

Generates an entry of type "Admission Is", if the date corresponds to the weekday Saturday
SundayGenerates an entry of type "Admission Is", if the date corresponds to the weekday Sunday

Prebook is Required

With this setting, a reservation is required and will be created on sales. Admission will only be allowed at the time specified on the reservation entry, Default schedule rule applies. The actual value used can be overridden based on the "Capacity Limits By" option defined for the 

admission.


Max Capacity Per Sch. EntryThis number defined the max capacity for the admission objects. The actual number used can be overridden based on the "Capacity Limits By" option defined for the admission.
Reserved for WebReserved for future use.
Reserved for MembersReserved for future use.
Capacity Control

With this option, the method for admission control is selected.

None – No capacity control is checked when admission is recorded.

Sales – On sales, the sum of sold tickets is compared to the "Max Capacity Per Sch. Entry" value

Admitted – When admission is recorded the sum is compared to the "Max Capacity Per Sch. Entry" value
Full – Also takes number of departed into account when calculating the current number of admitted.
The actual value used can be overridden based on the
"Capacity Limits By" option defined for the admission.

Prebook From

Date formula

Determines how far into the future timeslot should be generated. This in turn will control how far ahead reservation can be made.
The actual value used can be overridden based on the
"Capacity Limits By" option defined for the admission.


Examples:
A schedule that generates open entries for every weekday.
Admission Is: Open
Start From 2016-01-01 (a Tuesday)
Recurrence End Pattern: No End Date
Recurrence Pattern: Weekly

  • Recurrence Pattern: 1 (The same pattern every 1 week) Day Pattern – Check weekdays
  • Monday: Checked
  • Tuesday: Checked
  • Wednesday: Checked
  • Thursday: Checked
  • Friday: Checked
  • Saturday: Unchecked
  • Sunday: Unchecked.


Prebook from: +14D
A schedule that generates closed entries on December 24.
Admission Is: Closed
Start From 2016-12-24 (a Saturday)
Recurrence End Pattern: End After N Occurrences

  • End After Occurrences: 1 Recurrence Pattern: Daily
  • Recurrence Pattern: 1


Day Pattern Check all days, we don't care which weekday December 24 is. (Or maybe it should be closed only if the 24 is on a weekend, in which case you would check Saturday and Sunday only)

  • Monday: Checked
  • Tuesday: Checked
  • Wednesday: Checked
  • Thursday: Checked
  • Friday: Checked
  • Saturday: Checked
  • Sunday: Checked.


Prebook From: Note that schedules will only be generated a small portion at every time. Prebook from determines how long into the future will need to look. So if this date formula does not cover when the schedule is valid for, no entries will be generated.

Admission Schedule Lines


Combining the admission object with schedule definitions, makes it possible to define when a specific admission object is accessible. Admission objects may have many schedule objects to create the timeslots.

The actual value used can be overridden based on the "Capacity Limits By" option defined for the admission.

Schedule Generated Until Indicates to which date the schedule has been proceeded. Note that this is the date the schedule will continue generating entries from. Even though this date is set, there may be no entries created due to constraints induced by the schedule definition. Clearing this date when there are entries created for the admission will cause rescheduling to occur. If the schedule definition has changed, already created entries may be canceled as a consequence. Rescheduled entries occurring on the same date, will retain the external id they initially had.

Ticket


The Ticket table represent the printed ticket.

FIELD NAME

DESCRIPTION

No.

Primary key, generated from Number Series on Ticket Type

Ticket Type Code

The Ticket Type for this ticket

No. Series

Number Series used.

Valid From Date

The date of first validity

Valid From Time

DEPRECATED, will always be 00:00:00

Valid To Date

The date of last validity

Valid To Time

DEPRECATED, will always be 23:59:59

Blocked

Reserved for future use.

Blocked Date

Reserved for future use.

Printed Date

Reserved for future use.

Salesperson Code

Reserved for future use.

Document Date

Date of ticket creation.

Source Code

Reserved for future use.

Customer No.

Reserved for future use.

Sales Header Type

Reserved for future use.

Sales Header No.

Reserved for future use.

POS Receipt No.

Receipt number of sale in POS

Line No.

Receipt line number

External Member Card No.

Reference to the member that swiped member card to get tickets 

No. of Access

DEPRECATED

External Ticket No.

The number that should be printed on the ticket

Ticket No. for Printing

DEPRECATED

Item No.

The item used in sales

Variant Code

The variant of item used in sales

Last Date Modified

Last Date Modified


Ticket Access Entry


This table holds the admissions that a ticket is valid for.

FIELD NAME

DESCRIPTION

Entry No.

Primary key, internal

Ticket No.

Foreign key to Ticket

Ticket Type Code

The ticket type

Access Date

The date of first access

Access Time

The time of first access

Description

The description of admission code

Customer No.

DEPRECATED, See Ticket

Member Card Code

DEPRECATED, See Ticket

Status

Future Use

Qty.

Sales Quantity

Admission Code

Code of the admission this access entry will grant access to.


Detailed Ticket Access Entry


This table contains all details regarding a specific admission for specific ticket.

FIELD NAME

DESCRIPTION

Entry No.

Primary key, internal

Posting Date

Future use, for deferred revenue

Ticket No.

Foreign key to Ticket

Ticket Access Entry No.

Foreign key to Ticket Access Entry

Type










Options stipulating the purpose of this entry

Initial Entry - represents the ticket sales

Reservation – this ticket has a reservation

Admitted – the ticket was successfully scanned for

arrival

Departed – the ticket was successfully scanned for

departure

Consumed – future use

Canceled – future use

Payment – the ticket was confirmed

External Adm. Sch. Entry













Foreign key to a schedule entry that captures the time which this entry is intended for.

Initial Entry – time entry for the sales day, used in capacity control.

Admitted – time entry for admission, used in capacity control.

Departed – time entry for departure, used for capacity control.

Reservation – time entry for the reservation.

Admission is not allowed unless the admission references the same entry.

Quantity

Sales Quantity

Closed By Entry No.

The entries are chain, linking initial entry with payment, reservation -> admission -> departure

Open

Last link in the chain

Sales Channel

Future use

Created Datetime

Date and time of creation

User ID

The logon user id creating the entry.


Setup


Suggested order for setting up ticketing:

  • Ticket Types, number series, ticket validity.

Items – create the sellable items, assign ticket type item in order to make it a ticket. Admission Objects. Decide on the list of entities for which you will be selling tickets. Ticket BOM – select which admissions object this ticket will be valid for.

  • Schedules. Define the general opening hours/days for the admission objects.

Combine Admission Objects and Schedules to create the specific schedules for admission object.

  • Add required buttons to the POS, including function buttons.


POS Setup


To add tickets as buttons on the POS sales form, simply add them as regular sales items on the "Sales Form".
The ticketing module has several command buttons in the POS, to control what the button should do for ticketing.
With the Line Type set to Internal and the Filter No. set to TM_SCAN_TICKET, different sub-functions can be accessible in the POS by defining the field "Parameter" according to the following table.

PARAMETER

DESCRIPTION

ARRIVAL

ARRIVAL::

<Admission Code>

This will display a pop-up window to input the external ticket number. When confirming the dialog, the ticket will be validated for arrival to admission code. When admission code is not defined, the default from Ticket Admission BOM will be used.

ADMITTED_COUNT

ADMITTED_COUNT::

<Admission Code>

This will display a pop-up window listing either all or specified admission code with some quick statistics regarding todays admissions.

EDIT_TICKETHOLDER

This functions brings up the dialog to change the notification address of the ticket holder.

EDIT_RESERVATION

This function operates on the current POS sales line. When the ticket item is created, it holds the reservation for 1500 seconds (25 minutes). After that, the½ ticket is expired and reservation is released. Should the RECONFIRM_RESERVATION fail, because there are no more spots available, the reservation timeslots will need to be edited!

RECONFIRM_RESERVATION

This function operates on the current POS sales line. When a sale takes more than 1500 seconds to complete, there will appear a message saying that the ticket has expired. In order to complete the sale the ticket need to be RECONFIRMED. If the tickets can't be reconfirmed, the reservations need to be EDITED

REVOKE_RESERVATION

The revoke function, cancels the reservation and refunds the money. The ticket must be a valid unrevoked ticket.


Ticketholder Notification

The ticket management module supports ticketholder notification.
Setup is done per admission code. "Ticketholder Notification Type" can be set to

  • Not Required
  • Optional
  • Required


Notification Address can be view / edited from the Issued Ticket List.
Only reservations for events will be notified, although the information is collectable regardless of admission type.
The web-service "ConfirmTicketReservation" collects Ticketholder Notification Address on web sales.
There must be at least one email template setup for table 6060113 "TM Ticket Participant Wks."

Notifying Ticketholders


Ticketholders can be notified from the ticket management module. Notifications are generated from the admission schedule entries that have reservations. 3 types of notifications are detected.
REMINDER – when there is one admission schedule entry for the event and it is open.
RESCHEDULE – when there are more than one schedule entry for the same event, the first entry is closed, the last is not.
CANCELATION – the last schedule entry for event is closed.
Procedure
From the "Ticket Admission" page, select the event and navigate to the "Admission Schedules" and from there navigate to the "Schedule Entries".
Find the admission entry that you wish to notify the ticket holders for. Select the action "Create Ticketholders List".
If this is this is the first time this action is performed for this event, a page with ticketholders will be created and displayed. If the list already exists, there will be prompts regarding actions to append or recreate the list.
The ticketholders list is displayed regardless of whether there is someone to notify or not.
Selecting the action "Send Notification" will try to send a notification to the selected list of ticketholders that have status Pending and are not blocked.
Notification method needs to be specified. Currently the only type support is email.

Internal Ticket Registration Process

Overview


Ticket registration is split into 2 logic parts, one that occurs on item registration and one that occurs after/during the posting of the audit role.
Internally the ticket state is stored in a request and response table.
Before Audit Role is posted

  1. During POS item registration, the POS identifies the item as being a ticket item.
  2. A reservation request is created
    1. Expired registrations are cleaned
      1. Reservation with status Registered, the tickets are removed to free up admission objects
      2. Reservation with status Expired are permanently deleted

b. Default timeslots are assign each admission object for default schedule TODAY and NEXT AVAILABLE

c. Request is set to be "Work in Progress"

3. Ticket is issued from reservation request

    1. Reservation Capacity is verified
    2. Sales Capacity is verified
    3. Status is changed to "Registered"

4. Receipt is checked for missing reservation information

a. New default values are inherited from previous POS sales lines

5. Ticket is checked for problems (capacity, missing reservations)

    1. A confirm dialog is shown to teller to resolve any problems.

6. On confirm, the reservation is re-reserved. Same process as step 3

    1. On Ok – the last changes are committed
    2. On Cancel – the sales line is deleted.


The reservation request has now a time-to-live of 1500 seconds.
During this time the ticket reservation can be RECONFIRMED at any time. As a result, the reservation request will be valid for a new set of 1500 seconds.


During Audit Role posting
When the audit role is processed, the ticket reservation request records the payment entries to ticket detailed entries.
A ticket is not valid unless it has recorded the payment entries.
If the ticket type specifies that admission should be recorded by the POS, this also occurs at this stage. The default admission code registered in Ticket Admission BOM is used.

Statistics

There are several means for statistics.
Quick Statistics is a "show me todays numbers" page, which could be available from the POS. See the button assignment in the POS Setup section.
A more flexible multidimensional access statistics page is available in the "Report and Analysis" section. Will aggregate the detailed access entries of type admitted.

Known limits and discrepancies

Quick Statistics


This method uses a flow field on the Admission Schedule Entry to quickly calculate the number of admissions. However if a ticket is used, and then revoked, it will be excluded from the admitted count. This method is primary for calculating the capacity limit, and a canceled ticket would require the ticket holder to be departed from the location.

Access Statistics Matrix


This method is more precise, but since it aggregates the admissions, it will be no available for the admissions of today. The example of the revoked ticket above, is counted as a valid admission even though it was canceled. This is because it has a valid admission recorded. The aggregated data is persistent and will not change over time as opposed to how the flow filter works, creating a new sum every time it is executed.

Access Control


The Access Control Engine performs many checks to validate the ticket on arrival.

  1. Ticket Number must exist
  2. When a ticket specifies a reservation request, that request must exist and have status CONFIRMED
  3. Admission Code may be blank, in which case the default admission code is selected.
  4. The admission code must exist
  5. There must be a Ticket Access Entry for the admission code and ticket number.
  6. There must be a Detailed Ticket Access Entry of type PAYMENT.
  7. If the admission specified that "Prebook is Required":
    • Detailed Ticket Access Entry of type RESERVATION must exist
    • If no schedule entry is submitted to access control, a default is found using the current date and time.

8. If the admission does not specify that "Prebook is Required":

    • If no schedule entry is submitted to access control, a default is found using the current date and time.

9. The arrival is registered using the schedule entry

10. Dependency control

    • Blank
    • Exclude
    • Dependency Timeframe.

11. Capacity Control

a. Admission is verified to see if the admission capacity is violated

  • NONE
  • SALES
  • ADMITTED
  • FULL

b. Ticket is verified to see is ticket capacity is violated.

  • SINGLE
  • SAME_DAY
  • MULTIPLE

Reservation Request Workflow


Reservation requests undergo an automatic workflow. A request may have the following states:
Work In Progress – This is the state when the request is in the creation process Registered – then reservation is active

  • Request has a sub-state to confirm if ticket access entries are actually created
  • The request is assigned an expiry time.
  • When expired time has passed, the next incoming request will expire the ticket and thus release the reservation.
  • PreConfirmTicketReservation message can be used to extend the expiry time.


Expired – the request still remains, but the ticket access entries are removed. This allows capacity control to grant access to new / other tickets. To re-register the reservation without changing the reservation contents, the PreConfirmTicketReservation message can be used.

  • Expired request also has an expiry time. When expired time has passed, the next incoming request will cancel the request.


Confirmed – This is the final state. In order to confirm a ticket, the reservation state must be "Registered" prior to call. Tickets with a request state different from confirmed, are not valid. Confirmed requests may not be deleted or changed in any way.
Canceled – Removes all data belonging to the reservation request.

Web Services


Tickets have the following web services available:

SERVICES

DESCRIPTION

MakeTicketReservation

This service creates a ticket reservation

MakeTicketReservation

This service is a "do-all" service, indented for use with the

ConfirmAndValidateArrival

member module.

PreConfirmTicketReservation

This services extends the timeframe for an already created


reservation.

ConfirmTicketReservation

Confirm finalizes the ticket sales. Unconfirmed tickets are not valid.

CancelTicketReservation

Cancel removed the created reservation.

ValidateTicketArrival

Validates a ticket for arrival to specified admission object.

ValidateTicketArrival

Validate a tickets for departure to specified admission object.

MakeTicketReservation


This will create an order of sort to facilitate the reservation request:

NAME

DESCRIPTION

Token

An initial request will specify a blank token value. A blank token indicates that this is a NEW request. The service will then return a token that should be used to reference this reservation request.Token can be thought of as an order number

External ID

The external id should be the sales item, This could either be an actual item number, or a label barcode (alternative number), which is preferred.

Line No

External line number to distinguish different lines on the order

Qty

Number of ticket to reserve

Admission Schedule Entry

The reference to a scheduled time slot. This field may be optional if the setup for ticket does not require a specific timeslot for the admission.

Member Number

A reference to a member for whom to associate the reservation with. (optional)

Admission Code

The reference to an admission code. This field may be 

optional if the setup for ticket does not require a specific

timeslot for the admission

The service will return the following information:

NAME DESCRIPTION

Status

True or False, depending on the reservation being successful

Reservation Token

The Token to use in future service calls to manage this reservation

Expiry Time

The time in seconds until the reservation will be expired and a confirm will not be possible without reconfirming the reservation.

MakeTicketReservation Confirm- And ValidateArrival


Ticket self-scan for members with accompanying guests.
This service is a "do-all" service, indented for use with the member module only. It combines the followings services:

MakeTicketReservation

  • ConfirmTicketReservation
  • ValidateTicketArrival

NAME

DESCRIPTION

Token





An initial request will specify a blank token value. A blank

token indicates that this is a NEW request. The service will

then return a token that should be used to reference this

reservation request.

Token can be thought of as an order number

External ID



The external id should be the sales item, This could either

be an actual item number, or a label barcode (alternative

number), which is preferred.

Line No

External line number to distinguish different lines on the order

Qty

Number of ticket to reserve

Admission Schedule Entry

The reference to a scheduled time slot. This field may be optional if the setup for ticket does not require a specific timeslot for the admission.

Member Number

A reference to a member for whom to associate the reservation with. Required.

Admission Code

The reference to an admission code. For registering arrival.Required.


The service will return the following information:

NAME

DESCRIPTION

Status

True or False, depending on the reservation being successful

Order_uid

Alias for token

Message Text

In case status is false, there might be a reason text here

(Ticket) External ID

Reflects input

(Ticket) Line No

Reflects input

Ticket UID

External Ticket Number

Barcode No

Same as Ticket UID

Valid from

YYYY-MM-DD, ticket is valid from date

Valid Until

YYYY-MM-DD ticket is valid until date

(Admission Validated)

Reflects input

Code


Description

Admission description

Quantity

Reflects input


PreConfirmTicketReservation


This services extends the valid timeframe for an already created reservation. It may also

NAME DESCRIPTION
Ticket token

The reservation identified by the token will re-confirmed.

Expiry time will be extended.

When the state is:

“Registered”, this call should not fail, since the request already has an active reservation.

“Expired”, this call may fail since the reservations was released and other reservation may have consumed the available tickets

“Confirmed”, this call will fail.


 

The service will return the following information:

NAMEDESCRIPTION
Status

True or False, depending on the reservation being successful


ConfirmTicketReservation


Confirm finalizes the ticket sales. Unconfirmed tickets are not valid.

NAME

DESCRIPTION

Ticket token








The reservation identified by the token will re-confirmed.

Expiry time will be extended.

When the state is:

"Registered", this call should not fail, since the

request already has an active reservation.

"Expired", this call will fail. Use the

PreConfirmTicketReservation to reregister it.

"Confirmed", this call will fail.

Send Notification To

Ticketholder notification address. Can be mobile phone number, email, etc.

External Order No

For matching Magento web order to ticket sales


The response includes all ticket details.

NAME

DESCRIPTION

Status

True or False, depending on the reservation being successful

Order_uid

Alias for token

Message Text

In case status is false, there might be a reason text here

(Ticket) External ID

Reflects input

(Ticket) Line No

Reflects input

Ticket UID

External Ticket Number

Barcode No

Same as Ticket UID

Valid from

YYYY-MM-DD, ticket is valid from date

Valid Until

YYYY-MM-DD ticket is valid until date

(Admission Validated)

Reflects input

Code


Description

Admission description

Quantity

Reflects input


CancelTicketReservation


NAME

DESCRIPTION

Ticket token

The reservation identified by the token will re-confirmed.


Expiry time will be extended.


This will fail when the token has been confirmed.


The service will return the following information:

NAME

DESCRIPTION

Status

True or False, depending on the reservation being successful 


ValidateTicketArrival


Use this service to validate a ticket for arrival to specific admission code. On success the arrival has been recorded and future calls may fail when using the same ticket number, as it may only allow one entry.

NAME

DESCRIPTION

Admission Code

The location or event you wish to gain access to.

External Ticket No

The ticket number

Scanner Station Id

Future Use


The service will return the following information:

NAME

DESCRIPTION

Status

True or False, depending on the request being successful

Message Text

On false, there should be a reason why it failed.

ValidateTicketDeparture


Use this service to validate a ticket for departure from a specific admission code. This service should not fail event though arrival was not granted or ticket number is invalid. (or you could use it to brute force search for valid ticket numbers)

NAME

DESCRIPTION

Admission Code

The location or event you wish to register departure from.

External Ticket No

The ticket number

Scanner Station Id

Future Use

Message Text

A message that is reflected.


The service will return the following information:

NAME

DESCRIPTION

Status

True or False, depending on the request being successful

Message Text

Reflects the input message text