Налаштування роботи з держзамовленнями (44-ФЗ) через Бітрікс24

Налаштування роботи з держзамовленнями (44-ФЗ) через Бітрікс24

Ми часто зустрічаємо компанію-постачальника, яка бере участь у державних закупівлях за 44-ФЗ. Тендери знаходять на ЄІС (zakupki.gov.ru), документи зберігаються розсипом у пошті та папках, а виконання контракту ніяк не відстежується в CRM. Бітрікс24 сам по собі не знає про 44-ФЗ, але його CRM, завдання та документи — достатня платформа для вибудовування процесу. На основі більш ніж 30 реалізованих проектів ми гарантуємо, що кастомізація під держзамовлення скорочує час на кожен тендер на 40–60%.

Згідно з 44-ФЗ, контракти на суму понад 100 000 ₽ повинні бути зареєстровані в ЄІС (див. 44-ФЗ).

Як автоматизувати моніторинг закупівель?

Ручний моніторинг забирає до 2 годин на день. Автоматизація через парсинг XML-фідів ЄІС або API обробляє закупівлі в 10 разів швидше. Економія на зарплаті менеджера може сягати 300 000 ₽ на рік.

Ми налаштовуємо скрипт, який раз на годину зчитує нові закупівлі за заданими фільтрами (ключові слова, 44-ФЗ, малий бізнес) і створює угоди в CRM з первинним аналізом.

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-ФЗ',
                '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'       => 'Закупка на ЄІС',
                'DESCRIPTION'   => (string)$item->link,
            ]);
        }
    }
}

Порівняння ручного та автоматичного підходу:

Структура об'єктів CRM для держзамовлень

Стандартні сутності Бітрікс24 адаптуємо під специфіку 44-ФЗ.

Угода = Закупівля (тендер). Користувацькі поля:

• UF_CRM_ZAKUPKA_NUMBER — реєстровий номер закупівлі (ЄІС)
• UF_CRM_ZAKUPKA_IKZ — ідентифікаційний код закупівлі
• UF_CRM_ZAKUPKA_NMCK — початкова максимальна ціна контракту
• UF_CRM_ZAKUPKA_TYPE — спосіб визначення постачальника (відкритий конкурс, аукціон тощо)
• UF_CRM_ZAKUPKA_DEADLINE — дата закінчення прийому заявок
• UF_CRM_ZAKUPKA_FZ — список (44-ФЗ, 223-ФЗ)
• UF_CRM_CONTRACT_NUMBER — номер контракту (після перемоги)

Контакт/Компанія = Замовник. Реквізити: ІНН, КПП, ОГРН, особовий рахунок у казначействі.

Воронка тендерних продажів

Стадії угоди для 44-ФЗ:

Кожній стадії відповідає набір завдань — шаблони завдань Бітрікс24.

Чому важливий контроль термінів за 44-ФЗ?

44-ФЗ жорстко встановлює строки: подачі заявки, підписання контракту після перемоги (30 днів), виконання етапів. Порушення — штрафи до 30% від ціни контракту та включення до реєстру недобросовісних постачальників (РНП). Наприклад, при контракті на 10 млн ₽ штраф може становити до 3 млн ₽. Ми налаштовуємо агента, який щодня перевіряє дедлайни та створює сповіщення за 5, 3 та 1 день до настання. Це виключає людський фактор.

$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'],
]);

Автоматичні завдання за стадіями

При зміні стадії угоди створюємо шаблонні завдання через роботів Бітрікс24 або напряму:

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

    $taskTemplates = [
        'C4:PREPARATION' => [
            'Підготувати технічну пропозицію',
            'Зібрати пакет документів для участі',
            'Розрахувати ціну пропозиції',
            'Перевірити ЕЦП для подачі заявки',
        ],
        'C4:CONTRACT' => [
            'Підписати контракт через ЄІС',
            'Зареєструвати контракт у реєстрі',
            'Налаштувати банківську гарантію (якщо потрібно)',
        ],
        'C4:EXECUTION' => [
            'Підготувати план-графік виконання',
            'Виставити рахунок на аванс (якщо передбачено)',
        ],
    ];

    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);
        }
    }
});

Документи за контрактом

Шаблони документів 44-ФЗ (котирувальні заявки, комерційні пропозиції, виконавча документація) зберігаються в розділі «Документи угоди». Ми налаштовуємо генерацію на основі смарт-документів або кастомного DOCX-генератора з підстановкою реквізитів замовника. Для обміну даними з 1С використовується CommerceML.

Типові помилки при роботі з держзамовленнями

• Пропуск строку подачі заявки через відсутність сповіщень
• Неповний пакет документів (відсутність ліцензій, сертифікатів)
• Неправильний розрахунок НМЦК, що призводить до збитків
• Відсутність банківської гарантії при підписанні контракту
• Несвоєчасне оновлення реквізитів у CRM

Наше налаштування виключає ці ризики завдяки автоматичним чек-листам та завданням на кожному етапі.

Що входить у налаштування

• Створення воронки тендерних продажів з кастомними стадіями та бізнес-процесами
• Користувацькі поля CRM для реквізитів закупівлі
• Парсер фідів ЄІС або інтеграція з API ЄІС
• Автоматичні завдання за стадіями через роботів
• Агент контролю дедлайнів зі сповіщеннями
• Шаблони документів (заявки, контракти, акти)
• Навчання команди роботі з CRM
• Підтримка протягом місяця після запуску

Оцінимо ваш проект за 2 дні — зв'яжіться з нами для консультації. Отримайте консультацію з налаштування під ваші процеси. Наші інженери допоможуть адаптувати CRM для держзамовлень. Ми — сертифіковані спеціалісти з Бітрікс24, більше 5 років на ринку, реалізували більше 30 інтеграцій з держзакупівлями.

Терміни: базове налаштування CRM та воронки — 2–4 тижні. Повний цикл з автоматичним парсингом ЄІС та документообігом — 6–10 тижнів. Вартість розраховується індивідуально після аналізу поточних процесів.

Як налаштування кошика 1С-Бітрікс вирішує проблему втрати конверсії

Ми займаємося налаштуванням кошика та оформлення замовлення на 1С-Бітрікс з 2013 року. За цей час зіткнулися з типовою проблемою: штатний sale.order.ajax втрачає на кожному кроці 10–15% покупців. Три кроки — і третина тих, хто вже додав товар, іде. Не тому що передумали — інтерфейс спотикається.

sale.order.ajax видає 500-ку, якщо не налаштований хоча б один обробник доставки. Зависає на 15 секунд при розрахунку НПП — запит синхронний, без таймауту. Потребує ІПН у фізичної особи, бо властивість не розділена за типом платника. Кожен такий кейс — прямі втрати, які система не компенсує.

Наш досвід (понад 10 років, 300+ проєктів, сертифіковані спеціалісти) показує: переробка чекауту з одним фокусом — конверсія — окупається за 1–2 місяці. Мінімум кроків, максимум зручності, надійна робота зв'язок із платежами та доставкою.

Чому однокроковий чекаут збільшує конверсію?

Всі поля на одній сторінці. Логічне групування, жодних зайвих переходів:

• Контактні дані — ім'я, телефон, email. Три поля. Не п'ять, не десять, не «вкажіть дату народження для програми лояльності».
• Доставка — вибрав місто → побачив способи з цінами та термінами. AJAX-розрахунок через API НПП, Boxberry, Укрпошти. Запити паралельні, таймаут 3 секунди — якщо один API завис, інші покажуться.
• Оплата — способи фільтруються за вибраною доставкою. Післяплата при самовивозі? Не показуємо.
• Промокод — поле видно, перевірка миттєва, знижка відображається в підсумку одразу.
• Підсумок — динамічний перерахунок за будь-якої зміни. Змінив кількість → сума → вартість доставки → підсумок. Без перезавантаження.

Під капотом:

• Повний AJAX — жодного перезавантаження. Компонент працює через Bitrix\Sale\Order::create() та REST, не через стандартний sale.order.ajax.
• Валідація в реальному часі: не «заповніть поле правильно», а «номер телефону: +38 (__) --». Маска inputmask + серверна перевірка.
• Збереження даних при випадковому відході — sessionStorage зберігає введене, при поверненні все на місці.
• Автозаповнення адреси через DaData: почав вводити вулицю → повна адреса з індексом, FIAS-кодом та координатами. Менше помилок з боку кур'єрської.
• Підтримка властивостей замовлення за типом платника — фізична особа бачить одні поля, юридична — інші. Перемикач у формі.

Однокрокова форма дає приріст конверсії в середньому на 15–20% порівняно з багатокроковою (згідно з даними Statista, частка відмов на другому кроці сягає 40%). Джерело: Statista, дослідження чекауту в e-commerce.

Як відновити покинуті кошики?

Збереження. Авторизовані — кошик у b_sale_basket, доступний з будь-якого пристрою. Гості — cookie з TTL 30 днів. FUSER_ID прив'язаний до cookie, кошик не пропаде через годину. Синхронізація: додав з телефону, оформив з ноутбука — кошик єдиний.

Повернення. Email-серія: 3 листи. Через 1 годину — нагадування. Через 24 години — «ваш товар закінчується». Через 72 години — персональний промокод на 5–10%. Реалізація через sale.basketcomponent + CEvent::Send() з відкладеною відправкою через агенти. Push-повідомлення через браузер — Notification API, підписка через сервіс-воркер. Ретаргетинг — дані про кошик йдуть у Google Ads через eCommerce-події.

Аналітика відмов. На якому кроці йдуть? Якщо на виборі доставки — ціна шокує. Якщо на оплаті — карта відхиляється, 3D-Secure не проходить. Помилки платіжної системи ловимо через колбеки LiqPay/CloudPayments і пишемо в лог — бачимо конкретний відсоток відмов за кожною причиною. Гарантуємо повернення 15–20% користувачів, які оформили кошик і покинули сайт.

Гостьове замовлення: убити обов'язкову реєстрацію

«Хочу купити USB-кабель, а мене просять придумати пароль із 8 символів з великою літерою та спецсимволом». Обов'язкова реєстрація вбиває 25–30% конверсії на дрібних замовленнях.

• Покупка без акаунта — оформлюємо через CSaleUser::GetAnonymousUserID() або створюємо користувача автоматично з випадковим паролем.
• Після оформлення — лист з даними для входу. Хоче — активує акаунт, не хоче — і так отримає замовлення.
• Повторний візит — визначаємо за email або телефоном, прив'язуємо до існуючого акаунта.
• Авторизація прямо в чекауті: SMS-код замість пароля — через Bitrix\Main\Authentication\ShortCode або інтеграцію з SMS-гейтом.

Крос-сел: допродажі, які не дратують

У кошику

Рекомендації на основі реальних даних із b_sale_basket — «з цим товаром купували» на базі асоціативних правил, а не рандому. Прив'язка через властивість інфоблоку PROPERTY_ACCESSORIES. Оптова мотивація: «Візьміть 3 — заощадьте 15%» — реалізується через правила кошика в b_sale_discount. Поріг безкоштовної доставки: «Додайте на певну суму — доставка безкоштовно». Простий віджет, але збільшує середній чек на 10–20%.

Управління через адмінку

Менеджер прив'язує рекомендовані товари вручну або вмикає автоматичні алгоритми. Правила відображення: категорія, діапазон цін, наявність. A/B-тестування різних стратегій — без розробника.

Промокоди: правильна реалізація

UX промокоду:

• Поле видно, але не кричить — не відволікає тих, у кого коду немає.
• Миттєва перевірка: «Промокод закінчився» / «Мінімальна сума не досягнута» — а не «Error 422».
• Знижка видна в підсумковому розрахунку окремим рядком.
• Можна прибрати промокод і застосувати інший.

UX-оптимізація: дрібниці, які вирішують

Десктоп:

• Прогрес-бар — користувач бачить, де він.
• Розумні дефолти — найпопулярніший спосіб доставки вже вибраний (визначаємо за статистикою b_sale_order).
• Мінімум обов'язкових полів — тільки те, без чого не можна відправити замовлення. По батькові? Необов'язково. Коментар? Необов'язково.
• Перерахунок без лоадерів на 5 секунд — debounce 300ms на AJAX-запитах.

Мобільні:

• Великі кнопки — палець не промахується. min-height: 48px за гайдами Google.
• Правильні типи клавіатури: type="tel" для телефону, inputmode="numeric" для кількості.
• Кнопка «Оформити» зафіксована внизу — position: sticky.
• Згорнуті секції — екранний простір на 375px дорогий.

Обробка помилок:

• «Перевірте номер картки» замість «Payment processing error».
• Автопрокрутка до першої помилки — scrollIntoView({ behavior: 'smooth' }).
• «Товар закінчився» — обробляємо без втрати заповнених даних. Пропонуємо аналог або прибираємо з перерахунком.

Інтеграції

• DaData — адреса, ПІБ, ІПН. Підказки під час введення, валідація ФІАС.
• Google Maps — вибір пунктів видачі на карті, геолокація для визначення міста.
• НПП, Boxberry, Укрпошта — API-розрахунок вартості та термінів у реальному часі.
• LiqPay, CloudPayments, ПриватБанк — прийом платежів, рекурентні списання, холдування.
• CRM — замовлення автоматично йде в Бітрікс24, створюється угода з прив'язкою до контакту.
• Склад — перевірка залишків через CCatalogStoreProduct::GetList() у реальному часі.

// Псевдокод для паралельних запитів
$promises = [];
foreach ($tariffs as $tariff) {
    $promises[] = async(function() use ($tariff, $basket) {
        return $tariff->calculate($basket);
    });
}
$results = awaitAll($promises, 3000);

Що входить у роботу

• Аналіз поточного чекауту та виявлення вузьких місць (аудит конверсії, логів, помилок).
• Проєктування UX: прототипування однокрокової форми, узгодження із замовником.
• Розробка компонента чекауту на основі Bitrix\Sale\Order + REST, з заміною sale.order.ajax.
• Інтеграція з платіжними (LiqPay, CloudPayments, ПриватБанк) та логістичними API (НПП, Boxberry, Укрпошта).
• Налаштування промокодів, крос-селу, покинутих кошиків.
• Тестування на реальних сценаріях: десктоп, мобільні, планшети.
• Передача документації (опис API, інструкції для менеджерів, доступи).
• Навчання співробітників роботі з новим кошиком.
• Пост-релізна підтримка — 2 тижні моніторингу та правок.

Строки

Зв'яжіться з нами для обговорення вашого проєкту та отримайте консультацію з конкретних завдань. Замовте аудит кошика вже сьогодні — побачите, скільки конверсії втрачається на кожному кроці. Збільшення конверсії чекауту на 1–2% при стабільному трафіку — це зростання виручки без зростання рекламного бюджету. Найшвидший ROI в e-commerce.