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

Exposes Currency (table 4) master data — code, description, rounding precision, and the LSC-specific POS presentation attributes (currency symbol and its placement) — as a read-only OData v4 entity. Replaces the legacy RetailWebServices read used by LS Omni''s CurrencyGetById(id, culture) operation (GetGeneralWebRequestXML("Currency", "Code", id)). Microsoft''s own standard v2.0 currencies API does not project the POS-specific rounding/symbol fields exposed here, so this is a separate, purpose-built endpoint. This release is read-only: Insert, Modify, and Delete are not supported over the API; currencies are maintained through the LS Central back-office UI.

Exposes the legacy SOAP GetCustomerCard operation (LSCGetCustomerCard / LSCGetCustomerCardUtils codeunits) as a standalone, read-only OData v4 entity. This is a top-level lookup, not nested under another entity: a caller supplies the customer to look up via the customerNo filter, e.g. GET .../customerCardLines?$filter=customerNo eq ''10000''. An omitted or non-resolving customerNo filter is not an error condition — it simply returns an empty result set. Each row is a computed (label, value) pair built fresh from a single Customer record on every request — this is not a persisted table, so there is no meaningful "last modified" timestamp for a row and lastModifiedDateTime is deliberately not exposed. The 12 rows, their labels, and their order exactly match the legacy operation''s output: Customer No, Name, Address, Address2, Postcode/City (Post Code and City concatenated with ''/''), Country, Phone No., E-Mail, Contact, Blocked, Balance, Credit Limit. viewCode is a verbatim echo of the request, matching legacy''s View parameter: ''01'' against a resolving customer returns zero rows (not an error — the customer still resolved, the requested view simply has none); blank or any other value (legacy has no ''02''/''03'' branch here) returns the full 12-row dump. A viewCode filter expression is treated as no criterion. The underlying "LSC WS Line Buffer" table (also used, unaffected, by several legacy SOAP web service codeunits) and its "Source No." extension field, together with "LSC Card Line Buffer Mgt", are intentionally generic and reusable — the Item and Vendor "card" APIs (GetItemCard / GetVendorCard replacements) reuse the same buffer table and helper codeunit rather than each defining their own. This entity is read-only: Insert, Modify, and Delete are not supported over the API.

Exposes posted customer invoice entries (Cust. Ledger Entry, filtered to Document Type = Invoice) as a read-only OData v4 entity, nested under LSC Customer API as $expand=customerInvoices. Replaces the legacy RetailWebServices SOAP GetCustomerInvoices operation (codeunits LSCGetCustomerInvoicesUtils / LSCGetCustomerInvoices). Only invoice-type entries are returned — other ledger entry types (payments, credit memos, etc.) are out of scope for this endpoint; see the separate, broader LSC Customer Entries API for all entry types. The amount and remainingAmount fields are deliberately sourced from the LSC extension fields "LSC Amount Int" / "LSC Remaining Amount Int" rather than the base Amount / Remaining Amount FlowFields, for parity with the legacy SOAP operation''s unposted-POS-payment amount adjustment behavior — this is a deliberate parity choice, not an oversight. This release is read-only: Insert, Modify, and Delete are not supported over the API.

Exposes Customer (table 18) master data — identity, contact, address, and the commercial attributes (price group, discount group, currency, VAT status) an external system needs to price and localise an order — as a read-only OData v4 entity. Replaces the legacy RetailWebServices SOAP Customer read (the generic GET_TABLE_DATA reflection read and the GetCustomer projection in GetCustomerXML) for Unified Commerce integrations such as LS Ecommerce. The nested customerInvoices part ($expand=customerInvoices) replaces the legacy SOAP GetCustomerInvoices operation, returning the customer''s posted invoice-type Cust. Ledger Entry records. This release is read-only (Phase 1): Insert, Modify, and Delete are not supported over the API; customers are maintained through the LS Central back-office UI. The intended filter entry points are no, name, email, and phoneNo — plain scalar fields BC''s OData v4 stack filters natively via $filter. A future phase may add write support.

Exposes the legacy SOAP GetItemCard operation (LSCGetItemCard / LSCGetItemCardUtils codeunits) as a standalone, read-only OData v4 entity. This is a top-level lookup, not nested under another entity: a caller supplies the item to look up via the itemNo filter (e.g. GET .../itemCardLines?$filter=itemNo eq ''40180'') or, when itemNo is blank, via the barcodeNo filter — itemNo always wins when both are supplied, matching legacy precedence. variantCode narrows to one item variant (ignored when resolving by barcodeNo, where the variant instead comes from the barcode''s own variant); storeNo/locationCode scope the Inventory/Qty rows to a store or location; viewCode selects the response shape: blank or ''01'' returns the 7-row card (Item, Description, Variant Code[, Variant Description, Variant Description 2], Inventory, Qty in PO, Qty in SO, Qty inb. TO); ''02''/''03'' return a matrix lookup (a Dimension Value row plus one row per sibling variant, keyed by the other dimension) and never include Inventory/PO/SO/TO rows; any other viewCode returns an empty result set. barcodeNo, variantCode, storeNo, locationCode and viewCode are a verbatim echo of the request, not resolution output — they exist only so the platform''s $filter can match generated rows; itemNo is the exception and always holds the resolved item number. An unresolved item, barcode, variant, store or location is not an error condition — it simply returns an empty result set. A filter expression (wildcards, ranges, or/and operators) on any of these properties is treated as no criterion. Each row is a computed (label, value) pair built fresh on every request — this is not a persisted table, so there is no meaningful "last modified" timestamp for a row and lastModifiedDateTime is deliberately not exposed. The underlying "LSC WS Line Buffer" table (also used, unaffected, by several legacy SOAP web service codeunits) and its "Source No." extension field, together with "LSC Card Line Buffer Mgt", are the same shared, generic infrastructure the Customer Card API and Vendor Card API reuse rather than duplicating. This entity is read-only: Insert, Modify, and Delete are not supported over the API.

Read-only projection of Item Category codes and descriptions. Item Category is the standard Business Central classification table used across LS Central as the "Item Category Code" lookup target from many entities, most notably the LSC Retail Product Group (see the separate LSC Retail Product Group API, whose own categoryName field is a FlowField sourced from this same table via the assigned Item Category Code). This entity exists so a consumer can resolve or enumerate category codes/descriptions directly, without depending on a specific product group record. productGroups is a read-only, $expand-able child collection of the Retail Product Groups assigned to this item category; it nests one level further into productGroupItems (the Items in each group), so a caller can $expand=productGroups($expand=productGroupItems) to retrieve the full three-level tree in a single request.

Exposes Item (table 27) master data — identity, description, product grouping, and the LSC-specific retail attributes (product group, season, item family, scale item) needed for point-of-sale and catalog lookups — as a read-only OData v4 entity. Replaces the legacy RetailWebServices GET_TABLE_DATA read used by LS Omni''s ItemSearch(search) operation (GetGeneralWebRequestXML("Item", "Search Description", "search")). Microsoft''s own base-app "Item Entity" API (items, v2.0) is a compiled dependency this app does not reference and does not project the LSC-specific fields exposed here, so this is a purpose-built endpoint rather than an extension of that entity. searchDescription is filterable with OData $filter=contains(searchDescription,''...'') for free-text search parity with the legacy wildcard (search) semantics — this requires no special page code, since contains() is automatic OData v4 behavior on any exposed field. This release is read-only: Insert, Modify, and Delete are not supported over the API; items are maintained through the LS Central back-office UI.

Exposes VAT Posting Setup (table 325) master data — the VAT business/product posting group combination, VAT %, calculation type, VAT identifier, sales/purchase VAT accounts, and VAT clause — as a read-only OData v4 entity, replacing the legacy SOAP GetVATPostingSetup replication read. Legacy stays available unchanged for the 18-month coexistence window. This entity is NOT store- or distribution-scoped: the legacy operation itself performs no such filtering (it calls the shared replication helper with an empty store parameter, which disables all distribution filtering), and the base table has no store/location dimension — every VAT Posting Setup combination in the company is returned to any caller, matching legacy behavior exactly. Read-only: VAT posting setups are maintained through the LS Central back-office UI.

Exposes the legacy SOAP GetVendorCard operation (LSCGetVendorCard / LSCGetVendorCardUtils codeunits) as a standalone, read-only OData v4 entity. This is a top-level lookup, not nested under another entity: a caller supplies the vendor to look up via the vendorNo filter, e.g. GET .../vendorCardLines?$filter=vendorNo eq ''10000''. An omitted or non-resolving vendorNo filter is not an error condition — it simply returns an empty result set. Each row is a computed (label, value) pair built fresh from a single Vendor record on every request — this is not a persisted table, so there is no meaningful "last modified" timestamp for a row and lastModifiedDateTime is deliberately not exposed. The 6 rows, their labels, and their order exactly match the legacy operation''s output: Vendor No, Name, Name 2, Phone No., Fax No., E-Mail. viewCode is a verbatim echo of the request, matching legacy''s View parameter: ''01'' against a resolving vendor returns zero rows (not an error — the vendor still resolved, the requested view simply has none); blank or any other value (legacy has no ''02''/''03'' branch here) returns the full 6-row dump. A viewCode filter expression is treated as no criterion. The underlying "LSC WS Line Buffer" table (also used, unaffected, by several legacy SOAP web service codeunits) and its "Source No." extension field, together with "LSC Card Line Buffer Mgt", are the same shared, generic infrastructure the Customer Card API reuses rather than duplicating. This entity is read-only: Insert, Modify, and Delete are not supported over the API.

Exposes the languages configured for LS Central data translation — each row is a language code (linked to the Business Central Language table) whose translations may be maintained in LS Central. Provided as a read-only OData v4 entity replacing the generic RetailWebServices GET_TABLE_DATA read of table "LSC Data Translation Language". This release is read-only (Phase 1): Insert, Modify, and Delete are not supported over the API; translation languages are maintained through the LS Central back-office UI. A future phase may add write support.

Exposes the feature-flag setup rows (table "LSC Feature Flags Setup") as a flat, standalone read-only OData v4 entity — each row is a Store No. / POS Terminal / Feature Flag combination with its Value. Replaces the per-terminal feature-flag lookup portion of the legacy RetailWebServices TerminalGetById SOAP call (GetGeneralWebRequestXML on "LSC Feature Flags Setup" filtered by POS Terminal). This entity does NOT implement fallback/precedence resolution: it is a plain projection of the setup table, one top-level call, no server-side merging. A row with a blank POS Terminal represents a store-level default, and a row with both Store No. and POS Terminal blank represents a global default; the consumer is responsible for querying all three levels and merging them client-side if that semantic is needed, mirroring the legacy caller''s own id + "|''" OR-blank pattern (for example: $filter=posTerminal eq ''X'' or posTerminal eq ''''). This release is read-only (Phase 1): Insert, Modify, and Delete are not supported over the API.

Read-only projection of Item Management (picking/receiving) documents, provided so a caller can locate a document and post it. Hosts the post bound action, which replaces the legacy SOAP operation IMDocumentPost: it confirms or posts the document identified by this entity''s id, using the terminalNo, requestType, postMethod and documentType supplied on the request. Unlike the legacy operation, which always returned HTTP 200 with a failure message embedded in the response body, post raises a real error - and therefore an HTTP 4xx/5xx status - when the underlying posting fails, so callers can rely on the HTTP status code rather than parsing the response body.