Спасибо за комментарий. Давайте разберём по фактам.
Про REST API и 1С. Протокол HTTP/REST технологически нейтрален. Наш API интегрируется не только с 1С — у части дилеров custom-системы на PHP/Python, у нескольких — SAP. Если у LOVOL дилер на PostgreSQL или MongoDB — этот же API подключится за те же 3 дня. Вопрос не в "программисте 1С", а в том, что 90% российских дилеров работают на 1С — это рыночная реальность.
Про гипотетический стек LOVOL. Вы час "дрючили ИИ" на тему того, что должно быть у китайских производителей. Хорошо. У меня встречный вопрос из практики:
Есть ли у LOVOL онлайн-каталог запчастей на русском языке? Не PDF на китайском, а структурированный каталог с поиском по артикулу, серийному номеру, интерактивными схемами узлов?
Потому что у большинства китайских производителей на российском рынке этого нет до сих пор. Дилер получает PDF-каталог, переводит сам, вносит в Excel, продаёт по телефону. Реальность. Мы с огромным удовольствием взялись бы за разработку интерактивных каталогов-взрыв-схем для LOVOL, Zoomlion, YTO и любых других производителей. PartsPublisher (Docware), который мы используем, изначально разрабатывался для немецких и японских автопроизводителей — он технологически нейтрален к бренду. Если у китайских производителей есть структурированные данные о составах изделий (аналог SEARCH) — подключаемся. Если нет — ну вот и разговор о том, кто где в цифровизации.
Про WeChat и IoT. WeChat-интеграция работает в Китае. Кто в России WeChat использует для B2B?. Telegram — да, WhatsApp — да, но это не "из коробки", это доработка под рынок.
IoT-мониторинг парка — отличная штука, когда она работает. Вопрос: кто её поддерживает, когда датчик на комбайне в Омской области отваливается в августе посреди уборочной? Местный дилер умеет чинить железо. Умеет ли он дебажить китайское IoT-решение с документацией на китайском?
Про мобильное приложение. Его нет — это факт. Но давайте честно: мобильное приложение для каталога запчастей — это удобство, не критичный функционал. Критичный функционал — найти деталь, узнать цену, оформить заказ, автоматически получить логистику из Хабаровска в Калининград (это пример). Адаптивный веб делает это без установки приложения, без обновлений в сторах, без версий под iOS/Android. Если завтра нужно приложение — делается 5-7 дней MVP, а за месяц готовый продукт, API тот же.
Итог. Вы сравниваете маркетинговые обещания LOVOL с реальным внедрением. Покажите мне работающий дилерский портал LOVOL в России с теми возможностями, что вы перечислили. Со структурированным каталогом, онлайн-заказом, реальной техподдержкой на русском. Если он есть — действительно интересно посмотреть. Для этого мы тут и делимся мнением и опытом.
А "час дрючить ИИ" — это не исследование рынка, это генерация гипотез. Я с 2012 года работаю с реальными дилерами, которые продают реальные запчасти реальным фермерам. Даже в 2026 году все выглядит "красиво", а по факту ...
Спасибо за развёрнутый комментарий — вопрос абсолютно по делу.
Честно: 1С:MDM и 1С:Шина в проекте не рассматривались как основные кандидаты из-за контекста задачи.
Про 1С:MDM. Инструмент правильный для задачи централизации мастер-данных внутри периметра одной организации. Но здесь ситуация другая: 40+ дилеров — это независимые юридические лица со своими IT-бюджетами, своими подрядчиками, своим темпом изменений. Обязать всех внедрить 1С:MDM как условие подключения к порталу — это не техническое решение, это многолетние переговоры и почти наверняка отказ большей части сети. Мы выбирали между «идеальной архитектурой данных» и «работающей интеграцией, которую дилер внедряет за 3-5 дней». Выбрали второе — осознанно.
Про 1С:Шину. Она хороша для интеграции внутри корпоративного 1С-контура. Наш случай — гибридный: веб-портал на Битрикс общается с внешними системами дилеров через HTTP. Шина здесь добавляет слой, который не снимает ни одну из наших проблем, но добавляет зависимость и стоимость.
Системная задача интероперабельности действительно не решена — и это не «архитектурная победа», это осознанный выбор. Клиент получил кастомную интеграцию с конкретными ограничениями: если завтра нужно подключить 20 новых дилеров с SAP — придётся дорабатывать. Стоимость владения через 5 лет выше, чем была бы при MDM-подходе.
Почему пошли на этот trade-off: КИИ-требования ограничивали стек, сроки и бюджет не предполагали многомесячного внедрения MDM у каждого дилера (дилеры не платили за интеграцию вообще), а минимализм API (5 методов) дал скорость подключения, которая в нашем контексте важнее архитектурной чистоты.
Если бы задача формулировалась как «построить унифицированную интеграционную платформу для всей экосистемы на следующие 10 лет» — разговор про 1С:MDM был бы первым. Но задача была другой, да и не у всех дилеров была 1С
Сейчас дам расклад, 1$ у нас ушел на анализ и python: PDF-Каталог был на 140+ страниц (мы оставили часть схем защиты растений для обучения и использования в. следующих задачах), весил он при этом 65мб. Токены чисто в Claude:
Все верно, мы реализовали систему на 1С-Битрикс, а не Б24. Изначально проектировали на Laravel, но в результате событий СВО стало понятно, что импортозамещению все-таки быть, и переиграли все на bitrix framework. Б24 слишком громоздкий, плюс установка во внутренний контур предприятия, плюс стоимость самого Б24, в итоге собрали все на лицензии "Стандарт" за три копейки :)
Во второй части надеюсь "пофантазировать" на тему будущих веток развития. Почему? Вероятно, заказчик будет мигрировать с SAP/TeamCenter, и сейчас стадия неопределенности.
Спасибо за комментарий. Давайте разберём по фактам.
Про REST API и 1С. Протокол HTTP/REST технологически нейтрален. Наш API интегрируется не только с 1С — у части дилеров custom-системы на PHP/Python, у нескольких — SAP. Если у LOVOL дилер на PostgreSQL или MongoDB — этот же API подключится за те же 3 дня. Вопрос не в "программисте 1С", а в том, что 90% российских дилеров работают на 1С — это рыночная реальность.
Про гипотетический стек LOVOL. Вы час "дрючили ИИ" на тему того, что должно быть у китайских производителей. Хорошо. У меня встречный вопрос из практики:
Есть ли у LOVOL онлайн-каталог запчастей на русском языке? Не PDF на китайском, а структурированный каталог с поиском по артикулу, серийному номеру, интерактивными схемами узлов?
Потому что у большинства китайских производителей на российском рынке этого нет до сих пор. Дилер получает PDF-каталог, переводит сам, вносит в Excel, продаёт по телефону. Реальность.
Мы с огромным удовольствием взялись бы за разработку интерактивных каталогов-взрыв-схем для LOVOL, Zoomlion, YTO и любых других производителей. PartsPublisher (Docware), который мы используем, изначально разрабатывался для немецких и японских автопроизводителей — он технологически нейтрален к бренду. Если у китайских производителей есть структурированные данные о составах изделий (аналог SEARCH) — подключаемся. Если нет — ну вот и разговор о том, кто где в цифровизации.
Про WeChat и IoT. WeChat-интеграция работает в Китае. Кто в России WeChat использует для B2B?. Telegram — да, WhatsApp — да, но это не "из коробки", это доработка под рынок.
IoT-мониторинг парка — отличная штука, когда она работает. Вопрос: кто её поддерживает, когда датчик на комбайне в Омской области отваливается в августе посреди уборочной? Местный дилер умеет чинить железо. Умеет ли он дебажить китайское IoT-решение с документацией на китайском?
Про мобильное приложение. Его нет — это факт. Но давайте честно: мобильное приложение для каталога запчастей — это удобство, не критичный функционал. Критичный функционал — найти деталь, узнать цену, оформить заказ, автоматически получить логистику из Хабаровска в Калининград (это пример). Адаптивный веб делает это без установки приложения, без обновлений в сторах, без версий под iOS/Android. Если завтра нужно приложение — делается 5-7 дней MVP, а за месяц готовый продукт, API тот же.
Итог. Вы сравниваете маркетинговые обещания LOVOL с реальным внедрением. Покажите мне работающий дилерский портал LOVOL в России с теми возможностями, что вы перечислили. Со структурированным каталогом, онлайн-заказом, реальной техподдержкой на русском. Если он есть — действительно интересно посмотреть. Для этого мы тут и делимся мнением и опытом.
А "час дрючить ИИ" — это не исследование рынка, это генерация гипотез. Я с 2012 года работаю с реальными дилерами, которые продают реальные запчасти реальным фермерам. Даже в 2026 году все выглядит "красиво", а по факту ...
Спасибо за развёрнутый комментарий — вопрос абсолютно по делу.
Честно: 1С:MDM и 1С:Шина в проекте не рассматривались как основные кандидаты из-за контекста задачи.
Про 1С:MDM. Инструмент правильный для задачи централизации мастер-данных внутри периметра одной организации. Но здесь ситуация другая: 40+ дилеров — это независимые юридические лица со своими IT-бюджетами, своими подрядчиками, своим темпом изменений. Обязать всех внедрить 1С:MDM как условие подключения к порталу — это не техническое решение, это многолетние переговоры и почти наверняка отказ большей части сети. Мы выбирали между «идеальной архитектурой данных» и «работающей интеграцией, которую дилер внедряет за 3-5 дней». Выбрали второе — осознанно.
Про 1С:Шину. Она хороша для интеграции внутри корпоративного 1С-контура. Наш случай — гибридный: веб-портал на Битрикс общается с внешними системами дилеров через HTTP. Шина здесь добавляет слой, который не снимает ни одну из наших проблем, но добавляет зависимость и стоимость.
Системная задача интероперабельности действительно не решена — и это не «архитектурная победа», это осознанный выбор. Клиент получил кастомную интеграцию с конкретными ограничениями: если завтра нужно подключить 20 новых дилеров с SAP — придётся дорабатывать. Стоимость владения через 5 лет выше, чем была бы при MDM-подходе.
Почему пошли на этот trade-off: КИИ-требования ограничивали стек, сроки и бюджет не предполагали многомесячного внедрения MDM у каждого дилера (дилеры не платили за интеграцию вообще), а минимализм API (5 методов) дал скорость подключения, которая в нашем контексте важнее архитектурной чистоты.
Если бы задача формулировалась как «построить унифицированную интеграционную платформу для всей экосистемы на следующие 10 лет» — разговор про 1С:MDM был бы первым. Но задача была другой, да и не у всех дилеров была 1С
deep seek использовали для парсера данных и скриптов, он значительно дешевле обходится.
Сейчас дам расклад, 1$ у нас ушел на анализ и python:
PDF-Каталог был на 140+ страниц (мы оставили часть схем защиты растений для обучения и использования в. следующих задачах), весил он при этом 65мб.
Токены чисто в Claude:
Всего использовано: 720,207 токенов
Входных: 429,191
Выходных: 291,016
Общая стоимость: $5.65 (537₽)
По этапам:
Анализ каталога: $0.82
Валидация: $0.31
Маппинг: $2.02
Региональная адаптация: $0.57
Документация: $0.96
Страницы сейчас отключены, ждем согласования. Все будет! Ж)
это что-то про seo c помощью нейросетей :)
На будущее учту - сделаю больше графики, чтобы было понятно без слов.
Расход на api был <1$, через open router настроена работа связки deep seek + Claude
Забыл добавить ссылку whitepapper по DSAC на https://www.webformula.pro/upload/DSAC-Whitepapper-2026-Webformula.pdf
Подробно описал эволюцию с 2016 года до наших дней :)
Все верно, мы реализовали систему на 1С-Битрикс, а не Б24. Изначально проектировали на Laravel, но в результате событий СВО стало понятно, что импортозамещению все-таки быть, и переиграли все на bitrix framework. Б24 слишком громоздкий, плюс установка во внутренний контур предприятия, плюс стоимость самого Б24, в итоге собрали все на лицензии "Стандарт" за три копейки :)
Во второй части надеюсь "пофантазировать" на тему будущих веток развития. Почему? Вероятно, заказчик будет мигрировать с SAP/TeamCenter, и сейчас стадия неопределенности.