Every direct to consumer channel, EDI dropship, Shopify and marketplaces, fulfilled from wherever the unit sits: your own warehouse on AIMS360 WMS, a retail store back room, several warehouses at once, or your 3PL. Allocation, fraud screening, address verification, routing, tracking and partial shipments all run automatically.
An EDI dropship order from a retailer, a Shopify order from your own storefront, a marketplace order: all three arrive by different routes and all three end the same way, picked somewhere and tracked back to the customer. That somewhere can be your own warehouse, a store back room, one of several warehouses, or your 3PL. In AIMS360 the path is the same and nobody is standing in it.
In AIMS360 every physical location is a warehouse. Your distribution center is a warehouse. Each retail store is a warehouse. A 3PL is a warehouse. A showroom is a warehouse. Because they are the same kind of object, the automation that runs a consumer order does not change when the order ships from a different place, and adding a location does not mean adding a second fulfillment process next to the first.
The order becomes a pick ticket. Pickers work from mobile scanners against bin locations, one picker pulls for several orders in a zone and the system consolidates, packing confirms by scan, the carrier label prints, and the tracking number goes back to the channel. Cycle counts and stock adjustments post to the same record the storefront sells against.
A size that sold out in the distribution center but sits in a store back room is still sellable online, and the pick happens where the unit is. Store staff work the same scanner flow. Back room to sales floor movements are tracked, and minimum stock levels per location trigger replenishment from the distribution center rather than someone noticing.
Inventory templates decide what counts as sellable for a given location: its own stock only, or the distribution center too, or incoming production up to a chosen date. Wholesale and EDI commitments come out before the storefront ever sees a number, so the consumer channel is not selling goods that are already promised to a retailer.
The order leaves as a ship order and the confirmation comes back with cartons, weights and tracking. Whether that travels as an API call, a CSV, a flat file or genuine EDI depends on the warehouse, not on you. Eighteen warehouses are already connected and a warehouse that is not on the list connects the same way.
Most brands run more than one of these at the same time, which is the real point. A store, a distribution center and a 3PL can all be live in the same week, on the same stock record, feeding the same storefront.
Retailer EDI and warehouse integration are two different jobs, and only one of them has to be EDI. AIMS360 performs the retailer side itself: the 850 purchase order comes in, and the 855 acknowledgement, 856 advance ship notice and 810 invoice go back on that retailer's routing guide spec. There is no separate EDI provider, translator or subscription in between. The warehouse side is a different connection entirely, and it runs on whatever that warehouse can actually do.
We name the warehouse messages with the familiar numbers, 940 for a ship order, 945 for a shipment confirmation, 943 and 944 for inbound advice and receipt, 947 for an adjustment, 832 for the catalog, 846 for an inventory snapshot. That is shared industry vocabulary, not a statement about file format. Across our own partner list those messages travel as REST API calls, CSV files, tab delimited files matching a warehouse platform's native import template, AIMS360 native XML, and sometimes as real X12. Several of our busiest warehouse connections exchange no X12 at all.
| The assumption | What is the case |
|---|---|
| Our 3PL has no EDI, so we cannot automate fulfillment | The warehouse connection can be API, CSV, tab delimited, XML or flat file. EDI capability at the warehouse is optional |
| If we use a 3PL we lose retailer EDI compliance | Retailer EDI stays in AIMS360 and is unaffected by where the goods sit. The warehouse never touches a retailer document |
| A 940 means an EDI file | A 940 means a ship order. How it travels is a transport decision made per warehouse |
| We need an EDI provider as well as the ERP | AIMS360 is the EDI. There is no translator or second subscription in between |
| Modern ecommerce 3PLs are ruled out because they only have an API | An API is easier to integrate than EDI, not harder. It is warehouses with neither that are the problem |
This matters more than it sounds. If your ERP insists the warehouse must be EDI capable, your shortlist quietly shrinks to warehouses that have already built EDI, which excludes a large share of the modern ecommerce 3PLs, the ones with a clean API and no X12 at all. You would be ruling out good operators for a technical reason that has nothing to do with how well they pick, pack and ship. The same applies in reverse when you change warehouses: the retailer side does not move, because it never left.
Seven things have to happen to a direct to consumer order before a carton leaves a building. In most operations at least three of them are somebody opening a spreadsheet. In AIMS360 all seven run automatically, and the exceptions are what surface for a person rather than the routine.
| Step | What runs | Why it is usually manual elsewhere |
|---|---|---|
| 1 | Order capture from Shopify, an EDI 850 dropship order, or a marketplace | Different channels land in different systems, so somebody rekeys or exports |
| 2 | Allocation against stock on hand, or against production still in progress | Allocating against a cut ticket that has not landed yet needs the ERP to know both |
| 3 | Location routing, choosing which warehouse, store or 3PL holds the unit | Routing lives in a spreadsheet, or every order ships from one place whatever the cost |
| 4 | Fraud screening and address verification, with failures held rather than released | Screening happens on the storefront and the result never reaches fulfillment |
| 5 | Release to the fulfilling location: a pick ticket to your own WMS, or a ship order to your 3PL in whatever format it accepts | Warehouses get emailed spreadsheets, or a portal gets keyed by hand |
| 6 | Pack and confirm: scanner confirmation in your warehouse, or the shipment confirmation back from the 3PL | Tracking arrives as a file somebody imports the next morning |
| 7 | Tracking pushed to the channel, so Shopify marks it fulfilled and emails the customer | The storefront stays unfulfilled until someone updates it |
Steps three and four are the ones brands underestimate. Routing badly costs freight on every order and nobody sees it because the cost is spread across thousands of parcels. A fraud flag that never reaches the warehouse means you shipped it. An unverified address means you paid twice, once out and once back, and refunded the customer anyway. All three are cheap to catch before the pick and expensive after.
Most order automation works until an order ships in two pieces. Then it breaks, because a partial shipment is not one event, it is a state that has to stay consistent across the warehouse, the ERP and the storefront at the same time. Split the order across two locations and it breaks sooner.
A customer orders three items. Two are in the bin, one is still on a cut ticket. Or two are in the distribution center and one is in a store. What should happen is that the available units ship now, the customer gets tracking for exactly those units, the storefront shows a partial fulfillment rather than a completed one, the balance stays allocated to that order, and when it lands it ships as a second shipment with its own tracking. What usually happens instead is that the whole order waits for the slow line, or it ships in two and the customer gets one tracking number covering goods that are not in the box.
AIMS360 confirms per shipment, whether the confirmation comes from a scanner in your own warehouse or from your 3PL. Each shipment updates the channel with its own cartons and its own tracking, so the storefront reflects what left the building rather than an approximation of it.
Available units release now rather than waiting behind the slowest line on the order.
The remainder stays allocated to that customer, against stock, against another location, or against the production run it is coming from.
Each shipment sends its own tracking to the channel, so the customer email matches the box.
The order stays a single order for margin, returns and service, however many boxes and however many locations it took.
Retailer EDI dropship. An 850 arrives from the retailer with a consumer address on it. AIMS360 turns it into a pick ticket or a ship order, and returns the 855, 856 and 810 to the retailer on their spec. The consumer gets the parcel, the retailer gets the documents, and the warehouse sees a normal order. The carton detail that comes back from the warehouse, or off the scanner in your own building, is what generates the 856.
Shopify and your own storefront. Orders import as they are placed, inventory syncs back, and fulfillment plus tracking is pushed to Shopify so the customer notification fires without anyone in the loop. One AIMS360 customer processed 1.2 million Shopify orders in a single day, and 1.25 million across all channels that day.
Marketplaces and everything else. Amazon, Farfetch and other channels follow the same allocation, screening, routing and release path.
Returns, in store and online. A consumer return can come back to a store or to the warehouse, restock into the location that received it, and produce the credit without anyone typing it twice. Apparel carries the highest return rate in retail, so the return path deserves the same automation as the outbound one.
Last reviewed 15 August 2026 by the AIMS360 integrations team.
Reviewed against the AIMS360 warehouse document set in production, the AIMS360 WMS location model, and the direct to consumer order flow across EDI dropship, Shopify and marketplace channels.
| The assumption | What is the case |
|---|---|
| DTC automation means a 3PL | The same automation runs against your own warehouse, your stores, several warehouses, or a 3PL. The fulfilling location is a setting, not a different product |
| You have to choose in house or 3PL | Both can be live at once, on the same stock record, with routing deciding per order |
| Ship from store needs its own system | A store is a warehouse. Store staff use the same scanner flow as the distribution center |
| Available to sell means what is on hand | Inventory templates net out wholesale and EDI commitments and can add incoming production to a chosen date, per location |
| Multiple warehouses needs a second platform | Locations are added, not systems. Stock, sales and margin report per location and in total |
| Partial shipments are an edge case | They are routine in apparel, and they are where most order automation quietly breaks |
Yes. The order imports from Shopify as it is placed, allocates against stock or against production, routes to the location holding the unit, passes fraud screening and address verification, and releases as a pick ticket to your own warehouse or a ship order to your 3PL. Confirmation comes back off the scanner or from the warehouse, and AIMS360 pushes fulfillment and tracking to Shopify so the customer notification fires automatically. The only orders a person sees are the ones that failed a check.
No. AIMS360 performs the retailer EDI itself, so the 850 comes in and the 855, 856 and 810 go back on the retailer's routing guide spec regardless of what your warehouse can do. The warehouse connection is separate and runs on whatever that warehouse supports: REST API, CSV, tab delimited files, XML, flat files, or real X12 if they have it. Several of our busiest warehouse connections exchange no X12 at all and their retailers still receive conformant advance ship notices. There is also no separate EDI provider or translator to buy, because AIMS360 is the EDI.
Yes, and the automation is the same. In your own building the order becomes a pick ticket, pickers work from mobile scanners against bin locations, packing confirms by scan, the carrier label prints and tracking goes back to the channel. The difference between your warehouse and a 3PL is where the confirmation comes from, not how the order is handled before or after it.
Yes. Every retail store is a warehouse in AIMS360, so a size that sold out in the distribution center but sits in a store back room is still sellable online and the pick happens where the unit is. Store staff use the same scanner flow, back room to sales floor movements are tracked, and minimum stock levels per store trigger replenishment from the distribution center.
Inventory templates define what counts as sellable for a given location: its own stock only, or the distribution center as well, or incoming production up to a chosen date, with wholesale and EDI commitments netted out first. Routing then picks the location that can serve the order, which is what keeps a store from selling goods already promised to a retailer and keeps freight from crossing the country unnecessarily.
Each shipment is confirmed separately, off the scanner in your own warehouse or on its own confirmation from a 3PL, and pushed to the channel with its own tracking. A customer who ordered three items and received two sees a partial fulfillment covering exactly those two. The balance stays allocated to that order, against stock, another location, or the production run it is coming from, and ships as a second shipment when it lands. The order remains one order for margin, returns and customer service.
Yes. Allocation can run against stock on hand or against units still in production, which matters for preorders and for drops where demand lands before the cut ticket does. The ERP has to know both the order book and the production position to do this, which is why it is uncommon outside apparel native systems.
It is held before it reaches the warehouse rather than after. Fraud flags and failed address verification stop the order from releasing, so it surfaces for review instead of being picked, packed and shipped. Catching it at that point costs a few minutes. Catching it after the carrier does costs the outbound freight, the return freight and the refund.
The middle of the path is identical. A dropship 850 from a retailer carries a consumer address, and from allocation onwards it behaves like any other direct to consumer order. The difference is at the retailer end: the 855, 856 and 810 go back to the retailer on their routing guide spec, while a Shopify order pushes fulfillment and tracking to the storefront instead.
Bring a real order, your locations and your channel mix. We will run it from capture to tracking without touching it, including one that ships in two pieces from two places.
