Вообще не ММ-щик даже близко. Но так, интереса ради.
Там же все равно отрабатывает экранная логика постобработки. Если проводить параллель с другими процессами, например, с финансами. То там отсутствие какого-то значения (ну допустим МВЗ) станет ошибкой при обработке первичного вида затрат в проводке. Но если создать нужное МВЗ в параллельно открытом режиме и дойти до сохранения, то в исходном режиме нужный элемент справочника уже доступен. Это означает, что проверка корректности и существования этого элемента происходит заново через проверочные таблицы или чейн-логику.
В вашем случае введенная инфозапись все равно не видна, отчего можно предположить более сложную и глубокую логику проверки по стеку - на момент запуска проверки "вердикт" об отсутствии уже вынесен, а вывод сообщения об ошибке уже становится лишь формальностью (например, вообще откуда-то из буфера читает, если буфер непустой).
Экран надо "передернуть", чтобы заставить мозги обнулиться. Что если не сохранять временно заказ на поставку и не заходить в него потом повторно, а просто покинуть проблемное экранное место, чтобы потом туда вернуться? Например, затереть материал, поставщика оставить. Перещелкнуть. Потом вернуться и ввести материал. Это заставит заново анализировать инфозапись на предмет существования.
Более сложный вариант. После создания инфозаписи не затереть материал, а подставить вместо него какое-то существующее техническое значение DUMMY чучело. После чего с DUMMY обратно перещелкнуться на нужный материал (только что созданный). При этом сам заказ с инфозаписью с участием чучела запретить к сохранению с помощью существующих средств проверки (чтобы его по ошибке случайно не оставили и не протащили до конца). Ну это все было в порядке генерации бреда
потому что теперь надо еще решать задачу наличия в инфозаписи поставщик + DUMMY. Вообще мне кажется, что это перспективное направление мысли, если всю мою дурную энергию направить в нужное русло.
А вообще, как написал LKU, правильно динамически сразу создавать при проверке. Но тогда это привело бы к постоянному созданию отсутствующей инфозаписи (а что если не все отсутствующие надо создавать?) Тогда уже пахнет целым диалогом. Впиливать в ME21N целый диалог может быть сложно. Но почему его не впилить в начале?
Тогда процесс может выглядеть так: рядом с ME21N создается условная оболочка ZME21N_KONS. После примитивного селекционного экрана и ввода поставщика и материала система анализирует наличие планируемой к использованию инфозаписи. Далее при отсутствии спрашивает: создать? Если ответ ДА, то через вызов транзакции ME11 создаете инфозапись. После этого сразу же вызывается голая ME21N без BDC, без OK-кодов. Просто call transaction. Вы останавливаетесь на вводе заголовка заказа, как было бы при запуске обычной ME21N. Далее после сохранения или выхода просто ловите нужную таблицу BDC-мессаг от ME21N, на основе которой покидаете исходную оболочку до sap меню или остаетесь в оболочке для последующего ввода нового заказа. Это уже примитивные бантики.
Вход
Регистрация
FAQ пользователя
Поиск
