Синхронизация данных между 1С:Управление торговлей 11 и 1С:Розница 2 — одна из наиболее востребованных, но в то же время сложных интеграционных задач. На практике типовой обмен «из коробки» нередко вызывает ошибки: дублирование справочников, сбои при переносе серий номенклатуры, некорректную передачу дисконтных карт и накоплений по клиентам. Разберем по шагам архитектурные причины этих проблем и практические способы их решения.
Проанализируем первую и самую частую причину ошибок синхронизации — несовпадение версий конфигураций. Разработка правил конвертации ведется под конкретные пары релизов УТ и Розницы. При несовместимости версий реквизитный состав объектов может различаться, что приводит к фатальным ошибкам выгрузки или потере данных.
Розницы совместим текущий релиз УТ.Выясним причину, почему при первом обмене в базах появляются дубли единиц измерения, видов номенклатуры, статей ДДС и контрагентов. По умолчанию механизм синхронизации сопоставляет элементы по уникальному идентификатору (GUID). Если классификаторы и нормативно-справочная информация (НСИ) заводились в обеих конфигурациях независимо друг от друга до настройки обмена, их идентификаторы различаются.
ОКЕИ, ставки НДС, склады и кассы).УТ с последующей трансляцией в магазины. На стороне узлов Розницы создание элементов справочника Номенклатура рекомендуется заблокировать правами доступа.Рассмотрим подробнее работу подсистемы лояльности. В конфигурации 1С:Управление торговлей 11 реализовано строгое разделение понятий Партнеры (управленческий учет клиентов) и Контрагенты (юридические лица). В 1С:Розница 2 учет ведется в разрезе контрагентов и физических лиц. Из-за этого при передаче данных из Розницы в УТ все новые покупатели могут ошибочно привязываться к одному базовому партнеру.
Для корректного ведения дисконтной программы применим следующие правила:
УТ). При обмене типовые правила автоматически транслируют их в Розницу в виде соответствующих документов и условий.Рознице в качестве владельцев дисконтных карт необходимо указывать Контрагентов, а не просто физических лиц, чтобы в УТ корректно формировалась связь с партнером.Чек ККМ и Отчет о розничных продажах).HTTP-сервисы.Проанализируем ситуацию с миграцией серий товаров. Типовой обмен не переносит серии в документах поступления и реализации, если в конфигурациях не согласованы Политики учета серий. Если на складе в УТ используется справочное указание серий, а в магазине Розницы включен учет остатков по сериям (или наоборот), документы при загрузке не проведутся либо потеряют табличные части с серийными номерами.
Для решения проблемы выравниваем настройки политики учета серий для каждого вида номенклатуры и каждого склада/магазина в обеих конфигурациях до начала активного документооборота.
Посмотрим на частую проблему в распределенных сетях: документ поступления или перемещения регистрируется к отправке во все магазины без учета фильтрации по узлам. Это приводит к засорению очередей обмена и передаче избыточных данных.
Для исправления алгоритма регистрации объектов в конфигурации Конвертация данных откроем правила регистрации и добавим в обработчик события ПриОбработке проверку принадлежности документа к магазину узла:
Если Объект.Склад.Магазин <> УзелДляПередачи.Магазин Тогда
Отказ = Истина;
КонецЕсли;
Разберем ситуации, когда двусторонний постоянный обмен между УТ и Розницей создает избыточную нагрузку на сопровождение:
УТ в Розницу, а в обратную сторону выгружаем исключительно свернутые за смену документы Отчет о розничных продажах и кассовые ордера, исключая миграцию промежуточных документов внутреннего товародвижения.1С:Розница, а учет верхнего уровня ведут через периодический обмен с 1С:Бухгалтерией. Если же в приоритете оптовые продажи, сложный расчет себестоимости и интеграция с внешними площадками (например, 1С-Битрикс), целесообразно использовать режим работы тонкого клиента 1С:Управление торговлей непосредственно на рабочих местах кассиров при наличии стабильного интернет-канала.