Достали, блин.
Девелоперы выполняют настройки в продуктиве, минуя тест. Это нормально? (объясняют, что иначе не получается, ссылаясь на инструкции генразработчика (не будем тыкать пальцами...)).
Поделитесь, плз, соображениями.

настройки какого рода? Есть некоторые таблички, являющиеся настроечными, которые в общем-то разумно вести именно в продуктиве. То, что сразу приходит на ум - валюта например.

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

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

принесли объяснилово - в тесте не настроен тип позиции ZDTY(SD)..полгода голову морочили, бестолочи. если б базис у меня так работал - разогнал бы уже.

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

да уж конечно...только дай волю )) - фиг. Придётся устроить разбор полётов. Хакеры хреновы...

Вообще-то для сравнения настроек между системами есть удобная вещь - OY19

во - эт интересно! погляжу ща ).

[quote="Skif]да уж конечно...только дай волю )) - фиг. Придётся устроить разбор полётов. Хакеры хреновы...[/quote]

угу - значит написана программа, которая меняет некоторые настройки? У меня вопрос - как ты это отследил?

актуальная задачка однако - надзор над разработчиками...

делал? Сравнение двух мандантов например по IMG?:)

Про отдельные таблички не говорим.

всё - разобрались. ложная тревога из-за рассинхронизации по времени тестирования в тесте и просмотра продуктиве.
p.s. ничего - всё равно полезно для повышения общей ответственности, дисциплины и сплочения коллектива - в след. раз сразу будут разбираться, а не через полгода. ))

угу - значит написана программа, которая меняет некоторые настройки? У меня вопрос - как ты это отследил?
актуальная задачка однако - надзор над разработчиками...[/quote]
да отсюда же и узнают )) - в октябре "зачищал" только "левые хвосты" в продуктиве - всем трындюлей было.

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

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

С отдельными табличками - вопросов нет - но сравнение мандантов - это зрелище не для слабонервных