The skill scans a bot with subagents (never runs it) and writes HANDOVER.md, an 11-section ops guide in the operator's order: where is what, how to run, how long to wait, after the run, how to see an exception, exception list, how you will know, how to tell us, don'ts, issues seen before. Dev material (check against 12 failure classes from Tebra Auto Post, gaps with file:line, incidents) goes to HANDOVER-DEV.md. Also adds ADR-0004, glossary terms, five fixture bots and a handoff eval runner (--resume, --regrade) with results from 47 runs of the earlier 13-section version. The grader still expects that structure and must be updated before the next eval run. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
215 lines
29 KiB
Markdown
215 lines
29 KiB
Markdown
# ClaimDesk Poster - ops handover
|
|
|
|
Version 1.4.2 · Written 2026-10-23 · Escalation: RPA dev team, #rpa-support Teams channel
|
|
|
|
## 1. What the bot does
|
|
|
|
The bot posts remittance payments into the **ClaimDesk** desktop app, one clinic at a time. Ops starts it from the "ClaimDesk Poster" launcher window with an input Excel file that has three sheets: **Login** (the ClaimDesk user name and password in row 2), **Clinics** (one clinic per row in column A, starting at row 2) and **Settings** (the cutoff date in cell B1). For each clinic, the bot opens ClaimDesk, signs in, opens the clinic and goes through the remittance list:
|
|
- It posts and saves every ACH payment dated on or before the cutoff.
|
|
- It skips payments that are not ACH.
|
|
- It defers payments dated after the cutoff.
|
|
|
|
It writes one result row per payment to the **Report screen** in the launcher, and a run log to the `logs` folder. It writes no other output files. It drives one app: **ClaimDesk**.
|
|
|
|
## 2. How it works
|
|
|
|
```
|
|
"ClaimDesk Poster" launcher (the window you use; title bar shows the version)
|
|
└─ starts → posting bot (runs in the background) ──drives──> ClaimDesk desktop app
|
|
│ (do not touch while it runs)
|
|
├─ writes → bot database ──read by──> Report screen in the launcher
|
|
└─ writes → logs/run_<date>_<time>.log
|
|
```
|
|
|
|
- **Launcher:** where you pick the input file, start the run, see the version and open the Report screen.
|
|
- **Posting bot:** a separate background program that does the work. It has no window of its own.
|
|
- **ClaimDesk:** the bot starts it, signs in and clicks through it. Before each new clinic, and after each failed try, it force-closes **every** ClaimDesk window on the machine.
|
|
- **Bot database:** holds the batch, the clinic list and one result row per payment. Ops cannot open it directly. The Report screen shows part of it.
|
|
- **Run log:** one file per run, in local time. It is the only place that shows clinic-level failures and retries.
|
|
|
|
**One run, step by step:**
|
|
1. The bot checks that no earlier batch is still open. If one is, it stops at once (E01).
|
|
2. It reads the input Excel and creates a new batch with every clinic set to Pending.
|
|
3. For each clinic, in input order:
|
|
1. Start ClaimDesk and sign in.
|
|
2. Click the clinic's link and check that the window title now shows the clinic name.
|
|
3. Wait for the remittance list.
|
|
4. For each payment in the list: skip it, defer it, or click Post Payment, then Save, then wait for "Payment saved". One Report row is written per payment.
|
|
5. Close ClaimDesk.
|
|
4. If a clinic fails, the bot tries it again, up to 3 tries in total. After 3 failed tries the clinic stays Pending and the bot moves on to the next clinic.
|
|
5. At the end, the batch is marked Completed only if no Report row is red and no clinic is still Pending. Otherwise the batch stays open, and **the next upload is refused** (E01).
|
|
6. The log ends with "[RUN SUMMARY] batch N done". This line appears even when the batch did **not** complete.
|
|
|
|
## 3. Before a run
|
|
|
|
- [ ] On this machine, the RPA dev team has set the ClaimDesk program path for the bot. If it is missing or wrong, every clinic fails (E07).
|
|
- [ ] The bot's `data` folder exists next to the bot. If it doesn't, the bot cannot start; escalate (E01).
|
|
- [ ] No earlier batch is still open. If you are unsure, check the last run log for "left Pending", "[WATCHDOG]" or red rows on the Report screen (see E01).
|
|
- [ ] **Input Excel, Login sheet:** the user name goes in A2 and the password in B2. Both must be filled in.
|
|
- [ ] **Input Excel, Clinics sheet: one clinic per row.** Never put commas or semicolons in a cell. The bot cuts a cell at every comma and every semicolon.
|
|
- Bad: `Clinic A, Clinic B` in one cell.
|
|
- Good: `Clinic A` in A2 and `Clinic B` in A3.
|
|
- A clinic whose **real name** contains a comma or a semicolon cannot be run at all. Leave it out and tell dev (E03).
|
|
- [ ] Clinic names are spelled **exactly** as the clinic link in ClaimDesk, including capitals and `&`. Names containing `&` have failed before (E06).
|
|
- [ ] **Settings sheet:** put the cutoff date in B1. The bot compares the date as text, not as a calendar date. After the first run, check that the Deferred rows really are later than the cutoff (E13).
|
|
- [ ] The Login, Clinics and Settings sheets all exist and are spelled exactly like that.
|
|
- [ ] The launcher title bar shows version 1.4.2 (see section 10).
|
|
|
|
## 4. During a run
|
|
|
|
- **Don't use the mouse or keyboard on this machine.** The bot clicks on the screen, and Windows may stop it from bringing ClaimDesk to the front. The log then shows "could not bring window to foreground".
|
|
- **Don't open ClaimDesk yourself on this machine**, and keep any other window whose title contains "ClaimDesk" closed. This includes SQL or database tools, browser tabs and Explorer folders named ClaimDesk. The bot uses the first window it finds with "ClaimDesk" in its title, and between clinics it force-closes every ClaimDesk window (E17).
|
|
- **To stop the bot:** there is no Stop button and no safe way to stop it mid-run.
|
|
- Closing ClaimDesk does **not** stop it. The bot counts that as a failed try and starts ClaimDesk again.
|
|
- The launcher code is not part of this handover, so it is unknown whether closing the launcher stops the background bot. Ask dev before relying on it.
|
|
- Any stop mid-run leaves the batch open, and the next upload is refused (E01). Let the run finish if you can.
|
|
- **A run looks stuck** when ClaimDesk sits on the same screen and no new line has been added to the run log for several minutes.
|
|
- The bot gives up by itself when **no payment has been processed for 5 minutes**. It then ends the whole run and writes "[WATCHDOG]" in the log (E16).
|
|
- Wait those 5 minutes before you act.
|
|
- Signing in and waiting for screens do **not** count as progress. A clinic that keeps failing can therefore trigger the watchdog before its 3 tries are used up.
|
|
|
|
## 5. Where to look when something goes wrong
|
|
|
|
| Question | Where to look |
|
|
|---|---|
|
|
| Did the run finish? | The newest file in `logs` (`run_<date>_<time>.log`): the last line should be "[RUN SUMMARY] batch N done". If the last line is "[WATCHDOG]", or the file is empty, the run did not finish. |
|
|
| Did the batch complete, or is it blocking the next upload? | Ops cannot see this directly. A batch is still open if the Report screen shows any **red** row, or the run log has a "left Pending" or "[WATCHDOG]" line. |
|
|
| Which payments failed? | Report screen for that batch: the red rows (File Status = Error). |
|
|
| Why did one payment fail? | Report screen, Comments column. Then search the run log for the clinic name. |
|
|
| A clinic has no rows on the Report screen | Search the run log for the clinic name. "left Pending after 3 attempts" means the clinic failed: see the message on the "[ERROR] Clinic" lines just above it. If there is no error line, the clinic had nothing to post. |
|
|
| Did the bot already retry? | Run log: lines "[AUTO-RERUN] attempt 2" or "attempt 3" for that clinic. |
|
|
| Which version is running? | The launcher title bar. |
|
|
| Output files | None. The bot writes no output files. Its results are only on the Report screen and in the run log. |
|
|
|
|
Note: Report rows have no time stamp. To match a row to a log line, use the clinic name and the order of events.
|
|
|
|
## 6. Statuses
|
|
|
|
The Report screen shows a File Status (with a colour) and a Comment for each payment. **Green does not always mean posted.** Always read the Comment.
|
|
|
|
| Status (File Status - Comment) | Colour | Meaning | What ops does |
|
|
|---|---|---|---|
|
|
| Completed - "Posted successfully" | green | Payment posted and saved in ClaimDesk | Nothing |
|
|
| Completed - "Remittance Errors on posting" | green | **Not posted.** ClaimDesk showed its "Remittance Errors" screen, and the bot pressed Cancel. Needs follow-up. | Review and post it in ClaimDesk by hand (E11) |
|
|
| Completed - "Payment method '<method>' - not posted" | green | **Not posted on purpose.** The payment is not ACH. | Nothing, unless the client wants non-ACH payments posted (E12) |
|
|
| Deferred - "Check date <date> is after the cutoff - deferred" | grey | Not posted. Its date is later than the Settings cutoff. | Nothing. A later run with a later cutoff picks it up. Check the date really is after the cutoff (E13). |
|
|
| Error - "Save button not found" | red | Post Payment was clicked, but the payment screen had no Save button. Not saved. **Blocks the batch.** | E14 |
|
|
| Error - "Payment not confirmed after Save" | red | Save was clicked, but "Payment saved" did not appear within 20 seconds. **It may have posted.** **Blocks the batch.** | E15: check ClaimDesk first, never re-post blindly |
|
|
| Pending | amber | The bot never writes this today. It would mean a result the bot did not recognise. | Escalate (Dev) |
|
|
| Clinic Pending / Success | not shown | Kept in the bot database only. Success means the clinic's list was walked, **even if some rows are red or there were no payments**. Pending means all 3 tries failed. | See the run log for "left Pending" |
|
|
| Item status Posted / Rejected by app / Skipped / Deferred / Error | not shown | A second, more precise status the bot stores for each row, in a column the Report screen hides. Posted, Rejected by app and Skipped all show as green Completed. | Tell them apart by the Comment |
|
|
| Batch Pending / Completed | not shown | Kept in the bot database only. Pending blocks every new upload. | E01 |
|
|
|
|
## 7. Exception catalogue
|
|
|
|
Clinic-level errors (E03-E10) appear in the run log as `[ERROR] [ERROR] Clinic '<name>' : <message>`. The word ERROR appears twice; that is normal.
|
|
|
|
| ID | What you see | How the bot identifies it | Where it is recorded | Type | Who acts | What to do | Escalate when |
|
|
|---|---|---|---|---|---|---|---|
|
|
| E01 | Upload refused: "A Pending batch exists - finish or clear it before a new upload". The new run log is empty. | At start, the bot checks for an earlier batch that is still open. An earlier batch stays open if it has a red row, a clinic left Pending, or a run that was killed or stopped. | Launcher message only (if the launcher shows it). The new run log is empty. | System | Dev | Find the last run log and note why that batch did not complete (red rows, "left Pending", "[WATCHDOG]"). Ops cannot clear a batch. Ask dev to clear it. | Always. Send the batch number from the last "[RUN SUMMARY]" line (if there is one), the last run log file, and the time of the refused upload. |
|
|
| E02 | The run stops at once with "'Login' sheet not found", "UserName/Password missing in Login sheet (row 2)", or an error naming "Clinics" or "Settings". The run log is empty. | The bot reads the input Excel before it creates the batch. A missing sheet, or an empty A2 or B2 on the Login sheet, stops it. | Launcher message only (if shown). The run log is empty. No batch is created. | Business | Ops | Fix the input Excel (section 3) and start again. Nothing is blocked. | The Excel is correct and it still fails. Send the time, the error text and the empty log file name, **not** the Excel (it holds the password). |
|
|
| E03 | Log shows "Clinic '<part of a name>' not found in list" for names that look cut in half, or for an empty name '' | The bot cut a Clinics cell at a comma or semicolon (or a trailing comma). Each piece is looked for in ClaimDesk and is not found. | Run log, 3 tries per piece, then "left Pending after 3 attempts". No Report rows. Batch stays open. | Business | Ops, then Dev | Put one clinic per row with no commas or semicolons. The batch is now blocked: ask dev to clear it (E01). | Always, to clear the batch. If the clinic's real name contains a comma, it cannot be run until dev fixes the bot. Send the batch number, run log and clinic row number. |
|
|
| E04 | "Clinic '<name>' not found in list" for one clinic | The bot waits 10 seconds for a link with exactly that name in ClaimDesk, and none appears. | Run log, 3 tries, then "left Pending after 3 attempts". Batch stays open. | Business | Ops, then Dev | Check the spelling against ClaimDesk exactly (capitals, `&`, spaces) and whether this user can see the clinic. Fix the input. Ask dev to clear the batch (E01). | Always, to clear the batch. Also escalate when the spelling is already exact. Send the batch number, run log and time. |
|
|
| E05 | "not found in list" for **every** clinic in the run | Most likely the sign-in failed (wrong user name or password). The bot never checks that sign-in worked, so it looks for clinics on the login screen. | Run log; every clinic "left Pending". Batch stays open. | Business | Ops, then Dev | Check the user name and password in Login A2/B2 by signing in to ClaimDesk by hand when no run is going. Ask dev to clear the batch. | The login is correct. Send the batch number, run log and time. Never send the password. |
|
|
| E06 | "Wrong clinic opened, leaving Pending: <name>" | After clicking the clinic link, the ClaimDesk title bar does not contain the clinic name exactly. This has happened with names containing `&`, and when the bot could not bring the window to the front. | Run log, 3 tries, then "left Pending". Batch stays open. | System | Bot, then Dev | Wait for the 3 tries. Check that nothing else was used on the machine during the run (section 4). | It fails after 3 tries. Send the batch number, run log, clinic row number and a screenshot of ClaimDesk if it is still open. |
|
|
| E07 | "Login window not found", or every clinic fails with an error naming the ClaimDesk program path | ClaimDesk was started, but its "ClaimDesk Login" window did not appear within 60 seconds, or the program path is not set. | Run log, 3 tries per clinic. Batch stays open. | System | Bot, then Dev | Wait for the 3 tries. Check that ClaimDesk opens by hand on this machine when no run is going. | It fails after 3 tries. Send the batch number, run log and time. |
|
|
| E08 | "ClaimDesk window not found" | Right after Sign in, no window title contains "ClaimDesk". | Run log, 3 tries. Batch stays open. | System | Bot, then Dev | Wait for the 3 tries. | It fails after 3 tries. Send the batch number, run log and time. |
|
|
| E09 | "Remittance grid did not load" | The remittance list did not appear within 60 seconds after the clinic opened. | Run log, 3 tries. Batch stays open. | System | Bot, then Dev | Wait for the 3 tries. ClaimDesk may just be slow; try again at a quieter time. | It fails after 3 tries, or on two runs in a row. Send the batch number, run log and time. |
|
|
| E10 | Any other "[ERROR] Clinic '<name>' : <message>" (for example "list index out of range", or a message about an element or a click) | An unexpected screen or click failure while the clinic was open, for example clicking Post Payment. The whole clinic is retried from the top. | Run log, 3 tries. Batch stays open. Rows already written stay on the Report screen. | System | Bot, then Dev | Wait for the 3 tries. Check the Report screen for duplicate rows (E20). | It fails after 3 tries. Send the batch number, run log, time and the exact message. |
|
|
| E11 | Green row, "Remittance Errors on posting" | After Post Payment, ClaimDesk showed its "Remittance Errors" screen within 5 seconds. The bot pressed Cancel. | Report screen (green, **not posted**) | Business | Ops | Open the payment in ClaimDesk, review the errors, and post it by hand or follow the client's process. | ClaimDesk shows no error for that payment. Send the batch number and check number. |
|
|
| E12 | Green row, "Payment method '<method>' - not posted" | The payment method in the list is not exactly "ACH". | Report screen (green) | Business | Ops | Nothing, unless the client wants that method posted. Then post it by hand. | An ACH payment was skipped. Send the batch number and check number. |
|
|
| E13 | Grey row, "Check date <date> is after the cutoff - deferred". Or payments posted or deferred on the wrong side of the cutoff. | The bot compares the payment's date with the Settings cutoff **as text, not as a calendar date**. Different date formats can give a wrong answer. | Report screen (grey) | Business | Ops | Check a few Deferred and Posted dates against the cutoff. If they look right, nothing to do: deferred payments are picked up by a later run. | Dates are on the wrong side of the cutoff. Send the batch number, two example check numbers and the cutoff you entered. |
|
|
| E14 | Red row, "Save button not found" | After Post Payment, no Save button appeared within 10 seconds. The bot moves on without saving. | Report screen (red). Batch stays open. | System | Ops, then Dev | Check the payment in ClaimDesk. It should be unposted. Post it by hand if needed. Ask dev to correct the row and clear the batch. | Always (to clear the batch). Send the batch number, check number and run log. |
|
|
| E15 | Red row, "Payment not confirmed after Save" | After Save, the bot waits 20 seconds for "Payment saved". If it does not appear, it writes Error. **It does not check whether the payment really posted.** | Report screen (red). Batch stays open. | System | **Ops**, then Dev | **Check the payment in ClaimDesk before doing anything.** In the past these had often really posted. If it posted, do **not** post it again. If it did not post, post it by hand. Ops cannot edit the row, so ask dev to correct it and clear the batch. | Always (to correct the row). Send the batch number, check number, whether it posted in ClaimDesk, and the run log. |
|
|
| E16 | The run ends early. The last log line is "[WATCHDOG] no progress for 300s - killing run", with no "[RUN SUMMARY]" line. ClaimDesk may be left open. | No payment was processed for 5 minutes. Signing in, opening clinics and waiting for lists do not count as progress. | Run log. Batch stays open. Remaining clinics are not run. | System | Dev | Close ClaimDesk. Do not start a new run: it will be refused (E01). | Always. Send the batch number, the run log, and which clinic was being retried (from the last "[ERROR]" or "[AUTO-RERUN]" lines). |
|
|
| E17 | ClaimDesk closes unexpectedly, or the bot clicks in a database tool or another window with "ClaimDesk" in its title | The bot takes the first window with "ClaimDesk" anywhere in its title. After every clinic it force-closes every ClaimDesk program on the machine. | Nothing specific. Often followed by E04, E06 or E08 in the run log. | System | Ops | Close every other window with "ClaimDesk" in its title before the run, and don't use ClaimDesk on this machine during a run (section 4). | It happens with no such window open. Send the batch number, run log and the names of the windows that were open. |
|
|
| E18 | Log shows "could not bring window to foreground" | Windows refused to bring ClaimDesk to the front, usually because someone used the machine. | Run log (warning). Usually followed by E06. | System | Ops | Keep hands off the machine during a run. | It happens with nobody using the machine. Send the run log. |
|
|
| E19 | A clinic has no rows on the Report screen | Either the clinic had nothing to post (the bot still marks it done), or all 3 tries failed (see E03-E10). | Run log: "left Pending" if it failed. No line if it was empty. | Business | Ops | Search the run log for the clinic name. If there is no error, confirm in ClaimDesk that the clinic really has nothing to post. | ClaimDesk shows payments, but the bot wrote no rows and no error. Send the batch number, run log and clinic name. |
|
|
| E20 | The same check number appears more than once for a clinic on the Report screen | When a clinic is retried, the bot walks its list again from the top and writes new rows. It never checks for a row that already exists. | Report screen | System | Ops, then Dev | Check the payment in ClaimDesk before acting, to see whether it posted once, twice or not at all. An old red row keeps the batch open even if a later row is green. | A payment posted twice, or a red duplicate blocks the batch. Send the batch number, check number and run log. |
|
|
|
|
## 8. What the bot recovers by itself
|
|
|
|
| Problem | What the bot does | Limit | After the limit |
|
|
|---|---|---|---|
|
|
| Any clinic-level failure (E04-E10) | Force-closes ClaimDesk, then starts it again, signs in again and walks the clinic's list from the top | 3 tries per clinic. Each try can wait up to about 2 minutes (60 s for login + 10 s for the clinic link + 60 s for the list). | Clinic left Pending ("left Pending after 3 attempts"), and the bot moves to the next clinic. The batch will not complete. |
|
|
| "Remittance Errors" screen after Post Payment | Presses Cancel | Waits 5 s for the screen | Row green "Remittance Errors on posting" (not posted), next payment |
|
|
| Save button missing / no "Payment saved" | **No retry** | 10 s / 20 s | Row red, next payment |
|
|
| No progress at all | Watchdog ends the whole run | 5 minutes without a processed payment | The run stops, the batch stays open and ClaimDesk may stay open (E16) |
|
|
| Earlier batch still open | **No recovery or resume** | - | Every new upload is refused until dev clears it (E01) |
|
|
|
|
How long to wait: a clinic that keeps failing shows up to 3 "[AUTO-RERUN]" lines over about 5-7 minutes. If the log has had no new line for 5 minutes, the watchdog will end the run. Act after that, not before.
|
|
|
|
## 9. Known incidents
|
|
|
|
The repository shows a "fix" for incidents 1-4, but **none of them changed how the bot behaves**. Treat all of them as still open. Dates are unknown unless a log shows one; all were recorded on 2026-10-23.
|
|
|
|
| When / version | What ops saw | Cause | What to do now | Ops could handle? |
|
|
|---|---|---|---|---|
|
|
| Date unknown, launcher 1.3.0 → 1.4.x | Users stayed on version 1.3.0 after an update | The launcher kept using the old program folder until it was restarted | After every update, fully close and reopen the launcher, then check the title bar (section 10) | Yes |
|
|
| Seen 2026-09-01 and before | Red rows "Payment not confirmed after Save" for payments that had really posted | ClaimDesk sometimes takes longer than the bot's 20 s wait to save | E15: check ClaimDesk first, never re-post blindly. Not fixed. | Yes |
|
|
| Date unknown | Some clinics never processed, or "not found in list" for pieces of names | The bot cuts clinic cells at commas and semicolons | One clinic per row (section 3, E03). Names that really contain a comma still can't be run. | Partly |
|
|
| Date unknown | The bot drove a SQL browser window and then closed the real ClaimDesk | The window title of the SQL browser contained "ClaimDesk" | Close other "ClaimDesk" windows and don't use ClaimDesk during a run (section 4, E17). Not fixed. | Partly |
|
|
| 2026-09-01 | "could not bring window to foreground", then "Wrong clinic opened" for a clinic whose name contains `&`, then "[AUTO-RERUN]", then "[WATCHDOG] … killing run" | Window focus lost, `&` in the name (likely), and the watchdog does not count retries as progress. The batch was left open. | Hands off the machine (section 4). Check `&` names (E06). Ask dev to clear the batch (E01, E16). | Partly |
|
|
|
|
## 10. Releases and version check
|
|
|
|
- **How an update arrives:** through the launcher. The launcher's update code is not part of this repository, so dev must confirm the exact steps.
|
|
- **How to confirm it applied:** fully close and reopen the launcher, then check that its title bar shows the new version (today: 1.4.2).
|
|
- **If the version did not change:** close the launcher completely, reopen it and check again. If it still shows the old version, escalate to dev with the machine name and the version shown.
|
|
- Each machine keeps its own bot database and logs, so one machine on an old version does not overwrite another. Still, keep every ops machine on the same version.
|
|
|
|
## 11. Escalating to dev
|
|
|
|
Post in the **#rpa-support** Teams channel (RPA dev team).
|
|
|
|
Send:
|
|
- the exception ID from section 7 (for example "E15")
|
|
- the batch number, from the "[RUN SUMMARY] batch N" line in the log (a run killed by the watchdog has no such line; send the log file name instead)
|
|
- the time of the failure
|
|
- the run log file `logs/run_<date>_<time>.log`
|
|
- the clinic name and check number
|
|
- a screenshot of ClaimDesk, when it is still on the failing screen
|
|
|
|
Never send:
|
|
- passwords
|
|
- the input Excel (its Login sheet holds the ClaimDesk password)
|
|
- the bot's settings file
|
|
- patient or customer data, typed into chat
|
|
|
|
## 12. Failure-class check
|
|
|
|
- **F1 Missing prerequisite:** section 3 (ClaimDesk path, `data` folder), E07, E01. The settings and database setup are also in Fix before handover, items 9 and 10.
|
|
- **F2 Wrong window / focus:** section 4, E17, E18. Fix before handover, items 3 and 4.
|
|
- **F3 App slower or different:** E07, E08, E09, E10, E14, section 8. Fix before handover, item 7.
|
|
- **F4 Input read differently:** section 3 (one clinic per row, exact spelling, `&`, cutoff), E03, E04, E06, E13. Fix before handover, items 5 and 6.
|
|
- **F5 Marked done when nothing was done:** E19. Fix before handover, item 8.
|
|
- **F6 Action happened but not confirmed:** E15, E20. Fix before handover, item 2.
|
|
- **F7 Business exception shown as success:** section 6 (green "Remittance Errors" and "not posted" rows), E11, E12. Fix before handover, item 1.
|
|
- **F8 Endless re-runs / watchdog kill:** section 8, E16. Fix before handover, item 7.
|
|
- **F9 Stopping the bot the wrong way:** section 4 (no safe stop). Fix before handover, item 11.
|
|
- **F10 One stuck item blocks the queue:** E01, section 5. Fix before handover, item 12.
|
|
- **F11 Cause hidden from ops:** section 5 points only at the Report screen and the logs. Fix before handover, items 1, 13 and 14.
|
|
- **F12 Update didn't arrive:** section 10, section 9. Fix before handover, item 15.
|
|
|
|
## 13. Fix before handover (dev team)
|
|
|
|
| # | Gap | Why it hurts ops | Where (file:line) |
|
|
|---|---|---|---|
|
|
| 1 | "Rejected by app" and "Skipped" are stored with File Status Completed (green) | Ops reads green as posted, and rejected payments are missed | `bot.py:27-33` (STATUS_MAP) |
|
|
| 2 | "Payment not confirmed after Save" never re-checks ClaimDesk. The commit "raise save wait 10s to 20s" changed nothing (already 20 s at import). | Real posts show red, re-posting causes duplicates, and the batch is blocked | `bot.py:21`, `bot.py:117-118`, `bot.py:186` |
|
|
| 3 | The window search matches any title containing "ClaimDesk" (SQL tools, the launcher itself, the login window). The commit labelled "fix" only added a comment. It is also called straight after Sign in, with no wait. | The bot drives the wrong window | `bot.py:66-70`, `bot.py:83`, `bot.py:185` |
|
|
| 4 | `taskkill /im ClaimDesk.exe /f` kills every ClaimDesk on the machine | A user's own ClaimDesk session is closed | `bot.py:146` |
|
|
| 5 | Clinic cells are split on `,` and `;` | Real names containing a comma cannot be run, and blank pieces are created from trailing commas | `bot.py:62` |
|
|
| 6 | The cutoff is compared as text (`check_date > str(cutoff)`) | Payments are posted or deferred wrongly when the formats differ | `bot.py:107` |
|
|
| 7 | The watchdog heartbeat runs only per payment. Login, opening the clinic and list waits do not count, and `_last_beat` is set when the program loads. A kill skips cleanup. | Normal retries trigger the 300 s kill. ClaimDesk is left open and the batch stays open. | `bot.py:36`, `bot.py:39-49`, `bot.py:137` |
|
|
| 8 | A clinic is set to Success with no count check, even with 0 rows or red rows. Sign-in success is never checked. | Empty or failed clinics look done, and a wrong password looks like "clinic not found" | `bot.py:83`, `bot.py:140` |
|
|
| 9 | `data/poster.db` and its tables are never created by the code, and the `data` folder is not in the repo | A fresh machine crashes before any log line | `bot.py:20`, `bot.py:166-167` |
|
|
| 10 | Input and start-up errors (a missing sheet, the Pending-batch refusal) are not written to the run log, and `.env` keys `ALERT_SMTP` and `CLAIMDESK_PASSWORD_FALLBACK` are unused | Ops sees an empty log, and there are no alerts | `bot.py:54-63`, `bot.py:167-169` |
|
|
| 11 | No Stop button and no clean shutdown. It is unknown whether closing the launcher stops the bot. | Any stop leaves the batch open and blocks uploads | `bot.py:157-180`; launcher not in repo |
|
|
| 12 | An open batch blocks every new upload, there is no resume, and there is no way for ops to clear a batch or correct a row | One red row or one killed run stops all posting until dev edits the database | `bot.py:150-154`, `bot.py:167-168` |
|
|
| 13 | The Report screen hides `status` and `tech_comments`, and clinic and batch status are not shown anywhere ops can open | Ops cannot see whether a batch is blocking, or the developer cause | `report_screen.py:6` |
|
|
| 14 | No time stamp on Report rows. The log prints "[ERROR] [ERROR]". "[RUN SUMMARY] … done" is written even when the batch is not Completed. A clinic retry writes duplicate rows. | Rows can't be matched to the log, and "done" is misleading | `bot.py:122-126`, `bot.py:144`, `bot.py:180` |
|
|
| 15 | The launcher and update code are not in the repo, and the 1.3.0 "fix" is a comment only | Update failures can't be checked or fixed | `report_screen.py:8`, `report_screen.py:14` |
|
|
| 16 | `.env` and a run log are tracked in git. That run log contains a patient name. The ClaimDesk password sits in plain text in the input Excel. | PHI and credential exposure | `logs/run_20260901_101500.log:3`, `.env`, `bot.py:56` |
|
|
| 17 | `BOT_WAS_RUN` is written on every start and never read, and there is no lock against two runs at once | Two runs started together can both pass the open-batch check | `bot.py:161`, `bot.py:167` |
|