Коллеги, признавайтесь, у кого «любимая» часть работы — это отслеживать очередные внезапные изменения в электронных счетах-фактурах от КГД?
Недавно ИС ЭСФ преподнесла очередной сюрприз: вместо привычного тега <term> в XML прилетает <payment_form>. К счастью, SAP Казахстан обычно оперативно выпускает ноты (3749582), но тут разработчиков подстерегают классические грабли обратной совместимости.
При попытке прочитать или обработать из архива старые ЭСФ, система намертво падает в дамп CX_ST_MATCH_ELEMENT с текстом: «Expected element-end: ‘term’». Или даже просто сформировать PDF по ним. Компилятор Simple Transformation просто отказывается понимать старый XML по новой схеме.
Для целей SAP PP появилась необходимость в создании в системе SAP материалов-аналогов. Для этого в транзакции PIC01 несколько материалов были объединены в один FFF-класс
Транзакция PIC01 объединение материалов FFF-классом
Однако, столкнулись с проблемой, что новый ППМ — MRP Live (транзакция MD01N) иногда не видит этого объединения и при обработке потребности на материал 76833, создает заявки без учета остатков материала 76834. При этом время от времени он работает нормально.
При этом старый ППМ (транзакция MD02) работает прекрасно, а современный MRP Live пасует перед логикой FFF-классов.
Долго проверяли Z-расширения, настройки и ноты, но ни к какому результату не пришли.
В процессе отладки выяснилось, что происходит вызов BADI MRP_DISPATCHER_BADI – метода DISPATCH_CREATE_TASK. В этом методе есть изменяемый параметр – таблица CT_MATS_TO_PLAN, в которой приходит перечень материалов и заводов, по которым происходит расчет ППМ. Далее, на основе этого списка создается список задач для параллельной обработки в AMDP-процедурах.
При этом в этой таблице CT_MATS_TO_PLAN есть поле group_id, с помощью которого можно указать запускать некоторые материалы в рамках одной TASK и тогда все работает прекрасно.
Осталась только техническая реализация – сгруппировать материалы-аналоги по FFF-классу (поле MARA-IMATN), добавить нужные материалы, если ППМ запустили только по одному материалу 76833. Так как поле group_id имеет тип RAW16, воспользовался вычислением MD5-хеша значения поля IMATN с помощью метода cl_abap_message_digest=>calculate_hash_for_char.
Таким образом, с помощью небольшого расширения добились правильной работы MRP Live с материалами-аналогами.
А вы сталкивались с тем, что MRP Live ведет себя иначе, чем классический ППМ? Какие еще «сюрпризы» находили в MD01N?
Даже сейчас, в эпоху Fiori, есть некоторые плитки, которые на самом деле являются приложениями FPM. К примеру понадобилось скрыть ряд полей в «Изменение заказов ТОРО»
Первой мыслью было расширить конфигурацию компонентов. Для этого нажал правой кнопкой мыши по интересующему полю — «Техническая справка»
Многим знакома ситуация: нужно быстро сопоставить данные из нескольких таблиц (например, заголовок документа и его позиции), но старая добрая SE16N умеет работать только с одной. Приходится либо идти в DB02 писать SQL-запрос, либо мучаться с Eclipse.
В системах на базе HANA (включая S/4HANA) есть «секретное оружие» — транзакция SE16H.
В чем её главные фишки?
Table Joins: Вы можете на лету связывать несколько таблиц (Inner/Outer Join).
Агрегация: Можно сразу просуммировать значения или сгруппировать данные прямо в запросе.
Скорость: Она работает напрямую с мощностями HANA.
В предыдущих частях мы проделали путь от осознания необходимости изменения процесса подписания XML-файлов ЭЦП (часть 1) до нахождения рабочего механизма с помощью Egov Mobile(часть 1) и NCALayer (часть 2) для обеспечения соответствия законодательству Республики Казахстан.
Несмотря на работоспособность, решение с NCALayer оказалось не очень удобным при большом количестве подписываемых документов и интенсивной работе с порталом КГД.
В этой заключительной части мы рассмотрим вариант, который устраняет этот недостаток, существенно повышая комфорт пользователя.
Часть 3: Локальный Сервер Подписи — Скорость и Удобство
Этот вариант основан на том же сервере подписи, который входит в комплект разработчика NCALayer, но который функционирует непосредственно на компьютере пользователя.
В первой части мы определились с необходимостью изменения процесса подписания XML-файлов с помощью ЭЦП с целью обеспечения законодательства РК.
Я разработал решение, которое позволяет подписывать XML-файлы в мобильных приложениях Egov Mobile или Egov Business с помощью сервиса Sigex.
Дополнительно я реализовал возможность подписания XML через NCALayer. Этот механизм также может успешно использоваться для работы непосредственно из SAP.
Использование ЭЦП граждан Казахстана — давно не новость, особенно в решениях для работы с электронными документами (ЭСФ, СНТ, Виртуальный склад). Стандартное решение SAP, описанное в ноте 3380565, использует сервер подписи, куда сотрудник должен выложить свой личный сертификат ЭЦП.
Подобный запрос возник и у консультантов HCM для подписания документов перед отправкой в ЭСУТД.
К сожалению, данный подход противоречит закону РК «Об электронном документе и электронной цифровой подписи», согласно которому нельзя передавать закрытые ключи ЭЦП другим лицам. Незаконная передача закрытого ключа электронной цифровой подписи другим лицам влечет штраф на физических лиц в размере десяти, на должностных лиц, субъектов малого предпринимательства или некоммерческие организации – в размере пятнадцати, на субъектов среднего предпринимательства – в размере тридцати, на субъектов крупного предпринимательства – в размере ста пятидесяти МРП.
Я поставил цель найти законное и удобное решение. В качестве альтернативы мною был разработан вариант подписания с использованием приложений Egov Mobile или Egov Business с помощью сервиса Sigex.
