uatr

User flows

Flowcharts for Core ordering and Support & lookup.

Flowcharts for two journey groups of the web-ordering app: Core ordering (6 flows) and Support & lookup (3 flows). Each chart has a text version underneath. Click a “→ Flow” pill to jump to that flow.

How much of this was seen? Solid outlines were observed on screen in UAT. Dashed outlines marked † are read from the page source: they involve writing data (creating orders, emailing CS, overwriting Rx in POS, marking items checked), so they were not run. Treat them as the intended behaviour, to be confirmed in UAT.

Legend

LegendShapes used in the flowcharts.StartScreen / pageUser actionDecisionDialogSystem stepError stateEnd→ Another flowRead from code ††
Core orderingSupport & lookup

Core ordering

From a POS deposit bill to a submitted order, and what happens afterwards.

How the screens connect

Core ordering: how the screens connectSign in, Bills page, order form, review page, submitted order, orders page, plus the POS pull dialog and CS ticket dialog.Sign inBills pageBills › 'CS handling'tabPOS pull dialog(admin / supervisor)Order form†Review pageCS ticket dialogSubmitted order:held or confirmed†Cancel or back to edit(→ order form)†Orders pagePullOpenValidateBack to editBlockedCase openedConfirmTrackCancel

1 Triage deposit bills

Goal
Find the POS deposit bill that needs an order opened.
Who
Any signed-in user (bill list visible to all roles seen).
Evidence
Observed on screen.
Flow 1: Triage deposit billsFlowchart with 10 steps: Signed in → Bills page → Pick a status tab: → Pick a TOG sub-tab: → Search bill, branch, → Any results? …Signed inBills page(New tab by default)Pick a status tab:New · In progress · AllCS handling · HistoryPick a TOG sub-tab:All · TOG · No TOGSearch bill, branch,member or product(optional)Any results?Empty table(only a '0 bills' hint)Scan, sort or page;pick a bill→ Flow 3: open orderAuto-refresh from POSevery 15 minutesNoRefineYes
Text version of this flow
  1. After sign-in you land on the Bills page, on the 'New' tab.
  2. Choose a status tab: New, In progress (opening order), All, CS handling, or Document history. Tab counts update from the server.
  3. Optionally narrow by TOG sub-tab: all bills, bills with made-to-order TOG items, or bills without.
  4. Optionally search by bill number, branch, member or product, then press Search (Clear resets).
  5. If nothing matches, the table shows only its headers and a small '0 bills' note — there is no empty-state message.
  6. Sort by column, change page size or paginate, then pick a bill → Flow 3.

The page re-pulls deposit bills from POS automatically every 15 minutes.

2 Pull bills from POS on demand

Goal
Force an immediate refresh of deposit bills instead of waiting for the 15-minute cycle.
Who
Needs an admin or supervisor login (stated in the dialog).
Evidence
Dialog and the rejected-login path observed; the success path is from code (not completed).
Flow 2: Pull bills from POS on demandFlowchart with 12 steps: On the Bills page → Click 'Pull deposit bills → Dialog: confirm with an → Enter username → Confirm or → Dialog closes; …On the Bills pageClick 'Pull deposit billsfrom POS'Dialog: confirm with anadmin / supervisor loginEnter usernameand passwordConfirm orcancel?Dialog closes;nothing changesServer checks the login(POST /pos/refresh)Login accepted?Red message in dialog:'username or passwordis incorrect'Dialog closes; list andcounts reload†Alert: 'N new, N updatedbills pulled'†Back on the Bills pageCancelConfirmNoRetryYes
Text version of this flow
  1. On the Bills page click the 'pull deposit bills from POS' button.
  2. A dialog asks for an admin or supervisor username and password. Cancel closes it with no effect.
  3. On Confirm the server checks the login. A wrong login shows a red message inside the dialog (observed) and the user can retry.
  4. On success (from code) the dialog closes, the list and tab counts reload, and an alert reports how many bills were new and updated.
  5. If the server cannot be reached, the dialog shows a 'cannot contact server' message (from code).

Verified by submitting an invented username only; a real pull was never run.

3A Open an order and fill the order form

Goal
Turn a deposit bill into a validated order draft.
Who
Roles not verified (the form was not opened on a live draft).
Evidence
From page code. Opening an order creates data, so this was not run.
Flow 3A: Open an order and fill the order formFlowchart with 17 steps: Click 'Open order' → Server finds or creates → Already confirmed → → Flow 3B: review → Order form → Choose eye: …Click 'Open order'on a billServer finds or createsthe order draft†Already confirmedor held?†→ Flow 3B: reviewOrder form(editable draft)†Choose eye:right · left · both†Optional: pull the Rxfrom the POS exam†Fill frame, lens, glazingRx values, line docs†Save draft orsave & validate?†Draft saved('Draft saved' note)†Validation passes?†Errors listed; draft issaved but can't submit†Rx differs fromPOS exam?†Dialog: confirm theRx differences†Override confirmed?†Differing fieldsare highlighted†→ Flow 3B: reviewYesNoDraftKeep editingSave & validateNoFixYesYesNoEditNoYes
Text version of this flow
  1. 'Open order' asks the server for the draft. If it is already confirmed or held, you go straight to the Review page; otherwise the order form opens.
  2. Choose the eye(s) to order: right, left or both. Optionally pull the Rx from the POS exam.
  3. Fill frame SKU and type, lens item, glazing location, Rx values (SPH, CYL, AXIS, ADD, PD) and the per-line document choices for FS items. Helpers: check frame stock, lens finder, swap R/L.
  4. 'Save draft' stores the form and stays on the page.
  5. 'Save and validate' checks required Rx fields, AXIS range (0–180), formats and pending FS line documents. Failures list the problems; the draft is still saved but cannot be submitted.
  6. If the typed Rx differs from the POS exam, a dialog asks you to confirm the override; declining highlights the differing fields.
  7. When everything passes the draft becomes 'ready' and you move to Flow 3B.

Dashed outlines (†) are read from page code, not observed.

3B Review, confirm and submit to BC

Goal
Lock the order and create the sales and transfer documents (SO / TO) in Business Central.
Who
Roles not verified.
Evidence
Page load observed; confirm and submit logic is from code (not run — it creates documents).
Flow 3B: Review, confirm and submit to BCFlowchart with 14 steps: Review page opens → Loads draft, files, → Blocking issue? → → Flow 5: CS ticket → Click 'Confirm order' → Server locks the order …Review page opensLoads draft, files,delivery preview, stockcheck and CS ticketBlocking issue?†→ Flow 5: CS ticketClick 'Confirm order'†Server locks the order†Auto-submit: create SO(and TO) in BC†Result?†Hold banner: countdownto send to TOG factory†→ Flow 4: hold / cancelRed banner: 'confirmedbut BC submit failed'†Click 'Submit to BCagain' (same SO reused)†Green banner: SO / TOnumbers; order read-only†→ Flow 6: track the orderYesNoHeldFailedRetrySuccess
Text version of this flow
  1. The Review page loads the draft, attached files, delivery preview, frame stock check and any CS ticket (all read-only).
  2. If stock is short, the item is a drill-frame job, or the bill is outside the automatic-order scope, the confirm button turns red and opens a CS ticket instead (Flow 5).
  3. Otherwise 'Confirm order' locks the order and immediately submits it to Business Central.
  4. Held: some TOG routes wait before sending — a countdown banner appears (Flow 4).
  5. Failed: a red banner says the order was confirmed but the BC submit failed; 'Submit to BC again' retries safely and reuses the existing SO.
  6. Success: a green banner shows the SO (and TO) numbers with links to BC; the order is now read-only and a cancel window opens.
  7. Special cases: only an SO without a TO is shown as 'incomplete' and offers the retry; documents created by CS stay in 'Open' status until released in BC.

Order status then continues in Flow 6.

4 Cancel an order or go back to edit

Goal
Stop or correct an order after it was confirmed.
Who
Roles not verified.
Evidence
From page code (the dialogs were not triggered).
Flow 4: Cancel an order or go back to editFlowchart with 17 steps: Open a submitted → Order state? → Held: countdown to → What next? → Click 'Cancel (not sent)' → Timer ends; server …Open a submittedorder's review pageOrder state?†Held: countdown tosend is running†What next?†Click 'Cancel (not sent)'and confirm†Timer ends; serversends to TOG†Click 'Back to edit'and confirm†Order form again;nothing was created→ Flow 3B: result→ Flow 3A (timer resets)Green banner shows;cancel button visibleinside the window†Click 'Request cancel',confirm, give a reason†Ticket opened for CS('Ticket #…')†CS cancels documentsin BC / TOG; page reloadsConfirmed, but no BCdocument yet†Click 'Back to edit(unlock)' and confirm†→ Flow 3A: order formHeldCancelWaitEditSentLocked
Text version of this flow
  1. Held (TOG hold timer running): nothing exists in BC or at the factory yet. 'Cancel (not sent)' asks for confirmation, cancels free of charge and returns to the order form. 'Back to edit' unlocks the order and restarts the timer after the next submit. Doing nothing lets the timer end and the server send the order.
  2. Sent and inside the cancel window (shown with the 'Request cancel' button and its deadline): the user confirms and gives a reason; the system opens a CS ticket and CS cancels the documents in BC / the TOG factory.
  3. Confirmed but no BC document yet: 'Back to edit (unlock)' confirms, unlocks, and returns to the order form.
  4. If an SO exists but the TO failed, editing is disabled ('document already in BC'); only the retry from Flow 3B is offered.

Once documents exist in BC, changes must be made in BC by CS — the page says so.

5 Raise a CS ticket

Goal
Hand an order the system cannot auto-process to the customer-service team.
Who
Roles not verified.
Evidence
Dialog opened and cancelled (observed); sending is from code — it emails CS, so it was not sent.
Flow 5: Raise a CS ticketFlowchart with 14 steps: On the Review page → Blocking issue? → → Flow 3B: confirm → Click the red 'Open case → Dialog: 'Open ticket to → Send or cancel? …On the Review pageBlocking issue?→ Flow 3B: confirmClick the red 'Open casefor CS' button†Dialog: 'Open ticket toCS' — fixed recipient,auto subject, noteSend or cancel?Dialog closesServer emails the CSshared inbox†Sent OK?†Red text in dialog(Send re-enabled)†Ticket status on page(open → in progress…);'Resend' available†Bill listed under the'CS handling' tab†CS creates SO/TO in BCin Open status†CS releases in BC;order continuesNoYesCancelSendNoRetryYes
Text version of this flow
  1. 'Blocking issue' means: not enough stock, a drill-frame job, or a bill outside the automatic-order scope. The main button turns red and says to open a case for CS.
  2. Click it: a dialog shows the CS shared inbox (fixed), the subject (filled in automatically) and an optional message.
  3. Cancel closes the dialog. Send emails the order details to CS; if it fails a red message appears in the dialog and you can retry.
  4. On success the page shows the ticket's status (with a Resend option) and the bill appears under the 'CS handling' tab on the Bills page.
  5. CS then creates the SO/TO in BC. Documents created by CS start in 'Open' status and are not visible to the warehouse until someone releases them in BC.

6 Track submitted orders and confirm receipt

Goal
Follow an order from BC to the branch and close it when the goods arrive.
Who
Branch and head-office users; the manual TOG status control may be limited by role (not verified).
Evidence
List, filter and empty state observed; timeline, TOG status and receipt are from code (they write data).
Flow 6: Track submitted orders and confirm receiptFlowchart with 14 steps: Open 'Track orders' → Orders list (latest 200; → Filter by order no., → Any match? → Row: 'No orders match' → Click an order row to …Open 'Track orders'from the top barOrders list (latest 200;status from BC/WMS/POS)Filter by order no.,bill, SO/TO or branch;click SearchAny match?Row: 'No orders match'Click an order row toexpand its timeline†Grouped status timeline(+ TOG status if any)†TOG status torecord manually?†Pick status + note,confirm, save†Goods arrived atthe branch?†Wait: status updatesautomaticallyClick 'Received' andconfirm†Server records receipt;list reloads†Order closed as receivedNoRefineYesYesSavedNoNot yetYes
Text version of this flow
  1. The Orders page lists orders already sent to BC; status updates arrive automatically from BC, the warehouse system and POS.
  2. Filter by order number, POS bill, SO/TO or branch code and press Search. No match shows a single 'no orders match' row.
  3. Click a row to expand its grouped status timeline (and the TOG factory status, if any).
  4. For TOG orders without an API status, a control lets the user pick a status and add a note; it asks for confirmation before saving.
  5. When goods reach the branch, 'Received' (after a confirmation) closes the order immediately. If nobody presses it, the system closes the order when POS/BC confirm receipt.

Support & lookup

Lookups and clean-up tasks that support ordering.

How the screens connect

Support and lookup: how the screens connectTop bar leads to the stock page, the Rx page and the tracking page with its history drawer; the order form reuses the stock and Rx lookups.Top bar / user menuStock pageRx values (POS) pageTracking pageHistory drawerOrder form: 'Checkframe stock'†Order form: 'Pull Rxfrom POS'†Top-bar linkClick a rowSame lookupSame exam data

7 Check stock (frame or branch)

Goal
Find out whether a frame or product is available.
Who
All roles seen; branch-role users do not get the shop picker (code).
Evidence
Both search cards and the unknown-SKU error observed; branch lookup details are from code.
Flow 7: Check stock (frame or branch)Flowchart with 15 steps: Open 'Check stock' → Which check? → Type a frame code → Click 'Check stock' → Live lookup in BC → Stock found? …Open 'Check stock'from the top barWhich check?Type a frame code(e.g. FOESE…)Click 'Check stock'Live lookup in BC(frame warehouse)Stock found?'N pcs @ location' shown+ other locationsNo stock at location, oronly reserved stock;other locations listedPick a branch (hiddenfor branch-role users)†Type product code, nameor barcode (min. 2 chars)Click 'Search'Input valid?Red text: 'type at least2 characters' or 'choosea branch'†Branch stock lookup(POS)†Results list forthat branch†Frame codeYesNoBranch stockNoFixYes
Text version of this flow
  1. Two independent checks sit on one page.
  2. Frame check: type a frame code, press 'Check stock'. The result is either 'N pcs @ location' or a red line saying there is none at that location (or only reserved stock), plus the other locations.
  3. Branch check: pick a branch (not shown for branch-role users), type at least 2 characters of a product code, name or barcode, press Search. Missing input shows a red hint; otherwise a results list appears.

The order form has its own 'Check frame stock' button that uses the same frame lookup.

8 Look up and edit a customer's Rx

Goal
Correct a customer's prescription values held in POS.
Who
Roles not verified. Writes to the POS database.
Evidence
Search, environment banner and empty state observed; editing and saving are from code (saving overwrites POS data, so it was not run).
Flow 8: Look up and edit a customer's RxFlowchart with 15 steps: Open 'Rx values (POS)' → Page checks which POS → Type member code, name → Click 'Search' → Found? → 'No customers match' …Open 'Rx values (POS)'from the top barPage checks which POSdatabase it is wired toType member code, nameor phone; pick Rx typeand page sizeClick 'Search'Found?'No customers match'Edit SPH / CYL / AXIS /ADD / PD for each eye;row turns dirty†Click 'Save' on the row†Confirm dialog: member,Rx type overwritten,POS database, server†Confirm?†Nothing writtenOverwrite the Rx in POS(new exam if none)†Saved?†Red message in the row;Save re-enabled†'Saved' (+ 'new examcreated'); row is clean†NoRefineYesCancelConfirmNoRetryYes
Text version of this flow
  1. The page first checks which POS database it is connected to and shows it in a banner (the UAT build shows a test source).
  2. Search by member code, name, surname or mobile number; choose which Rx type to show (default: the lens-cutting values) and the page size.
  3. Results list each customer with right and left eye values. No match shows 'no customers match'.
  4. Edit the values; the row is marked dirty and its Save button enables.
  5. Save opens a confirmation that names the member, the Rx type being overwritten, the POS database and server. Cancel writes nothing; Confirm overwrites the values (and creates a new exam if none existed). Errors appear in red on the row.

Edits overwrite the selected Rx type only, per the page text.

9 Handle stuck or failed jobs

Goal
Find orders that errored on the way to BC / TOG and record that someone dealt with them.
Who
'Mark as checked' is limited to cs, admin and supervisor (code); other roles see the list read-only.
Evidence
List, tabs, drawer and read-only history observed; the resolve action is from code (it writes data).
Flow 9: Handle stuck or failed jobsFlowchart with 12 steps: Open 'Track outstanding → Tracking list → Pick a tab: Issues, Open, → Optional: export to XLSX → Click a row → Side drawer: history, …Open 'Track outstandingjobs' (user menu)Tracking listPick a tab: Issues, Open,All; filter by branchor searchOptional: export to XLSX†Click a rowSide drawer: history,send attempts, TOGstatus, CS ticketIssue open and youare cs / admin /supervisor?Read-only; close drawerOptional note, e.g.'opened SO manually'†Click 'Mark as checked'and confirm†Server recordswho and when†Row shows 'checked';list reloads; itemleaves Issues†NoYes
Text version of this flow
  1. Open the tracking page. Tabs: Issues, Open, All; filter by branch or search text. An XLSX export is available.
  2. Click a row to open the side drawer with the order's status history, send attempts, TOG status and CS ticket.
  3. If the order has an unresolved issue and your role is cs, admin or supervisor, a 'mark as checked' form appears with an optional note.
  4. After confirmation the system records who checked it and when; the row shows as checked and leaves the Issues tab.
  5. Marking as checked only closes the item on this page — it does not change the order itself.

Clicking a table row is a mouse-only action (no keyboard route) — noted in the audit.

Open questions