[ CONSULTING ] // LOGISTICS & SUPPLY CHAIN

Freight software that holds up at 3 AM on Black Friday

EDI integrations, WMS/TMS modernization, and real-time tracking built for 24/7 operations. We've shipped against Manhattan, SAP TM, Oracle WMS, and the EDI specs of every major retailer.

Veteran-Owned SDVOSB
[001 / 005] Field Conditions

Most logistics software fails the way logistics actually works — sideways, at scale, at night

// SITUATION

The TMS demo looked great. Then the first peak hit. EDI 214 status updates started arriving out of order, an 856 batch got rejected by Walmart at 11 PM, the rate engine quoted a fuel surcharge from last quarter, and your dispatchers ended up in a shared spreadsheet again. The platform vendor blames the integrator. The integrator blames the carrier. Meanwhile the customer service queue is full and your CFO is asking why chargebacks are up. The pattern is consistent across shippers and 3PLs: the happy path was built. The exception path wasn't.

  • ▸ EDI partners silently change segment requirements and your mapping engine fails open instead of alerting before transmission.
  • ▸ Real-time tracking dashboards show stale data because nobody reconciled Project44, ELD, and carrier API timestamps.
  • ▸ WMS and TMS run as black boxes — when a load is stuck, no one can answer where in the pipeline it died.
  • ▸ Modernization stalls because the legacy system can't be taken offline and dual-running was never designed in.
24/7
Operations cadence we design for
< 8 wks
Typical first EDI partner live
SDVOSB
Certified for federal set-asides
[002 / 005] Operational Approach

Build for the 3 AM exception, not the 10 AM demo

  1. STEP-01

    Map every trading partner spec

    Before writing code, we inventory every EDI 204/210/214/856/940/945 variant your partners send. Walmart's 856 isn't Target's 856. We document segment-level deviations, qualifier quirks, and ISA/GS envelope rules so nothing surprises you in production.

  2. STEP-02

    Idempotent ingestion + replay

    Every inbound document — EDI, API, scanner event, ELD ping — lands in an append-only event store before it touches WMS or TMS. If Manhattan or SAP TM is down, we replay on recovery. No lost shipments, no duplicate billing, no manual reconciliation.

  3. STEP-03

    Exception queues with SLAs

    Most freight software treats exceptions as logs. We build them as work queues with owners, age thresholds, and escalation rules. A stuck 214 status, a missing PO match, a weight discrepancy — each gets routed, timed, and tracked until cleared.

  4. STEP-04

    Observability at the load level

    Dashboards that answer the dispatcher's actual question: where is load #4471823 right now, what's blocking it, who touched it last. We instrument with OpenTelemetry, correlate by shipment ID across WMS, TMS, ELD, and customer portals, and alert on business metrics — not just CPU.

  5. STEP-05

    Cutover without a freeze

    24/7 operations can't take a weekend outage. We run dual-write or shadow-read patterns against the legacy WMS/TMS, reconcile nightly, and cut over by warehouse, lane, or customer. Rollback is a config flag, not a war room.

// TYPESCRIPT PATTERN 
// Idempotent EDI 214 (shipment status) ingestion
// Trading partners retransmit. Networks duplicate. Plan for it.

import { z } from 'zod';
import { db, eventStore, tms } from './infra';

const Edi214 = z.object({
  isaControlNumber: z.string(),
  shipmentId: z.string(),
  statusCode: z.string(), // X4, AF, CP, etc.
  statusTimestamp: z.string().datetime(),
  stopNumber: z.number().int(),
  rawSegment: z.string(),
});

export async function ingest214(payload: unknown, partnerId: string) {
  const msg = Edi214.parse(payload);
  const dedupeKey = `214:${partnerId}:${msg.isaControlNumber}:${msg.shipmentId}:${msg.statusCode}:${msg.stopNumber}`;

  const inserted = await eventStore.insertIfAbsent({
    key: dedupeKey,
    type: 'edi.214.received',
    payload: msg,
    receivedAt: new Date(),
  });
  if (!inserted) return { status: 'duplicate', dedupeKey };

  try {
    await tms.applyStatus(msg.shipmentId, msg.statusCode, msg.statusTimestamp);
    return { status: 'applied' };
  } catch (err) {
    // TMS down? Leave the event; replay worker will retry with backoff.
    await db.exceptions.enqueue({ dedupeKey, reason: String(err), sla: '15m' });
    return { status: 'queued_for_retry' };
  }
}

Every EDI 214 we've seen in production gets retransmitted at least once a week — idempotency keys and a replay queue are non-negotiable.

[003 / 005] Common Questions

Field FAQ.

→ We're on legacy Manhattan WMOS / SAP ECC. Can you modernize without halting operations?

Yes — and we assume you can't take downtime. The pattern is shadow-read first: we stand up the new service, mirror inbound events from the legacy system, and reconcile outputs nightly until parity is provable. Then we cut over by warehouse or customer, not big-bang. We've done this against Manhattan WMOS, SAP ECC, Oracle WMS Cloud, and homegrown AS/400 systems. Expect 8–16 weeks per facility depending on integration count and EDI partner spread.

→ How do you handle EDI 856 (ASN) accuracy penalties from retailers?

ASN chargebacks usually trace to three things: late transmission, GTIN/UCC-128 mismatches, or pack hierarchy errors. We instrument the 856 generation pipeline end-to-end, validate against each retailer's spec before transmission (Walmart, Target, Amazon, Home Depot all differ), and add a pre-send simulator that flags violations earlier. Most clients see chargeback rates drop materially within a quarter, but the real win is auditable evidence when you dispute the ones that do hit.

→ Can you integrate real-time tracking from carriers and ELDs?

Yes. We pull from Project44, FourKites, MacroPoint, and direct ELD APIs (Samsara, Motive, Geotab) depending on what your carriers support. The hard part isn't the API — it's reconciling three sources that disagree about where a truck is. We build a single shipment-state service that ranks signals by recency and confidence, exposes a clean GraphQL or REST surface to your customer portal, and stores the raw feeds for dispute resolution.

→ Are you SDVOSB-certified for federal logistics work?

Yes. VooStack is a Service-Disabled Veteran-Owned Small Business, certified through SBA's VetCert. That makes us eligible for SDVOSB set-asides and sole-source awards under FAR 19.14. We've worked on logistics and supply chain modernization aligned with DoD, DLA, and TRANSCOM-style requirements. If you're a prime looking for a qualified sub on a logistics IT vehicle, or an agency planning a set-aside, we can move quickly through the contracting paperwork.

→ What does AI integration actually look like in a freight context?

Useful, not magical. Concrete patterns we've shipped: classifying inbound carrier emails and parsing rate confirmations into TMS records, RAG over SOPs so dispatchers get instant answers on accessorial rules, anomaly detection on dwell times and on-time-in-full, and LLM-assisted exception triage that drafts the carrier email before a human sends it. We avoid autonomous agents touching dispatch or billing — humans approve writes. The ROI is hours saved per dispatcher per day, measured.

→ How do you staff engagements — onshore, cleared, or hybrid?

All US-based senior engineers. No offshore handoffs, no junior bench. For commercial logistics work we typically run a 2–4 person pod: a tech lead, one or two senior engineers, and a part-time architect. For federal work we can staff cleared personnel (Secret and above) depending on the contract. Engagements run as fixed-scope sprints or staff augmentation against your existing roadmap — whichever fits how your team already operates.

→ How fast can you stand up a new EDI trading partner?

If your VAN and mapping infrastructure already exist, a standard 850/855/856/810 partner is typically 2–4 weeks including their certification process — most of that is waiting on the partner, not engineering. If you're starting from nothing, we'll stand up the AS2 or VAN connection, mapping engine (we've used SPS, Cleo, MapForce, and custom), and monitoring in 4–8 weeks, then add partners in parallel.

→ What goes wrong most often in TMS implementations?

Three failure modes, in order: rate engine assumptions that don't match how your carriers actually bill (fuel surcharges, accessorials, tariff exceptions), integration timeouts during peak that nobody load-tested, and exception workflows designed by a consultant who never sat next to a dispatcher. We push back on all three early. The TMS vendor's reference architecture is a starting point, not a plan — your lanes and customer mix dictate the real design.

→ Do you work with smaller 3PLs or only enterprise shippers?

Both. A regional 3PL running 20–100 trucks has the same integration problems as a Fortune 500 shipper — fewer partners, but tighter margins and less tolerance for waste. We've built lightweight TMS extensions, customer portals, and EDI middleware for 3PLs that didn't want a six-figure platform license. The packages page lays out fixed-scope options; for anything custom we'll scope it in a 30-minute call before quoting.

[004 / 005] Adjacent Files

Continue recon.

REL-01

All Services

Custom development, AI integration, modernization, and staff augmentation across regulated industries.

 REL-02

Case Studies

How we've shipped EDI, WMS, and tracking integrations under real production load.

 REL-03

Fixed-Scope Packages

Defined engagements for EDI onboarding, TMS extensions, and tracking portals.

 REL-04

Start a Conversation

30-minute scoping call with an engineer who's done this before — not a sales rep.
[ NEXT ACTION ]

Your peak season is closer than your roadmap thinks. Let's talk.

Talk to a VooStack operator. We respond within one business day.

Open a Channel Full Services