Что важнее пункт договора или технического задания?
Expertrating.ru

Юридический портал

Что важнее пункт договора или технического задания?

Обязательно ти техническое задание для договоров строительного подряда?

(Мы не составляли, а налоговая проверка требует оъяснить почему) На что ссылаться? Спасибо!

В соответствии с п. 1 ст. 432 ГК РФ существенными являются условия о предмете договора, условия, которые названы в законе или иных правовых актах как существенные или необходимые для договоров данного вида, а также все те условия, относительно которых по заявлению одной из сторон должно быть достигнуто соглашение. При этом договор считается заключенным, если между сторонами, в требуемой в подлежащих случаях форме, достигнуто соглашение по всем его существенным условиям.

По договору подряда на выполнение проектных и изыскательских работ подрядчик (проектировщик, изыскатель) обязуется по заданию заказчика разработать техническую документацию и (или) выполнить изыскательские работы, а заказчик обязуется принять и оплатить их результат (ст. 758 ГК РФ). Заказчик обязан передать подрядчику задание на проектирование, а также иные исходные данные, необходимые для составления технической документации. Задание на выполнение проектных работ может быть по поручению заказчика подготовлено подрядчиком. В этом случае задание становится обязательным для сторон с момента его утверждения заказчиком (п. 1 ст. 759 ГК РФ).

Как видим, задание на проектирование прямо названо в законе в качестве обязательной составляющей договора на выполнение проектных и изыскательских работ, фактически определяющей содержание работ по договору, то есть его предмет. Соответственно, задание на проектирование должно быть отнесено к существенным условиям договора подряда на выполнение проектных и изыскательских работ, без которого этот договор не может считаться заключенным. На это неоднократно указывалось в судебной практике (смотрите, например, постановления Восьмого арбитражного апелляционного суда от 21 апреля 2010 г. N 08АП-9424/2009, ФАС Уральского округа от 2 февраля 2011 г. N Ф09-10970/10-С2, ФАС Поволжского округа от 14 сентября 2009 г. N А12-2940/2009, ФАС Волго-Вятского округа от 20 октября 2010 г. по делу N А43-5669/2009, ФАС Западно-Сибирского округа от 5 мая 2010 г. по делу N А46-6441/2009, ФАС Центрального округа от 30 июля 2010 г. по делу N А23-2371/09Г-6-140).

Отметим, что в судебной практике встречаются и другие мнения. В частности, Федеральный арбитражный суд Восточно-Сибирского округа в постановлении от 18 ноября 2009 г. N А58-2694/09 со ссылкой на п. 1 ст. 759 ГК РФ указал, что задание может выдаваться в ходе исполнения договора и не является существенным условием для оценки судом заключенности договора на выполнение проектных и изыскательских работ. Однако, по мнению многих специалистов, “разработка подрядчиком задания на проектирование не охватывается рассматриваемым договором, а осуществляется на основании специального соглашения, заключаемого между заказчиком и подрядчиком”, то есть фактически отдельного договора (смотрите комментарий к п. 1 ст. 759 ГК РФ в книге “Абрамова Е.Н., Аверченко Н.Н., Арсланов К. М. [и др.] Комментарии к Гражданскому Кодексу Российской Федерации. Часть вторая: учебно-практический комментарий (под ред. Сергеева А.П.)”. – М.: “Проспект”, 2010.).

Кроме того, некоторые суды считают возможным не считать задание на проектирование существенным условием договора на выполнение проектных и изыскательских работ, ссылаясь на п. 5 Информационного письма Президиума ВАС РФ от 24 января 2000 г. N 51 “Обзор практики разрешения споров по договору строительного подряда”, в котором разъяснено, что отсутствие утвержденной в установленном порядке технической документации не является безусловным основанием для признания договора строительного подряда незаключенным (смотрите, к примеру, постановления Восьмого арбитражного апелляционного суда от 25 ноября 2009 г. N 08АП-7414/2009, ФАС Уральского округа от 19 сентября 2011 г. N Ф09-2048/11). Однако, по нашему мнению, данное разъяснение не может быть применено в данном случае не напрямую, поскольку речь идет разных видах договора подряда, ни по аналогии. Дело в том, что согласно п. 1 ст. 743 ГК РФ подрядчик обязан осуществлять строительство и связанные с ним работы в соответствии с технической документацией, определяющей объем, содержание работ и другие предъявляемые к ним требования. Техническая документация, как следует из ст. 758 ГК РФ, разрабатывается именно по договору на выполнение проектных работ, то есть оборот “техническая документация” является эквивалентом оборота “проектная документация”. К проектной же документации законодательство предъявляет определенные требования (смотрите, например, ч. 12 ст. 48 Градостроительного кодекса РФ), она представляет собой совокупность документов, включая чертежи и расчеты, а потому (просто по техническим причинам) и должна представляться отдельно. Вместе с тем понятие строительства довольно широко и включает в себя создание и таких объектов, для создания которых подготовка проектной документации не обязательно, на что и указал Президиум ВАС РФ в упомянутом обзоре. К заданию же на проектирование законодательство никаких требований не предъявляет, соответственно, если договор на выполнение проектных и изыскательских работ содержит условия, позволяющие определить требования заказчика к результату проектирования, такие условия сами по себе могут считаться надлежаще предоставленным заданием на проектирование. В противном случае предмет договора на выполнение проектных и изыскательских работ в любом случае следует считать несогласованным. Более того, такой договор может быть признан незаключенным, даже если некий документ под названием “(техническое) задание на проектирование” был передан, но его содержание не позволяет определить требования к работам. В связи с этим можно отметить, что в приведенных выше случаях суды указывали, что предмет договора согласован в его тексте.

Что делать, если в документах закупки разные условия?

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

На этапе подачи заявки

Разночтения в документах закупки и извещении

Идеальный вариант — заранее внимательно прочитать все документы, которые прилагаются к закупке: извещение, техническое задание, проект контракта, инструкцию по заполнению заявки, обоснование НМЦ и т.д. Например, разночтения могут быть такими:

  • В извещении установлено, что закупка только для СМП по 30 ст. 44-ФЗ, а по документации — закупка на общих основаниях.
  • В извещении указан один срок подачи заявок, а в документах — другой.
  • В ТЗ единицы товары — штуки, а в контракте — упаковки.
  • В документах срок оплаты — 30 дней, а в проекте контракта — 240 дней.

Разночтения часто возникают из-за того, что заказчик просто ошибается, копируя условия одной закупки в другую. Обнаружив несоответствия, отправляйте запрос на разъяснения. На официальный запрос заказчик должен ответить в установленный законом срок и внести изменения в документацию. Если времени до окончания подачи заявок останется мало, то срок подачи заявок продлят.

Если не успели в срок, установленный для подачи запроса на разъяснения, остается обращаться в ФАС.

Разночтения в техзадании и разъяснениях заказчика

Как быть, если заказчик согласился с доводами участника в запросе на разъяснения, но ничего не изменил в документах закупки? В ФАС по этому вопросу сложилась однозначная практика: заказчик обязан внести изменения в документацию и продлить срок подачи заявок, иначе он нарушит закон. Даже если в инструкции по заполнению заявки есть фраза «В случае разночтения между данными, указанными в разъяснениях, и данными, указанными в техническом задании, участники должны руководствоваться данными, указанными в техзадании».

Вот одно из решений ФАС в пользу участника закупки.

На этапе подписания контракта

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

Читать еще:  Какой порядок оформления сведений о доходах госслужащего?

Присланный на подписание контракт не соответствует проекту контракта

Например, в проекте контракта из документов закупки срок поставки товара составляет 30 календарных дней, а в присланном на подписание документе он сократился до 20 дней. Давайте посмотрим, как могут развиваться события.

  1. Заказчик исправляет ошибку. Если это электронный аукцион, отправьте заказчику протокол разногласий. Дождитесь от него исправленный контракт, проверьте, что он соответствует проекту, и только после этого подписывайте.
  2. Заказчик отказывается вносить изменения. Заказчик говорит, что у него изменились условия и просит вас пойти на встречу. Но даже если новые условия вас устраивают, не следует соглашаться на них, так как у такого решения могут быть негативные последствия. Если вы подпишите контракт, то другие участники, обнаружив несоответствия, смогут через суд отменить сделку. Если заказчик не исправляет контракт, не соответствующий проекту, рекомендуем обратиться с жалобой в ФАС.

Условия в проекте контракта отличаются от требований в документации

Например, поставщик выиграл электронный аукцион на поставку оборудования, которое по инструкции производителя не относится к технически сложному и не требует монтажа одновременно с поставкой. По техническому заданию заказчик закупал водонагреватели с определенными характеристиками, а условие о монтаже было только в проекте контракта, и участник закупки его не заметил. Рассмотрим, какие тут могут быть варианты.

  1. Исполнить контракт на предложенных условиях. В этом случае победитель потеряет часть прибыли, выполняя работы, которые не были заложены в предложенную им цену. Убрать монтаж из контракта протоколом разногласий нельзя, так как предмет закупки — это существенное условие контракта, которое нельзя менять.
  2. . Поставщик может только поставить товар, а заказчику нужен монтаж. Тут два сценария:
    • Если победитель не планирует выполнять монтаж, а заказчик — выставлять претензии поставщику, можно расторгнуть контракт по обоюдному согласию. В этом случае победитель не попадет в РНП, а заказчику придется проводить новую закупку.
    • Заказчик настаивает на выполнении всех условий контракта, а победитель не может их исполнить. В этом случае придется отказаться от подписания контракта. Это не лучший вариант развития событий, так как победитель потеряет обеспечение заявки и право участвовать в закупках на 2 года.
  3. Заказчику нужен только товар. Посмотрите, как описан объект закупки в плане-графике, найдите обоснование НМЦ в документах. В вашу пользу сыграет то, что в плане-графике нет условия о монтаже, а на этапе запроса рыночных цен просчитывали только поставку оборудования. Задайте вопрос заказчику, действительно ли нужен монтаж? Может получиться так, что внутреннему заказчику сейчас нужна только поставка, а составитель закупочной документации просто ошибся, скопировав в контракт условие о монтаже из другого контракта на поставку оборудования. Если заказчик согласен только на поставку и вы уверены, что он не передумает после подписания контракта, подписывайте контракт и исполняйте.

После подписания контракта

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

  • По соглашению сторон, но маловероятно, что заказчик на это согласится.
  • В одностороннем порядке, если такая возможность прописана в контракте. Будьте готовы, что заказчик обжалует ваше решение в суде, и вы его проиграете.
  • По решению суда с риском попасть в РНП. Как правило суд в этой ситуации оказывается на стороне заказчика.

Выводы:

  • Проверяйте все документы закупки «на берегу».
  • Если не заметили каких-то условий в проекте контракта в момент подачи заявок, выполняйте контракт или попробуйте договориться расторгнуть его по соглашению сторон.
  • Заказчик не может менять существенные условия контракта. Незаконное включение новые условий можно оспорить в ФАС или в арбитраже.

В следующей статье мы подробнее расскажем о том, в каких ситуациях заказчик может изменить цену контракта.

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

Что первично: ТЗ или договор?

Я бы не стал делить эти документы на первичный и вторичный. Т.к. они имеют «немного» разное назначение. Договор – юридический документ описывающий взаимоотношения заказчика и исполнителя, их обязанности и права. В том числе в нем может быть прописана в явном виде стоимость проекта. ТЗ – технический документ, описывающий проект. Хорошее ТЗ – это «больше половины» проекта.
Составление ТЗ – отдельная и достаточно затратная работа. И выполнять её без договора и, следовательно, гарантий как минимум просто глупо.

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

Хорошо написанный договор легко разрывает Ваш замкнутый круг.

dms: Спасибо, во многом вы ответили на мой вопрос. Однако, в отношении того, что “делать ТЗ надо до заключения договора, т.е на чисто джентельменских началах, веря, что пользователь потом эту работу оплатит”, согласен со Скляровым Иваном – не дело это. У меня был такой опыт, ничего хорошего из этого не вышло.

Скляров Иван:
– Вы считаете, что ТЗ не является юридическим документом?
– Если составление ТЗ – есть производство работ по договору, то ТЗ уже нельзя считать приложением к договору? Так ТЗ сотавляющая договора или два разных документа?
– Т.е. можно в договоре поставить ссылку на еще не сущесвующее ТЗ и сказать примерно следующее, что “сумма ТЗ = х, а сумма разработки = см. будущее ТЗ” (может я не так выразился, но смысл, я думаю, понятен). Я правильно понимаю?

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

ТЗ описывается как необходимая часть договора, которая составляется в процессе работ. Такое бывает достаточно часто. (Пример из обычной жизни: Договор на ремонт в квартире. Вы подписываете договор с компанией (понятно что предварительно, «на глазок» происходит оценка работы и ее стоимости), которая первым делом проводит точные замеры, оценивает объем материалов и учитывает Ваши пожелания. А затем составляется калькуляция необходимых материалов, план работ и т.д. Эти документы становятся неотъемлемой частью договора. Но составляются они в процессе выполнения работ по договору.) Я не говорю, что часто в договор вносят изменения, дополнения, которые оформляются как приложения и протоколы к договору.

Да, в договоре можно написать, что Исполнитель обязан в течении N-ти дней провести консультации с Заказчиком и подготовить подробное ТЗ на проект. Заказчик обязан участвовать в консультациях и утвердить предоставленное ТЗ в такой-то срок. Кроме того в договоре можно отразить процедуру согласования ТЗ, внесения изменений и дополнений в него и т.д.

Могу заметить, что ТЗ при разработке информационной системы или ПО это вообще чисто советское изобретение. Ну хочется иметь один (!) документ, описывающий все технические вопросы! Посмотрите на RUP. Ну нет там такого понятия как ТЗ. Всяческие vision, requirement plan и прочие use case.
Ну нельзя заложить даже после тщательнейшей проработки в один «линейный» документ по определению итеративный процесс.

Читать еще:  Как вернуть деньги за неотгруженный товар в данном случае?

Также хочу напомнить, что есть Feasibility Study (аналог нашего ТЭО), а также просто-напросто бизнес-план (иногда для сайтов это дело называют концепцией).

А то что у нашего родного заказчика отсутствует культура работы с подрядчиками, так то не новость :((((

Ну в общем-то достаточно оптимальным представляется процесс именно по RUPу :)) Когда Vision пишется как бы и бесплатно – как предложение как таковое. Где время и собственно деньги оцениваются весьма приблизительно. Точно оценивается только фаза Inception (ну может быть и Elaboration, если продукт небольшой . ). И составялется договор на проведение работ по этим фазам – т.е. создание проектной документации а-ля Software Development Plan. И уже на основании эти документов можно писать большой договор, на собственно правильную сумму. Если речь идет о суммах в 4 порядка – то только так ИМХО и можно как-то застраховать и себя, и заказчика.

ИМХО договор вообще может нести два варианта нагрузки – отчетность перед гос. органами как оснвоание для проведления работ (тогда это просто две бумажки с набором стандартных фраз и в общем-то без указания суммы). Или именно договор – большой и толстый документ с опианием кучи ньюансов типа поэтапной разбивки, порядка приемки работ, обработки запросов на изменения и т.д.

z. “Ну нельзя заложить даже после тщательнейшей проработки в один «линейный» документ по определению итеративный процесс.”

Т. е. вы имеете в виду, что в процессе производства этот документ может и должен модифицироваться. Тогда это уже не документ, а так, план, схема, при чем вполне условная. Я вас правильно понимаю, что ТЗ вообще может не иметь юридической силы?

Я согласен, что в процессе работы какие-то измения и модификации ТЗ неизбежны. В одном из форумов упоминался XP. Так вот, в методиках ХР четко говорится, что “изменения – есть основной принцип”. Но как это граммотно сформулировать в готовящейся для проекта документации (договоре, ТЗ или что-либо еще), чтобы избежать лишней бюрократии в процессе производства (т. е. чтобы не пришлось исправлять или составлять дополнения к договору из-за того, что заказчику за две недели до сдачи проекта вздумалось добавить какой-то значительный модуль или крупный раздел к сайту)?

Вообще, я не юрист :). То что ТЗ скорее всего будет модифицироваться – скорее всего факт. Но я не понимаю, почему из этого следует то, что оно не может иметь юридической силы. Есть стандартная область знания в project management – управление изменениями. Почитайте, скажем PMBOK или RUP, там все написано. Также, Вы правильно заметили, что лучше подписывать не само ТЗ, а некий регламент его разработки и изменения.

Да и вообще, насколько я знаю, это не проблема – есть типы договоров, не предполагающие упоминание о конечной сумме. В договор включаются расценки (могут быть почасовые (rate), могут на отдельные работы), а по завершению проекта составляется т.н. «протокол согласования цены». Вещь стандартная – посмотрите в юридической литературе.

Да, но не надо пытаться скрестить ужа с ежом – ничего хорошего не выйдет. Есть два существенно различных сценария.

  1. Сроки проекта директивные, т.е. жестко установлены клиентом и не допускают изменения (иначе штрафные санкции). В этом случае – никаких изменений ТЗ. Любые поползновения клиента по этому вопросу жестко посылаются (есть такой термин «бить клиента по рукам договором»). Для разработки сложного ПО этот сценарий применим плохо (см. выше про итеративность, RUP и т.д.).
  2. Сроки плавающие, или «мягкие». Тогда – пожалуйста, если прописана процедура внесения изменений в ТЗ все делается согласно этой процедуры. Тот самый Requirement Management.

>Ни один программист не исполнит качественно ни один проект, пока все детали этого проекта не будут согласованы с заказчиком в ТЗ.

Ой не факт, ой не факт. Это чистый “водопад”, а многие УСПЕШНО работают и по итеративной модели и вообще по XP.

Владимир Филитович:
На мой в таком подходе есть одно слабое место, которое в итоге может сыграть злую шутку. Достаточно часто клиент не может самостоятельно ответить даже на простые вопросы опрос-листов (причем причины могут быть разные: от полного непонимания специфики и терминов до сильно размытых задач, которые он хочет решать путем создания проекта). А уж если у него одна задача: «у Васи есть и чтобы у меня было» – то легко представить его ответы. Не трудно догадаться что может произойти, если представитель заказчика не сказал, что не понимает вопросов или не знает, как отвечать и заполнил все графы, а разработчик на этапе обработки ответов не почувствовал что-то неладное.

Для меня более привычен метод с привлечением специалиста, который эту самую техническую концепцию с заказчиком и напишет. Т.е. проведет необходимое количество интервью со всеми представителями заказчика, поговорит о целях сайта, практически сам найдет задачи, которые для компании может и должен решать проект … т.д.… согласует документ. А уже на основе технического проекта компании разработчику будет легко написать подробное техническое задание.

>пока все детали этого проекта не будут согласованы с заказчиком в ТЗ.

С увеличением сложность и трудоемкости проекта, вероятность подготовки ТЗ, в которое не придется вносить никаких изменений, резко падает. ТЗ – это не статичный документ.

Особенности составления технического задания на выполнение подрядных работ. Образец документа

Техническое задание – это вид документации, в котором заказчик определяет цель и задачи по ее достижению. Комплекс задач, описанный в техзадании, принимаемый к исполнению, оформляется договором между сторонами. ТЗ является неотъемлемым приложением, являющимся основой для контроля заказчиком объемов, выполненных исполнителем.

Правила оформления техзадания к договору подряда

В преамбуле указываются участники договора. Обязательно присутствуют:

  • место и дата заключения соглашений между сторонами;
  • полное наименование заказчика, юридический и фактический адреса, указывается, кто уполномочен заключать контракт со стороны заказчика;
  • полное наименование подрядчика, юридический и фактический адреса, указывается лицо, уполномоченное отвечать за исполнение подряда.

Основание для производственных действий

Основанием для производства работ являются:

  • договор между сторонами;
  • техническое задание с подробным описанием этапов выполнения.

Цель и исходные данные

Для реализации потребностей по договору подряда обе стороны согласуют исходные данные:

  • основание для разработки, с описанием исходного состояния объекта (при его наличии);
  • назначение разработки определяет набор функций, которыми должен обладать объект после выполнения работы (что такое выполненные работы?);
  • стадии и этапы работы разрабатываются с учетом реальных затрат времени, материально-технического снабжения и финансирования проекта.

Требования заказчика

В качестве исходных данных может представляться техническая документация в виде чертежей, а также ряда дополнительных требований:

  • требования по назначению создаваемого или модернизируемого объекта;
  • характеристики ремонтопригодности, надежность, противодействия к условиям эксплуатации или вредному влиянию среды, где предусматривается использование готового изделия;
  • перечень конструктивных особенностей, которыми должен обладать предмет договора;
  • соответствие определенным эргономическим предпочтениям, инженерной эстетике. При особых условиях весь объект или его узлы должны иметь патентную чистоту или быть защищены новыми патентами.
Читать еще:  Слоган для юридической фирмы перспектива

Требования подрядчика

Чтобы подрядчик мог выполнять работы согласно ТЗ, согласуются условия для качественного исполнения этапов договора:

  • сроки начала и окончания работ;
  • предоплата, аванс, этапы финансирования;
  • предоставление жилья для командируемых сотрудников (при наличии такого пункта в договоре между сторонами).

Обоснования

Технико-экономическое

Разные отрасли промышленности и агропромышленного производства пользуются своими стандартами для определения экономической эффективности. Для всех общими являются:

  • Себестоимость единицы производимого продукта (в случаях создания производственной модели). При сравнении показателей до и после выполнения работ выполняется расчет для обоих вариантов, потом их сравнивают между собой по всем позициям, входящим в состав этого показателя эффективности.
  • Капиталовложения на единицу характеристики, уточняются добавочные вложения на изменение свойств.
  • Производительность и затраты труда, энергии и иных затратных показателей.
  • Обобщенная экономическая эффективность.

Патентно-лицензионное (при необходимости его оформления)

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

Этапы проведения

Сроки начала и завершения этапов оговариваются при составлении техзадания. Их согласуют перед подписанием договора.

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

Приложения

Для понимания обоими участниками договора разрабатываются приложения, которые являются неотъемлемыми частями. Без них невозможно грамотно производить определенные виды деятельности.

В качестве приложений могут быть:

  • чертежи, в том числе рабочие, иная техническая документация;
  • требования, проработанные на этапе согласования;
  • ограничения по определенным временным показателям (производство работ в определенные часы), экологическим (минимум выброса вредных веществ, запыленности, шуму и вибрации) и др.

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Когда в условиях согласья нет…

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

Повод к размышлению дала следующая практическая ситуация: в разных частях государственного контракта стороны указали различный гарантийный срок на выполняемые работы – в пункте 6.3 было указано, что он составялет 95 дней, в пункте 15.2. Технического задания (Приложение № 1 к контракту) гарантийный срок на выполняемые работы составляет не менее 2-х лет. Заказчик обратился с иском о взыскании неустойки за просрочку в выполнении гарантийных обязательств по устранению дефектов, обнаруженных после истечения 95 дней после приемки работ. Иск был мотивирован тем, что гарантийный срок составляет два года, подрядчик, понятное дело, ссылался на то, что срок составляет 95 дней. Три инстанции отклонили иск, использовав довольно интересную мотивировку:

«Суд первой инстанции пришел к правильному выводу о том, что при таких противоречащих друг другу условиях следует применять то, которое менее ухудшает положение той стороны, к которой за обнаружение недостатков в пределах гарантийного срока предусмотрено применение мер ответственности. Такой вывод следует из общего принципа, в силу которого условие об ответственности, чтобы ее применение было возможным, должно быть ясно и четко выражено, не допускать неясностей в толковании, в т.ч. определенными должны быть обстоятельства, описывающие объективную сторону состава, влекущего ответственность» (Постановление Девятого Арбитражного Апелляционного суда от 05 декабря 2016 г. № А40-70490/2016).

Данный вывод был поддержан и Арбитражным судом Московского округа. Поиск по ключевым словам позволи найти абсолютно аналогичную формулировку в другом деле, рассмотренном Арбитражным судом Московского округа (см. Постановление Арбитражного суда Московского округа от 03 апреля 2017 г. № А40-200205/2015).

При правильном ответе на задачку, ее решение, предложенное судами по этому делу, не кажется оптимальным. Интутивно чувствуется заимствование из права публичного, в котором действительно неравенство участников правоотношений (сильное государство против слабого «частника») требует трактовать все сомнения в пользу последнего – видимо пройдя процесс дистилляции в голове одного из помощников судей девятой апелляции, писавшего постановление, оно обернулось «общим принципом». К гражданскому праву, которое, наоборот, устанавливает более низкие стандарты доказывания в случае привлечения к ответственности (необходимость нарушителю доказывать невиновность или другие обстоятельства, исключающие ответственность), эти публично-правовые пассажи имеют очень отдаленное отношение. Кроме того, метод толкования предложенный судами работает только при привлечении к ответственности – таким образом, одна и те же ситуация с противоречащими друг другу пунктами могут быть по разному разрешена судом: можно, например, предположить себе ситуацию, когда заказчик обратился бы в суд не за неустойкой, а с требованием обязать подрядчика выполнить работы по устранению недостатков.

И все же ответ, как уже было сказано, является правильным – договор был заключен в порядке определенном Федеральным законом № 94-ФЗ, подрядчик имел очень ограниченные и в основном негативные возможности влиять на формулировки соответствующего условия (см. Постановления ВАС РФ № 11535/13 от 28 января 2014 г., 5467/14 от 15 июля 2014 г.), а значит в силу пункта 11 Постановления Пленума ВАС РФ № 16 от 14 марта 2014 г. «О свободе договора и ее пределах» в случае неясности условий договора и невозможности установить действительную общую волю сторон с учетом цели договора должно осуществляться в пользу контрагента стороны, которая подготовила проект договора либо предложила формулировку соответствующего условия. Ключевой прецедент на эту тему сформулировал сам же ВАС РФ – см. его Постаноление N 2504/14 от 10 июня 2014 г.

Итак, принцип толкования contra proferentem, в том виде, в котором он закреплен в разъяснениях ВАС РФ, позволяет разрешить коллизии договорных условий в тех случаях, когда известно авторство проекта договора (а также в случае, когда оно предполагается в ситуации с неравными договорными возможностями у сторон). Как быть, если в договор заключен между сторонами с равными договорными возможностями и авторство условия неизвестно? Предположим что в нашем случае договор был заключен не по 94-му федеральному закону – какова установленная им продолжительность гарантийного срока?

Анализ судебной практики позволяет сделать вывод, что в таких случаях суд считают условие несогласованным (см. Постановление Арбитражного суда Северо-Кавказского округа от 13 июля 2015 г. по делу N А53-29739/2014; Постановление Арбитражного суда Московского округа от 27 июня 2016 г. по делу N А40-148495/15; Постановление Федерального Арбитражного суда Поволжского округа от 27 сентября 2013 г. по делу N А65-3832/2013). Что представляется вполне логичным, если с действительная общая воля сторон с учетом цели договора не может быть выявлена с помощью инструментов перечисленных в ст. 431 ГК РФ, или если стороны не установили приоритет того или иного условия, над иными (положений договора над его приложениями, или положений одного из разделов над иными частями договора) в случае наличия противоречий. Давать возможность судам осуществлять восполнительное толкование, определяя гипотетическую волю сторон в таком случае, было бы серьезным вмешательством в принцип автономии воли сторон – получалось, что один суд решал бы то, что не смогли решить два бизнесмена.

Ссылка на основную публикацию
×
×
Adblock
detector