Raj Pravas (Travel)¶

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

Raj Pravas is a staff-run car and bus operation between the Research Centre and Mumbai-area points. The member app collects a request. 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.

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.

Request rules¶

Exactly one of the pickup and drop points must be the Research Centre.
A person can have one active request in each direction on the same date. Active requests include awaiting confirmation, waiting, pending payment, and confirmed.
A request is Regular or Full Car. Full Car requires the number of people and represents a request 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 backend rejects a date before the current date.
The request creates no travel charge. Staff set a fare later when they move the request to payment.

Pickup and drop points¶

On ordinary days, the 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 app offers an event-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, Navi Mumbai Airport, and Other.

Other requires a location comment.

How staff decide and run a trip¶

This section describes the current travel-team process. The system records requests 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 requests.
Full Car requests and shared requests compete for the one owned car.
If a Full Car booking is already committed, staff can cancel shared requests for that trip.
If two or three shared bookings were confirmed first, staff can cancel the later Full Car request.

Demand threshold and route¶

Staff want at least 2 requests before they send a vehicle.
Staff often wait for 3 total requests 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 request whose pickup and drop points fit the stop order.
Staff can also assign one request, a batch, or a spreadsheet of requests 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 requests for that date.

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

Request status and staff review¶

The backend creates a new travel request with the status awaiting confirmation. Staff review the request 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 member cancellation, staff cancellation, seats-full cancellation, or wrong-form cancellation.

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

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.

When staff create a group, the system can match and assign same-date travel requests whose pickup and drop points fit the stop order. The match covers confirmed and proceed-for-payment requests. 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 request label only.

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

Coordinator access and boarding¶

Staff can assign one coordinator booking to a bus group. 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.

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.

Cancellation and waitlisted requests¶

A member can cancel an awaiting-confirmation, confirmed, proceed-for-payment, or waiting travel request.
A travel cancellation does not create an automatic refund or member credit for a completed payment. Staff can issue a credit as a separate decision.
Staff can cancel a request and can choose to issue a credit.
Staff cancellation can record seats full or wrong form as the reason.
Cancellation removes the booking from its bus group and clears its coordinator link when needed.
A cancellation can promote the oldest matching waiting request to awaiting confirmation.

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

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 registration instead of relying on the self-reported Leaving post Adhyayan answer.

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 requests in waiting status.
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.