Case study · ERP integration

Business Central

Getting retail sales into an enterprise finance system in the exact shape it expects, and making the pipeline visible enough to trust.

Production system

Engagement
Integration engineering
Platforms
Synchronisation service with web interface
Role
Integration design and build
System
Microsoft Dynamics 365 Business Central Verify before publishing
Image placeholder The synchronisation service: the monitoring dashboard showing sales moving from point-of-sale into the ERP, with the transformation step, queue depth and recent activity. assets/portfolio/business-central/featured.png · 16 / 10
Industry
Enterprise operations
Users
Finance and operations teams
Integration
POS sales into ERP
Platforms
Web
Role
Integration engineering
Status
Production

01The business situation

Two systems, both right, speaking different languages.

Sales happen in Lightspeed, a point-of-sale built for a counter. Finance happens in Microsoft Dynamics 365 Business Central, a cloud ERP built to connect sales, service, finance and operations across a business. Both are correct about their own domain and neither describes a transaction the way the other does. Someone has to translate, and if that someone is a person with a spreadsheet, the finance record is always a few days behind the business.

Core challenge

Move transactions between two systems that model them differently, continuously, and let the business see it happening.

Before

Sales reconciled into finance by hand

  • Manual Export
  • Spreadsheet Mapping
  • Delayed Reconciliation
  • No Visibility

After

Transactions flowing into finance in the right shape

  • Point of Sale
  • Transformation
  • ERP Endpoint
  • Monitoring

Sync Service

02The system at a glance

One pipeline. Four connected parts.

  • Monitoring Interface Pipeline activity at a glance
  • Sales Ingestion Transactions from the POS
  • Transformation Layer Reshaped for the ERP
  • Delivery & Retry Into the ERP endpoint
Core PlatformQueue-driven, observable synchronisation
  • Sales Ingestion
  • Data Transformation
  • ERP Delivery
  • Queue Management
  • Activity Monitoring
  • Failure Handling

03Workflow 01

Translation is the whole job.

A sale leaves the point-of-sale in one shape and has to arrive in another. The transformation layer is where the integration earns its keep, because an ERP will reject anything it does not recognise.

Image placeholder The transformation step: a point-of-sale transaction on one side, the reshaped ERP payload on the other, and the field mapping between them. assets/portfolio/business-central/workflow-transform.png · 16 / 11
  • Reshaped, not forwardedSales are transformed into the structure the ERP expects rather than passed through unchanged.
  • One agreed contractThe target endpoint defines the shape, and the service conforms to it rather than negotiating.
  • Continuous, not batched by handSynchronisation runs on its own rather than waiting for someone to export.

04Workflow 02

A pipeline you cannot see is a pipeline you cannot trust.

The framework was chosen partly because watching queues and background work is straightforward in it. That decision is why the business can glance at a screen and know the integration is healthy.

  • Built to be watchedThe framework was chosen because monitoring queues and background processes in it is straightforward.
  • A quick glance is enoughThe interface exists so a business can confirm the service is working without asking an engineer.
  • Failures are visibleA job that does not land is surfaced rather than silently dropped.
Image placeholder The monitoring interface: recent synchronisation activity, queue depth, processed and failed jobs, and the detail of a single transaction’s journey. assets/portfolio/business-central/monitoring.png · 16 / 10
Image placeholder A single synchronisation job: its source transaction, transformed payload and delivery result. assets/portfolio/business-central/job-detail.png · 1 / 2.04

05Engineering behind the product

The system behind a reliable pipeline.

Integrations fail quietly. Most of the design here is about making sure this one cannot.

  • Data transformation layer

    Point-of-sale transactions are reshaped into the structure the ERP requires before delivery.

  • Queue-based processing

    Synchronisation runs as background jobs, so throughput is decoupled from the systems on either side.

  • Framework chosen for observability

    The stack was selected specifically because monitoring queues and background processes in it is straightforward.

  • Operational interface

    A deliberately simple web interface gives the business a view of synchronisation activity.

  • Failure surfacing

    Jobs that do not complete are visible rather than silently lost.

  • Endpoint conformance

    The service conforms to the Business Central API contract, transforming Lightspeed L Series sales into exactly what the endpoint expects.

06Technical architecture

Under the hood

Laravel was chosen specifically because monitoring queues and background processes in it is straightforward, which is what makes the pipeline auditable.

Backend

  • Laravel
  • PHP

Processing

  • Queued background jobs
  • Data transformation layer

Integrates

  • Lightspeed L Series (source)
  • Microsoft Dynamics 365 Business Central API (target)

07Delivery journey

How the integration was delivered.

  1. Requirement

    Define the sync scope and target

  2. Mapping

    Establish the transformation contract

  3. Service build

    Ingestion, transform and delivery

  4. Interface

    Build the monitoring view

  5. Testing

    Validate against the ERP endpoint

  6. Production

    Release into live operation

  7. Support

    Operate and extend

The service is in production. Dates, durations and transaction volumes are withheld until confirmed. Verify before publishing

08What the system enabled

What the delivered integration enabled

  • Point-of-sale transactions delivered into the ERP
  • Data transformed into the structure finance expects
  • Continuous synchronisation without manual export
  • Queue-based processing that absorbs volume
  • A monitoring view the business can read directly
  • Failures surfaced rather than silently dropped

Related systems

Ontex

Operations · SAP Integration · Web

A synchronisation service generating custom SAP iDoc files from retail point-of-sale sales and delivering them for processing.

View case study , Ontex

Integration is where most systems quietly break.

We build pipelines that show their working, so nobody finds out from the month-end numbers.

Discuss your system