IoT-Driven Oil
Replenishment Automation

When operators missed a level check — or a site was simply far down the review queue — tanks ran critically low before an order was placed. Emergency replenishment at remote Australian sites carries a significant cost premium.

To avoid runouts, site managers padded order quantities conservatively — tying up working capital in excess stock and creating storage pressure at smaller tank installations.

Every replenishment order was manually keyed into JD Edwards EnterpriseOne — a repetitive, time-consuming task that added no value and introduced transcription errors that back-office staff had to trace and correct.

The third-party sensors were collecting accurate real-time data, but that data lived in the sensor vendor's platform. There was no centralised view of tank levels across sites, and no alerting when levels crossed thresholds.

Adding new client sites meant adding more monitoring overhead. The only way to grow the distribution network was to grow the operations team — a model that was no longer sustainable.

The third-party sensor API occasionally returned stale readings, missing fields, or temporary errors due to connectivity issues at remote sites. We implemented a polling layer with configurable retry logic, reading validation (range checks, timestamp freshness), and a per-site circuit breaker that flags anomalous readings for manual review rather than triggering false orders.

Threshold evaluation sounds simple until you account for sensor noise — a reading that oscillates around a threshold could trigger multiple orders in a single polling cycle. We built a stateful threshold engine that tracks the last order raised per site, applies a configurable cooldown window, and requires the level to remain below threshold across consecutive readings before triggering. This eliminated duplicate orders entirely.

JD Edwards expects replenishment orders as EDI X12 850 (Purchase Order) files conforming to the client's specific trading partner map — segment ordering, qualifier codes, date formats, and control number sequencing are all part of the contract. We built an EDI generation module that maps the order data to the 850 structure, manages ISA/GS control number sequences with database-backed counters to prevent duplicates across restarts, and validates the generated document against the trading partner spec before dispatch.

Sterling acts as the EDI gateway between our system and JD Edwards — files are deposited into a Sterling-monitored mailbox via SFTP, where Sterling picks them up, processes the trading partner envelope, and routes the 850 into JDE. We built a file-delivery layer with delivery confirmation tracking, retry on SFTP failure, and monitoring for functional acknowledgement (997/999) files returned by Sterling to confirm successful processing by the ERP.

Each client site has different tank capacities, reorder thresholds, order quantities, lead times, and JD Edwards supplier codes. We built a configuration management layer with a site registry stored in PostgreSQL, allowing thresholds and order parameters to be updated without a deployment. Every sensor reading, threshold evaluation, and order dispatch is written to an immutable audit log — giving operations teams a complete, queryable history of every automated decision the system made.

Replenishment purchase orders are now raised, formatted as EDI, and delivered to JD Edwards automatically — no operator involvement, no transcription errors, no delays between the trigger event and the order being in the ERP.

Since go-live, no monitored site has experienced an unplanned runout. Threshold levels are calibrated per site to account for lead times, so orders are placed with enough runway for delivery — including remote locations with longer transport windows.

Order quantities are now calculated from actual consumption data rather than conservative estimates. The reduction in safety padding has meaningfully reduced average stock-on-hand and the working capital tied up across the client network.

Every sensor reading, threshold evaluation, order generation event, and Sterling delivery confirmation is logged to an immutable audit record. Operations and compliance teams can reconstruct the exact sequence that led to any order — down to the millisecond.

Onboarding a new client site requires only a configuration record — sensor ID, threshold, order parameters, JDE supplier code. No deployment, no code change. The distributor can grow their monitored network without any dependency on the development team.