Предложенный в статье метод расчета итогов через вычисляемые поля СКД с использованием функции ВычислитьВыражение - это архитектурная бомба замедленного действия, которую категорически нельзя подпускать к реальным промышленным базам данных (как и Автора).
Обратите внимание, коллеги, вот жесткая и бескомпромиссная критика этого «решения» на основе опыта практикующих разработчиков из комментариев:
1. Метод нагло врет пользователю на больших списках
Заявленный параметр "ОбщийИтог" - это опасная иллюзия. На реальных больших массивах данных система выводит случайный мусор. Вместо корректной итоговой суммы или количества (например, реального значения в 99 или 1,5 миллиона строк) вычисляемое поле отображает хаотичные мелкие цифры вроде 25, 45, 27 или 1.
Причина фатальна: динамический список по своей природе считывает данные порциями. И этот механизм считает итог исключительно по текущей загруженной/считанной в память порции данных, а не по всей таблице. Показывать пользователю динамически меняющиеся ложные итоги при скроллинге списка - это вершина непрофессионализма.
2. Угроза стабильности: дикие тормоза и падения платформы
Динамический список в интерфейсе должен работать мгновенно. Однако использование вычисляемых полей СКД превращает форму в источник зависаний. Стоит пользователю сделать шаг в сторону - наложить группировки, применить сложные настройки или просто запустить систему на определенном релизе платформы 1С - как этот костыль начинает своевольничать, нещадно тормозить или вовсе ронять платформу в аварийное завершение. Потеря стабильности всей системы ради «красивого» подвала - абсолютно неоправданный риск.
3. Полная неприменимость для справочников и иерархии
Попытка посчитать количество элементов справочника или использовать этот подход в списках с иерархической структурой мгновенно ломает логику отображения
. Механизм начинает жестко «глючить» и выдавать некорректные результаты, особенно если пользователь отключает отображение иерархии. Автор сам признает, что при попытке запустить этот метод на справочниках возникают непреодолимые «непонятки» (авторский слог!).
4. Профессиональный инфантилизм («У меня работает»)
Реакция автора на конструктивные вопросы и критику коллег - это классический антипаттерн безответственной разработки:
На прямой вопрос о влиянии этого решения на производительность автор беспечно отвечает: «ХЗ :) так у меня небольшие данные, особо не влияет на скорость». Никакого нагрузочного тестирования, никакой оценки рисков перед публикацией решения в общий доступ.
На детальный разбор ошибок подсчета количества элементов автор просто отмахивается: «Так мне надо считать суммы чисел, а это оно справляется». Тот факт, что решение позиционируется как универсальный метод для разработчиков, автора не волнует.
Итог: Предложенный метод - это опасный и грязный хак, применимый исключительно в демонстрационных базах, на ультрамалых объемах данных и только для простейших плоских таблиц. Внедрять его в реальные конфигурации (особенно уровня ERP) - значит осознанно закладывать в систему дефекты производительности и гарантировать пользователям получение недостоверных данных.
