(v1.0) LS Central scanPayGo API (1.0.0)

The feature-flag child collection of spgProfiles - each row is a feature toggle set on a ScanPayGo profile. Reachable standalone or via $expand from the spgProfiles entity. The underlying table''s Feature Value field is deliberately excluded - it is typed Blob, which is not a supported field type on an API page.

Replaces the legacy SPGProfileGet SOAP operation with a read-only OData v4 entity. The legacy operation is left untouched and remains available during an 18-month coexistence window - this entity is purely additive and opt-in for consumers ready to migrate. This first phase is read-only: Insert, Modify, and Delete are not supported over the API. The base GET on this entity set is intentionally unfiltered/unscoped: "LSC Scan Pay Go Profile" is reference data with no store or distribution ownership of its own. Store-scoped resolution (replicating the legacy SPGProfileGet operation''s StoreID-based lookup) is available via the resolveForStore action, not via a filter on this entity set. Two bound actions are provided: resolveForStore(storeId) replicates the legacy SPGProfileGet StoreID resolution chain (direct store link, then store-group fallback, then the "All Stores" group) and returns the matching profile(s) as JSON - the legacy store-to-store-group resolution is not guaranteed to be 1:1, so more than one profile can be returned for a single store. checkSecurity(storeNo, customerOrderId) delegates to the existing ScanPayGo security-check algorithm for a customer order at a store and returns whether the security check passed. The spgProfileTenders and spgFeatureFlags parts expose the profile''s linked tender types and feature flags and can also be reached standalone or via $expand.

The tender-linking child collection of spgProfiles - each row is a tender type allowed on a ScanPayGo profile. Reachable standalone or via $expand from the spgProfiles entity.

Exposes the ScanPayGo Security Check Log (table "LSC SPG Security Check Log") as an OData v4 entity supporting GET and POST. GET replaces the legacy RetailWebServices SOAP SecurityCheckLog(orderNo) call (GetGeneralWebRequestXML("LSC SPG Security Check Log", "Customer Order ID", orderNo)). A customer order can have multiple log entries; the legacy caller reads the LAST (most recent) row for the order. The OData equivalent of that "most recent" semantic is purely query-side and requires no server-side code: $filter=customerOrderId eq ''...''&$orderby=entryNo desc&$top=1. entryNo is the true primary key (AutoIncrement) and is read-only. POST replaces the legacy SPGLogSecurityCheckResponse SOAP operation: customerOrderId, check, and errorMessage are the only caller-supplied fields on insert. source is always forced to Employee and memberCardNo is always forced blank, exactly matching legacy SPGLogSecurityCheckResponse semantics, regardless of what the client submits for those fields. The customer order must exist (open or posted) or the insert is rejected. Modify and Delete remain unsupported: log entries are append-only. This entity has moved from the customerOrder APIGroup to scanPayGo, consolidating it with the other ScanPayGo entities (spgProfiles, spgProfileTenders, spgFeatureFlags) — this changes the entity''s OData URL path.