VMTech
Discuss a project →
← All capabilities
OPERATIONS & COMMUNICATIONS · 13

Delivery automation

Delivery does not break on the road — it breaks when data is handed over: the address retyped with an error, the weight guessed, the status never returned to the system. That is an engineering problem, not a logistics one.

Discuss a project
EXCHANGE WITH THE CARRIER

What goes to the courier and what comes back

Six exchange steps, where a failure must leave the system in a state you can reason about.

shipping.vmtech.rs
Shipment #RS4821
LIVE
the totals agree
Rate request 390 RSD
Address validation address complete
Creating the shipment RS4821···
The carrier is down queued
Statuses return in transit
Returns and reconciliation the totals agree
EXCHANGE WITH THE CARRIER
  1. Rate requestThe price is requested by zone, weight and size at checkout rather than averaged
  2. Address validationRequired fields and format are checked before sending — no “the house behind the shop”
  3. Creating the shipmentThe request goes to the carrier with an idempotency key: a retry does not create a second parcel
  4. The carrier is downThe job queues and retries; the order shows as “awaiting shipment” instead of vanishing
  5. Statuses returnCollected, in transit, delivered or refused — they reach the order and the customer by SMS
  6. Returns and reconciliationA refusal puts stock back, and cash on delivery is reconciled against the carrier's report
A FAMILIAR PICTURE

Where delivery actually breaks

Manual handover

  • The address is retyped into the carrier's portal, and the typo surfaces at the customer's door
  • Weight is estimated by eye, so the carrier's invoice regularly differs from the calculation
  • After a glitch the employee creates the shipment again — and two parcels travel
  • The parcel status lives in the carrier's portal and never reaches the system
  • Cash on delivery is reconciled monthly, by which point a discrepancy is untraceable

The exchange is wired

  • The address moves from the order untouched, and its completeness is checked at checkout
  • Weight and size come from the product records, so the invoice matches the calculation
  • A repeated request with the same key returns the same shipment instead of creating another
  • Statuses arrive in the order automatically and are forwarded to the customer
  • The carrier's report is matched to orders: what is paid, returned and still in transit
SCOPE OF WORK

What the work covers

Shipment model

Order and shipment are separate entities: a parcel has its own lifecycle and statuses.

Rate logic

Zones, weight, dimensions, surcharges and free-delivery rules in one configurable place.

Carrier connections

Integration with one or several carrier APIs behind a single internal interface.

Carrier selection

A rule by zone, weight and cost, with a manual override for exceptions.

Documents

Batch waybills, the shift's dispatch list and printing without manual entry.

Statuses and notifications

Receiving carrier statuses, updating the order and notifying the customer by SMS or email.

Returns

Refusals and failed deliveries put stock back and change the status without manual edits.

Report reconciliation

Matching the carrier's report to orders: cash on delivery, rates and returns.

TECHNOLOGY LANDSCAPE

What makes the exchange reliable

Carrier APIsRates, shipment creation, document printing and statuses
A common interfaceInside the system carriers look alike — adding one does not mean rewriting the logic
Idempotency keysA retried request does not create a second parcel for the same order
Job queueA carrier outage neither blocks the store nor loses orders
Exchange logWhat was sent and what the carrier replied — per shipment
ReportingTimes, returns and cost per route from your own data rather than carrier promises

Contracts and rates with the carriers stay on your company's side. We are responsible for data moving without distortion and for discrepancies being visible immediately.

QUESTIONS

What people usually ask

The courier's invoice does not match our calculation. Why?

Usually weight and dimensions: if the product records do not carry them, checkout uses an approximation while the carrier bills the actual figure. We tie the calculation to real product data and surface differences in a report, so the gap does not appear only at month end.

Can several carriers run at once?

Yes, and it usually pays off: different routes and weights are cheaper with different carriers. Inside the system they look alike, so adding one does not require rewriting the store's logic, and the selection rule is configured by zone, weight and cost.

What about parcels nobody collected?

The carrier sends them back, and that needs its own scenario: stock returns to the warehouse, the order moves to a returned status, and the cost of the return leg enters the report. Otherwise stock drifts and the cost of returns stays invisible.

How is cash on delivery reconciled?

Against the carrier's report rather than the bank statement: the money arrives as one sum per period and the individual orders have to be identified inside it. We match the report to shipments automatically and list what does not reconcile — usually returns and parcels not yet handed in.

What if a carrier has no API?

Then file exchange remains: exporting shipments in the carrier's format and importing statuses back. It is less convenient but still better than manual entry: addresses are not mangled and statuses reach the system. We flag such a limitation before the work starts, not after.

Related capabilities

Delivery automation The full service Online store Where the shipment comes from API integrations How the exchange works SMS campaigns Statuses to the customer

Let’s apply this capability to your project

We define the challenge, dependencies and a realistic delivery plan.

Discuss a project