Digital Packing / Warehouse Interface — scoping feedback wanted

We’ve had interest from a hub operator switching from another platform who relies heavily on a digital warehouse packing workflow for their weekly operations. Before taking this further I’ve had Claude do some initial scoping against the OFN codebase and wanted to share it here for community input:

The request in brief

A tablet-friendly, interactive packing screen to replace the current static packing reports. Key capabilities:

  • Filter packing lists by: storage type (frozen / refrigerated / ambient / dry), customer, producer/supplier, distribution type (home delivery vs. pickup), and packed / not-packed status
  • Tick off items as packed directly in the interface (laptop or tablet in the warehouse)
  • Generate sub-lists (e.g. “frozen items for delivery orders only”) for different packing stations or workflows
  • View only unpacked items later in the day to finish partial orders

What OFN already has

Solid foundations exist:

  • Static packing reports (by customer, supplier, product) in the reporting section
  • Shipment state tracking (pending / ready / shipped) on orders
  • Temperature control flag on shipping categories (boolean)
  • Delivery vs. pickup distinction via shipping_method.require_ship_address
  • Customer tags (used by tag rules)
  • Supplier/producer and distributor filtering in bulk order management

What would need to be built

The main gaps:

  1. Storage type enum — the current temperature flag is binary; a 4-way frozen/refrigerated/ambient/dry categorisation needs a schema change on ShippingCategory
  2. “Packed” status on line items — no packed state exists today; needs a new column and a toggle endpoint
  3. Interactive packing screen — a new admin page (Stimulus + Turbo) replacing the static reports with a live, tick-off interface optimised for tablet use
  4. Advanced filtering — the five filter dimensions above, all using data that already exists once the schema changes land
  5. Sub-list / filter-then-print — compound filters, with named/saved sub-lists as a potential follow-on

Rough scope

Estimated 10 or so development sessions, decomposable into roughly five story issues:

  • Storage type enum (schema + admin UI)
  • Packed status on line items (schema + toggle endpoint)
  • Basic packing screen with filters (new page, read-only first)
  • Real-time tick-off (Stimulus, makes it interactive)
  • Sub-list / filter-then-print

Questions for the community

  1. Is a “packed” status the right abstraction, or does it overlap with the existing shipment state machine in a way that creates confusion?
  2. Is storage type (frozen/refrigerated/ambient/dry) something hubs would configure on shipping categories, or is it more naturally a product property or taxon?
  3. Are there hubs already working around this with product tags, custom reports, or exported spreadsheets — something that would inform the design?
  4. Would this be useful beyond the single use case described, or is it niche enough that it warrants a feature toggle rather than core behaviour?

Happy to go deeper on any of this. Looking forward to input from hub operators and developers before taking it to an implementation plan!