Типовая 1С:ERP покрывает 80% задач. Оставшиеся 20% — это то, ради чего компании обращаются к разработчику. Дополнительная аналитика, нестандартные печатные формы, интеграция с маркетплейсами, собственная логика расчёта скидок, специализированные контроли при проведении документов. Вопрос не в том, нужны ли доработки, — а в том, как их реализовать, чтобы через год не оказаться на «снятой с поддержки» конфигурации, которую невозможно обновить без привлечения команды разработчиков на несколько недель.
Два основных пути: расширения конфигурации и прямые изменения в конфигураторе. У каждого — свои условия применимости, свои риски и свои подводные камни, которые проявляются не сразу. Выбор между ними — не вопрос вкуса. Это архитектурное решение, которое определяет стоимость владения системой на годы вперёд.
Когда расширение — правильный выбор
Расширение — это отдельный модуль, который подключается к конфигурации, не затрагивая её исходный код. Платформа 1С поддерживает этот механизм начиная с версии 8.3.9, и с каждым релизом возможности расширений растут.
Расширения хорошо работают в нескольких сценариях.
Интеграции с внешними сервисами. Подключение к маркетплейсам (Wildberries, Ozon), обмен данными с внешними системами, синхронизация с CRM. Мы часто используем расширения для интеграционных модулей — они добавляют новые справочники, регистры и обработки, не пересекаясь с типовой логикой. Если маркетплейс меняет API или клиент отказывается от канала продаж — расширение отключается, а конфигурация остаётся чистой. Пример: интеграция с Wildberries требует справочника соответствий номенклатуры, регистра очереди отправки, обработки обмена. Всё это живёт внутри расширения. Типовая конфигурация даже не знает, что Wildberries существует.
Дополнительные бизнес-механики. Промо-акции, розыгрыши, программы лояльности, специфические схемы ценообразования. Такие механики часто носят временный характер: запустили, протестировали, свернули или масштабировали. Расширение позволяет откатить изменения за минуту — отключить и убедиться, что основная система работает как прежде. Мы реализовывали через расширения механику розыгрышных кодов и бонусных начислений — отдельный модуль, который подключается к процессу продажи, но не модифицирует сам документ реализации. Когда акция закончилась — расширение отключили, никаких следов в конфигурации.
Дополнительные отчёты и печатные формы. Классический случай: стандартных отчётов не хватает, нужны собственные. Расширение добавляет отчёт, не затрагивая конфигурацию. При обновлении конфликтов не возникает.
Перехват событий без изменения модулей. Механизм «Перехват» в расширениях позволяет добавить код до, после или вместо процедуры типового модуля. Три аннотации — &Перед, &После, &Вместо — дают возможность вмешаться в типовую логику без редактирования исходного кода. Это мощный инструмент, но с оговорками — о них ниже.
Когда без изменения конфигурации не обойтись
Расширения не всесильны. Есть задачи, где прямая доработка конфигурации — единственный надёжный путь.
Глубокая модификация логики проведения документов. Если нужно изменить формирование движений по регистрам, добавить новые измерения в существующие регистры накопления или пересмотреть порядок расчётов при проведении — расширения создают хрупкую конструкцию. Перехватчики работают поверх типового кода, и любое обновление вендора может изменить внутреннюю логику процедуры, не меняя её сигнатуру. Расширение продолжит вызываться, но результат станет непредсказуемым. Например, вендор может изменить порядок формирования движений по регистру «Товары на складах» — и перехватчик, который корректировал эти движения, начнёт получать на вход другие данные. Ни ошибки, ни предупреждения — просто некорректные остатки.
Добавление реквизитов в существующие объекты со сложной бизнес-логикой. Технически расширение умеет добавлять реквизиты в справочники, документы, регистры сведений. Практически — если этот реквизит участвует в расчётах, проведении, контроле остатков — все точки, где он используется, потребуют перехватов. Каждый перехват — это зависимость от внутренней реализации типовой процедуры. Количество перехватов растёт, связность с типовым кодом увеличивается, и преимущество «лёгкого отключения» исчезает. Отключение такого расширения ломает учёт.
Изменение структуры регистров. Добавить измерение или ресурс в регистр накопления через расширение нельзя. Это ограничение платформы, и оно принципиально: регистры — это ядро учёта, их структура определяет, какие данные система способна хранить и как рассчитывать итоги.
Масштабные переработки подсистем. Если задача требует переработки целой подсистемы — например, полной замены механизма ценообразования или переделки складской логистики — расширение становится второй конфигурацией. Сотни объектов, десятки перехватов, собственная логика, которая тесно переплетена с типовой. Поддерживать это сложнее, чем поддерживать изменённую конфигурацию. Граница проста: если расширение не может быть безболезненно отключено — оно перестало быть расширением. Оно стало неотделимой частью системы, но без тех гарантий, которые даёт прямое включение в конфигурацию.
Ловушка «молчаливой несовместимости»
Главная опасность любых доработок — не конфликты при обновлении. Конфликт — это честная проблема: система сообщает, что что-то не совпадает, разработчик разбирается и принимает решение. Опаснее ситуации, когда всё работает, ошибок нет, платформа не ругается — а данные неверные. Мы называем это «молчаливой несовместимостью».
Реальный случай из практики. Предыдущий разработчик создал собственный справочник присоединённых файлов. Не использовал типовой механизм БСП (Библиотеки стандартных подсистем), а написал свой — с отдельным регистром сведений для хранения двоичных данных. Файлы записывались в ресурс регистра с именем «ХранимыйФайл».
Через какое-то время потребовалось прочитать эти файлы программно. Использовали стандартное API БСП — функции для работы с присоединёнными файлами. Вызов проходил без ошибок. Файл «находился». Но при попытке получить двоичные данные — возвращалось пустое значение. Ни исключений, ни записей в журнале регистрации. Просто пусто.
Разбор показал: стандартный API БСП ищет данные файла через набор реквизитов справочника — ТипХраненияФайла, Том, ПутьКФайлу. По ним определяется, где физически лежит файл: в базе данных, на диске в томе хранения или в облаке. В самодельном справочнике этих реквизитов не было — разработчик их не создал, потому что не планировал использовать типовое API.
API не находило ни тома, ни пути, ни типа хранения — и молча возвращало пустой результат. При этом файлы физически существовали: они лежали в ресурсе регистра сведений «ХранимыйФайл», а типовое API читало из ресурса «Хранилище». Один разработчик писал в одно место, стандартный механизм читал из другого.
Решение: прямой запрос к регистру за нужным ресурсом, распаковка через .Получить(). Технически — три строки кода. Но прежде чем написать эти три строки, пришлось пройти по цепочке: проверить, что файл записан в базу, убедиться, что двоичные данные физически существуют, пошагово пройти через код БСП, чтобы понять, где именно он «теряет» файл. Диагностика заняла часы — именно потому, что система не сообщала об ошибке. Ни исключения, ни записи в журнале — просто пустое значение, которое выглядит как «файл не загружен».
Урок: когда доработка расходится со стандартом, стандартные инструменты перестают работать. И перестают молча. Это касается и расширений, и прямых изменений конфигурации. Чем дальше кастомизация уходит от типовой архитектуры — тем больше «немых» точек отказа.
Архитектура доработок: расширения как слои
Правильный подход — рассматривать расширения не как «заплатки», а как архитектурные слои. Каждый слой решает одну задачу и минимально связан с остальными.
Слой интеграций. Отдельное расширение на каждую внешнюю систему. Расширение для Wildberries не знает о расширении для Ozon. Каждое можно обновить, отключить или заменить независимо. Внутри — свои справочники, регистры, обработки. Точки пересечения с типовой конфигурацией — минимальны и задокументированы.
Слой бизнес-логики. Расширения для механик, специфичных для конкретного бизнеса. Программа лояльности, генерация промо-кодов, специальные правила резервирования. Эти расширения могут зависеть от типовых объектов, но не друг от друга.
Слой отчётности. Дополнительные отчёты и обработки. Самый безопасный слой — практически не влияет на работу системы, легко добавляется и удаляется. Расширение с отчётом можно обновить прямо в рабочей базе, без монопольного режима и без перезапуска сеансов. Для пользователей это выглядит как «отчёт просто появился».
Такая архитектура даёт конкретные преимущества при развёртывании. Расширения деплоятся независимо от основной конфигурации. Обновление интеграционного модуля не требует блокировки базы для загрузки конфигурации. В CI/CD-пайплайне расширения — это отдельные артефакты со своим версионированием. Можно настроить автоматическую сборку и тестирование каждого расширения при изменении кода, а доставку в рабочую базу — отдельным шагом с подтверждением.
На практике это означает, что исправление бага в интеграции с маркетплейсом может попасть в продуктив за минуты, а не ждать планового обновления всей конфигурации. Для бизнеса разница существенна: простой интеграции — это потерянные заказы.
Но есть обратная сторона. Расширение зависит от программного интерфейса базовой конфигурации. Если вендор переименует процедуру, изменит состав параметров или уберёт экспортную функцию — расширение сломается. Причём сломается не при загрузке, а при вызове, в рантайме — в момент, когда пользователь попытается выполнить операцию. Поэтому критически важно тестировать совместимость расширений после каждого обновления конфигурации — до того, как обновление попадёт в рабочую базу. Идеальный вариант — автоматизированные тесты, которые прогоняют ключевые сценарии каждого расширения на обновлённой копии.
Как не потерять обновляемость
Обновляемость — это не абстрактное благо. Это конкретная экономия: возможность получать исправления ошибок вендора, новые формы отчётности, изменения законодательства — без ручной переработки. Потеря обновляемости обходится дорого: каждое обновление превращается в проект, а не в рутинную операцию.
Практический чек-лист для сохранения обновляемости:
Документируйте каждое изменение. Не «где-то в расширении что-то дописали», а конкретно: какой объект затронут, какая процедура перехвачена, зачем, какие типовые механизмы зависят от этого изменения. Без документации через два года никто — включая автора — не вспомнит, почему справочник «Файлы» отличается от типового.
Минимизируйте перехваты. Каждый перехват — это точка потенциального конфликта при обновлении. Если задачу можно решить через подписку на событие или через добавление нового объекта — это безопаснее, чем перехват процедуры типового модуля.
Используйте типовые API. БСП предоставляет программные интерфейсы для работы с файлами, правами доступа, рассылками, интеграцией. Эти API стабильны между версиями — вендор поддерживает обратную совместимость. Собственные механизмы, дублирующие типовые, — это путь к «молчаливой несовместимости».
Разделяйте «своё» и «типовое». Собственные объекты — с префиксом (например, ИП_ или КСТ_). Собственные процедуры — в отдельных модулях, а не вставками в типовые. Комментарии с маркером изменения — на каждом блоке, который добавлен или изменён. Чем проще отличить доработку от типового кода, тем проще обновление. При объединении конфигураций инструмент сравнения покажет все различия — и если собственный код визуально выделен, разработчик за секунды поймёт, что перенести, а что оставить.
Тестируйте обновления на копии. Перед обновлением рабочей базы — загрузите новую конфигурацию в копию, подключите все расширения, проверьте ключевые сценарии. Минимальный набор: проведение основных документов (поступление, реализация, перемещение), формирование ключевых отчётов, выполнение регламентных заданий. Автоматические тесты сокращают эту процедуру с дней до часов и убирают человеческий фактор — забыть проверить один сценарий из двадцати легко.
Ведите реестр расширений. Для каждого расширения фиксируйте: версию, дату последнего обновления, перечень перехватов, зависимости от типовых объектов, ответственного. Когда расширений больше пяти — без реестра управлять ими невозможно.
Планируйте выход из расширения. Некоторые доработки со временем перерастают расширение. Если расширение разрослось до сотен объектов и десятков перехватов — честнее перенести его в конфигурацию. Это осознанное решение, а не аварийная мера. Признаки того, что расширение пора «впитать» в конфигурацию: оно не может быть отключено без потери данных, его перехваты затрагивают более десяти типовых процедур, его объекты используются в других расширениях.
Выбор подхода — это архитектурное решение
Расширения и прямая доработка — не конкуренты. Это инструменты для разных задач. В одном проекте они часто сосуществуют: интеграции живут в расширениях, глубокие изменения учёта — в конфигурации, отчёты — снова в расширениях.
Ключевой критерий — не «что проще сейчас», а «что дешевле поддерживать через три года». Расширение, которое легко подключить, но невозможно обновить без ручной проверки каждого перехвата, — не лучше изменённой конфигурации. А конфигурация, изменённая с соблюдением правил и документации, обновляется полуавтоматически.
Мы рекомендуем начинать с вопроса: насколько глубоко доработка затрагивает типовую логику? Если ответ — «добавляет новое, не меняя существующее» — расширение. Если «перерабатывает существующее» — конфигурация. Если «непонятно» — стоит обсудить архитектуру до начала разработки, а не после.
Стоимость ошибки здесь — не испорченный код, который можно переписать за день. Это годы накопленных доработок, которые при неправильном подходе превращают каждое обновление в рискованную операцию. Правильная архитектура доработок — это инвестиция, которая окупается с каждым следующим обновлением конфигурации.
