Копирование ПСп (Страница 1 из 2)

Естессно не подходит!
Эта замечательная комманда работу никак не упрощает. 
У нас в перечне всего одна позиция ПСп!
Люди заводят по  150-200 деталей по одной штуке на ПСп  :?   
Я уж как тока не кроил - запустить их сразу не выходит никак.
Соответсвенно - самым утомительным становиться бредовое действие по добавлению доступа пользователей и проставлению галочек (Ctrl+C, Ctrl+V проблему не решает) и выбору состояния и присвоению номера. 
А СКРИПТОМ ЭТИ ДЕЙСТВИЯ АВТОМАТИЗИРОВАТЬ НЕВОЗМОЖНО!!!
А пришлось это сделать из-за довольно слабой проработки в TechnologiCS v.4 прослеживаемости изделий с индивидуальными номерами (в терминологии TechnologiCS - серийиными номерами).

нет . в версии 4 этого нет.

Всё что ты перечислил и надо копировать (как по кнопке "следущий", но с перечнем и ТП). 

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

Самое тут не удобное это доступ пользователей проставлять. Речь об очень трудоёмкой работе, которую невозможно автоматизировать имеющимися средствами API.

Это на закладке "номенклатура"?  Я и не замечал раньше...
Мы как-то всё в "Производстве" это дело заводили.... :) гы

Это самая огромная проблема. Много и сразными правами - просто не реально, даже 3-4 со всеми правами и то трудоёмко.
Если заводим ПСп и жмём "Следущий", то перечень не копируется, права тоже... 
С учётом 150-200 штук - работёнка не тривиальная, а отдельного человека на неё нет, у людей другие вопросы простаивают... :(  Вот как-то так...

Может тогда приемы работы пересмотреть, потому что вот это

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

А чем Вам в 5-ке не нравится прослеживаемость изготовления номерных изделий? Что не так то? И что именно Вас не устраивает, и что по Вашему не хватает, чтобы было не так далеко до совершенства?

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

Костя, вот это  заявление не менее безапеляционное:

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

Это уроза? :D

дак нам и не надо этого... нам процесс создания ПСп надо автоматизировать...

ПЕРВОЕ СООБЩЕНИЕ В ТЕМЕ ПРОЧТИТЕ!!!

Сложились уже бизнес-процессы, трудно переучить такую прорву народа... Тем паче нет у них времени на переучку, загрузка большая по работе.... Трудно баржу посреди реки на полном ходу развернуть.
Да и как объяснить руководству ради чего платить за обновление? API для ПСп как я понял и в 5-ке не сделано.

Я не срываюсь в полемику, просто нам конкретная помощь нужна, а не пространные замечания по поводу того как мы работаем. Либо чёткий ответ - нет невозможно, и не будет возможно - потому, что потому...
У меня кроме клиента, ещё и руководитель есть, который с меня работу спрашивает, и если я её не могу сделать, надо обьяснить почему.  Мы вроде не в игрушки играем.

Насчет

Т.е. по Вашему получается, что

это означает, что

???
Глубоко...  :) 

Насчет конкретики: 
то что Сергей говорит - сделать можно через API все, что Вы хотите за исключением раздачи прав. Пойдет? Или в правах именно вся загвоздка? Если дело в правах, то поясните, pls, как именно кому и зачем они раздаются, тогда попробуем какой-нибудь выход изобрести.

Действия:
1. создать ПСп, сгенерить номер.
2.Добавить позицию перечня, проставить к ней дату (с закладки основные в ПСп, даты в производство не попадают)
3.Привязать активный технологическ процесс.

И всё это одинаковое за исключением номера ПСп.

Вот и я тоже понять не могу  :oops: 

Поэтому и предложил Вам, Максим К., изменить способ работы.
Ведь сами же писали:

Может количество ПСП раз в десять уменьшить, ведь именно при создании ПСП у Вас неудобство и потери времени. Глядишь и проблемы нет  :lol: .

Ну это, конечно, дело Ваше, действительно пользователей переучивать проблематично.

По этому вопросу вот:

Т.е. основная головная боль должна пропасть, так?

А комментарий к позиции перечня ПСП не подойдет для этой цели? Его отлично видно в гриде.

какие?

ну это Ваше личное мнение. Тем более, что деньги совсем не большие, по-моему.

тоже, собственно, дело Ваше. Вот только в таком случае большинство претензий просто не принимается. Если Вы так категорично против того, чтобы обновлять программу хотя бы иногда,  ну хорошо, мы ж не против - работайте с той версией, которая есть. Но тогда возмущаться зачем? Какие есть возможности в этой версии такие и есть. Других не будет. А более современную версию Вы сами же и отказываетесь использовать. Чего ругаться то тогда?

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

Тут дело попахивает рисованием своего грида  :wink:
Вы поймите правильно - в режиме План производства на закладке План изготовления и так 58 колонок, не считая зависимых объектов. Из них ненужных в реальной жизни на мой взгляд всего 4-5. Остальные, в принципе, в разных случаях нужны. Вы же сами жалуйтесь что работать неудобно т.к. гриды слишком большие. И тут же говорите, что надо добавить еще с пару десятков колонок, причем многие из которых весьма специфичны (например, п. 2 и 3). Где правда?
Как с твоей точки зрения должен выглядеть удобный экран? Если не трудно, нарисуй пожалуйста и выложи сюда картинку. Обсудим.

Ну я бы так не сказал. Вон уже 2 страницы исписали. Пытаемся придумать же какое-то решение а не посылаем сразу  :wink: .
Просто получается, что очень много проблем возникает в следствие того, что программу пытаются использовать совершенно не так, как это задумывалось при ее разработке (имеется в виду не конкретно этот случай, а вообще). При этом возникают два характерных следствия/претензии:
1. "не удобно" - что, если разобраться, вполне логично, т.к. никто и не предполагал такой способ использования.
2. "работает не так, как должно" - тоже логично, т.к. "так как должно", а точнее - так, как кто-то решил, что так должно быть, никогда и не предполагалось что будет работать.

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

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

 
так это, уж извините конечно, но в первую очередь вопрос к  тому кто внедрял. Вообще то есть методика, позволяющая 90% подобного рода проблем избежать.
А как же этапы создания и настройки прототипа? Как же опытная эксплуатация и весь комплекс мероприятий перед запуском в промышленную эксплуатацию? Если все работы были на тех этапах были сделаны качественно и в должном объеме, то откуда такая постановка вопроса? Я бы еще понял вопрос вопрос в стиле "если сделать так, то может потребоваться изменить отлаженный и привычный способ работы, а для этого придется сделать и протестировать новый прототип. Иначе есть риск что изменение не приведет к улучшениям."
А так получается, что если работать так не удобно, то почему же эти вопросы не решались ДО запуска в пром. эксплуатацию? Или может с этим самым запуском в эксплуатацию поторопислись и недостаточно хорошо отработали бизнес-процесс с учетом работы с программой на прототипе?