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