Как принять работу 1С-программиста: чек-лист приёмки, типичные споры и что делать, если результат не устраивает

📅 Опубликовано 18 июня 2026 г. · 🔄 Обновлено 28 июля 2026 г.

Коротко: Принять работу 1С-программиста правильно — значит проверить результат по формальному чек-листу до подписания акта. Минимум: соответствие ТЗ, тест на реальных данных, проверка производительности, наличие документации и инструкции пользователя. Без этого 40% доработок возвращаются на переделку, а средняя стоимость споров с фрилансером — 30 000–120 000 ₽ потерянного времени и денег.

Почему приёмка работы 1С — отдельный навык

Большинство руководителей и бухгалтеров принимают работу 1С-программиста по принципу «включилось — значит работает». Это главная ошибка. Доработка может запускаться, но считать неправильно, тормозить при нагрузке, ломаться после обновления платформы или не иметь никакой документации. Обнаружится это через 2–3 месяца, когда исполнитель уже недоступен.

По данным практики маркетплейса Koderion, около 35% конфликтов между заказчиками и 1С-специалистами возникают именно на этапе приёмки — стороны не договорились заранее, что считается «готовой работой». Формальный чек-лист приёмки решает эту проблему на старте.

Есть и юридическая сторона: Гражданский кодекс исходит из того, что заказчик, принявший работу без проверки, теряет право ссылаться на явные недостатки, которые можно было обнаружить при обычном осмотре (ст. 720 ГК РФ). То есть формальная приёмка — не бюрократия, а условие, при котором ваши претензии вообще будут иметь вес.

Как проверить 1С-программиста до начала работ

Приёмка по-настоящему начинается не в момент сдачи, а до подписания договора. Вопрос «как проверить 1С программиста» большинство заказчиков задаёт уже постфактум — когда работа сдана, деньги ушли, а результат не устраивает. На старте те же риски снимаются за полчаса:

• Сертификаты 1С — «1С:Профессионал» подтверждает уверенное знание прикладного решения, «1С:Специалист» — умение дорабатывать конфигурацию по стандартам. Номер сертификата можно просто попросить и сверить.
• Портфолио с конкретикой — не «делал доработки в УТ», а «реализовал обмен УТ 11 с маркетплейсом через HTTP-сервис, около 4 000 заказов в сутки». Задайте 2–3 уточняющих вопроса по описанному кейсу: человек, который делал это сам, отвечает деталями, а не общими словами.
• Платное тестовое задание на 1–2 часа — небольшая реальная задача из вашей базы (копии). Смотрите не только на результат, но и на оформление: комментарии, именование переменных, вынесено ли изменение в расширение.
• Три контрольных вопроса: как вы доработаете типовую конфигурацию, чтобы не слетело обновление; как проверите, что запрос не «положит» базу на объёме; что именно войдёт в гарантию, а что будет считаться новой задачей.
• Юридический статус — самозанятый, ИП или ООО. У самозанятого после оплаты запрашивается чек из приложения «Мой налог», у ИП — сверяются реквизиты с выпиской из ЕГРИП. Это защищает вас от вопросов по расходам и по статусу выплаты.
• Отзывы с проверяемым следом — рейтинг на бирже с историей закрытых сделок надёжнее скриншотов переписки, которые нельзя перепроверить.

Практика показывает: заказчики, которые проверяют исполнителя на входе, тратят на приёмку в 1,5–2 раза меньше времени — просто потому, что исправлять почти нечего.

Что проверять при приёмке: 12-пунктный чек-лист

Ниже — практический чек-лист, который можно использовать для любой доработки 1С: от небольшого отчёта до комплексного внедрения модуля.

Блок 1. Соответствие техническому заданию

• ✓ Все пункты ТЗ реализованы — пройдитесь по каждому требованию из ТЗ и проверьте наличие в системе.
• ✓ Нет «самодеятельности» — программист не добавил функции, которые не просили, или не убрал то, что должно было остаться.
• ✓ Интерфейс соответствует описанию — кнопки, поля, формы расположены так, как было согласовано.

Блок 2. Тестирование на реальных данных

• ✓ Проверка на боевой базе или копии — тест только на демо-данных не считается полноценной приёмкой.
• ✓ Граничные случаи — нулевые значения, максимальные суммы, пустые поля, нестандартные контрагенты.
• ✓ Корректность расчётов — сверьте результаты с ручным расчётом или эталонными данными.
• ✓ Работа при параллельных пользователях — если система многопользовательская, проверьте одновременный доступ минимум 3–5 пользователей.

Блок 3. Производительность и стабильность

• ✓ Время выполнения операции — отчёт на 10 000 строк не должен формироваться дольше 30–60 секунд (если иное не оговорено в ТЗ).
• ✓ Отсутствие блокировок — доработка не должна создавать технологические блокировки в базе.
• ✓ Работа после обновления — проверьте, что доработка выполнена через расширение или механизм подписок, а не «в лоб» в типовой конфигурации.

Блок 4. Документация и передача знаний

• ✓ Инструкция пользователя — хотя бы 1–2 страницы с описанием, как пользоваться новым функционалом.
• ✓ Техническое описание доработки — что именно изменено, в каких объектах конфигурации, почему такое решение.

Приёмка кода, написанного с помощью нейросетей

К 2026 году генеративные ассистенты стали обычным инструментом 1С-разработчиков: код на встроенном языке пишется быстрее, но ошибки в нём другого типа — не синтаксические, а смысловые. Формально всё компилируется и даже запускается, а логика оказывается неверной на редких ветках. Отдельно проверять «писал человек или нейросеть» бессмысленно и не нужно: ответственность за результат несёт исполнитель независимо от способа написания кода. Полезно другое — знать, где именно такой код ломается, и проверить эти места.

• Несуществующие методы и параметры — генеративные модели уверенно придумывают функции общих модулей БСП или параметры, которых нет в вашей версии конфигурации. Проверяется синтаксическим контролем в конфигураторе и запуском всех ветвей алгоритма, а не только «счастливого пути».
• Запросы внутри цикла — классический антипаттерн, который сгенерированный код воспроизводит особенно часто. На 20 тестовых записях незаметно, на 200 000 боевых — минуты ожидания и блокировки.
• Отсутствие обработки ошибок и транзакций — нет попытки/исключения, нет отката при частичной записи. Проверяется намеренным «сломом»: отключите интернет во время обмена, введите заведомо некорректные данные.
• Игнорирование прав доступа — код работает под полными правами и падает у обычного пользователя. Обязательно тестируйте под учётной записью с реальной ролью, а не под администратором.
• Мёртвый код и «шумные» комментарии — блоки, которые никогда не выполняются, и комментарии, описывающие не тот алгоритм, что реализован ниже. Это прямой риск для того, кто будет сопровождать доработку после вас.

Что запросить у исполнителя дополнительно: устное объяснение логики ключевого фрагмента (человек, понимающий свой код, объясняет за минуту), результаты прогона инструментов автоматизированной проверки конфигурации на соответствие стандартам разработки 1С и — для крупных доработок — сценарные тесты, которые можно перезапустить после следующего обновления. Отдельным пунктом в договоре зафиксируйте, что исполнитель гарантирует работоспособность и оригинальность переданного кода вне зависимости от использованных инструментов.

Сколько времени занимает правильная приёмка?

Время на приёмку зависит от масштаба работ. Ориентир: 10–15% от времени разработки. Если программист потратил 8 часов — заложите 1–1,5 часа на тестирование и проверку.

Типичные споры при приёмке и как их разрешить

Спор №1: «Работает не так, как я представлял»

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

Спор №2: «После обновления 1С всё сломалось»

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

Спор №3: «Считает неправильно, но программист говорит, что всё верно»

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

Спор №4: «Программист недоступен после сдачи работы»

Типичная ситуация с фрилансерами: деньги получены, связь пропала. Решение: не платите 100% аванса. Оптимальная схема оплаты — 30% аванс, 70% после приёмки. При работе через маркетплейс (например, Koderion) деньги хранятся на эскроу-счёте и выплачиваются исполнителю только после подтверждения приёмки заказчиком.

Стоимость переделок: во что обходятся ошибки при приёмке

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

Акт приёмки-сдачи работ: что должно быть в документе

Акт приёмки — юридически значимый документ. Без него доказать факт выполнения работ или предъявить претензии крайне сложно. Минимальный состав акта для 1С-работ в 2026 году:

1. Описание выполненных работ — со ссылкой на ТЗ или номер задачи.
2. Перечень изменённых объектов конфигурации — справочники, документы, отчёты, регистры.
3. Результаты тестирования — краткое описание проведённых проверок и их результат.
4. Гарантийные обязательства — срок (обычно 1–3 месяца) и условия гарантийного обслуживания.
5. Подписи сторон и дата — с указанием, что заказчик проверил и принял работу.

Если акт подписывается электронно от имени организации сотрудником, а не руководителем, потребуется машиночитаемая доверенность — уточните это заранее у своего оператора ЭДО, иначе подписанный акт окажется бесполезным в споре.

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

Как выстроить приёмку при работе с аутсорсинговой компанией

При аутсорсинге приёмка обычно формализована: компания сама предлагает регламент тестирования и гарантийный период. Но есть нюансы, которые стоит проконтролировать:

• Опытная эксплуатация (ОПЭ) — для крупных проектов обязателен период 2–4 недели, когда система работает параллельно со старым процессом. Все расхождения фиксируются и устраняются до финального закрытия проекта.
• Протокол тестирования — попросите аутсорсера предоставить заполненный протокол с описанием тест-кейсов. Если его нет — это красный флаг.
• Разграничение ответственности — уточните, кто отвечает за обновление доработок при выходе новых релизов конфигурации. Обычно это входит в абонентское обслуживание за 15 000–60 000 ₽/мес.

Что делать, если результат не устраивает: алгоритм действий

Если работа сдана, но вы обнаружили проблемы — действуйте по чёткому алгоритму:

1. Зафиксируйте проблему письменно — скриншоты, видео экрана, описание шагов воспроизведения. Чем детальнее — тем быстрее исправят.
2. Направьте претензию исполнителю — письменно (email, мессенджер) с описанием конкретного несоответствия ТЗ. Дайте срок ответа — 2–3 рабочих дня.
3. Не подписывайте акт до устранения — подписанный акт означает согласие с результатом. После подписания претензии принимаются только в рамках гарантии.
4. Если исполнитель не реагирует — при работе через маркетплейс откройте спор: платформа выступает арбитром. При прямом договоре — претензионное письмо с требованием устранить недостатки в 10-дневный срок (ст. 723 ГК РФ).
5. Привлеките независимого эксперта — другой 1С-специалист за 3 000–8 000 ₽ напишет экспертное заключение о качестве работы. Это весомый аргумент при споре.

FAQ: частые вопросы о приёмке работы 1С-программиста

Нужно ли тестировать работу, если программист — знакомый или работает давно?

Да. Формальная приёмка защищает обе стороны. Даже опытный программист может допустить ошибку в конкретном кейсе. Приёмка — не недоверие, а профессиональный процесс.

Кто должен проводить тестирование — заказчик или программист?

Программист проводит внутреннее тестирование до сдачи. Заказчик проводит приёмочное тестирование — проверяет, что результат соответствует бизнес-требованиям. Это разные виды проверки, и оба обязательны.

Что делать, если нет ТЗ и непонятно, с чем сравнивать результат?

Восстановите требования ретроспективно: запишите, что именно вы ожидали увидеть, и сравните с тем, что получили. На будущее — всегда составляйте ТЗ до начала работ, даже на 1 страницу.

Принимать работу безопаснее через биржу 1С Koderion с безопасной сделкой.

Часто задаваемые вопросы

Что обязательно проверить при приёмке работы 1С-программиста?

Минимальный чек-лист приёмки: соответствие всех пунктов ТЗ, тест на реальных данных (не только демо), проверка граничных случаев, корректность расчётов (сверка с эталоном вручную), производительность при нагрузке, работа в многопользовательском режиме, наличие инструкции пользователя и технического описания доработки. Также убедитесь, что изменения внесены через расширение, а не напрямую в типовую конфигурацию.

Как проверить 1С программиста до начала работ?

До подписания договора проверьте: сертификаты «1С:Профессионал» и «1С:Специалист» (номер можно сверить), портфолио с конкретными кейсами и уточняющими вопросами по ним, небольшое платное тестовое задание на 1–2 часа на копии вашей базы, ответы на три контрольных вопроса (как доработка переживёт обновление, как проверяется производительность, что входит в гарантию), юридический статус (самозанятый — чек из «Мой налог», ИП — выписка из ЕГРИП) и отзывы с проверяемой историей сделок.

Сколько времени занимает приёмка работы 1С?

Рекомендуемое время приёмки — 10–15% от времени разработки. Небольшой отчёт (2–4 ч разработки) проверяется за 30–60 минут. Интеграция с внешней системой (16–40 ч) требует 4–8 ч тестирования. Комплексное внедрение — отдельный этап опытно-промышленной эксплуатации (ОПЭ) длиной 2–4 недели.

Что делать, если 1С-программист сдал работу, но она работает неправильно?

Алгоритм: 1) Зафиксируйте проблему письменно — скриншоты, видео, шаги воспроизведения. 2) Направьте письменную претензию исполнителю с описанием несоответствия ТЗ, дайте срок ответа 2–3 рабочих дня. 3) Не подписывайте акт приёмки до устранения. 4) При отсутствии реакции — откройте спор через маркетплейс или направьте претензионное письмо по ст. 723 ГК РФ. 5) При необходимости привлеките независимого эксперта (3 000–8 000 ₽ за заключение).

Как принимать код 1С, написанный с помощью нейросетей?

Ответственность за код несёт исполнитель независимо от инструментов. При приёмке проверяйте типичные слабые места сгенерированного кода: несуществующие методы и параметры (синтаксический контроль в конфигураторе, прогон всех ветвей алгоритма), запросы внутри цикла, отсутствие обработки ошибок и транзакций, работу под учётной записью с реальными правами, а не под администратором. Дополнительно попросите объяснить логику ключевого фрагмента и предоставить результаты автоматизированной проверки конфигурации на соответствие стандартам разработки 1С.

Что такое гарантийный период на доработки 1С и сколько он длится?

Гарантийный период — время, в течение которого исполнитель обязан бесплатно устранять ошибки в сданной работе. Стандартный срок — 1–3 месяца, должен быть прописан в договоре. В гарантийный период входят баги (ошибки в логике, неверные расчёты), но не входят новые требования и изменения законодательства.

Нужен ли акт приёмки при работе с фрилансером?

Да, акт приёмки нужен всегда. Без него сложно доказать факт выполнения работ или предъявить претензии. Минимальный состав: описание работ со ссылкой на ТЗ, перечень изменённых объектов конфигурации, результаты тестирования, гарантийные обязательства, подписи и дата. Если работаете без официального договора, зафиксируйте приёмку хотя бы письменным подтверждением в мессенджере.

Во сколько обходится переделка работы 1С-программиста?

Переделка обходится в 1,5–2 раза дороже первоначальной разработки. Небольшой отчёт, стоивший 5 000–15 000 ₽, при переделке обойдётся в 8 000–25 000 ₽. Переделка интеграции с ошибками — от 50 000 до 130 000 ₽ при первоначальной стоимости 30 000–80 000 ₽. Именно поэтому правильная приёмка экономит деньги.

Как защититься от ситуации, когда программист пропадает после получения денег?

Используйте схему поэтапной оплаты: 30% аванс, 70% после подписания акта приёмки. При работе через маркетплейс (например, Koderion) деньги хранятся на эскроу-счёте и перечисляются исполнителю только после подтверждения приёмки заказчиком. Это исключает риск исчезновения исполнителя с авансом.

Что значит 'доработка выполнена в лоб' и почему это плохо?

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