# Deploy — Advance Payment + Visit-Based Orders (Wallet Split)

Visit-based selling (advance online, balance collected in person by the seller — cash or online), wallet-first payment splitting, and a full order lifecycle (placed → paid → assigned → visit → collected → activated → completed) for customer, seller and admin.

## 1. Files to upload

### NEW file

| File | Purpose |
|---|---|
| `order.php` | Customer-facing single order tracker/detail page (stage timeline, payment breakdown, seller contact, "Order Placed Successfully" confirmation) |

### MODIFIED files

| File | What changed |
|---|---|
| `includes/purchase.php` | The order engine (already existed, one bug fixed): `buy_orders()` searched a non-existent `o.service_title` column — corrected to `o.service_name` |
| `checkout.php` | Was left mid-build/truncated. Completed the 3-step wizard: Choose Customer Type → Select Payment Method (Full / Advance / Payment Code, with wallet-balance toggle) → Review & Confirm, plus the Alpine `checkout()` component and Razorpay trigger |
| `admin/services.php` | Added a "Delivery & Advance Payment" section to the Edit Main Category modal (Fulfilment / Advance Mode / Advance Amount / Advance Percent) and the matching save handler |
| `admin/product_management.php` | Added the same "Delivery & Advance Payment" fields to the Add/Edit product modal, wired into `blankSvc()`, `openEditSvc()`'s field map, and the `add_service`/`edit_service` save handlers |
| `admin/orders.php` | Rewritten. Removed the old `update_order` handler (it manually paid sellers — would double-pay against the new engine's automatic settlement). Added an order detail endpoint, stage-based actions (assign seller, approve/reject collection, mark visit done, activate, complete, cancel, delete), stat cards and a Financial Overview panel |
| `seller/orders.php` | Rewritten. Removed the old `update_status` handler (same double-payment risk). Added collection-report / visit-status actions restricted to the seller's own orders, stat cards, an "Action Required" list, and a manage-drawer modal |
| `admin/index.php` | Added an "Order Engine" section to the dashboard: 4 stat cards + a Financial Overview panel, sourced from `buy_stats()` |
| `seller/index.php` | Added stat cards, an "Action Required" list, and a "Today's Visit Schedule" list, sourced from `buy_stats()` and direct order queries |
| `orders.php` | Customer "My Orders" list — simplified the SQL, rebuilt the table with stage badges (`buy_stage_meta()`), order codes, due-amount display and a "Track Order" link to `order.php` |
| `dashboard.php` | Added an "Active Order Tracker" card (shows service name, current stage, amount due and a Track Order link) whenever the customer has an order still in progress |

**Suggested upload order:** `includes/purchase.php` → `checkout.php` → `order.php` → `orders.php` → `dashboard.php` → `admin/services.php` → `admin/product_management.php` → `admin/orders.php` → `admin/index.php` → `seller/orders.php` → `seller/index.php`

## 2. Database — no new migration needed

Every column and table this feature uses (`fulfilment`, `advance_mode`, `advance_amount`, `advance_percent`, `allow_cart`, `allow_code`, `visit_note` on `seller_services` / `agency_services` / `service_categories`; the ~28 new columns on `orders`; the `carts`, `order_items`, `order_timeline`, `seller_collections`, `seller_settlements` tables) is already defined in **`ordmigration.php`**, which was already sitting in the project root before this session.

**Action needed:** if `ordmigration.php` has not yet been run on the live server, open it once:

```
https://<your-domain>/ordmigration.php
```

It is safe to run more than once (it checks what already exists before adding anything), and every old order keeps working — the new columns simply describe an old order as a fully-paid online order, which is what it was. **Delete the file after a successful run**, per its own footer note.

If it has already been run — the code added in this session assumes those columns exist, so this is worth confirming once on the live database before relying on the new pages.

## 3. What this session verified

- Read `ordmigration.php` in full and cross-checked every column referenced by every file above against it — no gaps found, no new migration file required.
- Ran `php -l` (syntax lint) on all 12 touched/created files — all clean, no syntax errors.
- Fixed a bug in `includes/purchase.php` (`buy_orders()` search clause referenced a column that doesn't exist).
- Fixed a bug caught during development: a new product's "Fulfilment" field was being silently forced to `online` when left blank, breaking the "inherit from category" option — corrected to preserve blank.
- Removed two legacy status-update handlers (`admin/orders.php`, `seller/orders.php`) that paid sellers directly — left running alongside the new engine's automatic settlement (`buy_complete_order`), they would have paid sellers twice.
- Fixed an Alpine.js scoping bug in `seller/orders.php` (state and methods were split across two `x-data` scopes; consolidated into one).

## 4. Residual risk to know about

`admin/product_management.php`'s `edit_service` save handler updates its new columns (`fulfilment`, `advance_mode`, `advance_amount`, `advance_percent`, `allow_cart`, `allow_code`, `visit_note`) in the same loop as the product's other fields, without a per-column try/catch. If `ordmigration.php` has **not** been run yet, saving a product edit from this page will throw instead of failing gracefully on just those columns. This resolves itself the moment the migration above has been run — flagging it so it isn't a surprise if tested out of order.

## 5. How it works, end to end

- **Admin** sets, per category (and optionally overridden per product), whether a service sells straight online or requires a seller visit, and how the advance is calculated (fixed amount or percentage).
- **Customer** buys through `checkout.php`'s wizard: picks how they're paying (Full / Advance + visit / Payment Code), optionally applies wallet balance — if wallet covers the price fully the order is free, otherwise the wallet portion is deducted and the remainder goes through Razorpay — then lands on `order.php` to track progress.
- **Seller** sees assigned visit-orders in `seller/orders.php`, reports what they collected on-site, and the office (**Admin**, in `admin/orders.php`) verifies the collection, activates and completes the order — at which point the engine automatically settles the seller's payout and the company's profit share.
