Интеграция ТСД с 1С и CRM: как настроить обмен данными склада

Зачем нужна интеграция, если ТСД уже сканирует

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

Живая интеграция закрывает это окно: операция на ТСД — приёмка, отгрузка, инвентаризация — сразу отражается в учётной системе, а не ждёт следующей синхронизации по расписанию.

Способы обмена данными: API, файлы, очереди

Прямой API-обмен. Приложение на ТСД отправляет запрос напрямую в 1С или в промежуточный сервис, который пишет в учётную систему. Минимальная задержка, но требует стабильной связи на складе и нормально спроектированного API на стороне 1С — типовая конфигурация часто не даёт нужных методов из коробки.

Файловый обмен. Классический способ для 1С: выгрузка XML/CSV по расписанию или по событию, обмен через каталог или учётную шину. Проще в реализации, но добавляет задержку и требует обработки конфликтов, если один и тот же товар корректируют из двух источников почти одновременно.

Очередь сообщений. Для складов с высокой интенсивностью операций события кладут в очередь (например RabbitMQ или аналог), а 1С и мобильное приложение читают из неё независимо. Переживает кратковременные обрывы связи лучше, чем прямой синхронный вызов, но сложнее в разворачивании и поддержке.

Типичные проблемы синхронизации

• Один и тот же товар редактируют на ТСД и в 1С одновременно — нужна явная стратегия разрешения конфликтов, а не «кто последний записал».
• Справочники номенклатуры расходятся: на терминале товар есть, в 1С он переименован или объединён с другой позицией.
• Операция на терминале выполнена, а пакет с данными потерян при обрыве связи — без подтверждения доставки учёт тихо расходится с реальностью.
• Выгрузка остатков занимает минуты на крупной номенклатуре и блокирует работу склада на это время, если делать её в рабочие часы.

Офлайн-режим на складе без связи

Металлические стеллажи и бетонные стены часто глушат Wi-Fi в дальних углах склада. Приложение на ТСД должно уметь копить операции локально и отправлять их пакетом, как только связь появится, а не просто показывать ошибку и терять данные. Для складов с устойчиво слабым покрытием имеет смысл отдельно спроектировать очередь на самом устройстве с подтверждением о доставке каждой записи, а не полагаться на то, что переподключение произойдёт быстро.

Кого привлекать к интеграции

Настройка типового файлового обмена 1С часто по силам штатному программисту 1С. Но как только нужен API-слой, очередь сообщений, офлайн-синхронизация или единый обмен между несколькими системами (1С, CRM, WMS, мобильное приложение), задача переходит в разряд системной интеграции — здесь важен не только код, но и архитектура обмена: где хранится единый источник правды по остаткам, как обрабатывать конфликты и что происходит при недоступности одной из систем.

Чек-лист перед запуском

• Определён единый источник правды по остаткам — 1С, WMS или отдельный сервис.
• Выбран способ обмена: API, файлы или очередь — в зависимости от интенсивности операций и стабильности связи.
• Прописана стратегия разрешения конфликтов при одновременном изменении одной позиции.
• Приложение на ТСД умеет работать офлайн и докладывать операции после восстановления связи.
• Справочники номенклатуры синхронизированы и у них есть единый идентификатор между системами.
• Выгрузка больших объёмов данных не блокирует работу склада в рабочие часы.
• Проведён пилот на одном складе или одном участке перед переносом на весь парк устройств.