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

PS документ двигает остатки и взаиморасчеты,оригинал может быть получен в следующем году

есно такое надо выносить в РС

+1 заставлял переделывать наших внедренцев такое же исполнение

(0) исполнитель внутренний или внешний? Техзадание было ли и что в нем по этому поводу написано?

Если заказчик доволен - исполнитель прав.
А нет - так и нет

соглашусь с (3) - если не было ТЗ, то тут можно только кулаками махать

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

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

(0) да тут делов на полчаса, с перерывом на сон
гони его в шею вообще, без оплаты

(8) оценил в 3 часа

(8) (9) понимаю копейки, просто обидно что свои косяки за наш счет пытаються исправить.

(3) а в ТЗ надо описывать такие моменты? пользователь должен быть в курсе поведения платформы?

если разраб сделал "галку" на документе, пусть сам решает возможность записи документа без проведения и двигания границ последовательностей при изменении его "галки"

(6) А в задании было оговорено, что при получении оригинала в следующем году нельзя трогать закрытый период? Если нет - исполнитель волен выбирать метод реализации как ему удобно. И сейчас придется доплатить.

А если ни исполнитель, ни постановщик не заострили на этом внимания - тогда оба они ССЗБ и теперь стали чуть умнее.

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

(7) то есть, ТЗ не было. Все, что не описано в ТЗ явно, реализуется на усмотрение разработчика. Живите с этим.
Заказчик обязан громко, четко и непротиворечиво описать требуемое поведение. Если описание ограничивалось тем, что "хотим галку 'признак оригинала'", то вы получили то, что заказывали.

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

(15) ты забываешь о таком моменте. Разработчик догадается, что программа будет вести себя так (догадается заранее, ещё при постановке задачи или при начале работ). А заказчик (если он не спец в данной области) поймет это постфактум. Разработчик эту проблему не озвучил при постановке задачи, значит либо его квалификация низкая, либо он специально это сделал. В обоих случаях его нужно гнать в шею.

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

(17) в ТЗ надо было описать все существенные прецеденты использования галки. В частности - что устанавливаться она может на документы в закрытом периоде.
Если вы написали, что-то типа: "Должна быть возможность установить в документе признак оригинала" без уточнений про границу запрета, то вы получили, что хотели.

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

(0) Найдите опытного разработчика, а не связывайтесь с первым попавшимся. Любые доп. реквизиты документов, особенно для типовых конфигураций должны быть где угодно, но только не в самом документе. Это правило выстрадано кровью дополнительных неоплаченных часов.
(18) Разработчик ДОЛЖЕН ЗНАТЬ о том что период может быть закрыт, документ может быть НЕДОСТУПЕН для изменения тому пользователю, кто "ставит галочки", при ограничении прав пользователя. А вот заказчик не обязан знать тонкости. Его задача "нужен признак того что оригиналы документов получены". ВСЕ. И разработчик ИЗНАЧАЛЬНО должен объяснить заказчику почему это стоит 5000 рублей, а не 1500 за три часа работы.

(18) если речь о кодере то да, если работа доверяеться франчу по ставке 2500 в час, он обязан делать грамотно

(19) (20) это ваши фантазии. Стоимость часа франча ни чего вам не гарантирует и не добавляет франчу телепатических способностей.

заказчик обязан знать тонкости поведение, которое он хочет получить. Кроме него это знать некому. Можно пригласить за деньги бизнес-аналитика или консультанта, который что-то подскажет и расскажет, объяснит, чего в данной ситуации надо хотеть, а чего нет. Но, по скольку, работать в итоге надо заказчику, он в итоге и должен знать, как он хочет/будет работать. Перекладывать эту ответственность на плечи франча - глупость.

кроме закрытого периода есть еще и ПРАВА, банально оператор который получает первичку может не иметь прав на запись документа

В типовой БП 3.0 это сделано через регистр сведений

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

(21) телепатия не нужна, нужны знания и здравый разум! знания что последовательнось при переповедении нарушаеться, знания реалий жизни что доки при ходят не в момент создания документа (иначе галочка не нужна былабы) итд.

(14) А если при установки галки попутно удаляется движение это тоже заказчик виноват, что заранее не оговорил что можно, а что нельзя удалять?

(23) да там много палок может вылезти
Лефмихалыч хочет идеального заказчика :)

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

(28) Тем профессионал и отличается от овнокодера, что он заранее просчитывает последствия своих действий

(22) Ничего подобного. Заказчик дает задачу. Реализация задачи это компетенция разработчика. Компетенция разработчика зависит от его опыта. В (0) просто попался студент который опытом не обладает и сделал решение "в лоб". Реализация НЕ устраивает заказчика. Разработчик ОБЯЗАН переделать за свой счет. Т.к. его решение повлияло на поведение программы, причем в отрицательную сторону.
Пару раз разработчик на такие грабли наступит - начнет думать прежде чем мышой в кнфигураторе лазить.

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

(28) а откуда такая настойчивость в защите криворуких?
разраб своей галкой фактически сломал типовое поведение проги, навязав пользователю исправления в закрытом периоде (к примеру)

(32) сейчас Левмихайлыч тебе докажет, что разработчик не обязан знать всей тонкости работы программы, это обязанность заказчика знать и рассказать разработчику как нужно сделать, чтобы ничего не сломать

(25) когда говорят про опят, знания и здравый разум и прочую логику, это значит, что заказчик обосрался при составлении ТЗ или сборе требований.

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

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

об этом только догадывался Заказчик, и это надо было указать разрабу

(33) про работу программы заказчик ни чего может не знать. А вот про поведение, которое ему нужно, кроме заказчика ни кто не знает. Это называется бизнес-требования.

(32) я ни кого не защищаю - там криворукие с обеих сторон

(35) Прог же не эфимерную конфу правит. Все таки он должен знать как повлияют его измеенния на поведение программы.
Еще раз - разработчик ОБЯЗАН исправить СВОЙ косяк ЗА СВОЙ СЧЕТ!!!!
Потом будет умнее.

(38) ну, вот, автор именно так и думал, сложив с себя ответственность за результат. Типа программист обязан, он много денег просит, вот пусть сам и думает. Получил то, что в таких случаях всегда закономерно получается.

(0) Я думаю, что оба в чём-то неправы. Вы - в том, что приняли обычного кодера "могу копать-могу не копать" за полноценного разработчика, который может видеть дальше собственного кода. Про неправоту исполнителя выше расписали.

(0) Кстати, а как, дословно, выглядела постановка задачи?
"Добавить галочку в документ" или как-то иначе?

(38) и косяк, конечно, исправить обязан. Только сабж - не косяк. Во всяком случае автор не докажет ни чего.

(41)+ да, да, ТС покажи уже ТЗ

(42) Не докажет, но разраб потеряет одного клиента.

Нефига искать дешевых исполнителей. Дешево всегда порождает геморой.

(7) >>  заказчик не обязан знать.... а исполнитель должен ....

Чего ты гонишь то?!?!?!!!....
Вот сейчас же ты всё знаешь и всё понимаешь. А в тот момент ты видите ли не знал.... Чего девочкой то прикидываться? Так и скажи, что в тот момент было впадлу вдумываться в возможные последствия и оценивать риски.

Исполнитель конечно тоже дятел. О таких вещах должен был подумать. Но опять таки "должен" не означает "обязан".

ИМХО.
Если не было письменного ТЗ, то исполнитель - прав.
Если было письменное ТЗ, но в нём не описан напрямую метод реализации и/или не указано ограничение, что изменение этого флажка не должно вызывать перепроведение/перезапись документа, то исполнитель - прав.

В следующий раз будете умнее.

Ну и последнее - деньги. Добавить реквизит - это одни деньги. А сделать регистр - другие. Есть версия, что в случае если бы делали регистр изначально, то и денег бы за это могли попросить побольше.

(36) Ты в 1С случайно не работаешь? А то судя по коду типовых там исключительно такие же программисты её пишут, которые  "необязаны вникать в работу программы и делают задачу в лоб без проверок на права и всего остальное"

(47) не работаю. Ты или свой гениальный код покажи, или скукожь это всё

(38)т.е. ты хочешь сказать что прог видит ТЗ "добавить галочку", и начинает звонить заказчику и выяснять: "а зачем она вам, а вы точно уверены, а кто будет её ставить, а при каких обстоятельствах, а где это будет происходить, а почему именно так и еще сто тыщ питсот вопросов"

(49) Не прог, а консультант.

(50)так вот понятие не путаем
про консульта вообще не шла речь

(25) >> нужны знания и здравый разум!

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

А че в реквизите то не устраивает.
При изменении галки просто записываешь документ без проведения и все (ес-но надо убедиться, что документ не модифицирован)

(51) Ну, если я говорю "разработчик", то подразумеваю консультанта и программиста в одном лице.

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

(54) много будешь подразумевать, получишь не то, что ожидаешь

(49) ДА. Потому что это не игрушка для смарфона, а УЧЕТНАЯ система. Любое изменение в ее структуре влияет на ее функционал.
ПРОГ ОБЯЗАН понимать к чему приведут его изменения, и на что повлияют.
А вообще задача уже сто тысяч пятсот раз изъезжена. Ее даже на 7.7 делали через простые справочники.

(52) Заказчик виноват лишь в том что понадеялся на профессионализм исполнителя. А оказалось что исполнитель дилетант и не в состояние подумать о последствиях своих действие и предупредить заказчика

(54)так в том то и дело, что ожидания не всегда оправдываются

(59) По ходу до этого случая у ТСа всегда оправдывались.

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

(58) Бред. В ходе внедрения возникает 100500 ситуаций, которые не прикроешь отмазками про профессионализм исполнителя.

Это в этой ветке просто привели вполне очевидный пример.

(57)а откуда прогр может знать назначение этой галки
мошт её будут выставлять только один раз при создании, и всё
а вот заказчик должен был донести до него и зафиксировать это в том или ином виде

(60) или не было случая поработать с не штатными исполнителями. Подход, типа, "прог обязан знать всё" только для фикси прокатывает. Любой опыт работы со сторонними исполнителями эти иллюзии отшибает напрочь буквально за месяц-два.

Как обычно:
Хотели отслеживать поступление оригиналов + права + еще какая лабуда
А сказали: нужна галка.
А теперь претензии: ты не протелепатил

(62) мы же обсуждаем конкретную ситуацию, а не сферическое внедрение в вакууме

(65)вот-вот, ТС недоволен прокаченностью скила телепатии у разраба

сам сделал через реквизит. Можно было бы и РС, но тогда отборы не будут работать или рисовать свои формы, что геморнее. Запись происходит по кнопке, при этом используется ОбменДанными.Загрузка = Истина

(65) Ты себе это как представляешь? Поймали мальчика на улицы и спросили
- ты 1С знаешь?
- Да
- Нам нужна галка
- Ок.

Или все таки была предварительная договоренность зачем она и для чего

(0) берешь такой и говоришь ему, мол, галку в документе проставили, слетела последовательность. косяк? косяк! при внедрении новых механизмов не должны ломаться имеющиеся

(68) Отборы чего? И почему в типовой работает

(69) Так и представляю:
ТЗ
В документе ХХХ нужна галка отражающая наличие оригинала

(41) В документе должна быть предусмотрена возможность отражения факта получения оригиналов документов

(68)а вот это вот другая песня
разраб сделал не галку, а РС
и потом будет: а у нас отборы в списке не робят, и все отчеты нужно переписывать

(66) Конкретная ситуации - всего лишь частный случай.
На всех внедрения одно и то же: "Ой, а мы думали, что вы и так, без слов, всё поняли, ведь ну это же очевидно...."

А самый главный косяк, что все эти гнилые разговоры начинаются тогда, когда уже всё сделано.

(69) автор упорно игнорирует вопрос: "что было в ТЗ про галку", так что мы не знаем, как это было. Но, я уверен, что в ТЗ какая-то вариация на тему "добавьте галку и отойдите"

В УПП в платежном поручении отражение оплаты организовано галкой.

(73) ну, вот она и предусмотрена. То, что не выполнены требования, которые в ТЗ не описаны - это твоя проблема.

(70) Комментарий поменял - последовательность слетела

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

Или все таки был какой то руководитель проекта который провел переговоры и скинул ТЗ своему прогу?

(79) это тут при чем?

(80) ты видно никогда с удаленщиками не работал

(74) Какие отборы, можно пример о чем речь.
И да добавления функционала не должно влиять на текущий, или это тоже должно быть в ТЗ прописано?

(69) >> была предварительная договоренность зачем она и для чего

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

Такое встречается на каждом шагу. Договорились об одном,  а потом выясняется, мягко говоря, чуть-чуть другое.

(80) ну, вот это опять предположения на тему профессионализма, честности, непогрешимости и телепатических способностей исполнителя. Надеяться на это можно. Но в результате получается сабж.

Если в (73) дословное задание. Разработчик - студент, или тупой и жадный франч. При такой постановке понятно для чего нужен признак у документа.

(82) Ну я почти сам удаленщик. На работу приезжаю раз в месяц за зарплатой или когда скучно

(80) Ты это ТЗ видил или рассказываешь сейчас о сферических конях?

(87) С той стороны (заказчика) совсем все по другому )))

Все ветка просто констатация того факта что дешево - не значит качественно. Вот и все. Заказчик хотел дешево - получил. Разработчик ОБЯЗАН был знать подводные камни. Не предупредил, сделал "в лоб". Не прокатило - ИСПРАВЛЯЙ БЕСПЛАТНО. Потом будет умнее.

(88) Ну так а чем моя фантазия хуже/лучше вашей про ТЗ. Тоже имеет право на жизнь.

(87) ты штатник, который работает из дома. Это другое. Здесь под удаленщиком понимается исполнитель по подрядному договору, когда он делает то и так, как в ТЗ написано. Потому, что деньги получает только тогда, когда результат соответствует написанному. И, соответственно, если ты ему что-то не написал в документе, то он это и не делает потому, что за это ты ему не платишь.

(89) НУ мне проще, у меня есть для переговоров специальный человек который слушает хочу и с ним мы уже обсуждаем моё могу

(90) да даже дорого не значит качественно. Качественно получается, когда ответственность за качество несут обе стороны. Здесь же заказчик с себя ответственность сложил.

Потом оба будут умнее. Заказчик поймет что дешево не бывает. Исполнитель поймет что нужно сначала думать и обсуждать, даже такую простую задачу, а только потом делать.

(76) копипастю "В документе должна быть предусмотрена возможность отражения факта получения оригиналов документов"

поддержу ораторов, которые кричат, что исполнитель мyд@к, независимо от наличия и содержания ТЗ.
- 3 часа за галку это наглость.
- галка, которая не учитывает типовые механизмы работы с закрытыми периодами и последовательностями, это тупость.

гнать, хоть это и типичный (тупой и жадный) одинэсник

(96) да, я видел, ты уже писал. Галка в документе - это как раз такая возможность. То, что ты думал, что исполнитель догадается вынести ее в регистр - это твоя проблема

(90) Дорого не значит качественно - согласен. Но если стоимость не обосновывается, а берет с потолка.

не думал я, что ветка до (100) доживет

(96) Все просто:
Как ты отнесся к написанию тз, так и прог отнесся к его выполнению

(98) Он не должен был думать. Думать должен был исполнитель.

(101) задачу ставили Франю, крупному, а не прогу, кого он будет привлекать это его дело.
Прикол будет если исполнитель сидит и данный пост читает)))

(96) С такой формулировкой можно вообще ничего не разрабатывать, а сказать "Вносите эту информацию в поле комментария".

(102) это экстремизм какой-то

+(104) оплатите 1 час за консультацию :)

(71) отборы в списке
в какой типовой?
в той же БП 2.0 делал через доп. реквизиты и свои формы

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

"Без внятного ТЗ - результат ХЗ" (с) Поговорка.

Всё правильно исполнитель сделал.

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

(103) Блин, а сами что не в состоянии? Задачка то детская.

(108) т.е. есть открывать закрытый период и перезакрывать год после получения документа это нормально, да?

(103) А претензия из (0) адресуется самому разработчику или его начальнику? Раз это "крупный франч", то подобного рода ситуации должны разруливаться с их стороны РП или руководителем отдела, имхо.

(110) ну собственно такой исполнитель посылается и больше не приглашается. а так да, не обязан.

(103) Теперь понятно почему такая реализация. Сотрудник франча даже не вникал в задачу, просто "спустил" Вашу постановку стажеру, который 1С в глаза пару месяцев назад увидел.

(97) ...- 3 часа за галку это наглость...
1. Обсуждение. Формулировка задания. Определение слабых мест, поиск путей устранения.
2. Внесение изменений в тестовую конфигурацию, суть:
  2.1. Реквизит
  2.2. Добавление реквизита на форму документа (это, конечно неправильно или в режиме только просмотр)
  2.3. Добавление реквизита на форму списка.
  2.4. Добавление функционала, который позволит изменять реквизит без перепроведения документа (например, кнопка на форме списка). Учесть, что документ может находится в закрытом периоде.
  2.5. Тестирование под администратором
  2.6. Тестирование под пользователем
3. Подготовить рабочую базу к внесению изменений (выгнать пользователей, создать копию)
4. Перенос функционала на рабочую конфигурацию. Обновление рабочей конфигурации
5. Сдача работ заказчику.

Вы уложитесь в три часа? Наверное с трудом.

2.4. Добавление функционала, который позволит изменять реквизит без перепроведения документа (например, кнопка на форме списка). Учесть, что документ может находится в закрытом периоде.

дык весь сыр-бор из-за того, что, кроме "галки" из твоего списка нифига не сделали
да и обновлением из хранилища поди фикси занимался

(116) И что из этого было при решении задачи из (0)?
Три часа, в данном случае - наглость.

(116) это фантазии, не имеющие ничего общего с реальной работой во франче.
я могу и на 5 часов растянуть с бэкапами и тестированием, только кто мне лист учёта на 5 часов подпишет?

У меня для таких задач как в (0) уже болванки имеются. И список вопросов, ответы на которых занимают 10-15 минут. После чего, максимум что было, это за 12 часов интеграция "болванки" в конфу заказчика. Если брать усредненно, то на реализацию задачи уходит, в среднем, около пяти часов.

(114) у тебя большой опыт работы с нештатными программерами? Или франчами?

(117) удали этот пункт, все равно за 3 часа без вариантов

автор, смотри, вот чел за копейки готов твои хотелки телепатировать (118). Не пропинай свой шанс.

(121) да, я за ними переделываю обычно.

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

(117) Акт не подписывать. Функционал не работает как нужно.

(118) Так добавлять нужно не галку, а функционал. Давайте я буду ходить по клиентам и предлагать добавить галки в документы и справочники. Зачем? -Чтоб была!

(119) Я фикс. Подобную задачу решал в январе. Там, правда не галка была, но не суть. Перечень действий помню)) Где-то полдня у меня заняла. Я ещё описание писал и короткую инструкцию.

(125) то есть из тебя плохая ванга

(126) >Акт не подписывать. Функционал не работает как нужно.
дальше будет суд, который нагибнет заказчика

> Подобную задачу решал в январе
о том и речь, что фикси и франчи по-разному работают и вот этой разницы автор не понимает

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

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

(129) штатный разработчик вам дешевле обойдется

(129) т.е. он сам, без ТЗ должен был догадаться, какие регистры вам нужны? И наверное, всё за "тарелку супа"?

(132) он должен знать как работаю регистры в УПП

(128) Не обязательно нагнёт. Всё зависит от того, что написано в договоре.

(128) Да, франч должен ставить часов 8. Дорога, уточнение, получение копии. Две подобные задачи не закроет - значит рабочий день должен закрыть.
Фикс, например, знает кто будет работу выполнять: под ним на копии и тестирует. У франча такого может не быть.

(129) в больших франях разброс уровня прогов колоссальный
Скорее всего к вам относятся по остаточному принципу

(125) Нифига не за копейки. Дороже. Но дам гарантию что будет работать годами. И изменения в форме будут выполнены так, что это всего одна строчка в форме документа. Ну и плюс документация для тех кто будет конфу дальше сопровождать и обновлять. А это, минимум пять часов. Так что, если бы я делал, то стоимость была бы, минимум 7 500.

(133) С какого перепуга? А если бы он добавил движения по регистрам, которых не было в ТЗ, вы бы сказали, что "этого нет в ТЗ" - за это не заплатим?

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

(135) общая стоимость ТЗ 400 т. руб. по цене особо не торговались, согласились сразу

(0) Конечно, исполнитель неправ. И разговоры с ним вести не нужно, а сразу выходить на руководство отдела исполнителя, которому платите деньги 400 т.р., с вопросом, что за студентов вы нам присылаете.

(136) а ты уверен, что автор тебе оплатит время, потраченное на задавание вопросов о том, что ты с его точки зрения ОБЯЗАН знать? Мне почему-то кажется, что - нет. Ты, конечно, можешь заложить это время в разработку, но тогда на мисте появится ветка о том, какой ты окуевший товарищ, за галку просишь 16 часов.
И это будет уже не первая такая ветка автора: JOB: Кажется, нас нагибает франч, как поступить?

а, так это тот же самый франч, который ногибает...

(139) Тогда это не косяк программиста. Это косяк РП. Судя по всему задача из (0) - одно из требований ТЗ. Должен был работать, хотя бы постановщик задачи. Он и накосячил с постановкой задачи своем программеру.
ОБЯЗАНЫ ИСПРАВИТЬ за свой счет.

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

(141) Задача еще с 7.7 типовая. По ней есть список вопросов. Ответы на них или по почте или по телефону. Общее время на обсуждение по телефону, максимум занимает 15 минут. Далее объясняется что будет сделано. Кроме простого программирования и интеграции болванки заказчик предупреждается что обязательно  делается документация на внесенные изменения. За 10 лет работы отказались только двое. Один реально хотел почти за бесплатно, второй нашел дешевле, но через три месяца заплатил мне за переделку в два раза дороже.

(145) удачи

(142) Значит, всё-таки нагнул. Причём сделал это по-умному. :)

(146) Спасибо.

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

(147) дело было в сентябре, значит исполнителю еще пару месяцев мозг скребли, так что, я думаю, это тупо месть :)

(0) Конечно же РС. Более того практически наверняка когда-нибудь вместо признака получен оригинал, будет выбор из множества состояний. Получен документ-заместитель, получен скан документа, получено ещё чего-нибудь.

+(150) а может это такая хитрожопо размещенная вакансия? Тогда снимаю, натурально, шляпу - грамотно разыграно :)

(151) в одной из контор факт возврата фиксировался только для того чтобы знать - сразу связываться с клиентом и запрашивать недостающий акт или сначала пойти порыться в архиве.

(152) Не думаю. Видимо ещё есть люди, наивно полагающие, что специалист, которому они платят деньги, отдаётся им в рабство и должен чуть ли не ноги целовать за такое благодеяние, и при этом должен ещё и сам догадаться, что же от него хочет заказчик. Ну и переделывать бесплатно 100500 раз, если выяснится, что хотелки изменились.

(96) ичто в этом такого...

Можно к учету принимать без первички???? - правильны ответ нет нельзя...

документ вноси тогда, когда пришла первичка... ставь галку, потом перепроводи и будет счасье.
А то что учет - не соответсвует законодательству, об этом надо говорить...  Заказчик в (0) неправ...

(155) >> документ вноси тогда, когда пришла первичка
уа-ха-ха-ха

(155) >Можно к учету принимать без первички???? - правильны ответ нет нельзя...

Заказали иппинячий станок в китае. Со склада. Оплатили сегодня, соответственно станок наш уже сегодня. А первичка придет через месяц потому, что ее китайцы положили в контейнер, контейнер погрузили на корабль, которому еще доплыть надо.
Что делаем с принятияем к учеты исполненных обязательств?

+(157) но это к сабжу отношения не имеет

(149) )) Кстати, точно. А то следующая тема будет "прав ли программист, что сделал РС, а не установил реквизит"

Мой богатый опыт подсказывает мне, что через непродолжительное время, этот булевый реквизит документа потребуется превратить сначала в перечисление, а потом в ссылку на иерархический справочник статусов документа :)

(160) А потом еще захотят историю изменений статуса, с ФИО того кто изменил и причиной понижения статуса.... :-)

(161) и обо всем этом надо догадаться по словосочетанию "В документе должна быть предусмотрена возможность отражения факта получения оригиналов документов", используя логику и разум

(162) всегда можно уточнить

(163) ты оплачиваешь трудозатраты на уточнения?

(160) (161) Иерархия черезчур, конечно. Перечисления хватит.
Я запилил бизнес-процесс.

(164) когда объявляют ценник исполнитель должен закладываться в уточнения.

(0) а можно нам скан ТЗ?

(166) Кто оценивал и кто исполнял - это один и тот же человек?

както насмотревшись "Ревизорро" мне приснислся кошмар, к нам в офис франча пришёл проверяющий и бес спросу лез в наш код, и спрашивал "почему запросы в цикле", почему переменные плохо называются? почему коментарии не по стантартам 1С?

(168) незнаю мы общались через манагера (167) скан полного ТЗ не могу дать комерческая тайна (там засвецены контрагенты,организация итд)

(162) Обо всем нет. Но это и не нужно в контексте задачи описанной в (0). Пусть она даже и часть большого ТЗ. Но постановщик или РП, отвечающий за данное ТЗ, не должен был упустить уточнения. В данном ТЗ его часть реализована не корректно, т.к. подразумевает изменения документов в закрытом периоде или сотрудниками не имеющими прав на изменение этих документов. Это упущение ИСПОЛНИТЕЛЯ. А конкретно РП или постановщика.

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

(170) в паинте закрась

(171)а мож небыло в тз никаокй галки? может разработчик подарил, а вы не довольны?

(174)  "В документе должна быть предусмотрена возможность отражения факта получения оригиналов документов"

(175) дословно из ТЗ

(176) разработчик прав. закрываем тему

(177) НЕ прав. Но тему можно закрывать.

(177) почему? интересно а как ERP нард внедряет? сначало закасчик изучает регистры документы архетектуру пишет тз или всёже обращаються к франю и их РП или Консультант работает?

(175) Он предусмотрел? Да.
ТЗ выполнено? Да.
Какие ещё могут быть вопросы?

(180) в таком случае франь будет послан...

Так я не понял чем автора то вариант из (68) не устраивает?
такой например
v8: Проведение в закрытом периоде
пусть разраба заставит доделать чтоб галочку можно ставить и в закрытом периоде и без проведения.

(180) Он предусмотрел? Да
ТЗ выполнено? Нет
Почему? Потому что в закрытом периоде установка данного признака не возможна, т.к. форма документа открывается в режиме только просмотра.

Устроит?

(183)где этот пункт в из?

(183) Таки установка возможна.

(183) откройте период и поставок галку.
1с это разрешает.

(184) Этого пункта в ТЗ нет. НО это поведение конфигурации в которую вносятся изменения. Разработчик это ОБЯЗАН ЗНАТЬ. Он либо должен был предупредит об этом заказчика, и возможно увеличить стоимость разработки, или исключить данную формулировку из ТЗ. Исполнитель не предупредил. Значит или он НЕ ЗНАЛ об этом, либо это сделано умышленно. И тот и второй вариант говорит о НЕКОМПЕТЕНТНОСТИ исполнителя. А некомпетентность приводит к неправильной реализации требований ТЗ. Поэтому ЗАКАЗЧИК обязан исправить данный косяк. Тем более что его исправление не такое уж и сложное. Почему они лезут в бутылку и требуют дополнительных денег - вопрос не в рамках этой темы.
(186) Открытие периода и установка данной галки приведет к тому, что съедет последовательность БУ при проведении документа. РАЗРАБОТЧИК ОБЯЗАН ЭТО ЗНАТЬ. Далее - смотри то что описано выше.

Требование ТЗ из (0) реализовано НЕ ВЕРНО. ЭТО КОСЯК разработчика. Исправление - на его совести.

(186) и сделайте перепроведение документов начиная с даты изменяемого документа

ГБ после таких приключений вышибет нафик и разработчиков и тех, кто ТЗ рисовал. и будет прав(а)

(177) +100500

(187) (186) Одного понять не могу откуда вы взяли что документы перепроводить нужно после устанвки галки? Вы же реализации то не видели. но уже устроили срач.

(175) >> "В документе должна быть предусмотрена возможность отражения факта получения оригиналов документов"

И чем эта формулировка понятнее и лучше "сделайте чтоб всё было красиво"...

Тем кто защищает разработчика.
Для вас пример немного другого рода.
Вы покупаете машину. Ваши требования - машина должна иметь руль, что бы управлять направлением движения.
ОК. Купили машину. Крутим руль вправо - машина едет на лево.
Вопрос к продавцу почему так? Диалог:
Продавец: руль есть?
Покупатель: Есть.
Продавец: Крутится?
Покупатель: Крутиться.
Продавец: Машина меняет направление движения?
Покупатель: Меняет.
Продавец: Ну и в чем проблема?

(191) это было озвучено ТС где-то в начале. доработка документа, который участвует в последовательностях.

(186) Бред. Девочка звонит штатному IT-шнику, просит его открыть ей период - ставит галку, звонит просит закрыть период. Значительное увеличение трудозатрат.

Любой суд согласится, что это не автоматизация процесса.

(192) потому что в этой формулировке только "ОТРАЖЕНИЕ ФАКТА", но не "ИЗМЕНЕНИЕ" или "УСТАНОВКА/СНЯТИЕ". Если уж следовать букве ТЗ, то флажок должен быть не доступен для изменения. Т.к. он ОТРАЖАЕТ ФАКТ. Значит разработчик должен был реализовать, где-то в другом месте, возможность ИЗМЕНЕНИЯ факта. А поскольку это "типа трудоемко и дорого" ОБЯЗАН БЫЛ либо увеличить стоимость ТЗ, либо, согласовав с заказчикои, исключить данное требование из ТЗ. Исполнитель не выполнил требования ТЗ, не предупредил заказчика об изменении стоимости, не согласовал исключение данного требования из ТЗ. Реализация требования, в итоге выполнена НЕ ВЕРНО.
Значит исполнитель ОБЯЗАН за свой счет исправить свои недоработки, косяки, ошибки и т.п.

(193) Не так. Машина - штука стандартизованная.
Заказчик пришел в КБ и попросил атомный шнекоход, чтобы управлялся силой мысли водителя.
Только инженер КБ сделал, чтобы эта фигня поворачивала влево, когда водитель думает о бабах, а заказчик хотел, чтобы о мужиках.
В каком-нибудь ларьке решение из 0 прокатит; там все равно период не закрывают и постоянно в заднее число лезут, для них важнее экономия.

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

(188) почему нет? Это противоречит из?

(193)Не-не-не... Машина - штука стандартизированная. Заказчик попросил увеличить обороты и, соответствнно, точность руля. Меняем кардан руля и рейку у которых более мелкий шаг. Но разработчик кардан руля воткнул наоборот. Но в ТЗ ведь это не указано?
(196) Олень втройне - именно исполнитель. И на их месте, я бы не лез в бутылку, а просто немного переделал бы реализацию. Это не сложно.
В рамках любого объемного ТЗ возникает масса недоговоренных моментов. Все они успешно разрешаюся при приемке у заказчика без дополнительных финансовых затрат. В данном случае не идет разговор о том, что заказчик требует изменить логику проведения документа, или добавить дополнительные проводки и движения документа. Т.е. существенных отклонений от требований ТЗ нет. Но реализация исполнителем, возможна только при определенных условиях. Причем эти условия не доработка, а штатный функционал. Исполнитель должен был об этом знать, или признать что он НЕ ЗНАЕТ ШТАТНОГО функционала конфигурации. В обоих случаях - это проблема исполнителя.
Заказчик не обязан знать структуру хранения данных, логику и алгоритмы модулей. Это должен знать исполнитель. Перед реализацией ТЗ исполнитель должен понимать что он будет реализовывать. И если есть требования которые могут быть реализованы различными методами, и их реализация может существенно отличатся по стоимости, то об этом нужно предупреждать, и согласовывать изменения. В данном случае, ничего сделано не было. Исполнитель реализовал требование с ошибкой, поскольку реализация не учитывает штатное поведение программы в части распределения прав (ролей) и в части запрета на изменения данных по дате.

Не, ну если в договоре прописано, что еще отдел ИТ заказчика потом будет инспектировать код, тогда должны быть требования к коду от заказчика. А если нет - так что, потом любая уборщица будет доптребования выставлять?

А по самой задаче: на первый взгляд кажется, что надо делать регистр отдельный. с другой стороны - не будут работать стандартные отборы в отчетах и списках, надо будет переписывать.

и вообще тут тему можно еще дальше развить: как отражать неотфактуровку поставки? Ведь если нет накладных, тогда по налогу на прибыль не можем принимать затраты? А если они потом пришли в срок до закрытия, значит и в документе можно галку поставить, что накладные есть. Вобщем, тут может даже не на 3 часа, а на "подумать" задача.

(0) а свойства(допсведения) документа использовать запрещено? И не нужно вообще никаких доработок и перепроведений.

(200) "Но разработчик кардан руля воткнул наоборот"
Так бы было, если бы он движения документа менял, когда это не требовалось. Аналогия неверна.
"В рамках любого объемного ТЗ возникает масса недоговоренных моментов"
Вот я это и хотел спросить. Вряд ли ТЗ было из одного предложения. Ты предлагаешь не двигаться с мертвой точки, пока все не будет тщательнейше расписано? Или ТЗ умножать на 2, чтобы был бюджет такое по 20 раз переделывать?
"поскольку реализация не учитывает штатное поведение программы в части распределения прав (ролей) и в части запрета на изменения данных по дате"
Сумму документа в закрытом периоде поменять тоже нельзя. Пусть 1С исправляет! Нам это нужно.
Скажу свою мысль очень просто, чтоб понятно было: без знания того, как это заказчику нужно, обсуждать правильность реализации - нельзя никак. Может, они извращенцы и им нужно, чтобы в закрытом периоде этот признак не проставлялся. Или чтобы в зависимости от этого признака движения документа менялись. Или еще что. Поэтому исполнитель - однократный олень, что подписался под такое нечеткое ТЗ и не переспросил. А заказчик - олень трехкратный, потому как никто кроме него не знает, что ему нужно, а он не говорит, но требует сделать ему хорошо.

С удовольствием прочитал ветку. Давненько такой не было. Завтра из неё получилась бы отличная пятничная. Одно только заметил: в стартпосте ТС пишет совсем не про то, в чём у него на самом деле проблема. Если отвечать формально на заданный вопрос, то хранить этот статус в реквизите документа абсолютно нормально. Все проблемы с закрытым периодом, отсутствием прав на запись документа, нарушением последовательности решаются легко и просто - это уже тут упоминали. Просто ветка сама по себе отличный пример того, что ТС не умеет формулировать свои мысли. Поэтому и получил ту проблему, которую получил.

(166) объем которых предсказать невозможно и невозможно предсказать объем работ, который прибавится к твоему бестолковому тз по результатам этих уточнений? Тебя инопланетяне не похищали ни когда?

(204) Не согласен. Если ты не понимаешь что хочет заказчик, или реализация того что хочет заказчик может быть выполнена несколькими путями отличающимися трудоемкостью, ты будешь молчать? Или все таки уточнишь что имеется ввиду?
Я всегда либо уточняю, либо формализую это в ТЗ внося туда изменения. И заказчик, как правило, только рад от того что вносится ясность, потому что понимает что невыясненные и недоговоренные моменты могут вылиться в дальнейшие проблемы.
В данном случае, исполнитель, это упустил, и реализовал так как он это себе представлял. Теперь, когда на приемке исполнителю это явно указали, и просят переделать он отказывается мотивируя тем что нужно еще денег за это платить. С этим можно согласиться когда переделка потребует существенной модификации форм, алгоритмов поведения форм, алгоритмов проведения документов. Н в данной ситуации проблема не стоит выяденного яйца. Сложность реализации - низкая. Время реализации, максимум пять часов, учитывая время написания документации, и комментирования каждой строки кода. Но исполнитель встал "в позу". Вопрос почему? А что-то мне кажется что таких "мелочей" на приемке набраллсь не мало. А раз их не мало, значит исполнитель, скорее всего и не пытался вникнуть в суть ТЗ. Оценил на вскидку взяв стоимость с потолка, и не согласовав спорные требования. Что опять же говорит только о квалификации исполнителя. Короче заказчик - олень. Исполнитель - олень втройне. Потому что только исполнитель знает как устроена конфигурация внутри, и знает как себя поведут те или иные изменения. Заказчик НИКОГДА не сможет формализовать свои требования, именно по этому техническое задание всегда согласовывается обеими сторонами. В процессе согласования как раз и выявляются проблемные требования ТЗ, которые могут быть реализованы различными путями, и влиять на стоимость ТЗ. И выявление таких проблемных требований лежит на исполнителе.

(192) +1
вот самое лучшее ТЗ на все времена:
"1. Сделать всё.
2. Всё должно быть сделано хорошо.
3. Хорошо пользователю должно делаться само автоматически"

но только его можно отдавать исключительно тому разработчику, который ОБЯЗАН знать, который КОМПЕТЕНТЕН и с ОПЫТОМ. Такому, как Byasha, например. Или ТС.
Остальные не справятся.

(193) мы обсуждаем ПО, а не материальный объект, так что пример не адекватный. Тем более, что в ТЗ написано "машина должна обеспечивать возможность рулить рулём", так что "поворачиваешь вправо, она едет влево" - подходит.

(208). Это реализуется просто, одной кнопкой. Стоит 10.000 рублей без возврата денег вне зависимости от результата.
Делается внешняя обработка с одной кнопкой. При нажатии на кнопку выводятся сообщения:
"1. ВСЕ СДЕЛАНО"
"2. ВСЕ СДЕЛАНО ОТЛИЧНО"
"3. ВАМ ОЧЕНЬ ХОРОШО".

Все требования ТЗ выполнены.

(210) У меня не сварен кофе. П.1 из ТЗ не выполнен - в топку. Ты должен был уточнить и догадаться :)

(209) Именно, но заказчик ожидает что машина, при повороте руля поедет в ту сторону, в которую крутится руль. Исполнителю же было пофигу куда поедет машина, главное что бы она повернула. И когда исполнителя просят просто перевернуть деталь, которая отвечает за поворот колес, он упирается и уверяет что все нормально. Однако использовать машину по назначению не получиться.

Кофе вообще-то содержит кофеин, который влияет на мозговую и сердечную деятельность. Употребление кофия, в больших объемах, вредно для здоровья и зубов - они становятся темнее.
Условие выполнено, Вам даже подарок подарили - позаботились о Вашем здоровье.

(3) А что, если в техзадании не написано, что делать через жпо нельзя, то значит можно?

(212) заказчик может ожидать чего угодно. Более того, в момент формирования ТЗ и в момент приемки его ожидания могут быть разными. Это нормально. Не нормально требовать того, чего в ТЗ нет. Не нормально ожидать, что исполнитель обязан о чем-то там догадаться. Вот он попытался догадаться и догадался до реквизита в документе. То, что заказчик загадал другое - это проблема заказчика, а не исполнителя

(215) В данном случае сделано все через жопу. Исполнитель проявил свою тупость и квалификацию на уровне плинтуса. Не нужно специально оговаривать при доработке ПО, что доработка не должна рушить само ПО. Это подразумевается по-дефаулту.

(214) и еще раз для тех, кому лень читать: при подрядных условиях работы исполнитель получает деньги за то и только за то, что описано в ТЗ. Если исполнитель делает что-либо, что в ТЗ явно не написано, он делает это бесплатно. Бесплатно нормальные люди не работают, это надо понимать. Исполнитель может задать уточняющие вопросы - да, но делать это будет только, если эта работа будет оплачиваться, чего в данном случае нет - см (166), автор эту работу оплачивать не желает и хочет, чтобы стоимость разработки ее включала.
Нет ножек - нет варенья. В данном случае автору не стоило разработку у франча заказывать, т.к. с внешними исполнителями он явно работать не умеет и ожидает, что они будут себя вести точно так же, как внутренние. А это вредная иллюзия.

(213)

1) Цвет зубов со здоровьем связан только в воспалённом мозгу маркетологов.

2) Минимум чашку в день натурального кофе очень рекомендуется употреблять - кофеин стимулирует работу сердца и улучшает общее состояние кровеносной системы. Кроме того в кофе содержится большое количество антиоксидантов (http://ria.ru/science/20150508/1063313758.html). Так что не сварив мне чашечку кофе ты не сохранил моё здоровье, а наоборот - ухудшил его.

(212) В глубокой молодости играл в леталки на компьютерах. Помню, что в них была настройка типа vertical reverse - жмёшь стрелку вверх, самолет летит вниз - именно так функционирует физический штурвал в самолёте: от себя - вниз. А можно было сделать наоборот: стрелка вверх - вверх. Так вот переучивание занимало считанные минуты. Кстати, если не путаю, то аналогичные настройки есть и в том-же сталкере, когда мышкой управляешь прицелом.

(216) где ты там разрушения узрел?

(217) Ты случаем не в той конторе работаешь у которой 1С последние типовые на Такси заказывает. Очень похоже. Там тоже сделано все через одно место, видимо заказчик это не оговаривал.
(218)
1) Цвет зубов - состояние зубной эмали. Чем темнее - тем больше зубного камня. Здоровье зубов к организму не относится - поздравляю, возможно у Вас протезы.
2) Не-не-не, все подсчитано, утренняя чашка кофе за завтраком уже внесла свою лепту.
3) Вообще-то мы не об игрушках говорим, а об экономическом ПО. В игре тебя собьют - начнешь заново. На основе данных ПО вообще-то решения принимают.

(0) "1) Цвет зубов со здоровьем связан только в воспалённом мозгу маркетологов. "

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

(220) нет, я не в той конторе работаю

(0) А прикиниь, если бы он сделал через регистр, а ему претензия: "почему во всех списках и отчетах нельзя фильтрануть по нему автоматом?"

(223) А вот тут можно было бы смело ссылаться на ТЗ. Т.к. требования о фильтрации и выборке данных именно тех документов у которых установлен или нет признак наличия оригиналов - нет.
В (0) иная ситуация. В таких случая говорят что задача решена "на от...бись"

я думаю, что клиент тупо кинуть хочет. Я думаю, что в ТЗ было что то типа "переписать расчёт себестоимости и галочку контроля документа", расчёт переписали, но до галочки докапались, чтобы тупо не платить.

(224) Как поставлена задача,так и решена.В одном предложении.Надо было написать про "разработать подсистему учета получения оригиналов с учетом тра-ля-ля и тыды-туда".
Разработчик выполнил все формально.

(220) Вообще-то про игрушки я упоминал в контексте управления автомобилем в "неправильную" сторону. Непривычно, но переучиться можно.

(221) Налёт на зубах от кофе и рак желудка?.. Мы точно говорим об одном и том же?

(224) Опять двадцать пять, за рыбу деньги. В ТЗ говорилось что нужно обеспечить установку в закрытом периоде - нет, не говорилось. В ТЗ говорилось что по этому реквизиту нужен отбор, сортировка и вывод в отчёты - нет. Почему в первом случае нельзя ссылаться на ТЗ, а во втором можно?

(225) автор уже выкладывал цитату про галку: "В документе должна быть предусмотрена возможность отражения факта получения оригиналов документов".
(224) чем твое "а вот тут" отличается от исходной ситуации? Почему а вот тут можно к ТЗ апеллировать, а в исходной ситуации нельзя?

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

(229) почему возможность фильтрации - это повод апеллировать к ТЗ, а возможность устанавливать признак за границей запрета - не повод?

Потому что невозможность изменения признака "за границей" запрета - ШТАТНЫЙ ФУНКЦИОНАЛ конфигурации, которое исполнитель ОБЯЗАН учитывать при разработке, т.к. иное не оговорено в ТЗ.  Фильтрация - отдельное требование которое не оговорено в ТЗ, следовательно аппелировать к нему нельзя.

Мне вот интересно, а разработчики дополнительного функционала,  при реализации которого необходима выборка данных, используют в запросах конструкцию "РАЗРЕШЕННЫЕ"? Неужели, если это не оговорено в ТЗ, то предполагается что, даже если включен режим доступа на уровне записей, ВСЕ пользователи могут видеть ВСЕ данные?. Или все таки учитывается что доступ может быть как ограничен, так и нет.
Все таки это штатный функционал, который разработчик обязан учитывать.

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

Все не читал, но чем не устраивает реквизит документа?
В обычных формах самое то, в УФ можно и РС при желании сделать.

(231) во-первых, "ОБЯЗАН учитывать при разработке, т.к. иное не оговорено в ТЗ" - это твои фантазии. Исполнитель обязан только то, что в договоре и всех приложениях. Ну - плюс все, что в местных и федеральных законах. Всё. Больше ни чего не обязан.
во-вторых, оно реализовано реквизитом, по этому невозможность есть.
в-третьих, в ТЗ ни чего не сказано о том, должна быть возможность или не должна изменять это значение за границей запрета. Значит заказчику это не принципиально.

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

(233) когда автор писал размытую формулировку в ТЗ, он загадывал другое. Франч загадку не угадал. Автору печально.

(235) Печально автору, если акт подписан. А если нет, то печально исполнителю.

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

А разве низзя сделать что если вся разница только этот флажок то не перепроводить при записи?

Исполнитель не может знать всего, в (0) самый простой пример.
Заказчик сделал ТЗ, получил как в ТЗ, ему не понравилось, значит нужно делать второе ТЗ, дорабатывать систему, может быть опять что нибудь не понравится и т.д., обычная разработка.
Когда разрабатывают машины, заказчик ведь ставит такое ТЗ, хочу машину на 4 колесах чтобы ездила. Если будет такое ТЗ то стоимость такой машины будет 5тыр, любая коляска подойдет. Заказчик посмотри и скажет, я в подразумевал в длину 6м и салон из кожи крокодила, как у соседа. И что в этом случае, исполнитель должен за 5тыр ему БМВ с салоном из крокодила сделать.
Ни заказчик ни исполнитель не могут предусмотреть всех нюансов при реализации и если они не были описаны в ТЗ, то они реализуются за счет заказчика.
Какая разница закажет заказчик какого нибудь аналитика, который ему составит ТЗ или доплатит исполнителю за доработку.

+(237) а франчу печально потому, что это будет крайне геморройный, неприятный и в высшей степени стрёмный клиент, от которого тоже особо ни куда не деться без потер, как минимум, в карме

(237) В суде ни одного шанса у исполнителя :) Вообще ни одного. Он ничем не докажет факт выполнения работ.

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

(239) Заказчик не обладает должными навыками, чтобы написать ТЗ. Он озвучивает технические требования, на основании которых исполнитель составляет ТЗ.

(241) чой-та не докажет?

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

(241) но и обязать выполнять (переделывать) работу по такому ТЗ за ту оплату скорее всего не выйдет
только вернуть аванс и все

ну и исполнитель за потраченное время и фактически выполненную работу вполне может что то (не факт что больше копеек) "высудить"

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

(244) Да ни чой-та не докажет, если заказчик пойдет в отказку. Вообще. Не были работы выполнены и все тут. Без бумаги на одного шанса.

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

(231)

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

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

в. при добавлении реквизита можно сделать универсальную "устанавливалку", при этом все остальное не поломается.
т.е. это решение  в общем случае универсальнее.

г. вариант через "рс" уже существует в программе, через дополнительные сведения; раз задача поставлена - значит рс не устраивает

д. Как этот признак должен устанавливаться, интерфейс и т.п. - в исходной постановке задачи все это отсутствует

е. При решении задач есть стадии: выяснения требований, постановки задачи, разработки архитектуры, само решение, тестирование, сдача-приемка. Судя по всему - стадии 2 и 3 отсутствовали, и судя по  "за что тут 3 часа!" - заказчик явно желает, чтобы исполнитель сделал это за свой счет. Да, по мелочи так бывает часто. Но это неправильно в корне.

Вердикт. В данном случае исполнитель прав. Да, в данном случае ХОРОШИЙ исполнитель задал бы уточняющие вопросы, не допуская кривого/недоделанного решения" - но обязанности такой у него нет.

(248) по твоей логике можно вообще ни за какие работы ни платить, а на суде просто сказать "не помню, значит не было". Это наивно как-то

(245) тут не компетенция покупается, а геморрой.
нормальный исполнитель о таких вещах предупреждать должен.

(247) исполнитель не может нести ответственности за некомпетентность заказчика. У заказчика вон автор есть, который всё знает, но не говорит потому, что ждет, когда у него начнут вопросы уточняющие спрашивать.

Ладно. Я больше спорить не буду. Пусть каждый останется при своем мнении.
Я свое озвучил. Ситуация в (0) возникла по вине исполнителя, который, на этапе согласования ТЗ должен был это учесть.
Вопрос конфиденциальности данных и использования "РАЗРЕШЕННЫЕ" в запросах - это то что используется в типовых конфигурациях, и плевать на это, прикрываясь ТЗ - не допустимо.
Есть такая фраза "франчи, позор 1С" - вот это как раз и можно отнести к данному обсуждению в данной ветке. Нельзя подходить ко всем требования формально в рамках ТЗ. На процессе согласования, разработчик уже должен, хотя бы в общих чертах, понимать как это будет реализовано, как это может повлиять на существующий функционал системы, и как существующий функционал системы повлияет на реализацию требований. Это конечно затратно, и не всегда заказчик готов платить. Именно для этого и существует процедура согласования ТЗ. Да даже если бы на этапе реализации с заказчиком был бы оговорено то, что озвучено в (0), то этой ветки не было бы.
Сколько раз сталкивался с тем что разработка начинается по самому простому ТЗ, и в дальнейшем оно обрастает изменениями, дополнениями, естественно не за просто так. И в итоге заказчик получает то что ему изначально предлагалось, но он "испугался" суммы. После трех-четырех таких реализаций заказчик сам просит предложить ему несколько вариантов, и не всегда выбирает самый дешевый.
Вообщем, "франчи - позор 1С" (с).

(253) он нанят для того чтобы решить определённый круг задач, а не добавлять их

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

(245) У заказчика есть навыки озвучить бизнес-требования. Как их реализовать в рамках модели данных - выбор исполнителя. Заказчик не должен знать ничего о регистрах, последовательностях, типах данных и пр. мутотени.

Заказчик закрывает период редактирования штатными средствами, ставит галку и наезжает на исполнителя, т.к. его доработки перестают работать. И это не проблема заказчика. Это проблема тупого и жадного, который сделал через жпо.

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

(256) Нет тут никакой части ответственности. В данной ситуации априори буратино исполнитель. Все прозрачно и однозначно.

Понятно, что терки между пониманием задачи и способов ее решения тема вечная. Но не в этой ситуации - тут явно через жпо сделано.

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

(259) это оценочное мнение

(260) а ещё мне надо её устанавливать в любой день месяца, в любую погоду, и сидя, и лёжа и когда чай пью.
тз будет - загляденье.

когда есть договор, ТЗ и четко отсмеченный объем работ, ни о каких догадываниях речи быть не может

(262) если ты будешь это проверять при приемке - пиши

(258) Еще раз - заказчик не пишет ТЗ в 99,99% случаев. И он не озвучивал требование, что документ должен перепроводиться при установке галки - это уже ересь, придуманная исполнителем.

Его вина в том, что нанял криворуких студентов, т.к. любой толковый архитектор такие штатные грабли обходит легко на этапе проработки задачи.

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

(265) я где-то писал про перепроведение? Я писал, что надо было явно указать, как и когда значение будет меняться. Написали бы, что может измениться через полгода после регистрации документа, было бы реализовано корректно.

(267) Тем не менее у автора он перепроводится. Я не говорю уже о таких приятных моментах, что галки может ставить лицо, не имеющее прав на перепроведение документов вообще. Секретарь какой-нибудь.

(254) А Вы при составлении ТЗ всегда все учитываете, прям на все 100%?
Если так, то что Вы либо гений, либо делали очень мелкие проекты!

(268) как исполнитель может сам догадаться, кто у заказчика должен иметь права на это действие, а кто - нет? Ты правда ожидаешь, что заказчик догадается даже о наличии таких неявных требований на основании формулировки "В документе должна быть предусмотрена возможность отражения факта получения оригиналов документов"? Серьезно? Да даже, если бы он догадался, что это лучше бы в регистре хранить, как бы он решал вопрос, кому права дать, если в ТЗ об этом ни буквы?

(268) Если так, то заказчик должен был это указать в ТЗ, а у разраба при реализации эта не стыковка вылезла.

(269) вопрос точно к Byasha ?

А может заказчик еще подразумевал, что галка должна устанавливаться стандартной обработкой "групповое изменение справочников и документов" она же стандартная и если бы исполнитель сделал РС, то этот стандартный функционал не работал и заказчик бы матерился, что его опять не так поняли, он хотел галку, а ему забубенили РС и запросили 10 часов за это.

(269) Конечно не на 100%. Многое в процессе разработки вылазит. Только это оперативно с заказчиком согласуется, а не ждем когда нас носом на приемке ткнут.
Вообще любая неоднозначность в процессе реализации обсуждается с заказчиком. Есть уже набившие оскомину требования, типа как в (0), которые уже на этапе первого согласования ТЗ выявляются.

мне эта тема напоминает древний анекдот про "почему в шапке, почему без шапки"

(217) Ага нанимаешь ты бригаду обои поклеить, а они тебе поклеили такие обои, но забрызгали окна клеям, а в ванной вообще потом устроили и затопили соседей снизу. На вопрос какого хрена, они тебе. А где в ТЗ написано что окна должны оставаться чистыми и нельзя поток устраивать? Обои поклеины, задача выполнена - а все остальное не наши проблемы, надо было чётко оговаривать задание

(273) Не катит. Он не ставил задачу добавлять реквизит в документ. А значит и возможность группового изменения реквизита документа отпадает.

(274) Такие детские грабли даже до согласования не доходят. Это настолько очевидная с точки зрения архитектуры задача, что сходу в голову приходит единственное решение - РС. Более того, так же сходу приходит в голову хранение в нем даты получения оригинала и ответственного, который отразил эту операцию. Как и сходу приходит в голову форма для группового редактирования этого добра с различными отборами. По сути это уже выработанный шаблон, т.к. задача "типовая".

(276) это все порожняк потому, что разработка ПО и материальное производство несравнимы

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

(0) сам текст тз можно почитать? если там ничего именно тот текст, что ты привел - разраб прав..
зы.. сам бы, конечно, сперва выяснил все, что нужно..

(231) Разработчики типовых от 1Сникогда не используют слово разрешенные в своих конфигурациях. За последние полгода все изменения в которых добавлялся тот или иной запрос были без этого слово, в результате приходиться искать где и что добавили и доказывать им что они олени

(277) >Он не ставил задачу добавлять реквизит
ну, так и реализовать возможность установки признака без перепровдения он тоже не ставил, а значит и с регистром закономерно лососнул. Какие вопросы к исполнителю?

(280) копипастю "В документе должна быть предусмотрена возможность отражения факта получения оригиналов документов"
(с) Насколько правильно хранить признак получения оригиналов дока в реквизите док?

(281) А ты не новые конфигурации смотри. Оно вообще, судя по всему, после обкурки пишутся. Посмотри УПП, УТ 10.

(283) ну, формулировка на любителя.. Если исполнитель подойдет формально, то есть слово "документ". В документе он и поставил.
Если постановщик не специалист по 1С, то прога я бы послал нахород картошку копать.. Если постановку делал специалист по 1С, ну "Для документа предусмотреть возможность отражения факта получения оригинала документов" - уже по другому звучит)) и можно нагибать программиста))

+ к (284) А не используют, потому что сами уже не помнят какой .... шаблоны ограничений разработал. Если их начать использовать с базой данный вообще работать не возможно будет.

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

(208) как только это реализуется. У заказчика сократят весь ИТ отдел и  бухгалтерию, ибо на одну кнопку директор сам будет нажимать :)))

в (0) этого не понимают :)

(207) кстати, в данном случае правильно сделать - это именно существенная переделка, а не "выеденного яйцы"))

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

(289) Да нифига это не сложная переделка. Я уже говорил, на такие задачки как в (0) уже есть болванки, к со сложной реализацией, так и простые, через регистр сведений. Да даже если нет болванки, простая реализация делается часов за 5 максимум. Хотя если разработчик за галку в документе 3 часа озвучил....

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

(0) озвучьте пожалуйста
1. Кто писал ТЗ?
2. Чем не устраивает типовой регистр "Свойства объектов"???

Правильно понимаю что весь спор на почти 300 постов из-за незнания и неприменения BDD с Gherkin?

Согласно А ты правильно разрабатываешь на 1С?

(0) и еще как это должно работать... тоже надо сформулировать.
коллективный разум мисты поможет найти самое дешевое и быстрое решение.

есть простое правило проектирования бд : каждый чих - таблица. Обоснование правила: сущность-модель уже полностью описана в базовых таблицах. А все остальное - вспомогательные бизнес-процессы, которые могут быть , могут
и не быть. Правда мы тут "натыкаемся" на 128 битный FK - 1с ный guid .

(292) А кто сказал что нужно курочить код модулей? Все делается парой строчек в модулях нужных форм и один доп. общий  модуль. А регистр сведений можно и типовой использовать, тогда и типовые фильтры в отчетах работать будут.

(294) Вся ветка это спор о реализации задачи, дословно, "В документе должна быть предусмотрена возможность отражения факта получения оригиналов документов". Ну и еще выяснение кто именно олень, заказчик или исполнитель.

За почти 300 постов обсудили все: автора, исполнителя, варианты решения, правила архитектуры...

Кроме одного вопроса: ЗАЧЕМ? Что заказчик собирается делать с этим признаком?

И тут мы плавно подходим к возможным сценариям:
1) отобрать неполученные документы и наехать на ответственных
2) сформировать взаиморасчеты с отбором для сверки
3) отфильтровать задолженность по отсутствию оригиналов перед подготовкой писем о штрафных санкциях / судебных исках

ИМХО регистр сведений эти задачи не решит, несмотря на "правильную архитектуру" :) .

(298) >"В документе должна быть предусмотрена возможность отражения факта получения оригиналов документов"

Вот если только это в ТЗ то да, я бы галочку сделал в документе и все.
Если нужно что то еще то пишите что, тоже сделаю галочки ))

Понятно что можно подумать слегка о том как ставить эту галочку задним числом.
Но это никак не отменяет галочку.

Возможно прикрутил бы ко всем докам вообще некий аналог "дополнительных реквизитов и сведений". Причем с независимой записью от записи самого документа.
А так же сделал бы возможность фильтры/отборы/отчеты по этим "доп"

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

А можно скопипастить с типовых готовые процедуры

(300)+ но во 2-м случае сложном часов 20 бы вышло к оплате

(294) БДД тут не поможет. Потому чисто формально задача выполнина, и все "типовые" скрипты отработают на ура и без проблем

(299) Странно в типовой БП все эти задачи решаются через РС, а в самописки это же решение уже "задачи не решит"

(299) Единственно что я не увидел это какие претензии предъявляет заказчик

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

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

(303) БДД и полное описание как раз при правильном применении решит

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

(305) Именно что претензия насчет перепроведения и невозможности установки признака в закрытых периодах.

(306) Ну хоть кто-то со мной согласился :-)

(306) Еще раз зависит от вида претензии.
Мы можем 100 раз обговорить галочку при использовании БДД, но БДД не даст ответа на вопрос, а что будет если поставить её в закрытом периоде. Потому что человек, а не БДД должен задать этот вопрос. А раз он не был задан здесь, то и при БДД точно также такого вопроса не возникнет

(307) Я этого не увидел от ТС, это было просто предположения почему галочка это плохо. Но почему для заказчика это плохо ТС молчит.
Или это вы вместе с ТС попали в эту ситуацию и знаете что то чего не знаем мы?

(309) автотесты с попыткой поставить галочку в закрытом периоде как раз дадут ответ

(311) нет не дадут

(304) гм..

по порядку. со стороны ЗАКАЗЧИКА.

1. ХОЧУ отобрать неполученные документы...
с реквизитом: штатный отбор в форме списка средствами платформы
с р/с: надо написать доп. отчет

2. ХОЧУ посмотреть взаиморасчеты по невозвращенным документам - платил ли по ним клиент
с реквизитом: отбор в отчете по взаиморасчетам/ОСВ по 62 счету/... (какая конфа - уже упустил из виду)
с р/с: или писать отчет, или (если поддерживается в отчете) - отбор по свойствам (ШТАТНЫМ! ПИСАТЬ НЕ НАДО!)

3. ХОЧУ среди задолженности выделить долги по невозвращенным документам (например, красным)
с реквизитом: условное оформление
с р/с: ??? писать отчет?

И ?

Кто напишет этот автотест? Заказчик? Потому что у исполнителя в голове не щелкнуло и он не спросил у заказчика что делать в этой ситуации, и поэтому исполнитель не будет писать этот тест

(312) боюсь это мнение с которым не согласятся те кто правильные тесты пишут с "нормальным" покрытием

(314) а эти тесты должны быть уже давно написаны... еще когда решение ваялось ))

(313) Мы о чем говорим о типовой и как там это реализовано, или о самописки?

Штатно во всех отчетах в типовых есть привязка к регистру дополнительные сведения, т.е. штатные отчеты будут

(315) Так мы же говорим о ТС. У профессионалов и тесты давно написаны с нормальным покрытием и он задаст эти вопросы заказчику. Но здесь явно не такой случай.

Нормальный бы прог задал бы все эти вопросы заказчику и предусмотрел бы чтобы установка галки в закрытом периоде не вызывала бы перепроведения документа

(310) Ну, в принципе это можно понять и из "PS документ двигает остатки и взаиморасчеты,оригинал может быть получен в следующем году".

(319) Ну вот видите вы это понимаете, я это понимаю, а ТС не понимает и считает что выполнил задачу как хотел ТС. И Левмихайлыч говорит, что исполнитель не обязан вникать во всякие PS и быть телепатом

Вроде как PS, это не формулировка ТЗ. Формулировку ТЗ он сюда копипастил. Дополнение в (0) это и есть по сути претензия. Автор похоже уже столкнулся с тем, что у заблокированного по дате документа реквизит не изменить. На что ему, как я понял, предложили открыть период и перепровести документ.

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

В итоге тупик.

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

В итоге успешный проект это завсегда компромиссы и уступки с обоих сторон ко взаимной выгоде

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

Задачи аналогичные (0) делал кучу раз
Почти всегда это так или иначе было решение СИЮМИНУТНОЙ ХОТЕЛКИ заказчика и пофиг что такая хотелка могла быть даже в тз озвучена. От этого она не перестает быть сиюминутной хотелкой.

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

(322) Я бы добавил сюда природную лень программиста, который стремиться сделать как проще ему, и ему не хочется лишний раз спросить у себя, а как с этим будет работать заказчик, потому что он понимает что тогда придется весь его овнокод переписать и сделать по человечески, а ему лень это делать

4 страницы обсуждения, куда правильно писать один булев реквизит. Докатились.

(324)  просто сделать за час и сделать хорошо за час стоит совсем разных денег...

(325)  это тебе кажется что вce просто
Например мой собственный проект по внедрению вмс
Столкнулся с кучей проблем по решению некоторых задач
Часть из которых я даже не задумывался озвучивать на этапе техпроекта так как по моему разумению при решении этих задач дб автоматом учтены/реализованы свойства вмс которые дефакто являются основополагающими свойствами вмс. У внедренцев вообщем другое мнение по таким задачам.

(318) А не допускаешь ситуации, что прог нормальный, только заказчик этого прога заклевал придирками и некомпетентностью так, что прог устроил итальянскую забастовку?

Это тупо хранить в реквизите.
Оригинал придёт, когда период будет уже закрыт.
Чтобы изменить статус, придётся открывать период и перепроводить документ.

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

Исполнител не посчетал это нужным , а просто озвучил ценник, мы сказали Ок делай, подумов про себя "наверно ты уже много раз это делал,знаешь как надо, у тебе огромный опыт всеже ты супер пупер франч и денег не малых просишь"

В результате видем косяки, не додумки, глупые вопросы, в виде, а какие вы регистра хотите двигать при проводки на 41 счет ? или галочку в документ повесить.

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

(331) я этим ТЗ и хотелками не занимался вообще, попросили на этапе приёмки посмотреть как всё сделано.

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

(322) >В итоге успешный проект это завсегда компромиссы и уступки с обоих сторон ко взаимной выгоде

так бы и было, если бы заказчик не был тяжело болен иллюзией собственной исключительности. См (166) - заказчик ожидает, что заранее неизвестная стоимость работ по уточнениям и неизвестных добавочный объем будет заложен в цену заранее. И смотри предыдущую ветку автора, где он жалуется, что франч много денег просит. В данном случае заказчик почему-то думает, что 400 кусков - это такая сумма, за которую исполнитель обязан догадаться обо всем сам и работать, пока солнце не потухнет

(332) это все отмазки, если если есть отдельный бизнес аналитик. Задача бизнес-аналитика - подробно, структурированно и однозначно изложить требуемое поведение в ТЗ. Понятно, что идельным ТЗ ни когда не будет, см посты Злопчинского. Но в данном случае речь не об неидеальности ТЗ, а о банальной халатности БА.

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

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

(335) тебе просто повезло))) доказательная медицина, слышал про такое?

(337) Я слышал про репутацию и рекомендации. Поэтому обратился не к первым попавшимся, а нормальным мастерам, у которых график работы расписан на месяц-два вперед.

(331) тут вопрос кто у них и когда должен писать ТЗ и должен ли вообще
возможно БА у них в теме только бизнес-процессов и максимум что может сделать это сформулировать развёрнутые требования безотносительно архитектуры системы
в таком случае инициатива написания ТЗ исходит от технических специалистов исполнителя
не изошла инициатива - риски на исполнителе

(338) всё равно повезло. я на таких условиях работаю только с человеком, которого лично знаю больше десяти лет по разным объектам
кстати искренне рад за тебя

(339) >сформулировать развёрнутые требования безотносительно архитектуры системы
именно это от него и требовалось и именно этого он не сделал.
Его задача была подробно описать бизнес процесс учета оригиналов. Бизнес процесс ни как не описан, исполнитель считает, что нет ни какого бизнес процесса и нужна тупая галка, которую ставит, кто угодно, когда хочет. Потому, что КТО должен ее ставить и КОГДА - не описано.

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

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

очень правильная статья "Объясняем бизнесу, почему у нас такие «фиговые» оценки"
https://habrahabr.ru/post/210720/

там как раз разбирается пример подобной "простой" задачи.

(0) Откройте типовую ТиС и посмотрите, как там сделано: есть поля документов номер и даты входящие. При получении оригиналов - заполняйте эти поля. При заполнении этих полей - ГП и ТА не отъезжают. посмотрите и сделайте аналогично.

Срач развели... Ужас.

(345) есть еще типовой резистр "свойства объектов"
автор в  (0) молчит , что же ему надо...

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

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

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

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

(352) добавление признака - тоже стандартный проект, который подразумевает разработку с учётом типовых механизмов (это вообще делается при любых доработках), также как и установка унитаза подразумевает учёт законов физики и физиологических особенностей человека.

(352) Кстати, очень многие вешают унитазы именно на стену :))
http://www.amodena.ru/images/cms/thumbs/db57448d37d8d46bd4156c0d50e436df8b193c30/21_auto_900_jpg.jpg

(352) А могли и так
http://moskprf.ru/images/stories/nasha_rasha.jpg

нет, я в видел в ТЗ строчки вроде "доработки не должны нарушать работу типовых механизмов таких-то и таких-то", видимо их стали писать после таких косоруких исполнителей.

(0)Для себя интересно.
1)У вас такой большой опыт, как вы додумались обратиться к крупному франю внедрять проект?
2)Из проекта только с "полученными доками" косяк? В проекте вообще что-нибудь работает?
3)В роли кого вы работаете?

(323) "я бы тупо сделал галку в документе и возможность ее изменения без проведения документа" - и получил бы облом при изменении документа закрытого периода. Это вам не 7.7 :)

Нечего тут мусолить. Только топ проги сделали бы по данному заданию через РС. Кроме себя я вообще нигде невидел чтоб данное задание реализовывалось через РС, везде сделано тупо реквизитом и устный порядок проведения или перепроведения.
Для франя каждая минута на счету, поэтому лишнюю работу ради качества они делать не будут.

(359) >> Для франя каждая минута на счету, поэтому лишнюю работу ради качества они делать не будут.
а за деньги? :)

(353) "добавление признака - тоже стандартный проект"
Пффф. Нет.
Может быть полдесятка разных вариантов использования и соответственно разных реализаций.

(361) не надо выдёргивать из контекста, посыл был в том, что любая разработка должна вестись с учётом существующих механизмов.
унитазов тоже великое множество, и мест установки тоже. при этом почему-то не требуется уточнять, что не нужно ставить на потолок и что должна быть подключена вода и канализация.

Кторые тут - про стандартный проект и логику. Если бы вы увидели, как устроен процесс контроля получения оригиналов у нас, вы бы на пару дней потеряли аппетит и сон. Но наш процесс тоже можно описать фразой "В документе должна быть предусмотрена возможность отражения факта получения оригиналов документов".
Единственное место, откуда франч могу узнать, как на самом деле правильно должно быть, - это ТЗ. А в ТЗ нет ни чего. Эта фраза ни чем, как выше уже было отмечено, не отличается от "нормально делай - нормально будет".
В программировании не существует единственно правильного или в даже в общем-то правильного способа решения задач. Поскольку нет законов. Есть только соответствующие требованиям и не соответствующие требованиям. Ну, еще - привычные субъекту и не привычные, нравящиеся и не нравящиеся.

(357) +1
Реквизит или РС - какая разница как делать? Есть ли внятное ТЗ при таком подходе от заказчика? Нет? К чему тогда претензии? Никто ваших мыслей не читает. Например при наличии БСП в составе конфигурации вообще можно сделать через доп. реквизиты.

Вообще конечно на франч можно довануть следующим:
правило 1с: документы проводятся только оперативно и перепроводить их нельзя.
Франч должен учитывать стандарты программирования заданные 1с, т.к. он франч. Исполнение задания из (0) приводит к перепроведению документа - косяк.

+(366)И таким образом, исполнитель может сделать как хочет, но сам выйдет на то что надо будет сделать через РС :)

(366) В типовых "номер акта" в РТУ тоже реквизит

Или оплачено в платежке

(369)До установки галки оплачено, платежка не проводиться.

(364)"В программировании не существует единственно правильного или в даже в общем-то правильного способа решения задач."
В 1с существуют в общем-то правильного способы решения)

(366) ссылку на правило это можешь дать?

(372)Позвони в 1с и спроси почему при перепроведении доков задним числом не срабатывает контроль остатков и другие контроли? Тебе ответят...
Ну наверное можно поискать нормы программирования в 1с установленные 1с.

(371) нет. Есть просто свод рецептов, типа "остатки хранить в регистре остатков", но остатки отпусков мы все знаем, где хранятся, или "запросы в цикле - зло", но мы все знаем, что оно не абсолютное. И так далее. Законов типа сопромата или там каких-нибудь уравнений Лагранжа не существует в программировании.

(373) бремя доказательства лежит в данном случае на тебе. Где ты это правильно нашел?

(375)Можно затребовать ответ в письменном виде.

(376) просто приведи ссылку на сайт *.1c.ru или аффилированный, где это правило написано. ИЛи честно признайся, что ты это придумал.

(377)Ну я это не придумал, это ответ поддержки на перепроведение задним числом. Эта политика просматривается в типовых.
У франей же есть список норм программирования, надо у них поспрашивать.
А вообще в ролях пользователей как правило стоит только оперативное проведение, если в конфе (0) так заданы роли, то тоже можно сослаться, что перепровести можно только оперативно, но это изменит дату документа - косяк.

(378) короче нет правила

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

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

(381) даже, если предположить, что где-то в недрах ИТС такой стандарт есть, то обязанность следования ему возникает только тогда, когда ссылка на этот стандарт указана в разделе "требования к стандартизации и унификации". Нет раздела или ссылки в нем - сами себе буратины, идите в ЖПО с претензиями по этому поводу и там ищите причины, по которым БА это не написал.

Вот, кстати, "Требования к проведению документов"
http://its.1c.ru/db/v8std#content:2149184252:hdoc

2.2. Если жизненный цикл документа состоит из нескольких этапов, которые соответствуют этапам некоторого процесса, то для описания этих этапов у документа могут быть введены дополнительные статусы. Например, документ «Заказ клиента» может иметь статусы: «не согласован», «к обеспечению», «закрыт»; документ «Расходный кассовый ордер» – сначала зарегистрирован в журнале регистрации кассовых ордеров (КО-3), затем подписан главным бухгалтером (руководителем), передан в кассу, затем зарегистрирован в Кассовой книге, подписан главным бухгалтером (руководителем).

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

Если документ проведен, то при переводе документа между статусами пользователям может быть предложено дозаполнить определенные данные документа, к этим данным могут быть применены определенные проверки и ограничения бизнес-логики, специфичные для каждого этапа. До момента проведения, перевод «черновика» документа по статусам не контролируется системой.


шах и мат, регистрострадальцы.

(383)Мда...ну что тут можно сказать: разрабы 1с просто полные... В след раз буду знать чем мозг вынести тех поддержке)

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

(385)Ну если б разрабы писали по данным стандартам то мы бы не встречали в коде кучи таких писаний:

// Проверка остатков при оперативном проведении.
            Если РежимПроведения = РежимПроведенияДокумента.Оперативный Тогда
                Движения.ТоварыВРезервеНаСкладах.КонтрольОстатков(ЭтотОбъект, "Товары",         СтруктураШапкиДокумента, Отказ, Заголовок);
                Движения.ТоварыВРезервеНаСкладах.КонтрольОстатков(ЭтотОбъект, "ВозвратнаяТара", СтруктураШапкиДокумента, Отказ, Заголовок);
            КонецЕсли;

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

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

(387)Ну я ж исходил из других норм проведения, теперь то конечно получается что 1с-козлы, к франю сложно что-то предъявить)

(388)Т.е. ты одобряешь то что написал исполнитель из (0)?:)

(388) это ты уже придумываешь.
вопрос изначально был - должен разработчик (аналитик) учитывать существующие механизмы или если в ТЗ не написано - "чо хочу, то ворочу".

(390) я не оцениваю то, что написал исполнитель. Но я одобряю его позицию: "что хотели, то и получили. Хотите по-другому, - это отдельная работа"

(391) да ни фига. Вопрос был изначально: "Вопрос кто прав в данной ситуации?" Прочитай в (0), если мне не веришь.
Прав в данной ситуации франч, т.к. сделал все по ТЗ.

(393) да нифига...
и тут мы заходим на новый круг, а это уже не интересно

(393) Соглашусь.
Кстати, в (0): "хотите по другому платите бабки. "
А если хотелось и хорошо, и подешевле - результат вполне оправдан.

(392)Печально. Не по программистски:(

(396) 1С - не программирование, а конфигурирование и сопровождение.

(396) не по-программистски - позволять продавливать свои границы и позволять расширяьт задачу доптребованиями. Это приводит к работе бесплатно и потерям нервов и времени.

а ведь лет 8 назад я бы поддержал автора в его непонимании. Забавно, как время всё меняет...

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

А вообще банальная задача статусов. Как ее можно решать добавлением реквизита даже в голове не поворачивается (только ну в очень крайних ситуациях).

(400) в стандартах на ИТС написано - как. Но это к топику не относится

(397) Для кого как :)

(401)Да те могут что угодно написать, если б они норм писали не было бы нас)

(403) напиши сам нормально и продавай гениальные продукты.

(404)Некогда.

+(405)Или скажем никто не спонсирует)

(405) (406) потому, что идеальный код ни кому не уперся

(407)Ну пользователям очень уперся, но оплачивать разработку типовой конечно никто не хочет.

(329)
Ну вот мне в одной конторе объясняли так: пока нет подтверждающего документа, мы не можем принимать затраты к налоговому учету. И поэтому делают они так: в предыдущем периоде они отражают поступление услуг по статье на ПР, у документа устанавливают признак "Отсутствие документов". Если документ пришел до закрытия периода - перепроводят документ по НУ, флаг снимают. Если период закрыт - сторнируют его в текущем периоде, вводят новый по НУ.  Если этот признак у автора используется для этих целей, то вполне логично иметь реквизит документа, т.к. в закрытом периоде он не меняется.

(402) Уже обсуждали. Предлагаю - не начинать
(408) И вот подошли к ключевому: программа - для пользователя или пользователь - для программы...

(408) и пользователям не уперся. Ты же виндовсом, скайпом и прочим гуглом пользуешься? Вот и пользователи учетных системы тоже пользуются и им напофиг, какой там внутри код, если по скайпу можно позвонить, виндовсом можно прочитать почту, а УТшкой - оформить заказ.

(410)Ну должна быть программа для пользователя, но пока наоборот, помимо пользователя еще и программист нужен для программы.
(411)Если б УТешкой можно было оформить заказ, то мне бы не звонили, а сделайте нам вот это, чтоб мы учет в опу не загнали и вот это чтоб можно было хоть как-то с этим заказом работать, а то надо кучу отчетов перелопатить чтоб завести заказ.

(412) заказ - как раз можно. А вот туеву хучу всяких фантазий пользователей - нельзя. Но это к качеству ни какого касательства.

(412) Не-е... Ты не понял.
Программа - для пользователя: все хотелки пользователя, дружелюбный интерфейс, нормальная работа.
Хотелки пользователя - это именно хотелки пользователя, а не программиста или разрабов 1С.

(412) Про заказа - это случаем не УТ?

(414) т.е. в 1С должны быть реализованы все хотелки всех пользователей, в том числе взаимоисключаемые? И только тогда это будет хорошим продуктом?

(416) В случае с 1С - должна быть база (платформа + основной функционал) (стабильно работающие без глюков). Дальше уже пользователь будет реализовывать "хотелки": навешивать доп. функционал от 1С, дописывать и пр.

(417) >стабильно работающие без глюков
это очень точное и непротиворечивое требование, ага

(417) "стабильно работающие без глюков"
Ты понимаешь, что это невозможно? Не в случае 1С, а вообще любого ПО.
Максимум - нечасто падающие с минимумом глюков.

(418) Что тебя не устраивает?
(417) Нет. Не понимаю.

(420) субъективность

(420) "Нет. Не понимаю."

Ну, это уже давно ясно.

Если рассматривать программы сложнее "Hello, world!", то у стабильного софта без глюков и постоянно развивающегося есть один существенный недостаток - он не существует.

(420) Это грустно. Потому что реальность не изменится, понимаешь ли ты ее или нет. А тебе непонимание реальности может навредить.

(422) Тебе уже писала.
(423) Тебе напишу: это не реальность, это опыт. Который сформирован не только работой с программами 1С. И если для тебя это "реальность" - остается только посочувствовать.

(424) Я тебе тоже уже писал, что в твоем опыте есть большие сомнения.

(425) Это твоего личное и субъективное мнение :)

По поводу "постоянного развития" - да, ради Бога. Но не за счет пользователя.

(414)Ну на счет всех хотелок нет конечно, но необходимые вещи нужны. Если мне звонит 10-20 клиентов и просят какую-то штуку в один голос, то это я рассматриваю не как хотелка, а как необходимый иснтрумент. Про ошибки в базах я уже молчу.
(417)Они не базу предоставляют, а некий каркас с косяками.
(422)Баян. У меня существует.

(427) Вот именно. Каркас - уже с косяками. И потом - исправления, обновления, обновления, исправления... А платит - пользователь.

косяки даже в ДНК есть, чего уж тут от программного кода требовать.
Мелкие недостатки будут всегда и во всем, что делает человек. Которые этого не понимаю - инфанты престаревшие

(428) он ведь может и не платить, никто не заставляет, а твои рассуждения про корявость ПО просто детский сад. Хотя неудивительно, ведь ты занимаешься только конфигурированием и сопровождением

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

Огненная ветка)

Нужна голосовалка, а то влом всё читать))

(429)Программный код проще и соотношение косяков: в днк какое? А в 1с 1 к 1.
Какие мелкие недостатки в 1с? Просто сплошной недостаток)

(429) Разработкой ДНК занимался не человек. Человек только его (ДНК) использует. Как использует - такие и косяки :(
Мелкие недостатки <> недостаткам 1С.

(430) В 1С - именно "конфигурю" и "сопровождаю".

(427) "Баян. У меня существует."
Готов выложить на обозрение?

(436) А тиражные решения разрабатывала?

(438) Да. В каждом случае были пожелания пользователей (мелкие, легко дописываемые).
А что - это показатель?

(439) Что ты понимаешь под тиражным решением? Полноценную конфигурацию или отчет/обработка?

(440) О, как...
А ты не знаешь, что до 1С программы были?

(437)Все у клиентов.

(437) Кстати, а зачем?
Ты выступишь в роли критика?

(437) сольется так же как было со стандартом от 1С, якобы подтверждающем правоту ТС

а, ну вот, это уже и приключилось

(442) Т.е. у тебя есть написанные идеальные решения, но показать ты их не можешь. Ок.

(443) Зачем критиковать? Критика - это субъективно. Просто найду ошибку - это объективно.

(441) Замечательно. Значит, у тебя есть опыт разработки комплексного тиражного решения не на 1С?

(446) (447) Не бери много на себя - надорвешься.

(448) Я всегда беру ношу по своим силам. В отличие от...

(449) Неси.

(446)Естественно. Кто ж вам покажет? Если б я писал для всех или хотя бы на продажу, то показал бы.

(451) А ошибки искать? :)))))))))))))))))))

(452)У себя пусть лучше ищут, раз в каждой разработке делают их.

(450) (451) Ну, вот вы синхронно и слились. Пошел дальше писать свой г*внокод.

(454) зачет

(454)У вас не правильное представление о сливе)
(455)У вас тоже)

(454) Я тебя искать ошибки не звала.
http://s020.radikal.ru/i721/1602/a6/add20b961aa4.jpg

(455) – Хочу предложить вам взять несколько журналов в пользу детей Германии. По полтиннику штука.
– Нет, не возьму.
– Почему же вы отказываетесь?
– Не хочу.
– Вы не сочувствуете детям Германии?
– Сочувствую.
– Жалеете по полтиннику?
– Нет.
– Так почему же?
– Не хочу.
(С)

достаточно демагогии

(441) У вас там багтрекер был? Не могу поверить, что там было пусто.

(0) все не читал, штатный механизм доп.реквизитов не устроил?

Косяк однозначно со стороны (0) франчу нельзя давать тз в виде одного предложения имея команду бизнес-аналитиков.

Франч = внешний разработчик

ухх , чуть не пропустил самого интересного песателя мисты.

ну для всех кто уже поспорил и "наговорился" прилагаю самое интересное v8: УПП как лучше реализовать механизм отслеживания получены ли оригиналы документов

сильно не ржать, добиваю :)
JOB: Возьмут ли меня Руководителем проектов?

по первой ссылке отмечаем "деятелеЙ" и смотрим дату :)

ну а вообще как грится  "no comments"

(464) и что тут такого, вариантов как сие реализовать масса, через регистр ,через категории итд,

Руководитель не должен до винтиков знать конфигурацию, для этого есть ахритектор