Feeding a video-analytics platform: daily LS Central POS exports to Azure Blob Storage

A multi-store retailer's loss-prevention platform matches point-of-sale (POS) transactions to camera footage, so it needs each day's transactions from LS Central. We built a 14-object extension that writes three CSV files per store per day and uploads them to Azure Blob Storage, and it is in daily use.

August 2025 – July 2026 · Business Central · 3 min read · Published October 2026

Industry

Specialty retail

Period

August 2025 – July 2026

Scale

14 objects

3 file layouts

0 table extensions

Platform

Business Central online + LS Central; Azure Blob Storage; Microsoft Entra ID app registration (OAuth 2.0 client credentials) via the System Application.

Services

System IntegrationERP Optimization & Automation

Building blocks

LS CentralAzure Blob StorageMicrosoft Entra ID

Why a video-analytics platform needs POS data

The client is a multi-store retailer on LS Central whose loss-prevention platform matches POS transactions to camera footage. The matching works transaction by transaction, so daily totals are not enough: for each store and day, the platform needs every transaction, the items on it, and how it was paid. Without that data, it has footage and nothing to match it against.

That data lives in LS Central, on Business Central online, and the platform takes its files from Azure Blob Storage. Between August 2025 and July 2026 we built the extension that connects the two: it exports each day's data as three CSV files per store, signs in with Microsoft Entra ID, and uploads the files.

What the extension does

1. AuthenticateThe extension gets an access token from Microsoft Entra ID through the System Application, using an app registration and the OAuth 2.0 client credentials flow. It signs in as itself rather than as a user, so the export can run from the job queue with nobody at the keyboard.
2. Build the filesXMLports write three CSV files for each store and day: the transaction headers, the item lines, and the payments, with cash payments consolidated. Only stores with numeric store numbers are exported, and file names follow a YYYYMMDD-NNN pattern.
3. UploadEach file goes to Azure Blob Storage, authorized with the token from the first step.
4. Log the runEach run, scheduled or manual, gets its own entry in the export log.

Operations

• A recurring job-queue entry runs the export for the current day, so each day's files go out without anyone starting them.
• A manual page re-runs it for a chosen date, for yesterday, or for the last 24 hours.
• The same page has a store filter, so a re-run can cover only the stores that need it.
• A connection test on the setup page checks the settings on demand.

Design choices

The file layouts live in XMLports, declared as objects rather than assembled as text in code. None of the 14 objects extends a standard table or page, and none subscribes to an event. The extension reads the transactions LS Central has already recorded, keeps its setup and export log in tables of its own, and comes with its own permission set, so installing it changes nothing in standard Business Central or LS Central.

Outcome

The export is in daily use, feeding the loss-prevention platform. Its 14 objects compile with 0 errors and 0 warnings on Business Central 27.0 and 27.5.

Takeaways

• Keep integrations small and light on dependencies. With no event subscriptions and no table or page extensions, a new Business Central release has little in this export to break.
• Put secrets in setup, never in code. Code goes into source control and every build; a secret entered on the setup page does not.
• Pair the schedule with a manual re-run. The job queue covers the normal day; the manual page, with its date options and store filter, covers a day or a store that has to be sent again.