← На главную

При работе с современными конфигурациями на базе ERP 2.5 и УТ 11.5 многие администраторы и разработчики сталкиваются с лавинообразным ростом объема базы данных. Часто при анализе таблиц выясняется, что более половины дискового пространства занимает один единственный регистр сведений — Детализация себестоимости партий товаров, постатейные и прочие затраты (периодический). Рассмотрим подробнее, почему это происходит, является ли это нормой и как мы можем оптимизировать хранение данных без потери важной информации.

Выясняем причину: почему регистр так быстро растет?

Для начала проанализируем механику работы этого регистра. Он предназначен для хранения развернутых данных о том, из каких составляющих сложилась стоимость каждой единицы товара: цена закупки, логистические затраты, дополнительные расходы и налоги. В отличие от большинства других регистров, этот объект является периодическим с разрезом в один месяц.

Разберем по шагам процесс его заполнения:

1. При каждом выполнении регламентной операции «Закрытие месяца» система производит полный пересчет стоимостных показателей.
2. Результаты записываются «срезами» на первое число каждого месяца.
3. Если в вашей базе ведется учет по 10 000 позиций номенклатуры, и по ним есть остатки или движения, система будет ежемесячно генерировать тысячи новых записей. Даже если себестоимость товара не изменилась, запись на новое число все равно будет создана.

Ситуация критически осложняется, если в настройках программы включена глубокая аналитика. Проанализируем факторы, ускоряющие рост:

• Партионный учет (ФИФО): Каждая новая партия создает отдельную ветку данных.
• Учет по ГТД и сериям: Каждая комбинация Номенклатура + Серия + ГТД + Склад — это отдельный набор записей в регистре.
• Распределение мелких расходов: Посмотрим на пример анализа валовой прибыли с доп. расходами и распределение транспортных расходов в 1000 рублей на документ поступления с 1000 позиций. Система создаст 1000 записей в детализации, чтобы учесть 1 рубль доп. расхода в каждой позиции.

Анализируем ошибки платформы и конфигурации

Важно понимать, что не всегда гигантский размер — это следствие объема ваших торгов. Проанализируем ситуацию с технической точки зрения. Компания 1С признала наличие архитектурных проблем и зарегистрировала ошибки 00-00615103 и 00-00600916.

Суть этих ошибок заключается в следующем:

• Избыточное дублирование: В некоторых релизах ветки 11.5 при перезакрытии месяца старые записи не удалялись корректно, либо создавались лишние корректирующие строки.
• «Сиротские» записи: При отмене проведения документов или прерывании закрытия месяца данные могли оставаться в таблицах, фактически не относясь ни к одному актуальному расчету.

Для исправления ситуации мы рекомендуем в первую очередь обновить конфигурацию до последних релизов (начиная с 11.5.12 и выше) и обязательно установить доступные исправления (патчи EF_...), которые оптимизируют алгоритмы записи в данный регистр.

Можно ли очистить старые записи и каковы последствия?

Рассмотрим вопрос, который больше всего волнует владельцев баз: можно ли просто удалить данные за прошлые годы? Чтобы ответить на него, нужно понимать роль этого регистра в системе.

Важный факт: Данный регистр не влияет на текущие остатки товаров, на взаиморасчеты с контрагентами или на итоговую сумму финансового результата в управленческом балансе. Он используется исключительно для формирования отчета «Анализ себестоимости товаров» (где можно ускорить формирование отчета Валовая прибыль) с детализацией по постатейным затратам.

Если мы решим произвести очистку данных, например, за 2021-2022 годы, последствия будут следующими:

• В отчетах за прошлые периоды вы увидите только общую сумму себестоимости, но не сможете расшифровать, какая часть суммы пришлась на закупку, а какая — на доставку или хранение.
• Текущие остатки и вывод себестоимости в заказах и реализациях не пострадают.
• Механизм закрытия месяца за текущие периоды продолжит работать корректно.

Пошаговый алгоритм оптимизации объема базы

Если размер базы стал критическим, выполним следующие действия для исправления ситуации:

1. Проверка настроек аналитики

Проанализируем необходимость ведения учета в разрезе ГТД и Серий для целей управленческой себестоимости. Если бизнес-процессы позволяют, отключение детализации по этим разрезам в настройках учета существенно замедлит рост регистра Детализация себестоимости партий товаров в будущем.

2. Переход на «Скользящую себестоимость»

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

3. Техническая очистка и сжатие

Простое удаление записей из регистра через обработку не уменьшит физический размер файла базы данных (особенно в формате SQL или файловом 1CD). Выполним регламентные операции:

1. Создадим полную резервную копию базы.
2. При помощи специализированных обработок или через Тестирование и исправление удалим записи регистра за неактуальные периоды (например, старше 3-х лет).
3. Для SQL-версии: выполним операцию Shrink (сжатие) базы данных и логов.
4. Для файловой версии: выполним выгрузку в .dt и последующую загрузку в чистую базу, либо воспользуемся утилитой chdbfl.exe.

4. Использование патчей

Убедимся, что в системе установлены патчи, исправляющие запись нулевых значений. Рассмотрим пример логики, которую внедряет 1С в последних исправлениях: система перестает записывать строки детализации, если отклонение стоимости составляет менее определенного порога (например, 0.01 коп.), что экономит миллионы строк в масштабах года.

Резюме

Ситуация, когда регистр детализации занимает 50-60% объема — это характерная особенность архитектуры 1С:УТ 11.5. Полностью «отключить» его без отказа от расчета себестоимости невозможно. Однако, соблюдая регламент обновления, устанавливая патчи и периодически архивируя данные старше 3-х лет, мы можем держать размер базы под контролем и обеспечивать высокую скорость работы системы.