2026 Q1: Advanced Integrations & AI

Acceptance Criteria

• Message bubbles have ≥0.5rem vertical spacing (margin-bottom: 0.75rem implemented)
• Spacing works consistently on desktop and mobile viewports
• Visual separation improves readability without excessive whitespace

Acceptance Criteria

• Scroll happens after each message append (user or assistant)
• Scroll happens during streaming for each token batch
• Uses `scrollIntoView` with `requestAnimationFrame` to avoid race conditions
• Fallback to `scrollTop = scrollHeight` if `scrollIntoView` fails
• Works reliably when popover is opened, messages added, or during streaming

Acceptance Criteria

• Indicator appears immediately when query is sent (before first token)
• Shows `BusyIndicator` with text "Thinking..." in message bubble
• Replaced/hidden when first token arrives from LLM
• If no tokens arrive within timeout, indicator remains visible

Acceptance Criteria

• `...` content is extracted from LLM response
• Thinking content shown in a collapsed section below main answer
• Link/button labeled "▶ Show reasoning" / "▼ Hide reasoning" toggles visibility
• Collapsed by default (`thinkExpanded: false`)
• Keyboard accessible (Enter/Space to toggle via Link control)
• Collapsed section has distinct styling (border, background, max-height when expanded)

Acceptance Criteria

• Whitelist of allowed tags enforced (`b`, `i`, `em`, `strong`, `u`, `p`, `br`, `ul`, `ol`, `li`, `a`, `code`, `pre`, `span`, `div`, `details`, `summary`)
• Allowed attributes restricted per tag (e.g., `href`, `title`, `target` for ``)
• `javascript:` and `data:` URLs in `href` are blocked
• Unknown tags are stripped but text content preserved
• Sanitization applied to main content AND think content
• Unit tests cover edge cases (malicious scripts, nested tags, attribute injection)

Acceptance Criteria

• Customer detail page (when `S4_IsSynced = true`) shows button: "Refresh from S/4"
• Clicking button:
• Calls S/4 `GET /A_BusinessPartner('{CustomerCode}')`
• Fetches latest BP data
• Shows comparison dialog:
• Side-by-side: SEP Value | S/4 Value
• Checkboxes to select which fields to update
• Buttons: "Apply Selected" or "Cancel"
• If "Apply Selected":
• Updates SEP Customer with selected S/4 values
• Updates `S4_SyncedAt = now()`
• Success message: "Customer refreshed from S/4"

Acceptance Criteria

• New action in Customers app: "Import from S/4"
• Dialog with two import modes:
• Option 1: Upload CSV with BP numbers
• Option 2: Search Criteria (Sales Org, BP Role, Date Range)
• Preview step:
• Shows matched BPs from S/4 (max 100)
• Columns: BP Number, Name, Address, Role, Created Date
• Checkbox to select which to import
• Validation: Shows conflicts (BP already linked to Customer)
• Import execution:
• Creates SEP Customers with CustomerCode = BP number
• Links to selected Sales Area
• Sets `S4_IsSynced = true`
• Shows progress bar
• Summary report:
• [X] imported successfully
• [Y] skipped (already exist)
• [Z] failed (with error details)

Acceptance Criteria

Acceptance Criteria

Acceptance Criteria

Acceptance Criteria

Acceptance Criteria

Acceptance Criteria

Acceptance Criteria

Acceptance Criteria

Acceptance Criteria

Acceptance Criteria

Acceptance Criteria

• The system should track the number of requests made to the LLM AI assistant.
• The system should monitor the costs associated with using the LLM AI assistant.
• Usage and cost data should be accessible through a reporting interface.

Acceptance Criteria

• Printout footer supports images/logos.
• Images can be managed and assigned per Sales Area or globally.

Acceptance Criteria

• An electronic signature feature is integrated into the printout process.
• Users can sign printouts using a digital signature pad or similar technology.
• Signed printouts are securely stored and can be retrieved for auditing purposes.

Acceptance Criteria

• An approval workflow is implemented for quotes.
• Quotes can be submitted for approval and tracked through the approval process.
• Notifications are sent to approvers when a quote is submitted for approval.
• Approvers can review and approve/reject quotes within the system.
• Quotes / Contracts in the Backend ERP system are blocked from use until approved.

Acceptance Criteria

• Maintainable Geofence entity (polygon and/or circular radius) associated to Plant or SalesArea (draft-enabled via admin app).
• On Plant or Location object page map: display relevant geofences (styled polygons / circles) with legend.
• When user places or drags marker: real-time indication (badge / color highlight) if inside one or multiple geofences.
• Auto-suggestion event (e.g., `geofenceMatch`) fired listing candidate Plants ordered by distance when within overlapping zones.
• Distance (in km) computed and exposed (Haversine on client initially) for selected plant vs current location.
• Optional toggle to show/hide geofence overlays for clarity.
• No performance degradation beyond +150ms initial map render with up to 50 geofences (baseline to be measured).
• We need to use our UseCase mapping configuration too, to ensure the best mapping solution can be chosen for edit, while a cost-effective can be used for View. Also, as different mapping solutions have better accuracy in different countries, this configurations of mapping solutions should be per Sales Area to allow flexibility.

Out of Scope (Phase 1):

• Server-side spatial indexing / HANA ST_GEOMETRY usage.
• Multi-stop routing, travel time matrix, traffic-aware distance.
• Automatic persistence of suggested plant selection (user confirms manually).

Acceptance Criteria

Acceptance Criteria

Acceptance Criteria

Acceptance Criteria

Acceptance Criteria

• The template field should be automatically cleared when the Sales Area is changed in the quote tool.

---

Acceptance Criteria

• A map should be displayed when selecting a Location in the quote tool
• The map should allow for easy navigation and selection of Locations
• Also show the plants on the map to help the sales rep choose the best location for delivery

---

---

Acceptance Criteria

• A map should be displayed when selecting a Plant in the quote tool
• The map should allow for easy navigation and selection of Plants
• Also show the chosen Location on the map to help the sales rep choose the best Plant for delivery

---

Acceptance Criteria

• When geocoding a Location, the map should display other Locations from the same Sales Area
• The map should allow for easy navigation and visibility of these Locations
• The Locations should be clearly marked and distinguishable on the map

---

---

Acceptance Criteria

• CPQ can trigger a BP creation flow that reaches ECC (via middleware)
• ECC returns a BP number (e.g., 'C-2025-000123') and status; this is stored in CPQ as `Customer.CustomerNumber` and `Customer.BackendStatus`, and `Location.LocationNumber` and `Location.BackendStatus`
• Error messages from ECC are captured and displayed in CPQ (already implemented)
• If mapping for the response payload is missing or invalid, the flow returns a clear validation error and logs mapping diagnostics

Acceptance Criteria

• Middleware accepts SOAP requests/responses and exposes a REST/OData endpoint returning normalized JSON
• Middleware handles XML namespaces, complex types, and repeated elements, producing deterministic JSON paths
• Middleware surfaces mapping warnings/errors when unexpected XML elements are present
• CAP app consumes middleware endpoint instead of calling SOAP directly

Acceptance Criteria

• Mapping document lists all expected fields from ECC response and target CPQ fields (CustomerNumber, Location, ECCStatus, ECCErrorCode, ECCErrorMessage)
• Mapping handles optional/missing elements and arrays (e.g., multiple parties)
• Date/time formats normalized (UTC ISO-8601)
• Numeric and currency fields normalized with locale-independent formatting
• Mapping implemented in CAP service layer (handler) with unit tests

---

Acceptance Criteria

• CAP app calls middleware endpoint to create BP and receives normalized response
• CAP maps the response and persists CustomerNumber, LocationNumber and ECCStatus
• Manual and automated E2E test: CPQ → middleware (real or stub) → ECC (or mock) → middleware → CPQ persists
• Error scenarios: middleware returns mapping error, ECC returns validation error; CPQ surfaces actionable messages

Definition of Done:

• End-to-end flows covered by automated integration tests (happy path + 2 error cases)
• Monitoring in place for middleware and CAP integration errors

---

Acceptance Criteria

• Search UI shows combined list of Contracts.
• Columns: Contract ID, Type, Status, Exists in SEP/S/4.
• Search query applies to both.

Acceptance Criteria

• In Hybrid Contract Search results, select multiple rows.
• Click "Import to SEP".
• System fetches full details from S/4 (Sales Contract API) and creates local Contract records.
• Success/Error summary displayed.

Acceptance Criteria

• Technical and user documentation is updated.
• Compliance team reviews and signs off on audit log implementation.

---

#### 25Q4-E10-07: Audit Logging for Transactional Data (Quote Updates)

Priority: Must Have

Story Points: 3

Status: Done (2026/01/09)

• `UPDATE` operations on `Quote` (Quotes app) trigger an audit log entry.
• Active Records Only: Changes to `*.drafts` are IGNORED. Only activation (Save) or direct updates to active entities are logged.
• Diff Logging: The `ChangeSummary` JSON includes a diff of changed fields (Old Value vs New Value).
• Custom Actions: Key actions like `calculateAIPrices` are logged if they modify data.
• Deletions: Deleting a Quote or Item is logged with `ActionType='DELETION'`.

#### 25Q4-E10-08: Audit Logging for Master Data (Customers & Locations)

Priority: Must Have

Story Points: 3

Status: Done (2026/01/09)

• `UPDATE` (and Creation/Deletion where applicable) on `Customers` and `Locations` are logged.
• Active Records Only: Ignore drafts.
• S/4 Sync: Updates triggered by "Refresh from S/4" or "Mass Import" must be logged with a clear Description (e.g., "Updated via S/4 Sync").
• Manual Edit: Manual updates via the UI are logged separately.
• Diff Logging: Capture changed fields (e.g., Address change: Old -> New).

#### 25Q4-E10-09: Audit Logging for Security & Configuration

Priority: Critical

Story Points: 3

Status: Done (2026/01/09)

• `UPDATE/CREATE/DELETE` operations on `AIAssistantConfig` and `AIAssistantPrompt` are logged.
• Active Records Only: Ignore drafts.
• Diff Logging: Capture exact changes to the `SharedSystemPrompt` or `Personality` text.

#### 25Q4-E10-10: Visualization of Audit Logs (Fiori App)

Priority: High

Story Points: 3

Status: Done (2026/01/09)

• List Report: View a list of "Audited Entities" (Quote, Customer, etc.).
• Object Page: Drill down into an entity to see its timeline of changes (Audit Details).
• Detail View: See the `ChangeSummary` JSON diff clearly (e.g., in a text area or formatted view).
• Scope: Implemented in `app/auditlogs` Fiori Elements app.
• `UPDATE`, `CREATE`, `DELETE` on `UserConfigurations` and `UserSalesAreaAccess` are logged.
• Active Records Only: Ignore drafts.
• Specifics: Log when a user is assigned a new Sales Area or a Default Sales Area is changed.
• Diff Logging: Complete "Before/After" snapshot in `ChangeSummary` is preferred for security configs.

---

Technical Implementation Notes:

• Entities:
• `AuditLogHeader`: `AuditLogID` (UUID), `EntityName`, `EntityID`.
• `AuditLogDetail`: `AuditLogDetailID` (UUID), `PerformedBy` (User), `PerformedAt` (Timestamp), `ActionType` (UPDATE, DELETE, SYNC, SECURITY_CHANGE), `Description`, `ChangeSummary` (LargeString/JSON).
• Diff Logic: Use a shared helper `auditLogUtils.computeDiff(oldData, newData)` to generate standard JSON: `{ "field": { "old": "X", "new": "Y" } }`.
• Active Only: Handlers must verify `req.entity.endsWith('.drafts') === false`.
• Handler Strategy: In `before('UPDATE')`, read the current DB state. Compare with `req.data`. If changed, write to Audit Log (or buffer to write in `after` if transaction success is required).

---

Acceptance Criteria

• LLM prompt composition includes exactly one normalized `QuoteContext` section.
• The prompt does not include both a basic quote JSON and a separate enriched quote JSON.
• `QuoteContext` includes friendly fields (quote number/title/status text/customer display name/currency/owner) when available.
• Behavior does not regress when no quote is present.

---

Acceptance Criteria

• Quote enrichment runs before intent detection.
• NLP intent detection receives enriched quote context (not only UUIDs/status codes).
• If enrichment fails, the assistant falls back gracefully (intent detection still works).

---

Acceptance Criteria

• `AIAssistantPrompt.UseCase` supports `NLP_INTENT_DETECTION`.
• Intent detection loads prompt configs for this use case from DB.
• Multiple prompt configs (same use case) can be evaluated in `Priority` order as a fallback chain.
• SalesArea-scoped prompt configs override global configs.

---

Acceptance Criteria

• If intent output is invalid JSON or missing required keys, it escalates to the next prompt in the chain.
• If confidence is below threshold (default 0.70), it escalates to the next prompt in the chain.
• If the final prompt in the chain is still below threshold, the assistant asks a clarification question.
• Clarification is deterministic and includes friendly quote identifiers when available.

---

Acceptance Criteria

• Tests cover invalid JSON → escalation.
• Tests cover missing keys → escalation.
• Tests cover low confidence after escalation → clarification.
• Tests assert prompt includes only one normalized quote context section.

Acceptance Criteria

• Map Section: A new custom section "Map" is available on the Quote Object Page.
• Visualization:
• Ship-To: Shown as a Green marker.
• Plant: Shown as a Blue marker (if one is selected/determined).
• Other Locations: All other valid Locations for this Customer (in this Sales Area) are shown as Grey markers.
• Selection: Clicking a "Grey" marker allows the user to select it as the new Ship-To location for the Quote (updating `Location_ID`).
• Configuration: The map provider is loaded dynamically using the existing `MapProviderFactory` based on the `QUOTATION_MAP` configuration for the current Sales Area.
• Access Control: The map only displays locations the user is authorized to see (inherited via OData RLS).

---

Acceptance Criteria

• Trigger: Approval is required if `QuoteHeader.TotalNetAmount` > Threshold defined in `ApprovalRuleConfig`.
• Source of Truth: Uses the `TotalNetAmount` returned from SAP sync (after any recalculations).
• Configuration: The threshold is configurable per Sales Area.
• Workflow: Integrating with existing approval flow; status changes to `Pending Approval`.

---

Acceptance Criteria

• Definition: "Discount Items" are defined as Quote Items linked to specific Products (e.g., "Manual Discount" placeholder product) or resulting in specific Condition Types (e.g., `K007`).
• Trigger: If any item matches the definition, approval is required.
• Detection:
• Option A (Product-based):* Check if `QuoteItem.Product` is in a configured list of "Discount Products".
• Option B (Condition-based):* Check if the item has specific condition types returned from SAP (requires detailed item pricing sync).
• Refinement: For this story, we focus on Product-based triggers (e.g., a "Discount" line item added by the user).

---

Acceptance Criteria

• Calculation:
• `Item Margin %` = `((Net Price - Cost) / Net Price) * 100`
• `Quote Average Margin %` = Weighted average of item margins (or Total Margin / Total Net Amount).
• Data Source:
• `Net Price`: From SAP via `QuoteItem.UnitPrice` / `TotalPrice`.
• `Cost`: From `QuoteItem.Cost` (derived from `ProductPlant`).
• Trigger: Approval required if `Quote Margin %` < Threshold defined in `ApprovalRuleConfig`.
• Pre-requisite: `ProductPlant` costs must be maintained and accurate.
• Zero Cost Handling: If Cost is 0 or missing, treat as 100% margin (or flag as error, TBD - assume 100% for now to avoid blockers).

---

Acceptance Criteria

• Product Classification Extension:
• IMPORTANT: Products already use `ProductClassification` association (NOT inline enum)
• Existing classifications: PC01=Discount, PC02=Surcharge, PC03=Product (standard sellable)
• Add NEW classifications: PC04=RTV (Return to Vendor), PC05=Complaint
• `QuoteItems` can reference products with any of these classifications via existing association
• Data Validation:
• PC04 items require link to original sales order (new field: `OriginalSalesOrder`)
• PC05 items require complaint reason code (new field: `ComplaintReason`)
• PC04/PC05 items show as negative quantities/amounts (reuse PC01 discount pattern)
• UI Adaptation:
• Product selection dialog filters by ProductClassification (existing pattern)
• Quote items table shows classification indicator
• Visual distinction for return/complaint items (icon, color via Criticality)

Acceptance Criteria

• New Virtual Fields (NOT stored in DB):
• `TotalSalesAmount`: Sum of PC03 (Product) items - positive amounts
• `TotalReturnsAmount`: Sum of PC04 (RTV) items - negative amounts
• `TotalComplaintsAmount`: Sum of PC05 (Complaint) items - negative amounts
• ⚠️ IMPORTANT: These are "Deal Composition View" fields for user insight
• ⚠️ SAP `TotalNetAmount` remains the authoritative single source of truth
• Calculation:
• Computed on-the-fly during READ operations (after('READ'))
• NOT persisted to avoid SAP sync conflicts
• Recalculated when QuoteItems are expanded in response
• Displayed in header summary section
• UI Display:
• Section shows composition: Sales + Returns + Complaints
• SAP TotalNetAmount displayed prominently as "Deal Net Amount"
• Color coding: Sales (neutral), Returns/Complaints (red/critical), Net (bold)
• Currency formatting consistent with existing fields
• Note: For deals not synced to SAP, composition view shows local calculation

Acceptance Criteria

• Action: New action "Create Return Order" available when Deal contains PC04 items
• Validation:
• All PC04 items must reference a valid Original Sales Order
• Quantities must be negative
• Return reason codes must be valid
• ERP Integration:
• Creates Return Order in S/4 via `API_SALES_ORDER_SRV` or equivalent
• Payload includes: Customer, Original Order Reference, Return Items, Quantities, Reason Codes
• Handles both S/4 and ECC backends via existing adapter pattern
• Response Handling:
• Stores return order number on QuoteItems (`ERPReturnOrderNumber`)
• Updates item status to "Return Order Created"
• Shows success message with order numbers
• Error handling for validation failures

Acceptance Criteria

• Action: New action "Create Credit Memo" available when Deal contains PC05 items
• Validation:
• All PC05 items must have complaint reason codes
• Amounts must be negative
• Optional: Approval workflow for high-value complaints
• ERP Integration:
• Creates Credit Memo Request in S/4 via appropriate API
• Payload includes: Customer, Reference Document, Credit Items, Amounts, Reason Codes
• Handles both S/4 and ECC backends
• Response Handling:
• Stores credit memo request number (`ERPCreditMemoNumber`)
• Updates item status to "Credit Memo Requested"
• Shows success confirmation
• Error handling for rejections

Acceptance Criteria

• Application Title: "Tatru Deal Tool" (previously "Quote Tool")
• Navigation: Menu shows "Deals" instead of "Quotes"
• Entity Labels:
• "Deal" in singular contexts
• "Deals" in plural/list contexts
• Technical entities remain `QuoteHeader`/`QuoteItems` (no schema change)
• i18n Updates:
• All user-facing text updated in `_i18n/` and app `i18n/` files
• Backward compatibility: internal code still uses "Quote" terminology
• Documentation:
• README and user docs refer to "Deal Tool"
• Technical docs clarify entity naming

Acceptance Criteria

• Grouping:
• Items table grouped by Product Type (Sales / Returns / Complaints)
• Collapsible groups with expand/collapse
• Default: all groups expanded
• Subtotals:
• Each group shows count and subtotal
• "Sales: 5 items, $50,000"
• "Returns: 2 items, -$5,000"
• "Complaints: 1 item, -$2,000"
• Visual Design:
• Group headers with background color
• Subtotal row in each group
• Icons for each product type
• Interaction:
• Sorting/filtering works within groups
• Actions available per group (e.g., "Create Return Order" only on Returns group)

Acceptance Criteria

• Project Setup:
• New directory: `/mobile-app` (or separate repo)
• Expo SDK (latest stable version)
• TypeScript configured
• Navigation stack (React Navigation)
• Build Capability:
• `npm start` launches Expo Dev Server
• App runs in Expo Go on iOS and Android
• Hot reload working
• Folder Structure:
• `/src/screens` - App screens
• `/src/components` - Reusable components
• `/src/services` - API and database services
• `/src/models` - Data models
• `/src/navigation` - Navigation configuration
• Branding:
• App name: "Tatru Mobile"
• Icon and splash screen with Tatru branding

Acceptance Criteria

• Database:
• SQLite via `expo-sqlite`
• Schema mirrors core CAP entities: Customers, Locations, Products, Plants, QuoteTemplates, QuoteHeaders, QuoteItems
• Initialization script creates tables on first launch
• Data Access Layer:
• Repository pattern for CRUD operations
• Repositories: CustomerRepository, ProductRepository, QuoteRepository, etc.
• Async/await API
• Migration Support:
• Database version tracking
• Migration scripts for schema changes
• Performance:
• Indexed queries for common lookups
• Lazy loading for large datasets
• Tested with 1000+ customers, 5000+ products

Acceptance Criteria

• Sync Trigger:
• Manual: "Sync Data" button on home screen
• Automatic: On app launch (if online)
• Background: Optional periodic sync when online
• Sync Scope:
• Downloads only data for user's assigned Sales Areas
• Entities: Customers, Locations, Products, ProductSalesArea, Plants, QuoteTemplates
• Quotes: User's own quotes only
• Sync Process:
• Shows progress indicator (% complete, entity currently syncing)
• Incremental sync: Only downloads changes since last sync (if supported)
• Full sync option: "Refresh All Data"
• Error Handling:
• Network errors: Retry with exponential backoff
• Authentication errors: Prompt to re-login
• Storage full: Alert user, suggest cleanup
• Metadata:
• Stores last sync timestamp
• Tracks sync status per entity

Acceptance Criteria

• Change Tracking:
• Local changes flagged in database (pending sync)
• Supports: New quotes, updated quotes, new customers, new locations
• Upload Process:
• Automatic on reconnect (if enabled)
• Manual: "Upload Changes" button
• Shows queue of pending changes
• Uploads in transaction order (creates before updates)
• Conflict Resolution:
• Detects server-side changes to same record
• Options: Keep Local, Keep Server, Merge (manual)
• UI shows conflict details for user decision
• Success Handling:
• Marks records as synced
• Updates local IDs with server IDs
• Clears pending flag
• Failure Handling:
• Validation errors shown to user
• Retries for network errors
• Failed uploads remain in queue

Acceptance Criteria

• Customers Screen:
• List view with search and filter
• Shows: Customer Name, Code, City, Status
• Tap to view customer details
• Detail view: All fields, associated locations, recent quotes
• Create new customer (offline capable)
• Edit customer (offline capable)
• Locations Screen:
• List view with search (by location name, customer, city)
• Shows: Location Name, Customer, Address
• Tap to view location details
• Detail view: All fields, map view (if lat/lon available)
• Create new location (offline capable)
• Edit location (offline capable)
• Offline Indicators:
• Banner shows sync status
• Records created/edited offline marked with indicator
• UX:
• Native mobile interactions (swipe, pull-to-refresh)
• Responsive design for tablets and phones

Acceptance Criteria

• Products Screen:
• List view with search (product code, description)
• Filter by product type, sales area
• Shows: Product Code, Description, Base Price, Availability
• Tap to view product details
• Detail view: All specs, pricing, plant availability
• Deals Screen:
• List: My deals with search and filter (customer, status, date)
• Shows: Deal #, Customer, Total Amount, Status
• Tap to view deal details
• Deal Detail:
• Header: Customer, Date, Status, Totals
• Items table: Product, Qty, Price, Total
• Actions: Add Item, Edit Item, Delete Item
• Calculate prices (offline using templates or cached pricing)
• Create New Deal:
• Select customer and template
• Add products with quantities
• Auto-calculate totals
• Save offline
• Templates:
• Load quote templates from local DB
• Apply template defaults to new deals

Acceptance Criteria

• Camera Access:
• Permission handling for camera
• Live camera view for document scanning
• Capture button and preview
• OCR Processing:
• On-device OCR using ML Kit or TensorFlow Lite
• Extracts text from images
• Optimized for: Business cards, Purchase orders, Invoices
• Data Extraction:
• Parse extracted text for: Names, Addresses, Phone numbers, Product codes, Quantities
• Use simple regex or ML-based entity extraction
• Show extracted data with confidence scores
• Integration:
• "Scan Business Card" from New Customer screen → pre-fills customer form
• "Scan Order" from New Deal screen → pre-fills items
• User can review and edit extracted data before saving
• Offline:
• All processing happens on-device
• No internet required

Acceptance Criteria

• NLP Search:
• Global search bar with voice input support
• Accepts natural language: "customers in Madrid", "product for steel pipes", "my deals from last week"
• On-device SLM (Small Language Model) parses query
• Returns relevant results from local database
• SLM Integration:
• Use lightweight model (e.g., TinyLlama, Phi-2 mobile, or ONNX Runtime)
• Model runs on-device (no internet required)
• Intent classification: Customer search, Product search, Deal search, Help/Info
• Entity extraction: Location names, product categories, date ranges
• Results:
• Unified results view showing customers, products, deals
• Grouped by entity type with counts
• Tap result to navigate to detail screen
• Voice Input:
• Microphone button activates speech-to-text
• Uses device native STT (online or offline capable)
• Performance:
• Query latency < 2 seconds on mid-range devices
• Model size < 100MB

Acceptance Criteria

• Login Screen:
• Username/password form
• "Remember Me" option
• Biometric authentication option (fingerprint/face ID)
• Authentication:
• OAuth 2.0 / OIDC flow with backend (IAS/XSUAA)
• Stores access token securely (Expo SecureStore)
• Refresh token for session extension
• Session Management:
• Token expiration handling
• Auto-logout after inactivity (configurable timeout)
• Prompt to re-login when token expires
• User Context:
• Stores user ID, name, assigned Sales Areas
• Used for data filtering and sync scope
• Security:
• Secure token storage (platform keychain)
• No credentials stored in plain text
• Support for SSO if available

Acceptance Criteria

• Documentation Structure:
• One markdown file per app: `/docs/apps/.md`
• Sections: Overview, Key Features, User Roles, Common Tasks, FAQ
• Screenshots/diagrams where helpful
• Content Coverage:
• Configuration apps: SalesAreas, Products, ProductSalesAreas, DocumentTypes, Customers, Locations, Plants, QuoteTemplates, UserConfigurations, MappingConfiguration, AIAssistantPrompts
• Operational apps: Quotes/Deals, Audit Logs
• Format:
• Markdown with standard headings
• Code examples for configuration values
• Links to related apps where relevant
• Metadata:
• Each doc includes: App ID, Title, User Roles, Last Updated date

Acceptance Criteria

• Help Button:
• Icon button (? or ℹ️ icon) in app header/toolbar
• Available on all Fiori apps (List Report and Object Page)
• Accessible via keyboard (F1 shortcut optional)
• Popover Display:
• Clicking button opens popover/dialog
• Shows documentation content for current app
• Markdown rendered as formatted HTML
• Scrollable content area
• Close button (X) to dismiss
• Content Loading:
• Loads markdown from `/docs/apps/.md`
• Converts markdown to HTML (client-side or server-side)
• Fallback: "Documentation not available" if file missing
• Styling:
• Consistent with Fiori theme
• Readable typography
• Code blocks syntax highlighted
• Links functional

Acceptance Criteria

• Context Awareness:
• Assistant knows which app user is currently in
• Includes app context in LLM prompts
• Documentation Access:
• Assistant has access to app markdown files
• Uses RAG (Retrieval Augmented Generation) to find relevant sections
• Answers questions based on official documentation
• Interaction:
• User asks: "How do I create a new Sales Area?"
• Assistant responds with instructions from SalesAreas app documentation
• Assistant can quote/link specific sections
• Fallback:
• If no LLM available, show static documentation (26Q1-E6-02)
• Works offline with pre-loaded docs

Acceptance Criteria

• Search UI:
• Search box in documentation popover/dialog
• "Search all documentation" option
• Shows results from all app docs
• Search Functionality:
• Full-text search across all markdown files
• Highlights matching text
• Results ranked by relevance
• Shows: App name, Section, Snippet with match
• Navigation:
• Click result to view full documentation for that app
• Scroll to relevant section
• Performance:
• Search latency < 500ms
• Supports fuzzy matching

Acceptance Criteria

• Language Files:
• Documentation available in: English (default), Spanish, German
• File naming: `.md` (en), `_es.md`, `_de.md`
• Language Selection:
• Documentation language follows user's UI language preference
• Manual override: Language selector in documentation popover
• Fallback:
• If documentation not available in selected language, show English
• Message: "Documentation available in: [EN] [ES] [DE]"
• Consistency:
• Screenshots localized where critical
• Code examples stay in English (technical content)

Acceptance Criteria

• Script:
• Node.js script: `scripts/convertDocsToHtml.js`
• Converts all `.md` files in specified directory to `.html`
• Command: `npm run docs:convert`
• Conversion:
• Uses markdown parser (e.g., `marked`, `markdown-it`)
• Preserves headings, lists, links, code blocks, tables
• Syntax highlighting for code blocks (via `highlight.js`)
• Converts relative links to appropriate format
• Joomla Compatibility:
• Output is clean HTML fragment (no ``, ``, `` tags)
• Uses semantic HTML5 tags
• CSS classes compatible with Joomla template
• No inline styles (uses class names)
• Output:
• HTML files saved to `/docs/html/` directory
• Maintains directory structure
• Filename: `.html`

Acceptance Criteria

• CSS Styles:
• Stylesheet: `/docs/styles/joomla-docs.css`
• Styles for: headings, paragraphs, lists, tables, code blocks, blockquotes
• Responsive design for mobile/tablet/desktop
• Compatible with Joomla template (no conflicts)
• HTML Structure:
• Semantic tags: `
  `, `

  `, `

  `, `
• BEM naming convention for CSS classes
• ARIA labels for accessibility
• Branding:
• Tatru color scheme
• Typography consistent with website
• Logo placement (if applicable)
• Components:
• Table of contents component (collapsible on mobile)
• Breadcrumb navigation
• "Last updated" timestamp display
• Print-friendly version

Acceptance Criteria

• Git Hook:
• Pre-commit hook runs conversion script
• Only converts changed markdown files (incremental)
• Fails commit if conversion errors occur
• CI Pipeline:
• GitHub Actions workflow on push to main
• Converts all markdown files
• Commits generated HTML to repository (or separate branch)
• Artifacts available for download
• Validation:
• HTML linting (W3C validator)
• Broken link checking
• Accessibility testing (Pa11y or similar)
• Fails pipeline if validation errors found
• Deployment:
• Optional: Auto-upload to Joomla via API
• Or: Manual upload from artifacts

Acceptance Criteria

• Index Page:
• Generated HTML: `/docs/html/index.html`
• Lists all documentation files with:
• Title (from markdown front matter or first H1)
• Brief description (from front matter or first paragraph)
• Category (Technical, User Guide, Admin Guide)
• Last updated date
• Categorization:
• Docs grouped by category
• Expandable/collapsible sections
• Search/filter box
• Navigation:
• Breadcrumbs on each doc page: Home > Category > Document
• "Previous" / "Next" links for sequential reading
• Back to index link
• Metadata:
• Each markdown file has YAML front matter with:
• `title`, `category`, `description`, `tags`, `date`

Acceptance Criteria

• Image Conversion:
• Markdown images: ``
• Converted to: ``
• Relative paths resolved correctly
• Asset Copying:
• Images copied from `/docs/images/` to `/docs/html/images/`
• Other assets (PDFs, downloads) also copied
• Directory structure preserved
• Optimization:
• Images optimized for web (compressed)
• Responsive images: `srcset` for different resolutions
• Lazy loading attribute added
• CDN Support:
• Optional: Upload images to CDN
• Update image URLs in HTML to CDN paths
• Fallback to local images if CDN unavailable

Acceptance Criteria

• Integration with S/4 HANA API to retrieve all Sales Organizations
• Create new Sales Organizations in CPQ that don't exist
• Update existing Sales Organizations when changes are detected
• Map all relevant fields (ID, name, currency, company code, etc.)
• Handle errors gracefully with detailed logging
• Provide UI to trigger manual sync and view sync status
• Display last sync timestamp and success/failure status

Acceptance Criteria

• Integration with S/4 HANA API to retrieve all Distribution Channels
• Create/update Distribution Channels in CPQ
• Map all relevant fields (ID, description, channel type)
• Synchronize changes and deactivations
• Provide sync status and error reporting

Acceptance Criteria

• Integration with S/4 HANA API to retrieve all Divisions
• Create/update Divisions in CPQ
• Map all relevant fields (ID, description, division type)
• Handle organizational changes
• Provide sync monitoring

Acceptance Criteria

• Retrieve valid Sales Area combinations from S/4 HANA
• Auto-generate Sales Areas in CPQ based on these combinations
• Link to parent Sales Org, Dist Channel, and Division entities
• Handle additions and removals of valid combinations
• Validate Sales Area uniqueness (SalesAreaKey generation)
• Provide bulk sync with progress indication

Acceptance Criteria

• Retrieve sales document types from S/4 HANA (filter for quotes: AG, contracts: various)
• Create/update DocumentType entities in CPQ
• Map all fields: document type code, description, category, number ranges
• Distinguish between quote types and contract types
• Handle document type configuration changes
• Validate document types work in quote creation flow

Acceptance Criteria

• Retrieve Sales Area to Document Type assignments from S/4 HANA
• Create AllowedDocumentTypes relationships in CPQ
• Remove assignments that are no longer valid in S/4
• Update document type value help filtering to use synced data
• Handle bulk assignment changes efficiently

Acceptance Criteria

• Retrieve Sales Office master data from S/4 HANA
• Create/update Sales Office entities in CPQ
• Map fields: office ID, description, address, responsible person
• Handle organizational changes and closures
• Link to parent Sales Organizations

Acceptance Criteria

• Retrieve Sales Group master data from S/4 HANA
• Create/update Sales Group entities in CPQ
• Map fields: group ID, description, manager, office assignment
• Link to Sales Offices where applicable
• Handle reorganizations

Acceptance Criteria

• Retrieve Sales Office to Sales Organization assignments from S/4
• Create assignment records in CPQ
• Handle multi-assignment scenarios (office serves multiple orgs)
• Remove invalid assignments
• Validate assignment changes don't break existing data

Acceptance Criteria

• Retrieve Sales Group to Sales Office assignments from S/4
• Create assignment records in CPQ
• Handle group moves between offices
• Update assignment history
• Support reporting on group structures

Acceptance Criteria

• Retrieve Plant master data from S/4 HANA
• Create/update Plant entities in CPQ (or Locations if mapped)
• Map fields: plant ID, name, address, coordinates, type (production/warehouse)
• Handle plant status changes (active/inactive)
• Support geocoding for map integration
• Link to company codes and sales organizations

Acceptance Criteria

• Retrieve Plant to Sales Org/Dist Channel assignments from S/4 HANA
• Create assignment records in CPQ
• Filter plant availability based on quote's Sales Area
• Handle plant assignment changes
• Support multiple plants per Sales Org/Channel
• Validate quote item plant selections against assignments

Acceptance Criteria

• Retrieve Condition Type configuration from S/4 HANA
• Create/update Condition Type entities in CPQ
• Map fields: type code, description, category (price/discount/surcharge/freight), calculation type, scale basis
• Import condition type rules and settings
• Handle condition type changes and deprecations
• Support pricing procedure mapping

Acceptance Criteria

• Retrieve Access Sequence configuration from S/4 HANA
• Create Access Sequence entities with steps and priorities
• Map to Condition Tables (see 26Q1-E8-15)
• Configure search order and exclusive indicators
• Link Access Sequences to Condition Types
• Support access sequence changes

Acceptance Criteria

• Retrieve Condition Table configuration from S/4 HANA
• Create Condition Table entities with key field definitions
• Map field structures and data types
• Link tables to Access Sequences
• Support custom condition tables
• Handle table structure changes

Acceptance Criteria

• Single UI dashboard showing status of all sync processes
• Ability to trigger individual syncs or full sync of all entities
• Display last sync time, record counts, success/failure status for each entity type
• Show sync progress with real-time updates during execution
• Error log viewer with filtering and search
• Sync history with audit trail
• Ability to schedule automatic syncs (daily/weekly)
• Dependency-aware sync ordering (e.g., Sales Org before Sales Area)
• Dry-run mode to preview changes without committing

Acceptance Criteria

• Document created mapping each CPQ entity to S/4 API endpoint
• Include API package names from SAP Business Accelerator Hub
• List required authorization scopes for each API
• Provide sample API requests and responses
• Document field mappings between S/4 and CPQ
• Include troubleshooting guide for common sync issues
• Add configuration requirements (communication arrangements, etc.)
• Create architecture diagram showing sync flows

Acceptance Criteria

• UI to create and manage `BackendType` records (S4_USA, S4_CAN, S4_EU, etc.)
• Configure backend properties: name, type, base URL, credentials
• Test connectivity to each backend
• Mark backends as active/inactive
• Add `SourceSystem` association to: SalesOrganization, DistributionChannel, Division, Plant, ConditionType
• Add `IsActiveInSEP` flag to master data entities
• Enforce same-backend constraint: Sales Area from backend X uses only org units from backend X
• Value help filtering: show only org units matching selected backend
• Backend selection in sync triggers
• Display source system badges in list views and object pages