При разработке собственных конфигураций на платформе 1С:Предприятие 8 разработчики иногда сталкиваются с необходимостью расширения аналитического учета на счетах. Однако попытка установить большое количество субконто (например, 7 или более) может привести к критической ошибке СУБД при обновлении информационной базы. В этой статье мы подробно разберем, почему это происходит, как исправить ситуацию и какие архитектурные последствия влечет за собой избыточное количество аналитик.
Рассмотрим ситуацию, когда при попытке сохранить конфигурацию система выдает сообщение: «Длина ключа индекса превышает максимально допустимую '_AccRgAT253_ByPeriod'». Чтобы понять природу этой ошибки, нам необходимо заглянуть во внутреннее устройство хранения данных 1С. Для каждого регистра бухгалтерии платформа создает в базе данных несколько таблиц, одна из которых — таблица итогов (в нашем примере это _AccRgAT с числовым индексом). Для оптимизации получения остатков и оборотов система создает индекс _ByPeriod.
В состав этого индекса входят следующие поля:
_AccountRRef — ссылка на счет (фиксированный размер)._Period — период итогов (дата)._ValueX_TYPE (тип значения), _ValueX_N (числовое значение), _ValueX_S (строковое значение) и _ValueX_RRef (ссылка).Проанализируем ключевой момент: если в Плане видов характеристик (ПВХ), который является источником видов субконто, разрешены примитивные типы данных (особенно Строка или Число), платформа вынуждена резервировать в структуре индекса место под максимально возможную длину этих типов. В файловом варианте базы (формат .1CD) ограничение на размер ключа индекса составляет примерно 2000 байт. Когда субконто становится много, суммарный размер зарезервированных полей превышает этот лимит, и СУБД блокирует создание такого индекса.
Самый быстрый и эффективный способ решить проблему «здесь и сейчас» — это пересмотреть состав типов в вашем Плане видов характеристик. Выясним, какие типы там выбраны. Если в составе присутствуют Строка, Число или Дата, их необходимо убрать, оставив только ссылочные типы (справочники, документы и т.д.).
Рассмотрим алгоритм действий:
План видов характеристик, который назначен в качестве субконто в вашем Плане счетов.Строка, Число, Дата и Булево.СправочникСсылка.Контрагенты, СправочникСсылка.Номенклатура).Как показывает практика, после удаления типа Строка ошибка исчезает, так как ссылки в 1С имеют фиксированную длину (16 байт), и они занимают гораздо меньше места в индексе, чем зарезервированные поля под строки неограниченной длины.
Даже если ошибка СУБД пропала, использование 7 субконто является серьезным сигналом к пересмотру архитектуры. Проанализируем, к чему это приведет в процессе эксплуатации системы. Платформа 1С позволяет устанавливать до 50 субконто, но это технический предел, а не рекомендация.
Разберем последствия «тяжелого» регистра бухгалтерии:
Оборотно-сальдовую ведомость с разверткой по всем аналитикам будет генерировать крайне тяжелые SQL-запросы с десятками соединений (JOIN), что может привести к превышению времени ожидания.Выясним, как можно организовать учет, не раздувая количество субконто. Рассмотрим несколько проверенных подходов.
1. Использование составного субконто (Ключ аналитики)
Вместо того чтобы добавлять пять отдельных субконто (Склад, Цвет, Размер, Артикул, Серия), создадим один справочник, например, КлючиАналитикиНоменклатуры. В этом справочнике создадим реквизиты для всех необходимых разрезов. На счете же будем использовать только одно субконто с типом этого справочника. Это позволит сохранить детальность учета, сохранив индекс регистра бухгалтерии максимально компактным.
2. Дополнительные сведения и характеристики
Если некоторые аналитики являются свойствами объекта (например, «Цвет» у «Номенклатуры»), их не нужно выносить в отдельные субконто. Используйте механизм Дополнительных сведений. В отчетах (например, на базе СКД) вы всегда сможете вытащить эти свойства через точку от основного субконто.
3. Использование регистров накопления
Проанализируем задачу: действительно ли все эти данные нужны на плане счетов? Бухгалтерский учет предназначен для отчетности по правилам двойной записи. Если вам нужна глубокая оперативная детализация (например, учет товаров в разрезе ячеек, серийных номеров и статусов), лучше реализовать это на Регистрах накопления. В регистре бухгалтерии при этом достаточно оставить сводную информацию (например, только по складам и номенклатуре).
Важно помнить о нюансе с количеством записей в таблицах оборотов. При каждом движении система может генерировать значительное количество записей для поддержки итогов в разных разрезах. Как отмечают эксперты, на одно движение может приходиться до 14 и более записей в служебных таблицах. Чем больше субконто, тем сложнее системе поддерживать целостность этих срезов, что в конечном итоге превратит вашу базу в «черепаху» даже при небольшом объеме документов.
Таким образом, для решения проблемы выполним следующие шаги: удалим примитивные типы данных из ПВХ для обхода ограничения индекса, а затем проведем рефакторинг структуры данных, сократив количество прямых субконто на счетах до разумного минимума (обычно 2–3, максимум 4).