Package quantities and order types without inconsistent cart rules
Explain pack-size corrections clearly, keep suggestions within quantity limits, and apply the authoritative rule across every cart entry point.
In this guide
- Current product policy
- Selected order type
- Validate quantity
- Explain correction
- Recalculate cart
The same quantity passes one screen and fails another
A buyer adds seven units of a product sold in packs of six. Quick order accepts it, the cart rounds it to twelve, and changing the order type restores seven. Each screen has a piece of the rule, but none owns the complete decision.
Write the commercial policy before implementing the arithmetic. For this fictional example, replenishment orders require whole packs while service orders may allow individual units for eligible products. The complete-pack rule is an explicit project policy layered onto the product's configured quantity limits.
Separate validity from suggested correction
A validator should explain whether a quantity is allowed and, when useful, suggest an alternative. Automatically changing a buyer's quantity can change the order value substantially. Decide whether the user must confirm the adjustment and how that confirmation is represented.
Keep minimum quantity, maximum quantity, pack multiple, and break-pack eligibility as separate concepts. A quantity can be a valid multiple while exceeding a maximum. Invalid configuration, such as a zero package size, needs a clear operational error rather than a division-by-zero exception or a permissive fallback.
Validate complete-pack quantities
Place whole-pack-suggestion.ts in the browser cart code. wholePackSuggestion rounds a positive whole quantity up to the next pack multiple. validateWholePack combines that calculation with a maximum and an enforcement flag, returning either a valid quantity or a correction message and optional suggestion.
Use the current server-supplied pack size and policy for early feedback. The Znode 9 C# cart service remains responsible for the complete decision, including minimum and maximum quantities, product eligibility, account rules, and order type. This TypeScript example implements the pack and maximum portion of that policy.
cart/whole-pack-suggestion.ts typescript
export function wholePackSuggestion(quantity: number, packSize: number): number {
if (!Number.isSafeInteger(quantity) || quantity < 1 ||
!Number.isSafeInteger(packSize) || packSize < 1) {
throw new RangeError("Positive safe integers are required.");
}
const result = Math.ceil(quantity / packSize) * packSize;
if (!Number.isSafeInteger(result)) {
throw new RangeError("Suggested quantity is out of range.");
}
return result;
}
export type PackDecision =
| { valid: true; quantity: number }
| { valid: false; suggested: number | null; message: string };
export function validateWholePack(
quantity: number, pack: number, maximum: number, enforce: boolean
): PackDecision {
if (!Number.isSafeInteger(maximum) || maximum < 1)
throw new RangeError("Maximum must be a positive safe integer.");
const suggested = wholePackSuggestion(quantity, pack);
if (quantity > maximum)
return { valid: false, suggested: null, message: "Quantity exceeds the maximum." };
if (enforce && suggested !== quantity)
return { valid: false, suggested: suggested <= maximum ? suggested : null,
message: "This order requires complete packs." };
return { valid: true, quantity };
}
// Resolve enforce, pack and maximum from the server's current product/order policy.
// Present a suggested quantity for buyer confirmation before applying it.With quantity 7, pack size 6, maximum 24, and enforcement enabled, the result is invalid with a suggested quantity of 12. If the maximum is 10, the result is still invalid but suggested is null because 12 exceeds the limit. Quantity 6 is valid. Show a suggestion for confirmation instead of silently increasing the order.
Revalidate transitions, not just additions
The rule must run when a line is added, its quantity changes, or the order type changes. It may also need to run when a saved cart is restored, an account switches, or product packaging changes. A previously valid cart is not permanently valid.
Keep the authoritative decision on the server so direct API requests and alternative ordering screens receive the same result. Frontend validation can provide quick feedback, but should consume the same policy information and display the server's final decision. Avoid trusting a browser field that claims a product is eligible for individual-unit ordering.
Build a small rule matrix
Test one product with a pack size of six and another with a pack size of one. Try quantities one, six, seven, twelve, zero, a fraction, and a value beyond the supported range. Vary the fictional order type and break-pack eligibility independently.
Switch order type after valid lines already exist. Verify that the cart reports every newly invalid line and that a suggested adjustment does not silently bypass limits. Exercise quick order, ordinary add-to-cart, saved-cart restoration, and direct API updates. Inspect recalculated totals after accepted corrections, including any shipping dependencies.
- Keep the original requested quantity available for explanation.
- Do not infer policy from translated order-type display labels.
- Test invalid product configuration as well as invalid buyer input.
Make the correction understandable
Explain the product rule and the proposed change together: 'This item is sold in packs of 6 for this order type. Change 7 units to 12, or edit the quantity.' If no allowed suggestion exists, explain the limit and leave the original input available for correction.
Use the same decision in quick order, cart editing, and saved-cart restoration. Revalidate when order type or account changes. The buyer should receive the same answer regardless of the screen used to reach the cart.
References and further reading
Independent guidance from GCG. Znode is a trademark of its owner. Examples use fictional data and are not official platform documentation. Suggest a correction.