Trade-item identifier planning

What the worksheet counts

This worksheet converts four counts of distinct configurations into a planning total for trade-item records. It is a counting aid, not an identifier generator. Enter the number of separate configurations, not the number of physical units, cartons or labels you expect to print. A single consumer variant counted once remains one record even if you order thousands of units. The model groups the first two fields as consumer-unit configurations and the last two as case and other configurations before returning the total. The three output labels are fixed, so your planning notes can map directly to the consumer side and the case or other side.

Filling the consumer-unit fields

Distinct consumer-unit variants is the count of separate consumer-facing items. Use one count per variant that you need to plan as a distinct trade-item record. Distinct sellable multipacks is separate: count each multipack configuration that is sold as its own item. A multipack that is only an internal pack should not be added to the sellable multipacks field. Both fields feed the consumer-unit row, so moving a count from one to the other changes the input breakdown but leaves all three output values unchanged.

Filling case and other trade-item fields

Distinct case configurations counts each separate case arrangement you need to plan as a trade-item record. Do not enter the number of cases you will ship; enter the number of distinct case configurations. Other distinct trade-item configurations covers configurations that are neither consumer units, sellable multipacks nor cases in the first three fields. Use it for additional distinct trade-item records in your plan, and keep the entry at zero when none apply. Cases and other are grouped into the case and other row. The worksheet does not ask for pack quantity, case pack size or channel; it only counts distinct configurations.

Reading the three output rows

The consumer-unit configurations row is the sum of variants and multipacks. The case and other configurations row is the sum of cases and other. The distinct trade-item records to plan row is the sum of those two rows. With the starting inputs the rows read 14, 3 and 17. These labels distinguish the planning groups: consumer configurations and case or other configurations. The total is a record count for planning, not a count of UPC symbols, GTINs, licenses or prefix capacity. The output order is stable and the labels are part of the result.

Worked example: starting scenario

Use variants 12, multipacks 2, cases 3 and other 0. The worksheet returns consumer-unit configurations 14, case and other configurations 3, and distinct trade-item records to plan 17. The 14 combines twelve consumer variants with two separately sold multipacks; the 3 is the case count with no other configurations added. The result is seventeen records to plan, not seventeen individual UPC licenses. Confirm allocation rules and channel acceptance separately.

Worked example: changed scenario

Use variants 4, multipacks 1, cases 2 and other 0. The worksheet returns consumer-unit configurations 5, case and other configurations 2, and distinct trade-item records to plan 7. Compared with the starting scenario, the lower variant, multipack and case counts reduce both grouped rows and the total. If you later add an other configuration, the case and other row rises by one and the total rises by one, while consumer-unit configurations stay as entered.

Why input changes move the total

Every field contributes its own count to one of the two grouped rows, so any increase in a distinct configuration raises the total unless another field is reduced by the same amount. Shifting counts between variants and multipacks changes the consumer-unit row composition but not its row total or the overall total. Shifting counts between cases and other behaves the same way inside the case and other row. Because the model is additive, a count entered in the wrong field can leave the total correct while making one grouped row misleading. The worksheet does not net configurations, deduplicate similar items or infer hierarchy relationships from item references.

Edge cases and review limits

The worksheet raises Enter at least one trade-item configuration when all four fields are zero. In that state there is no record count to display, so correct the entries rather than treating zero as a valid plan. Use whole nonnegative counts; fractional or negative entries are outside the intended integer model. Keep identifier records separate from licensed-prefix capacity. The worksheet neither assigns identifiers nor validates brand ownership. Some hierarchy identifiers derive from an existing item reference. Confirm allocation rules, channel acceptance and prefix capacity with GS1. A UPC symbol and a GTIN identifier are different concepts. Case-level numbering and prefix capacity need a GS1 allocation review; this sum is not a license purchase recommendation.

Questions about trade-item identifier planning