В процессе разработки и кастомизации типовых решений на платформе 1С:Предприятие 8.3, особенно таких сложных, как Бухгалтерия предприятия 3.0, разработчики часто сталкиваются с ситуацией, когда незначительное, на первый взгляд, изменение одного объекта метаданных приводит к многочасовому процессу обновления конфигурации базы данных. Типичный пример — расширение состава типов в Плане видов характеристик (ПВХ) ВидыСубконтоХозрасчетные. Рассмотрим подробнее, почему это происходит, как устроена реструктуризация "под капотом" и как избежать критических ошибок при проектировании системы.
Для начала проанализируем, что именно понимается под термином реструктуризация. Когда мы вносим изменения в метаданные в Конфигураторе, платформа должна привести физическую структуру таблиц в SQL-базе в соответствие с новой логической структурой. Рассмотрим ситуацию, описанную в теме: изменение типа субконто "Договоры" с одиночного (ссылка на один справочник) на составной (добавление еще одного справочника).
Разберем по шагам, почему это кардинально меняет хранение данных:
ALTER TABLE. Однако при переходе от простого типа к составному даже этот механизм часто вынужден выполнять полную перезапись данных, так как структура хранения "внутри" строки меняется фундаментально.Выясним причину, по которой изменение в одном ПВХ заставляет систему "перетряхивать" почти все документы. План видов характеристик ВидыСубконтоХозрасчетные является базовым объектом для всей учетной системы. На его основе строится План счетов, а на основе Плана счетов — Регистры бухгалтерии.
Проанализируем взаимосвязи в метаданных:
Связь по типу, они автоматически попадают в очередь на реструктуризацию.Таким образом, "поправив" один вид субконто, вы фактически приказали системе изменить способ хранения данных во всех таблицах, где эти субконто могут фигурировать, включая огромные архивы проводок за все годы ведения учета.
Рассмотрим подробнее, почему опытные разработчики предостерегают от расширения типов стандартных субконто, таких как "Договоры контрагентов":
1. Падение производительности в запросах.
Работа с составными типами в SQL-запросах всегда обходится "дороже". При выполнении соединений (JOIN) системе приходится анализировать дополнительные поля типов. Поскольку субконто участвуют практически в каждом бухгалтерском отчете, общее замедление системы станет заметным сразу после обновления.
2. Конфликты при обновлении типовой конфигурации.
При выходе очередного обновления от фирмы "1С", конфигуратор обнаружит расхождение в метаданных. Типовое обновление будет пытаться вернуть объекту ВидыСубконтоХозрасчетные его исходное состояние (простой тип). Если вы принудительно оставите свой вариант, вам придется вручную контролировать каждое обновление этого узла. Если же вы случайно согласитесь с типовым вариантом, платформа попытается "свернуть" тип обратно, что может привести к безвозвратной потере данных, записанных в ваш дополнительный справочник.
3. Нарушение логики типовых механизмов.
В коде "Бухгалтерии предприятия" множество функций завязаны на то, что в субконто "Договор" находится именно ссылка на СправочникСсылка.ДоговорыКонтрагентов. Например, алгоритмы закрытия месяца или подсистемы учета НДС. Появление там другого типа данных может вызвать ошибки выполнения кода:
// Пример потенциально опасного участка кода
Если ТипЗнч(Субконто1) = Тип("СправочникСсылка.ДоговорыКонтрагентов") Тогда
// Обработка логики договора
Иначе
// Ваша новая ссылка сюда не попадет или вызовет исключение в неожиданном месте
КонецЕсли;
Вместо того чтобы изменять структуру стандартных объектов, разберем более безопасные методы решения задачи "добавления своего договора":
Вместо изменения существующего элемента "Договоры", создайте в ПВХ ВидыСубконтоХозрасчетные новый элемент со своим типом. Затем добавьте это субконто на нужные счета в Плане счетов.
Плюсы: Вы не меняете логику работы стандартного поля, не ломаете типовые запросы и обеспечиваете чистое обновление конфигурации в будущем.
Если вам нужно просто хранить связь с другим объектом для аналитики, рассмотрите использование механизма Дополнительных сведений и реквизитов (БСП). Это позволяет расширять аналитику объектов без изменения структуры таблиц в конфигураторе. Проанализируем, как это можно реализовать программно:
// Пример получения значения доп. реквизита для анализа
ЗначениеСвойства = УправлениеСвойствами.ЗначениеСвойства(ОбъектСсылка, "ВашеДополнительноеСвойство");
Если ЗначениеЗаполнено(ЗначениеСвойства) Тогда
// Реализация вашей логики без изменения ПВХ
КонецЕсли;
Если необходимо "подсунуть" данные из другого справочника, можно создать промежуточный справочник или использовать механизм Расширений конфигурации. Однако стоит помнить, что даже в расширении изменение типа данных в ПВХ все равно приведет к реструктуризации базы данных, хотя и позволит сохранить основную конфигурацию на поддержке.
Реструктуризация всех объектов при сохранении изменений в Плане видов характеристик — это нормальное и ожидаемое поведение платформы. Это следствие глубокой архитектурной связанности метаданных. Любое изменение состава типов в ПВХ воспринимается системой как глобальное изменение правил игры. Чтобы минимизировать риски и время простоя системы, всегда оценивайте необходимость таких правок и старайтесь использовать механизмы, не затрагивающие базовые типы данных типовых решений.