Почему после обновления БИТ.ФИНАНС исчезают платежные позиции из журналов документов на MS SQL и как это исправить?

← На главную

При обновлении крупных корпоративных систем на базе 1С, таких как «1С:Комплексная автоматизация» или «1С:ERP Управление предприятием» совместно с отраслевым модулем «БИТ.ФИНАНС», технические специалисты часто сталкиваются со специфическими ошибками СУБД. Одна из самых коварных проблем — визуальное «исчезновение» документов из общих журналов (например, исчезновение документов Платежная позиция из журнала Позиции внутри документа Заявка на перемещение ДС) при том, что физически сами документы остаются в базе данных и доступны через стандартные списки.

В этой статье мы подробно разберем, почему возникает такое поведение, в чем разница между файловой базой и MS SQL Server при обновлении конфигураций с расширениями, и какими методами можно гарантированно восстановить видимость и корректную работу документов.

Анализ проблемы: почему на файловой базе все работает, а на SQL — нет?

Рассмотрим стандартную ситуацию. Выполнен переход с релиза Комплексной автоматизации 2.2 (с БИТ.ФИНАНС) на релиз 2.4. Обновление на файловой копии базы данных проходит успешно. Однако при обновлении рабочей базы, развернутой на MS SQL Server, пользователи обнаруживают, что в журнале позиций перестали отображаться старые платежные документы. При этом:

Новые документы создаются, проводятся и отображаются в журнале корректно.
Если выгрузить «проблемный» документ через обработку ВыгрузкаЗагрузкаXML из старой базы и загрузить в новую — он мгновенно появляется в журнале.
Обычное групповое перепроведение документов не дает никакого результата.
При отключении расширений система полностью теряет работоспособность, так как логика БИТ.ФИНАНС и кастомные реквизиты завязаны на расширения.

Выясним глубинную причину этого сбоя. При обновлении конфигурации платформа 1С выполняет реструктуризацию таблиц базы данных. В файловом варианте этот процесс происходит последовательно в рамках одного процесса. В клиент-серверном варианте (MS SQL) платформа осуществляет реструктуризацию через создание временных таблиц СУБД, пакетную вставку данных (BULK INSERT) и последующее перестроение индексов.

Если в расширении добавлены собственные реквизиты к документам Платежная позиция или изменен состав общего журнала Позиции, на уровне MS SQL под эти расширения создаются отдельные физические таблицы с префиксами вида _Extension. При обновлении на SQL-сервере из-за особенностей работы платформы связь между основными таблицами документов и таблицами расширений может нарушиться. Данные физически остаются в базе (поэтому документы видны в своих списках), но их регистрация в таблице журнала документов СУБД (_DocumentJournal) сбивается. Обычное проведение не помогает, так как система оптимизирует запись и не обновляет неизмененные индексы журнала.

Решение 1. Очистка кэша сервера «1С:Предприятие»

Часто сбои в отображении журналов после обновлений на SQL связаны с тем, что рабочие процессы сервера 1С (rphosts) кэшируют старую структуру метаданных расширения. Проанализируем схему очистки серверного кэша:

Остановите службу сервера «1С:Предприятия» (1C:Enterprise 8.3 Server Agent) через консоль управления службами services.msc.
Перейдите в каталог расположения данных сервера. По умолчанию это путь:
C:\Program Files\1cv8\srvinfo\ (или C:\Program Files (x86)\1cv8\srvinfo\).
Найдите папку вашего кластера (обычно имеет имя вида reg_1541).
Внутри папки кластера найдите папки с идентификаторами баз данных (UUID) и удалите в них каталоги кэша (папки с именами типа snccntry, а также временные файлы). Внимание: не удаляйте файлы журналов регистрации (папку 1Cv8Log), если они вам необходимы!
Запустите службу сервера 1С заново.

Решение 2. Тестирование и исправление с принудительной реструктуризацией

Для того чтобы заставить MS SQL Server заново сопоставить таблицы документов, расширений и журналов, необходимо выполнить процедуру тестирования и исправления (ТИС). Разберем по шагам, как правильно это сделать:

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

Решение 3. Программная перезапись документов («мягкое» восстановление)

Поскольку импорт через XML заставляет платформу создавать объект «с нуля» и тем самым регистрировать его во всех журналах, мы можем сымитировать этот процесс программно. Нам нужно обойти оптимизацию платформы при записи документов.

Напишем внешнюю обработку, которая принудительно перезапишет документы Платежная позиция с отключением режима загрузки данных, предварительно внеся фиктивное изменение в реквизиты, чтобы СУБД гарантированно обновила строку журнала.

Рассмотрим пример кода для такой обработки:


Процедура ВосстановитьДокументыВЖурнале() Экспорт
    
    // Выбираем документы за период, в котором произошло "исчезновение"
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |	ПлатежнаяПозиция.Ссылка КАК Ссылка
        |ИЗ
        |	Документ.Хозрасчетный КАК ПлатежнаяПозиция
        |ГДЕ
        |	ПлатежнаяПозиция.Дата МЕЖДУ &НачалоПериода И &КонецПериода";
    
    // Примечание: укажите имя документа БИТ.ФИНАНС, используемого в вашей версии
    // В данном примере используется обобщенный алгоритм для "ПлатежнаяПозиция"
    Запрос.УстановитьПараметр("НачалоПериода", НачалоДня(Объект.ПериодРегистрации.ДатаНачала));
    Запрос.УстановитьПараметр("КонецПериода", КонецДня(Объект.ПериодРегистрации.ДатаОкончания));
    
    РезультатЗапроса = Запрос.Выполнить();
    ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();
    
    Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
        
        ДокументОбъект = ВыборкаДетальныеЗаписи.Ссылка.ПолучитьОбъект();
        
        // Отключаем режим загрузки, чтобы сработали все обработчики и подписки событий
        ДокументОбъект.ОбменДанными.Загрузка = Ложь;
        
        // Вносим фиктивное изменение в несущественный реквизит (например, Комментарий)
        // Это заставит SQL-сервер перезаписать всю строку таблицы, включая индексы журнала
        СтарыйКомментарий = ДокументОбъект.Комментарий;
        ДокументОбъект.Комментарий = СтарыйКомментарий + " "; 
        
        Попытка
            // Записываем документ в режиме проведения (или просто записи, если он не был проведен)
            Если ДокументОбъект.Проведен Тогда
                ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);
            Иначе
                ДокументОбъект.Записать(РежимЗаписиДокумента.Запись);
            КонецЕсли;
            
            // Возвращаем комментарий в исходное состояние для чистоты данных
            ДокументОбъект.Комментарий = СтарыйКомментарий;
            ДокументОбъект.Записать(ДокументОбъект.РежимЗаписи);
            
            Сообщить("Документ " + Строка(ДокументОбъект) + " успешно восстановлен в журнале.");
        Исключение
            Сообщить("Не удалось записать документ: " + Строка(ДокументОбъект) + ". Ошибка: " + ОписаниеОшибки());
        КонецПопытки;
        
    КонецЦикла;
    
КонецПроцедуры

Данный скрипт обходит механизм оптимизации записи 1С. Добавление пробела в комментарий и последующая запись взводят триггеры СУБД, обновляя физические индексы связи между документом Платежная позиция, расширениями БИТ.ФИНАНС и журналом Позиции.

Решение 4. Проверка прав доступа и механизма RLS

Проанализируем еще одну возможную причину. Во время обновления КА и БИТ.ФИНАНС часто затрагиваются шаблоны ограничений доступа на уровне записей (RLS). Если у документов прошлых периодов не заполнен какой-то новый аналитический реквизит (например, направление деятельности или подразделение), который стал обязательным для RLS в новом релизе, система безопасности СУБД начнет скрывать эти записи из общего журнала.

Выяснить, виноват ли RLS, очень просто: зайдите в систему под учетной записью с полными правами (у которой полностью отключено ограничение доступа на уровне записей) и проверьте видимость платежных позиций в журнале. Если под полными правами документы видны, а под обычным пользователем — нет, то проблема кроется в настройках прав доступа. В таком случае вам потребуется пересмотреть профили групп доступа или заполнить новые аналитики в старых документах.