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