Разработка и Конфигурация · 13 мин
Как редактировать типовую конфигурацию 1С
Как правильно редактировать типовую конфигурацию 1С: включение возможности изменений, механизм поддержки, расширения, риски при обновлении и практические рекомендации.
Типовая конфигурация 1С (Бухгалтерия предприятия, Управление торговлей, Зарплата и управление персоналом и другие) поставляется вендором с закрытым от изменений кодом. Это сделано намеренно: пока конфигурация находится на полной поддержке, обновления устанавливаются автоматически, а ответственность за корректность логики несёт разработчик типового решения. Как только вы снимаете замок и начинаете править объекты напрямую, механизм обновления переходит в ручной режим сравнения и объединения.
Поэтому первое правило работы с типовой конфигурацией — выбирать минимально достаточный способ доработки. Если задачу можно решить расширением конфигурации, внешней обработкой или настройкой без изменения кода, не нужно снимать конфигурацию с поддержки. Прямое редактирование оправдано только тогда, когда нужный функционал невозможно добавить иначе.
Ниже разобраны все рабочие способы изменения типовой конфигурации: от включения возможности изменений в конфигураторе до правильной подготовки к обновлению после доработок. Материал ориентирован на платформу 1С:Предприятие 8.3 и актуален для большинства типовых решений.
Когда редактировать типовую конфигурацию, а когда нельзя
Прежде чем открывать конфигуратор, определите, действительно ли нужна правка типового кода. Большинство типичных запросов — добавить печатную форму, дополнительный отчёт, реквизит в документ, проверку при записи — решаются без изменения типовых объектов. Прямая доработка оправдана, когда нужно изменить существующую логику проведения, типовые движения по регистрам, встроенные формы так, как расширение не позволяет, или исправить поведение, которое нельзя переопределить.
Ограничения расширений реальны: нельзя изменить состав движений документа по регистрам, нельзя править роли и права в полном объёме, часть типовых форм сложно доработать из-за программного создания элементов. Если задача упирается в одно из этих ограничений — это аргумент в пользу прямого редактирования.
Как выбрать способ доработки
Подготовка: копия базы и учёт исходного состояния
Любая работа по редактированию конфигурации начинается с резервной копии. Для файловой базы достаточно скопировать файл 1Cv8.1CD при остановленной работе пользователей; для клиент-серверной — сделать выгрузку через конфигуратор (Администрирование → Выгрузить информационную базу) или штатный бэкап средствами СУБД. Выгрузка в .dt надёжнее, так как проверяет целостность данных при загрузке.
Второй шаг — зафиксировать текущее состояние конфигурации. Откройте Конфигурация → Поддержка → Настройка поддержки и посмотрите, на какой поддержке находится база: полная поддержка поставщика, конфигурация уже изменена или снята с поддержки. Это определяет, какие действия доступны и как будет проходить обновление. Полезно также сохранить конфигурацию поставщика в файл .cf — она понадобится для трёхстороннего сравнения при обновлении.
Третий шаг — организовать учёт изменений. Даже для небольшой доработки заведите документ (хотя бы текстовый файл), где фиксируется: какой объект изменён, что именно добавлено, зачем, кем и когда. При обновлении типовой конфигурации этот список сэкономит часы на анализе изменений.
Включение возможности изменений в конфигураторе
Если решение о прямой доработке принято, порядок действий в конфигураторе стандартный. Откройте конфигурацию через Конфигурация → Открыть конфигурацию, затем перейдите в Конфигурация → Поддержка → Настройка поддержки. В открывшемся окне нажмите кнопку «Включить возможность изменения». Платформа предупредит, что автоматическое обновление станет недоступным — это нужно принять осознанно.
Далее для каждого объекта, который планируется изменять, установите режим поддержки. В настройке поддержки можно выбрать правило: «Объект поставщика не редактируется», «Объект поставщика редактируется с сохранением поддержки» или «Объект поставщика снят с поддержки». Оптимальный вариант для большинства доработок — «редактируется с сохранением поддержки»: объект можно менять, но при обновлении платформа покажет конфликт и предложит сравнение.
Полное снятие объекта с поддержки — крайняя мера. Такой объект перестаёт участвовать в автоматическом сравнении при обновлении, и все изменения поставщика в нём придётся переносить вручную. Снимайте с поддержки только те объекты, которые действительно правите, а не всю конфигурацию целиком.
- 1Сделайте резервную копию базы и сохраните файл конфигурации поставщика (.cf)
- 2Откройте конфигуратор, Конфигурация → Открыть конфигурацию
- 3Перейдите в Конфигурация → Поддержка → Настройка поддержки
- 4Нажмите «Включить возможность изменения» и подтвердите действие
- 5Для нужных объектов установите режим «Редактируется с сохранением поддержки»
- 6Внесите доработки, обновите конфигурацию базы данных (F7)
- 7Проверьте работу изменённого функционала на тестовых данных
Правила внесения изменений в типовые объекты
Главный принцип безопасной доработки — минимизировать вмешательство в типовой код. Не переписывайте типовые процедуры целиком: добавляйте свои обработчики, вызывайте типовые процедуры из своего кода, выносите свою логику в отдельные общие модули с понятным префиксом (например, «Преф_»). Тогда при обновлении конфликтовать будут только точечные места вставок, а не весь модуль.
В формах объектов старайтесь добавлять элементы программно в обработчике ПриСозданииНаСервере, а не перетаскиванием в визуальном редакторе формы. Программно добавленные элементы проще перенести после обновления формы поставщика: достаточно заново принять типовую форму и оставить свой код в модуле.
Все вставки в типовой код помечайте комментариями с единым маркером, например:
// Преф.Доработка.Начало: добавлен контроль остатков по складу
...
// Преф.Доработка.Конец
Такой маркер позволяет мгновенно найти все свои правки глобальным поиском по конфигурации и корректно перенести их при обновлении. Это простая практика, которая многократно окупается при первом же выходе нового релиза.
Если доработок много, ведите разработку через хранилище конфигурации. Хранилище фиксирует историю изменений по объектам, позволяет откатиться к любой версии и существенно упрощает работу нескольких разработчиков с одной базой. Даже для одного разработчика история версий — страховка от неудачных правок.
Редактирование через расширение конфигурации
Расширение — механизм платформы, который позволяет доработать типовую конфигурацию, не изменяя её объектов. Конфигурация остаётся на полной поддержке и обновляется автоматически, а все доработки хранятся отдельным слоем. Создать расширение можно через Конфигурация → Расширения конфигурации → Создать.
Через расширение можно: добавлять собственные реквизиты, табличные части, формы, отчёты, обработки и роли; заимствовать типовые объекты и дополнять их; перехватывать обработчики событий форм и модулей с помощью аннотаций &Вместо, &Перед, &После; изменять макеты и командный интерфейс. Для перехвата типовой процедуры заимствуйте её в расширение и оберните вызов типовой логики своим кодом.
Ограничения важно знать заранее: нельзя изменить состав движений типового документа, нельзя удалить типовой реквизит, перехват методов работает не для всех контекстов, а при обновлении конфигурации заимствованные объекты нужно проверять на совместимость — платформа помечает проблемные объекты в списке расширения. Тем не менее для 70–80% типовых доработок расширение — правильный выбор.
Сравнение способов доработки
Подходит для добавления реквизитов, форм, отчётов и перехвата событий. Конфигурация остаётся на полной поддержке, обновления автоматические. Ограничение: нельзя менять движения документов и часть типовой логики.
Позволяет изменить любую типовую логику, включая проведение и движения. Обновление становится ручным через сравнение и объединение. Требует дисциплины в учёте изменений.
Подходят для разовых операций, дополнительных печатных форм и отчётов через механизм БСП. Конфигурация не меняется вообще. Не подходят для изменения поведения типовых объектов.
Даёт полную свободу, но отключает механизм автоматического обновления целиком. Оправдано только при глубокой переработке конфигурации под уникальные процессы.
Обновление конфигурации после доработок
Обновление доработанной конфигурации выполняется через Конфигурация → Поддержка → Обновить конфигурацию с выбором файла нового релиза. Платформа запустит сравнение и объединение: покажет, какие объекты изменил поставщик, какие изменили вы, и где возникли конфликты. Для объектов с режимом «редактируется с сохранением поддержки» по умолчанию предлагается объединение с приоритетом — выбирайте его внимательно.
Практический порядок такой: сначала обновите копию базы, пройдите по всем объектам с конфликтами и вручную перенесите свои доработки (здесь помогают маркеры-комментарии и ведомость изменений). Затем выполните обновление конфигурации базы данных, проверьте ключевые сценарии: проведение изменённых документов, формирование отчётов, работу доработанных форм. Только после успешной проверки повторите обновление на рабочей базе.
Если доработки велись через расширение, после обновления конфигурации откройте список расширений и проверьте колонку совместимости. Платформа сама помечает заимствованные объекты, которые изменились в новом релизе, — их нужно актуализировать, иначе расширение может отключиться или работать некорректно.
Как проверить результат после доработки или обновления
В настройке поддержки объекты в ожидаемом режиме, конфигурация обновляется штатно
Объекты сняты с поддержки без необходимости, обновление не находит порядок обновления
Проведение, отмена проведения и печать работают на тестовых данных без ошибок
Ошибки при проведении, незаполненные движения, падение формы
Все расширения применены, заимствованные объекты актуальны
Расширение отключено или помечено как несовместимое
Поиск по маркеру-комментарию находит все правки в новой версии
Часть доработок потеряна при объединении, логика работает по-старому
Типичные ошибки при редактировании типовой конфигурации
Самая распространённая ошибка — снятие с поддержки всей конфигурации или лишних объектов «на всякий случай». Каждый снятый объект — это ручная работа при каждом обновлении. Вторая типичная ошибка — правка типовых процедур без комментариев и учёта: через полгода никто не помнит, что и зачем менялось, и обновление превращается в археологию.
Третья группа ошибок — технические: доработка прямо в рабочей базе без копии, отсутствие резервной копии перед обновлением конфигурации базы данных, переписывание типовых форм в визуальном редакторе вместо программного добавления элементов. Все они приводят к потере времени или данных и легко предотвращаются дисциплиной.
Что важно запомнить
Редактирование типовой конфигурации начинается с выбора способа: расширение — для добавлений и перехватов, прямая правка — для изменения типовой логики. Перед любыми изменениями делайте копию, включайте возможность изменений только для нужных объектов, помечайте свои правки маркерами и проверяйте обновление на тестовой базе. Дисциплина в учёте доработок важнее объёма самих доработок.
Частые вопросы
Можно ли вернуть конфигурацию на полную поддержку после доработок?
Да, если все изменения убраны или перенесены в расширение. В настройке поддержки выберите режим полной поддержки и выполните сравнение с конфигурацией поставщика из файла .cf нужного релиза — все отличия должны быть устранены, иначе платформа не даст вернуть поддержку корректно.
Что произойдёт с моими доработками при автоматическом обновлении?
Если конфигурация редактируется с сохранением поддержки, автоматическое обновление через интернет может быть недоступно или потребует ручного объединения. Платформа покажет окно сравнения, где нужно пройтись по конфликтам. Доработки в расширениях при обновлении не удаляются, но требуют проверки совместимости.
Чем расширение отличается от внешней обработки?
Внешняя обработка — отдельный файл, который запускается в режиме предприятия и не меняет поведение типовых объектов. Расширение подключается к конфигурации и может изменять её формы, модули и данные, оставаясь при этом отдельным слоем. Для разовых операций достаточно обработки, для постоянных доработок — расширения.
Нужно ли хранилище конфигурации для одного разработчика?
Формально не обязательно, но на практике полезно: хранилище даёт историю версий каждого объекта и возможность отката. Альтернатива для одиночной разработки — регулярные выгрузки конфигурации в файлы .cf с датами в имени или выгрузка в файлы конфигурации для работы с внешними системами контроля версий.
Как перенести доработки в новую базу или филиал?
Для расширений — выгрузите расширение в файл и загрузите в целевую базу. Для прямых доработок — используйте сравнение и объединение конфигураций: загрузите изменённые объекты из конфигурации-источника. Перед переносом убедитесь, что релизы конфигураций в обеих базах совпадают, иначе возможны конфликты типовых объектов.
Можно ли редактировать конфигурацию в режиме предприятия?
Нет, структурные изменения вносятся только в конфигураторе. В режиме предприятия доступны лишь пользовательские настройки: дополнительные реквизиты и сведения, пользовательские отчёты, настройка форм. Часть простых задач — добавить поле для хранения информации, изменить печатную форму через макет — действительно решается без конфигуратора.