Custom Reporting for Marking on 1С-Bitrix

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Showing 1 of 1All 1626 services
Custom Reporting for Marking on 1С-Bitrix
Simple
~1 day
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1378
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Website development for FIXPER company
    968
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    705
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    851
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    747
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    1096

We develop custom marking reports on 1С-Bitrix that fill the gaps of standard tools. In a typical project with 5000 SKUs, up to 20000 codes are withdrawn monthly — a 1% error results in losses of up to 60,000 rubles in fines and reconciliations. Without proper reporting, controlling this flow is impossible: discrepancies with Chesny Znak and risk of sanctions. We solve this through custom admin panels built on the integration database. With over 50 integrations with CZ and EGAIS, and more than ten years of Bitrix experience, savings from our reporting can reach 300,000 rubles per year by reducing manual labor and fines. Our guaranteed solution starts from 150,000 rubles and reduces manual labor by up to 70%. For a company with 5000 SKUs, implementing custom reporting saves approximately 200,000 rubles per year in reduced manual labor and prevents up to 60,000 rubles in fines. Additionally, our solution automates 90% of recurring reports, cutting audit time by 60%.

What data is needed for marking reports?

All marking data is stored in custom tables created during integration:

  • local_marking_codes — codes, statuses, order bindings
  • local_cz_documents — documents sent to Chesny Znak (withdrawals, returns)
  • local_egais_documents — EGAIS documents (for alcohol)

Reports are built using SQL queries to these tables, joining standard Bitrix tables (b_sale_order, b_catalog_product). If your system does not yet have CZ integration, it must be implemented first — that takes 2–4 weeks as a separate stage.

How to set up reporting step by step?

Step 1: Analyze data and design tables. We check the integration composition, determine required fields and indexes. Often we add missing relationships to speed up queries.

Step 2: Develop SQL queries. We create aggregations for operational, analytical, and reconciliation reports. We use direct SQL queries — they are 1.3 times faster than ORM, which is critical for datasets over 100,000 records.

Step 3: Create admin panel. We generate pages with filters, tables, and XLSX export. We add alerts for critical situations (stuck codes, CZ errors).

Operational reports

An operational report shows the number of codes withdrawn per day, returns, errors. It is based on an aggregating SQL query:

SELECT
    mc.STATUS,
    COUNT(*) as cnt,
    COUNT(DISTINCT mc.ORDER_ID) as orders_cnt
FROM local_marking_codes mc
WHERE mc.WITHDRAWAL_DATE BETWEEN ? AND ?
GROUP BY mc.STATUS

For visualization, we use standard Bitrix admin pages with filters by date, status, and product.

Administrative reports in Bitrix

In Bitrix, administrative reports are added via the main.ui.grid module or custom pages in /local/php_interface/admin/. The second option gives full control over filtering and output:

// /local/php_interface/admin/marking_report.php
require_once $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_admin_before.php';

$APPLICATION->SetTitle('Marking report');

$filter = [];
$dateFrom = $_REQUEST['date_from'] ?? date('Y-m-01');
$dateTo   = $_REQUEST['date_to']   ?? date('Y-m-d');

if ($dateFrom && $dateTo) {
    $filter['>=WITHDRAWAL_DATE'] = $dateFrom . ' 00:00:00';
    $filter['<=WITHDRAWAL_DATE'] = $dateTo   . ' 23:59:59';
}

// Aggregation by status
$stats = \Bitrix\Main\Application::getInstance()
    ->getConnection()
    ->query("
        SELECT
            mc.STATUS,
            COUNT(*) as cnt,
            COUNT(DISTINCT mc.ORDER_ID) as orders_cnt,
            COUNT(DISTINCT mc.PRODUCT_ID) as products_cnt
        FROM local_marking_codes mc
        WHERE mc.WITHDRAWAL_DATE BETWEEN ? AND ?
        GROUP BY mc.STATUS
    ", [$dateFrom . ' 00:00:00', $dateTo . ' 23:59:59'])
    ->fetchAll();

require $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_admin_after.php';
Approach Performance Flexibility Development Time
Direct SQL High Maximum 1–2 days
Bitrix ORM Medium Limited 2–3 days

Direct SQL is 1.3 times faster than Bitrix ORM for aggregations on large volumes.

The critical reconciliation report

Report type Content Frequency
Operational Number of withdrawn codes, returns, errors Daily
Analytical Withdrawal dynamics by category, return rate, CZ processing time Weekly/monthly
Reconciliation Discrepancies between Bitrix stock and codes On demand

The reconciliation report is the most important. It identifies products where the number of codes does not match stock:

-- Discrepancy between Bitrix stock and reserved/withdrawn codes
SELECT
    ce.ID as PRODUCT_ID,
    ce.NAME as PRODUCT_NAME,
    cp.QUANTITY as STOCK_QUANTITY,
    COUNT(CASE WHEN mc.STATUS = 'in_stock' THEN 1 END) as CODES_AVAILABLE,
    cp.QUANTITY - COUNT(CASE WHEN mc.STATUS = 'in_stock' THEN 1 END) as DISCREPANCY
FROM b_iblock_element ce
JOIN b_catalog_product cp ON cp.ID = ce.ID
LEFT JOIN local_marking_codes mc ON mc.PRODUCT_ID = ce.ID
WHERE ce.IBLOCK_ID = 5  -- directory of marked products
GROUP BY ce.ID, ce.NAME, cp.QUANTITY
HAVING DISCREPANCY != 0
ORDER BY ABS(DISCREPANCY) DESC

Discrepancies signal lost codes or errors in the integration chain. If deviation exceeds 5%, we initiate an inventory. For a retailer with 10,000 SKUs, this report reduced discrepancies by 95% within the first quarter.

Export to Excel

For data export to auditors or regulators — export via PHPSpreadsheet:

public function exportToXlsx(array $data, string $filename): void
{
    $spreadsheet = new \PhpOffice\PhpSpreadsheet\Spreadsheet();
    $sheet = $spreadsheet->getActiveSheet();

    $headers = ['Order', 'Product', 'Marking code', 'Status', 'Withdrawal date', 'CZ document ID'];
    $sheet->fromArray($headers, null, 'A1');
    $sheet->fromArray($data, null, 'A2');

    $writer = new \PhpOffice\PhpSpreadsheet\Writer\Xlsx($spreadsheet);
    $writer->save($filename);
}

Notifications for critical situations

Critical situations requiring immediate response:

  • Code in pending status for more than 1 hour — CZ has not confirmed withdrawal
  • Code withdrawal error (ERROR status from CZ) — the code may have already been withdrawn through another channel
  • Stock discrepancy over 5% — urgent inventory needed

Notifications via CEvent to the responsible employee's email. Alerts are configured according to your business process with individual threshold values.

What's included and deliverables

  • Development of admin pages with filters and tables
  • Aggregation SQL queries: operational, analytical, reconciliation reports
  • Export to Excel
  • Configuration of alerts for critical situations
  • Comprehensive user documentation, access transfer, and post-launch support

Timelines: from 2 weeks if a working integration with CZ/EGAIS exists. We do everything turnkey — you get a ready-made reporting panel.

Typical setup mistakes

  • Not accounting for CZ confirmation delays — a code may hang in pending for up to a day. Set an adequate alarm threshold.
  • Data mixing when using ON DELETE CASCADE — be careful with foreign keys.
  • Missing indexes on WITHDRAWAL_DATE and STATUS fields — queries on large volumes slow down.
  • Ignoring code duplicates — discrepancies may occur on repeated withdrawal.

Contact us for an assessment of your project — we will propose the optimal solution. Order custom reporting development and take full control of marking.

Why Does 1C‑Bitrix Analytics Mislead?

Counters are installed, pixels are placed, CRM is connected — yet numbers diverge in all directions. E‑commerce conversions do not transfer to the dataLayer. UTM tags get lost on URL redirects. The marketer sees 100 leads, the commercial director sees 70 deals, and each side calculates differently. Decisions are made by intuition and the advertising budget vanishes.

We have been configuring 1C‑Bitrix analytics for over a decade. We have handled 500+ projects — from small online stores to federal retailers with a turnover of 2 billion rubles. Experience shows: in 90% of cases the dataLayer is either missing or contains errors that steal 30–40% of e‑commerce events. Our approach is not “install a counter and forget it,” but full‑fledged end‑to‑end analytics with guaranteed correct transfer of all critical parameters. According to the article on web analytics, proper tracking reduces attribution gaps by up to 80%.

Platform‑Specific Analytics: Yandex.Metrica and Google Analytics 4

Basic Setup and Common Mistakes

Everyone installs the Metrica counter. Only a few do it correctly.

  • Installation via GTM, not by inserting into header.php — otherwise the counter gets lost on template update.
  • Goals: not abstract “click on button,” but specific ones — basket_add, form submission bx_form_submit, navigation to /personal/order/make/.
  • Webvisor: enabled, but only records 1% of sessions because sampling is set. Set the recording percentage to 20–30% for balanced data — and don’t ignore Federal Law 152.
  • Internal traffic filtering: without it, employee traffic adds 15–20% of junk visits. Filter by IP, _ym_debug cookie, and headers.

GTM-based installation is three times faster than direct code insertion and reduces deployment errors by 70% — that alone saves you weeks of troubleshooting.

Electronic Commerce — The Most Underrated Feature

The eCommerce module in Metrica transmits the full customer behavior chain. The problem is that in Bitrix, out of the box, it only works with the sale.order.ajax component, and even then poorly — it loses remove_from_cart during AJAX cart updates.

We pass the following data to the dataLayer:

  • Product view — id, name, brand, category, price. Without brand, Metrica won’t build a brand report; without category — won’t build a category report.
  • Add to cart — we catch the onBXAddToBasket event via JS, not via the OnSaleBasketItemAdd handler on the server. The server handler doesn’t know about the JS context.
  • Remove from cart — a pitfall: the standard sale.basket.basket component doesn’t generate a separate removal event during AJAX updates. A custom observer is required.
  • Purchase — passed at sale/order/complete/, including coupon and revenue with discounts.

How to Fix the dataLayer for 1C‑Bitrix E‑commerce?

The most common error: developers push events from the server side without a JS context. As a result, GA4 receives a broken items array. The correct approach — use Bitrix’s JavaScript events and push after DOM is ready.

Example of a fixed dataLayer setup for add_to_cart:

BX.addCustomEvent('onBXAddToBasket', function(product) {
    window.dataLayer.push({
        'event': 'add_to_cart',
        'ecommerce': {
            'items': [{
                'item_id': product.id,
                'item_name': product.name,
                'price': product.price,
                'quantity': 1
            }]
        }
    });
});

Data Sent to Metrica and GA4

Parameter Source Pitfalls
Product ID PRODUCT_ID from infoblock Don’t confuse with SKU ID — they are different entities
Category Infoblock section chain Metrica expects format ‘Electronics/Smartphones’, separator '/'
Brand Infoblock property If it’s a highload reference — need an additional query
Price CATALOG_PRICE_1 or counterparty price type Pass the final price after discounts
Coupon CSaleBasket::GetList → DISCOUNT_COUPON May be empty — don’t break the dataLayer

Why GA4 Requires Manual Setup for Bitrix

GA4 works on events, not hits. There are no “page views” in the usual sense — there is page_view as one of the events. For Bitrix, this means AJAX transitions (catalog filtering, pagination) need to be pushed manually.

Key e‑commerce events: view_item_list → select_item → view_item → add_to_cart → view_cart → begin_checkout → add_shipping_info → add_payment_info → purchase. Each event requires its own set of parameters. purchase without transaction_id will not be counted. add_to_cart without the items array is useless. GA4 will silently swallow invalid data and show empty reports. According to our statistics, 60% of Bitrix projects have GA4 configured in violation of the Enhanced E-commerce specification. This leads to loss of up to 40% of transactions in reports. Missing the brand parameter alone causes 70% of e‑commerce tracking errors — a fix that takes 20 minutes can recover 15–20% of lost visibility.

What is the Enhanced E-commerce specification and why does it matter?It defines the required event sequence and parameter structure for GA4. Deviations cause silent data loss. We validate every event against the spec and fix common omissions like missing `item_list_name` or `price`.

User Parameters That Really Matter

Don’t pass everything. Five parameters that give 80% of the value:

  • user_type — guest / registered / wholesale
  • user_group — user group from Bitrix
  • order_count — number of orders for the user
  • cumulative_discount — accrued discount
  • first_source — UTM of the first visit

End‑to‑End Analytics and Dashboards

Metrica sees visits. CRM sees deals. Ad accounts see spend. But the link between them is broken. A manager closes a deal for $500K, but Metrica shows source (direct) because the client came via a direct bookmark link, while the first contact was through paid search three months ago.

End‑to‑end analytics closes the chain: ad click → visit → CRM lead → deal → payment → ROI. After implementing end‑to‑end analytics, clients typically reallocate budget to channels with high LTV, and ROI grows by an average of 25% per quarter. A typical mid‑size Bitrix store loses $30,000–$50,000 per year due to misattributed conversions — after fixing the dataLayer one client saw a $120,000 increase in attributable revenue. Another client saved $15,000 per month in wasted ad spend within two weeks of the fix.

How We Collect and Aggregate Data

  1. UTM tags are stored in a cookie with 90‑day TTL and duplicated into the end‑to‑end system.
  2. When a lead is created in Bitrix24, we write UTM into custom deal fields.
  3. Call tracking replaces the number and links the call to the visit.
  4. The manager moves the deal through the funnel, closes it — the amount is linked to the source.
  5. The service aggregates expenses via ad account APIs.
  6. ROI = (revenue — expenses) / expenses for each campaign.

Tools Comparison

Platform Strength Weakness
Roistat Multi‑channel attribution, call tracking, Bitrix24 integration (3x faster integration than Calltouch) Monthly cost
Calltouch Best call tracking on the market End‑to‑end analytics weaker than Roistat
CoMagic (UIS) Integration of calls + chat + analytics Outdated interface
Bitrix24 CRM Analytics Free, inside CRM Doesn’t calculate ad spend, no call tracking

Where Exactly Is the Hole in Your Funnel?

Typical Bitrix store funnel:

Stage What We Look At Where the Problem Usually Is
Catalog → Product page CTR by product Poor photos, no price in listing
Product page → Cart Add‑to‑cart rate No ‘Buy’ button on the first screen
Cart → Checkout Checkout initiation Unexpected shipping cost
Checkout → Order Completion rate Mandatory registration, sale.order.ajax failure

The checkout drop‑off is the most expensive. The user already wanted to buy, already added to cart, and then sale.order.ajax throws a 500 error due to an unconfigured delivery handler. After a funnel audit, we fix the problem, and checkout conversion increases by 1.5–2 times within a month.

Cohort Analysis and LTV Insights

We group by month of first purchase, look at retention after 30, 60, 90 days. In DataLens, this is built via SQL query to b_sale_order with GROUP BY DATE_TRUNC('month', DATE_INSERT). The main insight: which channel attracts high‑LTV customers. Context may give cheap first orders but zero repeat rate. SEO traffic converts worse but comes back. Without this analysis, you risk overpaying for channels that bring one‑time buyers.

What’s Included in Our Analytics Setup Service

  • Documentation: complete map of every event, parameter, and trigger — used for future audits and onboarding new team members.
  • Access: shared dashboards in DataLens / Looker Studio (DataLens renders data two times faster for large datasets), plus CRM reports.
  • Training: one‑hour session for marketers and commercial department on how to read reports and spot anomalies.
  • Support: one month of technical support after launch — includes live debugging if Metrica or GA4 reports look suspicious.
Task Duration Deliverable
Yandex.Metrica + eCommerce (with correct dataLayer) 3–5 days Event map + live counter
GA4 + Enhanced E‑commerce 3–5 days Validated data stream
End‑to‑end analytics (Roistat/Calltouch + CRM) 2–4 weeks Full attribution setup
Dashboards in DataLens / Looker Studio 1–2 weeks Custom KPIs per channel
Comprehensive system 4–8 weeks All of the above + audit report

How to Start: Audit and Setup

Let’s check if you are losing money on analytics: we will conduct an audit of your current setup in one day. Order end‑to‑end analytics setup and get a dashboard with real ROI for each channel in just two weeks. Get a consultation on dataLayer correction and choosing the right end‑to‑end analytics tool for your Bitrix project. Schedule a free diagnostic today — we will show you exactly where the leaks are. Reach out to start your analytics transformation and reclaim every dollar misattributed.