Skip to content

The phone app (staff ERP on a phone)

The ERP laid out for one hand: /m. The same data and the same rules as the desktop — every screen calls the routes the desktop calls and the database decides — but only the jobs people do on the move: find, approve, take a payment, see a departure, count heads. Setup, finance configuration and reports stay on the desktop.

Routes: /m (home), /m/bookings, /m/bookings/:id, /m/approvals, /m/customers, /m/groups, /m/more, /m/notifications. Staff only (allowedRoles admin and staff); each screen is gated on the permission the desktop screen needs. Rule PLT-060.

The Android app opens /m. A phone-sized browser lands on /m too; More → Open the full desktop ERP switches that phone to the desktop layout until it is switched back (/app?desktop=0).

This web phone layout stays. The native app (apps/mobile, decided 2026-09-25) is a separate build with its own screens: the staff ERP, the tour leader's stack and a traveller's portal. Both call the same database functions; a member of staff may use either. The Capacitor shell described on the Android page still opens /m.

Screens

Home. A search box (booking number, name, passport, phone), three counts (approvals waiting for the sales check, waiting for finance, jobs in my inbox — each only if the person holds the permission), the departures in the next 30 days with visa / ticket / rooming progress (dash_departures), and what needs my decision (dash_approvals_inbox). All of it, and the bell's unread count, arrives in one request — dashboard_screen('phone') (PRF-002, API); reopening the home shows the last answer at once and refreshes it behind the scenes.

Bookings. The desktop's paged list (booking_page, keyset paging, 30 a page) as cards: name, booking number, departure, partner, total and balance, status chip. Filters: all, pending, approved, needs correction, cancelled. A booking finance has not approved yet shows Awaiting finance approval — ₹X will be due in amber in place of a ₹0 balance (FIN-033). A New booking button opens the wizard for those with bookings.create.

Booking. Who, the departure, total / paid / balance, the travellers, the emergency contact (INC-005) — before finance approves the booking voucher, Awaiting finance approval — ₹X will be due under the figures (FIN-033) — and:

  • Receive payment (finance.payments.record): a sheet with the amount (the full agreed due — full balance, or all that will be due before approval — and half as one-tap chips), the method, the reference (required for anything but cash), the received date, and a note. Recorded as pending; another finance user verifies it (FIN-032).
  • Approve / Send back (approvals.approve): the sales check on a PENDING_OPS booking, or finance on a PENDING_FINANCE one. Send back needs a reason. Maker-checker holds: you cannot approve a booking you created.
  • Open the departure: the group screen shared with the tour leader.

Lists page (PLT-050). Bookings, Customers and both approval queues load 30 at a time with Show more; Customers and the queues say how many of how many. Customers used to show the first 30 and the queues the first 50, with nothing to say more existed.

Approvals. Two queues — sales check (PENDING_OPS) and finance (PENDING_FINANCE) — each card with approve and send back.

Customers. Search by name, phone or passport; a call button on every row; the name opens Customer 360.

Groups. Upcoming, travelling now, all. A group opens the tour leader's screen (field app: people, rooms, plan, log, SOS), which answers staff with groups.view for any group.

More. Who is signed in, customers, my work, the tour-leader app, notifications, security, the desktop, sign out.

Notifications. The switch for alerts on this phone or browser, the inbox — every notification sent to this login, kept (TRV-010): unread in bold with a dot, a tap marks it read and opens the screen it is about, "Mark all read", the latest fifty — and the counts the desktop badges use. The bell in the app bar and the Notifications row on More carry the unread count.

Notifications

Alerts are sent when a booking is submitted for approval, approved, sent back, or a cancellation is requested or decided (the same events as the desktop; see Communications).

  • In a browser (Chrome on Android, desktop): Web Push, as before. Switch on under More → Notifications.
  • In the Android app: the WebView has no Web Push, so the app registers with Firebase Cloud Messaging. On first open it asks for permission and stores the device token as a push_subscriptions row with the endpoint fcm:<token>; push-send delivers to those rows through FCM's HTTP v1 API using the FCM_SERVICE_ACCOUNT_JSON secret. A tap on the notification opens the screen it is about. Set-up steps: Android app → Notifications.

Until Firebase is configured the app runs normally; only the alerts are off, and the switch says so. Whatever the delivery, the notification is kept in the inbox (AppNotification, one row per login) — see Communications → Notification inbox.

Not built

  • The phone layout for the rest of the ERP: inventory, finance vouchers, reports, settings. Those open the desktop layout on a phone.
  • Alerts for events other than approvals and cancellations (a new enquiry, a WhatsApp message, a job assigned, a missing traveller). They are counted on the Notifications screen, not pushed.
  • A phone-first sign-in screen: the sign-in page is the desktop card, which fits a phone.