03 - это для УУ?
При перемещении лучше не менять иначе у вас на старой карточке может сумма зависнуть. Лучше сделать это перед перемещением. Создать вид движения, который срезает сумму с данной области оценки, ну и второй на увеличение. Откорректировать ПС и пересчитать амортизацию за последний месяц. Но это корректно сработает, если это у вас первый год в системе. А после этого перемещать.


А вопрос мой про структуру кулассов был задан с целью понять цель сего мероприятия. Вполне вероятно, что достаточно будет ввести пару лишних справочников в карточу ОС. Заполнить их, написть отчет и цель будет достигнута.

Или использовать поля дополнительной классификации ("Присвоение")

[/quote]А вопрос мой про структуру кулассов был задан с целью понять цель сего мероприятия. Вполне вероятно, что достаточно будет ввести пару лишних справочников в карточу ОС. Заполнить их, написть отчет и цель будет достигнута.[/quote]

Соглашусь с коллегой!
В ОЗОС есть столько полей, что если причина разделения - аналитика, то незачем шлаковать ПСч

то есть вы предлагаете использовать дополнительные поля в карточке как тот же класс и при формирование отчета выводить данное поле. Но это не будет выходом, так как хотят видеть разбиение в ОС = разбиению на счетах 01 в ГК.

А я хочу 500 счетов 01 с дикой аналитикой
Просто нужно сопоставить цели и инструменты их достижения.
Установите цель - для чего это нужно. Просто хотеть - это не цель. А мы Вам поможем подобрать инструмент.
Раз это УУ - то цель скорее всего аналитика. Аналитика в SAP FI-AA достигается в основном не через счета ГК.
Вероятнее всего специалисты Вашего УУ абсолютно не в курсе возможностей SAP, поэтому идут проторенным путем - через план счетов, что логично с их стороны.

p.s. работа консультанта заключается не в выполнении "хотелок" ломая все и вся, а в поиске оптимального решения, его обосновании и аргументации.

а не нужно разбиения 500 штук на 500 субсчетов 01. Об этом никто и не говорил. Необходимо просто еще может добавить максимум 4 субсчета всего на 01. Я говорю о том, что сущ-ие об-ты надо разбить на новые уже классы, так как с точки зрения УУ был изничально выбран не тот класс. ТО есть у нас может быть оюъект на классе Здания, а нужно на сущ-й класс отправить Неотдел.улучшение. ВОт и все. Так что просто аналитикой не обойдешься в карточках ОС,так как должно быть четкое соотв-е со счетам ГК.

Не совсем ясна фраза: "ТО есть у нас может быть оюъект на классе Здания, а нужно на сущ-й класс отправить Неотдел.улучшение."
Но исходя из всего остального скорее всего только перемещение.

Если вопрос стоит в массовом изменении класса ОС посредством LSMW - то можно, транзакция - ABUMN, с отметкой "в новое ОС", система автоматически создаст новые карточки... По крайней мере у меня такая практика...
Если изначально в систему были прогружены неверные классы и есть необходимость их исправить, то можно попробовать через AS92 (измен.загрузочных данных) (не уверен)