Ещё по теме
Комментарии по теме
Александр Горбульский:
Кирилл Сатарин:
Андрей Тимофеев:
База знаний
Рекомендация. Оптимизация нумерации операций для предотвращения пропусков
При открытии бизнес-операции в Service Desk ей сразу присваивается идентификационный номер. Если сохранять эту операцию не требуется, то в диапазоне номеров фактических бизнес-операций возникает пропуск, который невозможно устранить. Причиной возникновения пропуска является присвоение идентификационных номеров бизнес-операциям при выполнении любого из следующих условий:
- Пользователь заполнил данные в ракурсе “Transaction Processing” (транзакция CRMD_ORDER), но решил, что сообщение в сервисную службу создавать не требуется.
- Пользователь выполнил тестирование в ракурсе “Transaction Processing” и нажал кнопку “Create Support Notification” или “Create Change Request”.
Следовательно, общее количество бизнес-операций в модулях Issue Management, Service Desk и Change Request Management (ChaRM) при создании отчетности окажется некорректным. Независимо от намерений пользователя бизнес-операции присваивается следующий порядковый идентификационный номер, и в нумерации фактически созданных сообщений в сервисную службу возникает пропуск. В данной статье описываются действия, выполнение которых позволит предотвратить возникновение таких нежелательных пропусков и избежать ошибок в отчетах.
Пропуск возникает потому, что установлен флажок “Early No. Assgt” (т.е. флажок активации предварительного присвоения номеров документам). Этот флажок установлен для всех типов операций в сценариях SAP Customer Relationship Management (SAP CRM) в системном ландшафте SAP Solution Manager. (Другими словами, для модулей Issue Management, Service Desk и ChaRM требуется определить значения диапазона номеров.) Таким образом, если используется диапазон номеров, флажок “Early No. Assgt” устанавливается автоматически. Если этот флажок установлен, бизнес-операции присваивается идентификационный номер независимо от того, будет она сохранена пользователем или нет. Далее рассмотрим шаги, которые необходимо выполнить для деактивации этой функции.
Вы хотели бы увидеть полную версию статьи?
Если вы являетесь подписчиком журнала SAP
Professional Journal, пожалуйста,
авторизируйтесь на сайте.
Если вы хотите подписаться на SAP Professional Journal, пожалуйста, обратитесь в редакцию или сделайте заказ
на сайте.
Правила получения тестового доступа к статьям SAP Professional Journal
Кирилл Сатарин (Рейтинг: 1144) 17:46, 08 сентября 2010
Пока никому не понравилось
Олег Точенюк (Рейтинг: 10833) 16:52, 20 сентября 2010
1 инстанция получит номера: 0001 - 0010
2 инстанция получит номера: 0011 - 0020
При запросе номера, по первой инстанции будет сгенерирована заявка с номером 1, а при запросе номера по второй инстанции будет получен номер 11. При этом если пользователи первой инстанции более активные, то их диапазон исчерпается раньше и они получат новый в интервале с 0021 - 0030, так что уже имеем погрешность в среднем на величину размера локального буфера номеров для инстанции. Далее при перезагрузке системы не использованные номера не возвращаются, т.е. система зафиксирует последний используемый номер, пусть это будет 0030 из первой инстанции, а во второй пусть были выбраны только 5 номеров с 0011 - 0015, так вот при загрузке инстанции получат номер с 0031 - 0040 и с 0041 - 0050, т..е. каждая получит по следующему десятку номеров.
В общем виде, я бы считал номера заявок используя SELECT COUNT(*) FROM <таблица> WHERE <Условия> в с каком-нибудь отчете. Все остальные способы исходя из реализации работы с диапазонами номеров в SAP, будут давать погрешности в оценке количества документов/записей.
Пока никому не понравилось