Дано:

Есть транзакция FF67, у которой есть специальное окошечко для значений “по умолчанию”. Там в том числе есть важное поле – “Вид последующей обработки”. Для правильной работы по шаблону должно стоять значение режима равное 4.

Есть глупые пользователи, которым если давать такие вещи в руки, то можно получить разные числа на выходе.

Наблюдаю следующее решение этой проблемы:

(далее…)

К вопросу о том, почему иногда полезно почитать документацию.

За страшными словами “разграничение вручную” и “объект разграничения” на самом деле скрывается всего лишь навороченный механизм по типу долгосрочных проводок.

(далее…)

Если транзакция является отчётом, то у неё есть экран выбора.

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

А теперь – в подробностях…

(далее…)

Есть два основных направления отслеживания истории изменения какого-либо объекта.

1. Историчность данных

В этом случае мы принимаем за основу, что нам интересно знать состояние объекта на любую заданную дату: год назад, месяц назад, вчера, сегодня. И знание такой информации важно для осуществления бизнес-операций.

Реализуется такое в БД посредством включения даты в ключ таблицы (BEGDA/ENDDA) и написания многих строк на ABAP, разруливания этого добра на экранах.

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

Модуль Управление кадрами HCM практически полностью использует этот подход, там всё зависит от даты (имя, должность, организационное присвоение, наименования, мероприятия, отсутствия, документы, счета).

2. Журналирование изменений

В этом случае мы принимаем за основу, что нас интересует только текущее состояние объекта, но мы хотим “на всякий случай” иметь историю изменения.

Эта история нужна в первую очередь для контроля за действиями пользователя пост-фактум. Как правило, её используют только в качестве улик, при разборе проблем. Информация о предыдущем состоянии объекта не может использоваться в бизнес-операциях, хотя я встречал в жизни и такие Z-кейсы.

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

Самый базовый подход предполагает использование четырёх дополнительных полей: ERNAM (кто создал), ERDAT (когда создал), AENAM (кто изменил), AEDAT (когда изменил). Дело совсем нехитрое. Однако нас может и должен заинтересовать характер вносимых изменений, то есть список всех изменений, включая старые и новые значения полей:

Пользователь IVAN 13 декабря 2012 года в 14:15 GMT в объекте ANLA (ключ  001234567890) в таблице ANLA поменял поле TXT50 (Наименование основного средства) со значения «Мой компьютер» на «Просто компьютер».

Именно такой подход используется практически во всех основных данных ERP (ОС, Счёт, Дебитор, Кредитор), поэтому есть некоторый стандартный механизм в SAP, который используется везде, где это необходимо.

И именно о нём пойдёт речь под катом.

(далее…)

Напутствия начинающим абаперам на ниве взращивания отчётов.

Черновик статьи.

Есть заметки или наводки? – в комментарии

(далее…)

Система классов – общий для всего ERP механизм, расширяющий описательную часть любых объектов SAP. Одно из первых мест, где можно столкнуться с этим – это учёт в MM. В нём механизм классификации используется для классификации самих карточек материалов, так и для классификации партий, если включён учёт по партиям.

Кратко:

• К объекту в SAP можно присвоить несколько ракурсов его классификации (как правило один)
• Каждый ракурс классификации содержит неограниченное количество предварительно настроенных признаков разного рода, и пользователь может вводить туда данные
• Данные не очень красиво выглядят, не очень красиво хранятся и не очень красиво ищутся
• Не работает система переносов (классы и признаки являются основными данными)
• Старая консервативная разработка
• Кроме пар признак/значения есть управление статусами этой классификации

 

До сегодняшнего дня непосредственно с системой классов не сталкивался. И вот подвернулся повод разузнать это на деле методом проб и ошибок.

А теперь подробнее.

(далее…)

В любом языке неявные преобразования типов всегда были особыми песнями. И у ABAP есть пара фенечек.

И вот пример лесенки:

1. Есть Excel, в котором в ячейке невооружённым взглядом написано:

0

2. Если посмотреть на ячейку вооружённым взглядом, то вместо нуля уже виднеется значение:

-0.0299854666809551

3. Если это значение считывать в ABAP в текстовую переменную, то уже получается:

-2.99854666809551E-02

Предполагаю, что Excel строит из себя умного, и намекает, что числа с таким количеством знаков после запятой следует хранить только с экспонентой

Если присваивать это значение напрямую к типу P, то возникнет ошибка преобразования.

4. Это текстовое значение мы сначала присваиваем типу F и получаем:

-2,9985466680955100E-02

5. А затем уже присваиваем его типу P и получаем

0,03-