Привет всем,
Даже не знаю к чему эта проблема больше относится к ABAP или BC, но проблема следующая:
Имеется туева хуча(200) собственных сгенерированых стандартных ракурсов ведения таблиц, ну естественно с классом поставки таблиц C "Таб. пользов. настройки, ведёт только клиент, не SAP-импорт".
Проблема состоит в том, что нужно все эти ракурсы ведения вместе с таблицами перекинуть клиентским системам заказчика. Все хорошо выглядит в общем если Пакет некоторых разработок(программ, таблиц, доменов и т.д.) записывался под отдельный класс разработок. Тогда просто берем и в транспортной системе создаем запрос на перенос, а потом говорим что хотим туда подцепить объекты из Класса разработок такогото. Все замечательно, казалось бы, но проблема состоит в том, что страндартные ракурсы ведения не были полностью включены в запрос, т.к. они состоят из "объектов инструментальных средств" (группа функций, экраны ведения и т.д.) а также все они еще и есть ЧАСТЬ НАСТРОЙКИ, которая ведется отдельно и никак не связана с пользовательским классом разработки. Короче... вот эту настройку и есть проблема - как ее перенести.
У меня есть один рабоче-крестьянский метод , брать таблицу или ракурс на измение, потом заходить в меню Утилиты->Генератор ведения таблиц, а потом жать на кнопку ТекстГрФункций, и только тогда эта скотина(система) желает предложить мне запрос на запись этой настройки.
Наверное вы скажете, ну и хрен с этой настройкой, но когда объекты(ракурсы, таблицы) будут перенесены в систему назначения, то при попытке их ведения, например через транзакцию SM30, система любезно обругается типа - "ракурс не полон или не существует", хотя физически все экраны ведения и все такое существует, все именно записит от этой настройки..
Так вот собственно я считаю что вот так вот ручками перед каждым переносом, лопатить все таблицы настройки, на предмет записи настройки есть БОЛЬШАЯ ЖОПА, поэтому я начал искать метод массового переноса и наткнулся на некую транзакцию SOBJ (Ведение кластера ракурсов SOBJ), где все эти настройки автоматич.генерации таблиц и прописаны.
Я почти обрадовался моему счастью, когда увидел что как и в большинстве Саповских транзакций там можно задать диапазон нужных мне объектов и нажать на заветную кнопочку "Перенести".
Но видимо у меня плохая карма или саповский софт уже совсем кривой стал
Вообщем делаю следущее: Выделяю записи что мне нужны, далее выбираю Перенести, система спрашивает у меня запрос, далее нажимаю кнопку Включить в запрос, а ЭТА ПАДЛА(система) говорит следущее "0 записи(ей) уже содержались в задаче TDEK926802." навсякий случай жму кнопку Удалить из запроса, на что система мне любездно отвечает "0 запис. не содержались в задаче TDEK926802". Если смотреть запрос и чего в него записано, то тама - правильно ни хрена нету
Короче ничего я так и не смог записать, в OSS рыться бесполезно, т.к. это не ошибка как таковая
*
Ну и теперь меня как жителя всего постсоветского пространсва интересуют ДВА ВОПРОСА: КТО ВИНОВАТ И ЧТО ДЕЛАТЬ
*
Есть ли у кого-нибудь еще другие варианты более-менее массового переноса настроек ракурсов ведения таблиц.

Заранее всем благодарен, а также благодарен за то, что хватило сил дочитать мой монолог до конца. Честное слово, как меня уже ЗАДОЛБАЛА ЭТА СИСТЕМА, глюк на глюке - багом погоняет

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

Ну честно говоря я решил использовать старый проверенный и извращенный метод. Напишука я Call tranzaction с предварительным выбором объектов по классам разработки которых нужно включить в запрос