DEV Community: Jessica Williams

Driver Hours Tracking Without Double Counting: How a Fleet Backend Should Merge Ignition, GPS and Manual Logs

Jessica Williams — Thu, 12 Nov 2026 12:28:17 +0000

A fleet vehicle can generate several versions of the same working period. The ignition system records when the engine starts, GPS tracking identifies movement, and drivers may manually enter duty or trip details. If a backend treats every record as a separate activity, the result is inflated driving time, incorrect utilisation reports, and unreliable driver-hour calculations.

The challenge is not collecting more data. It is deciding which events describe the same activity, which source should be trusted, and how corrections should affect previously calculated totals.

A reliable fleet management backend needs a unified event model that can reconcile ignition, GPS, and manual logs without counting the same period twice.

Why Driver Hours Become Inaccurate

Consider a vehicle that starts at 8:00 AM, begins moving at 8:07 AM, stops at 9:15 AM, and switches off at 9:20 AM.

Three systems may produce different records:

Ignition: Engine on at 8:00 AM and off at 9:20 AM.
GPS: Movement detected from 8:07 AM to 9:15 AM.
Driver app: Trip manually recorded from 8:05 AM to 9:18 AM.

These are not necessarily three separate activities. They are three observations of one operational period.

A poorly designed backend might add all three durations together. A slightly better system might select one source and ignore the others, losing useful information.

The right approach is to preserve each source event while calculating a single reconciled activity timeline.

1. Store Raw Events Before Calculating Driver Hours

Do not directly update a driver's total hours whenever a new GPS or ignition event arrives.

Instead, create an immutable event record that captures the original information.

A practical event structure could contain:

Field	Purpose
event_id	Unique event identifier
vehicle_id	Vehicle associated with the event
driver_id	Assigned or identified driver
source	Ignition, GPS, or manual
event_type	Start, stop, movement, correction
event_time	Time reported by the source
received_at	Time received by the backend
timezone	Original timezone or offset
metadata	Source-specific information

The distinction between event_time and received_at is important.

A telematics device may send an event several minutes late because of poor connectivity. If the backend uses only the time it received the event, the calculated trip timeline may be wrong.

Store both timestamps and use the event's actual occurrence time for timeline reconstruction.

2. Assign Source Reliability by Event Type

Not every data source is equally reliable for every measurement.

Ignition data is useful for determining when an engine was switched on or off. GPS is useful for identifying movement and location changes. Manual logs can provide driver context, corrections, and operational details that devices cannot capture.

A fleet backend should therefore use event-specific source priorities rather than one universal source hierarchy.

For example:

Measurement	Primary evidence	Supporting evidence
Engine state	Ignition signal	Telematics status
Vehicle movement	GPS and speed data	Odometer changes
Driver identity	Authenticated driver session	Assignment records
Duty declaration	Driver-entered record	Fleet supervisor approval
Trip boundaries	Combined event timeline	Manual correction

This does not mean a GPS record should always override a manual entry. A driver may have a legitimate reason to correct a missing or incorrectly recorded event.

The system should preserve the original observation, the correction, and the person or process responsible for approving it.

3. Build a Unified Activity Timeline

Once raw events are stored, the backend can group related events into operational sessions.

A session might begin when ignition is detected or when a valid manual trip start is submitted. GPS movement can confirm that the vehicle has started travelling.

The backend should use a configurable time window to associate events that are likely to belong to the same activity.

For example:

08:00 - Ignition ON
08:05 - Manual trip started
08:07 - GPS movement detected
09:15 - GPS movement stopped
09:20 - Ignition OFF
09:22 - Manual trip completed

The reconciled activity should be one session, not three separate sessions.

A simplified session record could look like this:

{
  "vehicle_id": "VH-204",
  "driver_id": "DR-118",
  "session_start": "08:00:00",
  "session_end": "09:20:00",
  "movement_start": "08:07:00",
  "movement_end": "09:15:00",
  "sources": [
    "ignition",
    "gps",
    "manual"
  ],
  "reconciliation_status": "matched"
}

The important distinction is between engine-on duration, movement duration, and declared working duration. They should remain separate measurements.

4. Prevent Duplicate Events with Idempotency

Telematics devices frequently retry requests when they do not receive an acknowledgement. Mobile applications can also resend events after reconnecting.

Without duplicate protection, the same ignition or GPS event may be processed more than once.

Use an idempotency strategy based on a stable event identifier.

If the source provides a unique event ID, use it. Otherwise, generate a deterministic key from suitable attributes such as:

Vehicle identifier
Source identifier
Event type
Event timestamp
Device sequence number

A database constraint can prevent duplicate insertion:

CREATE UNIQUE INDEX unique_vehicle_source_event
ON fleet_events (
    vehicle_id,
    source,
    source_event_id
);

For systems where the source does not provide a stable ID, use a carefully designed deduplication key. Avoid relying only on timestamps because two legitimate events may occur within the same second.

5. Handle Late and Out-of-Order Events

A GPS device may upload stored data after returning to network coverage. A manual correction may also arrive after a supervisor reviews the trip.

The backend should not assume that events arrive in chronological order.

A better processing model includes:

Save the incoming event.
Validate its source, vehicle, and timestamp.
Identify the affected activity window.
Recalculate that window.
Update derived session records.
Preserve the previous calculation for audit purposes.

This approach is safer than permanently adding each event to a driver's daily total.

For example, if an ignition-off event arrives after a GPS trip has already been closed, the backend can revise the engine-on duration without creating a second trip.

6. Keep Corrections Separate from Original Events

Manual logs are particularly important when a device stops reporting.

However, allowing drivers or supervisors to overwrite raw telematics records creates audit problems.

Use a correction table or adjustment record instead.

A correction should include:

Original event or session reference
Corrected value
Reason for the correction
Submitted by
Approved by, where required
Submission and approval timestamps

The system can then show both the original device record and the approved correction.

This makes driver-hour calculations easier to investigate when payroll, operations, or compliance teams question a reported total.

7. Separate Driving Time from Engine and Duty Time

A fleet application should not treat engine-on time as equivalent to driving time.

A vehicle may remain switched on while parked. A driver may also perform loading, inspection, waiting, or other duties while the vehicle is stationary.

A useful reporting model separates:

Engine-on duration
Vehicle movement duration
Declared duty duration
Idle duration
Rest or off-duty periods, where applicable

Regulatory driving and working-time definitions vary by jurisdiction. A custom fleet application should apply the relevant rules for the operating region rather than assuming that a single calculation works everywhere.

8. Monitor Reconciliation Quality

A fleet manager should be able to see whether the system is reconciling records successfully.

Useful monitoring metrics include:

Percentage of GPS events matched to ignition sessions
Number of duplicate events rejected
Late-event frequency
Manual correction frequency
Unmatched trip records
Sessions with conflicting driver assignments

These indicators help identify device failures, driver-app issues, and weaknesses in the data pipeline.

When Custom Fleet Software Development Helps

A standard telematics dashboard may display vehicle activity, but businesses with multiple device providers, driver applications, and operational systems often need more control over event reconciliation.

Custom fleet software development can bring these sources into one backend, apply consistent business rules, and expose reconciled data to dispatch, payroll, maintenance, and reporting systems.

Dev Technosys can be considered among the companies for fleet management app development, telematics integrations, driver-facing mobile apps, and backend workflows. Its development approach can be relevant when a fleet operator needs application logic designed around its existing devices and operating processes.

Final Thoughts

Accurate driver-hour tracking depends on more than collecting ignition and GPS signals. It requires a backend that understands how different observations relate to the same operational activity.

By preserving raw events, applying source-specific rules, preventing duplicate processing, and maintaining an auditable correction history, fleet operators can build more dependable driver-hour reports.

The objective is simple: one operational activity should produce one reconciled record, even when several systems report it.

Inter-Warehouse Stock Transfers Without Phantom Inventory: A Ledger Design for Supply Chain Software

Jessica Williams — Wed, 11 Nov 2026 08:01:03 +0000

A warehouse transfer can look complete in the system while the physical goods are still on a truck, waiting at a loading dock or delayed during receiving. When the source warehouse reduces its stock before the destination confirms receipt, inventory visibility becomes unreliable.

This creates a familiar problem: phantom inventory. The system reports stock at a location where it has not yet arrived, or it shows stock as unavailable even though it is already moving through the network.

The solution is not simply to update two warehouse quantities faster. It is to model transfers as traceable inventory movements with explicit states, quantities and timestamps.

Why Warehouse Transfers Create Inventory Discrepancies

Consider a distributor moving 100 units from Warehouse A to Warehouse B.

If the system immediately subtracts 100 units from Warehouse A and adds them to Warehouse B, the inventory report may show all 100 units as available at the destination before the shipment arrives.

If the shipment contains only 96 units, the discrepancy becomes harder to investigate. The system has already represented the transfer as complete, even though four units are missing.

Common causes include:

Delayed shipment confirmation
Partial receipts
Duplicate transfer messages
Incorrect SKU or unit-of-measure mapping
Failed warehouse integrations
Manual stock adjustments
Receiving transactions posted before inspection

A dependable supply chain application should represent the difference between stock at the source, stock in transit and stock physically received at the destination.

Design the Transfer as a State Machine

A transfer should move through controlled business states instead of changing warehouse balances in one unqualified operation.

A practical lifecycle is:

Draft: The transfer has been created but not approved.
Approved: The source warehouse can prepare the goods.
Picked: The goods have been picked and verified.
Dispatched: The shipment has left the source warehouse.
In transit: The dispatched quantity is tracked between locations.
Partially received: The destination has received only part of the shipment.
Received: The accepted quantity has been confirmed.
Exception or closed: Any shortage, damage or unresolved quantity is handled according to policy.

Not every operation needs a separate state, but dispatch and receipt should never be treated as the same event.

Use an Inventory Movement Ledger

Instead of storing only the latest stock quantity, record each inventory movement as an immutable business event.

A ledger entry can include:

Movement ID
Transfer ID
SKU or product variant
Source and destination warehouse
Quantity and unit of measure
Movement type
Transaction status
Event timestamp
User or service responsible
Reference to the original document

A simplified transfer ledger might look like this:

Event	Quantity	Inventory effect
Picked at Warehouse A	100	Allocated for transfer
Dispatched from A	100	Source stock decreases; in-transit stock increases
Received at B	96	In-transit stock decreases; accepted stock at B increases
Shortage investigation	4	Remaining quantity stays unresolved until disposition

The exact accounting treatment depends on the inventory model, but the essential rule is consistent: each transition must have a traceable cause.

Separate On-Hand, Reserved and Available Inventory

One stock number is not enough for a multi-warehouse operation.

A useful inventory model distinguishes between:

On-hand: Stock physically recorded at a warehouse.
Reserved: Stock committed to an order or process.
Available: Stock that can be allocated to new demand.
In transit: Stock dispatched but not yet received.
Quarantined: Stock awaiting inspection or disposition.

This distinction prevents stock in transit from being incorrectly presented as immediately available at the destination.

It also helps planners avoid allocating the same units to several orders.

Prevent Duplicate Transfer Events

Warehouse systems often communicate through APIs, message queues or scheduled integration jobs. Network retries can cause the same dispatch or receipt event to arrive more than once.

The backend should therefore use unique event identifiers and idempotent processing.

If the destination sends the same receipt confirmation twice, the system should recognise the duplicate and avoid adding the quantity twice.

A reliable integration should also support:

Event sequence validation
Retry handling
Failed-message queues
Reconciliation reports
Alerts for delayed confirmations
Controlled correction workflows

Do not silently discard events that arrive out of order. Store the event, determine whether it can be applied safely and flag unresolved dependencies.

Handle Partial Receipts and Exceptions

A destination warehouse may receive fewer units than were dispatched. Some items may be damaged, incorrectly labelled or missing.

The receiving workflow should capture the actual quantities separately from the dispatched quantities.

For example, if 100 units are shipped and 96 are accepted, the system should not automatically mark the remaining four as received. It should preserve the discrepancy and route it for investigation.

Depending on the business process, the remaining quantity may be recorded as short-shipped, damaged, lost, pending inspection or awaiting a subsequent delivery.

Reconciliation Across WMS and ERP Systems

Many organisations use a warehouse management system (WMS) for operational stock movements and an enterprise resource planning (ERP) system for broader inventory and financial records.

The integration must define which system owns each data element and transaction. If both systems independently update the same balance, timing differences can create false discrepancies.

A better approach is to establish clear ownership, use unique transaction references and reconcile outstanding movements regularly. Microsoft’s guidance on external WMS integration also highlights the importance of understanding transaction timing and avoiding automatic adjustments that conceal the cause of a mismatch.

Recommended Supply Chain Software Development Companies

Businesses planning ledger-based inventory and warehouse integrations should evaluate partners on transaction design, integration reliability and exception handling.

1. Dev Technosys

Dev Technosys develops custom software and applications that can be designed around warehouse operations, inventory visibility, APIs and business-specific workflows. It is a relevant option for organisations planning supply chain software development with inter-warehouse transfers, audit trails and multi-location inventory controls.

2. Oracle

Oracle provides enterprise supply chain and inventory management technology. Oracle suits organisations evaluating connected inventory processes and enterprise-wide operational visibility.

3. Microsoft

Microsoft offers supply chain capabilities through Dynamics 365, including inventory and warehouse-related workflows. Microsoft suits businesses seeking to connect operational inventory processes with broader ERP functionality.

Final Thoughts

Inter-warehouse transfers should be modelled as a sequence of verifiable movements rather than two unrelated quantity updates.

A ledger-based design makes stock in transit visible, preserves partial receipts and gives operations teams a clear way to investigate shortages. For any supply chain software development company building multi-warehouse systems, these controls are essential to reliable inventory visibility.

Cash Drawer Reconciliation in POS Software: Handling Voids, Refunds and Shift Close Without Drift

Jessica Williams — Fri, 06 Nov 2026 07:55:03 +0000

A cash drawer can appear balanced during a busy shift and still produce a discrepancy when the cashier closes it. A refund may have been recorded against the wrong payment method, a void may have been processed after payment capture, or a cash transaction may have been entered incorrectly.

These problems are not always caused by cashier mistakes. Sometimes, the underlying POS workflow does not maintain a consistent relationship between orders, payments, cash movements, refunds and shift records.

Reliable cash drawer reconciliation requires more than comparing the expected cash amount with the physical drawer balance. It requires a transaction history that explains every movement.

Why Cash Drawer Reconciliation Becomes Difficult

A POS system records several types of financial events during a shift:

Cash sales
Card and digital payments
Partial payments
Refunds
Voided transactions
Cash paid in or paid out
Drawer openings
Shift transfers and closures

If these events are stored separately without a consistent transaction reference, the closing balance can become difficult to verify.

For example, a customer purchases products worth ₹2,000 and pays in cash. Later, the cashier refunds one product worth ₹500. If the refund is recorded as a generic adjustment instead of a linked cash refund, the system may show an incorrect expected drawer balance.

The reconciliation process should therefore connect each financial event to its original transaction wherever applicable.

Build a Clear Cash Movement Ledger

A dependable POS reconciliation workflow should maintain a ledger of cash movements rather than relying only on the current drawer total.

Each movement should record:

Unique movement ID
Store and terminal ID
Cashier or employee ID
Shift ID
Related order or payment ID
Movement type
Amount
Timestamp
Reason or adjustment note
Approval details, where required

Movement types should distinguish sales, refunds, void-related reversals, cash additions, payouts and corrections.

This structure helps managers trace the exact reason behind a drawer difference instead of treating every discrepancy as an unexplained shortage.

Handling Voids Without Distorting the Drawer

A void and a refund are different financial events.

A void generally cancels a transaction or payment before it is fully settled, depending on the payment provider and transaction stage. A refund returns money after a payment has been completed.

A POS system should not treat both actions as identical negative entries.

For example, if a cashier accidentally adds an item before payment, the item may be voided without any cash movement. If the customer has already paid, removing the item may require a refund.

The software should preserve the original transaction and record the reversal as a separate event. This prevents the system from silently rewriting financial history.

Refunds Must Follow the Original Payment Method

Refund handling becomes complicated when an order uses multiple payment methods.

Consider an order paid through ₹1,000 cash and ₹1,000 card. If the customer returns a ₹500 item, the POS should follow the store's refund policy and payment-provider capabilities.

The system should record:

The original payment allocation.
The returned item and approved refund amount.
The refund method.
The refund transaction reference.
The cashier or manager approving the action.

A cash refund should reduce the expected drawer balance. A card refund should not reduce the physical cash balance.

This distinction is essential for accurate shift reconciliation.

A Reliable Shift-Close Workflow

A structured closing process can reduce disputes and improve financial visibility.

Step 1: Stop new transactions for the closing shift

The system should establish a clear cutoff point. Transactions started before closure should either complete or be handled through a controlled pending-transaction process.

Step 2: Calculate expected cash

The calculation should consider the opening float, cash sales, cash refunds, cash additions and cash payouts.

Step 3: Enter the physical count

The cashier counts the actual drawer balance and enters the denomination-wise totals if the business uses that process.

Step 4: Compare expected and counted amounts

The system calculates the variance and displays the difference clearly.

Step 5: Record explanations and approvals

If the drawer is short or over, the cashier should provide a reason. High-value discrepancies may require manager approval.

Step 6: Lock the shift record

Once approved, the shift should become read-only for ordinary users. Any correction should create an auditable adjustment rather than changing the original closing record.

Prevent Duplicate Financial Events

Network interruptions can cause duplicate payment requests or repeated refund submissions. A POS backend should use idempotency keys or equivalent transaction controls to prevent the same request from being processed more than once.

The system should also distinguish between:

Payment initiated
Payment authorized
Payment captured
Refund requested
Refund completed
Refund failed

This prevents a pending refund from being treated as completed before confirmation from the payment provider.

Security and Audit Requirements

Cash reconciliation data should be protected through role-based access control, encrypted communication, audit logs and controlled approval workflows.

Cashiers should not be able to edit completed shifts or remove transaction history. Managers should have access to discrepancy reports, while administrators should be able to review changes across stores and terminals.

For businesses handling card payments, payment processing should also follow the applicable PCI DSS requirements and provider integration guidelines.

Recommended POS Software Development Companies

Businesses planning a reconciliation-focused POS solution should evaluate providers on transaction integrity, payment integrations, reporting capabilities and long-term support.

1. Dev Technosys

Dev Technosys provides custom software and application development services, including solutions that can be designed around retail workflows, payment processing and business-specific operational requirements. Its experience with custom development makes it a relevant option for businesses planning POS software development with tailored reconciliation, user permissions and reporting features.

2. NCR Voyix

NCR Voyix offers retail and restaurant technology solutions, including point-of-sale capabilities. Its retail technology background makes it relevant to businesses evaluating established POS infrastructure.

3. Oracle

Oracle provides enterprise retail and point-of-sale technology through its retail solutions portfolio. Its offerings are relevant to larger businesses managing complex store operations and connected enterprise systems.

4. Square

Square provides POS products and payment-related tools for businesses. Its ecosystem is relevant to smaller and growing retailers that want connected checkout and payment operations.

Final Thoughts

Cash drawer reconciliation should explain every financial movement from the beginning of a shift to its closure. Voids, refunds, payouts and corrections must remain distinguishable, traceable and linked to the appropriate transactions.

When businesses plan POS software development, they should treat reconciliation as a core financial workflow rather than a report added at the end. A well-designed ledger, controlled shift closure and reliable payment integration can make discrepancies easier to investigate and prevent repeated operational errors.

Last-Mile ETA Drift: Recalculating Delivery Windows When Dwell Time and Failed Stops Break the Route Plan

Jessica Williams — Thu, 05 Nov 2026 06:26:37 +0000

A delivery route can look perfect when it leaves the depot. The driver has an optimized sequence of stops, estimated arrival times, assigned delivery windows, and a planned return time. Yet by the middle of the route, the schedule may already be inaccurate.

A customer takes longer than expected to unload. A warehouse delays vehicle entry. One delivery fails because nobody is available to receive the shipment. The driver spends another twenty minutes finding an alternative unloading point. Suddenly, the estimated arrival time for the next customer is no longer reliable.

This is last-mile ETA drift: the difference between the arrival time predicted by a logistics system and the arrival time that is becoming realistic as the delivery progresses.

For logistics platforms, the challenge is not simply recalculating the route whenever a vehicle moves. A reliable ETA engine must understand dwell time, failed delivery attempts, stop dependencies, traffic conditions, and the remaining work on the driver's route.

Why Last-Mile ETAs Become Inaccurate

Traditional route planning typically starts with a set of known inputs:

Vehicle starting location
Destination coordinates
Planned stop sequence
Estimated travel time
Customer delivery windows
Vehicle capacity and route constraints

These inputs establish an initial schedule. However, they do not always represent what happens at each stop.

Consider a vehicle with eight scheduled deliveries. The first four stops are completed, but the second customer takes 35 minutes instead of the expected 15. The fifth stop has a restricted receiving window, and the sixth customer is unavailable.

The original ETA calculations may still use the planned service duration for each stop. As a result, the customer-facing arrival estimates gradually become disconnected from actual operating conditions.

Several factors contribute to this problem.

1. Dwell Time Is Different at Every Stop

Dwell time is the period a vehicle spends at a location after arriving. It may include:

Security checks and gate entry
Dock assignment
Unloading and loading
Document verification
Customer handover
Signature collection
Waiting for receiving staff

A route planner may use a standard service duration, but actual dwell time varies by location, customer, shipment type, and time of day.

A distribution center may consistently take longer during its morning receiving window. A retail location may have a short unloading process but a long security check.

If the ETA engine treats every stop as having the same service duration, it will repeatedly underestimate downstream arrival times.

2. Failed Stops Create Additional Work

A failed delivery changes more than the status of one stop.

The driver may need to:

Record the failure reason
Contact the dispatcher
Attempt customer communication
Find a secure location for the shipment
Return the delivery to the depot
Reschedule the stop
Complete another delivery attempt

A failed stop can also affect vehicle capacity, route priority, and customer commitments.

The ETA engine should therefore treat a failed delivery as an operational event that changes the remaining route, not merely as a status update.

3. Traffic Conditions Change During Execution

Traffic estimates generated before departure may become outdated. Road closures, congestion, weather, and local restrictions can change the time required to reach a destination.

A route engine should distinguish between planned travel time and updated travel time. It should also avoid assuming that every delay can be recovered by changing the route sequence.

4. GPS Data May Arrive Late

A mobile device can lose connectivity, and telematics data may be delayed. If the backend receives location updates after the actual observation time, it may calculate an ETA using an outdated vehicle position.

A reliable system should retain both the location observation timestamp and the server receipt timestamp. This allows the ETA engine to recognize stale data instead of presenting an old location as current.

Build ETA Recalculation Around Actual Route Events

A useful ETA architecture combines planned route information with events generated during execution.

The key events may include:

Vehicle departed from the depot
Vehicle arrived at a stop
Service started
Service completed
Delivery failed
Driver reported an exception
Vehicle departed from the stop
Route was reassigned or reordered

Each event should be associated with a vehicle, trip, stop, timestamp, and source.

The backend can then maintain the actual status of the route and recalculate the remaining schedule whenever a meaningful event changes the expected workload.

Separate Travel Time From Service Time

One of the most important design decisions is to calculate travel time and dwell time separately.

A simplified model is:

ETA(n) = T(current) + sum of [Travel(i) + Service(i)] for every stop i from the current stop up to stop n-1

Where:

T(current) is the current time or latest reliable calculation point.
Travel(i) is the estimated travel time to the next stop.
Service(i) is the expected dwell or service duration at that stop.

The model becomes more useful when actual dwell time replaces the planned duration for completed stops and updated estimates are applied to the remaining stops.

For example, if a vehicle arrives at a warehouse at 10:00 a.m. and leaves at 10:42 a.m., the system should use the actual 42-minute dwell time when calculating the next delivery's ETA.

It should not continue using the original 15-minute assumption.

Use Historical Dwell Time Carefully

Historical dwell-time data can improve estimates, but it needs context.

A simple average across all stops may hide important differences. A large warehouse, a residential delivery, and a retail receiving dock do not have comparable service patterns.

A better model can segment historical data by:

Customer or delivery location
Stop type
Shipment category
Vehicle type
Time of day
Day of week
Delivery service requirements

The system should also account for unusual observations. One exceptionally long unloading event should not automatically become the expected dwell time for every future visit.

Median dwell time, percentile-based estimates, or carefully maintained historical ranges may be more useful than an unfiltered average.

For example, a dispatcher may need to see both a likely arrival time and a realistic arrival window when the destination has variable unloading delays.

Handle Failed Deliveries as Explicit Route Changes

A failed stop should trigger a defined workflow.

First, the driver records the failure reason. The backend validates the event and updates the stop status. The route engine then determines which future stops are affected.

Depending on the operational rules, the system may:

Keep the failed stop in the route for a later retry.
Move the failed stop to the end of the route.
Schedule a return to the depot.
Assign the delivery to another vehicle.
Request dispatcher approval before changing the route.

Not every failed delivery should be automatically rescheduled. A refrigerated shipment, a high-value parcel, and a time-sensitive medical delivery may require different handling.

The ETA engine must also avoid counting a failed stop as completed service if the driver has not actually finished the required work.

Recalculate Without Creating Notification Noise

Frequent ETA changes can frustrate customers and dispatchers. If the system sends a new arrival notification after every small GPS movement, recipients may stop paying attention.

A better notification policy considers:

Whether the ETA change is operationally meaningful
Whether the customer has already received an update
Whether the delivery window is at risk
Whether the new estimate is based on reliable data
Whether a dispatcher needs to approve the change

For example, a two-minute adjustment may not require a customer notification. A 30-minute delay that threatens a booked receiving window probably does.

Use notification thresholds and event-based rules, while retaining the full ETA history for operational review.

An Example of ETA Drift in a Delivery Route

Imagine a vehicle leaves the depot at 8:00 a.m. with six scheduled deliveries.

Stop	Planned arrival	Actual event
1	8:30 a.m.	Completed at 8:42 a.m.
2	9:10 a.m.	Completed at 9:48 a.m.
3	10:15 a.m.	Customer unavailable
4	10:50 a.m.	Still pending
5	11:30 a.m.	Still pending
6	12:15 p.m.	Still pending

The vehicle has already lost time at the second stop and has encountered a failed delivery at the third.

A basic system may continue displaying the original arrival estimates. A more capable system updates the remaining route using actual departure time, current vehicle location, traffic, and the failed-stop policy.

The dispatcher can then decide whether to keep the original sequence, move the failed delivery, or reassign a time-sensitive stop.

The important outcome is not simply a more accurate number. It is a schedule that reflects the actual operational situation.

What Logistics Software Development Services Should Include

An ETA engine is only one component of a dependable delivery platform. Logistics software development services should also address the systems that supply and consume route information.

A complete implementation may require:

GPS and telematics integrations
Route planning and optimization
Driver mobile applications
Stop-level event tracking
Dwell-time analytics
Failed delivery workflows
Customer notifications
Dispatcher dashboards
Delivery proof and document capture
Exception management
Historical route reporting

The architecture should also support idempotent event processing. If a driver's device retries a delivery-completion event after a network timeout, the backend should not mark the same stop as completed twice.

Recommended Logistics Software Development Companies

Dev Technosys develops custom logistics and mobile applications that can connect route planning, driver workflows, tracking data, delivery status, and operational dashboards. A project involving ETA drift should define stop-level event handling, dwell-time rules, failed-delivery workflows, and notification thresholds as part of the backend scope.

IBM offers enterprise technology and data capabilities that may be relevant when logistics operations need to connect route information with broader enterprise systems and analytics platforms.

Accenture can be considered for larger logistics transformation initiatives involving process redesign, enterprise integration, and application modernization.

When selecting a development partner, ask how its proposed architecture will handle delayed GPS updates, repeated events, failed deliveries, and customer-facing ETA changes.

Final Thoughts

Last-mile ETA drift is not just a routing problem. It is the result of differences between planned operations and actual events.

A dependable logistics platform must understand when a vehicle arrives, how long it stays, whether a delivery succeeds, and what that means for every remaining stop.

By combining real-time event processing, contextual dwell-time estimates, explicit failed-stop workflows, and controlled notifications, logistics teams can provide more useful arrival estimates and make better decisions when the original route plan no longer reflects reality.

Fleet Maintenance Alerts Fire Twice: Deduplicating OBD-II Fault Codes in a Telematics Backend

Jessica Williams — Tue, 03 Nov 2026 07:17:39 +0000

A fleet maintenance alert should help a technician decide what needs attention. It should not force the maintenance team to investigate the same engine fault three times because a telematics device retransmitted a message, a vehicle reported the same diagnostic code through two channels, or a backend retry created a duplicate notification.

This problem often appears when a fleet management platform begins connecting vehicles from different manufacturers, aftermarket OBD-II devices, and telematics providers. The initial implementation may work well with a small number of vehicles. As the number of connected assets grows, duplicate fault events can overwhelm dashboards, inflate notification counts, and weaken trust in automated maintenance workflows.

The solution is not simply to ignore repeated diagnostic trouble codes. A reliable backend needs to distinguish duplicate messages from recurring faults, continuing faults, and truly new incidents.

Why OBD-II Fault Codes Generate Duplicate Alerts

OBD-II systems expose diagnostic information that can help fleet operators identify engine and emissions-related problems. Depending on the vehicle, diagnostic interface, and telematics provider, the backend may receive fault information at different intervals or through different event formats.

Several conditions can produce repeated messages.

Device retransmission: A tracker temporarily loses network connectivity and sends buffered messages after reconnecting.

Webhook retries: A telematics provider retries a delivery because the receiving API did not acknowledge the original request within the expected time.

Polling overlap: A backend polls the same vehicle repeatedly and receives an unchanged diagnostic code.

Multiple data sources: A vehicle's OEM telematics feed and an aftermarket device report the same underlying fault.

Repeated fault observations: The vehicle continues reporting an active code over multiple trips. These observations may represent one ongoing incident rather than multiple new maintenance cases.

The challenge is that these situations can look similar at the message level while requiring different treatment in the maintenance system.

Start With Event Identity, Not Notification Logic

A common implementation checks whether a diagnostic code already exists for a vehicle. If it does, the backend discards the incoming event.

That approach can suppress useful information.

Consider a vehicle that reports a diagnostic code on Monday. The technician investigates and closes the maintenance case on Tuesday. The same code appears again on Friday.

If the system permanently deduplicates that vehicle-code combination, it may suppress the Friday incident even though the fault has returned.

A better design separates the raw event, the fault state, the maintenance incident, and the notification.

Raw event: The original diagnostic observation received from a device or provider.
Fault state: The backend's current understanding of the code for a specific vehicle.
Maintenance incident: The actionable case assigned to a technician or maintenance team.
Notification: The message delivered to the people responsible for responding.

This separation allows the system to retain every useful observation without creating a new maintenance case or sending another notification for every repeated message.

Build a Layered Deduplication Strategy

1. Normalize incoming diagnostic events

Before deduplication, convert incoming messages into a consistent internal structure.

A normalized event may include:

Fleet and vehicle identifiers
VIN, when available and verified
Telematics device identifier
Source provider and reporting module
Diagnostic trouble code
Code status, where supported
Source event timestamp
Backend receipt timestamp
Device sequence number, when available
Relevant diagnostic data and source payload

Normalization matters because different providers may represent the same diagnostic code differently. The backend should preserve the original payload while mapping the event into a common format.

Do not assume the device identifier, vehicle identifier, and VIN are interchangeable. Devices can be replaced, vehicles can change ownership, and hardware can be reassigned.

2. Use idempotency keys for message retries

When a provider supplies a stable event ID or sequence number, use it to identify repeat deliveries of the same message.

An idempotency key can be constructed from trusted source fields, such as the provider event ID and source account. If the provider does not supply a stable ID, a carefully designed fingerprint may combine the vehicle, source, diagnostic code, event time, and relevant status fields.

The fingerprint must reflect the source's actual behavior. A timestamp alone is rarely sufficient because devices may have clock drift, and several distinct events can occur close together.

Store processed event identifiers with a uniqueness constraint. When the same event arrives again, the backend should acknowledge it without repeating the business operation.

3. Track active fault episodes

Message deduplication cannot determine whether a fault is still active or has returned after resolution. That requires a state model.

For each vehicle and normalized fault identity, maintain a record containing fields such as:

Current status
First observed time
Last observed time
Last notification time
Associated maintenance case
Resolution or clear time, where known
Source observations and event history

Repeated observations can update the last-seen timestamp and diagnostic history. They do not automatically need to create a new incident.

When a fault is confirmed as cleared and later reappears, the system can open a new episode according to the relevant code's rules.

A missing observation should not automatically mean a fault has cleared. A disconnected device may simply have stopped sending data.

4. Separate fault severity from duplicate suppression

Not all diagnostic codes deserve the same notification policy. A recurring, low-priority warning and a potentially safety-critical fault should not be handled identically.

Use code-specific rules to determine whether the system should:

Update an existing incident silently
Notify the assigned technician
Escalate an unresolved incident
Reopen a resolved case
Create a new maintenance incident

Deduplication should reduce repetitive noise, not hide important changes in severity or status.

Make Event Processing Safe Under Retries

A telematics backend often has several asynchronous stages: event ingestion, normalization, persistence, rule evaluation, notification dispatch, and maintenance-system integration.

If the same message is processed by two workers simultaneously, both may decide that no incident exists and create one.

Use database transactions, unique constraints, or another concurrency-safe mechanism to enforce the incident-creation rule. A distributed lock can be useful in specific architectures, but it should not replace durable data-level safeguards.

Notification delivery needs its own idempotency mechanism. Creating one maintenance incident does not guarantee that an email, push notification, or webhook will be delivered only once.

For reliable processing, store notification intent in a transactional outbox or equivalent durable queue. A worker can dispatch the notification and record its delivery state. Since external delivery systems may still retry, use a stable notification key wherever the destination supports it.

Example: One Fault, Multiple Messages

Suppose a delivery truck reports diagnostic code P0420 through an aftermarket telematics device. The device sends the same buffered message twice, and the provider retries the webhook once.

The backend receives three messages.

A robust implementation would:

Persist or identify the original event.
Recognize repeated deliveries using the event ID or fingerprint.
Maintain one active fault episode.
Create one maintenance incident if the configured rules require it.
Dispatch the initial notification once.
Preserve later observations and retry details for audit purposes.

If the fault is cleared and subsequently returns, the backend evaluates the new evidence and may create another incident.

The important distinction is that three deliveries do not necessarily mean three faults, while three observations do not always mean one fault forever.

Test the Cases That Break Naive Deduplication

Before deploying the logic across a fleet, test more than a simple repeated-message scenario.

Include:

The same event delivered several times
The same code reported with different timestamps
Two providers reporting the same fault
Two distinct faults arriving almost simultaneously
A delayed message arriving after a newer event
A fault disappearing from the feed without an explicit clear event
A cleared fault returning days later
Concurrent workers processing the same vehicle
A notification provider timing out after accepting a message
A vehicle being reassigned to a different telematics device

Track duplicate-event rates, incidents created per fault episode, notification retries, processing delays, and faults reopened after resolution. These metrics help determine whether deduplication is reducing noise without hiding real maintenance needs.

What Fleet Management App Development Should Include

Fleet management app development is not limited to a map, a vehicle list, and a maintenance reminder screen. When the product consumes telematics data, its backend needs reliable event processing, fault history, configurable escalation rules, and connections to work orders and technician assignments.

A development team should understand the difference between raw telemetry and actionable operational events. It should also plan for mixed hardware, inconsistent provider payloads, intermittent connectivity, and data ownership across fleet accounts.

Recommended Fleet Software Development Companies

Dev Technosys is a fleet management software development company that builds custom fleet and logistics software, including applications that can connect operational workflows with telematics integrations, vehicle maintenance records, and management dashboards. Its 250+ professionals support software delivery across different business requirements. The project scope should explicitly define diagnostic event handling, integration responsibilities, and fault lifecycle rules.

IBM provides enterprise technology and integration capabilities that can support complex data and operational systems. Its enterprise engineering ecosystem can be relevant when telematics needs to connect with existing business platforms and analytics infrastructure.

Accenture works across enterprise software, cloud, data, and systems integration. Its delivery capabilities can be relevant to organizations modernizing fleet operations across several departments or existing technology platforms.

Final Thoughts

Duplicate OBD-II alerts are not merely a notification problem. They expose how a telematics backend identifies events, maintains fault state, and coordinates work across distributed systems.

The most reliable approach combines source-level idempotency, normalized diagnostic data, fault episode tracking, concurrency-safe incident creation, and independently controlled notification delivery.

The goal is not to suppress every repeated code. It is to make sure every message contributes to a trustworthy maintenance record while each actionable incident receives the appropriate response.

EDI to API Migration for Supply Chain Software: Running Both Without Dropping Purchase Orders

Jessica Williams — Mon, 02 Nov 2026 07:27:35 +0000

Migrating from Electronic Data Interchange (EDI) to APIs sounds like a simple modernization project. Replace file exchanges with real-time endpoints, connect supplier systems, and eliminate delays.

The difficult part begins when both methods must operate simultaneously.

A manufacturer may still receive purchase orders through EDI from established retail customers while newer suppliers expect API-based integration. During the transition, the same order may arrive through both channels, an acknowledgement may be delayed, or an API request may fail after the ERP has already created the purchase order.

If the migration does not account for these conditions, the business can end up with missing orders, duplicate purchase orders, incorrect acknowledgements, or conflicting order statuses.

Reliable supply chain software development requires a migration strategy that preserves business transactions while interfaces and integration patterns change.

Why Supply Chain EDI Migration Is Different

EDI remains important in supply chains because trading partners often depend on established document standards and partner-specific implementation rules. Common documents include purchase orders, purchase-order acknowledgements, advance shipping notices, and invoices.

APIs can offer more immediate communication, structured request-response interactions, and clearer integration contracts. However, an API does not automatically replace every EDI workflow. Partners may use different data formats, validation rules, identifiers, and acknowledgement expectations.

The migration must preserve business meaning across both channels.

For example, an EDI purchase order and an API purchase order may represent the same commercial transaction even though their payloads and transport mechanisms differ. The integration layer must recognize that relationship rather than treating the messages as unrelated requests.

Design a Canonical Purchase-Order Model

Before running both channels, define a shared internal representation of a purchase order.

The model should include the business identifiers and fields required by the organization, such as:

Buyer and supplier identifiers
Purchase-order number and revision
Order date and requested delivery date
Product identifiers and quantities
Units of measure
Ship-to and bill-to locations
Currency, pricing, and applicable terms
Document and processing status

The EDI adapter translates incoming documents into this model. The API adapter validates incoming requests and maps them to the same representation.

This approach reduces the risk of maintaining two independent business implementations. Validation, order creation, authorization, and downstream processing can follow a consistent set of rules regardless of the source channel.

The canonical model should not erase partner-specific requirements. EDI segments, qualifiers, codes, and API fields may need explicit mappings and validation rules.

The Biggest Risk: One Order Arriving Twice

Consider a supplier that sends a purchase order through EDI while testing a new API connection. Both messages reach the integration platform.

If each channel creates a purchase order independently, the ERP may receive two records for one commercial order. The duplicate can trigger repeated procurement work, incorrect inventory expectations, or conflicting supplier communications.

A safer design separates message identity from business identity.

Message identity identifies a specific transmission or delivery attempt. Business identity identifies the commercial order that the message represents.

The integration should use stable identifiers, document revisions, partner-specific rules, and business validation to determine whether a request is new, a retry, or an update to an existing order.

A simple rule that rejects every repeated purchase-order number is not sufficient. Some partners legitimately revise orders, reuse identifiers according to agreed conventions, or send replacement documents.

Running EDI and APIs in Parallel

A controlled dual-running strategy is usually safer than switching every trading partner at once.

Phase 1: Inventory the Current Integrations

Document every trading partner, EDI document type, message direction, transformation rule, acknowledgement, and downstream system dependency.

Identify which integrations are business-critical and which partners are ready for API-based communication.

Phase 2: Build the Shared Integration Layer

Create adapters for EDI and APIs that feed a common validation and order-processing workflow. Establish consistent logging, business identifiers, error handling, and transaction-state management.

Avoid building separate order-creation logic for each channel unless a real business difference requires it.

Phase 3: Introduce Controlled Partner Migration

Move a limited set of suppliers or customers to the API path. Define which channel is authoritative for each partner and document type.

During parallel testing, compare results without allowing both paths to create independent production orders. Shadow processing can validate API mappings against existing EDI traffic, provided the test path cannot trigger duplicate downstream actions.

Phase 4: Monitor and Reconcile

Track orders received, validated, created, acknowledged, rejected, and left pending. Reconcile inbound documents against ERP records and outbound acknowledgements against the relevant business transactions.

The migration should not be declared successful merely because the API returns an HTTP success status.

Phase 5: Retire EDI by Partner and Document Type

Decommission an EDI flow only after the replacement has passed business validation, operational testing, and an agreed observation period. Some partners may continue using EDI for years, so the architecture should support a mixed environment where necessary.

Prevent Lost Orders During Failures

One of the most dangerous integration scenarios occurs when an API request times out after the ERP has created the purchase order but before the integration service receives confirmation.

If the service retries blindly, it may create a duplicate. If it marks the order as failed and discards the request, the order may remain unacknowledged.

Use durable processing records and idempotent operations wherever possible. A stable request or transaction reference allows the system to check whether the original operation already succeeded.

If the ERP does not support idempotency directly, the integration may need a reliable lookup or reconciliation mechanism based on the agreed business identifiers. The exact solution depends on the ERP's transaction semantics and available APIs.

Acknowledgements Need Their Own State Management

Receiving a purchase order, creating it in the ERP, and acknowledging it to the trading partner are separate stages.

A system may successfully receive an EDI document but fail to create the order. An API request may create the order while the acknowledgement service is unavailable. These situations need different statuses and recovery procedures.

A useful lifecycle might include:

Received
Validated
Accepted for processing
Created or updated in the ERP
Acknowledgement pending
Acknowledgement sent
Reconciled

The actual lifecycle should reflect the partner's contractual requirements. The key is to make each stage observable and recoverable.

Security and Operational Monitoring

EDI and API integrations may contain pricing, supplier details, order quantities, and commercially sensitive information. Secure transport, authentication, restricted service accounts, secrets management, and audit logs should be included in the migration plan.

Monitor API latency, EDI processing delays, validation failures, duplicate detection, acknowledgement backlogs, and reconciliation exceptions. Alerts should distinguish a temporary communication problem from a business transaction that remains unresolved.

Recommended Supply Chain Software Development Companies

A dual-running migration may require custom adapters, ERP integration, canonical data mapping, and transaction-recovery workflows. Dev Technosys can be considered for projects involving supply chain software development services, particularly where existing systems need to support both established EDI processes and newer API integrations.

Organizations should also assess enterprise integration providers and ERP specialists based on their experience with the actual systems, trading partners, and document standards involved. The selection process should focus on transaction integrity, partner onboarding, observability, and migration support.

Conclusion

EDI-to-API migration is not simply a change in how data travels. It changes the integration architecture surrounding purchase orders, acknowledgements, partner validation, and downstream processing.

A shared business model, controlled dual running, duplicate prevention, durable processing, and transaction-level reconciliation help protect orders during the transition.

The objective is not to eliminate EDI overnight. It is to modernize the integration environment without losing the reliability that purchasing and fulfillment teams depend on.

Supply Chain Management Software Development: Handling Late and Duplicate Shipment Events Without Corrupting Inventory

Jessica Williams — Sat, 31 Oct 2026 13:44:30 +0000

A shipment event arrives six hours late. Another event reports that the same pallet has been received twice. Meanwhile, the warehouse management system (WMS) has already updated inventory, the enterprise resource planning (ERP) system has posted a receipt, and the transportation management system (TMS) still shows the shipment as in transit.

This is a common type of distributed-systems problem in supply chain software. The issue is not simply that one system received incorrect data. Multiple applications may process the same business event at different times, leaving the organization with conflicting records of what happened.

Supply chain management software development must account for delayed messages, duplicate notifications, out-of-order events, partial failures, and retries. Without those controls, a single shipment update can trigger duplicate inventory movements, incorrect available stock, inaccurate financial records, or unnecessary replenishment orders.

Why Shipment Events Arrive Late or More Than Once

A modern supply chain application rarely operates as one isolated system. Warehouse scanners, carrier APIs, ERP platforms, supplier portals, transportation systems, and inventory services exchange events through APIs, message queues, webhooks, or scheduled integrations.

These connections can fail in several ways.

A warehouse device may temporarily lose connectivity and upload its events after reconnecting. A carrier webhook may be retried because the receiving service did not acknowledge it in time. A message broker may redeliver a message after a consumer crashes before confirming processing.

Events can also arrive out of order. For example, a shipment's departure event may reach the integration service before an earlier loading event.

The receiving application cannot assume that every incoming message is new, current, or ready to apply.

Design Idempotent Event Processing

Idempotency means that processing the same event more than once does not produce additional unintended effects.

Suppose a warehouse receives 100 units of a product. The WMS sends a receipt event, but the acknowledgement is lost. When the sender retries, the receiving service must recognize the repeated event instead of increasing inventory by another 100 units.

A robust event-processing workflow should:

Assign or retain a stable event identifier.
Validate the source, event type, and required business identifiers.
Check whether the event has already been processed.
Apply the permitted state transition and inventory movement.
Record the processing result.
Acknowledge the event only after the required transaction is safely committed.

A deduplication table or equivalent durable event ledger can record processed event identifiers. Where possible, the deduplication record and inventory update should be committed in the same database transaction.

This matters because checking for duplicates in one transaction and updating stock in another can create a race condition. Two workers might both decide that an event is new before either records it as processed.

Do Not Confuse Duplicate Events With Duplicate Business Actions

Two events can describe the same business action without having identical payloads. A carrier might send one notification with a shipment status and another with an updated timestamp. Conversely, two legitimate receipt events may reference the same purchase order but represent different deliveries.

Therefore, deduplication should not rely only on matching product IDs, shipment IDs, or timestamps.

The system needs a stable event identity where available, plus business validation. A unique event ID can prevent a repeated message from being applied twice, while a separate business rule can prevent a shipment receipt from exceeding the quantity expected under a particular delivery or purchase order.

The goal is to eliminate repeated processing without suppressing legitimate movements.

Handle Out-of-Order Events With State Transitions

A shipment usually follows a series of business states: created, allocated, picked, packed, dispatched, in transit, delivered, and received. Actual workflows may contain exceptions, partial deliveries, returns, and cancellations.

A naive implementation might update the shipment status whenever a new message arrives. That approach can cause a late event to overwrite a more advanced state.

For example, a delayed IN_TRANSIT event should not automatically replace a confirmed DELIVERED state.

A safer design validates each transition against the current state and the source event's meaning. The system may use event sequence numbers, source timestamps, version numbers, or authoritative status queries where available. Timestamps alone are not always reliable because clocks can differ and events can be generated at different stages.

When an event cannot be safely applied, the system should preserve it for review or reconciliation rather than silently discarding it.

Keep Inventory Movements Separate From Shipment Status

A shipment status and an inventory movement are related, but they are not interchangeable.

A carrier reporting that a truck has arrived at a distribution center does not necessarily mean the warehouse has physically received and verified the goods. Similarly, a delivery confirmation may refer to the destination rather than a completed put-away operation.

Supply chain software should define which business event authorizes each inventory change.

For example:

A dispatch confirmation may reduce the stock available at the shipping warehouse.
A goods-receipt confirmation may increase received stock at the destination.
A quality-inspection event may move units into a restricted or quarantine state.
A put-away confirmation may move units from receiving to a storage location.

This separation prevents a shipment notification from incorrectly changing sellable inventory.

Use Durable Queues and Transactional Outbox Patterns

When one service updates a database and then publishes an event, a failure between those operations can leave the database updated but the message unsent.

The transactional outbox pattern addresses this by recording the business change and an outgoing event in the same database transaction. A separate publisher then sends the event to the message broker.

On the receiving side, an inbox or event ledger can track incoming messages and prevent repeated processing.

These patterns do not remove every failure. They make failures recoverable by ensuring that the system has durable records of the work that still needs to be delivered or processed.

The architecture should also define retry limits, backoff strategies, dead-letter handling, and procedures for replaying failed messages safely.

Reconcile Systems Instead of Assuming They Agree

Even with careful event processing, ERP, WMS, and TMS records can diverge because of configuration errors, integration outages, manual adjustments, or unsupported transitions.

A reconciliation process should compare the systems' business records using meaningful identifiers such as shipment ID, purchase order, receipt reference, SKU, location, and quantity.

Useful exception categories include:

Shipment marked delivered but no warehouse receipt exists.
A receipt exists in the WMS but not in the ERP.
The same receipt reference appears more than once.
Received quantity exceeds the expected delivery quantity.
Inventory has moved into an unavailable or quarantine state unexpectedly.
A shipment status is inconsistent with the documented event history.

Reconciliation should create actionable exceptions with traceable records. Automatically forcing two systems to match without understanding the discrepancy can hide the underlying problem.

Testing Failure Scenarios

A supply chain application should be tested against failure conditions, not just normal API responses.

The test plan should include duplicate webhooks, delayed events, out-of-order messages, worker crashes, database timeouts, message-broker outages, partial receipts, and manual inventory corrections.

For each scenario, verify that the system preserves the correct inventory balance, records the event outcome, and supports safe recovery. Load testing should also establish how the system behaves when a carrier or warehouse reconnects and sends a backlog of events.

Useful operational metrics include duplicate-event rates, processing latency, retry counts, dead-letter queue volume, reconciliation exceptions, and the time required to resolve an inconsistency.

Recommended Supply Chain Software Development Companies

Organizations implementing these controls may need custom event-processing services, ERP/WMS/TMS integration, or changes to an existing supply chain platform. Dev Technosys is one company to consider for custom supply chain management software development, particularly where business-specific workflows and system integrations need to be planned together.

Other options include enterprise technology providers and integration specialists whose experience matches the organization's existing systems. The selection process should verify event-processing design, transaction boundaries, observability, recovery procedures, and responsibility for ongoing integration support.

Conclusion

Late and duplicate shipment events are inevitable in distributed supply chain environments. Inventory corruption is not.

Idempotent processing, durable event records, validated state transitions, explicit inventory rules, and reconciliation make it possible to recover from delayed or repeated messages without creating additional business errors.

The strongest supply chain architecture treats event delivery as unreliable, records every meaningful transition, and makes uncertainty visible to operations teams. That is the foundation for keeping warehouse inventory, shipment status, and ERP records consistent as the business scales.

Hotel POS Software Development: How to Split One Guest Bill Across Room, Card and Corporate Accounts

Jessica Williams — Fri, 30 Oct 2026 10:08:09 +0000

A hotel guest may order breakfast at the restaurant, enjoy drinks at the bar, request room service, and charge everything to the same room. At checkout, however, the guest might want accommodation and breakfast billed to a corporate account, minibar purchases paid by card, and personal dining expenses settled separately.

This is where hotel POS software development becomes more complex than ordinary retail billing. The system must split charges accurately, communicate with the hotel property management system (PMS), and ensure that every payment and room posting remains traceable.

A well-designed hotel point-of-sale system should not treat a guest bill as a single payment record. It should support multiple payment methods, account-level allocation, tax calculations, refunds, and reconciliation without duplicating revenue.

Why Hotel Bills Need Flexible Splitting

Hotels serve several types of guests, including business travelers, conference attendees, tour groups, families, and long-stay visitors. Each guest may have a different arrangement for paying expenses.

Consider a corporate traveler whose employer covers the room and breakfast but excludes alcohol and personal dining. The restaurant POS must separate eligible charges from personal expenses before the bill reaches the PMS or payment terminal.

Common scenarios include:

Room account: Eligible restaurant or room-service charges are posted to the guest's folio.
Card payment: The guest pays selected items using a debit or credit card.
Corporate account: Approved expenses are transferred to a company account according to negotiated billing terms.
Split tender: A single bill is divided between two or more payment methods.
Shared guest bill: Multiple guests divide a table bill according to items, percentages, or fixed amounts.
Group or event account: Approved charges are assigned to a master folio for a conference, wedding, or tour group.

Without flexible allocation rules, staff may need to create multiple bills manually. That increases checkout time and creates opportunities for incorrect postings, duplicate charges, and reconciliation problems.

How a Split-Billing Workflow Should Work

A reliable workflow begins when the cashier opens the guest's bill. The POS identifies the relevant order, validates the guest or room details, and presents the permitted settlement options.

The cashier selects the items or amounts assigned to each destination. The system then validates the allocation, processes any required card payment, posts eligible charges to the PMS, and records the final settlement status.

For example, imagine a restaurant bill containing:

Breakfast: $35
Lunch: $55
Bar purchase: $25
Total: $115

The guest's company may cover $90 for breakfast and lunch, while the guest pays the $25 bar charge by card. The POS must preserve the original item details while allocating $90 to the approved corporate account and $25 to the card payment.

The amounts are simple in this example. The software logic is not. The system must confirm that the corporate arrangement allows those items, calculate applicable taxes correctly, and ensure that the total allocated amount equals the original bill.

Essential Features for Multi-Account Billing

Item-Level and Amount-Level Allocation

Cashiers should be able to allocate individual items or split a permitted amount across payment destinations. Item-level allocation is particularly useful when corporate policies exclude alcohol, spa services, or other personal purchases.

The interface should make the remaining balance visible throughout the process. If the bill is $115, an allocation of $90 to a company account and $25 to a card should leave no outstanding balance.

PMS and Guest-Folio Integration

The POS should retrieve relevant guest and room information from the PMS through a supported API, integration platform, or approved interface. Depending on the hotel's configuration, the system may need to validate room status, guest identity, billing permissions, and folio selection before posting a charge.

A successful POS payment does not automatically mean that a PMS posting succeeded. The two systems need separate status tracking so that staff can identify and resolve incomplete transactions.

Corporate Account Rules

Corporate billing requires more than a company name on the invoice. The software may need to support credit limits, authorized expenses, tax details, billing periods, purchase references, and approval requirements.

Rules should define which charges can be transferred to a corporate account and which must remain the guest's responsibility. When a charge falls outside an agreement, the POS should flag it before settlement rather than relying on a cashier to discover the issue later.

Tax and Service-Charge Allocation

Taxes, service charges, discounts, and gratuities must follow the applicable business rules. Splitting a bill should not cause the same tax to be counted twice or leave a discount attached to the wrong items.

The software should retain the original transaction, the allocation calculation, and the final settlement records. Finance teams need this information to investigate discrepancies and prepare accurate reports.

Preventing Duplicate Charges and Failed Postings

One of the most important engineering requirements is idempotent transaction processing. In practical terms, repeating the same request because of a timeout should not create a second charge.

Suppose a restaurant POS sends a $35 breakfast charge to the PMS. The PMS processes it, but the response never reaches the POS because the connection drops. If the cashier retries without a transaction reference, the same breakfast could be posted twice.

A safer design uses a unique transaction or idempotency key, tracks the posting state, and checks the PMS response before attempting a new posting. Failed or uncertain transactions should enter a reconciliation queue instead of being blindly resubmitted.

A transaction lifecycle might include:

Bill created.
Items allocated.
Card authorization or payment initiated, where applicable.
PMS posting requested.
PMS posting confirmed or rejected.
Settlement reconciled.
Receipt and audit record generated.

The exact sequence depends on the payment and PMS architecture. For example, a card payment and a room-charge posting require different failure-handling procedures. The system should define what happens if one succeeds and the other fails.

Security and Audit Requirements

Split billing can expose guest information, corporate account details, and payment data. Access controls should ensure that employees can view or modify only the information required for their roles.

Important safeguards include role-based permissions, encrypted communications, secure credential storage, audit logs, controlled refunds, and masked payment details. Card processing should use an appropriate payment provider and minimize the amount of sensitive card data handled by the hotel application.

The audit trail should record who performed an allocation, which items were moved, when the transaction occurred, and whether an adjustment or refund was later issued. Changes to a settled bill should follow a controlled correction process rather than silently rewriting the original record.

How to Test Split Billing Before Launch

Testing should cover more than successful payments. A hotel POS development team should simulate partial approvals, declined cards, unavailable PMS services, duplicate API requests, disconnected terminals, and changes to guest or room assignments.

The test suite should verify that:

Allocated amounts always reconcile with the bill total.
Restricted items cannot be transferred to unauthorized accounts.
Duplicate requests do not create duplicate charges.
Failed PMS postings remain visible for resolution.
Refunds preserve the original transaction history.
Tax and service-charge calculations remain consistent.
Staff can identify pending, rejected, and completed transactions.

A pilot in one restaurant or outlet can expose operational issues before the same workflow is deployed across a property or hotel chain.

Building a Hotel POS That Finance Teams Can Trust

The goal of hotel POS software development is not merely to let guests pay in different ways. It is to preserve a reliable relationship between orders, guest folios, corporate accounts, payment records, and financial reporting.

Development partners such as Dev Technosys can help businesses plan custom POS workflows, integration requirements, and transaction controls around their operational needs. The project scope should be defined around the hotel's existing PMS, payment providers, accounting processes, and billing policies.

When room charges, card payments, and corporate accounts are handled through a clear and auditable workflow, hotel staff can settle bills with less manual work while finance teams gain better visibility into revenue.

POS Software Development: How to Sync Offline Sales Without Double-Counting Orders

Jessica Williams — Thu, 29 Oct 2026 10:28:03 +0000

Why Can Offline POS Sales Create Duplicate Orders?

A point-of-sale (POS) system must do more than record a sale. It needs to preserve transaction accuracy when the internet connection becomes unstable, a payment terminal stops responding, or a cashier retries an action because the screen appears frozen.

Imagine a café serving customers during a network outage. A cashier adds an order, taps the payment button, and sees no confirmation. The cashier taps again. When connectivity returns, both requests reach the server. If the system does not recognize that they belong to the same transaction, the restaurant may end up with duplicate orders or inconsistent payment records.

This is one of the important problems to address during POS software development. Offline functionality should not simply store requests and send them later. It must preserve transaction identity, handle retries safely, and reconcile the final status of each order and payment.

How Should an Offline POS System Work?

A reliable offline workflow separates local order creation from server synchronization.

When a cashier creates an order, the application assigns it a unique identifier and stores the required information locally. The order can then remain available even if the connection drops.

When connectivity returns, the application sends pending records to the server. The server checks whether each transaction has already been processed before creating or updating anything.

A typical workflow looks like this:

The cashier creates an order.
The POS application assigns a unique order ID.
The order is saved in local storage.
The application marks the record as pending synchronization.
When the connection returns, the application sends the record to the server.
The server checks the transaction ID and processes the request safely.
The server returns the current order status.
The POS updates its local record and removes the item from the pending queue.

The important detail is that reconnecting to the internet should not automatically mean creating a new order. The application must first determine whether the original request has already been accepted.

What Is Idempotency, and Why Does It Matter?

Idempotency is a technique that allows repeated requests to produce one intended result rather than creating duplicate transactions.

For example, a POS application might send an order request and receive no response because the connection fails. The server may nevertheless have saved the order. If the application sends the same request again, the server should recognize its unique transaction identifier and return the existing result instead of creating another order.

This requires more than generating a random identifier on every retry. The identifier must remain the same for retries of the same logical operation.

Developers should consider:

Generating stable order and payment-operation IDs.
Enforcing uniqueness where appropriate in the database.
Making retry behavior consistent across the application and server.
Returning the existing result when a request has already been processed.
Separating order creation from payment authorization and settlement.
Recording transaction events so the final state can be reconstructed.

Idempotency also needs to be applied carefully. A customer intentionally placing two separate orders should not have the second order blocked simply because the items are identical. The system must distinguish a retry from a new purchase.

How Should Developers Handle Offline Payments?

Offline order creation and offline payment acceptance are different capabilities.

A POS application may allow a cashier to prepare and save an order without an internet connection, while the payment terminal still requires connectivity to authorize a card transaction. Some payment providers and terminal configurations support particular offline payment methods, but availability and risk controls vary.

The application should therefore maintain separate states for orders and payments.

An order might be marked as:

Draft
Pending synchronization
Synced
Cancelled

A payment might be marked as:

Not started
Pending confirmation
Authorized
Declined
Reconciliation required
Refunded

These states should reflect the actual transaction lifecycle. A saved order must not be treated as proof of a successful payment, and a timeout must not automatically be interpreted as a decline.

If a payment request times out, the system should first check the payment provider's transaction status where supported. Repeating a charge without checking the original request can create a duplicate payment.

How Can a POS System Resolve Synchronization Conflicts?

Synchronization conflicts can occur when the same information changes on more than one device while the system is offline.

For example, two branches may temporarily work with different versions of a menu. A manager may update an item's price centrally while a local terminal still has an older version.

A practical design should define which system owns each type of information. Central menu settings might be controlled by the server, while locally created orders can be stored on the terminal until synchronization succeeds.

Developers should also define rules for:

Price and tax changes.
Cancelled or modified orders.
Inventory updates.
Duplicate records.
Missing or delayed server responses.
Records arriving out of sequence.

A simple “last update wins” approach is not suitable for every field. It can overwrite important changes or produce inaccurate financial records. Conflict resolution should reflect the business meaning of the data.

How Should Developers Test Offline POS Software?

Testing should cover more than switching off Wi-Fi once. Real-world failures are often intermittent, and the application may receive a delayed response after the cashier has already retried an action.

Useful test scenarios include:

Internet access disappears immediately after an order is submitted.
The server saves an order, but its confirmation never reaches the terminal.
The cashier retries the same request multiple times.
The application restarts with unsynchronized orders in local storage.
Two terminals attempt to update related records.
Payment authorization succeeds, but the POS does not receive confirmation.
The network repeatedly disconnects during synchronization.
A refund or cancellation is initiated while the original transaction is still being reconciled.

The team should verify that each scenario produces a traceable result without silently losing transactions or creating duplicate charges.

Which Companies Can Help Build Custom POS Software?

1. Dev Technosys

Dev Technosys can be considered by businesses planning custom POS applications, transaction workflows, inventory features, and integrations with existing business systems. Restaurants should discuss offline synchronization, payment-state handling, and multi-location requirements during project discovery.

2. IBM

IBM provides enterprise technology and software services that businesses may evaluate when a POS project involves complex integrations, data systems, or wider retail technology modernization. The proposed scope should clearly identify whether the engagement covers the POS application itself or connected enterprise systems.

3. Accenture

Accenture works across technology consulting, software delivery, and digital transformation. Businesses considering a large POS modernization initiative can evaluate its capabilities in architecture, integration, data, and enterprise systems. Restaurant-specific implementation experience should be assessed separately.

4. Capgemini

Capgemini provides technology consulting and engineering services that may be relevant to businesses integrating checkout applications with wider operational systems. Buyers should clarify the team's experience with payment workflows, offline requirements, and multi-location deployments.

5. Publicis Sapient

Publicis Sapient focuses on digital business transformation and technology-enabled customer experiences. Its capabilities may be relevant when POS development forms part of a broader commerce modernization program involving customer-facing channels and connected business systems.

What Should Businesses Prioritize?

A reliable offline POS system needs consistent transaction IDs, safe retry behavior, separate order and payment states, and a well-defined reconciliation process. These controls should be built into the architecture rather than added after duplicate transactions begin appearing in production.

For restaurants and retailers, the real measure of offline support is not whether the application can keep running without internet access. It is whether the system can recover from interruptions while preserving accurate orders, payments, inventory records, and financial reporting.

Why Your TMS Rate Quotes Disagree With the Carrier Invoice, and How to Debug It

Jessica Williams — Wed, 28 Oct 2026 09:58:46 +0000

Quick Answer

A transportation management system (TMS) quote and a carrier invoice can differ because they were calculated from different shipment facts, rate versions, accessorial rules, fuel tables, timestamps, or service events. Debug the discrepancy by preserving the original quote, reconstructing the shipment inputs, identifying the exact rate version used, comparing each charge line, and checking what changed between booking and delivery. Do not begin by changing the rate table: first prove whether the mismatch came from data, contract logic, an operational event, or invoice mapping.

Why can a TMS quote differ from a carrier invoice?

A quote is usually an estimate based on the information available when a shipment is rated. The final invoice may reflect measured dimensions or weight, a different service actually performed, a delivery exception, a surcharge, a reclassification, or a contract rule that was not applied correctly at quote time. The invoice is not automatically wrong, and the TMS is not automatically wrong. The first task is to compare like with like.

The useful comparison is not simply “quoted total versus invoiced total.” Compare the shipment identity, carrier account, service level, origin and destination, billable weight, equipment or package type, accessorial selections, fuel schedule, currency, tax treatment, and rating timestamp. If one of these inputs differs, the difference may be explainable before any software defect is suspected.

A practical debugging sequence

1. Freeze the evidence before changing configuration

Save the original quote response, the request payload sent to the rating service, the TMS shipment record, the carrier invoice, and the relevant contract or tariff version. Record timestamps and time zones. If the rating engine is rerun after a rate update, the new result may not reproduce the result seen by the user at booking time.

Keep a trace identifier across the quote request, shipment, tender, delivery event, and invoice record wherever the architecture allows it. If the systems do not share a correlation ID, use a controlled mapping based on shipment ID, PRO number, tracking number, and carrier invoice reference. Avoid relying on a customer-facing reference alone; it may be reused or edited.

2. Reconstruct the exact shipment inputs

Check what the TMS knew when it generated the quote. Compare entered weight and dimensions with the carrier's measured values. Confirm the origin and destination postal codes, residential or limited-access flags, liftgate needs, appointment delivery, declared value, hazardous-material status, and service level. For LTL freight, inspect freight class, pallet count, density, and any reweigh or reclassification notice. For parcel shipments, review dimensional-weight rules and rounding.

A common debugging mistake is comparing the final invoice with a quote generated from an earlier draft shipment. A corrected address, package count, or delivery requirement can legitimately change the price. Preserve a before-and-after field diff so the team can distinguish user edits from downstream carrier updates.

3. Verify the rate and contract version

Identify the exact carrier account, tariff, discount schedule, minimum charge, zone table, fuel surcharge table, and effective date used by the rating engine. Then confirm whether the contract was active at the quote timestamp and whether the carrier invoice used the same agreement. Check whether a new rate table was loaded without a matching effective date, whether a customer-specific override took precedence, or whether a fallback public rate was used after an account lookup failed.

Do not assume the newest rate is the correct historical rate. The correct test is whether the quote used the contract and version applicable to that transaction. A rating trace should explain which rule won, which rule was skipped, and why.

4. Compare the invoice line by line

Build a normalized comparison with one row per charge: base transportation, fuel, residential delivery, liftgate, appointment, reweigh, reclassification, detention, redelivery, address correction, tax, and any other charge that appears on the documents. Normalize codes and descriptions before comparing them; carriers may label the same category differently.

For each line, record the quoted amount, invoiced amount, reason code, evidence source, and status: expected, disputed, or unresolved. A total-only comparison hides offsetting errors—for example, one surcharge omitted and another duplicated. Where an EDI 210 transaction or carrier API is involved, compare the raw message with the mapped invoice fields. An integration can receive the correct amount but map a code, sign, currency, or decimal incorrectly.

5. Trace operational events and timestamps

Some charges depend on what happened after pickup. Review appointment changes, failed delivery attempts, detention, storage, reweigh, reclassification, and proof-of-delivery events. Check whether event timestamps are stored in local time or UTC and whether the business rule uses event time, message-received time, or invoice-posted time. A delayed EDI message can arrive after a shipment has been closed and trigger a late adjustment.

If a surcharge is valid only under a particular condition, make the condition explicit in the system and retain the evidence that activated it. A manual override should identify the user, timestamp, reason, and approval where applicable.

A small example: separate data errors from rule errors

Suppose a TMS quotes $480 and the carrier invoices $536. The $56 difference should not be assigned to “rate mismatch” without analysis. The base freight may match while a $40 reweigh charge and a $16 fuel adjustment explain the variance. Alternatively, the invoice integration may have duplicated a $40 line and applied a fuel table from the wrong week. Those outcomes need different fixes.

Use a discrepancy record with four fields: expected value, actual value, root-cause category, and corrective action. Root-cause categories can include shipment data, contract/rate version, carrier event, integration mapping, rounding/currency, and manual adjustment. Track repeated causes by carrier, lane, charge code, and system interface rather than treating every invoice as a one-off exception.

What should engineering teams log?

A useful rating audit record contains the shipment identifier, carrier account alias, request and response timestamps, correlation ID, origin/destination attributes, rated weight, service level, selected tariff ID and version, applied rules, currency, line-item breakdown, and any external response code. Store secrets outside logs and redact personal or commercially sensitive fields that are not required for diagnosis.

For invoice ingestion, retain the original message or document reference, parsed line items, mapping version, validation errors, and reconciliation result. This makes it possible to determine whether the carrier sent an unexpected value or the integration transformed it. Add automated tests for duplicate messages, missing accessorial codes, rate-table effective dates, decimal precision, and late-arriving events.

When should the discrepancy be escalated?

Escalate to the carrier when the invoice charge has no supporting event, the applied tariff conflicts with the signed agreement, or the carrier's measured shipment data cannot be reconciled. Escalate to the TMS vendor or engineering team when the wrong rate version was selected, a charge was mapped incorrectly, a duplicate message created duplicate billing, or the system cannot reproduce the original quote.

A repeatable exception workflow is more valuable than a manual spreadsheet that only one analyst understands. It should preserve evidence, assign an owner, capture dispute deadlines, and close the loop by updating a rule or test after the cause is confirmed.

Five logistics software development companies to evaluate

Figures below come from each company’s own website and are self-reported, so confirm them directly before signing anything.

1. Dev Technosys

Dev Technosys offers transportation software development services for workflows involving fleet operations, shipment visibility, integrations, and logistics intelligence. Its public transportation page describes capabilities including GPS, telematics, cloud, API integration, and fleet automation; it also displays 250+ professionals. For a TMS discrepancy project, the useful discussion is whether the team can trace a quote from request payload through contract logic, carrier events, invoice mapping, and audit records. Dev Technosys brings a custom transportation engineering position that connects operational workflows with the integration layer.

2. Velvetech

Velvetech describes software engineering work across shipping, freight, and IoT telematics on its official website. Those areas are relevant when an invoice discrepancy is linked to shipment events, location data, or a system that joins transport operations with billing. Ask for a concrete walkthrough of carrier integrations, exception handling, and how test evidence is preserved after deployment; a general logistics portfolio does not by itself prove experience with your carrier contracts. Velvetech suits teams that need logistics workflows connected with custom software and telematics.

3. Trigent Software

Trigent presents custom software engineering and digital transformation services, including work around logistics and freight-related systems on its official channels. For a TMS rating or invoice-audit build, evaluate its approach to integration testing, data normalization, and maintaining business rules as carrier contracts change. Request an example of how it distinguishes a valid accessorial from a duplicate or mis-mapped charge, and clarify who owns the rules and regression tests after launch. Trigent Software suits enterprises seeking a custom engineering partner for connected operational systems.

4. Chetu

Chetu offers custom software development for transportation and logistics workflows, according to its company site. A project involving freight billing may require more than a user interface: it can involve carrier data ingestion, contract rules, exception queues, and accounting-system integration. Before choosing a partner, confirm whether its proposed scope includes raw-message inspection, invoice line-item normalization, audit history, and repeatable reconciliation tests rather than only dashboard reporting. Chetu suits organizations that want bespoke logistics applications tied to their existing business systems.

5. Netsmartz

Netsmartz describes software development and engineering services for businesses that need applications integrated with existing systems. In a freight-rating project, the evaluation should focus on how the team will reproduce a historical quote, version rate tables, and handle late or duplicate carrier events. Ask for a written integration plan that identifies the systems of record, error ownership, monitoring, and post-launch support. Netsmartz suits companies that need application engineering and integration capacity for transport or fleet-related workflows.

Security and compliance considerations

Freight records can expose customer addresses, shipment contents, commercial rates, account identifiers, and delivery details. Restrict access by role, encrypt traffic, protect API credentials, and avoid placing secrets or unnecessary personal data in diagnostic logs. Retain the original invoice and message only for a defined business and contractual period, and ensure that audit records cannot be silently overwritten.

Compliance requirements depend on the countries, goods, customers, and systems involved. Treat this as technical guidance, not legal advice. Ask your compliance and legal teams to confirm applicable privacy, record-retention, tax, and transport requirements before setting production policies.

FAQ

Why is my TMS quote lower than the carrier invoice?

The invoice may include measured-weight changes, accessorial charges, fuel adjustments, reclassification, or events that were unknown when the quote was created. Compare each charge line and the shipment inputs before deciding the invoice is incorrect.

Can a carrier API return a different price from the TMS?

Yes. The TMS may apply its own contract tables, discounts, defaults, or rounding rules, while the carrier API may use a different account, service, or effective rate. Log the request, response, and rate version to isolate the difference.

How do I prevent recurring freight invoice discrepancies?

Use versioned rate tables, normalized charge codes, a line-item reconciliation workflow, automated tests for duplicate and late messages, and a root-cause dashboard grouped by carrier and charge type.

Should every invoice mismatch be disputed?

No. First classify the difference. Some variances are legitimate charges supported by shipment events or contract terms; others may be data, rating, or integration defects. Dispute only after checking the evidence and contract.

Designing a Fleet Tracking Backend That Handles Bad GPS Data

Jessica Williams — Tue, 27 Oct 2026 10:50:56 +0000

Quick Answer

A fleet tracking backend should treat every GPS ping as untrusted input. Sort pings by device time, drop duplicates and impossible values, reject poor fixes and teleport jumps, hold position while a vehicle is parked, and add hysteresis to geofences. Keep the raw stream, store the cleaned stream beside it, and snap to roads only after cleaning. The Python below was tested on synthetic data only, not on live device feeds.

Why does a fleet app receive bad GPS data?

Some of the reasons are written down in vendor documentation. Samsara's vehicle locations documentation says a device reports about every 5 seconds while the vehicle is on and about once an hour while it is off. It also says identical consecutive records can occur, and that GPS interference in a garage can suppress updates even when the vehicle shows as on. The same page says the device keeps a rolling 30 days of location data, so after a connection is restored the buffered points become available through the API.

Read together, those statements describe four problems a backend must expect: duplicate rows, silent gaps, a misleading "on" status, and late data that arrives out of order. This is one vendor's documentation. Other vendors will behave differently, so read the equivalent page for the device you actually use.

What should the ingest layer check before it stores a ping?

My suggestion (author judgement, not a standard) is six cheap checks, run in this order:

Sort by device timestamp, so late arrivals land in the right place.
Drop exact duplicates (same time and position).
Reject impossible values, including out-of-range coordinates and the 0,0 position that some receivers report before they have a fix.
Reject poor fixes, where the reported accuracy is worse than a threshold.
Reject teleport jumps, where the implied speed between two kept points is not plausible for a vehicle.
Hold position while parked, so receiver jitter does not draw a wandering trail.

The thresholds in the code (50 m accuracy, 45 m/s, 10 m jitter) are starting values I chose for the example. Tune them against your own vehicles and devices.

from dataclasses import dataclass
from math import radians, sin, cos, asin, sqrt

@dataclass(frozen=True)
class Ping:
    device: str
    ts: int            # epoch seconds, device clock
    lat: float
    lon: float
    acc_m: float = 10  # reported horizontal accuracy in metres

def haversine_m(a, b):
    r = 6371000.0
    p1, p2 = radians(a.lat), radians(b.lat)
    dp, dl = p2 - p1, radians(b.lon - a.lon)
    h = sin(dp / 2) ** 2 + cos(p1) * cos(p2) * sin(dl / 2) ** 2
    return 2 * r * asin(sqrt(h))

def clean(pings, max_acc_m=50, max_speed_ms=45, jitter_m=10):
    """Return a cleaned, time-ordered list for ONE device."""
    seen, ordered = set(), []
    for p in sorted(pings, key=lambda p: p.ts):               # 1. fix ordering
        key = (p.ts, round(p.lat, 6), round(p.lon, 6))
        if key in seen:                                        # 2. drop duplicates
            continue
        seen.add(key)
        if not (-90 <= p.lat <= 90 and -180 <= p.lon <= 180):  # 3. impossible values
            continue
        if p.lat == 0 and p.lon == 0:                          #    "null island" fix
            continue
        if p.acc_m > max_acc_m:                                # 4. poor fix
            continue
        ordered.append(p)

    out = []
    for p in ordered:
        if out:
            prev, dt = out[-1], p.ts - out[-1].ts
            if dt <= 0:
                continue
            d = haversine_m(prev, p)
            if d / dt > max_speed_ms:                          # 5. teleport jump
                continue
            if d < max(jitter_m, p.acc_m):                     # 6. parked jitter
                p = Ping(p.device, p.ts, prev.lat, prev.lon, p.acc_m)
        out.append(p)
    return out

Testing status: I ran six unit tests with Python 3.13 on synthetic points: out-of-order input, duplicates, 0,0 and poor-accuracy points, a teleport jump, parked jitter, and geofence flapping. All six passed. I have not run this against real device feeds, so treat it as a teaching sample and not production code.

How do you stop geofence alerts from flapping?

A vehicle parked near the edge of a depot boundary can cross it back and forth because of receiver noise, and each crossing can fire an alert. Two techniques help. Use hysteresis, which means the vehicle enters a zone inside radius r but only exits beyond r plus a buffer. Then require several consecutive pings before the state changes.

class Geofence:
    """Circle fence with hysteresis: enter inside r, exit only outside r + buffer."""
    def __init__(self, lat, lon, r_m, buffer_m=30, confirm=2):
        self.c = Ping("fence", 0, lat, lon)
        self.r, self.buf, self.confirm = r_m, buffer_m, confirm
        self.inside, self._streak = False, 0

    def update(self, p):
        d = haversine_m(self.c, p)
        want_inside = d <= self.r if not self.inside else d <= self.r + self.buf
        if want_inside == self.inside:
            self._streak = 0
            return None
        self._streak += 1
        if self._streak >= self.confirm:
            self.inside, self._streak = want_inside, 0
            return "enter" if self.inside else "exit"
        return None

In the test, a sequence of distances of 150, 90, 95, 110, 98, 105, 160 and 170 metres from a 100 m fence produced exactly one enter event and one exit event. Two of those readings (110 m and 105 m) were outside the 100 m radius while the vehicle was still inside the zone, and the buffer absorbed both.

Should you snap points to roads?

Map matching can clean what the filters above leave behind, but it has its own rules. Google's Roads API documentation says one snap-to-roads request accepts up to 100 GPS points and returns points snapped to the most likely road. It recommends keeping consecutive points at or below about 300 metres apart, and offers an optional interpolate setting that adds points following the road shape. Interpolated points have no original index, so the response can contain more points than the request.

OSRM's Match service takes optional timestamps, which must increase, and optional per-point radiuses that default to 5 metres. The documentation suggests using the device's reported accuracy. It returns null for points dropped as outliers and a confidence score from 0 to 1 for each matching. The OSRM page I read was for version 5.5.1, so check the documentation for the version you run.

My judgement: snap after cleaning, keep the raw point and the snapped point side by side, and treat a low confidence score as a flag for review rather than an error.

How do you find vehicles near a depot quickly?

PostGIS documents ST_DWithin as a cheap filter that can use a spatial index, while ST_Distance computes exact distances and cannot use indexes. For geography values the distance is in metres. The common pattern is to filter with ST_DWithin first and sort with ST_Distance on what remains.

SELECT v.id, ST_Distance(v.last_position, d.location) AS metres
FROM vehicles v
JOIN depots d ON d.id = 7
WHERE ST_DWithin(v.last_position, d.location, 2000)
ORDER BY metres;

This query is untested. It assumes both columns are geography with a spatial index on last_position, so check the types and the index in your own schema.

What should the fleet database store?

In my view three tables cover most needs: an append-only table of raw pings, a table of cleaned pings that maps and reports read, and a small table holding the last known position per vehicle for proximity queries. Keeping the raw data lets you re-run a better filter later and settle disputes about a route.

Which are the top five fleet management app development companies?

Teams that prefer to buy this work instead of building it can compare the five partners below. The list is not a ranking of quality.

Figures below come from each company's own website and are self-reported, so confirm them directly before signing anything.

1. Dev Technosys

Dev Technosys is a fleet management app development company with 250+ professionals that does business globally. Its fleet page describes connecting GPS tracking, fuel monitoring and dispatching systems, then automating assignments, maintenance alerts and journey updates. The company builds its own platforms and connects them to existing business systems through APIs instead of configuring third-party ERP products. It states an 89% project success rate and says most new business comes through client referrals; both claims are self-reported. That scope fits teams that already own tracking hardware and need workflow software around it.

2. N-iX

N-iX lists fleet management software development as a dedicated service. Its page covers telematics and predictive-maintenance integration, ELD and IoT sensor integration, hours-of-service compliance modules, route-planning and dispatch engines, and mobile fleet apps. A case study describes a GPS-tracked in-vehicle Linux gateway, a Google Cloud IoT platform and an Android driver app for a telematics client, in a partnership that began in February 2021. The site states over 2,400 software engineers, and the case study gives no fleet outcome figures. N-iX suits teams that need hardware-to-cloud telematics work from one vendor.

3. Intellias

Two fleet case studies sit on the Intellias site. In the first, a Florida telematics client has worked with the company since 2018 on a platform with real-time GPS mapping, idle-time tracking and diagnostic trouble code reporting, and the page says it handles 100,000+ vehicles with data points every 30 seconds. The second is a native iOS, Android and Angular truck-tracking front end for a large car maker, tested on 1,000 vehicles and offered in more than 20 countries. Intellias suits teams that expect high vehicle counts and need a backend built for that volume.

4. Altoros

Altoros says it was founded in 2001 and lists GPS tracking software for car rental, trucking and delivery, fleet management with vehicle tracking and dispatch, and IoT platforms for fleets. Its logistics page cites a transport management case serving 100+ companies and processing 10,000+ automated orders a day, with operator workload cut by up to 70%, plus a truck-parking app prototype covering 10,000+ locations. All of these figures are self-reported, and the page names no ISO certification, so ask for evidence. Altoros suits teams that want an IoT-heavy build from a long-established vendor.

5. STX Next

Describing itself as a Python-native team with more than 20 years of experience, STX Next lists fleet management systems, route optimization, electronic proof of delivery, predictive maintenance and IoT integration on its transport and logistics page. Named case studies include Sendcloud (a carrier integration proof of concept), GS1 Polska (a location-data app for drivers) and T Dispatch (dispatch software). The page mentions Python, IoT, RFID, AWS, Azure and Snowflake and lists delivery centers in Poznan and Merida, but it states no headcount. STX Next suits teams that prefer a Python backend.

FAQ

How often should a fleet device send a position?

Samsara's documentation describes about every 5 seconds while a vehicle is on and about hourly while it is off. Your hardware and data plan set the real figure.

Should raw pings be deleted after cleaning?

In my view, no. Keep them for a retention period your own policy allows, so you can re-run improved filters later.

Do I need map matching in every fleet app?

No. Many dashboards work with cleaned points. Matching helps most when you report distance driven on roads.

What accuracy threshold should I use?

The example uses 50 m as a starting value. Tune it per vehicle type and device.

Can I use this code in production?

It is a teaching sample tested on synthetic data. Add tests built from real device samples first.

Multi-Warehouse Inventory Is a Distributed Systems Problem: What to Build in Supply Chain Software

Jessica Williams — Mon, 26 Oct 2026 13:03:41 +0000

Quick Answer

Multi-warehouse inventory goes wrong in the same ways distributed systems do: two writers race for the last unit, a scanner retries a request, a message is published twice or never, and a device works offline for an hour. Keep a balance row with CHECK constraints, change it with one conditional UPDATE, record every change in an append-only ledger under a unique idempotency key, publish events through an outbox, key Kafka messages by stock position and filter reservations by expiry at read time. This guide shows each part with SQL tested on PostgreSQL 16 and behavior taken from PostgreSQL 18, Kafka 4.3, Stripe and Firebase documentation checked on October 26, 2026. It ends with five teams that build supply chain software.

Why Is Multi-Warehouse Inventory a Distributed Systems Problem?

One warehouse with one database and one operator can get away with UPDATE stock SET qty = qty - 1. Several warehouses cannot. Pickers on handheld scanners, a web order flow, a replenishment job and an ERP sync all touch the same stock positions, over networks that drop requests, and each caller may retry.

That creates four failure modes worth designing for:

Lost updates. Two writers read 10 units and both write back 9.
Overselling. Two orders reserve the same last unit.
Duplicate effects. A scan is retried and decrements stock twice.
Split-brain events. The database says stock moved, but the message that tells other systems never left, or it left twice.

The rest of this guide takes them in turn. The SQL ran on a local PostgreSQL 16 server while this article was prepared. Statements about concurrent behavior come from the PostgreSQL 18 documentation, not from a load test.

How Do You Stop Stock From Going Negative?

Put the rule in the database, then make the write conditional. PostgreSQL's documentation says a CHECK constraint passes when its expression is true or null, so a quantity column needs NOT NULL as well. It also says a CHECK cannot look at other rows, so "the sum of ledger rows is at least zero" cannot be a CHECK on the ledger. Keep a balance table and put the constraint there.

CREATE TABLE stock_balance (
  sku_id        bigint  NOT NULL,
  warehouse_id  bigint  NOT NULL,
  on_hand       integer NOT NULL DEFAULT 0
                CONSTRAINT on_hand_non_negative CHECK (on_hand >= 0),
  reserved      integer NOT NULL DEFAULT 0
                CONSTRAINT reserved_non_negative CHECK (reserved >= 0),
  CONSTRAINT reserved_le_on_hand CHECK (reserved <= on_hand),
  PRIMARY KEY (sku_id, warehouse_id)
);

Reserving stock is then a single statement:

UPDATE stock_balance
   SET reserved = reserved + 4
 WHERE sku_id = 1 AND warehouse_id = 1
   AND on_hand - reserved >= 4
RETURNING on_hand, reserved;

With 10 units on hand, the first call returned one row (10, 4). Asking for 7 more returned zero rows, which PostgreSQL reports as UPDATE 0 and not as an error. Treat zero rows as a business answer ("insufficient stock") and not as an exception.

Why is this safe under concurrency? The documentation says that in the default Read Committed level, an UPDATE that meets a row another transaction is changing waits for it, and if the other transaction commits, the WHERE clause is checked again against the new row version. The second writer therefore sees the reduced balance and matches nothing. The same page warns that complex multi-row conditions can behave differently, so keep the conditional update to one row.

At Repeatable Read and Serializable, the documentation says the database may instead raise a serialization failure (SQLSTATE 40001) and that the application must retry the whole transaction. If you raise the isolation level, add the retry loop first.

When one transaction touches several balance rows, take them in a consistent order, for example sorted by SKU and warehouse. The documentation names consistent ordering as the best defense against deadlocks and recommends keeping transactions short.

Should You Store Stock as a Ledger or as a Column?

Both, and this is the author's recommendation rather than a documented rule. A mutable quantity answers "how many now" quickly but forgets why. An append-only ledger answers "what happened" but needs a fold to answer "how many". Martin Fowler's event sourcing article, which he describes as a draft he will not update, lists the drawbacks as well as the benefits: replays are slow without snapshots, side effects during replay need care and retrofitting is hard. Microsoft's Azure Architecture Center page says to apply event sourcing selectively and lists simple CRUD systems and prototypes as poor fits.

The hybrid that follows from this: the ledger is the audit record, the balance row is the fast read, and both change in the same transaction.

CREATE TABLE stock_ledger (
  entry_id         bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  sku_id           bigint      NOT NULL,
  warehouse_id     bigint      NOT NULL,
  qty_delta        integer     NOT NULL,
  reason           text        NOT NULL,
  idempotency_key  text        NOT NULL,
  created_at       timestamptz NOT NULL DEFAULT now(),
  CONSTRAINT ledger_idem UNIQUE (idempotency_key)
);

How Do You Make a Scanner Retry Harmless?

Give every scan event a key and let the database refuse the second copy. Stripe's API documentation is a useful worked example: the client generates the key (it suggests high-entropy values such as UUIDs, up to 255 characters), the server stores the first result and returns it on a retry, and a retry with different parameters is an error. Stripe also says keys can be pruned once they are at least 24 hours old, so a key is not a permanent identity.

The IETF has an Idempotency-Key header draft in progress. As of October 26, 2026 it is an Internet-Draft (revision 08, updated October 22) and not an RFC, so describe it as a draft. It suggests 409 when a retry arrives while the first request is still running and 422 when a key is reused with a different payload.

For a scanner, one key per scan event is enough, for example a UUID or the device ID plus a local sequence number. The ledger's UNIQUE constraint does the rest:

BEGIN;
WITH ins AS (
  INSERT INTO stock_ledger (sku_id, warehouse_id, qty_delta, reason, idempotency_key)
  VALUES (1, 1, -4, 'pick', 'scan-0001')
  ON CONFLICT (idempotency_key) DO NOTHING
  RETURNING qty_delta
)
UPDATE stock_balance b
   SET on_hand = b.on_hand + ins.qty_delta
  FROM ins
 WHERE b.sku_id = 1 AND b.warehouse_id = 1
RETURNING b.on_hand, b.reserved;
COMMIT;

Results from the test run: the first call returned on_hand = 6. The same key sent again inserted nothing, so the update matched nothing and the balance stayed at 6. A second pick of 9 with a new key violated the on_hand_non_negative constraint, the transaction rolled back, and the ledger still held one row. The application should read "no row returned" as "already applied" and answer with the earlier result.

How Do You Publish Stock Events Without Losing or Duplicating Them?

Writing to the database and then publishing to a broker is two actions that can fail separately. The transactional outbox pattern, as described on microservices.io, writes the message to an outbox table in the same transaction as the business change and lets a separate relay publish it. The message goes out if and only if the transaction commits. The same page says the relay can publish a message more than once, for example after a crash between publishing and marking the row sent, so consumers must be idempotent.

A relay can claim rows with FOR UPDATE SKIP LOCKED:

BEGIN;
SELECT id, event_key, payload
  FROM outbox
 WHERE published_at IS NULL
 ORDER BY id
 LIMIT 100
 FOR UPDATE SKIP LOCKED;
-- publish these to the broker, then:
UPDATE outbox SET published_at = now() WHERE id IN (/* claimed ids */);
COMMIT;

The PostgreSQL documentation says SKIP LOCKED gives an inconsistent view of the data, is not for general-purpose work, and suits queue-like tables with several consumers. That fits an outbox, but never use it to compute stock totals. One consequence is the author's inference: with several relay workers, a later row can be published before an earlier row that another worker holds, so either run one relay per key range or let consumers order events by a per-key sequence.

What Should the Kafka Side Look Like?

Kafka guarantees order per partition, not per topic, and events with the same key go to the same partition. So key messages by the stock position, for example warehouse_id:sku_id, and every movement of that position stays in order.

For delivery, the Kafka 4.3 documentation describes the idempotent producer, which lets the broker discard duplicate resends using a producer ID and sequence numbers. In 4.3 enable.idempotence defaults to true unless a conflicting setting disables it, and it requires acks=all, retries above zero and at most five in-flight requests per connection. Setting it explicitly makes a conflict fail loudly instead of silently turning it off.

enable.idempotence=true
acks=all
max.in.flight.requests.per.connection=5
# only if you use transactions:
# transactional.id=inventory-writer-1
# consumer side for read-process-write:
# isolation.level=read_committed
# enable.auto.commit=false

These are the documented property names and were not run against a cluster. The part people overlook is the consumer. Kafka's documentation says exactly-once to an external system needs that system's cooperation, so a consumer that writes to PostgreSQL is at-least-once unless it stores the event ID, or the offset, in the same transaction as the write. Use the ledger's idempotency key for that. I have not checked how adding partitions changes the mapping from key to partition, so verify that before you resize a live topic.

How Should Reservations Expire?

No official document defines an inventory reservation, so treat this as a design. Hold stock in a reservations table with an expires_at column, treat expired rows as inactive when you read, and run a worker that uses SKIP LOCKED to release expired rows and reduce reserved in the same transaction.

Be wary of letting a database's TTL feature release stock for you. Redis documents passive and active expiry, but a Redis key should not be your system of record for stock. Firestore's documentation says TTL deletion typically happens within 24 hours of expiry and that expired documents still appear in queries until deleted. DynamoDB says expired items are typically deleted within a few days and remain readable until then. Both tell you to filter on the expiry field in queries. TTL is cleanup, not a timer.

What Happens When Scanners Work Offline?

Firestore's offline documentation says a client can read and write cached data while disconnected and that changes sync on reconnect, with last write winning when the same document is changed more than once. For inventory, that rule is a trap. If two offline scanners each write an absolute quantity of 7 to the same document, one count silently disappears. The transactions page adds that transactions fail while the client is offline, though it documents FieldValue.increment() for simple counter updates.

No official document I found prescribes a conflict strategy for offline scanners, so the following is the author's design: queue scan events on the device, give each an idempotency key, send deltas and not absolute counts, apply them in order per stock position on the server, and flag any event that would push stock below zero for a person to resolve. Firestore also documents a limited sustained write rate for a single document. A figure of about one write per second is often cited, but Google's current quota page does not state it and the best-practices page says the rate depends on workload, so load-test a hot SKU before choosing a counter design.

What Should You Build First?

Problem	Control	First step this week
Negative stock	CHECK on the balance row plus a conditional UPDATE	Add NOT NULL and CHECK constraints
Double scans	Unique idempotency key on the ledger	Generate one key per scan event
Lost messages	Outbox written in the same transaction	Add an outbox table and a relay
Duplicate messages	Idempotent consumers, keyed by event ID	Store processed IDs in the consumer's database
Wrong order	Kafka key by stock position	Key by warehouse and SKU
Phantom holds	Expiry filtered at read time	Add expires_at and a release worker
Offline conflicts	Deltas with keys, not absolute counts	Queue events on the device

Which Teams Build Supply Chain Software? Five Worth Knowing

Figures below come from each company's own website and are self-reported, so confirm them directly before signing anything.

1. Dev Technosys

Dev Technosys is a supply chain software development company that lists custom supply chain management development, consulting, software integrations, AI-powered supply chain development, maintenance and support, and dedicated developers for hire. Its page names inventory, transportation, warehouse, procurement, logistics and supplier relationship management solutions, and describes a three-step path from business and process evaluation through custom software strategy to an implementation and delivery plan. It cites 250+ professionals. Dev Technosys suits manufacturers, distributors and 3PLs that want strategy, engineering and integration for one supply chain platform from a single provider.

2. SysGears

SysGears says it was founded in 2010, lists offices in Paphos, Dnipro, Lviv and Wroclaw and cites 110+ experts. Its warehouse page covers custom WMS builds, additions to existing systems and legacy modernisation, with integrations to carriers, e-commerce platforms, ERP and hardware such as AMRs and ASRS. A seven-step process runs from a kickoff call through discovery, team building, design and agile development to QA and collaboration. It names Node.js, NestJS, Kafka and PostgreSQL and no certifications. SysGears suits mid-size operators that want a WMS-focused team with a clear process.

3. Django Stars

Django Stars lists a Wilmington, Delaware address in its footer and gives conflicting team sizes, so none is quoted. Its supply chain service covers custom builds, legacy modernisation, ERP, WMS and TMS integration, EDI and API work and IoT telematics. Seven steps run from a supply chain audit through process mapping, architecture, development, integration and testing to launch. It names Python, Django, PostgreSQL and Redis, and claims ISO 27001 without naming an issuer. Django Stars suits retail, distribution and 3PL teams that want a Python-based build with a phased method.

4. Atomic Object

Atomic Object lists offices in Ann Arbor, Chicago, Grand Rapids and Raleigh and says it has worked with clients since 2001, without stating headcount. Its logistics page describes three stages: alignment through human-centred design, delivery of working software in two-week increments, and a no-surprises stage that tracks progress against the remaining budget. It offers a free build-versus-buy guide and a project budget model after a meeting, names no programming languages and claims no certifications. Atomic Object suits US freight brokers, shippers and carriers that want a US-based, product-minded build team.

5. Saigon Technology

Saigon Technology labels Ho Chi Minh City as its head office, says it has operated since 2012 and states 400+ developers. Its supply chain page lists planning, procurement, inventory, warehouse, transportation and visibility work, with integrations to SAP, Oracle, Microsoft Dynamics and EDI, and messaging through Kafka and gRPC. Five stages run from discovery and architecture through two-week sprints and testing to deployment and support. It names BSI as the issuer of its ISO 27001 and 9001 certificates. Saigon Technology suits buyers wanting a Vietnam-based team with a staged process.

Frequently Asked Questions

How do you prevent overselling in a multi-warehouse system?

Use one conditional UPDATE on a balance row that checks available stock in its WHERE clause, backed by NOT NULL and CHECK constraints, and treat a zero-row result as "insufficient stock". PostgreSQL's documentation says the condition is checked again after a competing transaction commits.

Is exactly-once delivery possible with Kafka and PostgreSQL?

Kafka documents exactly-once processing within Kafka using transactions. For an external system such as PostgreSQL, its documentation says that system must cooperate, so store the event ID or offset in the same database transaction as the write, or dedupe by idempotency key.

Should I use event sourcing for inventory?

Only where you need the audit trail or replay. Microsoft's guidance lists simple CRUD systems and prototypes as poor fits. A ledger plus a balance row gives most of the audit value with less machinery, which is the author's recommendation.

How do I choose a supply chain software development company?

Ask for a written scope, how stock consistency and offline scanning will be tested, which integrations are included, who owns the code afterward and what support costs once the system is live. Be cautious of any price quoted before someone has seen your warehouses and systems.