1С-Битрикс *

Типовая задача на российском рынке: есть публичный сайт (лендинг, маркетплейс, каталог), на нём формы — заявка, регистрация, заявка партнёра. Эти лиды должны попадать в 1С Битрикс, где с ними работает отдел продаж.

Подход "в лоб" выглядит так: в обработчике формы сделать await fetch('https://bitrix.../crm.lead.add', ...) и вернуть пользователю ответ после того, как Битрикс подтвердил создание лида.

Это плохо работает. Битрикс REST API нестабилен по latency — 200 мс в норме, 8 секунд при нагрузке на стороне CRM. Пользователь сайта в это время смотрит на крутилку. Если Битрикс упал или таймаутит — сайт отдаёт ошибку, хотя пользователь форму заполнил корректно.

В этой статье — паттерн, который я использовал на маркетплейсе недвижимости на Next.js 16 + PostgreSQL 16 + 1С Битрикс. Без Redis, без BullMQ, без отдельного воркера. Просто Next.js API route + after() + минимальный HTTP-клиент с retry и таймаутом.

Цифры проекта для контекста: 25 объектов недвижимости в каталоге (отдельная сущность ready_homes оставлена за скобками статьи), 57 API-роутов, PostgreSQL 16.13 на VPS, деплой через systemd + nginx, интеграция с Битрикс — исключительно outbound (сайт → CRM).

Заходят как-то в бар Битрикс24 и Диадок — и быстро выясняется, что работать вместе им пока сложно. Битрикс24 отвечает за сделки и коммуникации, Диадок — за документы и статусы. А бизнесу нужна единая цепочка: документ появился в Диадоке — менеджер сразу видит его в CRM без переключений и ручных сверок.

Мы реализовали такую интеграцию с нуля. Настроили автоматическую передачу документов из Диадока в Битрикс24. Документы создают лиды, а статусы, файлы и история изменений отображаются в CRM.

Привет, Хабр! Расскажу, как мы спасли крупный новостной сайт ugra-news.ru от постоянных падений — без покупки нового железа и переписывания с нуля. Только точечные оптимизации, знание архитектуры Битрикс и немного детективной работы. Приступим.

Часто слышу в IT:

PHP устарел

Bitrix - монолит из 2000-х

На Bitrix невозможно писать нормальную архитектуру

С Bitrix24 работаю больше шести лет и за это время поработал над проектами: от простых внедрений до CRM с серьёзной нагрузкой и десятками интеграций. Каждый раз убеждался в том, что архитектуру делает не платформа, а разработчик.

За пару лет я сделал с десяток приложений для Маркетплейса Битрикс24 — коннекторы мессенджеров, роботы, iframe-панели. На PHP, TypeScript и Python. Каждый раз одно и то же: документация разбросана, примеры устарели, а реальные подводные камни вылезают только в продакшене.

Эта статья — сборник всего, что я хотел бы знать перед тем, как начать: формат токенов при установке, мультитенантность, обновление OAuth, петля сообщений в коннекторах и ещё десяток граблей с кодом и решениями.

В условиях экономической турбулентности управление личными финансами превращается из хобби в задачу по выживанию. Когда инфляция съедает накопления, а горизонт планирования сузился до месяца, красивые круговые диаграммы с итогами года больше не работают. Чтобы выбраться из долгов или хотя бы не свалиться в кассовый разрыв, нужен жесткий, тотальный контроль над каждым рублем, долларом или крипто-центом.

Мы разобрали 6 популярных PFM-инструментов (Personal Finance Management), чтобы посмотреть, как именно — на уровне архитектуры и UX — они заставляют пользователя «резать косты» и брать бюджет под контроль.

Привет, Хабр!

В Битрикс24 есть два инструмента автоматизации, которые как будто делают одно и то же. Роботы — настраиваются в CRM на стадиях воронки, срабатывают при переходе сделки между этапами. Бизнес-процессы — настраиваются в визуальном дизайнере, поддерживают ветвления, циклы, переменные и многоэтапные согласования.

Ответ на то, что использовать — очевиден не всегда, потому что возможности частично пересекаются: и робот может отправить письмо, и бизнес-процесс тоже. Но граница между ними большущая.

Разберём, чем роботы и бизнес-процессы отличаются по механике, и на конкретных сценариях покажем, где какой инструмент уместен.

TL;DR

Мигрировал продакшн базу с Supabase на VPS PostgreSQL прямо на работающем проекте — без остановки, без потери данных. Заодно перенёс авторизацию через strangler-подход и убрал Supabase из SSR read-path. Расскажу три инженерных решения с кодом.

Продолжаем серию статей о нашем функциональном и удобном корпоративном портале.

Открытость — часть культуры Sminex. Своё мнение принято высказывать, устаревшие бизнес-процессы — совершенствовать и менять. Любой сотрудник может предложить идею, изменить устаревшие и неэффективные правила и технологии. И не только предложить, но и заработать, если идея соответствует определённым критериям и выгодна компании. Это отличная мотивация для команды. Для реализации на практике работает корпоративный сервис «Идеи». Раньше технической базы для него не было. Всё сводилось к отдельному почтовому ящику и группе сотрудников, координировавших процесс. Единого подхода к подаче идей тоже не было: предложения поступали в свободной форме, не всегда содержали нужную информацию и часто повторялись.

Привет! Миша Васильев на связи, разработчик в команде AI Битрикс24. 

Недавно я написал статью про MCP — протокол для стандартизации работы LLM с внешними инструментами. Там мы разобрали, как это всё устроено, какие возможности даёт и почему это круто.

Но за год активной работы с MCP мы наступили на все возможные грабли. Некоторые из них очевидны только постфактум. Другие не описаны ни в какой документации. Третьи — следствие того, что MCP развивается настолько быстро, что устоявшихся практик ещё толком не существует.

В этой статье я собрал семь основных проблем, с которыми мы столкнулись при разработке MCP-серверов, и объясню, как их избежать (или хотя бы постараться это сделать).

Еще пару лет назад веб жил в простой и понятной модели: есть сайты, есть поисковые роботы, есть пользователи. Роботы приходят, сканируют страницы, кладут их в индекс — дальше начинается привычная борьба за позиции в выдаче. Эта логика десятилетиями определяла, как мы строим сайты, настраиваем SEO и пишем robots.txt.

С появлением LLM-агентов эта модель начала трещать по швам.

В коробочной версии Bitrix24 функция «Авторизоваться под пользователем» является штатной и удобной для администрирования.
Однако в корпоративной среде с требованиями ИБ и compliance она порождает интересную инженерную задачу: где проходит граница прикладной безопасности?

Разбираем архитектуру impersonation, ограничения триггеров БД и попытку реализовать компенсирующие меры на прикладном уровне.

Когда производитель с дилерской сетью из 85+ партнёров решает стандартизировать их сайты — первый инстинкт понятен: сделать JSON-фид с основного домена, настроить синхронизацию, и пусть у всех будет одинаковый актуальный каталог.

Проблема в том, что «одинаковый» и «хорошо индексируемый» — противоречащие друг другу требования, если реализовано наивно. Яндекс видит 85 сайтов с идентичным контентом и поступает предсказуемо.

Под катом — как мы решали эту задачу для крупнейшего производителя сельхозтехники в России (150+ моделей комбайнов и тракторов, 50 000 SKU запчастей): архитектура Lock/Edit на уровне инфоблоков Битрикс, Manticore Search для артикулов со спецсимволами, OpenAI Batch API для обогащения каталога и Python-автоматизация развёртывания 85 поддоменов.

Работая над корпоративным порталом большого предприятия, рано или поздно оказываешься лицом к лицу с типовыми проблемами работы с таблицами: данных много, требования к интерактивности и настройкам — ещё больше, а бизнес не хочет ждать «когда всё подгрузится». Мы вырастили свой универсальный компонент для работы с гридами — и теперь можем честно поделиться: как минимизировать боли, не разрабатывать раз за разом один и тот же функционал в разных сервисах и сделать жизнь разработчика проще.

Наша команда специализируется на развитии корп. портала Группы НЛМК на платформе Битрикс, и еще нескольких корпоративных сайтов.

Значимая часть портала — это широкий набор сервисов для решения задач бизнеса. Например, регистрация и обработка заявок на перевод документов, работа с приёмом делегаций, волонтёрской активностью, проведение оценки рабочих, работа с пользователями (поздравления, благодарности, знаки отличия сотрудников) и многое другое. Несмотря на всё разнообразие сервисов, для их разработки зачастую используются одни и те же функциональные блоки — универсальные "кирпичики" для решения типовых задач.

В предыдущей статье я рассказывал про опыт работы с бизнес процессами 1С-Битрикс. Сейчас хотелось бы затронуть другую, не менее востребованную задачу — задачу по удобному и структурированному выводу данных.

Про эталонный справочник, JWT-авторизацию, требования КИИ и почему 1С-Битрикс вместо Laravel

В 2022 году мы получили задачу: автоматизировать заказы запчастей для 40+ дилеров. Вызов был не в объёме данных (50,000 SKU), а в разнородности систем дилеров и требованиях безопасности КИИ.

Через 18 месяцев 65% заказов пошли через портал без участия операторов. REST API интегрирован с 28 дилерами (70% сети). Время оформления заказа сократилось с 45 минут до 7.

Под катом — архитектурные решения, почему эталонный справочник важнее REST API, и как обойти ограничения КИИ.

Привет, Хабр! (И тебе, 1С-ник, который привык к «желтой» программке, и тебе, веб-разработчик, который до сих пор думает, что 1С - это только про накладные и бухгалтеров.)

В прошлой серии мы выяснили, что «1С:Предприятие.Элемент» - это не та «желтая программа», к которой привыкли бухгалтеры, а вполне себе модный cloud-native зверь с IDE в браузере. Но слова - это дешево. Разработчику нужно видеть код, архитектуру и понимать, как это соотносится с тем, что он уже знает (будь то 1C, Python или JavaScript).

Сегодня мы лезем под капот. Мы разберем синтаксис, систему типов, декларативный UI и узнаем, как 1С реализовала ORM, который (спойлер) удобнее многого, что вы знали, но не без своих 1С-овских замашек.

Поехали.

Claude AI + Python + pandas = экономия 85% времени. Полный разбор архитектуры, кода и подводных камней.

Делюсь опытом разработки проекта, где потребовалось совместить Laravel и «Битрикс Управление Сайтом» в одной системе: подробно описал путь от настройки окружения и выбора инструментов до внедрения CI/CD и решения возникавших проблем.

При работе с Bitrix24 понадобилось сохранить адрес из Google Maps в стандартное поле Address у лида. Не просто строку, а полноценный адрес: с координатами, разбивкой на части и корректной работой всей CRM-логики.

REST API рассматривался первым, но быстро стало ясно, что в этом сценарии неудобен. Нужно было переносить адрес между сущностями Bitrix24, сохраняя связи с модулем location. REST такого контроля не даёт.

При этом в Bitrix24 уже есть стандартное поле address, связанное с Google Maps и модулем location. Оно умеет хранить координаты и структуру адреса, но в документации нет описания, как правильно заполнять его через код.

В статье разберу практический кейс: как сохранить адрес из Google Geocode во внутренние сущности Bitrix24 без REST API и без пользовательского интерфейса.

Геополитические и экономические сдвиги последних лет привели к фундаментальной перестройке агропромышленного комплекса (АПК) на пространстве Содружества Независимых Государств (СНГ). Традиционная архитектура рынка, базировавшаяся на доминировании западных технологических гигантов (John Deere, CNH Industrial, AGCO, Claas), претерпела необратимые изменения, особенно на территории Российской Федерации и Беларуси. Этот процесс, часто характеризуемый как «поворот на Восток», повлек за собой не только замещение выбывающего парка техники машинами китайского производства, но и создал вакуум в цифровой инфраструктуре отрасли.

Западные производители поставляли на рынок СНГ не просто «железо», а интегрированные экосистемы: телематические системы, облачные платформы управления флотом и, что критически важно для дилеров, интерактивные электронные каталоги запчастей (EPC — Electronic Parts Catalogs) с глубокой детализацией и связью с ERP-системами. Китайские бренды (Zoomlion, Lovol, YTO, SANY), стремительно заполняющие освободившиеся ниши, пока находятся на этапе формирования аналогичных цифровых сервисов. Этот разрыв между привычными стандартами обслуживания, заданными западными вендорами, и текущими возможностями азиатских поставщиков формирует колоссальный спрос на услуги специализированной веб-интеграции.

Анализ показывает, что рынок веб-интеграции для АПК перестает быть нишевым сегментом создания корпоративных сайтов-визиток и трансформируется в рынок сложных B2B-решений. Ключевыми драйверами здесь выступают необходимость унификации разнородных данных от новых поставщиков, потребность крупных агрохолдингов Казахстана и текстильных кластеров Узбекистана в прозрачности закупок, а также жесткие требования российского законодательства и санкционные ограничения, вынуждающие локализовывать программное обеспечение.