Alibek B.Обычные сотрудники напрямую с биллингом не работают, а работают со сторонней CRM-системой, которая взаимодействует с биллингом через API.
Если сможете доказать оракелю-корп, что пользователи сторонней CRM поддаются строгому и проверяемому учету, то, быть может, сумеете уболтать на NUP.
Нет - придется разориться на процессорные.

Alibek B.Или достаточно одной NUP?
Недостаточно.
Oracle - не благотворители, они на своих продуктах бабки зарабатывают.
Все именованные Васи, Пети и SySAdMiN-ы должны быть пролицензированы.

-2-и все клиенты, чьи счета хранятся в системе.
Клиенты БС обычно называются абонентами и не совершают операций по своим лицевым счетам, это ведь не АБСка.
В этой связи их сложно оформить пользователями БС и БД.

Вот если система предусматривает самообслуживание абонентов, тогда еще можно как-то "потолкаться" - но и тут есть варианты в виде сервиса CRM с передачей изменений в БС по команде оператора.

С другой стороны, непосредственно операторов БС может оказаться достаточно много, чтобы процессорная лицензия оказалась выгоднее.

-2-Если предположить биллинг телефонии, то телефонный аппарат это human operating device и все, кто им пользуются подлежат лицензированию.
Телефон не взаимодействует с БД биллинга.
Вообще не взаимодействует.
В биллинг насыпает коммутатор, и насыпает он по факту логи (CDR/EDR), а не разговоры.
Если бы речь шла об IN-платформе - то да, а так...

-2-andrey_anonymousТелефон не взаимодействует с БД биллинга.Приложение клиент-сервер тоже с базой не взаимодействует. Оно только сетевые пакеты формирует. А пакеты в БД попадают через коммутатор.
Даже не пытайтесь :)
БД биллинга и сам биллинг технически НЕ являются необходимым компонентом для предоставления услуги связи.
Клиент-серверное приложение не в состоянии работать без БД.

...а так-то да, можно еще в NUP повключать всех сотрудников энергогенерирующих и энергосбытовых компаний, которые липистричество телефону продают (могут теоретически продать), а также всех китайцев, этот телефон (как и любой другой телефон, в который теоретически может быть вставлена данная sim-карта) собравших.
Впрочем, это будет уже открытое множество "юзверей", которое под правила NUP не подходит :)

Leonid Kudryavtsev(точно не знаю!!!)
Тут многое зависит от функционала биллинговой системы.
Ветхозаветная Классика - это postpaid решение без самообслуживания, когда на вход подаются CDR-файлы (содержит call data record's) от коммутатора (в одном месте тупо на ленте раз в сутки приносили) и банковская выписка (реестр платежей), а на выходе имеем счета за услуги связи.

А дальше начинаются танцы.

Предоплатная система расчетов, к примеру, потребует от биллинга (на самом деле - уже от OSS) разрешать или запрещать предоставлять услугу. Обычно это делается посредством IN-платформы, но "биллинг" (точнее, тарификатор) все-таки участвует, причем часто в реальном времени - тут уже надо тщательно обставляться под NUP и аккуратно договариваться с вендором.

Портал самообслуживания - если заведен непосредственно на биллинг - разом переводит всех абонентов в Named Users.
Если опосредовано (через CRM) - то можно потолкаться, если, к примеру, изменения из CRM в биллинг проталкиваются пакетом а не в онлайне.

Reporting и прочий BI - в зависимости от организации процесса - тоже может потребовать NUP-лицензий либо для всех пользователей, либо только для интеграционной жестянки.
Фрод-контроль, интеграция с бухгалтерией, роуминг, EAI и прочее також надо внимательно рассматривать на предмет нупов.

Короче, геморрой это все не детский. Все известные мне телекомовские биллинги были лицензированы по процессорам, тем более что это позволяет держать на той же железке вспомогательные базейки без дополнительных затрат.

А дискуссию с утенком я затеял просто из врожденной вредности и желания малость побрюзжать ;)

witteА если это отправление (и получение) сообщения через какую-нибудь ESB или MQ?
Если лично абонент любым способом общается с БД (просматривает свой баланс, управляет своими услугами online) - то хоть тушкой, хоть чучелом, но будет NUPом
Если же абоненты общаются с каким-нть CRM, а потом, к примеру, раз в сутки пакет изменений уходит в биллинг через тот же ESB - то абонентов под NUP привязать будет сложно.