Рекомендация. Оптимизация нумерации операций для предотвращения пропусков
Автор приводит простую и эффективную процедуру настройки для предотвращения пропусков в нумерации уведомлений о поддержке, запросов на изменение и идентификаторов в модуле Change Request Management (ChaRM).
При открытии бизнес-операции в 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” устанавливается автоматически. Если этот флажок установлен, бизнес-операции присваивается идентификационный номер независимо от того, будет она сохранена пользователем или нет. Далее рассмотрим шаги, которые необходимо выполнить для деактивации этой функции.
Оформите подписку sappro и получите полный доступ к материалам SAPPRO
Оформить подпискуУ вас уже есть подписка?
Войти
Обсуждения 2
Комментарий от
Кирилл Сатарин
| 08 сентября 2010, 17:46
Комментарий от
Олег Точенюк
| 20 сентября 2010, 16:52
1 инстанция получит номера: 0001 - 0010
2 инстанция получит номера: 0011 - 0020
При запросе номера, по первой инстанции будет сгенерирована заявка с номером 1, а при запросе номера по второй инстанции будет получен номер 11. При этом если пользователи первой инстанции более активные, то их диапазон исчерпается раньше и они получат новый в интервале с 0021 - 0030, так что уже имеем погрешность в среднем на величину размера локального буфера номеров для инстанции. Далее при перезагрузке системы не использованные номера не возвращаются, т.е. система зафиксирует последний используемый номер, пусть это будет 0030 из первой инстанции, а во второй пусть были выбраны только 5 номеров с 0011 - 0015, так вот при загрузке инстанции получат номер с 0031 - 0040 и с 0041 - 0050, т..е. каждая получит по следующему десятку номеров.
В общем виде, я бы считал номера заявок используя SELECT COUNT(*) FROM <таблица> WHERE <Условия> в с каком-нибудь отчете. Все остальные способы исходя из реализации работы с диапазонами номеров в SAP, будут давать погрешности в оценке количества документов/записей.