Generate a packing slip

Create a packing slip that belongs inside a shipment without turning it into an invoice. Supply an order number, a structured shipping address, and one or more item rows with quantities. The generator validates the shipment data, numbers each line, calculates total units, and returns both reusable structured fields and a clean plain-text document. Prices, taxes, payment terms, and billing details are deliberately excluded, keeping the result focused on fulfillment, recipient checks, and package contents.

Build the document from fulfillment data

A packing slip answers a practical warehouse question: what should be in this package, and where is it going? Start with the order number used by your store, warehouse, or order-management system. Then provide the recipient and destination as structured address fields so each part remains reusable after generation.

Add every packed product as its own row with a name, a positive whole-number quantity, and an optional SKU. The generator keeps the supplied row order, assigns visible line numbers, normalizes stray whitespace, and calculates both the number of distinct lines and the total number of units. The result includes a structured object for software workflows and a plain-text packing slip for printing, saving, or inserting into another document layout.

Because the algorithm does not invent missing shipment details, the generated document stays traceable to the information your fulfillment process supplied. A request with no item rows fails instead of creating an empty and potentially misleading shipment record.

Keep a packing slip distinct from an invoice

Packing slips and invoices may refer to the same order, but they serve different jobs. An invoice requests or records payment and commonly includes unit prices, discounts, taxes, totals, billing addresses, payment instructions, and legal terms. This capability intentionally produces none of those fields.

Its output identifies the document as a packing slip and contains only the order reference, ship-to destination, item identities, quantities, counts, and a printable representation of that information. That distinction is useful when a parcel is a gift, when purchasing staff should receive financial documents separately, or when warehouse workers do not need access to commercial terms. It also prevents downstream systems from treating a fulfillment insert as evidence of an amount due.

If you need accounting calculations or a customer payment document, use an invoice-specific workflow. Here, quantities are operational facts: they help a packer, recipient, or returns team compare physical contents with the order without exposing price information.

Validate, print, and automate consistently

Use the structured response when another system needs to archive the slip, map item lines into a PDF template, create a label packet, or compare packed quantities with scan results. Use the plain-text document when a simple human-readable insert is sufficient. Required address components are checked individually, while optional company, second address line, region, postal code, and SKU fields are omitted when blank rather than represented as null values.

Item quantities must be positive integers, which avoids ambiguous fractional or zero-unit rows in ordinary parcel fulfillment. The generator is deterministic: identical input produces identical output, with no network request, current timestamp, random identifier, inventory lookup, or product enrichment. Perform those checks in the appropriate inventory, address-validation, and carrier systems before treating the generated slip as authorization to dispatch a package.