Как писать доработки 1С: практическое руководство

Доработка 1С — это любое изменение типовой конфигурации под задачи конкретной компании: новые документы, печатные формы, отчёты, обработчики проведения, интеграции с внешними системами. Качество доработки определяется не только тем, что она работает сейчас, но и тем, как конфигурация будет обновляться через год и что произойдёт, когда разработчик уйдёт из проекта.

Главная проблема самописных доработок — конфликты при обновлении типового решения. Чем глубже изменён типовой код, тем дороже каждое обновление. Поэтому современный подход строится на приоритете расширений, минимальных правках типовых объектов и обязательной документации каждого изменения.

Ниже разобран практический цикл: от анализа задачи и выбора способа реализации до тестирования и переноса в рабочую базу. Материал ориентирован на разработчиков и внедренцев, работающих с конфигурациями на управляемых формах (Управление торговлей, ERP, Бухгалтерия, ЗУП и подобные).

Формализация задачи перед началом разработки

Большинство неудачных доработок рождается не из-за плохого кода, а из-за размытого технического задания. Прежде чем открывать конфигуратор, зафиксируйте: какую бизнес-задачу решает доработка, кто ею пользуется, какие данные входят на вход и что должно получиться на выходе. Формулировка «сделайте удобно» не является требованием.

Проверьте, не решается ли задача типовыми средствами. Значительная часть запросов закрывается настройкой прав доступа, дополнительными реквизитами и сведениями, вариантами отчётов или подключаемыми внешними печатными формами без единой строки изменения конфигурации. Доработка, которую можно не делать, — самая дешёвая доработка.

1. 1
   Сформулируйте бизнес-цель и критерий приёмки: как поймёте, что доработка работает
2. 2
   Проверьте типовые механизмы: дополнительные реквизиты, внешние печатные формы, настройки отчётов
3. 3
   Определите затрагиваемые объекты: документы, регистры, роли, обмены данными
4. 4
   Сделайте копию рабочей базы для разработки и тестирования
5. 5
   Зафиксируйте текущую версию конфигурации и релиз платформы

Выбор способа реализации: расширение или изменение конфигурации

Первый вопрос любой доработки — куда её поместить. Расширение конфигурации — это надстройка, которая не меняет типовые объекты, а дополняет их: можно добавлять собственные объекты, заимствовать формы и модули, перехватывать обработчики событий через аннотации «Вместо», «После», «Перед». При обновлении типовой конфигурации расширение в большинстве случаев продолжает работать без доработки.

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

Способы реализации доработки

Внешняя обработка или печатная форма

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

Расширение конфигурации

Основной способ для новых объектов, подписок на события, изменения форм и модулей. Сохраняет простоту обновлений. Ограничения: не все типовые объекты и свойства доступны для изменения.

Изменение типовой конфигурации

Крайняя мера для глубоких изменений структуры данных и проведения. Удорожает каждое обновление, требует тщательного документирования.

Разработка в расширении: типовые сценарии

Создание расширения начинается в конфигураторе: «Конфигурация — Расширения конфигурации — Создать». Задайте осмысленное имя и префикс — он будет добавляться к именам собственных объектов расширения и поможет отличать их от типовых. Префикс выбирайте короткий и уникальный для организации, например по аббревиатуре компании.

Добавление реквизита и вывод его на форму

Через контекстное меню типового документа в расширении добавьте собственный реквизит. Затем заимствуйте форму документа и разместите реквизит на ней. Проверьте, что значение сохраняется, отображается в списке (при необходимости добавьте его в динамический список через расширение запроса) и не ломает заполнение по данным основания.

Перехват событий типового модуля

Для изменения логики проведения или записи заимствуйте нужную процедуру модуля объекта или менеджера и оберните её аннотацией. Предпочтительный порядок: «После» — если нужно дополнить типовую логику, «Перед» — если нужно подготовить данные, «Вместо» — только когда типовой код должен быть полностью заменён, с пониманием, что при обновлении вы потеряете изменения типовой процедуры.

&После("ОбработкаПроведения")
Процедура Префикс_ОбработкаПроведения(Отказ, РежимПроведения)
// собственная логика после типового проведения
КонецПроцедуры

Изменение типовой конфигурации без лишнего ущерба

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

Каждое изменение помечайте комментарием с единым маркером, например:

// ДОРАБОТКА-0117: добавлено заполнение склада по подразделению
Склад = ДоработкиСервер.СкладПодразделения(Подразделение);
// КОНЕЦ ДОРАБОТКА-0117

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

Тестирование доработки

Тестирование выполняется на копии рабочей базы с реальными данными — именно там всплывают проблемы с большими объёмами, незаполненными реквизитами и нестандартными документами прошлых периодов. Проверяйте не только «счастливый путь», но и отказные сценарии: проведение с пустыми полями, отмену проведения, повторное перепроведение, работу под пользователем с ограниченными правами.

Отдельно проверьте влияние на смежные механизмы: обмены данными (регистрация изменений новых объектов), отчёты, использующие изменённые регистры, регламентные задания, права доступа к новым объектам. Новый объект без назначенных ролей будет недоступен пользователям даже при корректном коде.

Контрольные точки

Как проверить результат

Проведение затронутых документов

Норма

Документы проводятся, движения корректны, отмена проведения очищает записи

Тревожный признак

Ошибки при проведении старых документов, дубли движений при перепроведении

Права доступа

Норма

Новые объекты доступны нужным ролям, лишние права не выданы

Тревожный признак

Пользователи не видят объект или получили доступ к закрытым данным

Обновление типовой конфигурации на тестовой копии

Норма

Расширение загружается, точки изменения типовых объектов переносятся без ручного разбора

Тревожный признак

Расширение отключается, конфликты объединения требуют ручного слияния модулей

Обмены и интеграции

Норма

Изменения регистрируются и выгружаются, состав плана обмена не нарушен

Тревожный признак

Новые данные не попадают в обмен или выгрузка падает с ошибкой

Перенос в рабочую базу и сопровождение

Перенос выполняется в нерабочее время после создания резервной копии. Расширение загружается через «Все функции — Стандартные — Управление расширениями конфигурации» или из конфигуратора; изменения типовой конфигурации — через «Загрузить конфигурацию из файла» с последующим обновлением конфигурации базы данных. После переноса прогоните ключевой сценарий вручную и убедитесь, что пользователи могут войти и работать.

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

Частые вопросы

Когда внешняя обработка предпочтительнее расширения?

Когда нужна разовая или периодическая операция без реакции на события системы: групповая обработка данных, загрузка из файла, специализированный отчёт. Внешняя обработка не требует изменения конфигурации и легко обновляется простой заменой файла.

Можно ли изменить типовую печатную форму без доработки конфигурации?

Да, через механизм дополнительных отчётов и обработок (подсистема БСП «Дополнительные отчеты и обработки»). Внешняя печатная форма регистрируется в справочнике и подменяет или дополняет типовую без каких-либо изменений конфигурации.

Что делать, если расширение перестало работать после обновления?

Сначала откройте расширение в конфигураторе обновлённой копии и выполните проверку применимости: платформа укажет заимствованные объекты, которые изменились или удалены. Обычно достаточно обновить заимствованную форму или процедуру под новую типовую версию. Не удаляйте расширение из рабочей базы — собственные данные расширения при этом могут быть потеряны.

Как организовать работу нескольких разработчиков над одной конфигурацией?

Используйте хранилище конфигурации для типовой части и систему контроля версий (например, через выгрузку в файлы конфигуратора или EDT) для расширений и внешних обработок. Договоритесь о префиксах и зонах ответственности, чтобы изменения не пересекались.

Нужно ли согласовывать доработки с франчайзи или вендором?

Формально — нет, но если конфигурация обновляется сторонним специалистом, предупредите его о наличии доработок и передайте реестр изменений. Это сократит время обновления и снизит риск потери ваших правок.

Как оценить трудоёмкость доработки до начала работ?

Разбейте задачу на этапы: анализ типовых механизмов, реализация, тестирование на копии, перенос и сопровождение обновлений. Отдельно заложите время на непредвиденные конфликты с типовым кодом — для доработок, затрагивающих проведение документов, это обычно заметная доля сроков.