Помогите плз. разобраться с проблемкой:
при переносе документов из FI в спец.регистр FI-SL (транзакция GLCU2) данные записываются в регистр в версию 1. Каким образом на это можно повлиять? где определяется в какую версию записывать данные? Хочу, разные документы записывать в разные версии.
Заранее благодарен.

Добрый день.

Нельзя на это повлиять. Вот Выдержка из Хелпа :

В принципе есть такая возможность с использованием замещений для спецрегистров.

Да есть.
Только не замещение, а постоянный перенос полей с навешенной на него пользовательской програмкой.
Только, как мне кажется, не дело использовать версию для таких целей.
В конце концов передается же в регистр ссылочнвй вид документа FI.
Можно же сделать дополнительное поле для аналитики, и использовать его потом в отчетности, но не следует ломать стандартный функционал.
Но это мое ИМХО.

2 Niki: Согласен, именно перенос и имел в виду. Здраво мыслите!

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

[quote="Niki(4.6B)"]Да есть.
Только не замещение, а постоянный перенос полей с навешенной на него пользовательской програмкой.
Только, как мне кажется, не дело использовать версию для таких целей.
В конце концов передается же в регистр ссылочнвй вид документа FI.
Можно же сделать дополнительное поле для аналитики, и использовать его потом в отчетности, но не следует ломать стандартный функционал.
Но это мое ИМХО.[/quote]

Коллега совершенно прав, поменять версию можно экзитом на постоянный перенос полей, но это не есть хорошо. При необходимости видеть аналитику по видам документов, следует добавить в таблицу поле для вида документов и для всех возможных видов операций прописать правила переноса этого поля. Если есть необходимость, можно сразу уплотнить несколько видов документов FI в один SL, но ИМХО это лучше делать на уровне отчетности, а не настроек переноса, так как удобнее поддерживать при создании новых видов документов. Поэтому если не заморачиваться с уплотнением по видам документов на этапе переноса, дополнительное поле можно не вводить, а пользоваться видами ссылочных докуметов, как советует Manticore. Возможно, даже не придется делать сведения, а отчетность получите с использованием наборов по видам документов с определенными как надо репрезентативными значениями наборов.

Уважаемые коллеги, спасибо за ваши ответы, действительно взгляд на проблему со стороны бывает полезен. Только вот в чем беда, вариант с пользовательской программой навешанной на постоянный перенос полей я уже рассматривал, но не могу понять на какое именно поле нужно вешать этот UE? Да и вариант с видом документа тоже не проходит, потому что у меня все переносимые документы одного вида, и уже их нужно поделить по определенным правилам. Вот дополнительный регистр - это уже ближе к делу, но ведь они будут на основе одних и тех же таблиц (новые завести точно не выйдет), значит 1 версию нужно исключать из дальнейшей обработки (пока не прогонишь через доп.регистр). отсюда мораль - использовать версию 1 только для переноса документов, а как тут быть с другими данными в 1 версии??? Короче, вопросов получилось больше чем получено ответов.
Если не затруднит, подскажите, как быть. Я уже всю башку себе сломал, ничего нового не лезет.

Честно говоря немного путанный ответ, вызванный видимо, паникой Спокойно! Сейчас разберемся!

1. Вариант с постоянным переносом полей. По правильному, user program надо вешать на целевое поле. То есть, в Вашем случае - на поле Версия. Причем поле Версия - получатель, а поле, например, номер исходного документа (ну т.е. первичный документ, "породивший" запись в спецрегистры) - отправитель. И далее писать некий Uxx USING FROM_FIELD TO_FIELD.
Однако, никто не запрещает навесить user program на любое другое поле, а ней объявит парочку field symbols (впрочем в первом варианте это тоже придется делать) для динамического линка на таблицу-отправитель и таблицу-получатель. И дальше уже обрабатывать любые поля этих таблиц (в том числе и Версию) по любым алгоритмам.

2. Вариант с дополнительным регистром. Не понял Вашего смятения. В чем собственно проблема. В первый регистр попадают данные в одной версии, а потом при переносе их из первого во второй регистр, на уровне пакетов сведения происходит анализ необходимых полей (например номера исходного документа) и замена поля Версия.

Коллеги,
давайте идти от задачи.
Stas поясните, что Вы хотите получить на выходе?
Как я предполагаю некий отчет или гуппу отчетов.
Вы определились на каком инструменте Вы будете делать отчтеты?
(Report Painter/Writer, Sap Query или ABAP отчеты.)
Планируется ли передавать в регистр все документы FI или нужно получать только определенные, отбранны по определенному правилу?Если по правилу , то что является критерием отбора ( значение поля в заголовке документ, в позиции или совокупность значений полей)?
Нужна ли Вам информация по деталям проводки или отчеты будут строится по итоговой таблице (по уплотненным данным)?
Если по уплатненным данным, то что является критерием уплотнения?
Является ли этот критерий объектом ABAP словаря (поле таблицы, структуры и т.д.) Например Номер счета, МВЗ, МВП, Бизнес-сфера, БЕ?
Или такого объекта в словоре нет, но он требуется требуется для составления отчетности?
Или критерием уплотнения является контировка, состаящая из нескольких объектов?
Планируете ли Вы в дальнейшем сведение, перераспределение или раскладку в Вашем регистре. Если да, то между какими объектими?

Ну для начала, наверное, хватит.

Stas поясните, что Вы хотите получить на выходе?
Да на выходе я собираюсь получить некий отчет.

Вы определились на каком инструменте Вы будете делать отчтеты?
Да определился - это ABAP отчеты (других вариантов у меня нет в силу определенных причин)

Планируется ли передавать в регистр все документы FI или нужно получать только определенные, отбранны по определенному правилу?
Да, по правилу, критерием отбора являются поля в позиции, а именно счет, МВЗ, БСф

Нужна ли Вам информация по деталям проводки или отчеты будут строится по итоговой таблице (по уплотненным данным)?
Думаю, для начала мне хватит итоговой таблицы

Если по уплатненным данным, то что является критерием уплотнения?
Является ли этот критерий объектом ABAP словаря (поле таблицы, структуры и т.д.) Например Номер счета, МВЗ, МВП, Бизнес-сфера, БЕ?
Думаю, уплотнять по тем же критериям, что и отбирать документы, ну и еще добавятся некоторые поля (тоже поля таблицы)

Планируете ли Вы в дальнейшем сведение, перераспределение или раскладку в Вашем регистре?
Да, планирую сведение, только не понял вопроса, к чему бы этот вопрос...

Еще по поводу поля для UE... в том, то и дело, что при переносе документов в переносе полей нет поля-отправителя ВЕРСИЯ и поля-получателя такого тоже нет!Я ИДИЁТ, УБЕЙТЕ МИНЯ КТО-НИБУДЬ!! На какое поле вешать UE? вопрос остается открытым.

Большое всем спасибо за участие.

Так поля отправителя Версия и не будет. Это поле есть только в целевой таблице-получателе. А чтобы это поле появилось в перечне полей-получателей, надо, если память не изменяет, его прописать в ведении переносов полей. Транзакция GCI4 или GCL4, точно не помню.

Ваш выбор, на мой взгляд, не совсем верен, но раз иного выхода нет, то все остальные вопросы снимаются.

Stas чтобы я Вам посоветовал.

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

Есле же Вам покоя не дает стандартное поле версия, то для его замещения используется постоянный перенос полей (тр. GCI4).
В этой транзакции, как совершенно правильно сказал коллега Manticore, надо добавить записи для Ваших таблиц для поля RVERS.
Если Вы будите передавать в регистр детали документов, то записей должно быть две, как для таблицы детальной информации так и для таблицы с итоговыми данными. Иначе данные разъедутся....
Там же для вашего переноса определяется и экзит. Только надо учесть, что кодировка для экзита ведется в модуле, отличным от модуля определенного для переменного переноса полей.
Определяется этот модуль в тр. GCX1, для прикладной области GIMF.
Для примера можете взять модуль RGIFS000. Это модуль для системных замещений. Можете его скопировать в свой на Z. Только не забудьте поудальть в нем все ненужные замещения.

После того как определите переносы, не забудьте сделать актуализацию кодирования. тр. GCCG. Иначе все Ваши экзиты не будут вызываться.



Вопрос не праздный, поскольку от этого зависит настройки таблиц и регистра.
Есле не планируется дальнейших действий с данными, то при определении объектов контировки в таблице объектов, не нужно ставить галку "Отправитель", тогда не будут создаваться доп. поля по таблицам значений. Это не критично, но может вносить некую путанницу, при создании переменных переносов полей.

Гость -это я.
Залогинится забыл

Хочу подменить поле "Период проводки".
Однако в Итоговой таблице оно RPMAX, а в таблице отдельных позиций и таблице GLU1 - это поле POPER.
Поэтому, когда прописываю две строчки по обоим таблицам в GCI4, то при проведении документа вываливается дамп
"The following syntax error occurred in the program RGIMF000 :
"The data object "GLU1" has no component called "RPMAX", but there is a"
Error in ABAP application program."

Получается, что нельзя в тр. ведения постоянного переноса полей указывать поля из таблицы итоговых данных ?

Получается, что лучше не извращаться