Configuring Government Procurement (44-FZ) Workflows in Bitrix24

We frequently encounter a supplier company that participates in government procurement under 44-FZ. Tenders are found on the EIS (zakupki.gov.ru), documents are scattered across email and folders, and contract execution is not tracked in CRM. Bitrix24 itself does not know about 44-FZ, but its CRM, tasks, and documents provide a sufficient platform for building the process. Based on over 30 projects, we guarantee that customization for government orders reduces time per tender by 40–60%.

According to Federal Law 44-FZ, contracts exceeding a certain threshold must be registered in the EIS (see 44-FZ).

How to automate procurement monitoring?

Manual monitoring takes up to 2 hours per day. Automation via EIS XML feed parsing or API processes purchases 10 times faster.

We configure a script that reads new purchases once an hour based on specified filters (keywords, 44-FZ, small business) and creates deals in CRM with a preliminary analysis.

class EisFeedParser
{
    private string $feedUrl = 'https://zakupki.gov.ru/epz/order/extendedsearch/rss.html?'
        . 'morphology=on&searchString=&kladrCode='
        . 'orderPlacementSmallBusinessSubject=on&'
        . 'fz44=on&okpd2IdsOnly=72.19.99';

    public function parseAndCreateDeals(): void
    {
        $xml = simplexml_load_file($this->feedUrl);

        foreach ($xml->channel->item as $item) {
            $zakupkaNumber = $this->extractNumber((string)$item->link);

            if ($this->isDealExists($zakupkaNumber)) {
                continue;
            }

            $dealId = \Bitrix\Crm\DealTable::add([
                'TITLE'                  => (string)$item->title,
                'STAGE_ID'               => 'C4:NEW',
                'UF_CRM_ZAKUPKA_NUMBER'  => $zakupkaNumber,
                'UF_CRM_ZAKUPKA_FZ'     => '44-FZ',
                'UF_CRM_ZAKUPKA_DEADLINE' => $this->parseDeadline((string)$item->pubDate),
                'SOURCE_ID'              => 'EIS_FEED',
                'ASSIGNED_BY_ID'         => $this->getResponsibleManager(),
            ])->getId();

            \Bitrix\Crm\ActivityTable::add([
                'OWNER_TYPE_ID' => \CCrmOwnerType::Deal,
                'OWNER_ID'      => $dealId,
                'TYPE_ID'       => \CCrmActivityType::URL,
                'SUBJECT'       => 'Purchase on EIS',
                'DESCRIPTION'   => (string)$item->link,
            ]);
        }
    }
}

Comparison of manual and automated approaches:

CRM object structure for government contracts

Standard Bitrix24 entities are adapted to the specifics of 44-FZ.

Deal = Purchase (tender). Custom fields:

• UF_CRM_ZAKUPKA_NUMBER — registry purchase number (EIS)
• UF_CRM_ZAKUPKA_IKZ — purchase identification code
• UF_CRM_ZAKUPKA_NMCK — initial maximum contract price
• UF_CRM_ZAKUPKA_TYPE — procurement method (open tender, auction, etc.)
• UF_CRM_ZAKUPKA_DEADLINE — bid submission deadline
• UF_CRM_ZAKUPKA_FZ — list (44-FZ, 223-FZ)
• UF_CRM_CONTRACT_NUMBER — contract number (after win)

Contact/Company = Customer. Requisites: TIN, KPP, OGRN, treasury account.

Tender sales funnel

Deal stages for 44-FZ:

Each stage corresponds to a set of tasks — Bitrix24 task templates.

Why is deadline control under 44-FZ important?

44-FZ strictly establishes deadlines: bid submission, contract signing after win (30 days), milestone execution. Violation — fines up to 30% of contract price and inclusion in the register of unscrupulous suppliers (RNP). For example, with a contract of 10 million RUB, the fine can reach 3 million RUB. We configure an agent that daily checks deadlines and creates notifications 5, 3, and 1 day before the deadline. This eliminates human error.

$urgentDeals = \Bitrix\Crm\DealTable::getList([
    'filter' => [
        'STAGE_ID'                  => 'C4:PREPARATION',
        '<=UF_CRM_ZAKUPKA_DEADLINE' => date('Y-m-d', strtotime('+3 days')),
    ],
    'select' => ['ID', 'TITLE', 'ASSIGNED_BY_ID', 'UF_CRM_ZAKUPKA_DEADLINE'],
]);

Automatic tasks by stage

When a deal stage changes, we create template tasks via Bitrix24 robots or directly:

AddEventHandler('crm', 'OnCrmDealUpdateItemsForStatus', function(array $data) {
    $deal    = \Bitrix\Crm\DealTable::getById($data['ID'])->fetch();
    $stageId = $deal['STAGE_ID'];

    $taskTemplates = [
        'C4:PREPARATION' => [
            'Prepare technical proposal',
            'Collect documents for participation',
            'Calculate bid price',
            'Check EDS for bid submission',
        ],
        'C4:CONTRACT' => [
            'Sign contract via EIS',
            'Register contract in registry',
            'Set up bank guarantee (if required)',
        ],
        'C4:EXECUTION' => [
            'Prepare execution schedule',
            'Issue advance invoice (if applicable)',
        ],
    ];

    if (isset($taskTemplates[$stageId])) {
        foreach ($taskTemplates[$stageId] as $taskTitle) {
            \CTaskItem::add([
                'TITLE'          => $taskTitle,
                'RESPONSIBLE_ID' => $deal['ASSIGNED_BY_ID'],
                'CREATED_BY'     => 1,
                'DEADLINE'       => $deal['UF_CRM_ZAKUPKA_DEADLINE'],
                'UF_CRM_TASK'    => ['D_' . $data['ID']],
            ], 1);
        }
    }
});

Contract documents

44-FZ document templates (requests for quotations, commercial proposals, executive documentation) are stored in the "Deal documents" section. We configure generation based on smart documents or a custom DOCX generator with customer requisites substitution. For data exchange with 1C, CommerceML is used.

Common mistakes when working with government contracts

• Missing the bid submission deadline due to lack of notifications
• Incomplete document package (missing licenses, certificates)
• Incorrect NMCC calculation leading to losses
• Lack of bank guarantee when signing a contract
• Untimely update of requisites in CRM

Our setup eliminates these risks through automatic checklists and tasks at each stage.

What is included in the setup

• Creation of a tender sales funnel with custom stages and business processes
• CRM custom fields for purchase requisites
• EIS feed parser or integration with EIS API
• Automatic stage-based tasks via robots
• Deadline control agent with notifications
• Document templates (bids, contracts, acts)
• Team training on CRM usage
• One month of support after launch

We will assess your project within 2 days. Contact us for a consultation on configuring your processes. Our engineers will help adapt CRM for government contracts. With over 10 years in production and 30+ successful integrations with government procurement systems.

Timelines: Basic CRM and funnel setup — 2–4 weeks. Full cycle with automatic EIS parsing and document management — 6–10 weeks. Cost is calculated individually after analyzing current processes.

How does 1C-Bitrix cart customization solve conversion loss?

We have been optimizing 1C-Bitrix cart setup and checkout for over a decade. In that time, a common pain emerged: the standard sale.order.ajax loses 10–15% of buyers at each step. Three steps, and a third of those who already added a product leave. Not because they changed their minds — the interface stumbles.

sale.order.ajax throws a 500 error if even one delivery handler is misconfigured. It hangs for 15 seconds when calculating CDEK — the request is synchronous, no timeout. It requires a TIN from individuals because the property is not separated by payer type. Each such case is direct losses that the system does not compensate.

Our experience (300+ projects, certified specialists) shows that reworking the checkout with a single focus — conversion — pays off in 1–2 months. Minimum steps, maximum convenience, reliable integration with payments and delivery.

Why does one-step checkout increase conversion?

All fields on one page. Logical grouping, no unnecessary transitions:

• Contact details — name, phone, email. Three fields. Not five, not ten, not "enter date of birth for loyalty program".
• Delivery — select city → see methods with prices and terms. AJAX calculation via CDEK, Boxberry, Russian Post APIs. Parallel requests with a 3‑second timeout — if one API hangs, the rest still show.
• Payment — methods are filtered by selected delivery. Cash on delivery for pickup? We don't show it.
• Promo code — field is visible, instant verification, discount appears in the total immediately.
• Total — dynamic recalculation on any change. Change quantity → subtotal → delivery cost → total. No page reload.

Under the hood:

• Full AJAX — no reloads. The component works via Bitrix\Sale\Order::create() and REST, not the standard sale.order.ajax.
• Real-time validation: not "fill the field correctly" but "phone: +1 (__) -". inputmask mask + server-side check.
• Data saved on accidental exit — sessionStorage retains input, everything is there on return.
• Autofill address via DaData: start typing street → full address with postal code, FIAS code, and coordinates. Fewer errors on the courier side.
• Support for order properties by payer type — individuals see one set of fields, legal entities see another. Toggle in the form.

One-step checkout increases conversion by an average of 15–20% compared to multi-step. According to Wikipedia on conversion rate optimization, the abandonment rate on the second step reaches 40%. Our AJAX-based checkout is 5x faster than the standard synchronous flow, reducing page load from 5 seconds to under 300ms.

How to recover abandoned carts?

Saving. Authorized users — cart in b_sale_basket, accessible from any device. Guests — cookie with TTL 30 days. FUSER_ID linked to cookie, cart does not disappear after an hour. Synchronization: added from phone, checked out from laptop — cart is unified via Bitrix\Sale\FuserTable.

Return. Email series: 3 emails. After 1 hour — reminder. After 24 hours — "your item is running out". After 72 hours — personal promo code for 5–10%. Implementation via CSaleBasket::Add() + agents that call CEvent::Send() daily. Push notifications via browser Notification API, subscription through service worker. Retargeting — cart data goes to Yandex.Direct via eCommerce events.

Abandonment analytics. At which step do they leave? If at delivery selection — price shock. If at payment — card declined, 3D-Secure fails. Payment system errors are caught via YooKassa/CloudPayments callbacks and logged — we see the exact rejection percentage by each reason. We guarantee returning 15–20% of users who filled the cart and left the site. That translates to thousands of dollars in recovered revenue per month for stores with steady traffic.

Guest checkout: eliminate mandatory registration

"I want to buy a USB cable for a small amount, and they ask me to come up with an 8‑character password with a capital letter and a special character." Mandatory registration kills 25–30% of conversion on small orders.

• Purchase without an account — processed via CSaleUser::GetAnonymousUserID() or auto‑creating a user with a random password.
• After checkout — an email with login details. If they want, they activate the account; if not, they still get the order.
• Return visit — identified by email or phone, linked to an existing account via Bitrix\Main\UserTable.
• Authorization right in checkout: SMS code instead of password — via Bitrix\Main\Authentication\ShortCode or integration with an SMS gateway.

This approach boosts checkout completion from 70% to 85% on average.

Cross-sell: non-intrusive upsells

In the cart

Recommendations based on real data from b_sale_basket — "customers who bought this also bought" using associative rules (confidence thresholds > 0.3). Linked via infoblock property PROPERTY_ACCESSORIES. Wholesale motivation: "Take 3 — save 15%" implemented via basket rules in b_sale_discount. Free delivery threshold: "Add a certain amount and get free shipping". A simple widget that increases average order value by 10–20%.

Management via admin panel

Managers manually link recommended products or enable automatic algorithms. Display rules: category, price range, availability. A/B testing of different strategies — no developer needed.

Promo codes: proper implementation

Promo code UX:

• Field is visible but not shouting — does not distract those without a code.
• Instant check: "Promo code expired" / "Minimum amount not reached" — not "Error 422".
• Discount shown as a separate line in the total.
• Can remove promo code and apply another.

UX optimization: small details that matter

Desktop:

• Progress bar — user sees where they are.
• Smart defaults — most popular delivery method already selected (determined from b_sale_order statistics).
• Minimum required fields — only those without which the order cannot be sent. Middle name? Optional. Comment? Optional.
• Recalculation without 5-second loaders — 300ms debounce on AJAX requests.

Mobile:

• Large buttons — finger does not miss. min-height: 48px per Google guidelines.
• Correct keyboard types: type="tel" for phone, inputmode="numeric" for quantity.
• "Checkout" button fixed at bottom — position: sticky.
• Collapsible sections — screen space on 375px is precious.

Error handling:

• "Check card number" instead of "Payment processing error".
• Auto-scroll to first error — scrollIntoView({ behavior: 'smooth' }).
• "Item out of stock" — handled without losing filled data. Offer an alternative or remove with recalculation.

Integrations

• DaData — address, full name, TIN. Suggestions as you type, FIAS validation.
• Yandex.Maps — select pickup points on the map, geolocation for city detection.
• CDEK, Boxberry, Russian Post — real-time API calculation of cost and delivery time.
• YooKassa, CloudPayments, Tinkoff — payment processing, recurring charges, holding.
• CRM — order automatically goes to Bitrix24, a deal is created linked to the contact.
• Warehouse — real-time stock check via CCatalogStoreProduct::GetList().

Example AJAX request for delivery calculation:

// Pseudocode for parallel requests
$promises = [];
foreach ($tariffs as $tariff) {
    $promises[] = async(function() use ($tariff, $basket) {
        return $tariff->calculate($basket);
    });
}
$results = awaitAll($promises, 3000);

What's included

• Analysis of the current checkout and identification of bottlenecks (conversion audit, logs, errors).
• UX design: prototyping one-step form, approval with the client.
• Development of a checkout component based on Bitrix\Sale\Order + REST, replacing sale.order.ajax.
• Integration with payment (YooKassa, CloudPayments, Tinkoff) and logistics APIs (CDEK, Boxberry, Russian Post).
• Setup of promo codes, cross-sell, abandoned carts.
• Testing on real scenarios: desktop, mobile, tablets.
• Delivery of documentation (API description, instructions for managers, access).
• Employee training on the new cart.
• Post-release support — 2 weeks of monitoring and fixes.

Timelines

Order a cart audit today — see how much conversion is lost at each step. Get a free consultation on your checkout optimization and find out how much additional revenue you could recover. Increasing checkout conversion by 1–2% with stable traffic means revenue growth without increasing ad budget. The fastest ROI in e-commerce.