Коллеги всем добрый день, скажите кто-то занимался реорганизацией рабочих мест, если да то какие были подводные камни и мели?

Был опыт. Хоть и не большой.
1. С переименовыванием (Key identifying) рабочих мест проблем не обнаружено.
2. Использование изменений статуса - блокировка/метки удаления - не отражается на стандартных средствах поиска.
3. Для удаления рабочих мест пришлось архивировать соответствующие объекты использования (естественно, только если это допустимо). Но и после этого остались неприятные следы (пришлось подчищать), что впрочем является обычным для архивации.

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

Если z-отчеты завязаны на идентификаторы рабочих мест, безусловно:

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


Может чего-то не понял. Проблемы вроде нет. При переименовании рабочего места во всех объектах оно измениться автоматически. Меняя идентификатор - мы меняем ARBPL, а у, например, операций заказов ТОРО хранится значение из OBJID, которое не меняется.

из моей практики - самое геморное - это удаление раб-мест

таки да, плавали

Ну у меня есть ТОРО, в которых были электрики с номером рабочего места 4711, пять лет работали и всё ОК. Я рабочее место переименовала и оно стало 89723. Они работают дальше проблем с переименованием не было (работает, проверяла ).
А мне нужен отчёт по электрикам и только по ним родимым, я 4711 нигде не найду только 89723. Ну или все ТОРО выбирать за пять лет выгружать в Excel,там компоновать по рабочим местам, сортировать, потом туда же новые ТОРО довыгружать и всё сводить под общий знаменатель "электрики". Это приблизительный сценарий ужастик, а что моим умникам ещё в голову придёт не знаю.
Z-если с опорой на таблицу, то таблицу можно расширить и код подкорректировать.

Я подумываю новые типы создать, ну типа Y001 вместо Z001, старые запереть, и оставить эти "трупы" для отчётов. Просто, но до ужаса не элегантно.

Добавлю свои пять копеек.
Для дополнительно проверки полномочий используем объект полномочий I_LBK_WC, где используется идентификатор рабочего места.
При смене идентификатора приходится вносить изменения в роли.

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

Пару дней молчания, но стоит только начать...

В некоторых случаях можно и поэлегантнее.
Можно использовать следующее: в интеграционных областях, при обмене данными иногда передаются значения рабочих мест как раз из ARBPL. Передается и там фиксируется. Например, таблица LSHR.

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

За пять копеек спасибо, но для меня эта тема не актуальна, в правах стоит *, там проблем не будет.

У меня Z-отчётов как описано нет, у нас отчётность идёт из BW, так что мне важно что стоит в match-code, а из него при переименовании тех.место исчезнет (При переименовании в селекционном окне старого тех.места нет. Я проверила).
Кроме того у меня на рабочих местах автоматические pdf формуляры висят, а для подвески служит таблица одна из колонок рабочие места, а не их внутренние индексы.

Коллеги, прошу прощения за некропост. Такое впечатление, что вроде по адресу.
Итак, у меня закрыто подразделение с некоторой даты. Так как я не могу убить РМ совсем, я в закладке Калькуляция закрываю калькуляцию со старым МВЗ датой закрытия, а стандарт мне создает второй срок действия с тем же МВЗ до 31.12.9999. Вот тут-то во втором сроке действия я меняю старый МВЗ (который в KS04 удаляю с нужной даты отдельно) на МВЗ с номером и названием УДАЛЕНО, у которого в настройках стоят все блокировки на план и факт какие только бывают.
Никто не пробовал такой способ. Что получается:
- в старых периодах все отчеты работают по тем данным какие есть
- в новых периодах нельзя ни запланировать ни зафактировать.

Есть опыт использования такой схемы?