← На главную

Механизм расширений в платформе 1С:Предприятие 8.3 прошел долгий путь эволюции. Если на ранних этапах расширения предназначались исключительно для корректировки интерфейса или перехвата процедур и функций, то со временем они превратились в мощный инструмент, позволяющий полноценно дорабатывать логику систем без изменения основной конфигурации. Одним из самых долгожданных этапов развития стала возможность изменять структуру базы данных: добавлять собственные справочники, документы и регистры.

В этой статье мы подробно разберем, в каких именно версиях платформы появлялись те или иные возможности, и проанализируем технические нюансы, которые необходимо учитывать при работе с расширениями данных.

Версия 8.3.11: Начало эпохи расширения данных

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

В этой версии была реализована первая очередь механизма расширения данных. Рассмотрим подробнее, что стало доступно:

• Создание новых справочников: Программисты получили возможность добавлять собственные Справочники, которые физически создают новые таблицы в базе данных СУБД.
• Создание новых документов: Аналогично справочникам, стало возможным проектировать новые типы документов внутри расширения.
• Добавление реквизитов к существующим объектам: Если вам нужно было добавить поле в типовой справочник «Номенклатура», начиная с этой версии, вы могли сделать это через расширение, не снимая основную конфигурацию с поддержки.

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

Версия 8.3.12: Появление регистров сведений

Следующим важным шагом стал выпуск версии 8.3.12. В ней разработчики платформы расширили список доступных объектов метаданных, добавив РегистрыСведений. Это позволило:

1. Хранить произвольную информацию в разрезе измерений.
2. Создавать настройки для новых подсистем, разработанных в расширении.
3. Кешировать данные, не перегружая основные объекты конфигурации.

Несмотря на этот прогресс, задачи оперативного и бухгалтерского учета все еще оставались «за бортом» расширений, так как регистры накопления и бухгалтерии по-прежнему были недоступны.

Версия 8.3.13: Прорыв в автоматизации учета

Версия 8.3.13 стала настоящим подарком для разработчиков сложных учетных систем. Именно в этом релизе была реализована поддержка ключевых объектов для автоматизации бизнеса:

• Регистры накопления: Появилась возможность создавать собственные обороты и остатки, что позволило строить полноценные контуры складского, финансового и торгового учета внутри расширения.
• Регистры бухгалтерии: Стало возможным добавлять свои планы счетов и регистры для ведения проводок.
• Бизнес-процессы и Задачи: Теперь логику согласования или последовательность действий пользователей также можно было упаковать в расширение.

Проанализируем ситуацию: начиная с 8.3.13, расширение стало полноценной «микро-конфигурацией», способной решать практически любые прикладные задачи. Однако оставались специфические области, такие как расчет заработной платы и интеграция с внешними ИТ-системами.

Версия 8.3.14 и 8.3.15: Завершение формирования стека метаданных

Для тех, кто занимается автоматизацией сложных расчетов (например, начисления зарплаты или аренды), критически важным стал выход версии 8.3.14. В ней была добавлена поддержка:

• РегистрыРасчета
• ПланыВидовРасчета

А в версии 8.3.15 решилась проблема, на которую часто жаловались специалисты по интеграции (как упомянуто в сообщении 14 на форуме). Платформа позволила добавлять в расширения ВнешниеИсточникиДанных. Теперь подключение к внешним SQL-базам или другим источникам можно было реализовать максимально чисто, не затрагивая ядро системы.

Технические нюансы и требования к назначению расширения

Просто знать версию платформы недостаточно. Для того чтобы изменение структуры данных заработало, необходимо правильно настроить само расширение. Разберем ключевой параметр Назначение.

В палитре свойств расширения есть поле Назначение, которое может принимать следующие значения:

• Исправление: Предназначено для оперативного исправления ошибок. Имеет самые жесткие ограничения на изменение структуры.
• Адаптация: Подходит для изменения интерфейса и логики под конкретного клиента.
• Дополнение: Это именно тот тип, который обязательно нужно выбрать, если вы планируете добавлять свои справочники, документы или регистры. Только расширения с типом «Дополнение» позволяют полноценно расширять структуру данных.

Также стоит учитывать вопрос хранения данных в СУБД. Выясним причину, по которой к работе с данными в расширениях нужно относиться осторожно: все новые таблицы в базе данных создаются с использованием специальных префиксов. Если вы удалите расширение из базы, все данные, накопленные в его объектах, будут безвозвратно удалены вместе с таблицами расширения. Поэтому перед удалением или критическим обновлением расширения всегда необходимо делать резервную копию базы.

Рекомендации по выбору минимальной версии

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

1. Для простых задач (добавить пару реквизитов или справочник) подойдет 8.3.11. Но помните, что это была «проба пера», и в первых сборках встречались ошибки реструктуризации.
2. Для полноценного оперативного учета (с регистрами накопления) минимально необходимый порог — 8.3.13.
3. Для профессиональной разработки, включающей интеграции и сложные расчеты, эксперты рекомендуют использовать платформу не ниже 8.3.15 или даже актуальные сборки 8.3.20+, где механизмы работы с данными в расширениях стали значительно стабильнее и быстрее.

Рассмотрим пример того, как система определяет уникальность объектов. При добавлении своего реквизита к заимствованному справочнику Номенклатура, в расширении он будет выглядеть как ИмяРасширения_ИмяРеквизита. Это позволяет избегать конфликтов имен при установке нескольких расширений от разных вендоров в одну базу.

Таким образом, современная платформа 1С предоставляет практически неограниченные возможности по модификации структуры данных через расширения, главное — четко соотносить ваши требования к объектам метаданных с возможностями конкретной версии платформы, установленной у заказчика.