ESA Order Processing

The ESA/EFS order workflow — customer ID lookup by program, net-30 terms, bundle-aware processing, and how orders flow from the RS sync into program buckets.

How ESA/EFS orders get processed: resolve the program to its RepairShopr customer ID, apply net-30 terms from the ticket date, decompose bundles into component line items, and route the result into the right program bucket off the master order list.

Resolve the program to a customer ID

Every ESA/EFS program maps to a single RepairShopr customer ID. The processing flow starts by resolving the program name to that ID, because the master order list is bucketed on it.

The programs currently in play:

  • Odyssey Iowa
  • Tennessee Portal
  • Odyssey Georgia
  • Odyssey Louisiana
  • Odyssey Utah

The authoritative ID for each lives on Customer ID Mapping — don’t duplicate the table here, because it drifts when a new program comes online. Look it up there.

Payment terms

All ESA programs are net-30 from ticket_created_at. The due date is computed from the ticket creation timestamp, not the invoice creation date. If a due date looks off by days, check which timestamp it was derived from first.

Bundle-aware processing

ESA orders frequently arrive as bundles — a single ordered SKU that represents several physical components. Processing resolves each bundle into its component line items before fulfillment, so the order, the shipment, and the invoice all reflect the actual components rather than the bundle placeholder.

The native module (below) owns bundle definitions and the component split. When a bundle resolves wrong, the fix is in the bundle definition, not in the order itself.

How orders flow into program buckets

RS ticket sync  →  master order list CSV  →  join on customer ID  →  program bucket
  1. The RS ticket sync runs hourly and writes the master order list to the exports dir on nvrbackup.
  2. The list is joined on RepairShopr customer ID to bucket each order by program.
  3. Each program bucket is processed under that program’s net-30 terms with bundle resolution applied.

If a new ESA program comes online, it has to be added to the RS customer record, the mapping the processor consumes, and the Customer ID Mapping page. Miss any one and its orders won’t bucket.

The native module

The order intake/fulfillment side — pulling marketplace order emails, parsing them, resolving bundles, and creating ShipStation orders and RS tickets — is handled by the native ESA Order Processor module that replaced the old Pabbly workflows. It’s bundle-aware, multi-platform, and lives in the Leif repo.

For the module’s architecture, supported platforms, and operational scripts, see ESA Order Processor.