Система классов – общий для всего ERP механизм, расширяющий описательную часть любых объектов SAP. Одно из первых мест, где можно столкнуться с этим – это учёт в MM. В нём механизм классификации используется для классификации самих карточек материалов, так и для классификации партий, если включён учёт по партиям.
Кратко:
- К объекту в SAP можно присвоить несколько ракурсов его классификации (как правило один)
- Каждый ракурс классификации содержит неограниченное количество предварительно настроенных признаков разного рода, и пользователь может вводить туда данные
- Данные не очень красиво выглядят, не очень красиво хранятся и не очень красиво ищутся
- Не работает система переносов (классы и признаки являются основными данными)
- Старая консервативная разработка
- Кроме пар признак/значения есть управление статусами этой классификации
До сегодняшнего дня непосредственно с системой классов не сталкивался. И вот подвернулся повод разузнать это на деле методом проб и ошибок.
А теперь подробнее.
Для примера создадим классификацию для основных средств, ведь для них стандартной классификации не существует.
Ключи объектов
Сначала мы описываем ключи к нашему объекту. Ключ необходим внутри механизма для адресации объектов и хранения их в таблице, так как для каждого случая ключи могут быть разными, разного типа, состоять из нескольких полей и так далее.
Ведение таблицы SM30:V_CLO (этот пункт есть в SPRO в ветке: Компоненты, общие для всех приложений –> Система классов)
Занятно, что ключи объекта настроены к основным средствам, но вот системы классов нет. Как будто бы начали, но так и не закончили.
В дальнейшем мы будем видеть код нашего объекта в виде примерно такого объединённого ключа:
F00000232100000300000 = F000 (БЕ) + 2321000003 (Номер ОС) + 0000 (субномер) + 0
Нолик на конце – это уже что-то нужное для самой классификации, то ли статус, то ли номер версии. Но по-простому у нас всегда будет нолик на конце.
Вид классов
Теперь к таблице можно создать вид классов. Для этого там же в SPRO можно найти транзакцию O1CL.
К виду классов нужно ещё обязательно заполнить разделы “Статус класса” и “Статус классификации”. Если там совсем ничего не заполнить, то при сохранении будет невнятная ошибка. Так что заполните попроще или скопируйте по образцу, всё равно управление статусами дёргать не будем. Однако имеем в виду – есть какие-то статусы самой классификации.
Если говорить о настройке, то это всё. Все остальные штуковины создаются без настроек непосредственно в каждом манданте.
Признаки
В транзакции CT04 создаём несколько признаков:
В первую очередь задаём наименование и типизацию. Здесь есть два варианта привязки справочника: через список значений и через проверочную таблицу.
Можно заполнить справочник вручную, при этом никаких Z-таблиц создавать не надо.
В этом случае вместо средства поиска будет выскакивать не очень обычное окошко с выбором из списка значений.
Вот так своеобразно, да….
Если настраивать признак через проверочную таблицу, то будет выскакивать стандартное простое средство поиска. Для указания проверочной таблицы надо нажать на кнопку “Другая проверка значений”:
Если на вкладке “Дополнительные данные” указать ссылочное поле, то это не влияет на средство поиска.
Выходит, что присвоить собственное средство поиска сходу нельзя, ну хоть можно присвоить какие-то функциональные модули в оговорённом интерфейсе.
Если в экране классификации ввести код, то вместо него подтягивается текстовое значение. Для измеряемых значений автоматически появляется единица измерения. Есть такие мелкие удобственности в этом очень ограниченном интерфейсе.
Присвоение признаков классам
В транзакции CL02 создаём несколько классов в нужном нам виде класса:
Остаётся только набить признаками наш класс. В каком порядке мы их укажем, в том порядке они и появятся на экране.
На этом с пользовательской настройкой можно закончить и перейти непосредственно к пользовательским операциям.
Классификация
В транзакции CL20N вводим код объекта и классифицируем. Ключ объекта придётся пока “сочинить” самостоятельно.
Штука хитрая: она расклеивает наш номер объекта в ключи для таблицы ANLA и проверяет наличие его в таблице, и если строки в таблице нет – то создать классификацию не удастся.
Если для одного объекта добавить несколько классов, то в нижней части экрана будут общим списком показаны атрибуты. При этом если в средней части в класс ткнуть, то его атрибуты прыгают в начало списка. Вот так просто безо всяких группировочных элементов интерфейса.
Предполагаю, что верхний экран можно настроить до человеческого состояния, так как в некоторых классах есть такая штука:
Хранение
Хранится это всё не очень удобно в специальных таблицах: AUSP, CAWN, CABN. Кроме этого есть функциональный модуль CLAF_CLASSIFICATION_OF_OBJECTS.
Двигаемся дальше
Если оглядеть существующие решения, то можно прийти к выводу, что если в программе SAPLCBCM (в группе функций CBCM) добавить экран (например: 9000) и описать этот экран в O1CL, то можно в транзакции CL20N видеть вместо дурацкого ключа нормальные поля.
В качестве примера можно посмотреть на экран 0108.
Сделал копию экрана и прикрутил в настройках. Результат в-целом удовлетворительный …
После этого остаётся сделать два шага:
- Сделать прямую транзакцию на доступ, не через стандартную же пользователям ходить
- Прикрутить эту транзакцию куда-нибудь в карточку ОС, например в виде кнопки на дополнительном экране
PS. Там в заголовках можно увидеть непонятки в стиле “: Изменение признака”. Есть подозрение, что это огреха перевода – там перед знаком двоеточия должны быть какие-то буквы.
PPS. Поматросил и бросил. Для стандартной функциональности ещё применимо, но для своих разработок – сомнительно.
PPPS. UPD
Привет, Иван. Как всегда пишешь очень интересно и красиво. Но упускаешь детали- вроде для нубов, но разбираться нужно. Пиши как есть, лишнее не украдут. Привожу примеры из текста:
1. «Одно из первых мест, где можно столкнуться с этим – это учёт по партиям в MM.» — в примере ты указываешь данные для основных средств.
2. » В дальнейшем мы будем видеть код нашего объекта в виде примерно такого объединённого ключа:
F00000232100000300000 = F000 + 2321000003 + 0″ — ну укажи ты, что и к чему. Если «F000» — это класс ОС, «2321000003» — номер ОС, а «0» — субномер ОС — почему об этом не написать?
3. » Теперь к таблице можно создать вид классов.» — к таблице ANLA (таблица ОС) при рассматривании материалов? Какой вид классов и с какой целью? А, ну и «статус класса» и «Статус классификации» — это круто… к таблице ANLA (ОСы).
4. Чего-то прикручиваешь, накручиваешь, указываешь таблицы… Что куда прикрутил, какой результат?
Инфа полезная для напоминаний тем кто шарит. Кто не шарит — тупо не осилят и поймут, что ты очень крут.
Извини, если ты хотел всех запутать.. Если нет, возьми на вооружение, что так не пишут.
Цели статьи, кроме демонстрации транзакций — не понял, я понимаю, что не для дебилов, но все же.
1. В том-то и фикус, что в ММ — есть стандартная классификация, а в основных средствах — нет.
2-3-4. Да, сумбурно, согласен, надо переработать. Самая сумбурная заметка, вероятно.
Пишу-то для себя, в том числе и потому что обратной связи нет, а в том числе я часто и сам перечитываю, что записал давно.
А тут ещё и не понравилась мне классификация, разочаровала. Я в ММ с ней практически не работал. И время само-собой тратится, даже на скриншоты с подписями.
Вот читал недавно заметки человека, который написал книгу…. но об этом как-нибудь в другой раз.
Большое спасибо. Хорошо написано, особенно для нас, тех кто только начинает постигать SAP. При реализации у себя наткулся на то, что не дает выбрать в качестве проверочной таблицы таблицу с несколькими ключевыми полями. Подскажите, видимо это ограничение никак не обойти?
Глубоко не копал, но думается всё сделано просто: так как поле заполняется одно, то и ключ должен быть один.
И это поле должно быть уникальным. В противном случае может получиться как-то глупо.
Спасибо, нашел таблицу AUSP, перед этим не мог найти где же связь между значениями признака и классифицируемыми объектами.
Как правило, связь с самими объектами должна храниться в INOB.
В случае классификации партии номер объекта классификации хранится ещё и в MCH1-CUOBJ_BM.