# Coordination: Gishen-Admin

How Gishen-B2B interacts with **Gishen-Admin** (pharmacy ops, commercial activation, Rx review).

**Workspace:** `/Users/kirukib/Desktop/Yaltopia Project/Gishen-B2B`

## Admin responsibilities (Admin repo owns UI)

| Domain | Admin action | B2B impact |
|--------|--------------|------------|
| Commercial activation | Set credit limit, payment terms, price list, contract dates | Org moves `pending_activation` → `active`; B2B unlocks members/packages/migration commit |
| Org creation (legacy) | Offline sales creates org + invites SUPER_USER | B2B receives invite link |
| Registration queue | Review `org.registration_submitted` / `org.registration_requested` | Admin contacts client, completes setup, activates |
| Pharmacist Rx queue | Review submitted prescriptions | B2B member sees status updates via `prescription.review_updated` |
| **Pharmacy ID scan** | POS / pharmacist scans member QR at purchase | Resolve `member_id` + `verification_id` from `gishen://member/{id}?v={verification_id}`; apply org package entitlement at checkout |
| Credit / invoice oversight | Monthly billing, suspensions | B2B Finance sees statements; `org.suspended` blocks new orders |
| Price lists | Corporate pricing | Referenced by `organisation.commercial.price_list_id` — read-only in B2B |

## B2B responsibilities

| Action | Event emitted |
|--------|---------------|
| Self-register | `org.registration_submitted` |
| Request to register | `org.registration_requested` |
| Member submits Rx | `prescription.submitted` |
| Migration commit | `migration.job_*` (audit) |

## Events: Admin → B2B

| Event | B2B handler |
|-------|-------------|
| `org.activated` | Update org status; show commercial fields; unlock HR workflows |
| `org.suspended` | Show banner; block mutations |
| `prescription.review_updated` | Refresh prescription status in member portal |

## Events: B2B → Admin

| Event | Admin handler |
|-------|---------------|
| `org.registration_submitted` | Registration review queue |
| `org.registration_requested` | CRM / sales follow-up |
| `prescription.submitted` | Pharmacist review queue |
| `migration.job_completed` | Optional audit log |

## Data ownership

| Field / entity | Writer | Reader (B2B) |
|----------------|--------|--------------|
| `Organisation.commercial` | Admin | HR, Finance, SUPER_USER (read) |
| `Organisation.status` | Admin | All authenticated |
| `Prescription` review fields | Admin | Member, SUPER_USER |
| `Member`, `Department`, `Package` | B2B (HR) | B2B |
| `Member.verification_id` / `card_id` / `avatar_url` | B2B (HR) | B2B portal + Admin POS scan |
| `Statement` | Admin/billing engine | B2B Finance |

## Pharmacy ID card (scan contract)

B2B prints employee pharmacy ID cards from `GET /v1/members/:id/id-card` (UI: `/members/[id]` → ID card tab).

| Item | Spec |
|------|------|
| QR payload | `gishen://member/{member_id}?v={verification_id}` |
| Card fields | Photo, name, employee ID, `card_id`, package, status, org |
| Admin responsibility | Implement scanner → resolve member → covered checkout (with Ecom entitlement) |
| Clinical | Card has **no** Rx or medicine data |

See [`../backend/endpoints/members.md`](../backend/endpoints/members.md) and [`../backend/OVERVIEW.md`](../backend/OVERVIEW.md#pharmacy-id-card-platform-contract).

## Clinical withhold alignment

Admin pharmacists see full Rx detail. B2B HR/Finance never receive clinical payloads — enforced in B2B API layer and documented in entity/endpoint specs.

SUPER_USER in B2B may view member Rx for support; does not replace Admin review workflow.

## Integration checklist

- [ ] Admin registration queue consumes `org.registration_*`
- [ ] Admin activation emits `org.activated` with commercial payload shape matching [`../backend/entities/organisation.md`](../backend/entities/organisation.md)
- [ ] Pharmacist queue consumes `prescription.submitted`
- [ ] Admin review emits `prescription.review_updated`
- [ ] Statement PDF generation exposes URLs consumed by B2B `/statements`
- [ ] POS / Admin scanner accepts `gishen://member/{id}?v={verification_id}` and resolves covered member

## Contact / escalation

Cross-repo contract changes must update both Admin spec sheet and this repo's `docs/backend/` in the same release cycle.