Добрый день:)
Есть такая проблемка. Нужно перенести план счетов из продуктивной системы, назад в разработку. Как это лучше сделать?:)

1. С помощью транзакции OBY9 включаете в запрос ракурс манданта (тексты и SKA1). Для этого нужно поставить первые две галочки - Accounts in Chart of Accounts и Accounts Name in all languages.

2. В транзакции SE10 включаете в тот же запрос дополнительную запись - таблицу SKB1 по ключу БЕ:

R3TR - TABU - SKB1, ключ - client - company code.

Деблокируете, переносите, наслаждаетесь жизнью

А есть еще FS15

Это как делать не надо. Таскать транспорты из продуктива в разработку не есть правильно. По хорошему, перетаскивать счета из продуктива в разработку надо запретить. А еще более правильно запретить и ведение плана счетов в продуктиве. Исходя из соображений поддержания порядка и недопущения анархии в системах. Под страхом отрывания у кого что можно оторвать. Но если все-таки нельзя, но очень хочется, настройте ALE. Почти как вот здесь, только сообщение использовать GLMAST.

Мы так только из разработки в продуктив таскали... В компании, в которой было запрещено счета в продуктиве заводить. А в середине проекта специалисты из центра компетенции SAP это радостно пользователям разрешили. Для продуктивных БЕ, использующих тот же план счетов. Вот смеху-то было...

На самом деле согласен полностью, не дело это, равно как не дело в продуктиве счета напрямую заводить. Но, увы, я знаю всего одну компанию, в которой это запрещено.

На самом деле официальных рекомендаций САП о том, что следует запрещать ведение плана счетов в продуктивной системе, нет. Это сугубо мое личное мнение, что в российских условиях возможность ведения плана счетов пользователями явно является излишней, и вот почему.
1. Обычно пользователям не объясняют, зачем нужна куча служебных полей в настройках счетов. Пользователям понятны номер и название, остальные - статусы полей, коды налога, финпозиции-шмазиции - на практике не могут быть правильно заполнены конечными пользователями.
2. Счет добавить легко. Допустим, даже с правильными галками его юзер настроил. А вот куда его девать в балансе, вспомнят только когда жареный петух под закрытие периода клевать начнет
3. Чем более разви система, тем более в ней счета задействуются в автоматических проводках. По любому, счета и в этом случае сначала должны быть заведены в разработке.
4, 5 и т.д. - наверняка коллеги добавят, кому не лениво, но ИМХО перечисленного уже достаточно

Как это ни забавно, я встречал такую ситуацию только в крупных западных компаниях, у которых сложная система с CO-PC и PP, очень много разработок и масса Z* таблиц, в которых нужно эти счета прописывать. Я уже не говорю о стандартных отчетах уровня баланса и P&L...

Знаю одну российскую компанию, в которой (по крайней мере, 2 года назад) не было CO, вся аналитика велась в FI, распечатка перечня счетов помещалась страниц на 80. У них половина отчетов друг с другом не сходилась, поскольку никто не отслеживал создание новых счетов (штук по 60 в месяц). Вот им такого запрета точно не хватает