Send Transactions

In this article

Overview of Send Transactions methods

Advantages and Disadvantages

Scenario-Based Recommendations

 

LS Central offers several methods to send transaction data from the POS to HO.

These methods are triggered by actions or POS commands and they do not require a Scheduler job setup, but they need a distribution location to be set up.

The available methods are:

Data Director (DD) Push

POS Web Services

Send Transactions Using Web Replication

Send Transaction by Storage Queue

Overview of Send Transactions methods

Data Director (DD) Push

Details on this method are intentionally not provided because it is not recommended for SaaS implementations.

Using Web Requests (POS Web Services)

This method uses POS Web Services to send transactions directly from the POS to Head Office. Each transaction is sent via a web service endpoint exposed by the HQ system.

Key Characteristics

  • POS initiates the communication
  • Synchronous communication
  • Immediate acknowledgment from Head Office.

Typical Flow 

POS → POS Web Service → Head Office

Notes

  • Extensibility requirement: Because transactions are sent through a dedicated XMLport exposed as a web service endpoint, any extension to the data being transmitted, whether adding fields to an existing LS Central table or including entirely new tables, requires to:
    • Create a new XMLport, implementing all fields and tables to be included
    • Create a new codeunit to publish the new XMLport
    • Create a new codeunit to subscribe to events in codeunit 10000801 - LSCSendTransactionUtilsV2 to implement changes

    This is an inherent constraint of the Web Services approach: the schema is fixed at the endpoint definition, so every data change must be explicitly reflected in a new endpoint.

Using Web Replication

Web Replication is part of the LS Central replication framework, where transactions are stored locally and sent to Head Office using replication jobs over HTTP/HTTPS.

Key Characteristics

  • POS initiates the communication
  • Synchronous communication
  • Transactions are sent in a background session by design. POS UI does not freeze at the end of the transaction, when the transaction is being sent.

Typical Flow 

POS → Web Replication Jobs → Head Office

Notes

  • Extensibility: Web Replication automatically handles new fields added to existing LS Central tables, but adding new tables still requires creating a codeunit to subscribe to OnAfterLoadTransactionTables and register the additional tables for replication.

Using Storage Queue

When a transaction is completed at the POS, instead of being sent immediately to Head Office, it is placed in an intermediate storage area. From there, a background process picks it up and forwards it to Head Office, where it is applied just as it would be with any other method. The POS does not wait for Head Office to respond — once the transaction is handed off to the intermediate storage, the POS is free to continue. This makes the method resilient to Head Office unavailability and well suited for environments with many POSes sending transactions simultaneously.

Under the hood, this intermediate storage is implemented using Azure Service Bus combined with an Azure Storage Account (Blob Container). The POS writes the transaction payload to a Blob Container in Azure Storage, and an Azure Service Bus message is published to signal that a new transaction is ready for processing. A background service consumes the Service Bus message, retrieves the payload from the Storage Account, and posts it to Head Office. Because the POS never calls Head Office directly, this approach is fully asynchronous and resilient to HO unavailability.

Key Characteristics

  • Asynchronous and decoupled architecture
  • POS writes to Azure Blob Storage; Azure Service Bus signals readiness to the processing service
  • No direct web service calls from POS to Head Office
  • Strong fault tolerance and retry capability via Service Bus
  • Supports high transaction volumes across large POS estates.

Typical Flow 

POS → Replication Jobs → Azure Blob Storage (payload) + Azure Service Bus (signal)
Asynchronous process:
  - Replication job runs in Head Office → Prompts Azure Service Bus for transactions in the queue, and fetches the transactions from Azure Blob Storage → Applies the transaction to Head Office

Notes

  • Introduced in LS Central 26.1
  • Extensibility: Like Web Replication, the Storage Queue method uses the same LS Central replication framework for packaging and processing data. New fields added to existing tables are included automatically, but adding new tables requires a custom codeunit subscribing to OnAfterLoadTransactionTables to register them for replication. This remains a key architectural advantage over the Web Services approach, which requires redefining endpoints for any schema change.

Advantages and Disadvantages

Web Services

Disadvantages

  • Relies on SOAP web services, which are subject to per-environment operational limits and are expected to be deprecated by Microsoft in the future
  • May block POS UI (when not running in a background session — configuration in the POS Functionality Profile)
  • Extending the replicated data requires customization (creating new XMLport and new codeunits to publish new web service endpoint).

Best Fit

  • Flagship or corporate stores
  • Environments with stable, high-quality connectivity
  • When near real-time posting is a business requirement.

Web Replication

Advantages

  • Extending the replicated data still requires customization for new tables, although new fields are handled natively by the replication framework.

Disadvantages

  • Requires additional web service calls, when compared to other replication methods.

Best Fit

  • Standard retail stores
  • Multi-store environments, without very high transaction volumes that could frequently hit Business Central Online's web service operational limits
  • Stores with occasional connectivity disruptions
  • Organizations already using replication heavily
  • Simpler implementations that do not require the "complexity" of setting up external Azure services (Service Bus and Storage Account)
  • Implementations where new fields have been added to transaction-related tables that need to be replicated.

Storage Queue

Advantages

  • Transactions are processed asynchronously rather than through direct web service calls from the POS to Head Office, making it well suited for implementations with a large number of POSes and helping avoid hitting operational limits when sending transactions to HO
  • Extending the replicated data does not require customization — new fields and tables to be replicated are handled natively by the replication framework shared with Web Replication
  • Uses modern SaaS-native technologies (Azure Service Bus and Azure Storage), providing high resilience and scalability at a low operational cost
  • Excellent for high transaction volumes
  • Decouples POS from HQ completely.

Disadvantages

  • Requires a learning curve, although Azure Service Bus and Storage are low-complexity and easy to adopt
  • Involves an additional cost, although the estimated pricing is very low and accessible.

Best Fit

  • Large enterprise or global retail operations
  • High-volume POS environments
  • Cloud-first or distributed architectures.

Scenario-Based Recommendations

Scenario Recommended Method
Small store with stable internet Web Services
Minimal operational complexity wanted Web Services
Medium retail chain, with relatively low transaction volume Web Replication
Very high transaction volumes Storage Queue
Centralized monitoring Storage Queue