Вроде все баги нашел...
В программе перенос полей - номер контракта глючил.
Осталась одна проблема. Иерархическое сведение слишком глубокое. Нижний уровень равен строке декларации.
Как избавиться от проблемы нехватки режимов?

Похоже режимы не при делах. Все просто. Сведение JF00 в стандартной поставке не работает. Ни одного переноса данных!
Если кто готов помочь то знайте - вы делаете благое дело!

Неужели у всех оно нормально работает в 6.0 ??

Проблема нехватки режимов идет с незапамятных времен, в данном случае я так понимаю выход один. Перестроить иерархию и сократить вложенность.
И еще, может у кого есть тех.описание "нового ТПРа", такое, как было по решению Юникона?
Дело в том, что во многих сведениях нехватает экзитов + хотелось бы лицезреть описание. Нет доверия, после ранее выпущенных ТПРов, так как зачастую у них описание не совпадает с настройками после установки решения.

Дело в том, что в макросе шаблона для декларации 2007, который выдал SAP содержиться ошибка!
А неправилно происходит перекодировка, потому что нужно проверить набор сведения - набор для элемента RTAXOBJ. Он должен быть "сгенерен" по иерархии RUPTD.

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

Вот возникла проблема: пытаюс инсталировать группу таблиц FI-SL. Согласно руководству

значит создал я копии таблиц под именами соотв. ZTAXRO... ZTAXRP
далее в транзакции GCIN пытаюсь инсталлировать группу таблиц ZTAXR но появляются сообщения

Сообщения к определению таблицы итоговых записей ZTAXRT
Элементы данных полей RCONTRACT и SCONTRACT идентичны
Элементы данных полей RKTRLAGT и SKTRLAGT идентичны
Элементы данных полей RDIVISION и SDIVISION идентичны
Проверьте индекс '1' таблицы ZTAXRT.

и как бы инсталяция не продолжается. в чем собственно дело??
кстати смотрю на группу ZTAXREG в качестве примера - проверка инсталляции выдает что она корректна но проверка группы выдает те же самые сообщения, тогда каким образом она проинсталлирована???

Там есть возможность продолжить инсталляцию принудительно. Надо выбрать по меню: Продолжить инсталляцию принудительно.

To Maxx: спасибо этот момент прошел но возникли проблемы с активацией BC-set тр. SCPR20. Дело в том что экспериментируем в манданте - копии продуктива и при активации выдается сообщение со смыслом Нельзя активировать в продуктивной системе. Получается что возможен только вариант - провести все действия в системе разработки а дальше посредством переносов запросов? я правильно понимаю?

Снимите с манданта и БЕ признак - продуктивно (если установлен). Должно помочь.
Хотя у меня такой проблемы не было - клиент изначально настроечный и все надо будет переносить через запросы в тест и продуктив.

ДА пробовали изменять признак продуктива - не помогало. Остается видимо только работать в системе разработки

А решение, тиражируемое БДО, полностью соответствует ТПР25?

Интересный вопрос

Можно еще попробовать в SCC4 пройтись по настройкам вашего клиента, наверняка там стоит признак "Запрет изменений" (если это была копия с продуктивного манданта), тогда он конечно никаких активаций ВС-сетов делать не даст.


Опасная игрушка. Если в индексе действительно косяк (а скорее всего так и есть, раз инсталить дальше не дает, одинаковые элементы данных - это повод для зеленых предупреждалок, а не так, чтобы инстал останавливать), то вообще потом ничего работать не будет. Поэтому стоит зарулить в SE11, выбрать поочередно каждую из табличек Вашей группы, там в меню "Утилиты" есть раздел "Объект базы данных", и под ним есть утилита БД. Вот в этой утилите и надо проверить все индексы для всех таблиц Вашей группы, они все должны существовать и находится в активном состоянии! если это не так, то надо адаптировать таблицу ZTAXRPO, это наиболее безболезненный путь устранения косяка с индексами

2 Lavanda
Не очень понимаю природу вопроса проще говоря - в связи с чем он возник? )) ТПР был разработан САПом пополам с Юниконом, но сейчас он поставляется собственно SAP CIS. Написав туда письмо, можно получить самую актуальную версия поддерживаемого ТПР25 и не париться с Юниконовским самоплясом