# Field runbook **Retail Pharmacy Platform · for partners and support** Replaces the go-live section of `pilot-readiness-pack.md`, which was written before the scheduler, backup verification, self-update and setup wizard existed. Print this. It is meant to be held in a shop. --- ## 1. Installing a counter In order. Each step fails loudly rather than continuing. ``` bin/rx-install ``` It checks PHP, refuses to continue if `php-pdo_mysql` or `php-json` are missing, and names them. It warns about `php-zip` (Excel export) and `php-curl` (cloud sync) without blocking — those break features, not billing. Then it applies the schema in the declared order and tells you what is still outstanding. **It does not claim the shop is ready**, because it is not. Register the worker (as Administrator, once): ``` schtasks /Create /TN "Caresoft Counter Worker" ^ /TR "\"C:\Program Files\Caresoft\php\php.exe\" ^ \"C:\Program Files\Caresoft\bin\rx-worker\" once" ^ /SC MINUTE /MO 1 /RU SYSTEM /RL HIGHEST /F ``` Every minute. The scheduler decides what is actually due; this is only a heartbeat. Overlapping runs are safe — the job lock refuses the second one — so a slow backup cannot cause a pile-up. --- ## 2. Setting the shop up Open the setup wizard. **Six things have to be true** — seven if the shop takes online orders — and each is checked against the shop's own records: | Step | Done when | Why it blocks | |---|---|---| | Shop details | drug licence 20 **and** pharmacist name entered | both print on every bill | | Counters | at least one counter, each with a number block | a counter without one cannot bill | | Staff logins | at least one user | a shared login makes the audit trail worthless | | Medicine list | 100+ items | the counter can only bill what it can find | | Opening stock | at least one batch with quantity | otherwise every sale reads as negative stock | | Jobs and backup | jobs scheduled **and** one backup verified | a backup nobody restored is not a backup | | Messaging *(storefront only)* | provider connected **and** OTP template approved | customers confirm their mobile with a code; without it nobody can order | **A screen that comes up blank is a build problem, not a shop problem.** Every screen's JavaScript is parsed by `bin/rx-test` before release, so a blank page in the field means the wrong files were copied — check the version in the footer against the release, and re-run `rx-install`. Do not start editing HTML on a counter machine. **Submit the WhatsApp templates the day you start an online shop.** Approval takes days and cannot be hurried, and the storefront cannot go live without the OTP template. It is the longest lead time in the whole install and the easiest to leave until last. Nothing is ticked because you clicked. If a step goes back to undone, something actually regressed — believe the wizard, not your memory. **Go-live is refused until all six pass**, and the refusal names what is missing. Do not work around it. The first bill would fail at the counter in front of a customer. --- ## 3. Before you leave the shop Four checks. All four, every time, even on your fortieth install. **1. The worker is alive.** ``` php bin\rx-worker status ``` Any job showing **never** under LAST OK has not worked once. That is the single most common thing a partner leaves broken behind him. **2. A backup exists and has been restored.** ``` php bin\rx-worker run-job backup.run php bin\rx-worker run-job backup.verify ``` Verification restores the archive into a scratch database and compares row counts. A run that says `UNVERIFIED` is a file, not a backup. **3. The printer prints a real slip.** Not the test pattern — an actual bill, on the shop's own paper, from the counter screen. Check the column ruler lines up. **4. Time a bill against whatever they use now.** Same hardware, same shop, same assistant. If ours is slower, say so and escalate. That is the kill criterion for the whole product, and a partner discovering it is worth more than a chemist discovering it. --- ## 4. When something breaks Work down this list. Most calls stop at the first or second item. | Symptom | First check | Usual cause | |---|---|---| | "Nothing is saving" | `rx-worker status` | scheduled task not registered | | "It won't let me bill" | setup wizard | licence or number block missing | | Slip prints wrong width | Counter Helper test pattern | wrong template for the printer | | "Prices are wrong" | is MRP being edited per bill? | MRP is GST-inclusive; the tax is inside it | | Stock looks 10–20× too high | any custom report | pack rate multiplied by base units | | Backups say UNVERIFIED | disk space, then the key | `no backup key configured` fails loudly on purpose | | Update failed | `update_run` stage column | it says exactly where it stopped | **On a rolled-back update:** the store is on its previous version and working. Do not re-run it. Send the `update_run` row. **On a restore:** it demands the store code typed back, and refuses an unverified archive. Both are deliberate. Overwriting a live shop with a week-old archive is the most destructive thing this software can do. --- ## 5. What updates do, so you can explain it Updates install **during working hours, lunch slot, never overnight.** That surprises people, so the reason matters: an overnight update that goes wrong is found by a chemist at 9am with customers queuing and nobody at Caresoft awake. The same update at 3pm is found in ninety seconds by someone who can phone you. Before anything is applied: the package signature is checked, a backup is taken **and verified by restoring it**, and the update refuses to start if that verification fails. Afterwards the data checks run, and any failure rolls back both the files and the database. You can hold updates for a store from the partner console while you investigate. Say why — the shop sees it too. --- ## 6. What you can and cannot see The partner console shows **counts and health, never contents**. No customer, no prescription, no bill. This is not a limitation to apologise for. It is the answer to the question every chemist eventually asks — *"can you see my customers?"* — and the answer is no, by construction, for you and for us. If a chemist withdraws consent, your access to that store ends that day. --- ## 7. The number that decides everything **Support contacts per store per month.** Reviewed every Monday. | Rate | What it means | |---|---| | under 0.3 | on track | | 0.3 – 1.0 | find the top cause and fix the product | | over 1.0 | stop onboarding until it is fixed | Log every contact **by cause**, not by store. Ten calls about one thing is one defect worth fixing. Ten calls about ten things is a design problem, and more stores will make it worse. > If a store needs a visit in the next three months, that is a fault in > the product, not in the shop.