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