Включение истории изменений в собственных документах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(далее…)

Сто лет, или туда и обратно

Маленькое путешествие во времени по мотивам недавних музыкальных открытий.

Первой мне попалась на глаза песня “Вы просите песен” за авторством Саши Макарова в исполнении Юрия Морфесси.

Вы просите песен, их нет у меня —
На сердце такая немая тоска.
Так скучно, так грустно живется,
Так медленно сердце холодное бьется,
Что с песнями кончить пора.

Аудиозапись сохранилась и датируется 1913 годом.

Потрясающая песня, а дошла до наших времён практически в виде фразы-отголоска “вы хочите песен? их есть у меня!”, что является прямой пародией на первую строку песни. Для примера, данную строку наблюдать можно в песнях у группы Ленинград и Аркадия Северного.

И в тот же день второй мне попалась песня из нового альбома Хью Лори с названием “Kiss of Fire”. Инструментальное танго, красивый вокальный дуэт и образные фразы текста меня просто захватили.

“Какая интересная новая песня, пойду загуглю слова”, подумал я. И вот сначала Гугл меня довёл до Луи Армстронга в середину пятидесятых, а затем бросил в начало века, в год 1903.

Меланхолия

Спасибо Гордону и Закрытому показу, что подвинул фильм в очереди на просмотр, а то я его всё откладывал и откладывал. Настоящий фильм, хоть и не идеальный. После фильма посмотрел обсуждение, в целом сумбурное и много оставляющее за кадром.

(далее…)

Про систему классов

Система классов – общий для всего 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-