🗓️ Fortnightly Allocation
Parking space allocation using the algorithm is performed on a fortnightly basis, with scheduled executions on the 1st and 15th of each month.
🛠️ Previous Configuration
The support team must configure the number of days in advance during which users are allowed to request a parking space in the lottery. These days define the period during which users can submit their requests.
⚙️ Scheduled Execution
The opening is executed at the time configured in the database (BBDD).
Administrators cannot modify either the execution time or date.
Working Days and Weekends
If the office allows weekend bookings, the execution remains unchanged.
If weekend bookings are not allowed, the system automatically moves the opening to the next working day.
If the date falls on a holiday, the opening is also postponed to the next available working day.
Opening Dates
Openings take place on the 1st and 15th of each month.
If the office has multiple consecutive opening days, they are counted from those dates.
For example:
If there are 3 opening days, they will be enabled on days 1, 2, and 3, and then 15, 16, and 17.
Days 1 and 15 are not counted as opening days themselves, but as the starting point of the process.
⚠️ Important: If the user belongs to a priority reservation group, the maximum number of priority days will be 5.
⚙️ Algorithm Execution
Once the request period ends, the algorithm runs the following day.
During execution:
Requests submitted within the period are processed
Available parking spaces are assigned according to configured rules
No more requests can be made for future days within that fortnight
After the lottery:
The system will only allow bookings for the current day, if there are available spaces for immediate assignment
Requests that could not be assigned remain in “requested” or “pre-booking” status.
If another user cancels their booking:
The algorithm runs again
Pending users are automatically reassigned based on defined priorities
Space and Shift Selection
Users can request different types of spaces on different days (e.g., a small space one day and a large one the next).
Each request must indicate the desired shift:
Morning
Afternoon
Full day (electric vehicles)
Full day (fuel vehicles)
A user may have an electric space in the morning, while that same space could be free in the afternoon if there are no additional requests.
If a user selects full day with an electric vehicle:
One shift (morning or afternoon) will be assigned to an electric space
The remaining shift will be assigned to a fuel-based space
The system always prioritizes electric spaces.
If there are users without available electric spaces:
They will be assigned to fuel-based spaces
Final priority is given to users with electric vehicles, if availability allows.
Unassigned spaces remain empty.
From the admin panel, it is possible to enable an option so the algorithm considers the user’s preferred space type during assignment.
⚙️ Configuration from the Admin Panel
A new option called “Space Preference” is available.
Here, you can:
Define the available space types
Assign a priority to each type
This priority determines the order in which spaces are assigned.
In the parking module configuration (within office settings), you can enable the space type preference option.
To use this preference:
Create space types
Assign those types to each parking space
This is done by accessing the details of each space.
⚙️ Configuration of Priority Groups
Zone Configuration
Each zone can be assigned one of the following characteristics:
Reduced mobility
ECO
Car sharing
Only one characteristic can be assigned per zone.
Example:
The zone “CW Fuel Car” allows assignments only for ECO vehicles.
User Configuration
Reduced mobility
To assign:
Go to user details
Enable “reduced mobility”
ECO
To assign:
Go to user → Vehicles tab
Edit the vehicle
Enable “ECO”
⚠️ Only applies to fuel vehicles.
Car sharing
To assign:
Go to user → Vehicles tab
Edit the vehicle
Enable “Car sharing”
📘 Practical Example
Scenario:
An office allows bookings from Monday to Friday and has 2 opening days.
The algorithm opens on May 15 (Wednesday).
Result:
Days 15, 16, and 17 are enabled
If the 15th is a holiday, the opening moves to May 16 and users can pre-book until May 18
Priority users can request from the 13th or 14th (depending on their range)
Non-priority users can request from the 15th
On May 18, the algorithm assigns spaces (if no holidays or weekends interfere)
Assignment example by group:
Groups:
Reduced mobility
ECO
Car sharing
Electric
Fuel
Assignments:
Reduced mobility users are assigned first
If full → remaining requests go to fuel zones
ECO and car sharing
If full → requests compete with fuel users
Electric spaces
If full → assigned to fuel
Fuel and remaining requests
Execution Details
When does it run?
First day after the request period
Also runs reactively when a user frees a space
Functionality
Executes via daily HTTP calls to
LotteryFortnightlyHttpTriggerAssigns spaces randomly, considering:
Reduced mobility / ECO / car sharing preferences
Space type preference (if enabled)
Only compatible spaces are assigned
If no compatible space exists → request is rejected
If preferences are not configured → behaves like a standard random lottery
Removes released bookings before assignment
Days 1 and 15 are not counted as advance days
Priority Order
Reduced mobility
ECO
Car sharing
Electric
Fuel
Additional Rules
If reduced mobility spaces are full → assign to fuel
If ECO/car sharing spaces are full → lottery with fuel
If no availability in one level → move to next
Notifications
Users with assigned bookings
Users rejected due to lack of space or incompatibility
Users who released a space (if reassigned)
Reports
The system can generate a report after the fortnightly process is completed