Packing data coverage

Three questions that have to be answerable before cartonization is worth switching on, and one screen that answers them.

Stockly → Operations → Shipping → Packing data coverage.

The figures at the top

Articles that can be fitted is the number that matters: the share of the catalogue with a weight and all three dimensions. The rest count what is missing, how many boxes exist and how many rules.

Two problems are called out as banners rather than rows, because each makes the whole feature inert rather than merely incomplete:

• no packaging materials — nothing can be fitted into anything;
• no default packing profile — articles outside every rule get no packing data at all.

Missing data

The work list, and it is sorted by how often the article actually shipped in the last six months.

That ordering is the entire point. A shop with five thousand articles will never fill in five thousand rows, and being required to do so is how a feature gets switched off again. Forty articles leave the building every day and the rest leave twice a year; ranked by shipments, the work becomes an afternoon with almost all of the benefit.

A variant with no measurements of its own counts as covered when its parent has them, because that is how it is actually resolved.

Box capacities

Stockly → Operations → Shipping → Packing data coverage → Box capacities answers one question per row: how many of one kind of thing go in one box. Nobody fills it in. Each row is either worked out from the measurements, or counted from parcels a packer actually closed; the On what authority column states which, and Behind the number shows how many parcels a counted row rests on.

Counted rows can only push a capacity above what the measurements predict. That is deliberate: a closed parcel proves that many fit and says nothing about one more, so goods that nest, roll into each other’s hollows or squash are taken into account. Nothing here records a box that refused to close, so nothing here can argue that fewer fit.

Full boxes of a single article are then built straight from these numbers instead of being fitted by volume. Recalculate repeats the computation for all rows; the nightly task does it in any case.

Rule collisions

Stockly → Operations → Shipping → Packing data coverage → Rule collisions lists articles that two profiles of the same rank both claim. The result is stable, because otherwise no complaint about a box could be reproduced, but it is decided by an internal comparison instead of by the configuration.

The fix is one edit: give one of the profiles a higher rank.

This list is normally empty. It exists because the alternative, refusing to save overlapping rules, would require a merchant to restructure three hundred articles, and because a tie-break that is not visible is what makes priorities a trap.

Estimate vs. scale

Stockly → Operations → Shipping → Packing data coverage → Estimate vs. scale shows where the predicted weight and the weighed weight disagree, per article.

Only parcels holding a single kind of article are counted. In a box with four different things a 300 g miss cannot be attributed to any one of them; every system that learns from actual figures learns from the single-article boxes.

A consistent gap means the article’s own data is wrong: a weight that was never updated after the supplier changed the packaging, a sleeve nobody recorded. Correcting the article closes the gap; no audit is required.

A sensible order of work

1. Create the packaging materials — ten rows, a single session.
2. Create a default packing profile, then one per packing class.
3. Work down the Missing data list until the articles that ship daily are covered.
4. Switch a shipping method to Fit into a real box.
5. Come back to Estimate vs. scale in a fortnight and fix what the scale disagreed with.

Once the first four are done, the packing table can draw what goes where. → Switching on the box loading assistant