Арбитражный суд признал договор на разработку ПО с интеграцией 1С недействительным: техническое задание оказалось неопределённым, а стоимость сделки — 9,2 млн рублей.
Между заказчиком и исполнителем был заключён договор на создание веб-сайта, интегрированного с системой на платформе «1С: Бухгалтерия КОРП». Цена работ — 9 200 000 рублей. В ходе разбирательства выяснилось: в договоре не указали ни конкретную серию или номер программного продукта 1С, ни сведения о приобретённой лицензии. Более того, сам заказчик приобрёл лишь «1С:Комплект поддержки», а не «1С: Бухгалтерия КОРП» — то есть объективной возможности создать интегрированный с 1С сайт попросту не было.
Главный вопрос дела: можно ли считать договор недействительным, если техническое задание не детализировано? ТЗ — не формальность, а документ, определяющий, что именно создаётся, как это работает и по каким критериям заказчик принимает результат. Ориентир здесь — ГОСТ 34.602-2020. Если в ТЗ нет конкретных функциональных требований — что должно быть на странице авторизации, как формируются обращения, какие данные обрабатываются — стороны фактически не согласовали предмет договора. Суд установил: техническое задание не было детализировано и являлось неопределённым. Конкретные функциональные требования заказчика согласовать должны были, но этого не сделали. Без определённого и утверждённого ТЗ ни выполнить работу качественно, ни проверить результат невозможно.
Отдельный нюанс: договор предусматривал, что ТЗ разрабатывает исполнитель и утверждает заказчик до внесения предоплаты. Это условие нарушили — техническое задание не разрабатывалось и на утверждение не предоставлялось. Суд признал договор недействительной сделкой. Ключевые основания: в договоре нет сведений о конкретном программном продукте 1С для интеграции; у заказчика отсутствовала лицензия на «1С: Бухгалтерия КОРП», что делало исполнение объективно невозможным; ТЗ не детализировано и неопределённо, функциональные требования не согласованы; при таких обстоятельствах договор не мог быть исполнен надлежащим образом, а его предмет — согласован.
Что делать заказчику: разрабатывать детальное ТЗ до подписания договора — с функциональными требованиями, описанием экранных форм, алгоритмов обработки данных и сценариев использования; фиксировать в договоре конкретный программный продукт и лицензию — точную конфигурацию, версию, номер лицензии; не перекладывать разработку ТЗ на исполнителя без последующего письменного утверждения; проверять, что всё необходимое для исполнения есть на руках — если для интеграции нужна лицензия 1С, её приобретают до старта проекта. Что делать исполнителю: не начинать работу без детализированного и утверждённого ТЗ, а если заказчик настаивает на старте «по общим словам» — фиксировать это письменно, иначе риск неопределённости предмета договора ляжет именно на исполнителя; проверять наличие у заказчика нужных лицензий и инфраструктуры и закреплять это в договоре; настаивать на разработке ТЗ до предоплаты — так заказчик понимает, за что платит, а исполнитель — что именно должен сделать; фиксировать все согласования письменно, включая изменения требований и дополнительные условия, через допсоглашения или официальную переписку.
Знакомая ситуация? Обращайтесь — помогу оценить риски и перспективы @RRSadykov
Загрузка...
