Типичный сценарий выглядит так. Партнёр 1С обновил конфигурацию в субботу, в понедельник заказы с сайта перестали попадать в базу. Заказчик пишет обоим исполнителям. Партнёр отвечает, что обновление прошло штатно и типовой функционал работает. Интегратор отвечает, что его код не менялся, а изменилась структура данных под ним. Оба формально правы, обмен стоит, и никто не начинает чинить, потому что чинить чужое никто не обязан.
Проблема здесь не в квалификации и не в добросовестности. Проблема в том, что граница между двумя исполнителями не описана письменно, а обмен физически стоит ровно на ней: он живёт внутри конфигурации, но обслуживает внешнюю систему. Кто такой партнёр 1С формально, что даёт его статус и сколько стоит наценка сети, мы разбирали отдельно в материале про франчайзи и независимого подрядчика. Здесь речь о другом — о том, как разделить работу между двумя уже нанятыми исполнителями так, чтобы поломка не превращалась в переписку.
Ниже — таблица зон ответственности по объектам, разбор момента, в котором граница проверяется на прочность, пять формулировок для обоих договоров и признаки, по которым видно, что подрядчик связку не потянет. Ставки в расчётах: партнёрская фирма 3 500 ₽/час, независимый инженер 3 000 ₽/час, внешний юрист 4 500 ₽/час. Ориентиры на сентябрь 2026 года.
Граница проходит по конфигурации, а не по компаниям
Разделение работает, если провести его по объектам, а не по репутации. Партнёр 1С сильнее там, где речь о самой конфигурации: лицензии и договор ИТС, релизы типовых конфигураций, обновление с сохранением доработок, учётная методика и отраслевые решения на базе 1С. Интеграционный подрядчик сильнее там, где конфигурация кончается: обмен с сайтом, CRM и маркетплейсом, веб-сервисы и очереди, обработка ошибок и повторные попытки, мониторинг, нагрузка, надстройки поверх учётных данных.
На словах это разделение принимают все. Ломается оно на трёх объектах, которые не принадлежат ни одной стороне очевидным образом: расширение, в котором живёт код обмена; служебная учётная запись, под которой этот обмен ходит; и тестовый контур, без которого ни одна сторона не может проверить свою часть. Все три надо назвать по именам.
| Объект | Кто владеет | Кто отвечает при поломке | Что фиксируется письменно |
|---|---|---|---|
| Лицензии, договор ИТС, релизы конфигурации | Партнёр 1С | Партнёр 1С | Срок уведомления о плановом релизе |
| Типовая конфигурация и учётная методика | Партнёр 1С | Партнёр 1С | Реестр доработок с датами и авторами |
| Расширение с кодом обмена | Заказчик, разрабатывает интегратор | Интегратор | Имя расширения, состав объектов, право на выгрузку |
| Планы обмена, веб-сервисы, очереди | Заказчик, разрабатывает интегратор | Интегратор | Перечень потоков по именам, а не «интеграция» |
| Внешние системы: сайт, CRM, маркетплейс | Заказчик | Интегратор | Кто держит доступы и кто продлевает ключи |
| Мониторинг обмена и дежурство | Заказчик | Интегратор | Метрики, кому уходит оповещение, срок реакции |
| Справочники и качество данных | Заказчик | Заказчик | Кто хозяин каждого справочника поимённо |
| Тестовый контур на копии базы | Заказчик | Заказчик | Кто разворачивает, как часто обновляется, у кого доступ |
Седьмая строка вызывает больше всего сопротивления и она же чаще всего спасает проект. За справочники не отвечает ни один подрядчик. Дубли контрагентов, разъехавшиеся единицы измерения и позиции с одинаковыми названиями — это данные заказчика, и никакой обмен их не починит. Если этого не написать, при первом же расхождении остатков спор пойдёт по тому же кругу: интегратор скажет, что возит то, что дали, партнёр — что учёт считает по тому, что введено.
Карта из трёх вертикальных зон. Левая зона «Партнёр 1С»: узлы «лицензии и ИТС», «релизы типовых конфигураций», «учётная методика», «реестр доработок». Правая зона «Интегратор»: узлы «сайт», «CRM», «маркетплейс», «мониторинг обмена». Средняя узкая полоса подписана «граница» и содержит три узла, выделенных двойной рамкой: «расширение с кодом обмена», «служебная учётная запись», «тестовый контур на копии базы». Через среднюю полосу проходят стрелки в обе стороны с подписью «поток данных». Внизу отдельная горизонтальная полоса во всю ширину «Справочники и качество данных — зона заказчика». Чертёжная графика, подписи по-русски.
Момент, в котором граница проверяется: обновление конфигурации
Плановое обновление — единственное регулярное событие, которое одновременно затрагивает обе зоны. У активно развивающейся конфигурации таких событий три в год, и каждое из них — это точка, в которой либо срабатывает регламент, либо начинается переписка.
Механика поломки почти всегда одна: обновление не трогает код обмена, но меняет структуру данных под ним. Реквизит переехал, состав табличной части изменился, метод общего модуля переименован. Обмен не падает с ошибкой, а начинает возить пустоту или молча пропускать часть документов. Подробный разбор того, как это выглядит и как увидеть раньше клиента, — в материале про то, почему отвалился обмен с 1С.
Самая обидная строка здесь — 39 000 ₽ за диагностику. Это деньги, заплаченные не за починку, а за ответ на вопрос «чья это зона», и платит их заказчик дважды, потому что каждая сторона исследует свою половину. Регламент, описанный ниже, убирает именно эту строку целиком и сокращает простой с восьми дней до одного окна.
Две горизонтальные ленты времени одна под другой на общей шкале дней. Верхняя «Без регламента», 8 рабочих дней: отрезки «дни 1–2 переписка», «дни 3–5 двойная диагностика — 39 000 ₽», «дни 6–8 исправление — 35 000 ₽», под лентой подпись «простой обмена 88 560 ₽, итого 162 560 ₽». Нижняя «С регламентом», 1 день: отрезки «уведомление за 5 рабочих дней», «регресс в тестовом контуре до релиза», «окно обновления, обмен остановлен флагом», «догон и сверка за окно», под лентой подпись «простой в пределах окна». Справа общий итог-сравнение двух лент. Чертёжная графика, подписи по-русски.
Пять формулировок, которые снимают спор
Это не юридические конструкции, а описание порядка работ. Их пишут одинаково в оба договора — с партнёром и с интегратором, — иначе смысл теряется: односторонняя обязанность уведомлять никого не спасает.
- 1Предмет договора перечисляет объекты по именам. Не «сопровождение конфигурации 1С» и не «поддержка интеграции», а список: план обмена такой-то, HTTP-сервис такой-то, расширение с таким-то именем, регламентное задание с таким-то названием. Формулировка «сопровождение конфигурации» почти никогда не включает внешний обмен — формально это не конфигурация, и в споре это работает против вас.
- 2Окно обновления и срок уведомления. Партнёр уведомляет о плановом релизе не позднее чем за пять рабочих дней. Интегратор в это окно обязан прогнать регресс обмена в тестовом контуре и письменно подтвердить готовность. Обновление без такого подтверждения возможно, но тогда ответственность за обмен в этом релизе переходит к тому, кто настоял на сроке.
- 3Правило первого обращения. Первичную диагностику начинает тот, к кому заказчик обратился, независимо от предполагаемой зоны, и делает это в течение оговорённого срока — обычно четыре рабочих часа. Только после диагностики инцидент либо закрывается, либо передаётся второй стороне с выгрузкой лога. Закрывать инцидент с формулировкой «не наша зона» без передачи нельзя — это отдельный пункт.
- 4Доступ к логам и тестовому контуру у обеих сторон. Именной, с журналированием, без права передачи третьим лицам. Половина споров держится на том, что интегратор не видит журнала регистрации 1С, а партнёр не видит журнала внешнего сервиса, и каждый описывает происходящее со своей стороны стены.
- 5Порядок передачи инцидента. Письменно, с указанием времени, версии конфигурации и выгрузкой соответствующего фрагмента журнала. Устная передача по телефону не считается: через неделю никто не помнит, кто что сказал, и разбор начинается заново. Общий состав таких договорных требований мы разбирали в материале о том, что должно быть в договоре на разработку.
Реестр доработок с датами, авторами и списком изменённых типовых объектов. Он ведётся партнёром, доступен интегратору и обновляется при каждом изменении. Без него цена следующего обновления не предсказывается вообще: три часа проверки при работе через расширения превращаются в десять часов переноса при изменённых типовых объектах, а в запущенном случае — в сорок часов ручного разбора и от 140 000 ₽. Механика роста этого счёта разобрана в материале про обновление 1С после доработок.
Признаки, что подрядчик не потянет связку
Проверяются они на первой же встрече и не требуют технических знаний. Смотреть надо не на то, что подрядчик рассказывает, а на то, о чём он спрашивает.
- Называет цену до обследования. Обмен с одной и той же на вид системой стоит по-разному в зависимости от конфигурации, её редакции и объёма доработок. Цифра, названная до того, как человек посмотрел базу, — это цифра из головы, и она изменится, когда выяснится реальное положение дел.
- Не спрашивает про конфигурацию и её доработки. Первые три вопроса нормального исполнителя: какая конфигурация и редакция, снята ли она с поддержки, есть ли реестр доработок. Если этих вопросов нет, человек не планирует жить с вашей базой дольше сдачи работ.
- Не требует тестовый контур. Разработка обмена прямо в рабочей базе — не смелость, а отсутствие процесса. Отказ от тестового контура означает, что каждый ваш релиз будет проверяться на живых заказах.
- Не спрашивает, кто и как часто обновляет конфигурацию. Это главный вопрос про эксплуатацию, а не про разработку. Исполнитель, который его не задал, ещё не думал о том, что будет с его кодом через полгода.
- Обещает, что при обновлениях ничего не сломается. Правильный ответ звучит иначе: сломается, вот регламент, по которому мы это ловим в тестовом контуре до релиза, и вот сколько времени занимает регресс. Обещание надёжности вместо описания процедуры — маркер того, что процедуры нет.
- Не готов ставить мониторинг обмена. Без него поломка обнаруживается от клиента, а не от системы, и любой разговор о зонах ответственности начинается уже в конфликте. Мониторинг — это 8 часов работы и разумная часть любого договора на сопровождение обмена.
Сравнение в две колонки по шести строкам. Левая колонка «О чём спрашивает»: «какая конфигурация и редакция», «снята ли она с поддержки», «есть ли реестр доработок», «кто и как часто обновляет», «есть ли тестовый контур на копии базы», «кому уходит оповещение при остановке обмена». Правая колонка «Что рассказывает вместо этого»: «цена до обследования», «сделаем как у всех», «у нас не ломается при обновлениях», «мониторинг не нужен, вы сами заметите», «работаем прямо в рабочей базе», «поддержка по звонку». Внизу общая подпись «цена одного спора при таком подходе — 162 560 ₽». Чертёжная графика, подписи по-русски.
Когда двух исполнителей не нужно
Разделение зон стоит денег: два договора, два счёта, регламент передачи и время заказчика на координацию. В трёх ситуациях это лишнее.
- Типовая конфигурация без доработок и один типовой обмен. Настройка обмена с сайтом на готовом модуле или обмен «УНФ — Бухгалтерия» из коробки делается партнёром целиком, и границы там нет. Второй исполнитель здесь добавит стоимость координации, не добавив ничего к результату.
- Компания до 15–20 человек с одним потоком данных. Объём работ по обмену — несколько десятков часов в год. Держать под него отдельного подрядчика с дежурством дороже, чем чинить по факту; разумнее договориться с партнёром о том, что обмен входит в предмет договора, и записать это отдельной строкой.
- Задача решается внутри конфигурации. Если разбор показывает, что нужен отчёт, реквизит или правило заполнения, — это работа партнёра и никого больше. Развилку между доработкой внутри и вынесением логики наружу мы считали на три года вперёд в материале про доработку 1С или внешнюю интеграцию.
И встречное соображение, которое стоит держать в голове, если исполнитель у вас пока один. Единственный подрядчик снимает вопрос границы, но создаёт другой: у него нет внутреннего оппонента, и качество его работы никто не смотрит со стороны. Практический компромисс, который мы видим чаще всего у компаний на 40–150 человек, — партнёр держит учётный контур и обновления, независимый исполнитель делает обмен и дежурит по нему, а граница между ними описана на одной странице, которую обе стороны подписали до начала работ. Эта страница и есть весь предмет статьи.
Спор «это не наша часть» стоит дороже любой поломки, потому что за него платят дважды и не получают ремонта.
