8.1 УПП + новый релиз (21) - не работают изменения внесенные в предыдущую конфигурацию

Мальчика не прииглашали, организация сопровождения прислала девочку, девочка предупредила, что некоторые переделки могут не заработать. Я согласна, что могут незаработать переделки, которые мы сами вносили. Но те, которые по нашей просьбе, за достаточную плату, делала организация сопровождения ... как с ними быть. Если честно - денюшки жалко ... Следующий релиз так же "положит" нам все изменения - нам опять платить за доработку???<br>

Поставте условие, чтобы их изменения при обновлении ими оставались работоспособными.<br>Мы сторонним разработчикам ставим одно условие - не должно быть изменения стандартных объектов. Если без такового всеже не обойтись, то это должно быть выделено. Поскольку обновление занимаюсь я, то мне это выгодно.<br>Хуже всего это "Общие модули" - с ними сложно. Формы можно копировать и править сколько влезет, тогда при обновлении можно не получить всего функционала, который добавили, но ваша разработка будет работать.

Если девочка с той организации, что делала эти переделки, то должна была сохранить их все, если не сохранилось, то должны востановить за свои деньги

Свои 5 копеек. Например, ЗУП 2.1 и ЗУП 2.5 настолько различны по базовой идеологии, что процентов 90 сделанного для 2.1 не будет работать в 2.5 - просто потому, что объекты конфигурации различные. Требовать от разработчика переделок того, чтобы он на стадии разработки предвидел набор объектов, которые 1С заложит в будущих релизах - по меньшей мере несерьезно. Перетасовка процедур и функций из одного общего модуля в другой уже воспринимается как неприятная, но неизбежная реальность. Ну перестала работать после обновления внешняя печатная форма, и все тут! "...процедура с таким именем не найдена...". А ведь при ее создании объекты конфигурации не трогались, она как была, так и осталась "под замком". Теоретически конечно можно протестировать тестовый релиз, но это только теоретически (особенно в УПП). Так что у меня нет однозначного ответа. Лично я для "старых" клиентов переделываю за деньги - за годы совместной работы они убедились, что необходимость переделок не от умышленно "заложенной бомбы", для "новых" - иногда приходится "за советское спасибо".

Кстати мы так и не знаем с какого релиза переходили? Глобальный релиз в УПП это 1.2.15, дальше пошли по нарастающей!

+1

21 релиз по сравнению с 19 очень сильно переделанный изменились некоторые фундоментальные механизмы<br>Сама сижу парюсь со своими изменениями.<br>Но я думаю, что фирма которая производит обслуживание перед обновлением должна была просчитать эти сложности и внести все в единый счет, а не выдавать пользователю не работающую конфигурацию, а если они это дело сразу прошляпили, то уж должны сделать все за свой счет<br><br>Я согласна с тем, что если бы изначальные изменения вносила бы другая фирма или мальчик, то требовать работоспособности было бы не правомерно, но свои-то изменения можно было бы и просчитать

Если договор на обслуживание еще в силе, то там однозначно должна быть прописана ответственность сторон за неработоспособность конфигурации (по вине стороны заказчика или исполнителя). Если это не прописано, то максимум, что может повлиять на исполнителя это расторжение договора.<br>А так - теория:<br>1) Любые изменения нужно стараться делать без влияния на типовую конфигурацию.<br>2) Если сделать изменения не затрагивая типовую не возможно, то ведется протокол изменений (с описанием функционала и измененных объектов/кода программы), а также клиенту указывается примерная стоимость внесения всех изменений в обновленную конфигурацию (сильно сомневаюсь, что кто-то согласится делать это бесплатно).<br>3) Перед каждым обновлением конфигурации делается резервная копия базы.<br>4) Со стороны заказчика назначается ответственный за приемку ВСЕХ ПРОВОДИМЫХ РАБОТ, а это проверка на работоспособность внесенных изменений, контроль ведения протокола изменений, контроль архивирования базы перед внесением изменений.<br><br>- практика:<br>1) Исполнитель не только практически не задумывается над изысканием возможности не затрагивать изменениями типовую конфигурацию, но и зачастую специалист не знает как это сделать.<br>2) Вместо ведения протокола в лучшем случае код программы будет "напичкан" комментариями разработчика, по которым практически не возможно понять что это такое и зачем это было сделано (изменения объектов вообще практически не отловишь).<br>3) Резервная копия, как правило, делается, но вот заказчик практически никогда не утруждает себя проверить работоспособность программы после обновления и в итоге приходит к ситуации, что уже внесено много данных в нерабочую программу.<br>4) Ответственного со стороны заказчика практически никогда не найти.

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

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