This original template focuses on purchase-request stages and the evidence behind their dates. It separates today's waiting age from the elapsed time of a completed request-to-PO cycle. No purchasing action occurs in the example.
Start with a fixed snapshot and distinct dates
Spendflo's published dashboard guidance describes a request pipeline using the current stage and the date a request entered it. It separately defines request-to-PO time using the request and PO endpoints. The example here uses a smaller, original date-only ledger and a fixed snapshot rather than a changing current-date calculation. Spendflo's procurement dashboard guidance
Set the snapshot to October 13, 2026. Count elapsed calendar days by subtracting the recorded date from that snapshot; these are not business days or full timestamp-based durations.
| Request | Current stage | Current-stage entry | Request date | PO issue date | Result at October 13 |
|---|---|---|---|---|---|
| R1 | Awaiting approval | October 10 | Not supplied | Not supplied | 3 calendar days waiting |
| R2 | Awaiting quote | October 8 | Not supplied | Not supplied | 5 calendar days waiting |
| R3 | PO issued | Not used for waiting age | October 6 | October 11 | Completed request-to-PO: 5 days |
| R4 | Awaiting approval | Unknown | Not supplied | Not supplied | Waiting age unknown |
This is a fictional ledger. Its statuses and supplied endpoint dates are sample record facts, not actual approvals or issued purchase orders. The maintained record needs references to the evidence supporting those facts.
Count the queue before summarizing its age
Three requests are outstanding: R1, R2, and R4. Two await approval; one awaits a quote. R3 is in the separately reported PO-issued group. The approval view must retain R4 even though its age is unknown.
For approval, show “2 requests; 1 known age of 3 days; 1 unknown age.” For quotes, show “1 request; known age 5 days.” If the display offers a longest-known-wait measure, qualify it as known: the missing date could change which request has actually waited longest. Do not apply invented “slow” or “stuck” thresholds to these numbers.
The date needed for R4 is the date it entered its current approval stage. Its request date, even if later supplied, would answer a different timing question. Ask for the stage-transition evidence instead of filling the blank with the snapshot date.
Keep completed cycle time in a separate panel
Only R3 has both supplied endpoints for a completed request-to-PO cycle: October 11 minus October 6 equals five calendar days. The completed-cycle mean is therefore five days, with n = 1. Show the request ID and endpoints beside that figure.
Open requests are excluded from this completed-cycle calculation. They are not zero-day completions, and their present waiting ages are not completed request-to-PO durations. With no eligible completed records, the mean should read “No completed cycles with both endpoints,” rather than zero. One completed example also does not establish typical supplier or team performance.
Make every drill-down answer a handoff question
The native workbook specification should separate the request ledger, stage-transition evidence, completion evidence, and snapshot summary. A request-detail record needs its current stage, entry date or explicit unknown, source reference, evidence still needed, and next handoff to check. Leave unsupplied actual approval and PO references blank.
The companion can filter the current stage and reveal these details. Filtering to approval must show both R1 and R4, including R4's missing age. The completed-cycle panel should retain its own scope and denominator, not quietly turn into an approval-wait average. If a stage-entry date is after the snapshot, flag it as invalid for this calculation rather than display negative waiting days. Check dates and sequence before including a completed cycle.
Keep approval and PO issuance in the authorized purchasing process. A workbook label, dashboard filter, or proposed next step does not approve a request. Promote a maintained status only when the required documentation exists and the actual workflow permits it.
Copy this prompt for a request-stage dashboard packet
Create one complete, self-contained US-English HTML companion for “Request waiting ledger”. Return the full HTML document, with inline CSS and any JavaScript needed for the local interactions. Use the original scenario, named records, numbers and expected cases below.
Design the page for this task: use clearly labeled input or source records, a readable result or worked example, and an adjacent explanation of the evidence. Use a restrained visual hierarchy, left-aligned text, readable tables or stacked records, and a responsive layout at 720px and 360px. Provide meaningful labeled controls for All outstanding; Approval; Quote. Use keyboard-accessible native controls and visible focus. Keep the complete content readable without an external dependency.
The following brief supplies the substantive content and constraints. Native-format requests describe the material to represent or copy manually; this HTML must not pretend to create DOCX, XLSX, PDF, PPTX, H5P or another native file, run Python/Flask/Django/Snowflake/Power BI, connect a live service, send messages, or perform an authorized real-world action. Where the task requires a native source, actual observation or separate approval, retain that requirement and leave unsupplied evidence blank.
Create a complete US English procurement dashboard review packet and native-workbook specification focused on purchase requests, current-stage waiting and completed request-to-PO cycles. Do not authorize, approve, buy or send anything. Use a fixed date-only snapshot: October13,2026. Elapsed days are calendar-date subtraction, not business days. Fictional records:
R1 Awaiting approval, entered October10: age3days; request/PO dates not supplied. R2 Awaiting quote, entered October8: age5days; request/PO dates not supplied. R3 PO issued October11, requested October6: completed cycle5days; no current waiting age. R4 Awaiting approval, stage-entry unknown: ageunknown; request/PO dates not supplied. Outstanding3=approval2+quote1; POissued1 separately. Approval view must include R4:2requests,1knownage3days,1unknown. Quote view:1request,knownage5days. Do not invent SLA thresholds or treat unknown as zero. Completed-cycle mean5days,n1,from R3 endpoints only. Exclude all open requests; zero eligible completed cycles gives undefined mean/no eligible cycles,notzero. Specify requestledger,stage-entry evidence,completion evidence and snapshot summary. Detail views retain source references,unknowns,evidence needed and handoff question. Leave actual approvals/POreferences blank. Require documented authority/evidence before status promotion; sample status is not actual purchase authorization. If proposing HTML filtering, approval showsR1andR4 and missingage; completionpanel retains separate scope/n. Futurestage-entry isinvalid,notnegativewait; validate completion endpoint order. No purchase/send/approve buttons,ERPsync or financial savings/performance claims. Controls and workbook execution remain to be built/tested; native purchasing record stays authoritative.
COMPLETE AUTHORED SCENARIO AND EXPECTED CASES
The following is the supplied reading/teaching/calculation record to represent in the companion. Preserve its particular content, examples, source references and unknowns. Wording about a future native implementation refers to that native task, not permission to omit this HTML companion.
# A Procurement Dashboard Template for Seeing Where Requests Are Waiting
An approval queue contains two purchase requests, but only one has a stage-entry date. Reporting a three-day average would make the second request disappear from the waiting-time picture. Reporting it as zero days would invent a fact. Keep both requests in the queue count and show the missing age separately.
This original template focuses on purchase-request stages and the evidence behind their dates. It separates today's waiting age from the elapsed time of a completed request-to-PO cycle. No purchasing action occurs in the example.
## Start with a fixed snapshot and distinct dates
Spendflo's published dashboard guidance describes a request pipeline using the current stage and the date a request entered it. It separately defines request-to-PO time using the request and PO endpoints. The example here uses a smaller, original date-only ledger and a fixed snapshot rather than a changing current-date calculation. [Spendflo's procurement dashboard guidance](https://www.spendflo.com/template/procurement-dashboard-template)
Set the snapshot to October 13, 2026. Count elapsed calendar days by subtracting the recorded date from that snapshot; these are not business days or full timestamp-based durations.
| Request | Current stage | Current-stage entry | Request date | PO issue date | Result at October 13 |
| --- | --- | --- | --- | --- | --- |
| R1 | Awaiting approval | October 10 | Not supplied | Not supplied | 3 calendar days waiting |
| R2 | Awaiting quote | October 8 | Not supplied | Not supplied | 5 calendar days waiting |
| R3 | PO issued | Not used for waiting age | October 6 | October 11 | Completed request-to-PO: 5 days |
| R4 | Awaiting approval | Unknown | Not supplied | Not supplied | Waiting age unknown |
This is a fictional ledger. Its statuses and supplied endpoint dates are sample record facts, not actual approvals or issued purchase orders. The maintained record needs references to the evidence supporting those facts.
## Count the queue before summarizing its age
Three requests are outstanding: R1, R2, and R4. Two await approval; one awaits a quote. R3 is in the separately reported PO-issued group. The approval view must retain R4 even though its age is unknown.
For approval, show “2 requests; 1 known age of 3 days; 1 unknown age.” For quotes, show “1 request; known age 5 days.” If the display offers a longest-known-wait measure, qualify it as known: the missing date could change which request has actually waited longest. Do not apply invented “slow” or “stuck” thresholds to these numbers.
The date needed for R4 is the date it entered its current approval stage. Its request date, even if later supplied, would answer a different timing question. Ask for the stage-transition evidence instead of filling the blank with the snapshot date.
## Keep completed cycle time in a separate panel
Only R3 has both supplied endpoints for a completed request-to-PO cycle: October 11 minus October 6 equals five calendar days. The completed-cycle mean is therefore five days, with `n = 1`. Show the request ID and endpoints beside that figure.
Open requests are excluded from this completed-cycle calculation. They are not zero-day completions, and their present waiting ages are not completed request-to-PO durations. With no eligible completed records, the mean should read “No completed cycles with both endpoints,” rather than zero. One completed example also does not establish typical supplier or team performance.
## Make every drill-down answer a handoff question
The native workbook specification should separate the request ledger, stage-transition evidence, completion evidence, and snapshot summary. A request-detail record needs its current stage, entry date or explicit unknown, source reference, evidence still needed, and next handoff to check. Leave unsupplied actual approval and PO references blank.
The companion can filter the current stage and reveal these details. Filtering to approval must show both R1 and R4, including R4's missing age. The completed-cycle panel should retain its own scope and denominator, not quietly turn into an approval-wait average. If a stage-entry date is after the snapshot, flag it as invalid for this calculation rather than display negative waiting days. Check dates and sequence before including a completed cycle.
Keep approval and PO issuance in the authorized purchasing process. A workbook label, dashboard filter, or proposed next step does not approve a request. Promote a maintained status only when the required documentation exists and the actual workflow permits it.
Implement the local companion rather than returning a text-only plan. Preserve every numerical fixture and the distinction between illustrative expectations and actual evidence. Any native-runtime or classroom tests mentioned above remain tests to perform in the proper environment; do not mark them passed. Keep edits and practice responses in this open page only, without claiming persistent storage. Provide invalid/missing-input feedback and reset behavior that agree with this specific brief. Do not claim accessibility certification, learning gains, real approvals or test results that were not observed.
Review the waiting evidence
After any proposed filters are built and tested, use the copy to inspect the missing evidence with colleagues. Keep actual stage changes and purchasing decisions in the maintained procurement workflow.
Close the review by identifying who will find R4's stage-entry evidence, while keeping all three outstanding requests visible until their documented handoffs occur.