Двусторонний обмен с 1С: какие данные передавать и как часто
Содержание
Двусторонний обмен звучит просто: данные идут из 1С на портал и обратно. На практике именно здесь появляются дубли заказов, потерянные документы, устаревшие остатки и споры о том, какая цена верная. Причина почти всегда одна: правила обмена не были описаны заранее, и каждый разработчик решал их по-своему.
Ниже практическая схема, которую ЯЩЕР использует при проектировании.
Карта данных
| Объект | Источник | Направление | Частота |
|---|---|---|---|
| Номенклатура и характеристики | 1С | 1С → портал | при изменении или несколько раз в день |
| Цены и типы цен | 1С | 1С → портал | при изменении |
| Персональные цены и скидки | 1С | 1С → портал | при изменении |
| Остатки и резервы | 1С | 1С → портал | от нескольких раз в час до мгновенно |
| Контрагенты и договоры | 1С | 1С → портал | при изменении |
| Кредитный лимит и дебиторка | 1С | 1С → портал | несколько раз в день и при заказе |
| Заказы | портал | портал → 1С | сразу |
| Статусы заказов | 1С | 1С → портал | при изменении |
| Документы | 1С | 1С → портал | при создании |
| Новые клиенты | портал | портал → 1С | после проверки менеджером |
| Рекламации | портал | портал → 1С | сразу |
Карта данных составляется для каждого проекта и согласуется с бухгалтерией и отделом продаж до разработки.
Три режима обмена
Пакетный
Данные передаются по расписанию. Подходит для каталога, характеристик, справочников. Главное правило: передавать изменения, а не всё целиком. Полная выгрузка тысяч товаров каждые 15 минут перегружает 1С и мешает работе бухгалтерии.
Событийный
Система отправляет данные в момент изменения: создан заказ, изменился статус, сформирован документ, поступила оплата. Нужен для всего, что влияет на деньги и остатки.
По запросу
Портал запрашивает данные в момент действия пользователя: например, точный кредитный лимит или остаток дефицитной позиции перед отправкой заказа. Используется точечно, чтобы не нагружать 1С.
Хорошая интеграция комбинирует все три режима. Выбор одного режима для всего почти всегда приводит либо к устаревшим данным, либо к перегрузке базы.
| Режим | Скорость | Нагрузка на 1С | Для чего |
|---|---|---|---|
| Пакетный | минуты и часы | низкая при передаче изменений | каталог, справочники |
| Событийный | секунды | низкая | заказы, статусы, документы |
| По запросу | мгновенно | зависит от частоты | лимиты, дефицитные остатки |
Правила, которые нужно зафиксировать
- Один источник правды для каждого объекта.
- Уникальный ключ у каждой операции, чтобы повтор не создавал дубль.
- Порядок применения: что делать, если статус «отгружен» пришёл раньше «собран».
- Поведение при конфликте: если цена изменилась между добавлением в корзину и отправкой заказа.
- Версионирование формата: что происходит, когда в 1С добавили новый реквизит.
- Сверка: ежедневная проверка, что количество и суммы заказов совпадают в обеих системах.
- Права на ручную правку: какие данные можно менять на портале вручную, а какие нет.
- Поведение при недоступности 1С: принимать заказы и ставить в очередь или блокировать.
Как выбрать частоту для остатков
Частота зависит от того, как быстро меняется остаток и сколько стоит ошибка:
- Медленный ассортимент (оборудование, запчасти под заказ): несколько раз в день достаточно.
- Средний оборот (стройматериалы, хозтовары): несколько раз в час.
- Быстрый оборот и дефицит (ходовые позиции, акции): обновление при каждом изменении плюс проверка в момент заказа.
Пример: что происходит с заказом
- Дилер отправляет заказ на портале. Интеграционный слой присваивает ему ключ операции.
- Заказ уходит в 1С. 1С недоступна из-за обновления, заказ ждёт в очереди.
- Через 10 минут 1С доступна, заказ создаётся, ставится резерв.
- Ответ не доходит до портала из-за сбоя сети, портал повторяет отправку.
- 1С видит тот же ключ операции и не создаёт дубль, а возвращает номер уже созданного заказа.
- Портал показывает дилеру номер заказа и статус.
Без очереди и ключа операции этот сценарий закончился бы либо потерянным заказом, либо дублем.
Частые ошибки
- обмен «всё целиком раз в час», из-за которого 1С тормозит в рабочее время;
- отсутствие журнала: никто не может сказать, когда и почему заказ не дошёл;
- ручная правка данных на портале, которая потом затирается обменом;
- отсутствие тестовой базы: доработки проверяются на рабочей 1С;
- разные справочники единиц измерения в 1С и на портале;
- никто не отвечает за мониторинг обмена после запуска.
Частые вопросы
Нужна ли тестовая база 1С?
Да. Разрабатывать и проверять обмен на рабочей базе рискованно: ошибка может создать лишние документы в учёте.
Можно ли сделать обмен через стандартный модуль?
Для простого каталога и заказов иногда да. Для персональных цен, лимитов, нескольких складов и документов обычно нужна доработка.
Что делать, если 1С перегружена?
Перенести тяжёлые операции в интеграционный слой, передавать только изменения и отказаться от полных выгрузок в рабочее время.
Как передавать документы: файлом или данными?
Чаще всего данными плюс печатная форма в PDF. Так документ можно и показать в кабинете, и скачать.
Как часто нужна сверка?
Минимум раз в сутки для заказов и оплат, для остатков и цен по ситуации.
Можно ли передавать фото и файлы через обмен с 1С?
Можно, но для больших объёмов медиа удобнее хранить файлы отдельно, а через обмен передавать только ссылки.
