Почему в 1С:Управление торговлей 11 дублируются строки в банковских выписках при одинаковых ссылках на документы?

В процессе работы с конфигурациями на базе 1С:ERP и 1С:Управление торговлей 11 пользователи часто сталкиваются с загадочным явлением: в списке Безналичные платежи или в банковской выписке один и тот же документ отображается дважды. При этом, если попытаться удалить одну строку, исчезает и вторая, а при попытке открыть «дубль», система просто переносит фокус на уже открытое окно документа. Проанализируем эту ситуацию и разберем по шагам, как исправить эту техническую ошибку.

Природа проблемы: почему это не физические дубли?

Важно понимать, что в 99% случаев мы имеем дело не с копированием самого объекта ДокументСсылка в базе данных, а с ошибкой формирования динамического списка. В современных решениях 1С списки документов строятся не напрямую по таблицам документов, а через вспомогательные механизмы оптимизации. Если в этих механизмах происходит сбой, одна и та же ссылка на документ начинает «двоиться» в представлении пользователя.

Рассмотрим основные причины, по которым это происходит:

1. Задвоение в регистре «Реестр документов»: Это специальный регистр, в котором хранится краткая информация о документах для быстрого отображения списков. Если при записи документа или при загрузке из «Клиент-банка» в этот регистр попали две записи с одинаковой ссылкой, динамический список покажет две строки.
2. Ключи аналитики учета: Система использует регистры сведений для хранения уникальных сочетаний партнеров, контрагентов и договоров. Если документ ошибочно привязался к двум разным ключам аналитики (например, из-за скрытых дублей контрагентов), левое соединение в запросе списка даст две строки на один документ.
3. Разные текстовые представления: Как отмечалось в обсуждении, в одной строке контрагент может называться «ПАО Сбербанк», а в другой — «Сбербанк ПАО». Это происходит из-за того, что данные в кэш регистра «Реестр документов» записываются в разные моменты времени или из разных источников обмена.

Способ 1. Очистка и обновление «Реестра документов»

Это самый эффективный метод решения проблемы. Выясним причину: почему реестр «глючит»? Обычно это происходит при обновлении релиза или прерывании процесса записи. Нам необходимо заставить систему пересчитать записи в этом служебном регистре.

Для исправления выполним следующие действия:

1. Перейдем в раздел НСИ и администрирование — Обслуживание — Корректировка данных.
2. Найдем регламентное или фоновое задание Обновление реестра документов.
3. Если стандартный интерфейс не позволяет запустить полную перегенерацию, можно воспользоваться небольшой обработкой или выполнить код в консоли для конкретного проблемного документа.

Проанализируем пример кода, который принудительно обновляет записи в реестре для конкретной ссылки:

// Очистка записей реестра по конкретному документу
НаборЗаписей = РегистрыСведений.РеестрДокументов.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Ссылка.Установить(ПроблемнаяСсылка);
НаборЗаписей.Записать();

// Вызов процедуры обновления из типового модуля (имя может меняться в зависимости от релиза)
РегистрыСведений.РеестрДокументов.ОбновитьДанныеОбъекта(ПроблемнаяСсылка);

Способ 2. Проверка ключей аналитики учета по партнерам

Если обновление реестра не помогло, рассмотрим ситуацию с ключами аналитики. В УТ 11 за построение связей отвечает регистр КлючиАналитикиУчетаПоПартнерам. Если для одного ИНН в базе создано несколько Партнеров или Контрагентов, система может запутаться.

Посмотрим на алгоритм действий:

1. Запустим стандартную обработку Поиск и удаление дублей.
2. Выберем область поиска Контрагенты и Партнеры.
3. Если дубли найдены, выполним их объединение. Система автоматически пересчитает ссылки в документах и, что более важно, схлопнет записи в регистрах аналитики.

Также стоит проверить регистр СоответствиеОбъектовИнформационныхБаз, если вы используете обмен с бухгалтерией. Иногда «фантомные» связи приходят именно оттуда в процессе синхронизации.

Способ 3. Техническая проверка через консоль запросов

Чтобы окончательно убедиться, что документ в базе один, выполним диагностический запрос. Это поможет исключить версию о физическом дублировании объектов (что было бы критической ошибкой базы данных).

Используем следующий текст запроса:

ВЫБРАТЬ
    Списание.Ссылка,
    Списание.Номер,
    Списание.Дата,
    КОЛИЧЕСТВО(Списание.Ссылка) КАК Количество
ИЗ
    Документ.СписаниеБезналичныхДенежныхСредств КАК Списание
ГДЕ
    Списание.Номер = &НомерДокумента
СГРУППИРОВАТЬ ПО
    Списание.Ссылка,
    Списание.Номер,
    Списание.Дата

Если в результате мы видим только одну строку с количеством «1», значит, проблема локализована в слое отображения (динамический список + регистры-кэши). Если же строк две и у них разные внутренние идентификаторы (UUID), то это реальные дубли, которые нужно удалять через Поиск и замену значений.

Рекомендации по предотвращению проблемы

Для того чтобы в будущем избежать «клонирования» документов в банковских выписках, придерживайтесь следующих правил:

• Своевременное обновление: Проблема часто встречается в релизах ветки 11.4.6.x. В более поздних версиях механизмы обновления Реестра документов были существенно доработаны.
• Контроль чистоты НСИ: Не допускайте создания дублей контрагентов с одинаковыми ИНН/КПП. Именно они провоцируют ошибки в ключах аналитики.
• Регламентные задания: Убедитесь, что в базе включено и корректно выполняется задание Текстовое описание внеоборотных активов и реестра документов. Оно отвечает за актуализацию строковых представлений в списках.

Таким образом, мы выяснили, что «клонирование» документов — это всего лишь некорректное поведение служебных таблиц оптимизации. Используя инструменты пересчета реестров и очистки дублей аналитики, вы сможете вернуть спискам документов корректный вид.