Договоры с подрядчиками 1С с 1 июля 2026: что нового

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

SLA в часах, а не «в разумные сроки»: время реакции на критичный инцидент — до 1 часа, восстановление — до 4 часов в рабочее время.
Финансовая ответственность: штраф за просрочку SLA от 0,1% до 1% стоимости этапа за каждый час сверх норматива.
Поэтапная приёмка: акт на каждый спринт + единый акт ввода в эксплуатацию, без «приёмки задним числом».
Передача исходников: расширения и внешние обработки передаются заказчику с документацией в конце каждого этапа.
Защита данных: отдельное приложение об обработке персональных данных и режиме коммерческой тайны.

Что именно изменилось в подходе к договорам с 1 июля 2026?

Главное изменение — рынок и судебная практика окончательно сместились от рамочных договоров «оказание услуг по сопровождению 1С» к договорам с измеримыми обязательствами. Если раньше формулировки «исполнитель устраняет ошибки в разумные сроки» считались нормой, то теперь такие пункты трактуются не в пользу подрядчика: при споре суд требует конкретные метрики, акты и переписку.

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

Три новых обязательных блока договора

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

Какие требования к SLA теперь обязательны?

SLA (Service Level Agreement) перестал быть маркетинговым приложением и стал юридически значимой частью договора. Ключевое требование 2026 года — все показатели должны быть выражены в измеримых единицах: часах, процентах, конкретных временных окнах. Формулировки «оперативно», «в кратчайшие сроки», «по мере возможности» больше не работают как защита ни для одной из сторон.

Какие метрики SLA нужно прописывать?

Минимальный набор показателей, который ожидают увидеть и заказчики, и суды:

Время реакции — сколько времени проходит от регистрации заявки до начала работы.
Время восстановления — за сколько восстанавливается работоспособность.
Доступность системы — процент аптайма за месяц (например, 99,5%).
Часы поддержки — рабочее окно, праздники, дежурная линия.
Каналы регистрации заявок — единая система учёта (helpdesk), а не «звонок менеджеру».

Уровень	Тип инцидента	Реакция	Восстановление
Критичный	Система недоступна, нельзя проводить документы, остановка отгрузок	до 1 часа	до 4 часов
Высокий	Не работает важный участок (зарплата, закрытие месяца)	до 2 часов	до 8 часов
Средний	Ошибка обходится вручную, есть workaround	до 4 часов	до 2 рабочих дней
Низкий	Косметика, неудобство, доработка отчёта	до 1 рабочего дня	по согласованию

Важный нюанс: время восстановления почти всегда считается в рабочих часах согласованного окна поддержки. Если бизнес работает круглосуточно, нужен отдельный тариф 24/7 и дежурная смена — иначе подрядчик физически не выполнит SLA, а заказчик не получит того, на что рассчитывал.

Как теперь распределяется ответственность сторон?

Раздел ответственности — самое спорное место договора. С 1 июля 2026 года стандартом стало указание конкретных штрафных санкций за нарушение SLA и лимита ответственности подрядчика. Это защищает обе стороны: заказчик получает реальный рычаг, а исполнитель — потолок убытков, выше которого он не отвечает.

Какие штрафы считаются адекватными?

Распространённая практика — пеня за каждый час сверх норматива восстановления. Для критичных инцидентов это 0,5–1% стоимости месячного абонемента (или этапа) за каждый час просрочки, для остальных — 0,1–0,3%. При этом обязательно фиксируется общий лимит — обычно не более 100% стоимости соответствующего этапа или месячного платежа.

Правило 2026 года: ответственность без верхнего лимита подписывать опасно для подрядчика, а ответственность без штрафов — бессмысленна для заказчика. Баланс — в измеримых санкциях с потолком.

За что подрядчик отвечает отдельно?

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

Тема приёмки и спорных ситуаций тесно связана с ответственностью. Если вы сомневаетесь в качестве сданного результата, полезен отдельный разбор — как принять работу 1С-программиста и что делать, если результат не устраивает.

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

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

Что должно быть в регламенте приёмки?

Критерии приёмки — что считается выполненным (прохождение тест-кейсов, отсутствие критичных дефектов).
Срок на приёмку — сколько дней у заказчика на проверку (обычно 5–10 рабочих дней).
Порядок устранения замечаний — сколько итераций, в какие сроки.
Молчаливая приёмка — если заказчик не дал мотивированный отказ в срок, работы считаются принятыми.
Что НЕ является дефектом — изменение требований, новые хотелки, доработки за рамками ТЗ.

Отдельно стоит зафиксировать разграничение между гарантийным устранением ошибки (бесплатно) и новой доработкой (оплачивается). Именно здесь происходит большинство конфликтов. Подробный разбор приёмки крупного проекта со списком красных флагов есть в материале — как принять 1С-проект у подрядчика.

Как автоматизировать учёт SLA внутри 1С?

Когда SLA стал юридически значимым, его нужно объективно измерять. Многие компании учитывают заявки прямо в 1С — в типовых конфигурациях есть подсистемы учёта обращений, либо используется отдельный регистр сведений. Покажем, как рассчитать факт нарушения времени реакции по заявкам поддержки.

Допустим, в конфигурации есть документ ЗаявкаВПоддержку с реквизитами ДатаРегистрации, ДатаНачалаРаботы, УровеньКритичности. Норматив времени реакции храним в справочнике УровниКритичности в реквизите ВремяРеакцииЧасов.

Запрос = Новый Запрос;
Запрос.Текст =
	"ВЫБРАТЬ
	|	Заявки.Ссылка КАК Заявка,
	|	Заявки.ДатаРегистрации КАК ДатаРегистрации,
	|	Заявки.ДатаНачалаРаботы КАК ДатаНачалаРаботы,
	|	Заявки.УровеньКритичности КАК УровеньКритичности,
	|	ЕСТЬNULL(Заявки.УровеньКритичности.ВремяРеакцииЧасов, 0) КАК Норматив,
	|	РАЗНОСТЬДАТ(Заявки.ДатаРегистрации, Заявки.ДатаНачалаРаботы, ЧАС) КАК ФактЧасов,
	|	ВЫБОР
	|		КОГДА РАЗНОСТЬДАТ(Заявки.ДатаРегистрации, Заявки.ДатаНачалаРаботы, ЧАС)
	|				> ЕСТЬNULL(Заявки.УровеньКритичности.ВремяРеакцииЧасов, 0)
	|			ТОГДА ИСТИНА
	|		ИНАЧЕ ЛОЖЬ
	|	КОНЕЦ КАК SLAНарушен
	|ИЗ
	|	Документ.ЗаявкаВПоддержку КАК Заявки
	|ГДЕ
	|	Заявки.ДатаНачалаРаботы > &ДатаНачала
	|	И Заявки.ДатаНачалаРаботы <= &ДатаКонца";

Запрос.УстановитьПараметр("ДатаНачала", НачалоМесяца(ТекущаяДата()));
Запрос.УстановитьПараметр("ДатаКонца", КонецМесяца(ТекущаяДата()));

Результат = Запрос.Выполнить().Выбрать();
КоличествоНарушений = 0;
Пока Результат.Следующий() Цикл
	Если Результат.SLAНарушен Тогда
		КоличествоНарушений = КоличествоНарушений + 1;
	КонецЕсли;
КонецЦикла;

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

Как рассчитать неустойку за нарушение SLA в 1С?

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

// Расчёт неустойки за просрочку восстановления по одной заявке
Функция РассчитатьНеустойкуПоЗаявке(Заявка, СтоимостьЭтапа) Экспорт

	ФактЧасов = РазностьДат(Заявка.ДатаРегистрации, Заявка.ДатаЗакрытия, "Час");
	НормативЧасов = Заявка.УровеньКритичности.ВремяВосстановленияЧасов;
	ПроцентЗаЧас = Заявка.УровеньКритичности.ПроцентПениЗаЧас;

	ЧасовПросрочки = ФактЧасов - НормативЧасов;
	Если ЧасовПросрочки <= 0 Тогда
		Возврат 0; // SLA соблюдён, пени нет
	КонецЕсли;

	Неустойка = СтоимостьЭтапа * ПроцентЗаЧас / 100 * ЧасовПросрочки;

	// Лимит ответственности — не более 100% стоимости этапа
	Если Неустойка > СтоимостьЭтапа Тогда
		Неустойка = СтоимостьЭтапа;
	КонецЕсли;

	Возврат Неустойка;

КонецФункции

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

Как зафиксировать передачу исходников и прав?

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

Технически выгрузка расширения выполняется штатными средствами платформы — через Конфигуратор командой «Сохранить расширение в файл» (формат .cfe) либо программно при работе с хранилищем конфигурации. Для внешних обработок передаётся файл .epf вместе с описанием алгоритма. В договоре стоит прямо указать формат передачи и срок — например, «в течение 3 рабочих дней после подписания акта этапа».

Что передаётся: файлы расширений (.cfe), внешние обработки и отчёты (.epf, .erf), тексты запросов СКД, документация по доработкам.
В каком виде: исходный код с комментариями, а не только скомпилированный результат.
Кому принадлежат права: исключительное право на доработки переходит заказчику (либо предоставляется неисключительная лицензия — это нужно явно прописать).

Без этого пункта заказчик рискует попасть в зависимость от одного подрядчика: сменить исполнителя без исходников практически невозможно, а восстановление логики с нуля стоит дороже самой доработки.

Чек-лист подготовки к 1 июля 2026

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

Выводы

Изменения с 1 июля 2026 года переводят отношения с подрядчиками 1С из плоскости «джентльменских договорённостей» в плоскость измеримых обязательств. Это выгодно обеим сторонам: заказчик получает предсказуемость и защиту, а добросовестный подрядчик — чёткие границы ответственности и защиту от бесконечных «хотелок» вне ТЗ.

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

Не откладывайте пересмотр документов на последний месяц — переходный период всегда сопровождается спорами по «старым» договорам, заключённым до вступления изменений в силу.

Найдите специалиста для решения этой задачи на koderion.ru