Текущее время: Вт, апр 23 2024, 14:35

Часовой пояс: UTC + 3 часа


Правила форума


ВНИМАНИЕ!

Вопросы по SAP Query и Quick View - сюда



Начать новую тему Ответить на тему  [ Сообщений: 5 ] 
Автор Сообщение
 Заголовок сообщения: USEREXIT_SAVE_DOCUMENT vs USEREXIT_REFRESH_DOCUMENT
СообщениеДобавлено: Вт, июл 17 2012, 18:52 
Младший специалист
Младший специалист
Аватара пользователя

Зарегистрирован:
Ср, май 19 2010, 15:54
Сообщения: 77
Есть необходимость запустить некий код, для успешной работы которого необходимо, чтобы поставка (delivery) была уже сохранена в таблице LIKP/LIPS - там далее выстреливает целая вереница функций, которые подвязаны на SELECT FROM LIKP, а переделывать их нет ну никакого желания ;)

- На момент срабатывания USEREXIT_SAVE_DOCUMENT поставка только в статусе XLIKP или уже произошла запись в LIKP?
- Или для обработки события, когда поставка уже записалась в LIKP, надо использовать все-таки USEREXIT_REFRESH_DOCUMENT?

Заранее спасибо!

_________________
F5-F6-F7-F8


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: USEREXIT_SAVE_DOCUMENT vs USEREXIT_REFRESH_DOCUMENT
СообщениеДобавлено: Вт, июл 17 2012, 23:38 
Младший специалист
Младший специалист
Аватара пользователя

Зарегистрирован:
Чт, июл 28 2011, 20:21
Сообщения: 88
Откуда: Кибертрон
Пол: Мужской
В момент вызова USEREXIT_SAVE_DOCUMENT данные еще не сохранены, но номер поставке (если она новая) уже "выдан". USEREXIT_REFRESH_DOCUMENT вызывается не всегда после сэйва, поэтому в ней не надо ничего делать да и не гарантировано, что таблицы будут обновлены, так как обновляются они в UPDATE TASK.
Можно в USEREXIT_SAVE_DOCUMENT вызвать свою функцию с IN UPDATE TASK. В момент ее выполнения таблицы будут уже сохранены.

Но я бы сделал так: Специально для этого прикрутил бы тип выходного документа к поставке и в программе обработки сделал бы все необходимые действия. Так сохраняется гибкость выполнения, легче при изменении требований заказчика, не трогаем USEREXIT_SAVE_DOCUMENT. В этом случае программа обработки выходного документа вызывается после обновления всех таблиц, блокировка на всех документах еще стоит, ее можно повторить при необходимости, удобнее дебажить. Немного больше работы, но в долгосрочном плане это более оптимально, чем в USEREXIT_SAVE_DOCUMENT.

_________________
Порхаю как пчела, жалю как бабочка.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: USEREXIT_SAVE_DOCUMENT vs USEREXIT_REFRESH_DOCUMENT
СообщениеДобавлено: Ср, июл 18 2012, 12:28 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, сен 09 2004, 07:32
Сообщения: 777
Откуда: Москва
Пол: Мужской
dedzinatajs написал(а):
...
- Или для обработки события, когда поставка уже записалась в LIKP, надо использовать все-таки USEREXIT_REFRESH_DOCUMENT?
...

Для обработки события необходимо использовать обработчик событий - см. БО LIKP & транз. SWETYPV :)
Конечно, это при условии, что результат работы "вереницы функций" вам не нужен в этой самой поставке в диалоговом режиме.

_________________
"Прежде чем сделать что-то, подумай, к чему это может привести..."


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: USEREXIT_SAVE_DOCUMENT vs USEREXIT_REFRESH_DOCUMENT
СообщениеДобавлено: Чт, июл 19 2012, 09:40 
Младший специалист
Младший специалист
Аватара пользователя

Зарегистрирован:
Ср, май 19 2010, 15:54
Сообщения: 77
Ув. nicky555, а можно поподробнее?
Я подумал что можно выставить там BOR Object --> Table --> LIKP, ан нет - не получается найти :(

_________________
F5-F6-F7-F8


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: USEREXIT_SAVE_DOCUMENT vs USEREXIT_REFRESH_DOCUMENT
СообщениеДобавлено: Чт, июл 19 2012, 14:16 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, сен 09 2004, 07:32
Сообщения: 777
Откуда: Москва
Пол: Мужской
Можно, конечно:
Транзакция SWO1, бизнес-объект LIKP:
он имеет ключ (LIKP-VBELN) и ряд событий (в том числе created, deleted, changed).

Транзакция SWETYPV:
настраиваем привязку обработчика событий к событию бизнес-объекта, то есть:
BO-LIKP-CREATED-<тип_получателя>. Здесь <тип_получателя> - любой текстовый идентификатор (если не стартует Workflow).

Обработчик событий: ФМ с определенным интерфейсом или класс, внедряющий интерфейс BI_EVENT_HANDLER_STATIC. Заполняется на следующем экране по Double-Click на строке настройки SWETYPV.

В более изощренном случае событие БО генерится самостоятельно (стандартный ФМ), да и сам БО может быть свой.

Вот, в общем и все шаги простейшего псевдо-Workflow. При вызове обработчика все обновления основных данных завершены, блокировки сняты - можете смело делать выборки по ключу бизнес-объекта и, в целом, крутить его как хочется. Ну, и не забудьте активировать связь (флажок в той же SWETYPV).

Привязать обработчик событий можно также и к созданию документов изменений.
Более подробно - курсы SAP по Workflow. Успехов.

_________________
"Прежде чем сделать что-то, подумай, к чему это может привести..."


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 5 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB