Create pick tickets in the sequence you choose, first in first out, by style or by cut ticket, with ship complete orders first and intelligent allocation reserved stock honored. Total a batch onto one bulk pick list, assign tickets to pickers and verify every pick by bin and UPC scan on a handheld.
Picking optimization in AIMS360 is how a brand decides which orders get the units when stock is short, in what sequence the pick tickets are cut, how a whole batch is picked in one pass, who each ticket belongs to, and how every unit is verified by bin and UPC scan before it goes in a box. No routing engine, no separate warehouse system: the same order, inventory and customer records the rest of the company runs on.
Picking optimization in AIMS360 is the set of controls around the pick ticket: the pick method (partial, complete or zero stock), the sort order a batch allocate run follows when it creates tickets, ship complete handling, intelligent allocation's reserved stock, the bulk pick ticket that totals a batch onto one list, assignment of tickets to named pickers, the print options that expose shortages and back orders, and scan to verify by bin location and UPC on a handheld. Together they decide who gets the stock, in what order it is picked, how often the floor is walked, and whether what was picked is what was ordered.
The pick tickets page covers the document itself: why a pick ticket has to exist before an invoice, the three ways to create one, and what each picking method does. This page is about the decisions a warehouse manager makes on top of that, and where in AIMS360 each one lives.
| Lever | What it does |
|---|---|
| Pick method | Partial picks up to the ordered quantity from what is in stock and unallocated, and is the recommended default. Complete picks a line only when every unit on it is available. Zero stock ignores inventory and picks everything selected, which is why it can be switched off per user and per warehouse. The three are explained on the pick tickets page. |
| Sequence | Batch allocate creates pick tickets in whatever order the order grid is sorted when you select the lines. Sort by completion date and the oldest promise gets stock first, which is first in first out regardless of order number. Sort by style or by the cut ticket that just landed, or filter to one channel first, and the run follows that instead. |
| Ship complete first | Orders flagged ship complete must be picked in full or not at all. Batch allocate can attempt those orders first, leave them out, or treat them like everything else, so a brand that is not on intelligent allocation can still protect its ship complete customers before the rest of the book eats the stock. |
| Allocated stock only | With intelligent allocation reserving units to orders by rule, batch allocate can be told to pick from allocated goods only. The rules decide who owns the units; the pick run just honors them. |
| One warehouse per run | With multi-warehouse active, each batch run picks against a single warehouse. That is a deliberate constraint: a pick list that spans buildings is a pick list nobody can walk. |
| Combine rule | A new ticket can stay separate, merge into any existing ticket on the order, or merge only into a ticket that has never been printed. The last is the recommended setting, because a printed ticket may already be on the floor. Printing to screen counts as printed. |
| Presets | The pick options tab in system settings fixes the defaults for method, combine and the other choices, and they apply to both the batch allocate module and the pick and invoice tab of a single order, so every user starts from the same rules. |
| Automation aware views | Brands running the B2C automation get a default batch view that hides order lines still being processed by the automation, so a manual run cannot grab a web order the automation is about to pack, and cannot fail on it either. |
Every one of these reads inventory at the style, color and size level, the way apparel stock actually exists, and picks against a real warehouse rather than a company wide total.
Open batch allocate and use the grid: a style, a season, a completion date range, a channel, or the cut ticket that was received an hour ago. Brands on the B2C automation start from the view that leaves the automation's lines out.
Completion date ascending for first in first out. Start date, customer, style or ticket number if that is how the floor runs. Pick tickets are created in this order, so this sort is the priority rule for the run.
Pick ship complete orders first, leave them out, or include them with everything else. If intelligent allocation already reserved their units, this step is unnecessary; the allocation carries the priority.
One warehouse per run. Partial, complete or zero stock as the method; allocated stock only if you use intelligent allocation; combine into existing tickets only if never printed. The presets fill all of this in; change it only for this run.
The module creates the tickets and you close it. The pick tickets module or print pick tickets shows what was created, with the never printed view as the safe starting point.
Print only never printed tickets, add a bulk ticket if the floor picks by totals, and assign the batch to pickers in the same step. From here the tickets are on the handheld or on paper, and the invoice waits for the picked quantities.
Select the batch in print pick tickets and tick bulk ticket. Every individual ticket prints, followed by ticket 0000: every style, color and size totaled across the batch. Pickers pull totals once; packers split them by order.
One ticket at a time from its drop down, or a whole batch from print pick tickets by choosing an assignee before printing. Reassigning a ticket asks for a typed confirmation. A system setting can assign everything to one person or to the creator.
Views filtered by assignee and assigned date turn the day's work into one stack per picker. Print only if never printed keeps a stack from being handed out twice.
The warehouse app opens on tickets assigned to me. Toggle it off to see unassigned tickets and, with permission, tickets assigned to others. Assign to me takes an unassigned ticket; takeover moves an open or packed ticket from another picker.
Search by pick ticket number, account, order number or customer PO, or scan the barcode printed on the paper ticket. The ticket opens with bin location, style, color, size and pieces on every line.
With bin locations in use, the ticket tells the picker where the units are and the scan step refuses a bin that is not on the ticket. Sensible bin naming is what puts lines in walking order.
| Option | What it changes on the ticket |
|---|---|
| Customer shipping instructions | On by default. Whatever is on the customer master prints on the ticket, so the picker sees the retailer's handling rules without asking. |
| Quantity on order, if different | Adds the ordered quantity under any line where fewer units were picked than ordered, so the difference is visible without opening the order. Lines with nothing picked do not print; anything absent from the ticket is the back order. |
| Prices and merchandise total | Prices print each style's price and add a ticket total. Merchandise total prints only the total, for the declared value on a carrier label, when you do not want prices on the floor. |
| Handwrite quantity | An extra line under each size for the packer to write what actually went in the box, for warehouses that confirm on paper before the quantities are keyed or scanned. |
| Order notes and warehouse details | Can be saved as defaults so notes from the order desk and the warehouse block reach the picker on every ticket without anyone remembering to tick them. |
| Only if never printed | Prints tickets that have never been printed and skips the rest. Paired with the never printed view, it is the simplest guard against the same ticket being picked twice. |
| Bulk ticket | Prints every selected ticket and adds a final ticket numbered 0000 that totals every style, color and size across all of them: one pick list for the whole batch, sorted back to orders at the pack bench. |
The printed ticket carries a barcode the handheld reads, and the modern format can be made the default in company settings. Labels are a separate step: shipping labels come from finalize pick tickets or shipment processing once the picked quantities are confirmed.
In the warehouse app's setup, choose scan to verify for the line item (the UPC), for the bin location, or both. A warehouse without bins verifies units only; a warehouse with bins verifies where the unit came from as well.
The scan function only appears on a ticket assigned to the logged in picker, so nobody verifies somebody else's work by accident.
Scan the bin first, tick same bin if several UPCs are coming out of it, then scan each unit's UPC. The screen counts scanned against required for the ticket. A scanner set to send a carriage return commits each scan without a tap.
Tap the check beside the line when it is done. The purple check fills the required quantity in one tap, the red X clears the line and starts it again, and an all at once version does the same for the whole ticket. A packed column records what was confirmed by scan or by hand.
A bin that is not on the ticket returns an invalid bin location error; a UPC that is not on the ticket returns an invalid UPC error. The count does not move until the right bin and the right unit are scanned.
The handheld side of picking, and the other warehouse modules on the device, are on mobile device scanning. The UPCs it reads are the ones already on your styles; see barcodes.
| Status | What sets it and what it allows |
|---|---|
| Open | Every ticket starts here. It can be edited from the order or the pick tickets module, reprinted, reassigned or voided. |
| Packed | Set when the ticket is exported to a warehouse file, sent through a 3PL integration, added to a shipment in shipment processing, or changed by hand from the status drop down. Editing is blocked in this status so the floor and the office cannot disagree. A setting can stop exports from setting it, and EDI orders can be excluded. |
| Shipped | Set by marking the ticket shipped in finalize pick tickets or by generating the EDI 856 advance ship notice that contains it. No changes after this. |
| Complete | The ticket has been invoiced. |
| Void | There is no delete. A ticket in open or packed status can be voided whole, never line by line, and a ticket inside a shipment is voided by removing it from the shipment first. Shipped tickets cannot be voided. |
| Never printed | Not a status but a view: tickets that have never been printed or exported, so they have no chance of being in process and are safe to void, change, print or export. Brands exporting to a 3PL are advised to make it their default view. |
Packed used to change only through exports and shipment processing, which left brands unsure whether a ticket was being worked. The status can now be changed by hand from open to packed, so a ticket that has been picked up is marked as such; agree the rule with the floor before anyone uses it.
There is no module that releases picking in timed waves by carrier cutoff or by zone. Batch allocate in your chosen sort order, released when you choose, against one warehouse, with a bulk ticket on top, is what AIMS360 offers, and it is what most brands asking for waves are describing. If you need timed release, say so during scoping.
AIMS360 does not compute a walking path. It puts the bin on every line and rejects a scan from the wrong bin. Walking order is a property of how you name bins.
Batch allocate picks against one warehouse at a time. Zero stock and combine always are both available and both not recommended; zero stock can be switched off per user and per warehouse.
A pick ticket is voided whole or not at all, while it is open or packed. Re-pick after voiding. Manual tickets from a single order rely on the user to choose priority; the sequencing lives in batch allocate and intelligent allocation.
It is the set of controls that decide which customer orders receive available units, in what sequence pick tickets are created, how many tickets a picker walks at once, who each ticket belongs to, and how every pick is verified before it is packed. The pieces are the pick method, the sort order of a batch allocate run, ship complete handling, intelligent allocation, the bulk pick ticket, picker assignment, the print options and scan to verify on the handheld.
Two ways. Intelligent allocation reserves units to orders by rules you set, before anyone picks, and batch allocate can then pick from allocated stock only. Without it, the batch allocate run creates tickets in the order the grid is sorted when you select the lines, so sorting by completion date gives the oldest promise first, and the ship complete option lets you protect ship complete customers before the rest of the book runs.
Not as a separate wave engine that releases work in timed waves by carrier cutoff or zone. What it has is batch allocate, which creates a set of pick tickets for whatever orders you filter and sort, in that sort order, against one warehouse, plus the bulk pick ticket that totals the batch onto one list. Most brands who ask for waves want exactly that: a controlled batch, released when they choose, in the order they choose. If you need timed release by cutoff, raise it during scoping.
No. AIMS360 does not compute a walking route through the warehouse. It prints the bin location on each line, shows it on the handheld, and refuses a scan from a bin that is not on the ticket. Walking order comes from how you name your bin locations, which is why the bin naming guidance matters more than any routing claim.
Yes, in two senses. Batch allocate creates many pick tickets in one run from the orders you select. The bulk ticket option in print pick tickets then adds a single ticket, numbered 0000, that totals every style, color and size across the selected tickets, so the floor picks once and the units are sorted back to individual orders at packing.
In batch allocate, filter to the order lines you want, sort the grid by completion date or start date ascending, select them and process. Tickets are created in that sort order, so the oldest promise is picked first even when its order number is newer, which happens constantly when orders arrive from the portal, EDI, Shopify and the order desk at once.
Ship complete overrides the picking method: the whole order has to be picked at once or the ticket is not created, and the user sees a reminder that partial shipments are not allowed. Non inventory and service fee lines are ignored in that check. Batch allocate can run ship complete orders first, and the zero stock method skips the check entirely, which is one more reason zero stock is not recommended.
Four guards work together: combine only into never printed tickets, so a ticket already on the floor is never merged into; the never printed view and the only if never printed print option, so a ticket is printed once; assignment, so each ticket has a name on it; and on the handheld, a ticket assigned to someone else has to be taken over deliberately rather than opened by accident.
Yes. Assign one ticket from its drop down in the pick tickets module, or select a set in print pick tickets, choose an assignee and print; the tickets print and assign in one step. Changing an existing assignee asks for a typed confirmation. A system setting can assign every ticket to one person or to whoever created it, which suits small teams. Views filter by assignee and assigned date, so each picker's day prints as a stack.
Per warehouse, you switch on scan to verify for the line item, the bin location, or both. A picker opens a ticket assigned to them, taps scan, scans the bin, then scans the UPC of each unit leaving it. The screen counts scanned against required. A purple check sets a line to the required quantity, a red X resets it, and a packed column records what was actually confirmed. Set the scanner to send a carriage return after each scan so nobody has to tap the screen.
The app rejects it. A bin that is not on any line of the ticket returns an invalid bin location error, and a UPC that is not on the ticket returns an invalid UPC error. Nothing is counted until the right bin and the right unit are scanned.
Style, color, size and quantity per line, with a barcode the handheld can scan to open the ticket. Customer shipping instructions print by default. Optional: prices with a total, a merchandise total on its own, the ordered quantity where it differs from the picked quantity, a handwrite line per size, order notes and warehouse details, and the modern format set as the default in company settings. Line notes from the order also show in the pick and invoice view.
Use the quantity on order if different option. Any line picked short prints the ordered quantity beneath the picked quantity. Lines with no pick at all do not print, and everything missing from the ticket is what remains on back order for the customer.
Tickets are created in AIMS360 the same way and then reach the warehouse through a 3PL integration or a flat file export in the warehouse's format, which moves the ticket to packed. What the 3PL actually shipped comes back through the integration or an import in finalize pick tickets, is validated row by row, and is marked shipped and invoiced from there. The never printed view is the recommended default for brands working this way.
The DTC fulfillment automation picks and packs web orders on its own. For everything else, batch allocate offers a view that excludes lines still inside the automation, so manual runs and the automation never collide. Orders from Shopify can also be filtered in batch allocate and sorted by date when a brand wants to run them by hand.
Neither. A pick ticket can be voided in full while it is open or packed, and re-created; there is no line level void and no delete. A ticket inside a shipment is removed from the shipment first, and a shipped ticket stays as it is.
Both exist. A batch allocate run is a person's decision about which orders to pick and in what order, and the presets keep every run consistent. Intelligent allocation reserves stock by rule without a person choosing line by line, and the automated order processing set takes web orders from order to pick ticket to invoice without anyone touching them. Picking optimization sits under AI automations because that is where the rules that feed it live.
UPC codes on your styles at the style, color and size level, a rugged handheld with a barcode scanner that runs the browser based warehouse app, and optionally bin locations and a WiFi or Bluetooth printer if pickers print from the device. The mobile device scanning page covers the device and the other warehouse modules.
We will run it in a demo: the orders you had, the stock you had, a batch allocate run in your priority order, the bulk ticket, the assignments and a scan to verify pass on a handheld.
