TMS, WMS and ERP: distinct responsibilities
A WMS owns stock locations, replenishment, picking, packing and receiving inside a facility. An ERP typically owns orders, customer accounts, procurement and financial records. A TMS coordinates transportation commitments: a load, its carrier, stops, appointment windows, movement events and delivery evidence. Each system needs a reliable reference to the others, not a duplicate copy of every business rule.
Kaporeal is not intended to replace inventory control or serve as a turnkey ERP. Its warehouse direction is interoperability: preserve the order, shipment and handling-unit references that make a handoff explainable, while leaving quantity availability, picking logic and financial posting with their authoritative systems. This boundary matters most when operators investigate exceptions across organizations.
Outbound: ready to ship is not departed
PlannedOutbound fulfillment begins in the warehouse. An order is picked, packed and staged, and the WMS supplies a ready-to-ship signal with facility, requested window, package or pallet references and freight attributes. The TMS would use that context to create or associate a load, arrange a carrier and coordinate an appointment. Readiness must not be inferred from a carrier assignment.
The proposed sequence is warehouse-ready → tender → dock scheduled → arrived → loaded → departed → received → POD. Every transition describes a different fact. A dock arrival does not confirm loading, and a signed BOL does not establish destination receipt. Shared identifiers and timestamp provenance allow both systems to reconcile these facts without collapsing them into a single ambiguous status.
- Readiness exchange: shipment reference, facility, handling units and requested window.
- Transportation response: load reference, assignment context and proposed appointment.
- Departure exchange: observed departure, freight references and document linkage.
- Receipt exchange: receiving outcome, exception details and proof of delivery.
Inbound receiving needs transportation context
Receiving supervisors plan labor, space and dock capacity around expected arrivals. A transportation update is useful when it identifies the shipment and stop, distinguishes an ETA from an observed arrival and supplies a reason for a changed expectation. Raw vehicle coordinates alone do not tell the receiving team which inbound order is affected.
An advance shipment notice could provide expected goods and handling-unit references, while a TMS event supplies the movement context. The planned exchange should allow receiving to report shortages, overages or damage against the same references. The warehouse remains responsible for inventory receipt; transportation retains the arrival, delivery and evidence trail.
Handling units, cross-docking and exceptions
Pallet, case and other handling-unit identifiers make a physical handoff traceable without requiring the TMS to model every warehouse location. Proposed linkage should retain the identifier's source and avoid assuming that a pallet count is interchangeable with a piece count. Splits, repacking and consolidated loads create relationships that need explicit treatment in later modeling.
Cross-docking adds another boundary: freight received at an intermediate facility may leave on another movement without entering long-term storage. A future model should distinguish inbound receipt, transfer readiness and outbound departure. Shortage or damage messages should capture the affected reference, observed quantity, evidence and responsible review owner, rather than overwrite the original shipping declaration.
- Appointment conflicts: preserve requested and accepted windows separately.
- Short loading: reconcile declared and observed handling units.
- Damage: link evidence to the handoff and affected freight reference.
- Missed departure: report the exception without claiming inventory moved.
Proposed standards, negotiated semantics
PlannedANSI X12 940 and 945 may be relevant to warehouse shipping orders and shipping advice, while 204 and 214 concern transportation tenders and status. An ASN can arrive through another EDI transaction or a partner-specific API. The transaction number does not remove the need to agree on identifiers, qualifiers, time zones and acknowledgement behavior.
The project has no verified EDI implementation or vendor-specific WMS connector. Useful early collaboration would provide anonymized handoff examples, responsibilities and exception cases. An adapter should be designed against a real partner contract, with replay, validation and reconciliation considered before any claim of plug-and-play compatibility.
