Configuring units of measurement in Bitrix: where accounting breaks down
Units of measurement in Bitrix live in three independent places: the catalog reference book, the cart and order, and the exchange with 1C. As long as the values match, no discrepancies are visible.
As soon as a "kg" with a coefficient appears in the catalog, while in 1C the same product is exported in "g", the order goes out with a quantity of 0.5 instead of 500 — and from there it carries through the invoice, shipment, and closing documents.
The most common cause of failures is quantity rounding. The catalog settings define precision, and it does not match the precision that 1C expects during export.
An item with a fractional quantity is either rounded to a whole number and loses the remainder, or goes out with extra digits and breaks item matching.
The second source is a mismatch of OKЕI codes: the units reference book in Bitrix and the classifier in 1C are filled in manually and diverge by code rather than by name.
The third failure is when units in the order and in the catalog diverge after a product card is edited. Already-placed orders store their own value, new ones take the current one, and in reports the same item is counted differently.
This is an accounting error that is noticed not at the moment it appears, but during reconciliation — when the discrepancy has already accumulated.
The fourth is 54-FZ: the receipt is generated based on the unit from the order, and if it does not match the one sent to 1C, the item in the receipt and in accounting diverge.
We break down how configuring units of measurement in Bitrix is resolved at the level of the reference book, rounding, and export rules to 1C, so that accounting reconciles without manual corrections.
What a unified unit of measurement reference gives
Units of measurement in Bitrix live in two places: the reference in the catalog and the reference in 1C.
As long as they are not linked, every new item in the nomenclature requires manual reconciliation — the manager selects a code from the list, while the export from the accounting system brings its own value.
The discrepancy does not surface immediately: the product is sold, the stock is written off, and only when reconciling warehouse balances does it become clear that "pack" and "packaging" are two different records about the same product.
A unified unit of measurement reference eliminates this class of errors at the data level.
We bring the codes into line with the all-Russian classifier, match the catalog and 1C records once, and fix the correspondence in the exchange settings — after that, synchronization proceeds without manual involvement.
New nomenclature arrives with an already filled-in unit rather than an empty field that someone has to close.
What this changes in numbers. Manual edits for units of measurement disappear from the daily work of managers — their share drops to isolated cases when a genuinely new unit appears.
Product balances stop "doubling": write-offs and receipts go by a single record, so the actual stock on hand matches the data in the system. Order accuracy grows because the quantity in the document and in the receipt is calculated from the same unit.
A separate effect is correct receipts. Cash register equipment under 54-FZ prints the name and measure of quantity from the reference, and if the unit code is not matched, a default value goes into the receipt.
After putting the reference in order, the unit of measurement in the receipt corresponds to the one specified in the product card, and no discrepancies arise during inspection.
Setup takes less time than the subsequent reconciliation of balances: the main work is a one-time matching of codes and checking the exchange on a test export.
After that, the unit of measurement reference maintains itself, and manual edits are reduced to adding new entries to the classifier.
Conversion factors and quantity precision
The base unit is the one in which the system stores the stock balance in the warehouse. The trade unit is the one in which the product is sold and appears in documents: a pack, a box, a pallet. A conversion factor is set between them, and this is exactly where precision is most often lost.
If the base unit is a piece and the trade unit is a pack of 12 pieces, the factor must be a whole number. As soon as a fraction appears (base unit is a kilogram, trade unit is a 0.435 kg pack), rounding error begins to accumulate.
The warehouse counts the balance in base units, documents are in trade units, and on every conversion back and forth the system rounds according to the configured quantity precision.
Over a hundred operations, the discrepancy between the stock register and the actual on-hand quantity becomes noticeable, and stocktaking turns into an investigation of causes.
1С and Bitrix store quantity with different digit capacity: in exchange via CommerceML, the value is exported with the number of decimal places configured in the export.
If the precision in the catalog and in the accounting system do not match, during synchronization the quantity gets "fractured" — 0.999 instead of 1, and the item goes negative while the balance is formally positive.
A practical rule: the conversion factor is made a whole number wherever possible, and quantity precision is set identically across all circuits — in the product card, in the exchange settings, and in the accounting system.
For weighed goods, the gram is taken as the base unit rather than the kilogram: then no fractions arise in the conversion at all.
Methods of managing units of measurement: comparison of approaches
Units of measurement in Bitrix can be managed in four ways, and the choice affects how exports to 1C, receipts, and reports will behave. Below is a comparison based on the criteria that matter most to the client: when an approach is suitable and where it starts to get in the way.
| Option | When it is suitable | Limitations |
|---|---|---|
| A single OKЕИ reference catalog for all sites | One catalog, shared nomenclature, export to 1C comes from a single place | Any change to a unit code affects all sites at once — regression testing of receipts and exchange is required |
| Separate reference catalogs per site | Multi-site setup with different markets and different OKЕИ codes for the same product | Data duplication, desynchronization during exchange, more difficult consolidated analytics |
| Manual entry in the product card | One-off items, services, non-standard units | Typos and different spellings of the same unit break reports and export |
| External source (1C as the master) | 1C is the accounting system, the site is only a storefront | The site depends on exchange availability; if it fails, new units do not appear |
The difference shows up at the junctions: in 1C a unit is stored according to the classifier, in a receipt for 54-FZ a correct code and conversion factor are required, and on the site a name understandable to the buyer is needed.
If the reference catalogs per site diverge, the same product goes into the accounting system with different codes, and the exchange starts complaining about a nomenclature mismatch.
We usually recommend a single OKЕИ reference catalog as the master source, and closing the differences between sites by linking to trade offers rather than with a second reference catalog.
That way multi-site does not turn into a separate accounting reality, and export and receipts remain predictable.
Implementation order: from audit to handover
We start with an audit: we export all unit of measurement values that have already accumulated in the catalog, orders, warehouse stock, and documents.
At this step, it becomes clear where the reference list has diverged from the accounting system — duplicates like "pcs" and "piece", items without an OKEI code, units that are not in the classifier.
Next, we design the target reference list: we match each item with an OKEI code, determine for which units fractional packaging is needed and for which only whole values are allowed.
- Reference list audit. We consolidate units from the catalog, orders, warehouse, and accounting system into a single mapping table, and record discrepancies and duplicates.
- Reference list design. We approve the list of units with OKEI codes, rounding rules, and the allowable precision for weight- and volume-based items.
- Integration setup. We define the unit mapping between the website and the accounting system so that during nomenclature export and order export the value is neither substituted nor lost.
- Testing on real orders. We run through checkout, payment, and order transfer to accounting, including items with fractional quantities and products with multiple units.
- Verification against receipt requirements. We check that the correct name and unit are sent to the receipt, and that the quantity calculation matches the order.
- Handover of regulations. We provide the mapping table, instructions for adding new units, and the procedure for handling discrepancies.
Each stage ends with a verifiable result rather than a report: after the audit — an agreed mapping table, after integration setup — a test order that goes through the entire path without manual adjustments.
This order of work makes it possible to change the reference list on a live website: old orders retain their historical values, while new ones are placed according to the approved rules.
What the client receives after setup
Setting up units of measurement does not end with a "checkbox in the admin panel," but with a set of artifacts that the system continues to run on without us.
Each item below is what actually remains with your team: it can be opened, verified, and handed over to a new engineer.
- A completed units reference — a table with OKЕИ codes, national designations, and conversion factors to the base unit for each item in the nomenclature. No "pcs.," "pack," "set" mixed together: one item — one storage unit, the rest are maintained as packages with an explicit factor.
- Conversion rules — a fixed logic for translating between storage, purchasing, and sales units: where the factor is applied on the fly, and where a separate record is stored. This eliminates discrepancies when goods arrive in boxes but are sold by the piece.
- Exchange settings — configuration for exporting nomenclature and documents between the website, the accounting system, and the cash register loop: which unit fields go out, in what form they come back, and what happens when codes mismatch.
- A mapping scheme — a map showing which website unit is linked to which accounting unit and how this is reflected in the receipt under 54-FZ requirements. Useful when adding new product groups.
- Documentation — a description of the reference, conversion rules, and exchange points in your team's language: what can be changed independently, and what requires edits in conjunction with the accounting system.
- A support procedure — the sequence of actions when adding a new unit or changing a factor: who approves it, in what order the reference is edited, and how it is verified that the conversion has not shifted in already-closed documents.
- A verification protocol — a set of control operations: a test export, reconciliation of balances in different units, a receipt run-through. You use it to accept the work and repeat the check after any edits.
This set is sufficient for units of measurement to stop being the point where the website, warehouse, and cash register diverge. Describe your system setup — we will get back to you with an estimate and a work plan for the reference and exchange.
What is the difference between a storage unit and a sales unit?
A storage unit is what a product is kept in at the warehouse and accounted for in stock: a box, a pallet, a roll, a package. A sales unit is what the customer buys it in: a piece, a meter, a kilogram, a serving.
In the Bitrix catalog these are two different fields, and they must not be confused: the system calculates the warehouse by the storage unit, and the order line and document by the sales unit.
The difference shows up at the moment of checkout. The customer orders 3 pieces, while the warehouse records 1 box of 10 pieces — without conversion the stock will be written off incorrectly, and the product will either "get stuck" or go negative.
That is why a conversion factor is set between the warehouse and sales units: it links the quantity in the order to the quantity in stock and in receipt documents.
In 1C this link lives in the item reference book: a position has a base storage unit and a sales unit, and conversion is performed by the factor. Bitrix receives stock already in the storage unit and converts it into the sales unit when the order is exported.
If the factors in the two systems diverge, stock will start to "drift": the site shows availability that does not exist, and the exchange records a discrepancy.
Conversion is not always needed. When a product is sold and stored in the same unit — piece for piece — a single value is enough, and extra fields only confuse managers.
Conversion is enabled where the warehouse operates in packages while the customer buys by the piece: building materials, metrage, weight, liquids, goods in boxes and pallets.
For 54-FZ the sales unit matters: it is what goes into the receipt as the unit of measurement according to OK 015.
If the order specifies a "box" but the receipt must carry a "piece" with the correct code, conversion must be configured before fiscalization — otherwise the receipt diverges from the actual sale.
The check is simple: take a position with conversion, place an order in the sales unit, and trace the path — the stock at the warehouse, the document in 1C, the line in the receipt. If the quantity matches at all three steps, the storage and sales units are configured correctly.
Case: cleaning up units of measure on a live website
The client is a wholesale supplier of building materials running 1C:Trade Management and a Bitrix-based website. The catalog contains several thousand SKUs; some products are sold by the meter, some by the pack, and some by the piece with a multiplier.
Units of measure in the product cards had been entered over the years by different employees: in some places "m", in others "meter", in others "linear m", while in 1C the same item was listed as a pack. An order would go into reserve with a quantity the warehouse could not ship.
What it was like before
The share of orders where a manager manually corrected the quantity after checkout held steady at 18-22%. Each correction meant a call to the client, recalculating the line, and re-exporting to 1C; sorting out a single cart took from 15 to 40 minutes.
Discrepancies between the website and the accounting system surfaced on average 60-80 times a month, and almost every one of them triggered a manual adjustment of a document.
What was changed
The units-of-measure reference was consolidated into a single set of codes and reconciled with the classifier used by 1C.
For items with a multiplier, a conversion factor was set so that the website operates with the base unit while the accounting system receives the quantity that is actually shipped.
A check was added at the checkout stage: if the unit in a product card is not mapped to the 1C reference, the item does not make it into the order — instead of a silent error, the manager sees the specific item.
Separately, historical product cards were run through and the discrepancies that had accumulated before implementation were fixed.
What it became
The share of orders with manual quantity correction dropped from 18-22% to 2-3% — those are the cases where the client changes the volume themselves in the cart.
The time to sort out a single cart fell from 15-40 minutes to a couple of minutes, and quantity discrepancies with 1C went from 60-80 down to just a few per month, each one traced to a specific item rather than requiring a search across the entire catalog. Managers are no longer a buffer between the website and the warehouse.
Common technical concerns about units of measurement
Units of measurement are the point where the catalog, warehouse accounting, and fiscal contour converge.
That is why concerns here are usually not about "which code to choose," but about compatibility with an already working system: your own reference list, fractional quantities, and exchange with 1C. Below is an analysis of typical situations that come up before launch.
We already have our own unit of measurement reference list deployed — do we have to redo everything?
No. First, we map it out: which codes are used in product cards, which go to 1C, which end up on receipts. Then we match them against the OKEI classifier and add the missing entries without touching the working ones.
A full replacement is only needed where the reference list is maintained manually and codes do not match between systems — in that case, migration goes by a mapping table, not "head-on."
What about fractional quantities — 0.5 kg, 1.25 m?
A fractional quantity requires that precision be aligned at all levels: in the product card, in the warehouse settings, and in the rounding rules when exporting to 1C.
If rounding to a whole number is set somewhere, an order for 0.5 kg will turn into 1 kg or 0 — and this will surface later in warehouse discrepancies. We set a single precision and verify it on test orders before launch.
Will the exchange with 1C break after the edits?
The exchange breaks not from the units themselves, but from mismatched codes and multiplicities. Before making changes, we record the current mappings, run a test export, and reconcile the nomenclature, quantity, and prices on both sides.
If the unit code in the catalog and in 1C do not match, the product will either fail to export or go out with the wrong quantity — that is why reconciliation happens before, not after.
What about receipts and 54-FZ?
In a fiscal document, the unit of measurement and quantity must be consistent with what was actually sold. A fractional quantity on a receipt is permissible, but only if precision and rounding are configured identically in the catalog, in the warehouse, and at the point of sale.
Otherwise the receipt will diverge from the order, and that is already a matter not for the website but for reporting.
If your situation is not on the list — describe how your reference list and exchange are currently set up, and we will come back with an estimate and a migration plan.
Let's discuss your task around units of measurement
Setting up units of measurement in Bitrix is rarely an end in itself — it usually comes up when the catalog is already live, and prices, stock, and receipts diverge between the website, the warehouse, and the point of sale.
If that's your situation, describe it as it is: which units are currently set up, where the data comes from, and exactly where the recalculation breaks down. That's enough to understand the scope of work and come back with an estimate and a plan.
To keep the conversation concrete, it helps to gather the inputs right away:
- which units of measurement are used in the catalog and how many there are — pieces, meters, kilograms, packs, services;
- whether there are products with fractional quantities and how they are sold — by the piece, by weight, in multiples of a pack;
- where the item master data comes from — from 1C, from supplier price lists, or entered manually;
- how units are linked to conversion factors between the base unit and the warehouse unit;
- what is printed on receipts and invoices and whether it requires compliance with the OKЕИ classifier;
- which reports and exports depend on units — stock, sales, cost of goods;
- how quantity and price rounding is configured so that no fractions and "leftovers" appear in line items.
From these answers it becomes clear whether a targeted setup of the reference book is needed or a rebuild of the link between the catalog, the warehouse, and the exchange with the accounting system.
We'll come back with a scope estimate, a phased plan, and a list of what will be required on your side — access, a test environment, and a contact from accounting or the warehouse.
Let's discuss the task — and then you decide whether to start the work or first test the hypothesis on a single catalog section.