Справочник городов является настроечными данными. Новые создаваемые города попадают в запрос.

Основной таблицей этого справочника является ADRCITY. Средство поиска для собственного употребления – например: CITY_NAME.

В SPRO есть раздел Города в Управлении адресами – SPRO:F999CC4C918CD21197EA0060B0672A3C

Основные транзакции по созданию/изменению/просмотру городов – это SR10/SR11/SR12.

Вот пример, как выглядит окно изменения:

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

Если вдруг вам нужно удалить город, то тут не всё так просто – есть отчёт SE38:RSADRLSM01, который удаляет в рамках страны все данные (города, индексы, улицы).

Сталкивался с ручной интерпретацией определения корреспонденции.

1. Для определения допустимой и запрещённой корреспонденции
2. Для получения отчётов по корреспонденции (журнал-ордер)
3. Для передачи документов в систему, в которой используются только пары Дт-Кт

До этого такие функции я видел только в Z-разработках, но есть, оказывается, в стандарте кое-что вокруг этого.

(далее…)

Сегодня — формулировка об унификации селективных экранов. О, да… это тоже борьба с энтропией.

Исключающие параметры

Часто бывает, что некоторые параметры образуются в некоторые взаимоисключающие группы. То есть в данном примере: следует заполнять или первое+второе поле, или третье+четвёртое поле.

В дополнение к таком селективному экрану можно написать обработчик, который будет выдавать ошибку вида “параметры А и Б не следует заполнять при заполненных параметрах В и Г”. Вариант суров и неоднозначен.

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

Параметры к параметру

Вот чуть-чуть другой пример. Радиогруппа уже есть, но некоторые параметры имеют смысл только для определённых пунктов.

 

Реализация

Во-первых, следует сделать пару добавок в описание селективного экрана:

 

Добавка “USER-COMMAND flag” требуется только для первого элемента в группе. Цель этой добавки – срабатывание PBO при выборе опции (щелчок мыши).

Добавка “MODIF ID OP1” требуется для группировки полей, чтобы “отвязаться” от количества и имён полей в обработчике экрана.

А во-вторых, добавляем обработчик экрана:

Этот обработчик по сути говорит:

• Для группы полей OP1: При включенной опции rg_opt1 – требуется включить ввод, иначе  — выключить ввод
• Для группы полей OP2: При включенной опции rg_opt2 – требуется включить ввод, иначе  — выключить ввод

Ничего сложного, а пользователю, надеюсь, будет немного понятней.

Впрочем, это только один из вариантов…

Часто бывает необходимость в рисовании всплывающих окон для получения тривиальных ответов от пользователя.

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

Запрос ответа “ДА” или “НЕТ”

Вызов совсем простой:

Выглядит этот экран следующим образом:

Запрос значения или нескольких значений

Сначала надо определить список полей и начальные значения:

Затем следует вызов этой функции:

Получить введённые значения можно из той же таблицы.

Выглядит этот экран следующим образом:

Для подобного экрана есть вариант: POPUP_GET_VALUES_USER_CHECKED. В этом функциональном модуле (по всей видимости) можно указать callback-подпрограмму для проверки введённых значений.

Выбор с вариантами ответов

Сначала определяем варианты ответов:

Затем вызываем функцию и анализируем ответ:

А выглядит это окно следующим образом:

Прочее

Ко всему прочему есть ещё много встроенных в SAP функций, в том числе и для работы с табличными данными.

… а лучше оно потому, что если его придерживаться, то порядок увеличивается, а беспорядок уменьшается.

С практической точки зрения порядок можно увеличивать до момента, когда он уже начинает вредить “поворотливости”.

(далее…)