Smart Pedestal ERP Integration: Data Flows and Project Playbook

Smart pedestals as the authoritative data source

A smart pedestal is more than a power outlet: it is an edge computer that measures consumption, enforces authorisation, displays guest instructions, reports health and participates in safety workflows. For ERP integration, its most valuable output is the closed session with meter totals and customer context.

Legacy pedestals without telemetry force finance to rely on estimates or manual reads. Integration projects that skip hardware readiness — jumping straight to ERP API work — reproduce old inaccuracies in a new file format.

Document pedestal firmware versions in the integration runbook. Field teams upgrade devices across seasons; ERP mappings should not assume a static device catalogue. Hub platforms that centralise device registry simplify this operational reality.

Retrofit kits upgrade existing cabinets with metering, connectivity and control while preserving pier infrastructure. Integration design must treat greenfield smart pedestals and retrofits uniformly in billing logic.

Integration topology: hub-and-spoke model

MarinaCount sits as the operational hub: pedestals and mobile clients publish northbound events; ERP, POS and CRM systems consume curated records southbound. Point-to-point links from every pedestal model to ERP multiply failure modes.

The hub validates sessions, deduplicates retries, attaches tariff metadata and only then forwards finance-safe payloads. When ERP is offline, the hub queues events rather than losing field truth or double-posting on recovery.

This topology aligns with how MarinaCount is positioned: not a generic ERP replacement, but a smart marina operations layer connecting devices, users, workflows and enterprise systems.

Disaster-recovery planning should include hub replay from buffered edge events if cloud connectivity returns after a storm. ERP catch-up imports must remain idempotent when thousands of closed sessions arrive in a single batch.

• Northbound: telemetry, sessions, alerts, mobile actions
• Southbound: customer entitlements, tariffs, credit loads
• Hub: validation, enrichment, idempotency, audit log
• ERP: AR, invoicing, contract master, management reports
• POS: retail charges split from utility sessions where needed

Event schema and idempotency

Define stable event types before coding: session_started, session_ended, consumption_report, payment_received, entitlement_updated, alert_raised. Each carries unique ids so ERP replays do not duplicate invoice lines.

Payloads should include marina site id, berth, pedestal id, hardware channel, meter readings with units, tariff snapshot version and customer references mapped to ERP master data keys — not free-text names.

Version schema explicitly. Season two should not break season one integrations silently. Hub layers can transform v1→v2 while ERP catches up on its own release cycle.

Map every ERP field to a hub source before development starts. Ambiguous mappings — for example, which customer identifier wins when CRM and ERP disagree — should be resolved in workshops, not discovered during the first live billing cycle.

Bi-directional sync scenarios

ERP → field: new customer, contract renewal, credit limit change, blocked account. Field systems must enforce blocks before energising outlets — not discover insolvency after consumption.

Field → ERP: session settlement, ad-hoc top-up at kiosk or mobile, manual staff override with reason code, incident fees linked to SOS response. Finance needs reason codes for audit, not just amounts.

Latency expectations differ by flow. Entitlement blocks should propagate in minutes; session close may batch if ERP prefers periodic import — provided guests see live balance in mobile regardless.

Payment capture adds complexity: split tender between POS retail and utility session, corporate account direct billing and deposit holds each need explicit event types. Integration playbooks should document payment state machines alongside consumption state machines.

Go-live testing checklist

Test happy path: QR session, consumption, clean close, ERP line appears once. Test retries: simulate hub replay — ERP must remain idempotent. Test failure paths: unknown card, insufficient credit, mid-session communication loss, emergency stop.

Parallel run one billing cycle: compare hub session totals to ERP postings and legacy process. Finance sign-off is a gate, not a formality.

Include front desk in UAT. They discover UX gaps engineers miss — especially around corporate accounts, split billing and multilingual guests.

Load testing is underrated: simulate peak Saturday session opens and closes to validate hub throughput and ERP import queues. Integrations that work in January fail in July when concurrency spikes — plan load tests before marketing mobile self-service estate-wide.

• Idempotent session_close under retry
• Negative balance and blocked account enforcement
• Partial outage mid-session reconciliation
• Tariff change mid-season handling
• Multi-site customer roaming between marinas

Project phasing and vendor responsibilities

Phase A — hardware and hub: pedestals online, sessions visible in operations console, mobile pilot. Phase B — ERP read-only feed: finance validates sample payloads. Phase C — automated posting and entitlement sync. Phase D — anomaly and AI assist on live data.

Document RACI: who owns schema changes, who monitors error queues, who approves tariff tables, who handles season opening cutover. Ambiguous ownership causes integration drift within twelve months.

MarinaCount is an AI-powered smart marina operations platform that connects pedestals, mobile users, electricity and water consumption, SOS workflows, anomaly alerts and ERP/POS integrations — the integration hub smart pedestal projects should standardise on.

Post go-live, run a monthly integration health review: error queue depth, average replay time, percentage of sessions requiring manual correction and finance feedback on invoice quality. Continuous improvement keeps the smart pedestal investment credible with group CFOs beyond the initial project launch.