Мдя... Автору же советовали обратиться в форум по HR.
Там практически КАЖДЫЙ знает, как работать со статусами A P O и как получать/сохранять результаты расчета.

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

Удачи.

Добрый день, коллеги. Есть такой вопрос - по поводу ID при использовании export/import to database.
Есть отчет, из него - для получения определенных данных - запускается еще один отчет по submit.

В вызываемом отчете для передачи данных прописано
EXPORT tab = gt_alv2
TO DATABASE indx(zg)
FROM wa_indx
CLIENT cl
ID 'ZFT_CORRESP'.

В вызывающем отчете после submit для получения этих данных прописано
IMPORT tab = gt_alv2
FROM DATABASE indx(zg)
TO wa_indx
CLIENT cl
ID 'ZFT_CORRESP'.

Мне говорят, что я должна сделать динамическое определение ID - т.к якобы при статическом определении не смогут работать несколько пользователей с этим отчетом.. опыт испольования отчета пока показывает, что никаких проблем не возникало.
Если это действительно необходимо - динамическое определение ID - возможно есть пример передачи этого ID - как корректнее это сделать?

спасибо заранее.

Правильно говорят. Можно добавить к ID имя пользователя sy-uname. Однако это не спасет при одновременном запуске программ одним пользователем.
Для подобных задач я использую "export/import ... memory", это гарантирует изолированность задач и не засоряет зря базу данных.

Если широко используется export to memory - то в какой то момент начинают сыпаться дампы по нехватке памяти, особенно если передавать таблицы

От дурака не спасут ни какие методы.
К тому же "import ... from database" всё равно положит данные в память.

да.. именно такая проблема и была -памяти не хватало - отчет -реальный монстр - пользователль хочет все и сразу и много.. поэтому заменили export to memory на export to database

Ну FREE MEMORY ID никто не отменял

Тогда это будет память процесса, что уже не так страшно А я говорю про дампы по нехватке shared-памяти, ее то заметно меньше

Конечно Но и это может не спасти, если в системе одновременно работает много пользователей и широко используется export/import

Вот , что я нарыла в хэлпе по операторуexport to database
The double-digit area ar, which must be specified directly, splits up the rows of the database table into several areas,
so that data clusters with the same identification id can exist multiple times in the data base table. - по-моему из этого следует вывод, что ничего страшного в статическом определении ID нет.. или я не права?

Есть такая транзакция COOIS - инфосистема производственных заказов. Как раз через EXPORT ...IMPORT FROM MEMORY работает.
Пришлось ограничить количество одновременно запущенных отчетов для каждого пользователя до 2-х.
Хорошо, что там BAdI есть

Если бы вы сохраняли в своем Z-кластере, то можно было бы генерить доп.уникальный ключ и в поле AR. Но у вас используется стандартный кластер INDX, что ограничивает подобные действия. Прибавьте sy-uname к ID 'ZFT_CORRESP' и успокойтесь на этом, это самое простое.
И очень желательно после импорта выполнять DELETE FROM DATABASE...

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

А какой ASSIGN после submit'а? Здесь же не вызов подпрограммы.
Если вызываемая программа - Z-программа, то наверное будет более правильно выборку и обработку данных переместить в ФМ, а этот ФМ уже вызывать там где нужно. Тогда отпадет необходимость и в submit'е, и export'е/import'е

спасибо большое всем за информацию... делаю вывод - все-равно придется делать динамический ID - я от этого хотлеа уйти... но , похоже , не получится... delete я безусловно делаю, это обязательно.... ФМ писать , вместо готовой программы, написанной не мной - она очень большая..., было не очень удобно, не было на это времени, поэтому делала через submit, увы...
еще раз всем спасибо....

COOIS - обязательно посмотрю... интересно...но ведь ограничение по пользователям - что самое важное -я там не увижу, если оно сделано уже в БАДИ(((