Order quantity step in 1C-Bitrix: where the cart breaks
The order quantity step in 1C-Bitrix surfaces not in the catalog but at the last checkout step.
The quantity step is set separately for the catalog and for the cart, is overridden by a trade offer, and some items come from 1C with their own sales unit — pack, pallet, multiple delivery.
While the customer adds the product manually, the discrepancy is invisible; as soon as the system substitutes the quantity, a non-multiple quantity appears in the cart.
There are plenty of sources for substitution: warehouse inventory balances, order repeat from history, recalculation when changing a trade offer, a gift or set under a discount rule, bulk upload from the accounting system.
Each source writes its own number, and the quantity step check in the cart is often disabled — it was assumed this point would never be reached.
Then the chain breaks. The unit price is recalculated, the total with delivery drifts, the warehouse shows availability that does not exist, and the order goes to 1C with a quantity that does not pass accounting rules.
The first to suffer are unverified areas: the checkout page, delivery calculation, exchange with the accounting system. The manager fills in order clarifications manually — a call, an email, re-approval.
At the same time, checkout errors rarely look like a failure: the order is created, the email arrives, payment goes through, and the discrepancy surfaces in the warehouse or during reconciliation.
That is why we analyze exactly where the quantity step rules diverge between the catalog, cart, and 1C and how to close this without manual clarifications.
What a correct quantity step in the catalog and cart gives
The quantity step in the catalog and cart is one rule for the entire order chain. If the product card returns a multiple of 5, and the cart does not check the value, the customer enters 3, and the manager edits the item manually.
That is why the quantity step (STEP_QUANTITY) is set both in the product property and in the add-to-cart handler: the interface on the 1C-Bitrix platform simply does not allow entering a number that is not a multiple of the base unit.
The cart maintains the step without manual edits
A unified step in the cart removes a whole class of errors such as “the item is ordered not as a whole pack.” The quantity remains a multiple at all steps — adding from the catalog, changing in the cart, repeat order from history.
Manual order edits become exceptions: the manager processes a non-standard customer request deliberately, not because the field allowed any number.
Quantity rounding at input, not in the accounting system
Quantity rounding triggers at the moment of input: the hint in the field and auto-substitution of the nearest multiple value show the logic immediately.
The manager does not recalculate lines before uploading to 1C, and discrepancies like “7 ordered, 5 shipped” stop reaching the warehouse.
Fewer order re-approvals
The share of re-approvals falls: the customer sees the correct total in the cart, erroneous volumes do not reach confirmation. Deadlines and delivery are calculated based on actual quantities, not those edited after the parties agreed.
Ways to set the quantity step: properties, rules, handlers
The order quantity step in 1C-Bitrix is set by three mechanisms, and they are not interchangeable: the step in the product card, checkout rules, and cart handlers. The choice depends on whether the item has trade offers and whether the step should be unified for a product group.
Comparison of methods
| Method | When it fits | Limitations |
|---|---|---|
| Product property | Constant step for an item, simple catalog without offers | Does not distinguish trade offers; for a product group the value is duplicated manually |
| Checkout rules | Need a multiple for the entire cart: minimum batch, pack | The check triggers at checkout — the customer learns about the restriction late |
| Cart handlers | The step depends on the warehouse, supplier, or selected offer | Require maintenance during updates; an error breaks add-to-cart |
What to choose
The property sets the base step and works without code, but as soon as trade offers with different packaging appear, it is not enough.
The handler overrides the step selectively and can calculate a multiple for a product group, but its behavior must be rechecked after every platform update.
Quantity rounding rules must match the step: if the cart brings the quantity to one value and checkout checks another, the customer gets a rejection at the last step.
That is why on the test bench we run scenarios with offers, partial packs, and warehouse changes — this way the boundaries of each method are visible before launch.
Work order: catalog audit, setup, verification, handover
The order quantity step is not one field in the settings but a bundle of the catalog, cart, and exchange with the accounting system.
That is why the work goes from data inventory to scenario verification: editing on a live site without an audit almost always produces orders with fractional quantities that then fail to post during upload.
- Catalog audit. We export products and trade offers, mark items where the step differs: piece, weight, sold in packs. We check units of measurement and minimum quantity — discrepancies in them break the cart even with the correct step.
- Test copy of the site. We deploy a copy with the current database and replicate the catalog configuration: the setup is tested on real data, and the production site remains available to customers.
- Step setup. We set STEP_QUANTITY for the catalog and selectively for sections and items, define the rounding rule for manual input so the customer cannot order an unavailable volume.
- Cart verification. We run scenarios: adding from the list and product card, changing quantity, repeat order, checkout with delivery. We separately check recalculation when changing a trade offer.
- Exchange verification. We make sure that orders go to the accounting system with a quantity that is a multiple of the step and return with statuses without manual edits.
- Setup acceptance. We go through the checklist together with your team: control products, boundary values, mobile version. We make edits before signing.
- Guidelines for managers. We hand over instructions: where to change the step for a new product, how to answer a question about quantity, whom to contact if there is a discrepancy with the accounting system.
What you keep: settings, diagrams, guidelines, documentation
We hand over not only a working quantity step but the entire contour that supports it. This means that when the assortment, supplier, or sales logic changes, your team can change the quantity step independently — without deciphering someone else’s code and without contacting us.
- Settings package. Quantity step by product types and trade offers, rounding rules at input and in the cart, behavior with partial warehouse availability.
- Catalog relationship diagram. Which sections, properties, and offers are tied to the quantity step, where the value is inherited, and where it is overridden manually.
- Instructions for the content manager. How to create an item with a quantity step, what must be filled in, and how not to disrupt the step for already configured products.
- Order processing guidelines. What to do with a quantity that is not a multiple of the step: an order from an external system, a repeat from history, an item discontinued.
- Step documentation. Where the value is changed, which templates output it, and how to restore previous behavior if the rule is canceled.
- Acceptance checklist. Scenarios that we run before handover: adding to cart, editing quantity, recalculation at checkout, repeat order.
Everything is described so that a new administrator can figure it out without correspondence with us — for each item we record the responsible person in your team.
Wholesale catalog case: metrics before and after setup
A wholesale catalog with multiple packs was assembled manually before setup: the customer entered any quantity, and the manager after checkout checked it against the supplier’s packaging norm.
Orders with “uneven” quantity went to re-approval — the customer was called, details were clarified, and sometimes the shipping list was corrected already at the warehouse.
The quantity step was moved into the product card and the cart calculation rules: the quantity step is taken from the specific supplier’s pack and recalculated when the warehouse changes.
The customer sees the price immediately for the multiple value, and the manager receives an order ready for shipment without manual adjustment.
Metrics before and after
| Metric | Before setup | After |
|---|---|---|
| Share of orders with manual quantity edits | 41% | 7% |
| Re-approvals of shipment terms | every fourth order | less than one in twenty |
| Time for the manager to assemble an order | 14–16 minutes | 3–4 minutes |
| Quantity step errors found at the warehouse | 6–9 per week | isolated cases |
Measurements were taken from checkout events in Yandex Metrica and compared with the order change log in the accounting system — there were no discrepancies.
Two months later, the share of manual edits remained below 10%, and re-approvals stopped being a regular burden on the sales department.
We separately fixed the rule: when the supplier’s pack changes, the quantity step is updated in one place and does not require manual edits in product cards.
How does the quantity step differ in the catalog and in the cart?
The quantity step lives in two independent places. In the catalog it is set by a product or trade offer property (in templates this is STEP_QUANTITY) and controls the selection in the product card: how many units the customer can take in one operation.
In the cart it is a separate component parameter and checkout rules parameter — it checks the already added quantity and does not have to match the catalog one.
When adding to the cart, recalculation occurs: the catalog value is brought to the cart step, not vice versa. If the cart step is smaller, the customer will see a non-multiple item — for example, three pieces with a step of two, and the manager will deal with this manually. That is why both parameters are configured consistently.
Step inheritance works by hierarchy: a trade offer may not have its own value and take it from the parent product, and the product from the section. When the chain breaks, the default value from the module settings is substituted.
The behavior when loading the list depends on what the server returned in the markup. When a section is loaded or a trade offer is changed, the values are read again, and if the step was changed by a script after rendering, the field will return to the original.
At checkout, a separate server-side multiple check is needed at the moment of saving. Without it, the restriction is bypassed by modifying the request, and a non-multiple quantity appears in the order, which then breaks warehouse accounting and exchange with 1C.
Technical concerns about the step, rounding, and upload
The quantity step is set at the product level and inherited from the section: the item value takes priority; if it is absent, the parent setting is used.
Therefore one catalog can return a different step by section, and editing the value in a section does not affect items where the step is already explicitly specified.
The second source of discrepancies is exchange with the accounting system. If the step is included in the attribute mapping during upload, it is overwritten on every session and local edits in 1C-Bitrix are lost.
Balances come in the same package, and a step greater than the balance silently blocks the purchase.
What happens if the step is greater than the balance?
Rounding up hits the warehouse limit: with a step of 10 and a balance of 24, the customer will take 20. We configure a rounding-down rule to a multiple, or hide items with a balance less than the step.
Will the exchange overwrite the configured step?
It depends on whether the step is included in the upload property mapping. If yes — the value in the catalog is subordinate and is edited in the accounting system. If no — the step remains a local setting and survives the exchange.
Can a different step be set for sections?
Yes: the setting on a section sets a general rule, and the item overrides it for itself. For products with variants, the step is set at the offer level — otherwise a quantity that is not in stock goes to the cart.
What happens to the cart when the step changes?
Already added items keep their previous quantity until the customer rebuilds the order. That is why we perform the step change together with the cart recalculation rule and catalog reindexing.
Let's discuss the task: send the catalog structure and sales rules
The order quantity step is calculated from catalog data, not general agreements: the quantity step depends on units of measurement, pack multiples, price types, and warehouses from which availability is taken.
Before estimating, we will ask for materials — they show where the step is already set at the product level and where it needs to be derived from sales rules.
- catalog structure: sections, trade offers, binding of products to units of measurement;
- sales rules: minimum batch, pack multiple, step for piece and weight products;
- conversion coefficients if the product is sold both in packs and by the piece;
- price types and warehouses involved in calculating available quantity;
- customer roles and scenarios: retail, wholesale, partner terms — where the step differs;
- examples of orders that are currently placed in violation of the quantity step, with cart screenshots.
In response, we will come back with an estimate and work plan:
- map of the quantity step by product groups, indicating places of rounding up;
- procedure for calculating the step and recalculation rules when changing a unit in the cart;
- list of edits in checkout and in exchange with the accounting system;
- draft guidelines: how a manager changes the quantity step without developer involvement;
- setup timelines by stages and verification procedure before publication.
Describe the task and attach what you have at hand — we will come back with an estimate and work plan. If some data is missing, we will review the catalog and sales rules together and clarify what is missing on a call.