# Changelog Completed user stories for the AOSmith CMS. Newest first. Format: story ID, title, date completed, purpose, and acceptance criteria (as delivered). --- ## 2026-09-23 Reported done outside this repo’s earlier story writeups. Specs remain in the V4 doc. - CMS MAINT-1 — Centralise the SAP HTTP client - App SPEED-3 — Network call mid-NFC session - App SPEED-4 — Two submitOrder calls per configuration - App SPEED-5 — Order queue flushes in parallel - CMS QUAL-6 — Remove Series 350 configuration - CMS QUAL-7 — Series 460 models - CMS QUAL-8 — Canada Series 460, no in-app gas selection ### CMS Improvements — CAT-66 through CAT-80 Shipped on the admin CMS. QUAL-14 view-as is read-only, role-gated, bannered, and it expires on its own. QUAL-16 digests are email only. QUAL-19 reads `GOOGLE_MAPS_API_KEY` from the environment. MAINT-6 is an admin help portal that stores markdown and calls Gemini only from the Ask button. - CAT-80 QUAL-1 — Type and status on the orders filter - CAT-66 QUAL-3 — Stable API error codes, no stacks - CAT-67 QUAL-4 — API coverage for these paths - CAT-68 QUAL-9 — Operations dashboard counts - CAT-69 QUAL-10 — Saved order filters - CAT-70 QUAL-11 — Bulk resubmit, export, and triage tag - CAT-71 QUAL-12 — Internal notes hidden from non-staff - CAT-72 QUAL-13 — Audit log for status changes and view-as - CAT-73 QUAL-14 — Read-only view-as customer - CAT-74 QUAL-15 — Order pages past 1,000 rows - CAT-75 QUAL-16 — Email digest from a saved filter - CAT-76 QUAL-17 — Header quick find - CAT-77 QUAL-18 — Customer search by city, branch, and SAP account - CAT-78 QUAL-19 — Zip validation and Places autocomplete - CAT-79 MAINT-6 — Admin help articles and Ask ## 2026-07-29 ### CAT-57 — Investigate and resolve pending SAP/catalog edge cases (QUAL-21) **Status:** Completed **Purpose:** As a AOSmith operations team member, I want the invoicing discrepancy, ID number mismatch, and Smartsheet access items investigated and converted into actionable, scoped tickets, So that known but unscoped issues raised in the April 2026 team meeting get tracked and resolved rather than staying informal. **Acceptance criteria:** - Given customer-reported invoicing discrepancies, when investigated, then reproduction steps are documented and the order-to-invoice flow (Catalyst → SAP billing) is reviewed for a data mapping or display/formatting root cause. - Given observed ID number mismatches between Catalyst and SAP records, when investigated, then the Catalyst order ID, SAP document number, and any interim mapping layers are cross-referenced to identify the divergence source (data entry, transformation, or sync timing). - Given the team's request for Smartsheet access, when followed up, then the sheet owner is confirmed and sharing permissions are requested and granted. - Given each investigation concludes, when findings are documented, then they are converted into specific, scoped follow-up tickets rather than left open-ended. **Tech notes:** These are investigation spikes, not fixes — the deliverable is a root-cause writeup and scoped follow-up tickets per item. **Risks:** Root causes are unknown going in; investigation may reveal each item is larger than expected. AOS Team to help provide repro examples for the invoicing and ID mismatch issues. **Related:** [QUAL-21](docs/Catalyst%20Improvement%20Recommendations%20V4.md) (parent recommendation) ### CAT-51 — Build automated SAP error recovery and resync process (INFRA-9) **Status:** Completed **Purpose:** As a AOSmith operations team member, I want SAP submission failures to automatically retry and resync, So that I don't have to manually identify and resubmit failed orders, and order processing isn't delayed by manual monitoring. **Acceptance criteria:** - Given an order fails to submit to SAP, when the automated retry mechanism runs, then it retries on a configurable schedule (e.g. 5m, 15m, 1h). - Given an order exhausts its max retries, when it permanently fails, then it moves to a dead-letter queue surfaced in the admin dashboard (QUAL-9, CMS). - Given an order moves to the dead-letter queue, when that happens, then the team receives an email or Teams notification requiring manual intervention. - Given a retry may have partially succeeded, when reconciling, then SAP document numbers are used to detect and deduplicate partial successes (ties into INFRA-7). **Tech notes:** Configurable retry schedule; ties directly into INFRA-7 (idempotency) for safe retries and QUAL-9 (admin dashboard) for visibility. **Risks:** Retry storms against a degraded SAP instance could worsen an outage — apply backoff and caps. **Related:** [INFRA-9](docs/Catalyst%20Improvement%20Recommendations%20V4.md) (parent recommendation); INFRA-7, QUAL-9 ### CAT-50 — Implement deduplication for SAP order submissions (INFRA-7a) **Status:** Completed **Purpose:** As a AOSmith operations team member submitting orders through Catalyst, I want SAP retries to never create duplicate orders, line items, or conflicting follow-up calls, So that I can trust that a slow or timed-out SAP call does not double-submit a customer's order. **Acceptance criteria:** - Given an outbound SAP operation (config order, production order, return, or other integration), when it is retried, then a deterministic idempotency key or natural key prevents duplicate creation. - Given a duplicate submission attempt within the dedupe window, when Redis-backed short-lived dedupe is checked, then the duplicate is suppressed. - Given SAP APIs support it, when creating an entity, then the system queries before creating to avoid blind duplicate inserts. - Given SAP returns an “already exists” response, when handled, then it is treated as success rather than an error. **Tech notes:** Complements MAINT-1 (centralized SAP HTTP client). Applies to config orders, production orders, returns, and all other outbound SAP integrations. **Related:** [INFRA-7](docs/Catalyst%20Improvement%20Recommendations%20V4.md) (parent recommendation)