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

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

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

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

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

(далее…)

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

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) уточняет, что останется самая ранняя (первая) запись из всех .

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

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

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

(далее…)

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

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

(далее…)

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

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

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

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

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

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

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

(далее…)

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

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

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

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

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

Стараюсь в написанных мною отчётиках использовать ‘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.

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

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

Использовал тут в одной программке 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.

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

Ещё один из подходов к массовому вводу всякой всячины. Однако он годится только для пакетного ввода и не касается остальных способов, таких как BAPI.

(далее…)