SQ01 Устаревший инфо-запрос

После редактирования инфо-набора, инфо-запрос при попытке редактирования может выдавать сообщение – “Разница между запросом и инфо-набором”. А при попытке изменения произойдет дамп “Exception condition “NOT_FOUND” triggered”

Читать далее «SQ01 Устаревший инфо-запрос»

HR_MAINTAIN_MASTERDATA не сохраняет отдельные записи ИТ при проведении мероприятий

Была поставлена задача – проводить мероприятия в системе при помощи HR_MAINTAIN_MASTERDATA. Мероприятия работали корректно. После проведения все инфо-типы записывались. Однако, при проведении увольнения инфо-типы 0000 и 0001 не сохранялись. Ошибки при этом никакой не возникало, на первый взгляд все отрабатывало штатно. Пробовал менять параметр LUW_MODE, сбрасывал буфер перед вызовом ИТ, запускал в отдельном потоке и прочее. Результата это никакого не дало.
Нашел два выхода из этой проблемы:

Читать далее «HR_MAINTAIN_MASTERDATA не сохраняет отдельные записи ИТ при проведении мероприятий»

Ошибка CX_HRPA_VIOLATED_PRECONDITION

В ходе расширения отчета HRULPAY2, возникла необходимость вставить запись в Z инфо-тип. Для этого был использован ФМ HR_INFOTYPE_OPERATION. Но программа упорно падала в дамп в классе CL_HRPA_MASTERDATA_FACTORY, а именно при атрибуте a_is_initialized = true. Данный флаг взводился при заполнении DAQ поля стандартным ФМ HR_RU_DAQ_PAY2_ADR, и возможности его убрать не было.
Быстрое гугление показало, что данная ошибка была из-за проблем с PS буфером, и его надо просто инициализировать заново. Для этого можно было использовать подпрограмму do_nothing (sapfp50p) . Однако, дамповать стала уже после нее.

Читать далее «Ошибка CX_HRPA_VIOLATED_PRECONDITION»

Дамп по тайм ауту

Если программа вываливается по тайм ауту, то один из способов устранения проблемы( считаем, что оптимизация не возможна) является использование ФМ TH_REDISPATCH .

Также можно изменить параметр ‘rdisp/max_wprun_time’ в транзакции RZ11. Параметр применяется без перезагрузке сервера.

Ошибка в отладчике при одинаковом наименовании глобальных и локальных переменных.

Сегодня прилетел дамп по одной старой разработке. Собственно ошибка была понятна по описанию, суть не в ней. Но чтобы убедиться точно, в правильности выводов по ошибке, решил поставить точку в коде недалеко от строки дампа и посмотреть что да как.
Каково же было мое удивление, что находясь внутри цикла  LOOP AT gt_data ASSIGNING <fs_data>. Field-symbol в отладчике отображался как еще не присвоенный, при этом было видно, что на самом деле с ним было все в порядке. Т.е. проблема была именно в отладчике и именно с <fs_data>. Остальные Field-symbol работали корректно, инклуд активировался без ошибок.

Читать далее «Ошибка в отладчике при одинаковом наименовании глобальных и локальных переменных.»

Добавление нового поля в таблицу с записями.

В результате тестирования разработки оказалось, что при выборке из Z* таблицы выбираются не все значения.
В таблице у нас находятся 15 записей. В se11 мы видим, что у пяти записей в поле del_flag = ‘X’, у десяти del_flag пустой.

Далее выполняем три запроса к таблице:

В результате имеем: все 15 записей в таблице lt_table_1, 5 записей с del_flag = ‘X’ в таблице lt_table_2 и ТОЛЬКО 5 записей в таблице lt_table_3 с del_flag ‘X’. Куда же делись еще 5 записей, которые должны были выбраться в таблицу ls_table_3 ?

Читать далее «Добавление нового поля в таблицу с записями.»

CALL TRANSACTION ‘QE01’

В одной из программ потребовалось вызвать транзакцию QE01 ввести там данные и вернуться в исходную транзакцию. Но в некоторых случаях вместо возврата в исходную программу, возвращалиcь в меню SAP. Оказалось, что транзакция в некоторых случаях вызывала другие при помощи LEAVE TO TRANSACTION, причем экраны были практически идентичны. А LEAVE очищает стек вызовов, и после выполнения транзакции просто некуда было возвращаться. В нашем случае, если были частичные партии, вызывалась транзакция QE14. Проблему решили тем, что теперь мы вызываем две транзакции в зависимости от наличия частичных партий QE01 и QE14 соответственно. Проблема с возвратом в исходную программу решена.

Ошибка при экспорте данных в XLSX из ALV

При выгрузке данных стандартным функционалом ALV возникла ошибка Удаленный компонент: часть/xi/sharedStrings.xml

32461e5e-9472-4373-ad9f-d924eddf952d

Оказывается, проблема была в спецсимволах в строках для вывода. В нашем случае, ALV не понравилась решетка #. Решение на май 2018 только одно – удалить спецсимволы или попытаться выгрузить в другой формат.

SELECT … FOR ALL ENTRIES и DISTINCT

Необходимо было разобраться, почему запрос  не получает все записи из БД. Сам запрос довольно простой. Казалось бы, ничего не предвещало беды.

Запрос:

Однако вместо 15-ти записей возвращалось всего 5.

Читать далее «SELECT … FOR ALL ENTRIES и DISTINCT»