Electronic Sales Labels (ESL)

Classification and setup guidance for electronic sales labels in Automotive with focus on project prerequisites, data flow, external platform integration, and stable operating procedures.

Purpose

This page explains how Electronic Sales Labels (ESL) should be classified from a business and technical perspective in a Automotive project. The older knowledge base describes the solution as an existing demo or integration function between Business Central and an external ESL platform. For current projects, that means ESL is not a self-running feature but a deliberately planned integration scenario with hardware, network, platform, and clear operating rules.

Important classification

Statement	Meaning for the project
ESL is an integration scenario with an external platform	In addition to Business Central, the label platform, access points, and radio coverage must work reliably.
The legacy documentation describes a demo function	Availability and scope must be confirmed actively in the project. Not every environment has the same delivered behavior.
Data is not maintained directly on the label	The leading data source is Business Central or an agreed source application. The label only displays the released state.
Changes have operational impact	Wrong texts, prices, item assignments, or status values become visible immediately in the store, warehouse, or shop floor.

Typical end-to-end flow

An approved process changes relevant item, price, stock, or status data in Business Central.
The integration prepares a data package for the target label.
The data is sent by HTTP and JSON to the external ESL platform.
Based on its configuration, the platform maps the fields to the correct label and layout.
Access point and radio infrastructure distribute the change to the physical label.
The business area verifies on site that the displayed content, update timing, and assignment are correct.

graph LR;

%% Nodes
A["Change in Business Central"]
B["Approved ESL process"]
C["HTTP/JSON data package"]
D["External ESL platform"]
E["Access point / radio network"]
F["Electronic label"]
G["Visual and plausibility check"]

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E
E ==> F
F ==> G

%% Classes
class A btProcessTitle
class B,C,D,E,F,G btProcessActive

Which content typically appears on ESL

The exact display is project-specific. Typical content includes:

item number or item reference,
short text or description,
price or condition information,
unit of measure or packaging reference,
warehouse, bin, or status information,
visual markers for exception states.

The key point is that for each label type it must be defined clearly which fields are leading and which process is allowed to update them.

Critical setup areas

Area	What must be clarified
Master data in Business Central	Which items, variants, units, prices, or status information should appear on the label
Process release	Which changes are actually allowed to update a label and who owns that release
External platform	Mapping of field values, layouts, label IDs, locations, and update rules
Network and hardware	Reachability of the platform, access points, radio coverage, and label power state
Operations and support	Who detects issues, who reassigns labels, and what the manual fallback process is

Historically documented technical prerequisites

The legacy documentation names outgoing connections for provisioning, cloud communication, and time synchronization in older installations. These details must not be copied blindly because vendor setup and architecture can change. For project starts, this means:

Historically named point	Meaning
TCP 443 outbound	typical base requirement for platform and provisioning communication
TCP 7354 outbound	project-specific vendor or cloud communication in older scenarios
UDP 123 outbound	time synchronization so that status and update timestamps remain consistent

Always use the current vendor and project specification for productive approvals. The historical list is only a validation horizon, not a replacement for current approval.

Recommended project flow

Define which business information should actually be shown electronically.
Define the leading data source and the allowed update triggers per process.
Clarify the target architecture for platform, access points, and radio coverage early with infrastructure and the vendor.
Assign label, location, item reference, and layout in a controlled pilot area.
Test at least one complete change case from Business Central to the physically updated label.
Document how faulty labels are detected, reassigned, or temporarily replaced.

Control steps

Point in time	What to check
Before technical setup	ESL confirmed as project-approved scope
Before the first integration test	leading fields, layout logic, and label assignment documented
Before pilot operation	network approvals, access points, and radio coverage checked
Before go-live	at least one real change case successfully updated all the way to the label
During operation	wrong displays, time delays, and unassigned labels are monitored

Typical error patterns

Situation	Possible cause	Check
Label does not change	transfer, trigger, or platform assignment does not work	inspect process trigger, HTTP transfer, and label mapping
Wrong item or wrong price appears	assignment between item, layout, and label ID is incorrect	inspect master data, label assignment, and field mapping together
Only some areas receive updates	radio coverage or access point setup is insufficient	perform location tests and infrastructure checks
Display is delayed	queue, platform processing, or network latency creates backlog	measure transfer path and update timing
Business users do not trust the labels	pilot, visual checks, and operating rules were not introduced cleanly	tighten the check routine and responsibilities

Result

You treat ESL not as isolated hardware but as a complete business process with BC, platform, and infrastructure responsibilities.
You know which approvals and checks are required before pilot or productive use.
You reduce wrong displays because data source, triggers, label assignment, and on-site verification are considered together.