1С-Битрикс *

На стройке смета и реальные закупки живут в разных мирах. Смету один раз считают в Excel, согласовывают и кладут в папку. А дальше на объект месяцами идут счета: документ на почту, фото в мессенджер, таблица от поставщика. То, что газобетон подорожал на 12%, а арматуры купили на полторы тонны больше сметы, обычно выясняется при закрытии объекта, когда маржа уже ушла.

Недавно разбирали такую задачу для строительной компании, которая ведет объекты в Битрикс24.Заказчик сказал примерно так: “Нужно, чтобы счет пришел, система сама разобрала позиции, сопоставила их со сметой и до оплаты показала, где цена закупки выше сметной, где объем материала уже превышен, а где позиции в смете вообще нет.”.

Расскажу, как устроена такая система и где в ней на самом деле сложно

На хакатоне сделали такой проект: делаешь фото коллеги, система распознает его, добавляет в коллекцию и начисляет очки. 

Игра хорошо подходит для корпоративов в больших компаниях — например, у нас много отделов и подразделений, большая доля удалёнщиков. По этим причинам люди часто не очень хорошо знают друг друга в лицо.

Это неочевино, но многие люди каждый день пишут код на языке 1С, проводят документы, закрывают месяцы и знают наизусть, что такое «Данные были изменены или удалены другим пользователем (сеансом)!». Kubernetes для большинства из них — что-то далёкое и чужое, с английскими словами, YAML-файлами и непонятной философией. Вчера в одном чатике по K8s Дядя Женя набросил про Kubernetes на 1С. Вызов был принят. Итак, что будет, если взять Kubernetes и перенести его в мир 1С, вместе с его языком, документами, регистрами и бухгалтерией за стенкой?

Получился дистрибутив, который я назвал Assnetes (или 1Ж:Оркестратор 8). Манифесты и операторы в нём пишутся на языке 1С (кириллицей), командная строка разговаривает голосом главного бухгалтера Тамары Петровны, а пакетный менеджер закупает в кластер Бухгалтерию и Битрикс вместе с операторами, один из которых умеет масштабировать кластер серверов 1С по количеству сеансов. Под всем этим работает самый обычный Kubernetes, и по дороге выяснилось, где он готов притвориться бухгалтерией, а где сопротивляется насмерть (могу его понять).

Выгрузка сделок из Битрикс24 годами работает без проблем, а потом начинает тормозить и возвращать HTTP 429. Увеличение пауз между запросами не помогает, хотя остальные методы REST API продолжают отвечать как обычно. Разбираемся, как устроен лимит OPERATION_TIME_LIMIT, куда уходит серверное время и как ускорить выгрузку в сотни раз.

В любой компании старше пары лет знания размазаны по вики, папкам с регламентами, почтовым перепискам, 1С и Битрикс24. Новичок ищет нужный документ полчаса или идёт спрашивать коллегу, и коллега отвлекается.

Очевидный ответ — «давайте сделаем ChatGPT по нашим документам». Но почти всегда тут же звучит требование: данные не должны уходить в чужое облако. Значит, модель, поиск и хранилище должны жить на своём железе.

В статье описываю стек, который собирал на практике для таких задач: RAG поверх XWiki, файлов и почты, доступ к 1С и Битрикс24 через инструменты агента, локальная модель на vLLM. Без маркетинга: что из чего состоит, как связано и где ломается.

Мы продаём инженерные узлы для отопления и водоснабжения многоэтажек. Каждая сделка — расчёт под конкретный дом, коммерческое предложение, договор, закуп, сборка и отгрузки партиями по графику стройки. Ещё недавно эта цепочка жила в Битрикс24, отдельном калькуляторе, 1С и рабочих чатах.

Мы написали свою CRM. Раньше от заявки до подписанного договора проходило около двух месяцев, теперь — около месяца: сделки закрываются примерно вдвое быстрее. Сильнее всего сократился первый отрезок: раньше КП уходило заказчику через 3–4 дня после заявки, теперь — на следующий день. Ниже — где на самом деле терялось время, что мы для этого сделали и на какие грабли наступили.

У одного из сотрудников TRI было около шести Excel-таблиц. Он выгружал данные из 1С, переносил их в свои файлы и занимался тем, чем приходится заниматься после переноса данных: сводил, пересчитывал, проверял. Когда в компании решили выяснить, сколько времени на это уходит, продуктовый директор Магомед Ахматов предложил завести ещё одну таблицу. В ней предполагалось учитывать время, потраченное на предыдущие.

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

Хотел разобраться с одним, казалось бы, простым вопросом: за что мы заплатили подрядчику? Платёж был в 1С, заявка была в Bitrix24, а договор и акты приходилось искать среди вложений. С поиска этой связи начался финансовый сервис, а вокруг него постепенно появились ещё четыре продукта. Расскажу, как они складываются в ERP‑контур для стройки, что уже работает и где автоматизация пока может уверенно ошибиться.

Что происходит после того, как Битрикс24 отправляет исходящий вебхук? Разбираем POST-запрос, логирование, Flask, Django и базовую защиту endpoint.

За год сайты получили 149 заявок. В CRM не попала ни одна: письма уходили в личную почту двух сотрудников, а форма обратного звонка слала их разработчику шаблона. Пароль администратора при этом время от времени «менялся сам», и объяснение нашлось в папке /ftp.

Это восемь сайтов-каталогов корпоративного ИТ-оборудования на одной установке «1С-Битрикс». Я занимался их маркетингом, разбор занял около трёх недель и ушёл далеко от маркетинга. Ниже: что нашлось, как чинили, что сломали сами, и чек-лист, по которому то же можно найти у себя за вечер.

Пользователь ИИ-агента прикрепил к диалогу навык и написал рабочую заметку. Навык должен был добавить комментарий к отчету в корпоративной системе проектной организации. Но до отправки дело даже не дошло: модель не вызвала инструмент.

В описании инструмента было условие - применять его, когда пользователь явно просит добавить комментарий в систему. Человек уже выбрал нужный навык и начал писать заметку. Но для модели этого оказалось недостаточно.

Я занимаюсь разработкой ИскраБота - это российский ИИ-агент. Недавно создал один навык для корпоративной системы проектировщика, а в другой интеграции исправлял подключение к 1С через VPN. Расскажу о проблемах, с которыми столкнулся, но для начала - о том, что такое навык.

Сайт на 1С-Битрикс может месяцами работать вроде нормально, пока подключения к базе подбираются к 95%, диск незаметно заполняется логами, бэкап давно не запускался, а в логах копится одна и та же ошибка, на которую никто не смотрит.

Разбираем пять инфраструктурных причин, из-за которых Битрикс-проекты тормозят и падают: база данных, диск, PHP и веб-сервер, резервные копии, мониторинг. В каждом разделе есть простая проверка, которую можно провести у себя за 10 минут.

Большой каталог сам по себе еще не делает интеграцию сложной. В нашем проекте интеграции сайта с 1С сейчас 211 761 позиция номенклатуры. Передать такой объем можно, вопрос скорее в том, сколько ресурсов и времени на это потребуется. Проблемы начинаются позже: когда данные нужно не просто выгрузить, а отобрать, обработать, регулярно обновлять и доставить в другую систему.

Проект работает на связке 1С:Управление торговлей + интернет-магазин на Bitrix. Источником основных данных остается 1С: там находятся номенклатура, склады, цены и остатки, а сайт в основном работает как витрина. В обратную сторону с сайта в 1С приходят заказы.

Изначально для этой связки использовали типовой обмен. Но проект развивался: появились дополнительные отборы и обработка данных, разные сущности стали требовать разной скорости обновления. В какой-то момент часть данных начала приходить на сайт с задержкой.

Мы не стали переписывать интеграцию целиком. Архитектура менялась постепенно, по мере того как в production проявлялось очередное ограничение. Сначала оказалось, что тяжелая полная выгрузка конкурирует с оперативными изменениями.

 Когда их развели по времени, уперлись в скорость обработки на стороне сайта. Когда начали разделять большой обмен на отдельные потоки, нашли bottleneck уже внутри 1С. Позже появились новые потребители данных, 1С:Шина и новый вопрос — как контролировать доставку при асинхронной передаче.

Ниже — этот путь в том порядке, в котором мы его проходили с командой ASAP.

«Это ТСПУ РКН, поделать ничего нельзя» — а проблема три месяца ждала в консоли сервера

Время расследования · 2 дня Причин найдено · 3 Команд для победы · 1

Клиент — онлайн-СМИ застройщика федерального уровня, несколько десятков публикаций в день, своя редакция. С июня сайт периодически становился недоступен. Подрядчик, который ведёт техподдержку, прислал такое сообщение:

Работа с файлами в REST API Битрикс24 — та задача, где документация заканчивается ровно там, где начинаются проблемы. Официальные примеры показывают, как загрузить один файл в одно поле. А дальше выясняется, что у crm.item.update и crm.deal.update разные несовместимые форматы, что вложенный base64 через http_build_query уходит в никуда, а сервер при этом честно отвечает «result».

За год я делал файловую логику в шести проектах: перелив сделок между порталами, загрузка фотоописей с мобильного, парсинг PDF из карточек, сборка архивов, синхронизация аватаров. Везде подход получился разный.

Собрал всё в один разбор — шесть подходов с кодом и восемь граблей:

два формата файлового значения, которые нельзя смешивать, и почему при смешении затираются уже прикреплённые файлы;

тихий провал: HTTP 200, в ответе result, поле не обновилось;

useOriginalUfNames=Y, без которого UF_CRM_* молча игнорируются;

downloadUrl приходит с пустым auth= и без подстановки токена не скачивается, а при протухшем токене вместо файла отдаётся HTML-страница с кодом 200;

у одного изображения бывает несколько URL, и часть из них не работает — пришлось делать скоринг вариантов по эвристике.

В конце — таблица «что брать под какую задачу» и чеклист граблей. Двадцать блоков кода, всё из боевых проектов.

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

Меня зовут Михаил Емельянов, я ведущий разработчик в НЛМК ИТ. Команда, в которой я состою, занимается разработкой и поддержкой различных корпоративных информационных систем на базе Битрикс24.

Сегодня я хочу поговорить о разработке сервисов бронирования. Они используются повсеместно - от медицинских центров и отелей, до внутренних активностей в компаниях. На старте мы, как и многие, пользовались готовыми решениями. Это позволяло быстро закрыть потребность, но при этом нам осложняли жизнь некоторые системные недостатки:

- Юридические нюансы: обработка персональных данных по требованиям 152‑ФЗ и внутренних политик безопасности. Стороннему сервису не всегда можно передать всё, что нужно, а иногда это прямо запрещено.

- Стоимость: даже одно недельное мероприятие обходилось достаточно дорого.

- Процессные ограничения: неудобно быстро менять расписание «на лету» во время мероприятия, неидеальная логика резервирования времени приводила к редким, но болезненным коллизиям.

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

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

Воронка продаж или любая другая воронка (производства, закупок, HR) в любой CRM всегда начинается с бизнес-аналитики, т.е. надо понять процессы в бизнесе клиента и под них настроить IT инфраструктуру, а не наоборот.

Тыкать пальцами кнопки в Битрикс24 много ума не надо, а вот сделать правильно, именно так как надо клиенту - это и есть специальность интегратора CRM.

Воронка продаж это всегда определение:

Один хакер полтора часа исследовал поддельный Bitrix-сервер: нашёл конфигурацию, извлёк ложные учётные данные базы, попытался выгрузить таблицы и записать PHP-файл.

Другой клиент отправил в открытый Ollama-compatible API 27 тысяч реальных задач. Самый большой промпт содержал 919 тысяч символов. Модели за API при этом не было.

Я три месяца наблюдал за двумя среднеинтерактивными ханипотами — традиционным SCADA/Bitrix-стендом и поддельным AI gateway. В статье разбираю 2,5 млн событий Cowrie, стотысячный MySQL password spray, 183 сохранённых payload, массовую эксплуатацию AI API и MCP-разведку.

Привет, технари, я на Хабре недавно, решил делиться своей экспертизой и общаться с единомышленниками, чтобы иметь окружение схожих себе и обмениваться опытом. Сам своими руками сделал более 70 интеграций Битрикс24 и AmoCRM за 3 года, есть что выложить из опыта.

Отделам продаж постоянно нужны отчеты: конверсии, звонки и так далее, но особо развитым кампаниям надо отчеты уже кастомные, не шаблон. Если брать шаблонные отчеты в Битрикс24, то там кусок фронта достаточно шаблонный, что и обычно для CRM которая «для всех», это же не самописка. Там есть Конструктор отчетов, но там тоже очень много ограничений.

А если РОП или директор по продажам хочет кастомный отчет? В Rest API лезть?

При большом желании можно и в API лезть, но в Битрикс24 есть промежуточный вариант, полушаблон, полукод (кастом) — BI конструктор.

[В статье немеряно скриншотов — прим. НЛО]