Travel (Raj Pravas)¶

Part of the Aashray Business Logic. Related: Booking Lifecycle & Engine, Adhyayan & Utsav, Payments, Credits & Reconciliation, Accounts, Identity & Authentication.

Raj Pravas is a staff-run car and bus operation between the Research Centre and Mumbai-area points. The member app collects a travel booking. Staff decide whether to run the trip, set a fare when needed, plan the route, and manage vehicle groups in the staff panel.

The travel-team process below is the actual operating flow. A separate travel pull request carries the matching software work. This page states any difference in the current main branches under Known limitations today.

Staff roles for travel¶

Role	What the staff panel offers
Super admin, travel admin	The travel list and status changes, the driver list, bus group management, and the coordinator sign-in page
Driver travel role	The driver list only
Travel coordinator	No staff account. A member who signs in with a one-time code on the coordinator page (see Coordinator access and boarding)

The backend lets the driver travel role use every travel staff action, the same as a travel admin. Only the staff panel limits that role to the driver list (see Known limitations).

Who can request travel¶

A member can request travel for themselves or for one or more Mumukshus.
A member can request travel for a guest.
A guest account can request travel only for itself.
The unified member booking flow can use travel as the main booking or as an add-on to a room, flat, meal, Adhyayan, or Utsav booking.
The guest booking flow can use travel as a main booking for itself.

Booking rules¶

Exactly one of the pickup and drop points must be the Research Centre.
A person can have one active booking in each direction on the same date. The backend counts awaiting confirmation, waiting, and confirmed bookings as active. A booking in proceed for payment does not count (see Known limitations).
A booking is Regular or Full Car. Full Car requires the number of people and asks for the Centre's owned car in the travel-team process.
A trip can be one-way or a linked round trip. A round trip has an onward date and a return date, with the return leg using the reverse direction.
The member app requires a luggage choice.
The member app requires an arrival time for airport and railway-station travel.
The member app requires a comment when the member selects Other as a point.
The member app uses a different point list during an Utsav.
The member app shows Leaving post Adhyayan only for a trip that starts at the Research Centre. The answer is self-reported.
The staff travel list shows Leaving post Adhyayan as yes when the member answered yes, or when the traveler has a confirmed Adhyayan booking that ends on the travel date. If staff set the answer to yes and no such booking exists, the staff panel warns them before it saves.
The backend rejects a date before the current date.
The booking creates no travel charge. Staff set a fare later when they move the booking to payment.

Pickup and drop points¶

On ordinary days, the member app offers the Research Centre, Dadar, Amar Mahal, Airoli, Vile Parle, airport terminals, Bandra Terminus, Kurla Terminus, CSMT, Mumbai Central, Navi Mumbai Airport, and Other.

During an Utsav, the member app offers an Utsav-specific list that includes the Research Centre, Dadar Pritam Da Dhaba, Amar Mahal, Borivali, Mulund, Vile Parle, airport terminals, Bandra Terminus, Kurla Terminus, CSMT, Mumbai Central, and Other.

The member app uses the Utsav list when the chosen travel date falls within the dates of a Research Centre Utsav that has not ended (member app and backend). The Utsav list has no Airoli or Navi Mumbai Airport, and the ordinary list has no Borivali or Mulund.

Other requires a location comment.

How staff decide and run a trip¶

This section describes the current travel-team process. The system records bookings and assignments, but it does not enforce every operating decision in this section.

Fleet and Full Car decisions¶

The Centre has one owned car.
Staff hire 20-seat or 35-seat vehicles when demand requires more capacity.
Staff can use hired vehicles on ordinary days as well as during events.
A typical Adhyayan has up to 20 to 25 travel bookings.
Full Car bookings and shared bookings compete for the one owned car.
If a Full Car booking is already committed, staff can cancel shared bookings for that trip.
If two or three shared bookings were confirmed first, staff can cancel the later Full Car booking.

Demand threshold and route¶

Staff want at least 2 bookings before they send a vehicle.
Staff often wait for 3 total bookings before they commit.
The count covers both directions on the date, not one direction or one pickup point.
Staff draft the stop sequence while they check demand and capacity.
A route can assign every booking whose pickup and drop points fit the stop order.
Staff can also assign one booking, a batch, or a spreadsheet of bookings by hand.
Capacity is a planning limit that staff can override.

Three pickup sequences recur in the travel-team process:

Dadar to Amar Mahal to Airoli to the Research Centre.
Borivali to Vile Parle to Amar Mahal to the Research Centre.
Airoli to the Research Centre when Airoli has enough demand on its own.

Staff may skip Airoli after Amar Mahal when the added travel time is not justified. Those travelers can meet the vehicle at Amar Mahal. Staff choose the final route from the bookings for that date.

If the threshold is not met about one day before travel, staff can cancel the bookings and tell the members to arrange their own travel or book a Full Car.

Booking status and staff review¶

The backend creates a new travel booking with the status awaiting confirmation. Staff review the booking and aim to confirm the trip at least 24 hours before travel. Staff can then:

move it to proceed for payment and create a payment amount,
mark it confirmed when no payment is needed or payment is complete, or
cancel it as a staff cancellation, optionally recording seats full or wrong form as the reason. Only the member can make a member cancellation.

The staff panel can filter travel bookings by date, direction, status, and cancellation reason. A confirmed booking can also be assigned to a bus group. Confirmed means that the travel-team process has committed a vehicle for the traveler.

Staff can change the status of many bookings at once. They select rows in the travel list, can see the selected travelers' names, and enter the new status, charge, and comment once. A batch holds up to 100 bookings. Each booking is updated on its own, with the same rules and notifications as a single update. A booking whose update fails does not stop the others. The backend returns each failure with its reason; the staff panel shows only how many bookings succeeded and failed.

Staff can add or edit a comment on a travel booking. The travel list also shows whether the traveler has breakfast booked on the travel date.

Status change rules¶

These rules apply to every staff status change, single or bulk (backend):

A change to the booking's current status is refused.
A cancelled or staff-cancelled booking cannot change again, with one exception: staff can turn a member's own cancellation into a staff cancellation, for example to give credit.
Staff cannot set waiting, awaiting confirmation, or a member cancellation.
Proceed for payment. The backend creates a travel charge for the fare staff enter. The charge is on the booker's card when someone else booked, otherwise on the traveler's card. A card from outside India gets a cash charge. The holder's travel credit is applied at once. If credit covers the whole fare, the booking becomes confirmed straight away. If the booking already has a charge, the backend reuses it and ignores the new fare; if that charge is paid, the booking becomes confirmed.
Confirmed. Any unpaid charge, online or cash, is marked paid, with the description staff enter.
Staff cancellation. The staff panel asks whether to give credit only for a plain staff cancellation (see Cancellation and waitlisted bookings).
Any cancellation takes the booking off its bus group, clears it as coordinator, and can promote the oldest matching waiting booking.

Two older status pages still exist in the staff panel but no menu links to them. One sends "Cancelled as wrong form filled" as a plain staff cancellation without a reason or a credit choice. The other cancels the charge of a waiting or confirmed booking under the staff credit rules, whatever status staff pick, and leaves the booking status unchanged. It sends no message.

Editing a booking¶

From the travel list, staff open an edit form for one booking (staff panel and backend). They can change:

the fare on the existing charge, whatever its payment state. No message is sent;
the pickup point, drop point, type, travel date, and Leaving post Adhyayan answer;
the staff comment;
the bus group, from the groups on the booking's date. A full group is refused; the staff panel then offers to raise the group's capacity and tries again;
whether the booking is the group's coordinator. The booking must be a passenger on the chosen group. Setting it to no clears it as coordinator.

If a change of date, pickup, or drop means the booking no longer fits its group's date or end point, the backend removes it from the group, then places it on the group staff selected, if any. When no group is selected and another group runs on the new date with the same end points, the staff panel offers to move the booking there, raising that group's capacity if it is full.

The backend does not repeat the booking checks on an edit, such as one end at the Research Centre or one booking per direction and date.

The travel list, summary, and downloads¶

Travel admins and super admins open the upcoming travel bookings screen (staff panel). It shows today and tomorrow by default.

Filters. A date range; any of confirmed, proceed for payment, awaiting confirmation, waiting, member cancellation, staff cancellation, wrong-form cancellation, and seats-full cancellation; pickup at the Research Centre; drop at the Research Centre.
Summary. A count of bookings per direction (Mumbai to the Research Centre, the Research Centre to Mumbai, or other) and status, with the two cancellation reasons shown separately (backend).
The list. Each row shows the travel date and booking date, the traveler's name and mobile number with a WhatsApp chat link, type, pickup and drop (an Other point shows the member's comment instead), the group's stop time, the group name, whether the traveler is coordinator, arrival time, Leaving post Adhyayan, breakfast booked, status, the member's comment, number of people, fare, payment status and date, booking number, booker, staff comment, luggage, and direction. Trips from the Research Centre are highlighted.
Bus summary. A view of the loaded bookings that are not cancelled, grouped by date, direction, and bus group (or unassigned). It shows each group's capacity, confirmed and proceed-for-payment counts, total, and remaining seats.
Download. The list downloads as a spreadsheet.

Driver list¶

Drivers, travel admins, and super admins see the driver list (staff panel and backend).

It shows confirmed bookings for today. After 8 PM IST it shows tomorrow's.
It has two tables, Mumbai to the Research Centre and the Research Centre to Mumbai, each with the date, the traveler's name and mobile number, and the pickup or drop point. All Dadar spellings show as one Dadar point. An Other point shows the member's comment.
Each table is ordered Dadar, Amar Mahal, Airoli, then the other points.
The list downloads as a spreadsheet.

Bus groups¶

The staff panel can create a bus group for a date. A group has a name, an ordered list of stops, stop times when available, a capacity, and staff notes. Navi Mumbai Airport is available as a group stop, and as a pickup or drop point when staff edit a booking.

When staff create a group, the system can match and assign same-date travel bookings whose pickup and drop points fit the stop order. The match covers confirmed and proceed-for-payment bookings. Staff can review capacity, force a group when capacity is not enough, assign or remove passengers, and use bulk staff tools.

The system has no vehicle-class field. A group name does not prove that the vehicle is a bus, an owned car, or a hired vehicle. Full Car is a booking label only.

After assignment, the member app can show the group name, the pickup-stop time, and the coordinator details when those values exist.

Creating and editing a group¶

Checks (backend). A group needs a date, a name, and at least 2 stops. Two groups on the same date cannot share a name. Each stop time must be later than the one before.
Matching (backend). A booking fits a group when it is confirmed or proceed for payment on the group's date, and its pickup point comes before its drop point in the stop list. Point names must match, ignoring capitals and spaces at the ends.
Preview (staff panel). Before creating, staff see every fitting booking, marked if it is already on another group. They can untick bookings, then create the group and assign the ticked bookings, or create it without passengers. A ticked booking that is on another group moves to the new one; an unticked one stays where it is.
Capacity. If more bookings fit than the capacity, the backend does not create the group. The staff panel offers to raise the capacity to the number that fit, then staff create it again.
Editing. Staff can change the name, stops, stop times, capacity, and notes, but not the date. Before saving, the staff panel shows which bookings would newly fit and which current passengers would no longer fit. Staff can remove passengers who no longer fit, and add newly fitting bookings that are on no group, up to the free seats.
List (staff panel). The bus group screen lists every group, newest date first, with its stops and times, capacity, and passenger count.

Adding and removing passengers¶

On a group's detail page (staff panel and backend):

Staff see the group's stops and times, capacity, coordinator, and passengers with their pickup, drop, status, and number of people.
Adding. Staff pick from bookings on the group's date that are confirmed or proceed for payment, go the same direction, and are on no group that day. If the total would pass the capacity, the staff panel asks to raise it first. The backend refuses the whole selection if any booking is already on a group.
Removing. Removing a passenger also clears them as coordinator when they held that place.
Coordinator. Staff mark one passenger as the group's coordinator. A group has one coordinator; a new one replaces the old.

Spreadsheet uploads¶

One group. Staff upload a sheet with a booking number column and a coordinator column (yes for the coordinator). The preview marks each booking as valid, already on a group, invalid (not found, or not confirmed or proceed for payment), wrong date, wrong route, or over capacity. Staff then assign the valid bookings up to the free seats, and the marked coordinator.
Many groups at once. Staff upload a workbook with a sheet of groups (group name, date, capacity, stop order, stop name, and time) and a sheet of assignments (booking number and group name). The preview flags, per group: a missing time, fewer than 2 stops, no Research Centre stop, an empty or repeated stop, a stop outside a fixed list, and a group that already exists for that date. It also lists valid passengers up to the capacity, overflow passengers, bookings not found or off the route, and bookings already on a group.
Importing many groups. Staff cannot import while existing groups clash, unless they tick "update existing". The import is all or nothing: a stop time out of order, a missing time, or a stop outside the fixed list stops the whole import. A clashing group is skipped, or with "update existing" its stops and capacity are replaced and its coordinator is cleared. Bookings already on a group are never moved.

Export and delete¶

Export. Staff download a group's passengers as a spreadsheet with name, mobile number, pickup, drop, status, luggage, comments, boarded, and coordinator.
Delete. Deleting a group removes its stops and passenger list. The bookings themselves do not change, and no message is sent.

Coordinator access and boarding¶

Staff can assign one coordinator booking to a bus group. When staff mark a coordinator on a single booking, the booking must already be a passenger in that group; otherwise the system refuses it. In the current travel-team process, the coordinator role applies to buses. The coordinator receives a one-time code through WhatsApp and can access the coordinator view after verification.

The code expires after 5 minutes.
The coordinator session lasts 7 days.
The coordinator can view assigned groups, ordered stops, passengers, pickup and drop points, luggage, comments, and boarding state.
The coordinator can mark a passenger as boarded and record the boarding time.
The coordinator cannot change fares, routes, capacity, or booking status.

Signing in (backend and staff panel). The coordinator opens the coordinator page in the staff panel. It needs no staff account.

The mobile number must belong to a card that has a travel booking and is the coordinator of a group dated today or later. Otherwise the code is refused.
The code has 6 digits. A mobile number can request at most 5 codes in 10 minutes.
After 5 wrong tries, the latest code is blocked and the coordinator must request a new one.
The staff panel keeps the session only in that browser tab.

The coordinator view (staff panel and backend).

It covers every group dated today or later where the person is coordinator. With several, the coordinator chooses one.
It shows the group's stops and times, capacity, remaining seats, and how many passengers have boarded and are still to board.
Each passenger shows name, mobile number with call and WhatsApp links, pickup and drop, the stop time, luggage, comments, and boarding state and time.
The coordinator can search passengers and filter to boarded or still to board.
The coordinator marks a passenger as boarded, or undoes it, which clears the boarding time. The coordinator can also scan a passenger's card QR code to mark them boarded. A card that is not on the list, or is already boarded, is refused.
Only the group's own coordinator can change its boarding states (backend).

The current travel-team process uses one coordinator per bus. A separate travel pull request covers a coordinator for each stop. The current main-branch data model does not support a separate coordinator for each stop or a rule that limits coordinators to a vehicle class.

What the member sees after booking¶

The member app lists the travel bookings that are for the member or that the member made for someone else, newest date first, 10 at a time (member app and backend).

Upcoming bookings show first. Past bookings are behind an "old bookings" toggle.
Each booking shows the date, points, type, status, and any fare and payment status.
When the booking is on a bus group, the member can open the group details: the group name, the time at the group's stop that matches the pickup point, and the coordinator's name and phone number.
The Cancel button shows only for a travel date after today, and only when the booking is not already cancelled (member app). Paying a proceed-for-payment fare follows Payments, Credits & Reconciliation.

Cancellation and waitlisted bookings¶

A member can cancel an awaiting-confirmation, confirmed, proceed-for-payment, or waiting travel booking.
When a member cancels, a completed payment is not refunded and does not become credit. This is a product decision, confirmed on 2026-09-30. Credit that was applied to an unpaid booking goes back to the member who paid.
When staff cancel a booking as a staff cancellation, they choose whether to issue credit. With credit, the amount paid, or the credit applied to an unpaid booking, becomes travel credit. Without credit, a paid booking keeps its payment with no refund, and credit applied to an unpaid booking goes back to the member who paid.
Staff cancellation can record seats full or wrong form as the reason. In the staff panel, both are sent as a staff cancellation with the reason added to the staff comment and no credit. The credit choice is hidden for them. So a paid booking keeps its payment with no credit, and credit applied to an unpaid booking goes back to the member who paid. The backend has separate seats-full and wrong-form statuses that always give credit, but the staff panel does not use them (see Known limitations).
A staff cancellation takes the booking off its bus group and clears its coordinator link when needed. A member cancellation does this only when the booking has a charge (see Known limitations).
A cancellation can promote the oldest matching waiting booking to awaiting confirmation. The match is a waiting booking on the same date in the same direction. A member's cancellation of a waiting booking promotes nothing.

The normal member travel-create path in the current main branch does not create waiting bookings. It creates awaiting-confirmation bookings and returns a waiting count of zero. The separate travel flow includes the waiting and promotion process.

Travel messages¶

WhatsApp¶

A new booking from the member app is always awaiting confirmation, so it sends one of these (backend):

Who booked	Recipient	Content
The traveler, for themselves	The traveler	Awaiting confirmation, with pickup, drop, number of people, and date
Someone else	The booker	The same, naming the traveler
Someone else	The traveler	The same, naming the booker

The backend also has a booked message and a waiting message for new bookings, but no current path creates a new travel booking in those statuses.

Status changes by staff, by the member, or by a completed payment send (backend):

Change	Traveler	Booker, when someone else booked
Awaiting confirmation to proceed for payment	Payment request, with a separate version for a card outside India. Sent only when the traveler booked for themselves	Payment request naming the traveler, with a separate version for a card outside India
Awaiting confirmation or proceed for payment to confirmed	Confirmed, with the date, points, and payment reference	Confirmed, naming the traveler
Awaiting confirmation to staff cancellation	Cancelled by staff, with separate wording for wrong form and for seats full	The same, naming the traveler
Proceed for payment to staff cancellation	Cancelled by staff	The same, naming the traveler
Awaiting confirmation, proceed for payment, or confirmed to member cancellation	Cancelled	Cancelled, naming the traveler
Confirmed to staff cancellation	Cancelled by staff. Includes the credit amount only when credit was given and the traveler booked for themselves	Cancelled by staff, with the credit amount when credit was given
Member cancellation to staff cancellation with credit	Credit given, with the amount. Sent only when the traveler booked for themselves	Credit given, naming the traveler

No WhatsApp is sent for a change from or to waiting, a promotion from waiting, a booking edit or fare change, a bus group assignment or removal, or a coordinator assignment. The coordinator's one-time sign-in code is also sent by WhatsApp.

Email and push¶

Event	Email	Push
Booking made in the member app	The booking email has a travel section: each booking's number, name, date, points, and status, and the standard pickup points and times. Mumbai pickups: Dadar Swaminarayan Temple 8:00 AM (7:30 AM in an Adhyayan), Amar Mahal 8:20 AM (7:40 AM), Mulund–Airoli Junction 8:40 AM (8:00 AM). Borivali and Vile Parle times come from the team. The Research Centre departure is from reception at 1:00 PM, or per the Adhyayan schedule. Timings during an Utsav come separately. It also gives the driver's contact for the travel day, the car, and a guidelines link. The traveler and the booker each get it. In production, the travel team's mailbox gets a copy for each traveler	None
Staff change a status	Status update email to the traveler, with the new status, booking details, status definitions, and the standard pickup section. A staff cancellation shows "cancelled because all seats were booked", "cancelled because of wrong form filled", or "cancelled by admin"	To the traveler: the new status. To the booker, if any: the traveler's new status
A waiting booking is promoted	Status update email to the promoted traveler, copied to the booker	None
Member cancels	Cancellation email to the member who cancelled, copied to the travel team's mailbox in production	To the other person on the booking: the traveler or the booker

Planned travel improvements¶

Add a coordinator at each stop instead of one coordinator for the full bus.
Send a WhatsApp reminder when an Utsav traveler says they need travel but has not booked it.
Detect when one family member has booked travel and another has not.
Show a reliable time to leave in the member app.
Check the member's actual Adhyayan booking in the member app instead of relying on the self-reported Leaving post Adhyayan answer. The staff travel list already checks it.

Known limitations today¶

The current main-branch guest booking flow does not yet contain the guest travel flow described above. The separate travel pull request covers it.
The member app checks luggage, airport and railway arrival time, Other comments, point lists, Full Car people count, and some form combinations. The backend does not repeat every one of these checks.
The current main-branch flow does not yet contain the linked round-trip flow described above. The separate travel pull request covers it.
Full Car does not select or reserve a specific vehicle. The system does not distinguish a car from a bus.
The backend has a waiting-promotion helper, but the current travel-create path does not place bookings in waiting status.
The staff panel offers Awaiting Confirmation for Payment as a new status in both the single and the bulk status forms, but the backend rejects it. Staff cannot move a booking back to awaiting confirmation.
Fleet size, vehicle choice, demand thresholds, route preferences, and manual cancellation targets are current travel-team practice. The backend does not enforce them as software rules.
Seats-full and wrong-form cancellations give no credit from the staff panel. The panel sends them as a plain staff cancellation without credit. In the single-booking form, the reason is added only when the staff comment box is empty, and the form starts with the booking's existing comment. So a booking that already has a comment loses the reason, and the traveler gets the plain staff-cancellation messages.
A member's cancellation of a booking with no charge leaves it on its bus group. The passenger stays on the group list, the coordinator view, and the export, and keeps any coordinator place.
Member travel cancellation trusts the booking number. The backend does not check that the member who cancels is the traveler or the booker, or that the travel date has not passed. Only the member app hides the Cancel button on and after the travel date.
A proceed-for-payment booking does not block a second booking. The one-booking-per-direction check skips proceed for payment.
Confirming marks an unpaid charge as paid. When staff confirm a booking whose online or cash charge is unpaid, the backend records the charge as paid, whether or not money arrived.
A member-cancelled booking cannot be turned into a staff cancellation without credit. Staff can turn a member's cancellation into a staff cancellation only with credit. For an unpaid booking that credit is only what was applied and not yet given back, often nothing.
The driver travel role reaches every travel staff action in the backend. Only the staff panel limits it to the driver list.
Some points fall out of the driver list and summary. The driver list leaves out trips to or from Navi Mumbai Airport and the Utsav points Dadar Pritam Da Dhaba, Borivali, and Mulund. The summary counts Navi Mumbai Airport trips under "other".
The many-groups spreadsheet rejects Navi Mumbai Airport. Its fixed stop list does not include it, though the group form offers it.
The many-groups import checks less than its preview. It assigns bookings without checking their status or date, and creates a group that the preview flagged for having no Research Centre stop or fewer than 2 stops.
A spreadsheet can set a coordinator who is not on the bus. Both upload paths accept the coordinator named in the sheet even when that booking was not assigned.
Bulk status failures are not listed. The staff panel shows only the number of failed bookings, not which ones or why.
The status emails define a staff cancellation as non-payment. Their status definitions describe every staff cancellation as cancelled for non-payment.
The booker's push title always says cancelled. On any staff status change, the booker's push is titled as a cancellation, even when the booking is confirmed.