Настройка обменов и синхронизации данных в 1С: между базами и с сайтом

Какие бывают обмены

Под «настройкой обмена» люди имеют в виду четыре разные задачи, и путаница между ними портит половину таких проектов. Способ, срок и цена у них отличаются в разы.

Обмен с сайтом отличается сильнее всего. Там участвует система, которая живёт по своим правилам, и вопрос «кто хозяин цены» становится скорее организационным, чем техническим. Про эту разновидность у меня есть отдельные разборы: как связать интернет-магазин с 1С и что подготовить до начала.

Синхронизация или правила переноса

Первая развилка, и проходить её надо в правильном порядке. Сначала проверяем типовой механизм, и только если он не подходит, пишем правила.

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

Если написать правила переноса там, где хватало типовой синхронизации, платить придётся дважды: при внедрении и потом при каждом обновлении.

Что решить до настройки

Эти пять вопросов определяют и способ, и трудоёмкость. Если ответов нет, обмен настроят «как понял исполнитель», а расхождения обнаружатся в отчётности.

1. Состав данных. Что именно передаём: номенклатуру, контрагентов, документы, остатки, цены, оплаты. Списком, а не словами «всё нужное».
2. Направление. По каждому виду данных отдельно: в одну сторону или в обе.
3. Кто хозяин данных. Об этом ниже, это самый важный пункт.
4. Частота. Какая задержка допустима. Остаткам для магазина и ценам для сайта нужна разная частота: раз в сутки для одного нормально, для другого недопустимо.
5. Что делать при конфликте. Когда один объект поправили с двух сторон между обменами.

Кто хозяин данных

Почти все долгие проблемы с обменом сводятся к одному. Для какого-то справочника не договорились, кто им управляет, и обе системы считают свою версию правильной.

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

Решение здесь скорее управленческое. По каждому виду данных выбирают одну систему, где их правят, а во второй они доступны только для чтения. Один раз составленная таблица «данные, хозяин, направление» экономит месяцы разбирательств.

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

Где обмены ломаются

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

Как узнать, что обмен встал

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

Обмен без этих четырёх пунктов правильнее считать ненастроенным, каким бы корректным ни было его содержимое.

Как принимать результат

Обмен нельзя принять по словам «настроено, работает». Его принимают по сценариям, и они одинаковы почти для любой пары баз.

Эти сценарии стоит согласовать до начала работ. Тогда «готово» становится проверяемым состоянием, а не мнением исполнителя.

Что прислать для оценки

1. Названия и версии обеих конфигураций, типовые они или изменённые.
2. Файловые базы или клиент-серверные, есть ли между ними сетевой доступ.
3. Перечень данных для передачи и направление по каждому виду.
4. Допустимая задержка: минуты, часы или раз в сутки.
5. Есть ли уже настроенный обмен, который работает неправильно.

С этими пятью пунктами оценка занимает один разбор. Без них любая цифра будет вилкой в несколько раз.