# Налог на хаос. Часть 3. Закладки в коде, подписки на подрядчика и другие способы держать вас на крючке Автор: Александр Орлов · 5 марта 2026 · Рубрика: Налог на хаос Источник: https://itnihilist.ru/blog/nalog-na-haos-3.html Впервые опубликовано: https://www.klerk.ru/user/2640567/682190/ --- # Налог на хаос. Часть 3: закладки в коде, подписки на подрядчика и другие способы держать вас на крючке В предыдущих частях серии «Налог на хаос» мы разобрали, почему без регламентов управляет подрядчик ([часть 1](/blog/nalog-na-haos-1.html)) и где в 1С утекают реальные деньги ([часть 2](/blog/nalog-na-haos-2.html)). Там речь шла о системных проблемах — размытые задачи, отсутствие приёмки, почасовка без границ. Сегодня — о другом. О ситуации, когда проблемы в коде создаются намеренно. ## Как мы нашли закладку Расскажу историю, которая происходит прямо сейчас — с одним из наших клиентов. Компания сменила подрядчика по 1С. Причины стандартные: счета росли, сроки плыли, качество падало. Нашли нового, начали передачу. Первые недели — нормально. Новый подрядчик разбирается в базе, берёт задачи в работу. А потом — через несколько недель после смены — «вдруг» перестаёт работать доработанный модуль. Просто перестаёт. Без обновлений, без изменений, без видимых причин. Новый подрядчик полез в код. И нашёл условие: конструкцию, которая проверяет дату. Если текущая дата больше определённого значения — функция отключается. Не ошибка. Не баг. Сознательно написанный код, который ломает работу системы в заданный момент. И вот что важно понять: это ломалось и раньше — ещё при старом подрядчике. Просто тогда компания звонила ему же, он «чинил», выставлял счёт, и все думали — ну, бывает, 1С же сложная система. Никто не объяснял причину, никто не показывал, что именно сломалось и почему. Починили — и хорошо. А по факту подрядчик брал деньги за устранение проблемы, которую сам же и заложил. Новый подрядчик — показал. Вот разница между работой в прозрачной среде и работой «на доверии». Что это означает на практике? Компания вынуждена либо вернуться к старому подрядчику (который «знает, как починить»), либо платить новому за поиск и исправление чужих закладок. В обоих случаях — повторная оплата за то, что уже было оплачено. Когда мы взяли этого клиента в работу, сразу перевели всё взаимодействие с подрядчиком в нашу систему управления — «Операционку». До этого у них не было никакого учёта заявок — задачи ставились в мессенджерах, результат не фиксировался, история терялась. Закладку нашёл новый подрядчик, когда полез в код разбираться с поломкой. Но на будущее компания уже защищена: система фиксирует каждую задачу и через ИИ ищет похожие — если та же проблема всплывает повторно, подсвечивает это. Подрядчик не сможет незаметно взять в работу задачу, которая уже была оплачена, а одна и та же ошибка в третий раз за квартал не пройдёт мимо. Тот самый «реестр доработок», о котором я писал во [второй части](/blog/nalog-na-haos-2.html) — только автоматический. ## Это не единичный случай После публикации предыдущих статей серии в комментариях на Клерке мне писали читатели с похожими историями. Код, который перестаёт работать после разрыва отношений с подрядчиком. Модули, которые «ломаются» именно тогда, когда компания пытается уйти. И это логично. Подрядчик, который работает в системе без правил, без ревизии кода, без передачи исходников — имеет техническую возможность заложить в код всё что угодно. А если нет человека, который этот код проверяет — закладка будет обнаружена только когда сработает. У себя в ТГ канале t.me/itnihilist я пишу про подобные ситуации и рассказываю как их избежать. ## Как подрядчики зарабатывают больше, чем если бы работали честно Закладка с датой — самый грубый вариант. Но далеко не единственный способ заработать на заказчике больше, чем стоит честная работа. В 1С код конфигурации открытый — казалось бы, всё на виду. Но кто его читает? Бухгалтер — нет. Руководитель — нет. А выделенного ИТ-специалиста в большинстве компаний МСБ просто не существует. Поэтому закладки и работают: условие по дате, скрытый флаг в регистре — вариантов масса. Код открытый, но если его никто не проверяет — проблема обнаруживается только когда срабатывает. То есть когда уже больно и дорого. А помимо закладок есть и другие способы. ### Дублирование типовых отчётов. Одна из самых распространённых и при этом неочевидных схем. Подрядчик разрабатывает «свой» отчёт по дебиторке, по оборотам, по остаткам — хотя типовой отчёт в конфигурации делает ровно то же самое. Иногда — буквально с теми же данными, только «в другом виде». Что получает компания: счёт за разработку, потом счёт за доработку, потом счёт за поддержку. А типовой отчёт тем временем обновляется бесплатно с каждым релизом от 1С, поддерживает новые требования законодательства и не требует отдельного сопровождения. Что получает подрядчик: постоянный поток задач на поддержку того, что не нужно было создавать. ### Порча типовой конфигурации. Вместо того чтобы использовать расширения или аккуратные точечные доработки, подрядчик правит типовые объекты конфигурации напрямую. Модули, формы, регистры — всё изменено. Пока подрядчик тот же — это незаметно. Но стоит выйти обновление от 1С (а они выходят регулярно — новые формы отчётности, изменения в законодательстве, исправления ошибок), и начинается кошмар. Десятки конфликтов при сравнении-объединении. Ручная работа на несколько дней. Риск потери данных. В итоге компания либо перестаёт обновляться — а это прямой путь к проблемам с отчётностью и безопасностью — либо платит за каждое обновление как за отдельный проект стоимостью 50–150 тысяч рублей. Для подрядчика же испорченная конфигурация — это гарантированный контракт на годы вперёд. Никто другой не возьмётся обновлять этот «Франкенштейн». ### Непереданные пароли и доступы. Пароль от базы данных, от хранилища конфигурации, от сервера — только у подрядчика. При расторжении договора передавать их «забывают» или «не успевают». ### Подписки и сервисы, оформленные на подрядчика. Астрал, Контур, ЭДО, сертификаты электронной подписи — подрядчик при настройке оформляет всё на свой аккаунт и оплачивает со своего счёта (включая стоимость в свои счета клиенту, разумеется). Пока работаете вместе — незаметно. Но стоит расстаться — и выясняется, что доступ к сервису сдачи отчётности принадлежит не вам. Причём выясняется это, как правило, накануне отчётного периода. Быстро разобраться, как всё было настроено, перерегистрировать, оплатить, проверить — это дни и нервы. А отчётность ждать не будет. ### Непередаваемые знания. Вся архитектура доработок — в голове одного человека. Код написан так, что разобраться может только автор: переменные названы бессмысленно, логика раскидана по модулям, комментариев нет. Другой программист потратит в 3–5 раз больше времени. Это не закладка, но эффект тот же — зависимость. ## Почему бухгалтер страдает первым Для бухгалтера закладка в коде — это не абстрактная ИТ-проблема. Это конкретная ситуация: утро понедельника, нужно сформировать отчёт для руководства, а модуль не работает. Или конец квартала, а расчёт себестоимости выдаёт ошибку. Или акт сверки не формируется, потому что внешняя обработка «почему-то» перестала загружаться. Бухгалтер не видит код. Бухгалтер видит результат: система, за которую компания заплатила, перестала работать. И срочно нужно исправлять — а значит, снова платить. Именно бухгалтер первым замечает, что «что-то сломалось». Именно бухгалтер тратит своё рабочее время на переписку с подрядчиком. И именно бухгалтер вынужден объяснять руководству, почему отчёт не готов вовремя — хотя его вины здесь нет. ## Как понять, что вы в зоне риска Вам не нужно быть программистом, чтобы оценить ситуацию. Задайте подрядчику (или своему ИТ-специалисту) пять вопросов: 1. Доработки сделаны через расширения или в основной конфигурации? Правильный ответ: через расширения, типовая конфигурация не тронута. Если подрядчик говорит «пришлось поменять типовые объекты» — спросите зачем. Каждое изменение типовой конфигурации — это будущая проблема с обновлениями. 2. Сколько типовых отчётов вы заменили «своими»? Правильный ответ: ни одного, или минимум с обоснованием. Если подрядчик создал десяток «своих» отчётов — спросите, чем не устроили типовые. Часто ответа не будет. 3. Что произойдёт с системой, если мы расторгнем договор? Правильный ответ: ничего, всё продолжит работать. Если подрядчик мнётся, говорит «нужно обсудить», уходит от прямого ответа — это сигнал. 4. Может ли другой специалист продолжить работу с нашей базой? Правильный ответ: да, вот документация по доработкам. Если ответ «в принципе да, но лучше мы» — это мягкая зависимость. Если на два или более вопроса вы получили уклончивые ответы — ситуация требует внимания. ## Как защитить себя Защита не требует технических знаний. Она требует управленческих решений. Зафиксируйте в договоре передачу всех доработок: расширения, внешние обработки, изменения конфигурации. Не «по запросу», не «после завершения проекта» — а регулярно, после каждой принятой задачи. Доработки — это актив компании, как и любая другая оплаченная работа. Требуйте обоснования каждой доработки. Прежде чем подрядчик начнёт писать «свой» отчёт — спросите: «А типовой это не умеет?» Часто оказывается, что умеет. Просто подрядчику выгоднее написать новый и потом его поддерживать. Запретите правку типовой конфигурации без согласования. Все доработки — через расширения. Если подрядчик говорит, что без правки типовых объектов никак — пусть обоснует письменно. Каждое изменение типовой конфигурации = удорожание каждого будущего обновления. Проводите ревизию кода. Раз в полгода — привлекайте независимого специалиста для проверки. Это стоит 20–50 тысяч рублей и занимает 1–3 дня. Для сравнения: обнаружение закладки после её срабатывания стоит в разы больше — и в деньгах, и во времени простоя. Храните всё у себя. База, конфигурация, внешние обработки, хранилище конфигурации — на ваших ресурсах. Пароли — в вашем менеджере паролей, а не в голове подрядчика. Проверяйте обновляемость. Раз в квартал спрашивайте: «Мы можем обновить конфигурацию до актуального релиза? Сколько это займёт?» Если ответ «2–3 дня» — нормально. Если «неделю и 150 тысяч» — конфигурацию уже испортили. ## Это не про «плохих» 1С-ников Повторю то, что писал в [первой части](/blog/nalog-na-haos-1.html): большинство подрядчиков по 1С — нормальные специалисты. Закладки в коде — это не массовое явление, это крайний случай. Но именно в отсутствие правил и контроля этот крайний случай становится возможным. Если у вас есть договор с пунктом о передаче кода, регулярная документация, периодическая ревизия и хранение на своих ресурсах — вам не нужно бояться закладок. Они просто не выживают в среде с правилами. А если ничего из этого нет — вы можете узнать о проблеме только когда она уже произойдёт. Как это произошло у нашего клиента. Чек-лист: защита от зависимости (распечатайте и проверьте) Пункт Да/Нет Все доработки сделаны через расширения, типовая конфигурация не изменена Нет дублирующих типовых отчётов Есть документация по каждой доработке База и хранилище конфигурации — на наших ресурсах Пароли от базы и серверов — у нас, а не только у подрядчика Обновление конфигурации до актуального релиза занимает не больше 2–3 дней Проводили ревизию кода за последний год Мы можем сменить подрядчика за 1–2 месяца Если 3+ пункта — «нет», пора менять правила игры. Предыдущие части серии: - [Часть 1: Налог на хаос — сколько стоит отсутствие регламентов](/blog/nalog-na-haos-1.html) - [Часть 2: Где в 1С утекают реальные деньги](/blog/nalog-na-haos-2.html) Столкнулись с похожей ситуацией? Нашли закладку в коде? Расскажите в комментариях — разберём вместе.