Каждый администратор и программист 1С рано или поздно сталкивается с мистической ситуацией: один и тот же отчет (например, оборотно-сальдовая ведомость или ведомость по товарам на складах) с абсолютно идентичными настройками под одним пользователем показывает верные данные, а под другим — пустые строки или некорректные остатки. Первая реакция в такой ситуации — погрешить на некорректный пересчет итогов базы данных или на локальный кэш пользователя. Однако на практике корни проблемы чаще всего кроются в механизмах работы Системы компоновки данных (СКД) и особенностях хранения пользовательских настроек.
В этой статье мы подробно проанализируем причины этой классической проблемы, выясним, почему обычная очистка локального кэша не помогает, и разберем по шагам действенные методы устранения подобных сбоев.
---
Давайте проанализируем ситуацию: пользователь выполняет стандартную очистку локального кэша (удаляет файлы из каталогов AppData\Local\1C и AppData\Roaming\1C), но это не решает проблему. Почему? Дело в том, что СКД хранит пользовательские настройки отчетов вовсе не на локальном компьютере.
Все персональные изменения (настройки отборов, состав полей, условное оформление и группировки) сохраняются непосредственно в информационной базе — в системной таблице, которая называется Хранилище системных настроек (или ХранилищеНастроек). Когда пользователь нажимает в отчете кнопку «Установить стандартные настройки», система зачастую сбрасывает только те параметры, которые выведены на форму отчета. При этом глубокие, скрытые настройки самого варианта СКД в базе данных могут остаться неизменными или «зависнуть» из-за внутренних сбоев платформы.
Именно поэтому копирование настроек от «исправного» пользователя к проблемному (как упоминается в обсуждении) решает задачу: эта операция принудительно перезаписывает поврежденную запись в системной таблице базы данных, полностью заменяя старый профиль настроек новым, корректным.
---
Рассмотрим подробнее одну из самых неочевидных проблем — влияние пустого отбора. В СКД незаполненное поле отбора может обрабатываться платформой по-разному в зависимости от активности флага «Использование». Пользователь может не видеть отбор визуально на форме, но система будет учитывать его при генерации запроса к СУБД.
Выделим два состояния пустого отбора:
Номенклатура или Склад), галочка активности напротив него установлена, а само поле значения оставлено пустым, СКД транслирует это в SQL-запрос как жесткое условие. В СУБД отправляется запрос следующего вида:
ВЫБРАТЬ
ТоварыНаСкладахОстатки.Номенклатура,
ТоварыНаСкладахОстатки.ВНаличииОстаток
ИЗ
РегистрНакопления.ТоварыНаСкладах.Остатки(&Период, Номенклатура = &ПустаяСсылка)
В результате такой отчет вернет пустые строки или остатки только по незаполненным («пустым») позициям номенклатуры, что пользователь воспримет как жесткий глюк отчета.
ГДЕ, и отчет формируется корректно по всем данным информационной базы.У разных пользователей из-за индивидуальной истории открытия и изменения отчета этот скрытый флаг Использование для пустых полей может находиться в разном состоянии. Визуально на форме настройки выглядят одинаково (значения пустые), но результат выборки получается принципиально разным.
---
Даже если в информационной базе полностью отключен механизм RLS (ограничение доступа на уровне записей), права пользователя и настройки системы могут неявно влиять на компоновку запроса в СКД. Проанализируем два важных фактора:
ВестиУчетПоНесколькимОрганизациям), а у второго пользователя эта опция отключена, СКД автоматически перестроит структуру запроса. Платформа физически исключит «ненужные» измерения (такие как Организация) из запроса для пользователя с отключенной опцией. В итоге суммы по отчету могут поползти или исказиться.NULL. Из-за этого конечные итоги могут рассчитаться неверно.---
Если вы столкнулись с расхождением данных в отчетах у разных пользователей, выполните следующие действия по порядку.
Вместо неэффективной очистки локального кэша на ПК выполните гарантированное удаление настроек формы из базы данных. Для этого пройдем по следующему пути в интерфейсе:
ОборотноСальдоваяВедомость) и удалите сохраненные настройки.Это действие полностью сотрет записи из таблицы хранилища настроек БД, и при следующем открытии отчет сформируется по умолчанию.
Если сброс не помог, необходимо проверить структуру СКД изнутри под учетной записью проблемного пользователя:
В редких случаях проблема действительно может быть связана с рассинхронизацией таблиц итогов СУБД. Если предыдущие шаги не дали результата, запустите конфигуратор и выполните процедуру Тестирование и исправление:
Выполнение этих шагов гарантированно устранит проблему расхождения данных в отчетах СКД и вернет стабильность работы пользователей в программе 1С.