При организации распределенной торговой сети часто возникает ситуация, когда учет ведется в нескольких независимых базах 1С:Управление торговлей 10.3, а фронт-офис (магазины) работает на 1С:Розница 2.3. Казалось бы, стандартные механизмы обмена должны справляться с этой задачей, но на практике возникают коллизии, приводящие к параличу розничных продаж. Одной из самых неприятных проблем является самопроизвольное изменение типа склада в Рознице с «Розничного» на «Оптовый», что делает невозможным пробитие чеков и приемку товара через перемещения.
В этой статье мы подробно проанализируем, почему так происходит, разберем техническую подоплеку конфликта и рассмотрим несколько вариантов решения — от изменения архитектуры обмена до настройки правил конвертации данных.
Для начала проанализируем ситуацию. Когда у нас есть три независимые базы УТ 10.3, каждая из них считает себя полноправным владельцем данных. При синхронизации с базой Розница 2.3 происходит сопоставление объектов справочников. Рассмотрим, по каким критериям это происходит:
Выясним причину конфликта: Когда Розница синхронизируется с первой базой УТ, она создает или обновляет склад. Если во второй базе УТ существует склад с таким же кодом или наименованием, но в правилах обмена этой базы не проставлены специфические реквизиты для розничной торговли (или склад помечен как оптовый), то при второй синхронизации данные будут затерты. В 1С это называется «правилом последнего»: чья транзакция прошла позже, того настройки и применились.
В Рознице 2.3 склад тесно связан с сущностью Магазин. Если из УТ 10.3 приходит объект, который система идентифицирует как существующий склад, но в пакете данных отсутствуют признаки розничной точки, Розница «сбрасывает» тип склада до оптового. Это происходит потому, что для розничного склада в этой конфигурации требуется заполнение множества дополнительных реквизитов (тип цен, организация, правила ценообразования), которых в старой УТ 10.3 в таком виде может не существовать.
Как показывает практика и опыт участников обсуждения, наиболее эффективным решением является слияние нескольких баз УТ в одну централизованную базу. Рассмотрим, почему это работает:
После объединения баз в единую информационную систему проблема «прыгающих» типов складов исчезает сама собой, так как Розница получает согласованный поток данных из одного источника.
Если по каким-то причинам (например, плохой интернет или разные юридические лица) объединить базы УТ 10.3 невозможно, необходимо строго разграничить пространство имен данных. Проанализируем, как это реализовать по шагам:
УТ 10.3 необходимо назначить уникальный префикс информационной базы (например, «УТ1», «УТ2», «УТ3»). Это гарантирует, что коды складов и документов не будут пересекаться.Рознице обмен должен быть настроен так, чтобы она четко понимала, из какой базы приходят данные.Если мы не хотим менять архитектуру, нам придется вмешаться в «мозги» обмена — правила конвертации. Рассмотрим, как запретить системе портить данные розничных складов. Нам потребуется конфигурация «Конвертация данных 2.1».
В правилах обмена (ПКО — Правила Конвертации Объектов) для справочника Склады (или Магазины) можно прописать логику, которая будет проверять, существует ли объект в базе-приемнике. Посмотрим на пример алгоритма, который можно разместить в обработчике ПриЗагрузке:
// Пример логики для предотвращения смены типа склада
Если ОбъектМодифицирован Тогда
// Проверяем, является ли склад уже розничным в текущей базе
Если Ссылка.ВидСклада = Перечисления.ВидыСкладов.Розничный Тогда
// Запрещаем менять вид склада на оптовый, если он пришел пустой или иной из УТ
Объект.ВидСклада = Ссылка.ВидСклада;
КонецЕсли;
КонецЕсли;
Такой подход позволит один раз настроить магазины в Рознице 2.3 вручную, и последующие синхронизации из любых баз УТ 10.3 не смогут сбросить эти настройки в «Оптовый».
Проанализируем технический канал передачи данных. Использование облачных сервисов вроде Яндекс.Диска для прямого обмена файлами XML несет определенные риски:
Message_XXX_YYY.xml еще синхронизируется облаком, а Розница уже начала его загрузку, это может привести к повреждению данных или некорректному заполнению реквизитов.Розница просто не увидит.Рекомендуем: Использовать для обмена FTP-сервер. Это более надежный протокол, который гарантирует, что файл будет доступен для чтения только после его полной загрузки на сервер. Это исключает появление «битых» объектов в базе Розницы.
Подводя итог, отметим: синхронизация «многие-ко-многим» в среде 1С требует ювелирной настройки нормативно-справочной информации. Если есть возможность уйти от разрозненных баз в сторону одной центральной УТ — это всегда будет лучшим решением, которое сэкономит время программиста и нервы пользователей.