Чёрный пояс 1С: БСП или своё поверх — где граница и 3 случая, когда переписать дешевле
Почему БСП изначально выгодна
Библиотека стандартных подсистем — это набор готовых механизмов, которые 1С выпускает и обновляет одновременно с платформой. Когда вы включаете подсистему БСП, вы получаете:
- Решённую задачу. Кому-то уже пришлось решать «как организовать обмен через универсальный план», «как сделать управление правами по группам», «как версионировать объекты» — и это решение интегрировано в типовую.
- Сопровождение от вендора. Новые требования нормативки, новые форматы выгрузки, изменения в платформе — приходят в очередном релизе БСП. Вы получаете их «бесплатно», без своей разработки.
- Единый язык в команде. Разработчик, перешедший с другого проекта на БСП, узнаёт знакомые имена объектов и обработчиков. Время онбординга сокращается с месяца до недели.
Это не маркетинг, это реальная экономия времени. На простой задаче «добавить контактную информацию к справочнику Контрагенты» БСП экономит вам неделю работы — против самописного решения. Через пять лет — экономит и сопровождение.
Где проходит граница
| Тип задачи | Решение |
|---|---|
| Стандартный сценарий, описанный в документации БСП | БСП штатно — всегда |
| Расширение стандартного сценария (новое поле, новый тип события) | БСП через точки расширения, если такая точка есть. Иначе — поверх БСП |
| Нестандартный сценарий, концептуально близкий к подсистеме | Своя реализация, использующая инфраструктуру БСП (объекты, регистры), но со своей логикой |
| Принципиально другой сценарий, не покрытый идеологией подсистемы | Полностью своя реализация, БСП в этой части не используется |
Большинство неудачных решений «БСП vs своё» — это когда задача из третьей или четвёртой строки таблицы принимается за вторую. Кажется, что точкой расширения «дотянем», а на деле приходится менять саму подсистему — и потом ловить конфликты при обновлении БСП.
Три случая, когда переписать поверх было дешевле в долгую
Случай 1: подсистема «Управление контактной информацией» под нестандартную модель
Бизнес-задача: контактная информация контрагентов должна иметь признак «основной для документооборота», «основной для рассылок», «архивный — не использовать», плюс автоматическую проверку на актуальность каждые 6 месяцев. Стандартная БСП-подсистема хранит контактные данные плоско, без признака назначения, и о проверке актуальности ничего не знает.
Первое решение команды — расширить БСП через расширение конфигурации, добавить три реквизита. Через год выяснилось: при каждом обновлении БСП эти реквизиты конфликтуют с новыми возможностями, которые 1С добавляет в стандартную модель. Каждое обновление — две недели регрессионного тестирования.
Переписали поверх: оставили БСП для базового хранения, поверх неё — свой регистр сведений с метаданными актуальности и сценариев использования. Обновления БСП теперь приходят штатно, своя логика живёт отдельно и не пересекается. Цена решения — две недели работы, экономия в долгую — десятки часов на каждое обновление БСП.
Случай 2: подсистема «Версионирование объектов» с собственным форматом diff
Стандартное версионирование БСП хранит копии объектов целиком при каждой записи. Для команды, у которой версионируются крупные документы с сотнями строк табличных частей, через полгода размер базы вырастает на 30%. БСП в типовом виде — не годится экономически.
Можно было попытаться «настроить БСП». В практике — её внутренняя модель не разделяет хранение и diff-логику, точек расширения для этого нет. Решение: своя реализация, использующая инфраструктуру БСП на уровне «регистрировать факт изменения», но хранящая только дельту в собственной структуре. Через шесть месяцев — размер базы стабилизировался, а пользователь по-прежнему видит «штатный» интерфейс истории объектов.
Случай 3: подсистема «Управление доступом» при матричной модели
БСП поддерживает модель «пользователь → группа доступа → права». Это работает в типичной компании с несколькими отделами. В холдинге с тремя десятками юрлиц, восемью функциональными ролями и тремя уровнями полномочий (наблюдатель, исполнитель, ответственный) матрица прав получается шестимерной. БСП в исходном виде её обслуживает, но конфигурирование занимает день на каждого нового сотрудника.
Поверх БСП написали слой автоматической генерации групп доступа из штатной модели «сотрудник → должность → юрлицо → полномочие». Кадровик заводит сотрудника один раз, нужные группы доступа создаются автоматически. БСП всё ещё в основе — но управление перенесено на свой уровень.
Старший товарищ говорит: «переписать поверх БСП» — не означает «выбросить БСП». Это означает добавить свой слой, который пользуется её инфраструктурой, но реализует логику, не предусмотренную авторами. БСП — фундамент. Точка расширения в БСП — встроенная розетка. Своя реализация поверх — отдельная проводка, идущая от того же щитка. Иногда розеток в комнате недостаточно — это не повод выкидывать электричество.
Сигналы, что пора переписать поверх
- На третий раз вы натыкаетесь на «БСП не позволяет» в одной и той же задаче — это сигнал, что задача не покрывается её идеологией, а не «надо ещё разок попробовать через расширение».
- Точки расширения БСП в этом месте отсутствуют, и каждая правка требует менять саму подсистему — это сигнал, что обновления БСП будут регулярно ломать вашу логику.
- Размер вашего расширения над БСП-подсистемой превышает 50% объёма самой подсистемы — концептуально вы уже написали своё, только в неудобной упаковке.
- На каждом релизе БСП регрессионное тестирование занимает больше двух дней — экономия от «штатной поддержки» съедается стоимостью этой проверки.
- Бизнес-заказчик регулярно спрашивает «почему так нельзя» — а ответ «БСП так не умеет» не помогает. Если ограничение становится частью переговоров с бизнесом — пора его снять.
Типичные ошибки
- «БСП решает всё, не трогаем». Догматический подход. Когда задача упирается в архитектурные ограничения подсистемы, надо честно признать и переписать поверх — а не пытаться третий месяц «дотянуть точками расширения».
- «БСП не подошла — выкидываем». Обратная крайность. Из одной нестыковки делается вывод «БСП не подходит», заводится 100% самописное решение. Через два года такая команда переизобретает версионирование, права доступа и обмен данными — и плохо.
- Не задокументировали границу. Команда написала свой слой поверх БСП, но не описала, где БСП заканчивается и где начинается своё. Новый разработчик путает, лезет в чужой слой через БСП-точку расширения, ломает интеграцию.
- Не отслеживают обновления БСП. Свой слой написан, БСП обновляется, но никто не сверяет, не появилась ли в новой версии БСП официальная поддержка того, что вы написали сами. Через два года 1С добавляет вашу функцию штатно — а у вас уже не годное самописное решение.
- «Своя реализация — значит, без регламента». БСП-подсистемы тестируются вендором. Свой слой над БСП тестируется только вами. Без своих тестов и регламента code review такой слой через год становится источником регрессий, на которые жалуется вся команда.
Перейти в каталог решений →