Shipments: Merch > Shipments. A coordination record for stock moving in, out, or between legs of the tour, not a postage system. No label purchase, no carrier account: this is the "who's sending what, where, on which truck" layer merch talk actually runs on.
A SHIPMENT HAS: a direction (inbound / outbound / transfer), a from and a to (free text, or link a show to auto-fill "to" from its venue/city), a vendor name/email, a carrier/tracking number/ETA, one or more BOXES, each holding a list of products+sizes+quantities, and notes. Status moves created → in transit → received (or reconciled).
PRINT A PACK SHEET. The printer icon on any shipment builds a PDF: a ship-to block (pulled from the linked show's ship-to address if there is one, else the shipment's own "to" field), the carrier/tracking/ETA, and every box's contents as a table. Same document family as the restock purchase order. Same header, same look.
RECEIVING A SHIPMENT NEVER DOES ITS OWN INVENTORY MATH. Tapping Receive walks every box line and folds it into that product's stock through the EXACT SAME "Add stock" path Inventory uses. A dated restock entry, tagged with the shipment so the history says where it came from. There is no second, shipment-only stock number to drift from the real one. A line naming a product that's since been deleted from the catalog is skipped, not blocked. The rest of the shipment still lands.
WHAT THIS IS NOT (YET): there's no vendor-facing portal (a vendor can't log in and update their own shipment. The TM or whoever has merch write access enters it), and no real postage purchase. Those are later phases of the same idea, not built.