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