2026 Q2: Research, Entitlements & Mobile Foundations

Acceptance Criteria

• `Customer` and `Location` expose an `AdministrativeRegion` text field alongside `Country`, `State`, and `City`.
• The field is intended for values such as states, provinces, departments, and regions (for example `Bayern`, `Texas`, `Antioquia`).
• The design remains easy to populate directly from reverse-geocoding results without foreign-key lookup complexity.
• Existing access-control rules for transactional data remain unchanged.
• Any indexing/search optimization remains implementation-owned and transparent to users.

---

Acceptance Criteria

• Internal research can compute aggregated peer signals for the same city, region, country, and optionally sales area.
• Benchmark outputs include measures such as average quote size, common product classes, win/loss trends, and margin bands.
• All cross-customer outputs are anonymized and aggregated; no raw customer or quote details from other accounts are exposed.
• Responses include confidence and/or sample-size signals so low-data regions do not look falsely precise.
• Tests cover confidentiality guardrails and empty-data behavior.

---

Acceptance Criteria

• A starter commodity/macro catalog is defined for signals such as diesel, WTI, Brent, natural gas, electricity, steel, copper, aluminum, CPI, and PPI.
• The model supports mapping from product family, industry, or sales pattern to one or more relevant indicators.
• Deep Research can attach price-spike / inflation warnings when mapped indicators move materially.
• The initial rule set is documented and easy to extend in later quarters.

---

Acceptance Criteria

• A portfolio-level Deep Research action exists and returns deterministic KPI, benchmark, and signal structures.
• The analytics envelope distinguishes benchmark states, anomalies, and recommended next actions.
• Portfolio scope respects the current Sales Area access boundaries rather than bypassing them.
• Remaining backlog work is clearly about UX/productization and release criteria, not about inventing the baseline analytics model from zero.

---

Acceptance Criteria

• Back-end entities or equivalent models exist for `ResearchSource`, `ResearchProfile`, `ResearchRun`, and `ResearchFinding`.
• Source metadata supports category, priority, enablement flag, API-key requirement, confidence weight, and freshness/cache TTL.
• Each research run records which sources were attempted, which succeeded, execution time, and any non-sensitive error summary.
• Findings are stored in a normalized form that can later be rendered as text, KPI, table, chart, or map blocks.

---

Acceptance Criteria

• Each source is implemented as a standalone adapter with a normalized return contract (`findings`, `sources`, `confidence`, `freshness`, and error state).
• The orchestrator can run multiple sources in parallel and continue when one source fails or a key is missing.
• Missing keys or transient provider errors are surfaced as structured warnings, not hard failures for the overall research request.
• Caching / freshness policy is applied per source to avoid unnecessary repeat calls.
• Logging clearly identifies source code, execution time, and sanitized failure reason.

---

Acceptance Criteria

• `Wikipedia` is used for company grounding, sector/context, history, and public footprint when available.
• `Yahoo Finance` is used for ticker/company profile, market context, public-company news, and commodity price pulls where relevant.
• The research flow handles public and private companies gracefully, avoiding false precision when a company has no market listing.
• Source citations are stored and shown in the assistant output.

---

Acceptance Criteria

• `Open-Meteo` is integrated as a no-auth source for quote location and/or plant location weather conditions.
• Deep Research can summarize next-day / short-horizon risks such as heavy rain, snow, heat, wind, or storms when relevant.
• The weather output is phrased as commercial/logistics guidance rather than raw meteorological dumps.
• The design is reusable for future Sales Order / LEP scenarios.

---

Acceptance Criteria

• Initial source set includes `FRED`, `EIA`, and at least one of `World Bank`, `ECB/Eurostat`, or `GSCPI` depending on region applicability.
• Indicators are mapped into plain-language commercial signals such as inflation pressure, energy-cost pressure, and supply-chain stress.
• The system can distinguish between global indicators and region-specific indicators so outputs stay relevant to the quote geography.
• Tests or fixtures validate parsing and resilience for each selected source.

---

Acceptance Criteria

• Premium providers (for example `Perplexity`) are disabled by default and only run when keys/configuration are present.
• Premium enrichment is invoked after internal + free-source passes, not instead of them.
• Research metadata clearly shows when premium enrichment was used and why.
• Failure or absence of premium providers does not reduce baseline research availability.

---

Acceptance Criteria

• The assistant response contract supports at least: `summary`, `kpis`, `table`, `chart`, `map`, `sources`, and `actions`.
• The UI can gracefully fall back to text-only rendering when a block type is unavailable.
• Source references and confidence information are included in a reusable way across all block types.
• The contract is reusable for Quote Deep Research first and extensible to future assistant scenarios.

---

Acceptance Criteria

• The popover can render a concise summary, KPI-style values, a top-N table preview, and source transparency links.
• Compact status/criticality cues are shown for opportunity, risk, and confidence.
• The layout remains readable in the existing assistant popover and degrades gracefully on smaller screens.
• An `Open full analysis` action is available whenever richer content exists.

---

Acceptance Criteria

• A full analysis surface exists as an expanded dialog, side panel, or quote facet linked from the assistant popover.
• The view uses Fiori/SAPUI5 visualization patterns such as `sap.f.Card`, `VizFrame`, and map-capable controls where appropriate.
• It can render at least one chart-based trend, one structured opportunity table, and one map/logistics/weather view.
• The view follows progressive disclosure: preview in popover, richer exploration in the expanded surface.

---

Acceptance Criteria

• Every rendered insight includes source/citation visibility and a clear confidence signal.
• Actions such as `Open full analysis`, `Refresh research`, and future export/share hooks are designed into the result model.
• The UI distinguishes between internal signals, public free sources, and optional premium enrichment.
• The design remains consistent with existing assistant safety, sanitization, and bounded-action policies.

---

Acceptance Criteria

• `QuoteHeaders` exposes `importFromERP(documentNumber, salesAreaId, documentCategory)` and supports both active and draft contexts.
• Category `G` uses `API_SALES_CONTRACT_SRV/A_SalesContract?$expand=to_Item,to_Partner,to_PricingElement,to_Text`.
• Category `B` uses `API_SALES_QUOTATION_SRV/A_SalesQuotation?$expand=to_Item,to_Partner,to_PricingElement,to_Text`.
• Imported header data resolves Sales Area and Document Type from ERP codes and local customizing.
• Upsert updates only ERP-mapped fields and keeps existing local extension fields intact.
• Quote items are upserted by ERP item number where available; unresolved product codes are skipped with warnings.

---

Acceptance Criteria

• `QuoteHeaders` exposes the same `SearchInERP` explicit-search pattern used in the other hybrid-search apps.
• Normal quote list reads stay local-first and do not trigger backend quote imports unless `SearchInERP` is enabled.
• Explicit quote ERP search applies the selected Sales Area to the S/4 contract and quotation reads.
• The quote-search path fetches current-page header details in batched form rather than one backend detail request per document.
• Missing sold-to, ship-to, and product master data are resolved locally first and then fetched from S/4 only for the missing codes.

---

Acceptance Criteria

• A static inventory script scans CAP registrations, CDS projections/actions, mounted REST routes, and UI controllers/fragments.
• Generated approuter assets under `app/router/resources` are excluded from dead-code analysis.
• CAP handlers and mounted assistant REST/stream routes write aggregated daily usage into a persistent table instead of one row per request.
• A confidence report ranks candidates using static references, runtime hits, and optional coverage data when available.
• Documentation explains why the approuter exists in the deployed BTP model and how the monitoring workflow should be run.

Acceptance Criteria

• A new CDS entity is associated with `SalesArea`.
• The entity stores a customer or commercial-group identifier, active state, validity window, and schema version.
• The model supports one community-grant Sales Area and additional commercial activations.
• The new entity does not change the existing runtime flags or the core Sales Area business model.

---

Acceptance Criteria

• The server reads the manifest through the configured BTP destination.
• The endpoint can remain read-only and ungated.
• The response is cached until the manifest validity window expires.
• The system refreshes the cache when needed without repeated calls on every request.

---

Acceptance Criteria

• The current flag names and their UI effects remain unchanged.
• The server sets those flags from cached entitlement data.
• A missing or expired manifest falls back to a safe default.
• The flag derivation is testable and does not require writing env vars at runtime.

---

Acceptance Criteria

• The backend can mark a Sales Area as active or inactive for license purposes.
• One granted Sales Area can consume the community allowance within a commercial group.
• Additional Sales Areas in the same commercial group require a valid commercial activation record.
• The Sales Area config surfaces the active/inactive state clearly.

---

Acceptance Criteria

• Tests cover manifest fetch and cache refresh behavior.
• Tests cover the safe fallback when the manifest is missing or expired.
• Tests cover the transition from community-grant consumption to commercial activation.
• The regression suite documents the named Sales Area activation rule explicitly.

---

Acceptance Criteria

Acceptance Criteria

• The entitlement client has an explicit timeout budget and documented fallback behavior for slow or unavailable UVA endpoints.
• Repeated entitlement refresh failures do not create unbounded retry loops or block normal non-entitlement request paths.
• Error state, last-success state, and operator-facing diagnostics remain visible when fallback behavior is used.
• Tests cover timeout, network failure, invalid payload, and repeated-failure scenarios without calling live UVA endpoints.
• The story hardens the current snapshot-based implementation without overstating progress toward the separate manifest/BTP-destination target state.

---

Acceptance Criteria

• The Sales Areas list report exposes a bulk-update action for selected rows.
• The action can update `IsActiveInSEP` and `S4_SyncEnabled` together or independently.
• Local Community Grant enforcement remains server-side and rejects bulk activations that would leave more than one Sales Area active.
• Enabling backend sync through the bulk action reuses the same defaulting and validation rules as single-record maintenance.
• Regression tests cover the bulk update path and the community-grant guardrail.

---

Acceptance Criteria

• The PDF export path validates that the requested quote is visible to the current user.
• The route cannot return a PDF for a quote the user is not allowed to access.
• Active and draft variants follow the same access policy.
• The implementation reuses the existing access-control model rather than inventing a separate one.

---

Acceptance Criteria

• PDF data assembly relies on the same secured quote retrieval semantics as normal reads where practical.
• Direct `SELECT` usage is minimized or wrapped in an explicit authorization guard.
• The PDF route remains compatible with draft and active quote handling.
• The implementation keeps the existing PDF rendering behavior intact.

---

Acceptance Criteria

• Tests prove unauthorized users cannot export PDFs for out-of-scope quotes.
• Tests cover active and draft quote variants.
• Tests verify the happy path still produces the expected PDF response.
• The regression suite calls out the direct route explicitly.

---

Acceptance Criteria

• The app includes a visible About or Licensing surface in the Config or Settings area.
• The surface references the root `LICENSE`, `LICENSE-MIT`, `LICENSE-SCOPE.md`, and `NOTICE` files.
• The license text can open in a modal or dedicated screen.
• The design works online and offline.

---

Acceptance Criteria

• Company/source attribution appears in a persistent or easy-to-find place in the app.
• The mobile surfaces include the equivalent of the current company attribution and repo/source buttons.
• Source links remain accessible from the UI.
• The implementation does not depend on a network round-trip to show attribution.

---

Acceptance Criteria

• The app can display a simple community / testing / commercial state indicator.
• The indicator is visible in settings or a comparable app surface.
• The design remains lightweight and does not block normal app usage.

---

Acceptance Criteria

• A test or build-time check confirms the mobile app still includes the chosen attribution surface.
• The check is easy to update when the mobile UX is finalized.
• The check does not enforce behavior changes unrelated to licensing.

---

Acceptance Criteria

• The action is available from the Sales Areas object page or equivalent config surface.
• The action opens a modal with license summary, source links, and current entitlement state.
• The design does not rely on a footer.

---

Acceptance Criteria

• The existing flags continue to govern the current attribution surfaces.
• The new About action adds discovery, not a second source of truth.
• The implementation does not remove or rename the current license-related runtime signals.

---

Acceptance Criteria

• A UI or integration check confirms the Sales Area config entry point is present.
• The check covers the modal or screen that presents license information.
• The check remains easy to update when the final UX is settled.

---

Acceptance Criteria

• The mobile app has a shared map abstraction that works across native and web builds.
• Runtime map configuration can be loaded from backend-driven endpoints or safe local defaults.
• The abstraction keeps provider/runtime concerns out of individual screens.
• Remaining backlog work is focused on rollout validation and UX, not on creating the shared map layer from scratch.

---

Acceptance Criteria

• Geofence draft state can be stored locally with stable storage keys.
• Runtime map policy includes explicit offline/provider rules instead of hidden assumptions.
• The foundation is documented as partial where advanced editing and download UX are still missing.
• Remaining backlog work is about editor completion and operator UX, not about inventing local persistence for map state.

---

Acceptance Criteria

• The app offers a defined operator/user flow for downloading, refreshing, or invalidating offline map packs.
• Provider terms and offline-cache rights are reviewed before any production rollout.
• The backlog clearly distinguishes implemented policy foundations from still-planned UX.

---

Acceptance Criteria

• Backend and mobile repos each expose a legal/security package index.
• The indexes link to the core license, security, privacy, contribution, and deployment artifacts.
• Remaining backlog work is focused on review completeness and release gating, not on the absence of the index itself.

---

Acceptance Criteria

• Backend and mobile repos each provide SBOM guidance and third-party notices.
• Deployment checklists exist for backend and mobile production review.
• The backlog treats these artifacts as maintained deliverables, not incidental documentation.

---

Acceptance Criteria

• Commercial support scope is documented separately from the root license terms.
• SAP trademark and independence notices are visible in the relevant repo entry points.
• Remaining backlog work is about packaging/sign-off and not about creating the first baseline wording.