против Энтропии
Немного хитрости и смекалки позволяют делать прямые ссылки на транзакции и объекты настроек в SAP.
Стоит только щёлкнуть по ссылке на сайте или в документе, и в SAPGUI открывается нужная транзакция или раздел.
Баловство без реальной необходимости, хотя…
Вот ниже вполне работоспособные ссылки (на моём компьютере):
Параметры можно рассматривать как некоторый способ неявной передачи данных из одной программы в другую. Нечто вроде “MEMORY ID”, только с более человеческим лицом.
Целый спектр возможность открывается, если использовать Z-таблицы в качестве справочников. Однако, если дать разработчикам полную свободу, то засилье Z-таблиц рано или поздно приведёт к “мусорке”, в которой трудно найти что-либо нужное.
Здесь самое главное предварительно определиться, действительно ли нужен отдельный справочник в конкретном случае. Во многих случая допустимо:
Справочник городов является настроечными данными. Новые создаваемые города попадают в запрос.
Основной таблицей этого справочника является ADRCITY. Средство поиска для собственного употребления – например: CITY_NAME.
В SPRO есть раздел Города в Управлении адресами – SPRO:F999CC4C918CD21197EA0060B0672A3C
Основные транзакции по созданию/изменению/просмотру городов – это SR10/SR11/SR12.
Вот пример, как выглядит окно изменения:
Надо только определиться с диапазоном номеров (подобрать оптимальный подход) – внешний(согласовать формат) или внутренний.
Если вдруг вам нужно удалить город, то тут не всё так просто – есть отчёт SE38:RSADRLSM01, который удаляет в рамках страны все данные (города, индексы, улицы).
Сталкивался с ручной интерпретацией определения корреспонденции.
До этого такие функции я видел только в Z-разработках, но есть, оказывается, в стандарте кое-что вокруг этого.
Сегодня — формулировка об унификации селективных экранов. О, да… это тоже борьба с энтропией.
Часто бывает, что некоторые параметры образуются в некоторые взаимоисключающие группы. То есть в данном примере: следует заполнять или первое+второе поле, или третье+четвёртое поле.
В дополнение к таком селективному экрану можно написать обработчик, который будет выдавать ошибку вида “параметры А и Б не следует заполнять при заполненных параметрах В и Г”. Вариант суров и неоднозначен.
В качестве более красивого решения можно предложить разбавить эти параметры с помощью радиогруппы.
Вот чуть-чуть другой пример. Радиогруппа уже есть, но некоторые параметры имеют смысл только для определённых пунктов.
Во-первых, следует сделать пару добавок в описание селективного экрана:
Добавка “USER-COMMAND flag” требуется только для первого элемента в группе. Цель этой добавки – срабатывание PBO при выборе опции (щелчок мыши).
Добавка “MODIF ID OP1” требуется для группировки полей, чтобы “отвязаться” от количества и имён полей в обработчике экрана.
А во-вторых, добавляем обработчик экрана:
Этот обработчик по сути говорит:
Ничего сложного, а пользователю, надеюсь, будет немного понятней.
Впрочем, это только один из вариантов…
Часто бывает необходимость в рисовании всплывающих окон для получения тривиальных ответов от пользователя.
И, разумеется, рисовать собственные экраны и писать обработчики при таком раскладе – занятие целиком неблагодарное.
Вызов совсем простой:
Выглядит этот экран следующим образом:
Сначала надо определить список полей и начальные значения:
Затем следует вызов этой функции:
Получить введённые значения можно из той же таблицы.
Выглядит этот экран следующим образом:
Для подобного экрана есть вариант: POPUP_GET_VALUES_USER_CHECKED. В этом функциональном модуле (по всей видимости) можно указать callback-подпрограмму для проверки введённых значений.
Сначала определяем варианты ответов:
Затем вызываем функцию и анализируем ответ:
А выглядит это окно следующим образом:
Ко всему прочему есть ещё много встроенных в SAP функций, в том числе и для работы с табличными данными.
… а лучше оно потому, что если его придерживаться, то порядок увеличивается, а беспорядок уменьшается.
С практической точки зрения порядок можно увеличивать до момента, когда он уже начинает вредить “поворотливости”.
В плане контрольных счетов у SAP в бухгалтерии сформировалась достаточно специфическая концепция.
Во-первых. Карточка контрагента.
Контрольный счёт – практически единственное необходимое поле ракурса БЕ из карточки контрагента. Без ракурса БЕ контрагент не может использоваться в бухгалтерии.
А счёт этот контрольный означает:
Понятное дело, что система должна иметь некоторые ограничения, чтоб пользователи не могли по контрагентам проводить на любые счета. Иначе будет хаос.
Во-вторых. Деление в главной книге.
Первоначально для себя необходимо разбить все контрагентские счета в главной книге на общие непересекающиеся группы.
Например:
Авансовые счета – практически всегда отделяют по коду ОГК (A). Таким же образом можно разделить и долгосрочную часть. А остальные — это обычная кредиторская задолженность по разным группам контрагентов. С моей точки зрения должно работать строгое соответствие “группа контрагентов <=> группа контрольных счетов”, жесткое, но не обязательно по принципу “один-к-одному”.
А о авансовых и долгосрочных счетах можно поговорить отдельно.
В группе задолженности резидентов (для примера) может быть выделено несколько субсчетов КР001-Услуги и работы, КР002-Материалы, КР003-Прочие и подобные.
Возникают такие вопросы:
С учетом этих вопросов можно сократить список таких счетов, передав соответствующую аналитику на откуп отчётности.
Список альтернативных счетов
Но если уж вдруг поделили и определились, то возникает понятие альтернативного счёта. Это связано с тем, что поставщик не всегда поставляет только что-то одно. Может он обычно поставляет материалы, но иногда может поставлять услуги, или наоборот. А контрольный счёт в его карточке только один. Перед проводкой на счёт менять контрольный счёт в карточке – этот вариант глуп, хотя и может быть использован в исключительных случаях.
В настройках SPRO список альтернативных счетов ведётся в ракурсе ведения V_THKON, при этом флаг разрешения альтернативного счёта должен быть также задан и в свойствах самого счёта главной книги.
Но какой именно счёт ставить контрольным в конкретной карточке контрагента: любимый(по желанию бухгалтера) или более определённый ? Здесь возникает палка с двумя концами.
С одной стороны, при использовании “любимого” счёта, потребуется вести в настройках все возможные комбинации каждого контрольного с его альтернативными из группы. Максимальное число комбинаций равно N*(N-1), то есть при десяти счетах в группе потребуется ввести до девяноста их комбинаций. А если учитывать межгрупные связи, то прозрачность также не увеличивается. Можно ещё отметить, что этот справочник является настройкой, и поэтому конфигурируется через переносы из системы разработки.
С другой стороны, при использовании “определённого” счёта необходимо в проводках переключать этот счёт на требуемый в каждом конкретном случае (хотя пользователю можно немного помочь в этом расширениями). Но зато список альтернативных счетов выглядит гораздо понятней: только один контрольный счёт из группы (первый?) и остальные как альтернативные к нему. Тем не менее, такой подход не запрещает устанавливать для конкретного контрагента контрольным счет из списка альтернативных – просто другие счета не смогут быть использованы.
Что именно выбрать – уже зависит от особенностей внутреннего бухгалтерского учёта.
Разделение контрагентов по ролям
Как один из альтернативных вариантов можно применять разделение контрагентов.
Если придерживаться схемы “группа контрагентов => группа контрольных счетов”, то вполне допустимо ведение нескольких карточек контрагентов, которые выполняют совершенно разные функции. Например: сотрудник как подотчётное лицо, и сотрудник как покупатель. Такое разделение ещё более допустимо, если учитывать, что такие операции, как правило, обслуживаются разными бухгалтерами или даже разными подразделениями бухгалтерского учёта. Таким образом устраняются связи по альтернативным счетам между группами счетов.
Зачетные операции между такими задолженностями одного контрагента следует проводить только на основании первичных документов (писем, заявлений), как и в случае “взаимозачёта”.
Разрабатывая отчетики на базе ALV можно также обратить внимание на дополнительные аспекты – не всегда простой таблицы бывает достаточно, а рисовать свои экраны не сильно тянет.
Если покопаться в примерах, то можно найти несколько полезных вариантов.
Одна оговорка: в данном случае ALV представлено не своим красивым элементом управления, а ABAP-списком. В стандарте очень много отчётов строятся похожим образом.
Пример можно найти в программе BALVHD01.
Этот отчёт строится на базе функционального модуля REUSE_ALV_HIERSEQ_LIST_DISPLAY.
Основная ALV функциональность присутствует: управление вариантами, сортировки, суммы, группировки, фильтр и прочее.
Иерархичность тут не полная, а всего лишь отношение master-detail, чего в большинстве случаев может и хватить, так как покрывает стандартные отношения типа “заголовок документа – позиции документа”.
Ко всему прочему, такой вывод поддерживает многострочность одной строки (до трёх строк), что позволяет упаковать больше данных по ширине экрана.
Пример можно обнаружить в программе BALVBT01.
Такой вариант реализуется на базе функциональных модулей REUSE_ALV_BLOCK_LIST_INIT, REUSE_ALV_BLOCK_LIST_APPEND, REUSE_ALV_BLOCK_LIST_HS_APPEND, REUSE_ALV_BLOCK_LIST_DISPLAY.
В программе требуется простая последовательность фрагментов: инициализация, последовательное добавление таблиц, вызов показывалки.
Таким образом можно представить несколько независимых наборов данных, с сохранением основной функциональности ALV в рамках отдельных таблиц.