AIMS360 carries an apparel order from entry to invoice: allocation profiles across stock and work in process at size level, batch pick tickets, scan to verify, packing rules, carrier and UCC 128 labels, ASN and automatic invoicing.
Automated Order Processing
AIMS360 carries a wholesale or DTC order from entry to invoice without an operator working each step by hand. Orders are allocated against stock and work in process down to the size level, pick tickets are created in batch, goods are scanned against bin and UPC, cartons are packed to your rules, labels and ASNs are produced, and the invoice is created when the pick ticket is marked shipped. You write the rules once. The system applies them the same way every time.
Automated order processing is letting your ERP move an order through allocation, picking, shipping and invoicing according to rules you configure, rather than having an operator perform each step by hand. In AIMS360 the order itself is the trigger. An allocation profile decides which orders receive goods and in what priority. A pick ticket is created from what was allocated. The warehouse scans against bin and UPC. Packing rules build the cartons. The invoice is created when the pick ticket reaches shipped status.
The part that matters operationally is that none of this is a black box. Every run is recorded as a workflow with its own history, so you can see which steps succeeded, which failed and why, and re-run the ones that need it. And every automated step in AIMS360 has a manual equivalent, so nothing traps you when an order needs a human.
Nine steps. Depending on how you configure it, an order can pass through all of them without an operator opening it once.
| Step | What the system does |
|---|---|
| 1. Order arrives | From EDI, from your B2B or DTC storefront, from a marketplace, from a sales rep, or keyed in directly. Every channel lands in the same order table against one master stock record. |
| 2. Validation | The system checks the order can actually be processed: valid style and UPC, ship via and terms present, customer on file. Anything that fails is queued as an exception with a reason, not silently dropped. |
| 3. Payment authorization | For credit card accounts, the card on file is pre-authorized when the order is saved. A successful authorization releases the order to allocation. A failure holds it with a reason code. |
| 4. Allocation | The allocation profile assigns stock and work in process to orders in the priority you defined, down to style, color and size. It will not over-allocate a unit to two orders. |
| 5. Pick ticket | Pick tickets are created in batch from what was allocated, in whatever sort order you choose, and can be assigned to a specific picker. |
| 6. Pick and pack | The warehouse scans the bin location and then each UPC. Scan to verify flags a mismatch before the carton closes rather than after the customer opens it. |
| 7. Cartonization | Packing rules build cartons by style, by customer, or by customer and style, respecting one color per carton, one size per carton, mixed styles, hanging racks, and a maximum units per carton ceiling. |
| 8. Ship | Carrier labels, UCC 128 carton labels, packing list and VICS bill of lading. For EDI accounts the 856 advance ship notice follows the shipment. |
| 9. Invoice | When the pick ticket is marked shipped, the invoice is created from the picked quantities. For EDI accounts the 810 follows. The invoice can be emailed automatically with a payment link. |
This is the part most vendors describe as “intelligent” and then decline to explain. Here are the parameters an AIMS360 allocation profile accepts. You add them in the order you want them applied, and the sort order sets precedence.
| Parameter | What it controls |
|---|---|
| Completion date | Fill orders due soonest first. The most common first rule in a profile. |
| Start date | Respect the start of the ship window. Stock is allocated to orders whose start or completion date is still ahead. |
| Order entry date | First in, first served. Leave the value blank and the system sorts earliest entered first. |
| Customer priority | A 1 to 9 ranking on the customer account. 1 is filled before 5. Use it for must ship accounts and for accounts that ship last. |
| Factored orders | Fill factored orders ahead of non factored ones, or restrict a profile to a named factor. |
| Order status | Allocate to open orders only, or include orders on hold. Most brands allocate only to fully approved orders. |
| Order source | Run a profile against one channel. Allocate your wholesale book separately from your e-commerce orders. |
| Status reason code | Narrow further by the reason code on the order, so a single status can be split into several handling paths. |
| Allocation source | Allocate from stock, from work in process, or from both. |
| Past due orders | By default the system does not allocate to orders past their completion date. You can switch that on deliberately. |
| Warehouse | A hard constraint rather than a preference. Goods must be in the warehouse the order ships from. |
| Custom order fields | Your own order level fields can be used as allocation parameters, so division, program or any internal flag can drive priority. |
| Excluded accounts | Keep specific accounts out of a profile entirely. Production planning accounts should always be excluded, or they will absorb goods meant for live orders. |
Profiles are saved and reusable, so “fill the majors by completion date, then everyone else first in first out” becomes a thing you run rather than a thing you explain to whoever is covering allocation this week.
Yes. AIMS360 allocates against work in process as well as on hand stock, at the size level, before the goods physically exist. WIP in AIMS360 means one of three things: a cut ticket, a vendor purchase order, or garment dye. Any of those can be allocated to a customer order.
This is the mechanic that separates apparel from general distribution, and it is where most order automation quietly falls over. A brand selling a prebook season is committing goods that are still on a cutting table. If the system can only allocate what is on the shelf, allocation is a thing you do at the last minute in a spreadsheet, and the answer to “when does this ship” is a guess.
Allocation happens at style, color and size, not at style and color. A single order line can be part covered by stock in the building and part covered by a cut arriving next month, and the system tracks both against that line without double committing either.
When the WIP is received, the allocation does not evaporate. It converts to a stock allocation automatically and the original WIP reference stays visible, so nobody has to re-run anything and you can still see which cut a customer's goods came from.
Because it works at size level, one WIP source can be referenced by many orders. The older style of allocation could only hold one reference per style and color, which is why brands ended up running a report to check they had not over-committed. That check is now the system's job.
What is left after allocation is what you can still sell. AIMS360 calls it open to sell, and splits it into OTS(I) for immediate on hand availability and OTS(W) for future stock and WIP. You can see both on the order entry screen while a rep is on the phone, and you can calculate open to sell by date across stock, WIP by in warehouse date, open orders by completion date, allocated stock, allocated WIP and open pick tickets, per warehouse or across all of them, displayed by size.
The same calculation drives what you publish outward, including the EDI 846 inventory advice you send to trading partners and the availability your storefront sees.
Short supply is the normal case, not the exception, and it is where automation either earns its keep or creates a mess someone has to unpick.
You set a threshold for orders that are not ship complete. If an order cannot be allocated to at least that percentage from stock, the system writes a failure reason code onto the order instead of quietly shipping a token quantity. If it clears the threshold, it writes a success code.
Both codes are yours to define, which means the outcome of every allocation run is visible as a filter on the order list rather than a report someone has to remember to run.
An account flagged ship complete gets 100 percent or nothing. The flag overrides the pick method, so no partial pick ticket can be created against it, and the minimum fill percentage does not apply because the requirement is already total.
This is the flag that stops a major retailer receiving a 60 percent shipment and issuing a chargeback for it.
One thing worth knowing, because it catches people out: the minimum fill percentage measures stock allocation only. An order at 50 percent WIP and 35 percent stock has not met an 85 percent stock threshold, and it should not, because WIP is not something you can ship this week.
A pick ticket is itself a form of allocation. Once goods are picked they are held for that order, which is why the pick ticket is the point where a plan becomes a commitment.
| Control | What it does |
|---|---|
| Batch creation | Create pick tickets for many orders at once, in the sort order you set on the grid. Sort by completion date to pick first in first out, or filter to one channel and pick that book on its own. |
| Partial | Picks up to 100 percent of the order from what is available and unallocated. The most widely used setting. |
| Complete | Creates the pick ticket only if 100 percent of the order can be filled. |
| Zero stock | A forced pick ticket that ignores system inventory. Useful, and risky, which is why it can be switched off per user and per warehouse. |
| Allocation percentage | When allocation is driving picking, the percentage per line replaces partial and complete. 100 percent is complete, 1 to 99 percent is partial, and nothing is picked where no stock is available. |
| Assignment | Pick tickets can be assigned to a named user and printed by assignee, which is how you hand a picker a day's work rather than a pile. |
| Wave picking | Waves are prioritized by carrier cutoff, so the orders that have to leave the building today are picked before the ones that do not. |
| Pick path routing | Pickers are routed the shortest way through the warehouse or the 3PL rather than walking the ticket in the order it printed. |
| Bin sequencing | Picking follows bin priority, primary before overstock before unspecified, then your own bin naming convention. Bin codes are hierarchical and you can sort on individual segments of the code. |
| Add without voiding | Newly allocated units can be added to an existing pick ticket, as long as it has never been printed, instead of voiding and starting again. |
On the floor, mobile scanning puts the pick ticket on a handheld. The picker scans the bin location, then each UPC. Scan to verify catches the wrong item before the carton is closed. Full detail on the ticket itself is on the pick tickets page, and the labeling behind it is on barcodes and RFID. Automated order processing is one of the AI automations in AIMS360, alongside EDI document handling, exception flagging and the read only AI assistants.
Packing rules are set by style, by customer for all styles, or by customer and style together. The rule types are one color per carton, one size per carton, mixed styles, one color and one size, and on rack for goods that ship hanging rather than boxed. Each rule carries a minimum quantity and a maximum allowed quantity, and you can cap maximum units per carton so the system divides the pack quantity accordingly. Four prepacks of eight units in a carton, no more than 36 units total, is a rule you configure rather than a thing you hope the packer remembers.
Carrier labels for UPS, FedEx and USPS are generated from inside AIMS360, at your negotiated rates rather than published ones, and can be batch generated across many shipments at once. UCC 128 carton labels print from the shipment, in batch across several shipment files, or directly from the ASN module. VICS bills of lading are generated for EDI shipments, and a standard BOL is available for non EDI orders.
Automatic invoice creation is a setting on the customer account. When a pick ticket for that account is marked shipped, the invoice is created from the picked quantities. This is built for accounts where the shipment is confirmed outside AIMS360, by a shipping API, by ShipStation, or by a 3PL, and the pick ticket comes back updated.
Where you would rather review a batch first, batch invoicing lets you select many pick tickets and invoice them in one pass. Delivery and collection are separate again: automated invoicing covers emailing the invoice and giving the customer a payment link. For EDI accounts, the 856 advance ship notice and the 810 invoice follow the same shipment.
Automation is only worth having if you can trust it not to ship the wrong thing. These are the controls that hold an order back.
| Control | Behavior |
|---|---|
| Credit limit | When an order takes an in house account past its credit limit, the order is saved into hold status with the reason code you nominated. Worth being precise about this: it holds the order, it does not prevent the order being entered. |
| Credit card pre-auth | The card is authorized when the order is saved. Success releases the order and allocates the goods immediately. Failure leaves it on hold awaiting authorization. |
| Factor approval | Factored orders route through credit approvals and cannot be submitted without the factor on the order. |
| Order status and reason | The primary control surface. Every automation gates on status and reason code, and writes a result code back, so a failed run is visible in a filter rather than buried. |
| Ship complete | Blocks any pick ticket that would fill less than the whole order. |
| Allocation lock | Lock an allocation to WIP or stock so it cannot be reassigned to another customer. Locking is permission gated per user. |
| Zero stock restriction | Forced picking can be removed at both user and warehouse level. |
| Workflow validation | Missing ship via, missing terms, invalid style or UPC, insufficient stock. These stop the run, name the problem, and wait for a re-run rather than guessing. |
Worth reading before you plan around it. These are the constraints we would rather you heard from us than found in month two.
| Constraint | Detail |
|---|---|
| Warehouse is not flexible | Allocation will not pull stock from a different warehouse than the one the order ships from. If the goods are in the wrong building, the order does not allocate. See multi warehouse. |
| Past due needs a decision | Orders past their completion date are excluded by default. Allocating to them is deliberate, not automatic. |
| Planning orders compete | Allocation will attempt every order it is given. Production planning orders left inside a profile will take goods from live ones. Exclude them. |
| Substitutions are not automated | There is no substitution engine, by design. An order is an obligation to ship what was ordered. The documented path for a short DTC order is to ship what you have, cancel the balance and refund, rather than send something else. |
| Cards need care in batch | If you capture cards at invoicing, fully automatic batch invoicing must be switched off, or invoices are created without the card being charged. |
| Every step has a manual twin | Not really a limitation, but worth stating: every automated step was a manual process first and still is one. Your team should know both, because the day a workflow stops is the day someone needs to finish the order by hand. |
Order automation questions we get from apparel and consumer brands.
An order arrives from EDI, a storefront, a marketplace or a rep. The system validates it, authorizes payment where a card is involved, and allocates stock and work in process to it according to your allocation profile. A pick ticket is created from what was allocated. The warehouse scans the bin and each UPC. Packing rules build the cartons. Carrier and UCC 128 labels print, and the ASN goes out for EDI accounts. When the pick ticket is marked shipped, the invoice is created from the picked quantities.
Yes, if it has a rules layer to decide priority. AIMS360 uses allocation profiles, which are ordered lists of parameters such as completion date, customer priority, factored status, order source and warehouse. The profile decides which orders get goods first, and the system allocates down to style, color and size without over-committing a unit to two orders.
Yes. AIMS360 allocates against work in process, which means cut tickets, vendor purchase orders and garment dye, alongside on hand stock. A single order line can be covered partly by stock and partly by a future cut. When the WIP is received the allocation converts to stock automatically and the WIP reference stays visible.
You set a minimum allocation percentage for orders that are not ship complete. Orders that reach the threshold get a success reason code, orders that fall short get a failure reason code and are visible as a filter rather than shipped short. Accounts flagged ship complete are all or nothing and cannot generate a partial pick ticket at all. Note that the percentage measures stock allocation only, not WIP.
Per warehouse, not across them. Allocation can only assign goods held in the same warehouse the order is set to ship from, for both stock and WIP. If the units are in another building the order will not allocate, which is deliberate: it stops the system promising goods that cannot physically make the shipment.
Yes, and it is forward looking by default. For stock, the order needs a start or completion date later than the date of the allocation run. For WIP, the order completion date needs to be later than the WIP completion date. Orders already past their completion date are excluded unless you switch that on.
Yes. Each customer account carries a priority from 1 to 9, where 1 is filled first. Brands typically use 1 for must ship majors and the higher numbers for accounts that ship after everyone else. You can also prioritize factored accounts over non factored ones, restrict a profile to a named factor, or exclude specific accounts from a profile entirely.
Several controls, each with its own reason code: a credit limit breach puts the order on hold, a failed card pre-authorization leaves it awaiting authorization, factored orders wait on credit approval, ship complete blocks anything under a full fill, an allocation lock stops goods being reassigned, and workflow validation stops the run outright for a missing ship via, missing terms, an invalid UPC or insufficient stock.
Automatic invoice creation is enabled on the customer account. When a pick ticket for that account is marked shipped, the invoice is created from the final picked quantities. It is designed for accounts where the shipment is confirmed outside AIMS360, by a shipping API, ShipStation or a 3PL. If you capture credit cards at invoicing, use per invoice processing rather than fully automatic batch mode.
Yes. The typical shape is that AIMS360 allocates and creates the pick ticket, the pick ticket goes to the 3PL or to ShipStation, the shipment comes back and updates the pick ticket to shipped, and that status change triggers the invoice and, for EDI accounts, the ASN and 810. Order source rules let you allocate 3PL fulfilled channels on their own schedule.
Yes. Allocations can be viewed, adjusted and locked. Locking is used when goods are being produced for a specific account and must not be reassigned, and it is permission gated per user. There is also an audit log by style, color and size showing every allocation interaction against each order line.
Yes, and that is the point of running it in the ERP rather than in a channel tool. Wholesale, dropship, marketplace and DTC orders all sit against one stock record, so a unit committed to a major cannot also be sold on your storefront. Order source is an allocation parameter, so you can still run each book on its own rules.
An order management system routes and tracks orders. An apparel ERP also owns the inventory those orders are drawing from, the production that replenishes it, the costing, and the accounting the invoice posts to. That matters for allocation specifically, because allocating against work in process requires the system to know about cut tickets and purchase orders, which an OMS sitting on top of a warehouse generally does not.
Bring an allocation problem you have this season. We will show you the profile that solves it, and what the system does when the stock is not there.
