AIMS360 connects CommerceHub dropship natively over EDI and routes each order to the warehouse or 3PL that actually holds the units. The ship notice and the invoice are built from what the warehouse confirms, so your 3PL never needs EDI of its own.
A CommerceHub dropship program puts the retailer's consumer order in your hands and gives you a day or two to get a single box out the door. AIMS360 takes the order in as an 850, sends the pick to whichever warehouse actually holds the units, whether that is your own building or a 3PL, and builds the ship notice and the invoice from what the warehouse confirms. The warehouse never sees a retailer document, so it does not need EDI of its own.
Natively, over EDI, from the same order and inventory record that runs your bulk retail accounts. Four transactions carry the work: the 846 inventory advice publishes your catalog and availability, the 850 purchase order brings each consumer order in, the 856 advance ship notice reports the shipment, and the 810 invoice bills it. There is no connector sitting beside the ERP holding a second copy of your stock.
What makes dropship different from bulk wholesale is not the document set, which is smaller. It is that the retailer has already sold the item to a consumer before you know the order exists. There is no purchase order acknowledgment step to negotiate, no routing request, no carton hierarchy and no pallet label. Dropship trades all of that for one obligation you cannot get wrong, which is keeping availability honest, and one clock you cannot miss, which is the ship by date on a single box.
The practical consequence is that the interesting question is rarely whether a system can parse an 850. It is what happens between the order landing and the tracking number going back, particularly when the goods are not in your building.
Most brands running a dropship program do not hold the goods themselves, or do not hold all of them. This is the part of the chain that decides whether the program is a background process or a daily chore.
| Step | What moves, and which way |
|---|---|
| 1. The order arrives | The retailer sends an 850 with the shopper's address in the ship to. AIMS360 imports it against the customer account for that program, alongside your wholesale, bulk EDI and ecommerce orders in one order queue. |
| 2. AIMS360 picks the location | The order is assigned to the warehouse that holds the units. That can be your own building, a retail store, or a 3PL, and allocation rules settle it when a bulk order wants the same size. |
| 3. The warehouse gets a ship order | A pick ticket goes out as a 940 warehouse shipping order: what to ship, to whom, by which carrier, packed to the retailer's rules. On an API warehouse the same event is an order push rather than a file. |
| 4. The warehouse confirms | A 945 warehouse shipping advice comes back with carton detail, weights and the tracking number. That single document is what the ship notice and the invoice are both built from, so they cannot drift apart. |
| 5. The retailer is told | AIMS360 sends the 856 and the 810. These are retailer documents, built by the ERP. The warehouse never sees them. |
| Alongside | Inbound production is announced with a 943 and receipted with a 944, count variances come back on a 947 with a reason code, the item master goes out as an 832 style catalog, and every file is acknowledged with a 997. |
Order processing and shipment processing run as two scheduled workflows. You choose which transactions to automate and how often each one runs, down to the days of the week and the interval in hours and minutes.
New 850s are downloaded from the connected file transfer on a schedule and imported to the purchase order module. The same setting handles the outbound direction, pushing any new EDI document that is waiting to go out.
Dropship order processing creates the order and the pick ticket and sends it to the fulfillment end. An order that fails validation is held with the reason rather than lost, and re-run once the cause is cleared.
Two workflow templates ship with the product. One sends the 856 alone and still creates the invoice inside AIMS360. The other sends the 856 and the 810 together. Pick the second unless the retailer takes invoices some other way.
Availability publishing runs on its own schedule, separate from orders, so the retailer's site is reading a current number rather than last night's.
Shipment confirmations from a 3PL are imported on a schedule of their own. Stagger it off the hour, fifteen minutes past rather than on the hour, so it is not competing with the order sync for the same window.
Every step in the chain has a manual equivalent in the same modules. Automation is a scheduler on top of the process, not a separate one, so a day when something upstream is broken is a slower day rather than a stopped one.
This is the single most common way a CommerceHub onboarding goes wrong in week one, and it is entirely avoidable.
The inventory advice does double duty. It publishes availability, and it is what builds the items inside the CommerceHub portal in the first place. Loading a CSV into the portal by hand creates a second set of items that the 846 then cannot match, and untangling that costs more than the setup it was meant to skip.
AIMS360 builds a unique identifier for each sellable item from the style number, the color code and the size name, for example CS4006PJ_BLK_S. That identifier and the UPC together create the product in the portal, which is what a consumer facing site needs and what a flat style list cannot give it.
The number published is available to sell with open orders and allocations netted out, calculated per location. Raw on hand is the number that oversells, because it has not met your bulk commitments yet.
Department store dropship programs generally take wholesale cost and retail from the 846 rather than from anything keyed into the portal, with the prices themselves negotiated between the buyer and your sales rep. Confirm the specifics for your own program during onboarding.
Worth settling before go live, because the difference decides which parts of the program need a person watching an inbox.
| Transaction | What it does | Status |
|---|---|---|
| 846 inventory advice | Publishes the catalog and the availability the retailer's site sells against. Runs on a schedule. | Integrated |
| 850 purchase order | One consumer order, with the shopper's address in the ship to. | Integrated |
| 856 advance ship notice | What shipped, in which carton, with the tracking number. | Integrated |
| 810 invoice | Generated from what actually shipped, so the order, the shipment and the invoice agree. | Integrated |
| 860 purchase order change | The retailer changes or cancels an order after sending it. | Document only |
| 820 payment remittance | What the retailer paid and against which invoices. | Document only |
| 180 return notification | A consumer return heading back under the retailer's returns policy. | Document only |
Document only means it arrives readable rather than as an integrated transaction, so somebody acts on it rather than the system posting it. Nobody enjoys hearing that, but it is better heard in an evaluation than discovered in week three. The rest of the retailer document set, including acknowledgments and the bulk wholesale transactions, is covered on native EDI.
Rithum is the company. CommerceHub is still the operational brand across much of it, with live supplier portals, single sign on, file transfer hosts and product names including OrderStream. Dsco kept its own product and its own login. They are separate connections with separate onboarding.
Stated plainly, because these are the questions that surface in month two rather than in the demo.
| Constraint | Detail |
|---|---|
| Multi warehouse has to be on | Dropship automation routes orders to a location, so multi warehouse is a prerequisite rather than an option. A single location brand can still run the program, but the scheduled chain expects locations to exist. |
| Automation is for dropship only | The scheduled order and shipment workflows apply to dropship orders. Bulk orders shipping to a distribution center or a cross dock keep their own process, with routing requests, carton hierarchy and pallet labels that a single consumer box does not have. |
| Outside EDI providers break the chain | The automation is built on AIMS360 EDI. If your EDI is handled by an outside provider, the pick ticket export and the shipment import still run but the sync, the 850 import, picking, the ASN file, invoicing and the outbound sync go back to manual. The EDI dropship page lists the split step by step. |
| Something has to confirm the shipment | Unattended shipment processing needs an integrated warehouse, a partner warehouse API or a connected shipping application. A warehouse that emails a spreadsheet at the end of the day can still be connected, but it is a file import on a schedule rather than a live confirmation. |
The availability the retailer's site is selling against is the same number your bulk allocations, your warehouse and your other channels are working from. That is the whole argument, and it shows up when things are busy.
A connector sitting beside the ERP has to be told what your stock is. That second copy is what eventually oversells, and it never picks a quiet week to do it.
Cartons on a pallet for a distribution center and single boxes to consumers come out of the same stock, with the compliance work applied only to the program that needs it.
The retailer side never moves, because it never left the ERP. Swapping a warehouse is a warehouse project, not an EDI recertification. The 3PL fulfillment guide covers how to pick one.
The ERP, the retailer EDI and the warehouse connection are the same system and the same implementation team, so a failure during a peak week is one conversation rather than three.
What brands ask when a retailer puts them on a CommerceHub dropship program.
Yes. The connection is native EDI inside AIMS360, with no separate middleware subscription between the ERP and the retailer. Four transactions are integrated: the 846 inventory advice that publishes your catalog and availability, the 850 purchase order that brings each consumer order in, the 856 advance ship notice that reports the shipment, and the 810 invoice. Orders land in the same queue as your bulk retail EDI and your other channels, reading the same stock record.
Yes, and this is the most common setup. The retailer's order arrives in AIMS360 as an 850, AIMS360 creates the pick ticket and sends it to whichever location holds the goods, and the warehouse confirms the shipment back with cartons, weights and tracking. AIMS360 builds the 856 and the 810 from that confirmation and sends them to the retailer. The warehouse never touches a retailer document, so the 3PL does not need to know anything about CommerceHub.
No. Retailer EDI and warehouse integration are two different jobs and only the retailer side has to be EDI. AIMS360 performs that side itself. The warehouse side runs on whatever the warehouse can actually do: a REST API, a CSV file, a tab delimited file matching its platform's native import template, AIMS360 XML, or real X12. Several of the busiest warehouse connections on the platform exchange no X12 at all. A warehouse with a clean API is easier to integrate than one with EDI, not harder.
Four are integrated and move as data: the 846 inventory advice, the 850 purchase order, the 856 advance ship notice and the 810 invoice. Three more arrive as documents rather than integrated transactions and are read by a person: the 860 purchase order change, the 820 payment remittance and the 180 return notification. Knowing which is which before go live saves an argument about why a change order did not update itself.
Through the 846, not through the portal's spreadsheet upload. AIMS360 sends the 846 from your style master and CommerceHub creates the products from it. Each item carries a unique identifier built from the style number, the color code and the size name, for example CS4006PJ_BLK_S, and that identifier is used together with the UPC to create the product in the portal. Loading a CSV into the portal first is what creates the duplicate item problems that take weeks to unpick.
The 846 publishes available to sell rather than units on hand, calculated per location, with open orders and allocations already netted out. A pallet committed to a bulk retail order this morning is out of the number the retailer's site sees this afternoon. The 846 can run on a schedule you set, down to the day of the week and the interval. On dropship a stale number does not create a backorder the way it would in wholesale; it creates a canceled consumer order, and cancellation rate is what the retailer scores you on.
Rithum is the company. CommerceHub is still the operational brand for a large part of it, with live supplier portals, single sign on, SFTP hosts and product names including OrderStream. Dsco is the exception: it kept its own product, its own login and its own documentation. They are separate programs with separate onboarding, so being live on one does not make you live on the other. The Rithum page walks through which product you have actually been offered, and the Dsco page covers Dsco on its own.
Yes, if the pieces are in place. Order processing and shipment processing run as scheduled workflows: the sync downloads new 850s, dropship orders are created and picked, and once the shipment confirmation comes back the 856 and the 810 go out. It needs an integrated warehouse or shipping application on the fulfillment end, which can be a 3PL or warehouse management system, a partner warehouse on the Bergen API, or ShipStation.
Three things. Multi warehouse has to be active, because the automation routes to a location. The fulfillment end has to be an integrated warehouse, a partner warehouse API or ShipStation, since something has to report the shipment back. And the EDI has to be AIMS360 EDI rather than an outside provider. Automation is also scoped to dropship orders only; bulk orders shipping to a distribution center or a cross dock are not part of it.
Yes. With the ShipStation account configured and the trading partner set to send pick tickets to it automatically, the dropship chain completes through ShipStation and the AIMS360 shipment processing modules. It is one of the three fulfillment ends the automation supports, alongside an integrated 3PL or warehouse management system and a partner warehouse API.
Not end to end. Dropship automation is built on AIMS360 EDI. With an outside provider the pick ticket export to your shipping app, the shipment import back and the shipment creation still run, but the EDI sync, the 850 import, picking, generating the ASN file, invoicing and the outbound sync go back to being manual. That is six manual steps per batch, every day, which is the usual reason brands move EDI in house once dropship volume climbs. The EDI dropship page has the full split.
Yes, and at most department stores that is the normal setup. They are separate programs with separate onboarding and separate performance records, drawing on one inventory pool. AIMS360 runs both from the same record, with allocation rules deciding which program gets the units when they compete for the same size.
Usually the retailer, on its own carrier account. When the retailer supplies a UPS or FedEx account number, the customer account is set to freight collect for dropship orders and the carrier tracking number is used as the bill of lading number on the shipment. Ship methods are mapped to the retailer's own transport codes in a cross reference, so the right service level goes out on each order.
The consumer returns to the retailer's rules, and the return notification arrives as a document rather than an integrated transaction, so it is read and entered rather than posted automatically. Return instructions print on the packing slip from codes carried on the 850 itself, so there is no separate return code table to maintain. Anything physically coming back to you is received against the original order through returns management.
Last reviewed 16 September 2026 by the AIMS360 EDI team. Transaction scope, catalog behavior and automation prerequisites reflect the AIMS360 CommerceHub dropship configuration as of that date and are confirmed for your program during implementation. Retailer programs, portal requirements and document sets change, so confirm current specifics with your retailer and with Rithum. Product and company names belong to their owners.
Name the retailer and name the 3PL. We will show you the order landing, the pick going out to that warehouse, the confirmation coming back, and the ship notice and invoice leaving, on one stock record with your bulk orders running alongside.
