Screen-by-screen build specification derived from the Partner App BRD v0.2. Every screen, field, state, validation rule and admin-side dependency that will be built, written so it can be signed off before development begins.
The app is organised into ten modules. Each module below carries its screens in build order. For every screen you get four things: a low-fidelity wireframe showing layout and hierarchy, a field table listing every input with its type and validation, the screen's states (empty, loading, error, locked), and the business rules the screen enforces.
Wireframes are structural sketches, not visual design. They fix what appears on a screen and in what order. Final visuals follow the existing Vandan app theme — rust primary #B94508, warm surface #FFF7F1, 12px card radius, 52px primary buttons — so the Partner App reads as part of the same family as the customer app.
Screen titles and labels are given in Marathi, as the app will ship, with the English meaning alongside for review. Every screen carries an ID (P1.2, A3.1) for use in review comments, QA test cases and development tickets.
Ten Partner App modules and one Admin Panel module. Screen counts are the screens specified in this document.
A five-item bottom navigation bar, matching the customer app's bar (white surface, rust selected state, 11px labels). The notification bell sits in the app bar on every tab with an unread count badge.
| Tab | Lands on |
|---|---|
| डॅशबोर्ड Dashboard | P5.1 — stats, milestone, next puja |
| पूजा Puja feed | P2.1 — open pujas in my city |
| माझ्या पूजा My pujas | P3.1 — four status tabs |
| आमंत्रण Amantran | P6.1 — my requests + invites to me |
| प्रोफाइल Profile | P1.5 — profile, settings, support |
A Partner's profile is both their identity on the platform and the input to allocation. City drives which pujas they see; puja types, rating and Preferred tag drive whether they are ranked Best Fit. The profile is therefore gated: nothing else in the app opens until it is complete and Admin has approved it.
First launch only. Marathi is preselected; the toggle exists so a Partner who taps English by mistake can recover. Choice is stored on device and mirrored to the profile record.
| Default | मराठी selected, पुढे चला enabled |
| No network | Inline retry strip; language choice still persists locally |
| Force update | Non-dismissible sheet, store deep link |
Single entry point for both registration and returning login — the same number is the account identifier. No password anywhere in the app.
| Field | Type | Validation |
|---|---|---|
| मोबाईल क्रमांक | Numeric, +91 fixed | Exactly 10 digits, first digit 6–9. Mandatory. |
| OTP | 4-digit, auto-read on Android | Valid 10 minutes. Resend after 30s, max 3 per 15 min. |
| New number | → P1.3 profile form, step 1 |
| Profile incomplete | → P1.3 at the first unfinished step |
| Complete, awaiting approval | → P1.6 approval pending |
| Approved | → P5.1 dashboard |
| Blocked by Admin | → Blocked screen with office contact number |
Split into four steps so the form never feels long: identity, address, credentials, documents. Each step saves on continue, so a Partner can leave and resume. A step is marked done only when its mandatory fields pass validation.
| Label (Marathi) | Type | Rule |
|---|---|---|
| नाव * Full name | Text | 2–60 chars, Devanagari or Latin |
| जन्मतारीख * Date of birth | Date picker | Age 18+; future dates blocked |
| मोबाईल क्रमांक * Mobile | Prefilled, read-only | From OTP login; change only via Admin |
| पर्यायी मोबाईल क्रमांक Alternate mobile | Numeric | Optional, 10 digits, must differ from primary |
| प्रोफाइल फोटो * Profile picture | Camera / gallery | JPG/PNG, ≤5 MB, cropped square, compressed on device |
| संपूर्ण निवासी पत्ता * Residence address | Multiline, 10–200 chars |
| शहर * City | Searchable picker from the Admin city master — reuses the customer app's city picker. Direct input to allocation. |
| उपशहर * Sub-city | Dependent picker, filtered by city. Used for the 10 KM Best-Fit test, so it carries a geo-coordinate from the master. |
| पिनकोड * Pincode | 6 digits, validated against city where master data allows |
| शाखा * Shakha | Single select: ऋग्वेद, यजुर्वेद, सामवेद, अथर्ववेद |
| वेदिक अध्ययन * Vedic Adhyayan | Text — institution / guru / years studied, 200 char limit |
| यज्ञिकी अनुभव * Years of experience | Numeric 0–70; shown on Amantran candidate cards |
| नियमित पूजा प्रकार * Regular puja types | Multi-select from the puja master (P1.4). Minimum one. |
| खातेदाराचे नाव * Account holder | Text, 2–60 chars |
| खाते क्रमांक * Account number | 9–18 digits, entered twice to confirm, masked on display |
| IFSC * | 11 chars, format AAAA0XXXXXX; bank name auto-filled where lookup available |
| पूजांचे फोटो Photos of pujas performed | Optional, up to 10 images, ≤5 MB each; feeds profile completeness and the Amantran candidate view |
Opened from step 3 and editable any time afterwards. The list is the Admin puja master, grouped by category, so a new puja type added in the Admin Panel appears here without an app release.
| Source | Admin puja master, grouped by category, Marathi names |
| Selection | Multi-select, minimum 1, no maximum |
| Search | Matches Marathi and English name; results keep grouping |
| Effect | Used for Amantran matching and shown on the Partner's profile; the city puja feed is not filtered by it, per BRD allocation scope |
| Empty state | If the master fails to load: retry strip, जतन करा disabled |
The profile tab doubles as the completeness nudge. A ring shows the percentage; below it, only the incomplete items are listed, each a direct link to the field that is missing. Fuller profiles receive more requests, so this screen is deliberately insistent until it reads 100%.
| Group | Weight | Counts as complete when |
|---|---|---|
| Identity + photo | 25% | All step-1 mandatory fields saved |
| Address | 20% | City, sub-city, pincode, address saved |
| Credentials | 25% | Shakha, Adhyayan, experience, ≥1 puja type |
| Bank details | 20% | Holder, account, IFSC saved and confirmed |
| Puja photos | 10% | At least 3 photos uploaded |
Admin approval is the gate between a filled profile and a working app. Three states, each with a single clear message and one action.
| Trigger to pending | All mandatory fields saved — submission is automatic, there is no separate submit button |
| While pending | Partner can still edit; edits keep the profile pending |
| Changes requested | Admin writes a reason; it is shown verbatim to the Partner and pushed as a notification |
| On approval | Push notification; all five tabs unlock; Partner enters the city notification pool |
| Blocked | App restricted to a contact screen; existing assigned pujas are withdrawn by Admin first |
When Admin pushes a booked puja, every approved Partner in that city is notified and sees it in this feed — but with limited details only. The Partner's single action is to show interest. Admin decides who gets it.
A single scrolling list, newest push first. Every card carries exactly the six limited fields plus the remark — nothing that identifies the customer. Cards the Partner has already requested show a muted "मंजुरी प्रलंबित" state and stay in the list.
| Field | Notes |
|---|---|
| पूजेचे नाव Puja name | Marathi name from puja master |
| उपशहर, शहर Sub-city, city | No street, flat or landmark — sub-city granularity only |
| दिनांक व वेळ Date & time | Marathi date format, 12-hour time |
| दक्षिणा Offered Dakshina | Set by Admin; this figure caps the later claim |
| विशेष सूचना Remark | Free text from Admin, e.g. who arranges samagri |
| Scope | Pujas whose city matches the Partner's profile city. No puja-type filter. |
| Sort | Push time, newest first; allocated-to-other cards sink to the bottom |
| Card states | Open · मंजुरी प्रलंबित · इतर पंडितांना दिली · Cancelled & re-pushed (shown as open again) |
| Auto-removal | Pujas whose date has passed without allocation drop off the feed |
| Empty state | "सध्या तुमच्या शहरात पूजा उपलब्ध नाही" with a note that a push will arrive |
| Refresh | Pull to refresh; live update on socket event when app is foregrounded |
Tapping a card opens the same six fields at full size, plus the booking ID for reference. The sticky footer holds the single action. This screen exists so the Partner can read the remark properly before committing.
| Confirmation | Bottom sheet restating date, time and Dakshina, with होय, स्वारस्य आहे / रद्द |
| On submit | Puja moves to माझ्या पूजा → मंजुरी प्रलंबित; Admin is notified |
| Withdraw | Allowed while still pending — Partner can withdraw interest before Admin decides; Admin is notified |
| Clash warning | If the Partner already has an assigned puja that date, a warning appears — but interest is not blocked |
| Concurrency | If allocated to someone else mid-action, the screen reloads into the इतर पंडितांना दिली state and the action is refused |
| Who sees it | Every Partner in the city except the assigned one — including those who never showed interest |
| Notification | Partners who showed interest get a push telling them the puja is no longer open |
| Never shown | The name of the Partner it was allocated to, and any customer detail |
| Retention | Stays visible for 7 days, then drops from the feed; remains in माझ्या पूजा history if interest was shown |
| On cancellation | If the puja is later cancelled and re-pushed, the card returns to the open state for everyone (M9) |
Everything the Partner has a stake in, in four tabs. The assigned puja detail screen is the operational heart of the app: it changes shape three times — before the unlock, after the unlock, and after the puja date when the Dakshina claim opens.
| Tab | Contains | Card action |
|---|---|---|
| नियुक्त पूजा Assigned | Allocated to me, puja date not yet passed | Open P3.2; पेमेंट घ्या after unlock |
| मंजुरी प्रलंबित Approval pending | Interest shown, Admin has not decided | स्वारस्य मागे घ्या (withdraw) |
| पूर्ण झालेल्या पूजा Completed | Puja date passed; claim pending, claimed, or reconciled | दक्षिणा मागणी करा, or view invoice |
| रद्द झालेल्या Cancelled | Assignments cancelled by customer or by office request | View only, cancellation date shown |
| Counts | Live counts on each tab; नियुक्त shows a dot when a new assignment is unread |
| Auto-move | A puja moves नियुक्त → पूर्ण automatically once its date and time have passed; there is no "mark complete" action for the Partner |
| Amantran pujas | Pujas the Partner does as an Associate appear here too, badged सहाय्यक |
| Sort | Assigned and pending by puja date ascending; completed and cancelled descending |
Same screen, two data states. Before T-2 the customer block is a countdown; from T-2 it fills in, with the mobile number rendered only as a call button — never as readable text, never copyable.
| Unlocks at | 00:00 on the day two days before the puja date (puja on the 12th → unlock on the 10th) |
| Late assignment | If Admin assigns inside the 2-day window, details are available immediately on assignment |
| Notification | "पूजेचे संपूर्ण तपशील उघडले आहेत" push, deep-linked to this screen |
| Mobile number | Never rendered as text. कॉल करा opens the dialler with the number passed through; no copy, no share, not present in any list view |
| Re-lock | 24 hours after the puja, customer name, address and call button disappear; the puja stays in पूर्ण झालेल्या पूजा with puja data only |
| On cancellation | Customer details are revoked immediately, before the Partner is notified |
The Partner collects the customer's payment on Vandan's behalf by showing Vandan's QR code. Money goes to Vandan, not the Partner — the Partner's own money comes later through the Dakshina claim. The screen is deliberately plain so it can be held up to a customer.
| Availability | Enabled from the T-2 unlock until 24 hours after the puja; disabled and greyed before that |
| QR source | Vandan's collection QR, served from Admin settings. Where the payment gateway supports it, a per-booking dynamic QR carrying the amount and booking ID is used so reconciliation is automatic |
| Amount shown | The customer's payable amount from the booking — not the Partner's Dakshina |
| Partner declaration | पेमेंट मिळाले marks it collected-and-unverified. It is a declaration, not a confirmed receipt; Admin verifies against the gateway |
| Partial / cash | Partner may record a partial amount or note "रोख" (cash); both are flagged in the Admin reconciliation queue |
| Offline | QR image is cached so it displays without network; the declaration queues and syncs when connectivity returns |
| Share | QR शेअर करा sends the QR image over WhatsApp for customers not physically present |
The landing tab. Four numbers, one milestone, the next puja, and a route to the income report. Everything is derived — the Partner enters nothing here.
| Stat | Definition |
|---|---|
| पूर्ण झालेल्या पूजा | Count of assigned pujas whose date has passed and which were not cancelled. Includes Amantran pujas performed as Associate. |
| प्रलंबित नियुक्त पूजा | Assigned, date in the future. Interest-shown pujas are not counted here. |
| एकूण दक्षिणा | Sum of Dakshina actually paid and reconciled by Admin, lifetime. Claimed-but-unpaid amounts are shown separately as "प्रलंबित" on the income report, never added here. |
| या महिन्यात | Same basis, current calendar month by reconciliation date |
| Configured by | Admin only, in the Admin Panel. The Partner cannot set or hide a milestone. |
| Definition | Name, target amount or puja count, and whether it applies to all Partners or a selected list |
| Display | The nearest unachieved milestone only, one at a time, with remaining amount |
| On achievement | Celebration state plus a push notification; the next milestone takes its place |
| No milestone set | The card is omitted entirely — no placeholder |
| Presets | This month · last month · financial year (Apr–Mar) · custom |
| Custom range | Any from–to; to-date cannot precede from-date; maximum span 24 months |
| Line items | Date · puja name · booking ID · offered Dakshina · claimed · paid · expenses · status. Amantran rows are marked सहाय्यक. |
| Totals | Pujas, Dakshina received, Dakshina pending, expenses reimbursed |
| Export | Server-generated PDF with Vandan letterhead, Partner name and the range; shareable via WhatsApp. CSV as a second option for Partners who file returns. |
| Empty range | "या कालावधीत उत्पन्न नाही" and the download button is disabled |
A Partner-to-Partner flow that Admin does not sit in. The Principal raises a request, the platform matches and notifies suitable Partners, interested Associates apply, and the Principal approves one. After the puja both sides rate each other, and the Associate's Dakshina lands in their own dashboard.
The tab has two halves: requests I raised, and invitations sent to me. A Partner is both Principal and Associate depending on the row, so both live in one place.
| पूजा प्रकार * | Single select from puja master; drives matching |
| शहर, उपशहर * | Defaults to the Principal's own city; editable |
| दिनांक, वेळ * | Date must be today or later; past dates blocked |
| दक्षिणा * | Numeric, ₹100 minimum. Set by the Principal and paid by the Principal's arrangement — it is not capped by any Vandan booking |
| सूचना | Optional free text, 200 chars |
| Matched Partners receive a push immediately. The request stays open until the Principal approves someone or the date passes. A Principal may edit Dakshina or the note while open; editing re-notifies the matched set. Cancelling the request notifies everyone who had shown interest. |
Unlike the Admin allocation flow, here the Principal sees full candidate detail including the phone number — these are fellow Partners, not customers. Approval is single-choice and final.
| Identity | Name, profile photo, shakha |
| Rating | Overall average with rating count, or रेटिंग नाही |
| Experience | Years of Yadniki experience |
| Location | Sub-city and approximate distance from the puja sub-city |
| Feedback | Up to 3 most recent Amantran feedback comments received |
| Contact | Call button — Partner-to-Partner contact is allowed before approval |
| Puja photos | Tapping the card opens their profile view with puja photos |
| Who decides | The Principal only. Admin has visibility but no approval role. |
| One only | Approving one Associate closes the request; everyone else is notified it is filled |
| Re-open | If the approved Associate backs out, the Principal can re-open the request; it re-notifies the matched set |
| Associate side | The puja appears in the Associate's माझ्या पूजा badged सहाय्यक with the Principal's name and call button |
| Availability effect | The approved Associate is treated as unavailable on that date for all later matching |
| Trigger | Both Partners are prompted by push once the Amantran puja date and time have passed |
| Scale | 1–5 stars, mandatory; written feedback optional, 200 chars |
| Visibility | Each side's rating is revealed only after both have submitted, or after 7 days, whichever is first |
| Editable | No. A rating is final once submitted; disputes go to the office |
| Effect | Feeds the receiving Partner's overall average, pooled with Admin per-puja ratings |
| Earnings | On completion the Associate's agreed Dakshina is added to the Associate's own dashboard total, tagged आमंत्रण, and is not counted in the Principal's earnings |
How the Partner gets paid. The claim opens only after the puja date has passed, is capped at the offered Dakshina, and generates a customer invoice the moment it is submitted.
| Field | Rule |
|---|---|
| मागणी रक्कम * Claimed Dakshina | Prefilled with the offered amount. Editable downward only — cannot exceed the offered Dakshina. Above the cap, the field shows an inline error and submit stays disabled. |
| खर्च Out-of-pocket | Optional, numeric, ₹0–₹50,000. Kept separate from Dakshina throughout, including on the invoice and in reports. |
| पुरावा Media evidence | 0–5 files. Images ≤5 MB (JPG/PNG), video ≤50 MB and ≤60 s (MP4). Compressed on device, uploaded with resumable retry, stored on the server against the booking ID. |
| Opens | Only once the puja date has passed. Before that the button is not rendered. |
| One claim | One claim per booking. After submission the form becomes read-only; corrections go through the office. |
| Cancelled pujas | No claim can be raised against a cancelled booking |
| Reminder | If no claim is raised within 3 days of the puja, a reminder push is sent |
| Offline | Draft is retained locally; media uploads resume when connectivity returns, and submission completes only when all files are uploaded |
| Generated | Automatically on claim submission — never a separate action |
| Made out to | The customer's name and address from the booking, the claimed amount, and the puja date |
| Numbering | Server-side sequential per financial year, e.g. INV-2026-00318; immutable |
| Contents | Vandan letterhead, invoice number and date, customer block, puja name, booking ID, Dakshina line, expenses line, total, Partner name |
| Privacy note | The invoice carries customer name and address. It remains downloadable to the Partner from the completed puja even after the T+24h detail re-lock, since it is their own financial record. |
| मागणी पाठवली | Submitted, awaiting Admin reconciliation |
| रक्कम जमा | Admin has recorded the paid amount and transaction ID; both are shown to the Partner, and the dashboard total updates |
| फरकासह जमा | Paid amount differs from claimed; Admin's note is shown verbatim with the office contact |
Push notifications are the app's main trigger, so every alert is also kept in a screen the Partner can return to. Reachable from the bell on every tab.
| Trigger | Recipient | Opens |
|---|---|---|
| Puja pushed to a city | Preferred Partners first; all city Partners after 24h | P2.2 |
| Partner shows interest | Admin | Admin allocation view |
| Booking approved | Assigned Partner | P3.2 |
| Details unlocked (T-2) | Assigned Partner | P3.2b |
| Allocated to another Partner | Other interested Partners | P2.3 |
| Amantran request raised | Matched nearby Partners | P6.1 invites tab |
| Associate shows interest | Principal Pandit | P6.3 |
| Associate approved | Approved Associate | P3.2 (सहाय्यक) |
| Amantran puja completed | Principal & Associate | P6.5 rating |
| Dakshina claim submitted | Admin | Admin reconciliation |
| Dakshina paid | Claiming Partner | P7.3 |
| Puja cancelled | Previously assigned Partner | P9.1 |
| Puja re-pushed after cancellation | All Partners in that city | P2.2 |
| Profile approved / changes requested | The Partner | P1.6 |
| Milestone achieved | The Partner | P5.1 |
There is no in-app cancel action for the Partner. Both cancellation routes end with Admin marking the booking cancelled, which resets it into the allocation pipeline from the start.
| Customer cancels or postpones | Admin records it in the Admin Panel and the assigned Partner is notified. The Partner takes no action. |
| Partner wants to cancel | The Partner phones the Vandan office — outside the app. Admin then marks it cancelled. No in-app self-cancel or reject action exists anywhere in the app. |
| 1 · Customer name, address and call button are revoked from the Partner's device immediately. |
| 2 · The puja leaves नियुक्त पूजा and appears under रद्द झालेल्या with the cancellation date and, where Admin supplies one, the reason. |
| 3 · Any pending Dakshina claim route for that booking is closed; no claim can be raised. |
| 4 · The Partner's availability for that date is released, so they can be matched for other pujas and Amantran requests. |
| 5 · The booking re-enters the allocation pipeline at "pushed & city-notified" — a fresh interest round, a fresh Best-Fit ranking, a fresh Admin approval. Prior interest is not carried over; the previously assigned Partner may show interest again. |
| 6 · A postponed puja is handled as a cancellation plus a new date on the booking, then re-pushed. |
| भाषा | Marathi / English. Applies instantly without restart; server-driven content (puja names, remarks) follows the available translation and falls back to Marathi |
| सूचना | Per-category toggles. Assignment, unlock, cancellation and payment notifications are transactional and cannot be switched off |
| बँक तपशील | Masked view; editing requires OTP re-verification, re-triggers Admin verification and is written to the audit log |
| मदत व संपर्क | Office phone (tap to call), WhatsApp, working hours, and a short FAQ in Marathi covering allocation, T-2 unlock, QR payment and Dakshina claim |
| कायदेशीर | Terms and privacy policy served from the same legal pages as the customer app |
| खाते हटवा | Raises a deletion request into the existing Admin deletion queue. Blocked while an assigned puja or unreconciled claim is open, with the reason stated |
| बाहेर पडा | Confirmation dialog; clears session and de-registers the push token |
The Partner App runs on the existing Vandan backend and Admin Panel. The Admin Panel gains one new section — Pandit Lifecycle, where the whole life of a booked puja against its Pandit is managed — plus additions to the existing Pandits, Payments and Settings screens. Everything below follows the current Admin Panel's own layout conventions: left sidebar, page header with filters, data table, row drawer.
A new sidebar item. Every booked puja appears here the moment it is created, and is worked from left to right: push it, see who is interested, approve one, watch the claim arrive, reconcile the payment.
| Unique Booking ID · puja name · sub-city, city · date and time · Pandit Dakshina · lifecycle status · interested-Partner count · assigned Partner · payment collected · claim status · paid amount & transaction ID |
| Filters | City, status tab, date range, puja type, assigned Partner, claim status |
| Set Dakshina | Mandatory before a puja can be pushed; editable while unallocated, locked after assignment |
| Push to app | Starts the 24-hour Preferred window and notifies Preferred Partners in that city |
| Re-notify | Re-sends the push to all city Partners without changing state; logged with timestamp and actor |
| Open early | Ends the Preferred window immediately and opens the puja to the whole city |
| Cancel | Marks cancelled with reason and route (customer / Partner request), notifies the assigned Partner, and re-pushes per M9 |
| Opens from Review. Lists every interested Partner with name, photo, rating and rating count, years of experience, sub-city and distance from the puja sub-city, Preferred tag, pujas completed, cancellation count, and interest timestamp. |
| Best Suited badge | Shown when all three hold: Vandan Preferred Pandit tag · puja sub-city within 10 KM of the Partner's residence sub-city · overall rating 4 or above. Partners meeting all three sort to the top; the drawer states which conditions each Partner meets and which they miss. |
| Decision | Admin approves exactly one, with an optional internal note. Approval is a recommendation-assisted manual decision — the ranking never auto-assigns. |
| On approve | Assigned Partner notified; all other interested Partners notified and flipped to "Allocated to Other Pandit"; the T-2 unlock job is scheduled |
| Reassign | Allowed before the puja date; revokes the first Partner's access and customer details, notifies both |
| Keyed by Unique Booking ID. Shows offered vs claimed amount, out-of-pocket expenses, the up-to-5 media attachments, the generated invoice, and the Partner's payment-collected declaration. Admin records actual amount paid, transaction ID, payment date and an optional note. Saving notifies the Partner and updates their dashboard and income report. Bulk export of claims for a date range feeds the accounts process. |