# The booking form

The booking form gathers everything that belongs to a booking: tickets, options, the person (guest or user account), additional fields and the booking details. The header always shows the event, the date and the current occupancy.

## Tickets and booking options

For events with several ticket types (adult/child, say) you choose the quantity per ticket type; the prices are shown next to them. For free events there is a simple number of participants. If the event has booking options (a programme booklet, for example), you choose their quantity in a table of its own.

<div class="callout info" id="bkmrk-the-quantity-fields-">The quantity fields are limited automatically: to the DPCalendar limit *tickets per booking*, to the limit of the respective ticket type and to the remaining places. If DPCalendar still trims a quantity while saving (because someone else booked at the same time, for instance), the plugin reports the difference clearly.

</div>## Guest or user account?

There are two clearly separated cards for the person:

- **Book for existing users** — you search users through the search field (name, username or email, from two characters on) and book for their accounts. As soon as a user is selected, the guest card is disabled automatically and the save button changes to *continue to the personal data* — details in the chapter [Booking several users at once](https://docs.graup-it.de/books/backend-booking-en/page/booking-several-users-at-once).
- **Book as a guest (without a user account)** — you enter the contact details by hand. First name, last name and email are required; phone and address are optional. On request the plugin creates a user account automatically — see [A user account for guest bookings](https://docs.graup-it.de/books/backend-booking-en/page/a-user-account-for-guest-bookings).

## Additional fields

All custom fields you have set up in DPCalendar for bookings (*Components → DPCalendar → Fields*) appear in a card of their own — including field groups, required-field markers and the assignment to calendars. Exactly the configuration of the frontend form applies.

## Booking details

<table class="table" id="bkmrk-booking-datepre-fill"> <tbody> <tr><td>Booking date</td><td>pre-filled with the current time; freely adjustable for entries recorded after the fact</td></tr> <tr><td>Status</td><td>*active*, *pending*, *invited* or *waiting*. Left empty, the default status from the plugin options applies. For full waiting-list events, *waiting* is preselected.</td></tr> <tr><td>Payment provider</td><td>only for events that cost money; the payment plugins configured in DPCalendar (bank transfer, for example) are offered. There is no redirect to a payment service — the provider is merely assigned to the booking.</td></tr> </tbody></table>

<div class="callout warning" id="bkmrk-the-status-determine">The status determines what follows: only bookings with the status *active* count fully towards the occupancy and trigger the automatic account creation. You record the incoming payment later as usual by changing the status of the booking in DPCalendar.

</div>## Saving

With **Save booking** the booking is created through the regular DPCalendar logic. The success message links the new booking and names the booked date. *Back to the event selection* takes you to the list without saving, *Cancel* returns to the booking overview.

<small>Applies to version 1.0.7.</small>

[Deutsche Fassung](https://docs.graup-it.de/link/97)
Booking date	pre-filled with the current time; freely adjustable for entries recorded after the fact
Status	active, pending, invited or waiting. Left empty, the default status from the plugin options applies. For full waiting-list events, waiting is preselected.
Payment provider	only for events that cost money; the payment plugins configured in DPCalendar (bank transfer, for example) are offered. There is no redirect to a payment service — the provider is merely assigned to the booking.