Здравствуйте!

Заключили договор с подрядчиком на доработку типовой конфигурации 1С.
В техническом задании было просто сказано:
- разработать документ "Новый документ"
- описано назначение документа и его функции
- перечислены реквизиты документа
- перечислены реквизиты табличной части.

Нужно ли в тех-задании явно перечислять все типовые механизмы (которые используются в типовых документах), и которые должны работать в этом нашем новом документе?

Нам нужно, чтобы в этом документе работало:
- формат номера документа такой же как в типовых документах
- подсчет итоговой суммы по табличной части
- механизм цен и скидок
- механизм учета НДС (включен или не включен в цену)
- подбор из справочника номенклатуры
- авто-подстановка единиц измерения при выборе номенклатуры
- кнопка "Создать на основании"
- механизм разделения прав

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

Кто прав?
Какие типовые механизмы должны быть реализованы "по умолчанию" при создании новых документов?
А реализацию каких типовых механизмов нужно явно оговаривать в ТЗ?

Всегда конкретизируйте ТЗ. Или нанимайте подрядчика-телепата (3х от рынка).

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

(25) >> отступление от стандартного функционала.
Именно это должно быть прописано, если не надо.

Вы заблуждаетесь. В ТЗ описывают не какие-то там отклонения. В ТЗ описывают требования. Это принципиальный момент.

Кроме того понятие "стандартный" функционал - очень и очень растяжимое. Вы в силу недостаточно квалификации сами не понимаете отличия стандартного функционала платформы от стандартного функционала БСП (а ведь кроме БСП, например, в типовую бухню встроено еще по меньшей мере 11(!!!) библиотек - БиблиотекаИнтеграцииВЕТИС, БиблиотекаИнтеграцииГосИС, БиблиотекаИнтеграцииЕГАИС, БиблиотекаИнтеграцииМОТП, БиблиотекаПодключаемогоОборудования, БиблиотекаСистемыМаркировки, БиблиотекаТехнологииСервиса, БиблиотекаЭлектронныхДокументов, ИнтернетПоддержкаПользователей, РегламентированнаяОтчетность, УниверсальныйОбменСБанками). У каждой из этих библиотек может быть свой "стандартный" функционал, который можно связать с вашим документом.
А еще есть "стандартный" функционал для конкретной конфигурации.
А функционал типа "выводить итоги в табличных частях" - вообще не является стандартом. Где-то есть, где-то нету - как программист нарисовал, так и будет (если не оговорено специально).

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

Всё, что не оговорено в ТЗ, может быть реализовано на усмотрение исполнителя. Если исполнитель "перестарался" и сделал то, что его не просили, это повод для претензии со стороны заказчика. Так же верно и обратное - если исполнитель не реализовал какое-либо требование ТЗ или реализовал его не так, как оно описано, не согласовав предварительно с заказчиком, это тоже повод для претензии к исполнителю.

С ТС каши не сварить. Так окажется, что в требованиях было изменить печатную форму, а по факту нужно переделать расчет себестоимости. И кто виноват, что заказчик не знал/не смог объяснить?
Есть подозрение, что ТС выбирал по минимальной цене- минимальный функционал и получил.

Как бы ССЗБ

Даже не знал что копирование строк в типовых механизмах появилось. Я должен был это сделать если это не было указано в ТЗ?

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

(0) Подрядчик прав. Но конечно тоже молодец. Раз док делают уточнили бы что-куда он делает движения, и как им будут пользоваться.

ТЗ должно содержать четкое определение того что нужно выполнить. Любые формулировки которые можно истолковать по разному могут быть истолкованы по разному в конце.

Именно для "полного удовлетворения заказчика" всегда к рассчитанным часам прибавляю 50%. Даже когда точно знаешь, что "ну за 1 час сделаем по любому". Просто +50% и любые "мы не совсем так имели в виду" будут прикрыты. А если и сделал быстрее, и заказчик больше ничего не хочет, то воспринимаю эти +50% как премию за точный расчет трудозатрат. :)

Не надо экономить на постановке задачи. Как задачу поставили - так ее и сделали.

(0) однозначно! Просто спорные моменты всегда надо обговаривать. То есть подрядчик в данном конкретном случае обязан был спросить как мы делаем!

Когда есть ТЗ, тогда все, чего в нем не указано явно, разработчик делает или не делает на свое усмотрение.
Оно за тем и нужно - ТЗ это ваше.

Часто сталкиваюсь, что заказчики не знают как правильно реализовать ТЗ и предлагаю свое видение решения. А потом когда сделано, начинают включать голову и понимают, что надо немного по другому и забыли еще что-то учесть...

В данном случае за ТЗ не доделывать, ибо там конца края не будет.

(104) на сколько знаю у 1C табу трогать область ПрограммныйИнтерфейс - если используешь только эти методы, то ломаться не должно.

А ситуаций полно. У меня
1) В ТЗ было указано, что файл из которого надо загружать XLS, а оказался XML. Заказчик на пару букв ошибся, а трудоемкость в разы отличается
2) "Весь город знает, что я плачу за результат". Сделано по ТЗ, но себестоимость не считается как ему надо. Решилось малой  кровью - надо было в карточке номенклатуры галку поставить
3) В ТЗ указано "сделать произвольный отбор по реквзитам". На этапе сдачи оказывается, что подразумевалось (любое слово заказчиков), что произвольный отбор должен и по реквизатам ТЧ. Кто тут прав хз, но сделал

так