Меня зовут Виктория Мохирева, я консультант SAP MM. Сегодня расскажу о том, как мы с командой решили колоссальную задачу инвентаризации — пересортицу товаров — с помощью интеграции SAP с большой языковой моделью (ИИ).
Вот как бывает в обыденности магазина: пришёл товар, на учете кружка, а на полке по факту тарелка. Начинается танец с бубном из таблиц, сверка номенклатур и постоянные акты. Чтобы автоматизировать подбор правильных групп для пересортицы, мы написали инструмент, который позволяет общаться с ИИ напрямую из SAP GUI. Решение получилось достаточно компактным и элегантным. А под капотом у нас — архитектура, ключевые куски кода и логика, которые помогли нам превратить «регулярный ручной труд» в интеллектуальный диалог с машиной, и теперь у нас не разрозненная масса товаров, а сформированные по определенным параметрам логичные группы.
Задача: помочь пользователю «спросить правильно»
Главная проблема при внедрении ИИ в корпоративные процессы — не в том, чтобы отправить запрос, а в том, чтобы сформировать его контекстно. Мы не хотели давать пользователю пустое текстовое поле, куда он напишет «ну, в общем, подбери группу». Нам нужно было:
1. Предоставить удобный интерфейс для ввода промпта прямо в SAP.
2. Автоматически подгружать в запрос данные по текущей инвентаризации (материалы, описания, товарные отделы).
3. Сохранять всю историю взаимодействия для аудита и отладки.
4. Сделать так, чтобы разработчик мог легко масштабировать решение на другие бизнес-процессы.
Архитектура решения: класс LCL_PROMPT_EDITOR и его связь с глобальным API ZCLMM_AI_API
Сердцем системы стал локальный класс LCL_PROMPT_EDITOR. Почему локальный? Потому что на этапе прототипирования и тесной интеграции с конкретным циклом инвентаризации (программа редактора промптов) это позволило нам быстро итерировать, не создавая десятки глобальных типов.
Однако локальный класс — это лишь «тонкий клиент» для пользовательского ввода. Всю «тяжелую» работу по коммуникации с внешним миром берет на себя глобальный класс ZCLMM_AI_API. Это наш центральный шлюз для всех звонков к ИИ.
В конструктор класса мы передаем важные параметры контекста: подразделение (IV_DEP) и таблицу параметров (IT_PARAMS), где хранятся пары “Номер материала — Текст материала”. Это ключевой момент — ИИ получает не просто вопрос, а структурированные данные для анализа.
abap
METHOD constructor.
mt_params = it_params.
mv_dep = iv_dep.
ENDMETHOD.
1. Удобство ввода: Кастомизированный TextEdit
Мы использовали стандартный элемент CL_GUI_TEXTEDIT, но настроили его под специфику: включили моноширинный шрифт (SET_FONT_FIXED). Это важно, когда ИИ возвращает табличные данные или коды материалов — они не “плывут”, как в пропорциональном шрифте.
abap
METHOD init_editor.
” Инициализируем текстовый редактор
CREATE OBJECT mo_text_editor
EXPORTING
parent = mo_editor_container.
” Настраиваем параметры редактора
mo_text_editor->set_toolbar_mode( toolbar_mode = 1 ).
mo_text_editor->set_statusbar_mode( statusbar_mode = 1 ).
mo_text_editor->set_font_fixed( ).
” Загружаем шаблон по умолчанию
load_default_template( ).
ENDMETHOD.
Чтобы пользователь не мучился с формулировками, мы добавили кнопку “Загрузить шаблон”. Метод LOAD_DEFAULT_TEMPLATE заполняет редактор структурированным промптом, в который уже подставлены текущие материалы и контекст подразделения. Это резко повышает качество ответов ИИ.
Вот несколько вариантов промпта для использования:
Вариант 1.
«Сформулируй аналитический подход к классификации товаров внутри категории. Необходимо разработать правило формирования идентификатора группы пересорта, который имеет структуру: префикс (XX.YYY), за которым следует код материала и код логического объединения. Объясни, по какому принципу товары попадают в те или иные логические блоки. На основе этого принципа проведи разбивку всего ассортимента и создай схему нумерации, позволяющую однозначно определить принадлежность любого товара к конкретной группе пересорта».
Вариант 2.
«Требуется описать логику кодирования групп пересорта в формате “XX.YYY.{материал}.{логика}”. Нужно объяснить, как товары группируются внутри своей категории. Используя эту логику, необходимо обработать полный перечень товаров и предложить итоговый принцип присвоения номеров, чтобы можно было четко идентифицировать, к какой группе относится каждая единица товара».
Вариант 3.
«Разработай методологию присвоения кодов группам пересорта согласно маске “Префикс.Код_материала.Код_группы”. Опиши механизм распределения товарных позиций в разрезе категорий и подгрупп. Примени данную логику ко всему объему данных и на ее основе составь схему кодификации, которая позволит классифицировать любой товар по заданной группе пересорта».
2. Интеграция с ИИ: Метод SEND_PROMPT_TO_AI
Этот метод — основной боевой модуль. Он выполняет три действия:
· Сохраняет промпт на контент-сервере (для архива).
· Пишет лог в БД.
· Отправляет запрос в AI.
В коде видно, что мы не лепим всё в кучу, а строго разделяем ответственность. Локальный LCL_PROMPT_EDITOR отвечает за интерфейс и пользовательскую сессию, а за HTTP-вызовы, JSON-сериализацию и обработку таймаутов отвечает глобальный ZCLMM_AI_API. Это позволяет, например, исправлять ошибки в логике отправки или менять провайдера ИИ, не трогая код сотен локальных редакторов.
3. Надежность и прозрачность: Логирование всего и вся
Для интеграции с ИИ прозрачность критична. ИИ может ошибиться, и бизнес-пользователь должен иметь возможность спросить: “Почему он предложил именно эту группу?”.
Мы реализовали двухуровневое сохранение:
· Контент-сервер (UPLOAD_PROMPT_TO_CS) : Сам промпт сохраняется как txt файл на content server. Это гарантирует, что мы всегда знаем, какой именно текст был отправлен модели, даже если кодировки в логах БД “посыпятся”.
· База данных (ZMM_T_AI_PROMPT) : Здесь хранятся метаданные: TASK_ID (уникальный GUID), дата, пользователь, статус, короткий текст ответа. По TASK_ID всегда можно найти полный промпт на контент-сервере.
4. Эргономика: Обработка команд пользователя
Пользовательский интерфейс управляется через стандартную панель инструментов CL_GUI_TOOLBAR. Все действия (SEND, CLEAR, TEMPLATE, EXIT) обрабатываются в методе PROCESS_USER_COMMAND. Это классический подход Model-View-Controller в миниатюре, где класс редактора выступает контроллером.
5. Чистота памяти: Зачем нужен метод FREE
В ABAP важно следить за памятью, особенно в долгих сессиях. Мы не полагаемся на сборщик мусора, а явно освобождаем графические компоненты (CONTAINER, EDITOR, TOOLBAR) при выходе. Это предотвращает утечки памяти (memory leaks) и зависание gui-статусов.
Результаты и взгляд в будущее
Внедрение этого инструмента позволило нам:
1. Сократить время обработки формирования групп на 95%. Пользователь больше не ищет группы в справочниках, а просто проверяет предложенный ИИ вариант.
2. Унифицировать запросы. Шаблоны промптов гарантируют, что ИИ получает данные в нужном формате.
3. Получить прозрачность. Мы всегда можем провести аудит: какой запрос был отправлен и какой ответ получен по каждому TASK_ID.
Следующий шаг — вынести ядро редактора в отдельный глобальный класс (например, ZCL_AI_PROMPT_EDITOR) и повесить на него BADI. Это позволит подключать его к разным бизнес-процессам (закупки, продажи, претензии) без переписывания кода, просто передавая разные параметры и шаблоны.
Спасибо за внимание!
Автор: VikiToryStory
