Каждый второй заказчик из реального бизнеса говорит одну и ту же фразу: «У нас весь учёт в 1С, приложение вообще реально подружить?». За этой фразой обычно прячется страх, что интеграция — это что-то бесконечно дорогое и хрупкое.
Хорошая новость: в 90% случаев это решаемо, и часто проще, чем рисуют. Плохая новость: способ интеграции нужно выбрать правильный, иначе вы получите систему, в которой цифры в приложении и на кассе вечно расходятся.
01 · «У нас 1С» — это не препятствие
1С у большинства компаний — это рабочая система учёта: товары, остатки, клиенты, скидки, продажи. Приложению она нужна как источник правды: чтобы баллы лояльности, цены и баланс были такими же, как на кассе. Задача интеграции — не переписать 1С, а наладить обмен данными между ней и приложением.
Приложение не заменяет 1С и не лезет внутрь неё. Оно синхронизируется с ней — как два сотрудника, которые сверяют свои таблицы по расписанию.
02 · Главная правда: у 1С обычно нет API
Вот что важно понять до начала: у типовой 1С на стороне клиента нет готового HTTP-API, к которому приложение могло бы просто «постучаться». Нет REST-эндпоинтов, нет токенов, нет документации. 1С — это про учёт, а не про то, чтобы её дёргали извне.
Поэтому интеграция почти всегда — это не «подключиться к API 1С», а «договориться, как 1С и приложение будут обмениваться данными». И тут есть три рабочих сценария.
03 · Три способа связать приложение с 1С
В большинстве проектов мы выбираем третий вариант с файловым обменом под капотом — он не зависит от того, что 1С может «прилечь» на обновление, и не требует пускать 1С в публичный интернет.
04 · Как это работало у нас: сеть «Бавария»
Конкретный пример — приложение для сети из 7 пивных магазинов в Краснодарском крае. Карты лояльности и баллы у клиента ведутся в 1С, и приложение обязано показывать ровно те же цифры, что касса — иначе доверие к лояльности рушится с первого визита.
Мы сделали отдельный сервис обмена. 1С выгружает три файла:
barcodes.json— штрих-коды карт лояльности;bonus_points.json— бонусные баллы клиентов;total_spent.json— накопленные суммы покупок (от них зависит уровень карты).
Бэкенд забирает их по расписанию, разносит по базе и обновляет статус каждой записи. А в админке владелец видит, когда была последняя синхронизация, сколько записей по каждому файлу прошло, и может запустить обмен вручную одной кнопкой — без звонка разработчикам.
Главное в интеграции — не «красиво подключиться», а сделать так, чтобы расхождение между приложением и кассой не накапливалось. И чтобы владелец сам видел, что синхронизация жива.
05 · Что синхронизировать, а что — нет
Соблазн — «давайте гонять через 1С вообще всё». На практике это делает систему медленной и хрупкой. Мы разделяем данные так:
- Из 1С в приложение: то, где 1С — источник правды. Остатки, цены, баллы, уровни лояльности, статусы клиентов.
- В приложении, без 1С: то, что 1С не касается. Профиль пользователя, избранное, история действий в приложении, пуши, согласия на обработку данных.
- Из приложения в 1С (осторожно): заказы и новые клиенты — да, но через буфер и с проверкой, а не напрямую в боевую базу.
06 · Чек-лист перед интеграцией
- Какая версия и конфигурация 1С? УТ, Розница, Бухгалтерия, самописная — от этого зависит способ обмена.
- Есть ли свой специалист 1С? Если да — можно рассмотреть веб-сервис. Если нет — файловый обмен.
- Как часто данным нужно быть свежими? Раз в час — хватит файлов. Real-time остатки — это другой разговор и другой бюджет.
- Где «источник правды» по каждому типу данных? Решите это до старта — иначе получите два места, где «правильная» цифра, и вечные расхождения.
- Что будет, если 1С недоступна? Приложение должно продолжать работать на своих данных, а не падать вместе с 1С.
Если у вас есть 1С и идея приложения — опишите задачу. На бесплатном «Разборе идеи» мы посмотрим вашу конфигурацию и скажем, каким способом интеграцию делать дешевле и надёжнее именно в вашем случае.