Wholesale Order Module Development for 1C-Bitrix

Bitrix wholesale order module: where the cart breaks

The wholesale cart breaks not at the checkout stage, but earlier — when prices, reserves, and limits are calculated in different places and do not reconcile with each other.

The retail mechanism of recalculating prices based on a single base price does not work here: for a wholesaler, the price depends on the contract, the batch volume, and the accumulated order history, so the Bitrix wholesale order module must calculate the cost by tiers, not by the last applied discount.

The first typical failure is price recalculation when the quantity changes. The customer adds an item, the cart recalculates the line, but does not recalculate the contract total, and at checkout the amount diverges from what the manager saw.

The second is product reservation: the wholesale cart holds large volumes, but the warehouse releases them to another order because the reserve is placed at the line-item level rather than at the warehouse and batch level.

The third is limits: deferred payment, credit limit, and minimum batch are checked at the moment of confirmation, not at the moment of adding, and the order goes into processing with an overage.

A separate pain point is partial shipment. When an order is split into several deliveries, statuses, reserves, and closing documents must move in sync, otherwise the order balance is counted twice, and the customer receives an invoice for what has already been shipped.

We break all of this down further — how the wholesale order module handles price recalculation, reserves, limits, and partial shipments at the logic level, rather than with hacks in the template.

What the reworked wholesale order module delivers

The reworked wholesale order module in Bitrix changes not the interface but the very logic of checkout: the cart calculates prices and availability by customer tier on the server side, rather than catching up to them with scripts in the browser.

Thanks to this, the speed of checking out a large cart increases severalfold — line items are recalculated in batches, without reloading the page on every quantity change.

The share of successful orders grows where the customer previously abandoned checkout: the wholesale order module in Bitrix automatically substitutes contractual price tiers, warehouse, and pack multiple, so the manager does not need to manually recheck every line.

Manual edits after the order is submitted are reduced — typical errors (wrong price tier, item out of stock, quantity not a multiple of the pack) are cut off at the input stage rather than surfacing in the invoice.

A separate effect is predictability for managers: the order arrives already with the correct price tier and reservation, so processing follows a single scenario rather than a phone call to the customer for every disputed line.

Below we break down how this is handled at the level of integration with 1C and price tier configuration.

Ways to Implement Wholesale Ordering: Comparing Approaches

The built-in Bitrix mechanism covers the basic scenario: cart, checkout, linking to the customer profile. The problem starts where wholesale requires its own rules — contract-based price lists, minimum order quantity, pack multiples, deferred payment. The further you move from retail, the more built-in settings turn into workarounds.

Customizing the component is the fastest path when wholesale logic fits into one or two checkout templates. A separate module is justified if pricing rules and limits live in 1C and must apply across all entry points: the website, the customer portal, the manager.

An external service is connected when the order goes into a third-party accounting system and Bitrix remains the storefront.

The choice is dictated not by the amount of code, but by where the rule lives. If prices and limits are calculated in 1C, a module with data exchange is more reliable than customizing a template: the rule changes in one place, not in every component.

Stages of wholesale order module implementation

We start the implementation of the wholesale order module not with code, but with an audit: we look at how prices and discounts are currently structured, where stock is stored, who buys and on what terms.

At this step it becomes clear which rules will have to be transferred into the system and which should be rebuilt — otherwise the module will simply cement the current chaos in the price lists.

1. Audit of processes and data. We analyze the product nomenclature, customer groups, discount matrices, deferred payment terms and limits. We record which rules are calculated in 1C and which should work on the website side, and where the discrepancies between them currently are.
2. Interaction scheme. We design the exchange: which entities are synchronized, at what frequency, and what happens in case of a data conflict. We determine how the order is placed — via the cart, a quick order by SKUs, or uploading a list as a file.
3. Module configuration. We configure price types and their binding to customer groups, discount thresholds and rules, minimum order amount, packaging multiplicity, and deferred payment limits. For regular customers — personal terms and purchase history in the personal account.
4. Integration with the accounting system. We link orders, stock, and payment statuses with 1C, configure the export of nomenclature and prices, handle exchange errors, and set up re-sending in case of failure.
5. Testing on real scenarios. We run through typical and edge cases: a large order with mixed discounts, an item with zero stock, a price change between order placement and payment, cancellation of a line item. We reconcile the result in 1C with what the customer sees.
6. Handover and training. We provide access credentials, instructions for managers and customers, and show where to view the exchange log and how to respond to discrepancies.

After launch, we support the exchange and discount rules for the first few weeks — on a live flow of orders, situations arise that were not present in the test data. Describe how your wholesale sales are structured, and we will get back to you with an estimate and a work plan.

What the client receives

We hand over not a "finished module" but a package that your team can use to operate and develop it without us. Everything described below is recorded in the project repository and wiki, not left in a chat thread.

• Module configurations: settings files for price groups, discount recalculation rules, minimum order thresholds, and warehouse binding — with comments explaining which parameter affects what.
• Exchange schemas: data flow diagrams between the website, 1C, and warehouse accounting — what is synchronized and in what order, where the failure points are, and how they are handled.
• Access policies: a role matrix for wholesale buyers — who sees purchase prices, who places orders, who approves limits; separate rules for managers and for the integration exchange user.
• Documentation: a description of the module structure, extension points, and the update procedure when new platform versions are released.
• Operational regulations: the procedure for launching a full exchange, actions to take when stock balances diverge, and rules for rolling back to a previous configuration.
• User instructions: how a manager checks an order, how a buyer repeats a previous purchase, and what to do when a line item is rejected.
• A set of test scenarios: checks on typical wholesale orders, including edge cases for quantity and price.

Separately, we provide a changelog and a list of improvements that we deliberately chose not to make in the first version — so that you understand the boundaries of the solution and can plan its development. Describe your task — we will come back with an estimate and a plan.

Case study: how a wholesale order became 3x faster

The client is a distributor of construction chemicals with an assortment of several thousand SKUs and a pool of regular contractors.

Managers took wholesale orders manually: the client sent a list by email or messenger, the manager verified SKUs, recalculated prices using their own discount column, and entered the order into 1C.

For a large order of 80-120 lines, this took up to 40 minutes, and discrepancies in SKUs and pack multiples surfaced only at the picking stage.

1C-Bitrix was already in place as the catalog foundation, so no separate system was introduced — the existing environment was extended.

What was changed

We built a wholesale order module: a personal account with an individual price list and discount matrix, file-based order upload, and one-click repeat of previous orders.

The module automatically validates SKUs, pack multiples, and stock, recalculates prices according to the client's contract, and passes the finished document to 1C via integration — with no manual transfer.

Before and after metrics

Order processing time was cut by three times — mainly because the client assembles the order themselves, while prices and stock are populated on the fly.

Errors disappeared not because managers became more attentive, but because SKU and pack multiple validation now sits with the module rather than a human. The two remaining manual operations are approval of a non-standard discount and confirmation of deferred payment.

Two months after launch, the share of orders placed through the account reached 70% of the total wholesale flow, with the rest being large tender orders that managers deliberately handle manually.

How is a wholesale order different from a retail order in Bitrix?

A retail order in Bitrix is a single item or a cart tied to one warehouse and one price from the catalog.

A wholesale order follows different rules: the price depends on volume and the contract with the client, the quantity is limited by the minimum batch and the packaging multiple, and shipment almost never happens in full at the moment the order is placed.

The first dividing line is price levels. In retail there is one price, at most a promotional discount. In wholesale, a grid applies to the same item: base, dealer, distributor, plus individual terms under a specific contract.

The module must substitute the required level based on the buyer's profile and recalculate the cart when the volume changes, rather than giving one price to everyone.

The second is the minimum batch and multiple. A wholesaler cannot order three units if the packaging comes in twelves, and the minimum shipment amount is tied to the contract.

Checks trigger at the stage of adding to the cart, not at checkout, otherwise the client learns about the restriction at the worst possible moment.

The third is reserves and partial shipments. A retail reserve lives until payment and is released automatically.

In wholesale, goods are reserved for a specific request in the warehouse, can be shipped in parts as they arrive, and the remainder is carried over to the next delivery. Without this, the warehouse and the sales department work from different data.

The fourth is document flow. A retail sale is closed with a receipt, a wholesale one with an invoice, a delivery note, a VAT invoice, and a reconciliation, which must match the order in Bitrix.

That is why a wholesale module is designed together with 1C integration, and not as an add-on over the retail cart.

Common technical concerns

A wholesale ordering module is not a separate script layered on top of the cart, but a logic layer between the catalog, prices, and the accounting system.

That is why customers' concerns are usually the same: not "will this break the site," but "how will it behave under a real order flow and what happens when the platform is updated."

Below are the questions that most often come up during the evaluation stage, with technical answers.

How does the module work with 1C and will it create double accounting?

The source of truth for nomenclature, stock, and prices is the accounting system; the site receives data via exchange and does not store it as a "second truth." The order goes to 1C as a document, statuses come back, so the warehouse and the site do not diverge.

The exchange runs in batches with idempotent processing: a repeated export does not duplicate line items, and any stock discrepancy is visible in the log rather than surfacing for the customer at checkout.

Will the catalog with tens of thousands of items and wholesale carts hold up?

The bottleneck of wholesale ordering is not the catalog, but the recalculation of prices and discounts on a large cart. We calculate prices by tiers in batches, cache reference data and selection indexes, and move heavy operations to background jobs.

A cart with hundreds of lines is recalculated without reloading the page, and checkout does not block other shoppers.

How are access rights separated and prices protected?

Wholesale prices and terms are tied to the buyer company and its contract, not to the browser session, so tampering with data on the client side achieves nothing. Permission checks and price recalculation are duplicated on the server on every action.

Access to wholesale sections is closed to guests and retail users, and managers' actions on other customers' orders are logged.

If you still have questions about your configuration, describe the task: what price tiers you have, how the exchange with 1C is set up, and what order flow you expect. We will get back to you with an estimate and a work plan.

Let's discuss your wholesale order task

To make the estimate for the wholesale order module accurate rather than an "average market" figure, we need to understand your specifics: how the price for a wholesaler is formed, where stock balances come from, and who approves the order and how.

The more specific the inputs, the fewer assumptions in the plan and the more predictable the timeline. Below is what's worth clarifying and what data to prepare before the conversation.

What we clarify at the start

• How wholesale orders are currently accepted: manually by a manager, via email, by exporting to a spreadsheet, or whether a draft customer portal already exists.
• Where prices and discounts come from: a separate price type in 1C, a cumulative scale, contractual terms per customer.
• How stock balances and multiples are calculated: by warehouse, by batches, with or without reservation for the order.
• Who approves the order and at what stage: the manager, finance, the debt limit per counterparty.
• How the order goes into accounting: real-time exchange with 1C, on a schedule, or via a file.
• Roles and access: wholesaler, manager, regional representative — each has their own set of permissions and price visibility.

What to prepare for the conversation

• An example of a real wholesale order: what it looks like from request to shipment, with all approvals.
• Screenshots or a description of the current portal, if one exists, and a list of what doesn't work for you in it.
• The exchange scheme with 1C: which configuration, what's already set up, which entities are synchronized.
• The pricing and discount rules as applied by the sales department.
• Constraints on timelines and phasing: what needs to launch first, what can wait.

Based on the conversation, we'll come back with an estimate and a plan: we'll break the scope into stages, fix what's included in each, and mark the points where your decision will be needed. Describe your task — we'll clarify the details and prepare a proposal tailored to your process.