Таки есть случайные числа в ABAP

Нашлась случайно фишка по получению случайного числа:

Random

* Create a random number generator to return random
* numbers in the range of 1..{String Length}:
CALL METHOD cl_abap_random_int=>create
    EXPORTING
        seed = CO_SEED
        min = lv_min
        max = lv_max
    RECEIVING
        prng = lo_prng.

 

По большей части забава для написания примитивных игр на АБАПе, но может быть использована в алгоритмах криптования и рядом с ними.

А нашлась такая цитатка в книге “ABAP Cookbook, Programming Recipes for Everyday Solutions” за авторством некоего James Wood.

В остальном в бесплатной главе не нашел ничего особенного.

Купить PDF-версию за 70 долларов меня лично жаба душит. Вообще их политика, когда PDF стоит как и бумажный эквивалент, мне совсем не нравится. Вернее там даже не PDF, а какая-то странная веб-версия (с защитой от копирования и всё такое).

А возможно там есть кое-что интересное, очень хотелось бы полистать вот это:

3.3 Introspection with ABAP Run Time Type Services …………………… 98
3.3.1 ABAP RTTS System Classes ………………………………………. 99
3.3.2 Working with Type Objects …………………………………….. 100
3.3.3 Defining Custom Data Types Dynamically …………………… 102
3.3.4 Case Study: RTTS Usage in the ALV Object Model ……….. 104

 

7.2 Transaction Processing with SAP LUWs … 235
7.2.1 Introduction to SAP Logical Units of Work … 235
7.2.2 Bundling Database Changes in Update Function Modules … 239
7.2.3 Bundling Database Changes in Subroutines … 242
7.2.4 Performing Local Updates … 244
7.2.5 Dealing with Exceptions in the Update Task … 245

 

7.5 Tracking Changes with Change Documents ……………………………. 268
7.5.1 What Are Change Documents? …………………………………. 269
7.5.2 Creating Change Document Objects ………………………….. 269
7.5.3 Configuring Change-Relevant Fields ………………………….. 273
7.5.4 Programming with Change Documents ……………………… 274

М-м-м…

Расширения в ведении таблиц – транзакция SM30

Как это нередко бывает в системе требуются собственные справочники.

Первым делом делается соответствующая таблица ZRATES в транзакции SE11, затем она заполняется данными и используется в нужных разработках (Z-программах, расширениях, средствах поиска и так далее).

Потом уже в связи с тем, что записи надо изменять, включать в перенос – создается ведение таблицы посредством генератора.

Однако рано или поздно надо её отдавать конечному пользователю, а так как проверок в SM30 практически никаких не делается, то вероятность ошибки имеется.

Даже в самой примитивной таблице-справочнике в стиле [код + название] можно делать логические ошибки – добавлять записи с одинаковыми названиями. Ключом понятное дело является Код, а проверка на уникальность стандартно делается только по ключу. Так как же запретить пользователю вводить неверные данные ?

(далее…)

Практика использования утверждений ASSERT

Стыдно признаться, но я не использую (но стремлюсь использовать) такие конструкции:

ASSERT [ [ID group [SUBKEY sub]]  [FIELDS dobj1 dobj2 …] CONDITION ] log_exp.

Вот пример простого использования:

assert  i_debet = i_kredit.

Смысл очень простой: если условие не срабатывает, то программа сразу выпадает в осадок – прерывание.

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

(далее…)

Удаление дубликатов во внутренней таблице

В такой строке кода нет ничего удивительного:

delete adjacent duplicates from lt_table.

Здесь всё просто и понятно. Дубликаты удаляются, уникальные записи остаются.

Однако если попытаться с помощью добавки comparing удалять дубликаты только по нужным полям, то есть свои тонкости:

delete adjacent duplicates from lt_bseg comparing lifnr zuonr.

Тонкость первая: Дубликаты могут и не совсем удалиться. Удаление будет происходить только в сортированной последовательности. Таким образом результат будет слабопредсказуемым. То есть из последовательности А-А-Б-Б-А-А будет создана последовательность А-Б-А.

Тонкость вторая: Дубликаты удаляются после первого совпадения. Таким образом во внутренней таблице будет оставлено именно первое совпадение.

Следовательно вместо вышеуказанного примера кода всегда следует писать примерно так:

sort lt_bseg by lifnr zuonr zfbdt.
delete adjacent duplicates from lt_bseg comparing lifnr zuonr.

Больше полей в операторе SORT даёт большую предсказуемость и адекватность результата. Добавка сортировки по дате (ZFBDT) уточняет, что останется самая ранняя (первая) запись из всех .

Массовое изменение счетов в OB_GLACC12

Кое-что об основных счетах главной книги я уже говорил (тут: https://entropii.net/?p=317), а теперь поподробнее расскажу о массовом изменении счетов.

Счета массово можно изменить в транзакциях OB_GLACC11/12/13.

В качестве примера могу предложить задачу такую: расставить флаг “Просмотр отдельных позиций” на всех счетах, где он не стоит. Произошёл у меня такой “прокол”. Оказывается, что именно поэтому может не существовать строка проводки в таблице BSIS – раньше с таким не сталкивался.

(далее…)

Кое-что о настройке SPRO (часть 2) – упрощение доступа

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

Первая часть лежит тут: Кое-что о настройке SPRO (часть 1) – расширение SPRO и добавление собственных таблиц

(далее…)

Кое-что о настройке SPRO (часть 1) – расширение SPRO и добавление собственных таблиц

Да, именно так. хотя SPRO и является основной транзакцией настройки, но и её тоже можно немножко настроить.

В качестве предыстории этой статьи я взял для себя несколько проблем:

Во-первых, в практике внедрения как правило появляются настроечные таблицы, которые нужно периодически вести в транзакции SM30. Для красоты и полноты картины они должны быть видны в транзакции SPRO.

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

В-третьих, иногда мне очень лениво  заходить отдельно в настроечный эталонный мандант. 

Изменяем SPRO своими руками

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

(далее…)

Новости в ABAP

Вот пробежала ссылочка на днях: http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/18115

Очуметь! Не прошло и десяти лет! Наконец-то двадцать первый век наступил !

Особенно в числе прочих порадовала вот эта диаграммка:

ABAP 7.02

То есть: стало больше функций и !!наконец-то!! можно использовать вложенные выражения!

Я когда на язык ABAP переходил с Delphi/Pascal, то долго бился головой об стол, сетуя на ущербность языка и среды разработки. С тех пор появился новый редактор и новый отладчик, а теперь и язык хоть как-то стал ближе.

Раскраска ALV по ячейкам в ‘REUSE_ALV_GRID_DISPLAY’

Стараюсь в написанных мною отчётиках использовать ‘REUSE_ALV_GRID_DISPLAY’ почаще. Текст вызова кочует из программы в программу методом копи-паста. Но вот до раскраски дело обычно не доходило.

Спросил тут у сотрудника, который вроде как что-то недавно делал что-то подобное. А он мне ответил, что там всё так сложно и нетривиально.

Копнул, попробовал и сходу всё заработало. Запишу себе, чтоб не забыть.

В программу понадобилось внести:

1. Прописать в выходной внутренней таблице специальное поле:

data: begin of  it_detail_line.
              …
              data: cellcolors TYPE lvc_t_scol.
data end of it_detail_line .
data: it_detail like it_detail_line OCCURS 0 WITH HEADER LINE.

 

2. Прописать это поле при вызове ALV

alv_layout-coltab_fieldname = ‘CELLCOLORS’.

CALL FUNCTION ‘REUSE_ALV_GRID_DISPLAY’

              IS_LAYOUT                = alv_layout

3. Сделать раскраску по собственному условию

loop at it_detail.

Data ls_cellcolor TYPE lvc_s_scol.
clear it_detail-cellcolors.
if it_detail-d_wrbtr < 0.
              ls_cellcolor-fname =  ‘D_WRBTR’.
              ls_cellcolor-color-col = ‘6’ .
              ls_cellcolor-color-inv = ‘0’ .
              ls_cellcolor-color-int = ‘0’ .
              APPEND ls_cellcolor TO it_detail-cellcolors.
endif.


MODIFY it_detail.
endloop.

Запускаю и вижу, что раскрас произошел успешно.

image

Пошёл, пожалуй, стукну сотрудника чем-нибудь тяжёлым…

Багофича в кишках SAP

Использовал тут в одной программке FM ‘FI_ITEMS_MASS_CHANGE’. Вроде как хорошая помогалка. Мне нужно менять только поле BSEG-ZLSPR.

С помощью этого модуля я массово менял бухгалтерские документы с памятными позициями ТАП (созданные из транзакции F-47). Всё вроде почти нормально. Даже прикрутил в выходной форме теперь любимый мной BAL.

Но когда я натравил туда документы платежного требования (из транзакции F-59, код ОГК = P), то изменения не сохранялись, а в сообщениях появилась ошибка:

Данные пакетного ввода для экрана SAPMF05L 0306 отсутствуют.

№ сообщения 00 344

Вот и развалился внутренний пакетный ввод на транзакции FB02.

Стал искать внутри, нашел загвоздку в FM ‘NEXT_DYNPRO_SEARCH’.

В табличке T019 делается выход на запись:

A    K    X        303

Хотя по факту он должен выходить на запись:

A    ‘ ‘    P        306

Если пакетник запускать в отладке в видимом режиме, то видно, что включается именно 306 экран, и никак не 303.

Просто потому, что там кое-что прописано напрямую в коде, а именно все ОГК за исключением оговорённых считаются = ‘X’.

Поискал ноты на этот счёт – не нашел ничего стоящего.

Ну и непонятен подход к глотанию успешного сообщения. Внутри обнаружил код, что если ловится из пакетника сообщение F5 300, то это сообщение глотается, и BAL выглядит куцо. В принципе можно добавить дополнительный код, типа если сообщений ввобще нет, то добавить туда сообщение F5 300.