Fashion Logistics runs an unusual split with AIMS360: dropship retailer EDI goes through AIMS360, while brick and mortar retailer EDI is handled at the warehouse. Ship orders, shipment confirmations and inbound advice are live. Receipts, adjustments, catalog and returns are in testing.
This connection does something none of the others on our list do. Dropship retailer EDI runs through AIMS360 in the normal way, while brick and mortar retailer EDI is handled at the warehouse instead. It is an unusual arrangement, it suits a particular kind of brand, and it is worth understanding before you copy it or reject it.
On most connections AIMS360 performs all retailer EDI and the warehouse never touches a retailer document. On this one the work is split by channel. Dropship orders, where a retailer sends a consumer address and the parcel goes to a shopper, run their EDI through AIMS360. Brick and mortar orders, the bulk shipments going into a retailer's distribution center, have their EDI handled at the warehouse.
Both paths end in the same place, which is the point. The stock record is one record. Allocation, costing, margin and the order book do not fork because the paperwork took two routes.
Bulk retail EDI is the harder half: routing guides, carton labeling, must arrive by dates, ASN accuracy, chargeback exposure. A brand with a small team may prefer that sitting with the operator who is physically building the pallets.
A dropship order is a consumer order wearing a retailer's paperwork. It has to allocate, screen, route and confirm exactly like a Shopify order, so keeping it in the ERP keeps one consumer fulfillment path rather than two.
Two EDI paths means two places a compliance failure can originate. Agree in writing who owns routing guide updates, who is liable for chargebacks and who talks to the retailer when a spec changes.
If you later move the retail EDI back into AIMS360, the retailer relationships and trading partner setups move with it. Worth knowing the shape of that before you need it, not after.
We are describing this rather than recommending it. For most brands the simpler answer is that AIMS360 does all of it, because one system owning every retailer document means one place to look when a retailer changes a spec. This page exists because the split is real, it works, and a buyer comparing warehouses deserves to know it is an option.
Three warehouse documents are live in production. Four more are configured and in testing. We are publishing the status column because a partner page that lists capability without status is how buyers end up surprised after go live.
| Message | Direction | Status | What it carries |
|---|---|---|---|
| 940 | AIMS360 to warehouse | Live | The ship order, serving as order or pick ticket depending on a system setting, with the pick number and the customer purchase order |
| 945 | Warehouse to AIMS360 | Live | Shipment confirmation with carton detail, weights and tracking. The carton structure is what lets AIMS360 generate a retailer 856 |
| 943 | AIMS360 to warehouse | Live | Inbound advice. What is arriving from production or another location and what to expect on the container |
| 944 | Warehouse to AIMS360 | In testing | The receipt, posting against the open purchase order or return line |
| 947 | Warehouse to AIMS360 | In testing | Inventory adjustment for damages, cycle count corrections and found stock |
| 832 | AIMS360 to warehouse | In testing | The product catalog, so receiving is not guessing at a SKU |
| Returns | Warehouse to AIMS360 | In testing | Consumer and retailer returns coming back into stock or into a hold position |
What live means in practice: you can send orders and get confirmed shipments with carton detail back, and you can tell the warehouse what is inbound. What in testing means: receipts, adjustments and catalog updates are being validated and should be treated as a planned capability rather than something to build a process on this quarter. Ask us for current status when you scope, because this list moves.
Last reviewed 15 August 2026 by the AIMS360 integrations team.
Status reviewed against the AIMS360 production configuration for this partner. Documents marked in testing are configured and being validated, and are not represented as live.
Worth separating two things that get confused. Your 3PL does not need to support EDI at all. AIMS360 performs the retailer side itself: the 850 comes in, and the 855, 856 and 810 go back on the retailer's routing guide spec, with no separate EDI provider or translator to buy. The warehouse connection is a different job and runs on whatever the warehouse can do, whether that is an API, CSV, tab delimited files, XML or real X12. Several of our busiest warehouse connections exchange no X12 at all.
That is the default and it is what most brands should want, because one system owning every retailer document means one place to look when a spec changes and one party accountable for a chargeback.
Fashion Logistics is the exception that shows the model bends the other way too. Where a warehouse already runs retailer EDI competently and a brand would rather it stayed there, AIMS360 does not insist on taking it over. It keeps the dropship channel, which behaves like consumer fulfillment, and leaves the bulk retail channel where the operator wants it. The rule is that the arrangement should follow your team and your warehouse, not your software's limitations.
On other partner pages this section lists facilities, square footage, staff and services, attributed to the operator's own website. We cannot do that here honestly.
Fashion Logistics publishes very little publicly. Their website is a short brochure and its interior pages did not reliably serve when we checked in August 2026. Company directories carry conflicting figures on headcount and founding year, and directory data is not a source we will repeat as fact. So rather than pad this page with numbers we cannot stand behind, here is the honest position: we can speak to the integration because we run it, and you should get everything else from the warehouse directly.
Ask them, in writing, for the things that decide a fulfillment contract: which facilities would hold your goods, total and available square footage, whether they handle garment on hanger, whether they do retailer ticketing and steaming, which carriers they tender to, which retailer compliance programs they have live experience with, and what their inventory accuracy and on time shipping numbers have been for the last twelve months. Any warehouse worth signing will answer all of that.
Four documents are in testing, not live. Receipts, inventory adjustments, the product catalog and returns are configured and being validated. Until they are live, receiving and adjustments involve manual steps, so scope the work assuming today's status rather than the finished list.
There is no periodic inventory snapshot on this connection. Scheduled position to position reconciliation is something you would arrange with the warehouse rather than something the integration performs.
The split EDI model needs an owner. Because retail EDI sits at the warehouse, routing guide changes, carton label specs and chargeback disputes have to have a named owner on their side and yours. Write it into the agreement rather than discovering it during a compliance failure.
Yes. Ship orders go out, shipment confirmations with carton detail come back, and inbound advice goes out, all live in production. Receipts, inventory adjustments, the product catalog and returns are configured and in testing rather than live. The connection also runs an unusual split where dropship retailer EDI goes through AIMS360 while brick and mortar retailer EDI is handled at the warehouse.
For most brands the ERP should, because one system owning every retailer document means one place to look when a retailer changes a spec and one party accountable when a chargeback lands. AIMS360 performs retailer EDI itself with no separate provider to buy. The case for leaving it at the warehouse is a small team plus an operator who already runs retailer EDI well, since bulk retail compliance is physical work: routing guides, carton labels, must arrive by dates. If you do split it, name the owner of routing guide updates and chargeback liability in the contract.
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 the 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. Several of our busiest warehouse connections exchange no X12 at all.
A dropship 850 carries a consumer address and produces a parcel to a shopper, so from allocation onwards it behaves like a Shopify order and belongs on the consumer fulfillment path. A brick and mortar 850 produces bulk goods going into a retailer's distribution center, where the compliance work is physical: carton labels, pallet build, routing guide adherence, must arrive by dates and an advance ship notice that matches the truck. The second is where chargebacks come from, which is why who owns it matters.
Because this operator publishes very little, and the figures that appear in company directories conflict with each other. We are not going to repeat unverified numbers as fact on our own site. We can speak to the integration because we run it. For facilities, capacity, apparel handling, carriers and performance history, ask the warehouse directly and get the answers in writing.
Yes. In AIMS360 every physical location is a warehouse on the same stock record, including your own building, your retail stores and each 3PL. Inventory templates decide what each location can sell and routing decides where an order ships from. Given that four documents on this connection are still in testing, running a second warehouse alongside it is a reasonable way to stage a move rather than a complication.
Bring your retailer list and your team size. We will walk through which documents belong in the ERP, which can sit at the warehouse, and what it costs to change your mind later.
