design

src/api/customers.ts

@@ -29,6 +29,24 @@ export interface CustomerInfo {
   deliverylocationid?: number;
   tenantlocationid?: number;
   applocationid?: number;
+  /**
+   * Where the customer is, as text — the column type in `app_customers`.
+   *
+   * Sent by `gettenantcustomers` on 97% of rows (measured across 31 customers
+   * at 7 shops, 2026-09-15) and simply absent from this interface until now, so
+   * the one nearly-complete piece of geography the backend has about a shop's
+   * customers was invisible to every page.
+   */
+  latitude?: string;
+  longitude?: string;
+  /**
+   * Empty on every customer row on the platform — 0 of 31.
+   *
+   * Kept declared because the column exists and a future write could fill it,
+   * but nothing should render an Active/Inactive state from it: a badge that
+   * reads the same on every row is decoration, and one that reads blank is
+   * worse.
+   */
   status?: string;
 }
 

src/api/people.ts

@@ -140,11 +140,23 @@ export const posUsersApi = {
    * non-array and hands back `[]`, so the page showed "no till accounts" for a
    * shop that had them. Same shape trap as `/health/location`.
    */
-  list: (tenantid: number, locationid: number) =>
+  list: (tenantid: number, locationid: number, includeInactive = false) =>
     api
       .get<{ location_id?: number; users?: PosUser[] }>(`${WEB}/tenants/getposusers`, {
         tenantid,
         locationid,
+        /*
+        Off by default, because that is what every existing caller assumed.
+
+        The listing excludes inactive accounts unless asked
+        (`posUserRepository.go:494` — `LOWER(COALESCE(a.status,'active')) <>
+        'inactive'`), and `WebListPosUsers` reads `include_inactive` from the
+        query string. Nothing sent it, which had two consequences: a supervisor
+        who switched a cashier off in the drawer watched them disappear from the
+        list with no trace and no way back, and any Status column could only
+        ever render "Active" because that was the only status a row could have.
+        */
+        ...(includeInactive ? { include_inactive: 'true' } : {}),
       })
       .then((page) => (Array.isArray(page?.users) ? page.users : [])),
 

src/api/tenants.ts

@@ -44,6 +44,31 @@ export interface CreateTenantRequest {
 /** Everything the branch-onboarding form collects. */
 export interface CreateBranchRequest {
   tenantid: number;
+  /**
+   * The delivery region, inherited from the tenant's existing outlets.
+   *
+   * `tenantlocations.applocationid` has no column default, so a create that
+   * omits it stores 0 — and `resolveOfflineLocationContext` in
+   * `orderRepository.go` calls this column "authoritative", with no fallback
+   * anywhere for a zero. It is also copied straight onto the login the backend
+   * spawns for the branch, so the outlet AND the person running it both end up
+   * in no region at all.
+   *
+   * Measured 2026-09-15: 43 of 75 live branches carry 0. Regions are
+   * 1 = Coimbatore, 2 = Madurai, 23 = Nagercoil.
+   */
+  applocationid?: number;
+  /**
+   * Also inherited, and also without a column default.
+   *
+   * `orderRepository.go` documents the consequence in its own comment —
+   * "tenantlocations carries 0 for moduleid/partnerid at outlets whose live
+   * orders nonetheless use non-zero values" — and works around it by copying
+   * the scaffolding off the most recent real order at that outlet. A branch
+   * commissioned five minutes ago has no such order, so the workaround has
+   * nothing to copy and the joins are left to resolve against a zero.
+   */
+  moduleid?: number;
   locationname: string;
   email?: string;
   contactno?: string;