При необходимости добавить новый функционал в типовое решение 1С, например, создать документ «Заказ» на основе существующего «Счета на оплату», перед разработчиком встает фундаментальный выбор: вносить изменения непосредственно в основную конфигурацию или использовать механизм расширений. Рассмотрим этот вопрос подробно, проанализируем технические риски и выработаем оптимальную стратегию разработки на примере современных конфигураций (включая линейку BAS).
Механизм расширений был создан для того, чтобы минимизировать сложности при обновлении типовых решений. В идеальном мире основная конфигурация остается на «замке» (на полной поддержке), а все доработки живут отдельно. Однако на практике создание новых объектов данных (документов, справочников) в расширении имеет свои нюансы, которые могут привести к фатальным последствиям для бизнеса. Разберем по шагам, на что стоит обратить внимание.
Проанализируем главный аргумент против создания документов исключительно в расширении — сохранность данных. В системе 1С:Предприятие архитектура хранения данных в расширениях специфична:
Выясним, почему при попытке скопировать существующий документ «Счет на оплату» в расширение возникают ошибки. Рассмотрим основные причины:
ОбластьДанныхОсновныеДанные или Организация. Расширения имеют жесткие ограничения на работу с общими реквизитами, которые являются разделителями данных. Если вы заимствуете объект, который «привязан» к разделителю, расширение может войти в конфликт с правилами разделения данных платформы.Характеристиками и сложными типами в расширениях часто работает нестабильно, особенно если в основной конфигурации используется режим совместимости ниже 8.3.12.Этот метод считается классическим и наиболее надежным для создания новых объектов учета. Проанализируем последовательность действий:
ЗаказПокупателя в основной конфигурации.Преимущества: Данные защищены стандартными механизмами платформы. Объект виден всем программистам, нет путаницы с тем, «где искать данные». Легко настраиваются права доступа и нумерация.
Недостатки: Немного усложняется процесс обновления, так как дерево конфигурации теперь содержит кастомные объекты.
Разберем наиболее современный и «чистый» способ, который сочетает стабильность основной конфигурации и гибкость расширений. Мы разделим структуру данных и бизнес-логику.
Шаг 1: Создание каркаса в основной конфигурации.
В основной конфигурации создаем только сам объект (документ) и его реквизиты. Не создаем формы, не пишем код в модулях. Таким образом, структура данных жестко зафиксирована в БД. Это минимальное вмешательство в типовую конфигурацию, которое практически не влияет на сложность обновлений.
Шаг 2: Реализация логики в расширении.
Заимствуем созданный документ в расширение. Здесь мы уже создаем формы, команды, пишем обработчики событий. Рассмотрим пример кода в модуле расширения для обработки проведения нашего нового документа:
&После("ОбработкаПроведения")
Процедура Расш1_ОбработкаПроведения(Отказ, РежимПроведения)
// Здесь пишем логику проведения, специфичную для Заказа
РегистрыНакопления.Продажи.СоздатьНаборЗаписей();
// Дополнительные расчеты
КонецПроцедуры
Шаг 3: Связь с типовыми объектами.
Если нам нужно, чтобы «Заказ» создавался на основании типового «Счета», мы заимствуем процедуру ОбработкаЗаполнения в расширение и добавляем логику копирования данных из счета в заказ.
Посмотрим, как правильно организовать работу с формами. Вместо того чтобы править типовые формы «Счета», создадим в расширении команду, которая будет открывать наш новый документ. Это позволит избежать конфликтов при обновлении интерфейса поставщиком.
Проанализируем типичную ошибку при копировании: попытка перенести ОбщиеРеквизиты. Если платформа выдает ошибку, связанную с активностью общих реквизитов, следует отказаться от их заимствования в расширение и использовать программное заполнение этих полей при записи документа через подписки на события или методы модуля объекта.
Проанализировав все способы, можно сделать следующие выводы для качественной разработки:
&Перед, &После и &Вместо (с осторожностью) для изменения поведения типовых механизмов создания на основании.Таким образом, создание нового документа «Заказ» лучше всего реализовать через добавление пустого объекта в основную конфигурацию с последующим «наполнением» его функционалом через расширение. Это обеспечит баланс между безопасностью данных и удобством поддержки системы.