2025 Q4: Customer Integration & Clean Core

Acceptance Criteria

• Sales Area detail page has new section "S/4 HANA Integration"
• Can enable/disable S/4 sync via toggle switch
• When enabled, can configure:
• Customer Business Partner Grouping (4 chars, e.g., '0001')
• Customer BP Role for Screen Usage (6 chars, e.g., 'FLCU01')
• Location Business Partner Grouping (4 chars, e.g., '0002')
• Location BP Role for Screen Usage (6 chars, e.g., 'FLCU02')
• Configuration validates: Grouping field is mandatory when sync enabled
• Configuration persists and loads correctly

Acceptance Criteria

• When creating Customer in Sales Area with `S4_SyncEnabled = false`:
• User fills: Company Name, Contact Person, Address, Email, Phone
• User selects BP Category: Person (1) or Organization (2)
• System leaves CustomerCode field blank
• System sets `S4_IsSynced = false`
• Success message: "Customer created locally with code [UUID]"
• Customer detail page shows badge: "Local Only" (gray)
• CustomerCode is not editable by user

Acceptance Criteria

• When creating Customer in Sales Area with `S4_SyncEnabled = true`:
• User fills same fields as local-only mode
• System validates required fields based on BP Category:
• Person: FirstName + LastName mandatory
• Organization: Company mandatory
• System calls S/4 `API_BUSINESS_PARTNER` to create BP with:
• BusinessPartnerCategory from user selection
• BusinessPartnerGrouping from Sales Area config
• BP Role from Sales Area config
• System receives BP number from S/4 (e.g., "1000123")
• System stores BP number in CustomerCode
• System sets `S4_IsSynced = true`, `S4_SyncedAt = now()`
• Success message: "Customer created as Business Partner 1000123"
• Customer detail page shows:
• Badge: "Synced with S/4" (green)
• CustomerCode as text (not editable)
• "Last Synced: [timestamp]" below CustomerCode

Acceptance Criteria

• When updating Customer where `S4_IsSynced = true`:
• User changes name, address, email, or phone
• System calls S/4 `API_BUSINESS_PARTNER` PATCH endpoint
• System updates BP with CustomerCode
• System updates `S4_SyncedAt = now()`
• Info message: "Customer 1000123 updated in S/4"
• When updating Customer where `S4_IsSynced = false`:
• Changes saved locally only
• No S/4 call made
• No sync timestamp updated

Acceptance Criteria

• When creating Location under Customer in Sales Area with `S4_SyncEnabled = true`:
• User fills: Name, Address, City, State, PostalCode, Country
• User selects BP Category (usually Organization for locations)
• System calls S/4 to create BP with Location grouping/role from Sales Area
• System receives LocationCode (e.g., "2000456")
• System sets `S4_IsSynced = true`
• Success message: "Location created as Business Partner 2000456"
• Location detail page shows sync badge and LocationCode

Acceptance Criteria

• Network Error Scenario:
• S/4 API times out or returns 503
• System shows warning dialog:
• "S/4 HANA is temporarily unavailable"
• "Customer will be created locally. You can sync later."
• Buttons: "Create Locally" or "Cancel"
• If "Create Locally": Creates with `S4_IsSynced = false`
• Validation Error Scenario:
• S/4 returns 400 (e.g., invalid country code)
• System shows error message with details
• Form stays open for user to correct
• Does NOT create Customer locally
• Authorization Error Scenario:
• S/4 returns 401/403
• System shows error: "S/4 credentials invalid. Contact administrator."
• Does NOT create Customer
• Customer Detail Page Action:
• If `S4_IsSynced = false`, shows action button: "Sync to S/4"
• Clicking retries BP creation
• On success: Updates CustomerCode, sets synced = true

Acceptance Criteria

• Before creating Customer with S/4 sync enabled:
• System automatically searches S/4 by:
• Company Name + Country (if Organization)
• FirstName + LastName + Country (if Person)
• If 1+ matches found, shows dialog:
• "Potential duplicates found in S/4"
• Table with columns: BP Number, Name, Address, Created Date
• Buttons: "Use Existing BP [number]" or "Create New BP"
• If "Use Existing BP" selected:
• Links Customer to selected BP number
• Does NOT create new BP in S/4
• Sets `S4_IsSynced = true`
• If "Create New BP" selected:
• Proceeds with normal creation flow
• Search only triggered if S/4 sync enabled
• Search timeout: 3 seconds (then proceed to create)

Acceptance Criteria

• New app tile: "S/4 Integration Monitor"
• Dashboard shows KPIs:
• Total Customers: [X synced] / [Y local-only] / [Z failed sync]
• Total Locations: [X synced] / [Y local-only] / [Z failed sync]
• Last 24h sync success rate: [%]
• S/4 API response time: [avg ms]
• Section: "Recent Errors" (last 20)
• Timestamp, User, Entity (Customer/Location), Error Message
• Action button: "Retry" (re-attempts sync)
• Section: "Pending Syncs"
• List of Customers/Locations with `S4_IsSynced = false`
• Bulk action: "Sync All to S/4"
• Auto-refreshes every 30 seconds

Acceptance Criteria

• When creating or updating a Location under a Customer with `S4_IsSynced = true`:
• System calls S/4 `API_BUSINESS_PARTNER` to create or update the BP relationship
• System sends address data along with the relationship
• System receives confirmation from S/4
• Info message: "Location linked to Customer in S/4"
• When updating a Customer or Location, the relationship is updated in S/4

Acceptance Criteria

• When creating or updating a Customer with `S4_IsSynced = true`:
• System sends parsed address (City, State, PostalCode, Country, Street), email, and phone data to S/4 via deep insert
• System stores Latitude/Longitude/Timezone in SEP database (not sent to S/4 - SEP only)
• System receives confirmation from S/4
• UI shows parsed address fields instead of single Address string
• UI shows geocoordinates for map visualization
• Info message: "Customer contact data synced with S/4"
• When creating or updating a Location with `S4_IsSynced = true`:
• System sends address, contact person (ContactFirstName, ContactLastName), email, and phone data to S/4 via deep insert
• Contact person information helps delivery drivers coordinate deliveries
• System stores Latitude/Longitude/Timezone in SEP database
• System receives confirmation from S/4
• UI shows contact person fields for delivery coordination
• Info message: "Location contact data synced with S/4"
• Customer enhancements:
• Added parsed address fields (City, State, PostalCode, Country) - replaces hardcoded values
• Added geocoordinates (Latitude, Longitude, Timezone) - enables map visualization
• Email and phone retained (already existed)
• UI shows new "Address Details" and "Geographic Info" facets
• Location enhancements:
• Added contact person fields (ContactFirstName, ContactLastName) - for delivery coordination
• Added email and phone fields - direct contact with location
• Address and geocoordinates retained (already existed)
• UI shows new "Contact Person" facet

Acceptance Criteria

• Customer detail page displays interactive map section below Geographic Info facet
• Map shows marker at Customer's Latitude/Longitude coordinates
• In edit mode (draft), marker is draggable
• Dragging marker updates Latitude, Longitude, and triggers reverse geocoding
• Reverse geocoding auto-populates: Address, City, State, PostalCode, Country_code
• Map control includes geocode search button
• Entering address in geocode search centers map and updates coordinates
• In display mode (active entity), map is read-only (no dragging)
• If coordinates are empty, map shows default location without marker
• OpenStreetMap provider used with Nominatim geocoding API

Technical Implementation:

• Created `app/customers/webapp/ext/view/CustomerMap.fragment.xml` - Map UI fragment
• Created `app/customers/webapp/ext/controller/CustomerMapController.js` - Event handlers
• Updated `app/customers/webapp/manifest.json` - Added CustomerMapSection
• Added i18n labels: `CustomerMap` and `LocationMap`
• Reused existing `app/common/maps/MapControl.js` - Custom SAPUI5 control
• Reused existing `app/common/maps/OpenStreetMapProvider.js` - Nominatim integration
• Controller implements `onLocationChanged` event handler
• Controller implements `_updateAddressFromGeocoding` with full address parsing
• Controller implements `_getCountryCode` mapping (25+ countries)

Field Mappings (Reverse Geocoding):

| Nominatim Component | Customer Field | Update Method |

|---------------------|----------------|---------------|

| `house_number + street` | `Address` | Concatenated |

| `city/town/village` | `City` | Direct |

| `state` | `State` | Direct |

| `postcode` | `PostalCode` | Direct |

| `country` (name) | `Country_code` | Mapped via dictionary |

| `lat` | `Latitude` | Direct |

| `lon` | `Longitude` | Direct |

API Integration:

• Geocoding: `https://nominatim.openstreetmap.org/search?format=json&q={address}`
• Reverse Geocoding: `https://nominatim.openstreetmap.org/reverse?format=json&lat={lat}&lon={lon}`
• Rate Limit: 1 request per second (public Nominatim instance)

Parity with Location:

• Both Customer and Location have interactive maps
• Both support geocoding (address → coordinates)
• Both support reverse geocoding (coordinates → address)
• Customer has enhanced address parsing compared to Location (can be enhanced)

Definition of Done:

• Map fragment created and configured
• Controller extension implemented with full address parsing
• Manifest.json updated with map section placement
• i18n labels added
• Map displays correctly on Customer detail page
• Draggable marker in edit mode, read-only in display mode
• Geocoding and reverse geocoding functional
• Documentation created: `docs/geocoding-implementation.md`
• Integration test: Geocode address → verify coordinates update
• Integration test: Drag marker → verify address fields auto-populate
• Integration test: Save Customer → verify coordinates persist
• E2E test: Sales rep uses map to set Customer location visually

Future Enhancements:

• Auto-timezone detection from coordinates
• Comprehensive country code library (beyond 25 countries)
• Self-hosted Nominatim for production (remove rate limits)
• Bulk geocoding for existing records
• Distance calculations between Customer and Locations
• Enhanced Location address parsing to match Customer

---

Acceptance Criteria

• Before creating Location with S/4 sync enabled:
• System automatically searches S/4 by:
• Company Name + Country (if Organization)
• FirstName + LastName + Country (if Person)
• If 1+ matches found, shows dialog:
• "Potential duplicates found in S/4"
• Table with columns: BP Number, Name, Address, Created Date
• Buttons: "Use Existing BP [number]" or "Create New BP"
• If "Use Existing BP" selected:
• Links Location to selected BP number
• Does NOT create new BP in S/4
• Sets `S4_IsSynced = true`
• If "Create New BP" selected:
• Proceeds with normal creation flow
• Search only triggered if S/4 sync enabled
• Search timeout: 3 seconds (then proceed to create)

Acceptance Criteria

• CPQ can trigger a contract creation flow that reaches ECC (via middleware)
• ECC returns a contract number (e.g., 'C-2025-000123') and status; this is stored in CPQ as `Contract.ECCContractNumber` and `Contract.ECCStatus`
• 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 (ECCContractNumber, ECCStatus, ECCErrorCode, ECCErrorMessage, ValidFrom, ValidTo, Parties[], Items[])
• 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 contract and receives normalized response
• CAP maps the response and persists ECCContractNumber 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

• New configuration page in the admin console: "AI Assistant Prompt Tuning"
• Fields to configure:
• System Prompt Template per use case (text area)
• Use Case 1: Greetings and Onboarding
• Use Case 2: Customer Data Management
• Use case 2.1: Create Customer
• Use case 2.2: Update Customer
• Use case 2.3: Search Customer
• Use case 2.4: Visualize Customers in Map
• Use Case 3: Location Data Management
• Use case 3.1: Create Location
• Use case 3.2: Update Location
• Use case 3.3: Search Location
• Use case 3.4: Visualize Locations in Map
• Use Case 4: Quotation Assistant
• Use case 4.1: Create Quotation
• Use case 4.2: Update Quotation
• Use case 4.3: Search Quotation
• Use case 4.4: Add Products to Quotation
• Use case 4.5: Calculate Prices and Discounts
• Use case 4.6: Apply Discounts to Quotation
• Use case 4.7: Visualize Quotations in Map
• Use Case 5: Plant Data Management
• Use case 5.1: Create Plant - Not allowed via LLM, but could submit request to the PM team
• Use case 5.2: Update Plant - Not allowed via LLM, but could submit request to the PM team
• Use case 5.3: Search Plant
• Use case 5.4: Visualize Plants in Map
• Use Case 6: Order Assistant - Not implemented yet
• Use case 6.1: Create Order
• Use case 6.2: Update Order
• Use case 6.3: Search Order
• User Prompt Template (text area)

Acceptance Criteria

• Store prompts and responses in a structured format (e.g., oData enabled service and table in the DB)
• Include metadata such as user ID, timestamp, and interaction context
• Provide an interface for reviewing and analyzing stored interactions
• Ensure data privacy and compliance with regulations (e.g., GDPR)

Acceptance Criteria

• AI assistant can generate map visualizations for Customers and Locations
• Maps are interactive and allow for zooming and panning
• Maps are integrated into chat responses seamlessly
• Ensure performance and responsiveness of map rendering

Acceptance Criteria

Acceptance Criteria

Acceptance Criteria

• The AI assistant should be able to recognize common system error messages.
• The AI assistant should provide explanations for the error messages in user-friendly language.
• The AI assistant should suggest possible solutions or next steps to resolve the errors.

Acceptance Criteria

• The system should allow configuration of the assistant's name.
• The system should allow configuration of the assistant's verbosity level (e.g., concise, detailed).
• The system should allow configuration of the assistant's personality traits (e.g., formal, casual).
• The system should provide a shared system prompt configuration that can be applied across different use cases.
• We should keep the Temperature and the Top P configuration per use case, since those are more related to the creativity of the responses. Some scenarios can allow more creativity than others.

Acceptance Criteria

• The AI assistant should retain context from previous interactions within a session.
• The AI assistant should be able to reference previous messages and information provided by the user.
• The AI assistant should synchronize relevant information with the backend system, including approval status.
• The AI assistant should provide accurate and context-aware responses based on the retained information.

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 Plant field should be configurable as optional or mandatory at sales area Level for Material determination in the Quote Tool

Implementation:

• Added `PlantMandatoryForMaterialDetermination` boolean field to `SalesArea` entity (defaults to `true` for backward compatibility)
• Updated `app/salesareas/annotations.cds` to show the new configuration field
• Modified `srv/handlers/quoteItemsHandlers.js` to check SalesArea config before requiring Plant
• Added i18n label for the new field

---

Acceptance Criteria

Acceptance Criteria

• The SalesUnit field should be removed from the QuoteTemplateItem entity
• The SalesUnit and other product details should be derived from master data via projections

#### Plan:

Simplify QuoteTemplateItems with Master Data Projections

Remove the redundant SalesUnit field from QuoteTemplateItem and derive it (along with other product details) from master data via projections. This ensures data consistency and reduces duplication.

Steps

Remove SalesUnit from QuoteTemplateItem entity in db/schema.cds (line 406) — delete SalesUnit : Association to SalesUnit; since it will be derived via helper view.

Create helper view QuoteTemplateItemsWithProductDetails in srv/services.cds (~line 183) — similar to AllowedProductsForSalesArea, join QuoteTemplateItem with ProductSalesArea on Product_ID and QuoteTemplate.SalesArea_ID to expose:

SalesUnit_code, SalesUnit_name from ProductSalesArea

Product.Description, Product.ProductClassification.Name

Update QuoteTemplateItems projection in srv/services.cds (line 183) — either replace with the helper view or add computed fields that reference the helper view for display purposes.

Update template copying handlers in srv/handlers/quoteHeaderHandlers.js (line 685) and srv/handlers/quoteItemsHandlers.js (line 157) — remove SalesUnit_code: templateItem.SalesUnit_code and instead fetch from ProductSalesArea using existing pattern (lines 265-276 in quoteItemsHandlers.js):

Update QuoteTemplateItems UI annotations in app/quotetemplates/annotations.cds — change SalesUnit_code references (lines 157, 162, 307) to display the projected/computed field as read-only; remove any value list for SalesUnit since it's now derived.

Keep QuoteItem.SalesUnit editable — no changes needed to db/schema.cds for QuoteItem; the existing value list in app/quotes/annotations.cds remains for override capability.

---

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

• The quote tool can trigger a contract creation flow that reaches ECC (via middleware) to get initial prices (already done).
• After sales rep reviews prices, the quote tool can trigger a contract update flow that creates condition records for discounts/surcharges and finalizes the contract in ECC.
• ECC returns a contract number (e.g., 'C-2025-000123') and the items with updated prices; this is stored in the QuoteItems.
• Error messages from ECC are captured and displayed in the Quote tool.

Acceptance Criteria

• System captures `InitialTotalNetAmount` from the first ECC contract sync response (before condition records applied)
• System captures `RepricedTotalNetAmount` from the ECC contract update response (after condition records applied)
• System computes `PricingDelta = InitialTotalNetAmount - RepricedTotalNetAmount` (positive = discount granted)
• If `PricingDelta >= ApprovalRuleConfig.ThresholdAmount` for the Sales Area, quote requires approval
• On submit for approval:
• Quote Status changes from `P` (In Process) to `R` (Pending Approval)
• Condition records are created with ValidTo = today + 1 day (short validity to block ERP usage)
• System logs matched rule(s), delta, and timestamps in `ApprovalLog`
• If no rules match (delta below all thresholds), quote proceeds without approval
• Sales Rep sees clear feedback: "Quote submitted for approval. Pricing change: -$500.00"

Acceptance Criteria

• Approver sees list of quotes pending their approval (filtered by their approval level)
• Quote detail page shows approval context panel:
• Initial Total: $3,000.00
• Repriced Total: $2,500.00
• Pricing Delta: -$500.00 (16.7% reduction)
• Matched Rule(s): "Delta > $200 requires Level 2 approval"
• Submitted By: [Sales Rep name] at [timestamp]
• Approve action:
• Quote Status changes from `R` to `D` (Approved)
• System extends condition record validity to quote's original ValidTo date
• System logs approval in `ApprovalLog` with approver, timestamp, optional comments
• Sales Rep receives notification: "Your quote [number] was approved by [approver]"
• Reject action:
• Quote Status changes from `R` to `X` (Rejected)
• Approver must provide rejection reason (mandatory comment)
• Condition records remain with 1-day validity (will expire and not affect ERP)
• System logs rejection with reason in `ApprovalLog`
• Sales Rep receives notification: "Your quote [number] was rejected: [reason]"
• Rejected quotes can be revised and resubmitted (creates new approval cycle)

Acceptance Criteria

• New admin app: "Approval Rule Configuration" accessible from launchpad
• Admin can create `ApprovalRuleConfig` records with:
• Sales Area (mandatory) — rules scoped to specific region
• ThresholdAmount (mandatory) — minimum pricing delta (absolute value) to trigger this rule
• ApprovalLevel (mandatory) — integer 1-5 representing approval authority needed
• Description — human-readable rule explanation
• Priority — for rule ordering when multiple match (lower = higher priority)
• IsActive — toggle to enable/disable without deleting
• Multiple rules per Sales Area allowed (e.g., Level 1 for >$100, Level 2 for >$500, Level 3 for >$1000)
• Rule evaluation takes MAX(ApprovalLevel) from all matching rules
• Validation: ThresholdAmount must be positive, ApprovalLevel 1-5
• Draft-enabled for safe editing

Example Configuration:

| Sales Area | Threshold | Level | Description |

|------------|-----------|-------|-------------|

| US-East | $100 | 1 | Minor discounts - Team Lead |

| US-East | $500 | 2 | Significant discounts - Sales Manager |

| US-East | $2000 | 3 | Major discounts - Regional Director |

| EU-West | €200 | 1 | Standard threshold for EU |

Acceptance Criteria

• Admin can create `ApproverConfiguration` records with:
• Sales Area (mandatory)
• ApprovalLevel (mandatory) — corresponds to levels defined in ApprovalRuleConfig
• Approver (mandatory) — association to UserConfigurations
• BackupApprover (optional) — fallback if primary is unavailable
• ApprovalLimit (optional) — max delta this approver can approve (future use)
• IsActive — toggle to enable/disable
• Multiple approvers can be assigned to same level (parallel approval — any one can approve)
• Validation: Approver must be different from BackupApprover
• Warning if no approver configured for a level referenced by active rules
• Draft-enabled for safe editing

Example Configuration:

| Sales Area | Level | Approver | Backup |

|------------|-------|----------|--------|

| US-East | 1 | John (Team Lead) | Jane |

| US-East | 2 | Sarah (Sales Mgr) | Mike |

| US-East | 3 | Bob (Director) | Sarah |

Acceptance Criteria

• Every approval-related action creates an `ApprovalLog` entry:
• SUBMITTED: Who submitted, when, pricing delta, matched rules
• APPROVED: Who approved, when, optional comments, condition record IDs created
• REJECTED: Who rejected, when, mandatory reason
• RESUBMITTED: After rejection, new submission with updated context
• Log entries are immutable (no update/delete capability)
• Log entries include snapshot of pricing data at time of action (not references that could change)
• Accessible via read-only projection in service
• Filterable by: Quote, Sales Area, Date Range, Action Type, User

Acceptance Criteria

• Quote list shows approval status with color-coded badges:
• `P` (In Process) — Blue
• `R` (Pending Approval) — Orange/Yellow
• `D` (Approved) — Green
• `X` (Rejected) — Red
• Quote detail page shows:
• For Sales Rep (submitter):
• "Submit for Approval" button visible when quote has pricing delta and status is `P`
• Pricing context: Initial vs Repriced totals, delta amount and percentage
• If pending: "Awaiting approval from [Level X approvers]"
• If rejected: Rejection reason displayed prominently with "Revise and Resubmit" guidance
• For Approver:
• "Approve" and "Reject" buttons visible when status is `R` and user is authorized approver
• Full pricing context panel (Initial, Repriced, Delta, Matched Rules)
• Comment field for approval notes or rejection reason
• Actions are disabled with tooltip explanation when not applicable
• Confirmation dialog before approve/reject with summary of action

Acceptance Criteria

• On "Submit for Approval": Condition records created with `ValidTo = today + 1 day`
• This ensures records exist in ECC but are not usable for invoices beyond the short window
• On "Approve": NEW condition records created with `ValidTo = QuoteHeader.ValidTo`
• SAP ECC automatically handles overlap resolution by VARKEY/ConditionType
• Old short-validity records become obsolete
• On "Reject": Send the condition record payload with Deletion flag to ECC to remove short-validity records
• ECC correctly processes overlapping condition records without errors
• If quote is revised after rejection and resubmitted: New short-validity records created
• Condition record creation failures during approval flow surface clear errors

Acceptance Criteria

Acceptance Criteria

Acceptance Criteria

Acceptance Criteria

Acceptance Criteria

• `S4SANDBOX` added to `BackendType` entity.
• `contractsAdapter.js` (and others) updated to handle `S4SANDBOX` type.
• Application configured to connect to `https://sandbox.api.sap.com/s4hanacloud`.
• API Key authentication handled (header `APIKey`).

Acceptance Criteria

• Search UI shows a combined list of Customers.
• Columns: Name, ID, Status (In SEP, In S/4, Synced), Last Synced Date.
• "In SEP" icon/badge: Green if exists locally.
• "In S/4" icon/badge: Blue if exists in Sandbox.
• Search query applies to both local DB and S/4 API (`API_BUSINESS_PARTNER`).

Acceptance Criteria

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

Acceptance Criteria

• `AuditLogHeader` and `AuditLogDetail` entities are defined in `db/schema.cds`.
• `AuditLogHeader` includes: `AuditLogID (UUID)`, `EntityName`, `EntityID`.
• `AuditLogDetail` includes: `AuditLogDetailID (UUID)`, `PerformedBy`, `PerformedAt`, `AuditLogID` (composition), `ActionType`, `Description`, `EntityID`, `ChangeSummary (LargeString)`.
• Entities deployed and visible in the database.

---

#### 25Q4-E10-02: Expose Audit Log Service & Projections

Priority: Must Have

Story Points: 2

Status: Done (Completed: 2025-12-22)

• Audit log entities are exposed in `srv/services.cds` as read-only projections.
• Service is registered and accessible via OData.
• Filtering and sorting by entity, action type, date, and user is supported.

---

#### 25Q4-E10-03: Implement Audit Log Write Handlers

Priority: Must Have

Story Points: 3

Status: Done (Completed: 2025-12-22)

• Utility or handler functions exist to create audit log entries for all required actions.
• Handlers are called from retention jobs, redaction logic, and config change flows.
• ChangeSummary is populated with relevant JSON (fields redacted, config before/after, etc.).
• No update/delete allowed on audit log entries after creation.

---

#### 25Q4-E10-04: RBAC for Audit Log Access

Priority: Must Have

Story Points: 1

Status: Done (Completed: 2025-12-22)

• OData service for audit logs is accessible to all authenticated users.
• Full audit log UI/app (all logs, all entities) is restricted to admin/manager roles.
• Contextual log access (e.g., quote log via object page or popover) is enforced in the UI and/or service handler, showing only logs for objects the user is authorized to view.
• No sensitive audit data is exposed outside the user’s object context.

---

#### 25Q4-E10-05: Audit Log UI for Review & Analytics

Priority: Should Have

Story Points: 3

Status: Done (Completed: 2025-12-22)

• New Fiori Elements app (List Report/Object Page) for audit logs.
• Supports filtering by entity, action type, user, and date range.
• Detail page shows ChangeSummary and all metadata.
• UI is read-only and only visible to authorized roles.