Стандартная кассовая книга хоть и хороша собой, однако имеет ряд нюансов:
Предположим, что у нас есть отчёт в виде Z-разработки.
Кэширование данных отчёта нам может пригодиться в нескольких случаях, например:
Для начала допустим, что:
Бороздя просторы своих подписок, наткнулся между делом на нечто. В чём суть этого бессмысленного и беспощадного ненормального приёма программирования:
Требуется выполнить деление двух целых чисел с точностью до четырёх знаков после запятой, но используя только оператор простой замены подстроки.
В качестве базового алгоритма использован Нормальный Алгоритм Маркова, который можно реализовать на любом языке программирования. Входные значения – унарные числа.
Обуреваемый скептицизмом, решил переложить на язык ABAP.
Реально работает!
Пример кода выложил отдельно в виде SLNK.
В редакторе кода есть кнопка “Структурная печать”.
По умолчанию она выправляет отступы в тексте, однако там есть ещё опция преобразования регистра. Если душа лежит к одному из этих подходов – вперёд и с песней.
Вот наблюдаем некоторый бардак:
А вот что стало после обработки:
В окне поиска есть галочка “Регулярные выражения”:
По регулярным выражениям можно учебники писать, однако краткая вводная информация доступна по пумпочке справа от искомого текста. Можете дополнительно полистать документацию, но не обязательно саповскую – регулярные выражения (Regular Expressions, RegExp, регэкспы) используются в огромном количестве других систем в разных вариациях.
Вот несколько примеров, которые обычным поиском просто не решаются:
Поиск всех слов, начинающихся на букву Z:
\<Z\w*\>
Поиск всех “слов” из трёх знаков:
\<…\>
Поиск строк – любых вариантов из списка (bsis, bsas, bsik, bsak, bsid, bsad):
bs[ia][dks]
В практике программирования бывает необходимость выделить несколько однородных карточек в особую группу. Счета главной книги для особого использования, группа контрагентов входящих в особый “холдинг”, список материалов-синонимов и так далее.
Хорошо, если такую группировку получается легко реализовать на базе самих карточек.
Один из универсальных подходов – применение наборов (используются в Report Writer). Здесь особо без разницы, какие именно карточки хотите сгруппировать – тип данных можно указать вручную.
Немного хитрости и смекалки позволяют делать прямые ссылки на транзакции и объекты настроек в SAP.
Стоит только щёлкнуть по ссылке на сайте или в документе, и в SAPGUI открывается нужная транзакция или раздел.
Баловство без реальной необходимости, хотя…
Вот ниже вполне работоспособные ссылки (на моём компьютере):
Параметры можно рассматривать как некоторый способ неявной передачи данных из одной программы в другую. Нечто вроде “MEMORY ID”, только с более человеческим лицом.
Целый спектр возможность открывается, если использовать Z-таблицы в качестве справочников. Однако, если дать разработчикам полную свободу, то засилье Z-таблиц рано или поздно приведёт к “мусорке”, в которой трудно найти что-либо нужное.
Здесь самое главное предварительно определиться, действительно ли нужен отдельный справочник в конкретном случае. Во многих случая допустимо:
Справочник городов является настроечными данными. Новые создаваемые города попадают в запрос.
Основной таблицей этого справочника является ADRCITY. Средство поиска для собственного употребления – например: CITY_NAME.
В SPRO есть раздел Города в Управлении адресами – SPRO:F999CC4C918CD21197EA0060B0672A3C
Основные транзакции по созданию/изменению/просмотру городов – это SR10/SR11/SR12.
Вот пример, как выглядит окно изменения:
Надо только определиться с диапазоном номеров (подобрать оптимальный подход) – внешний(согласовать формат) или внутренний.
Если вдруг вам нужно удалить город, то тут не всё так просто – есть отчёт SE38:RSADRLSM01, который удаляет в рамках страны все данные (города, индексы, улицы).