vdd писал(а):
Если коротко, то мое предложение позволяет эффективнее использовать категории для работы с номерной емкостью.
Если развернуто, то:
1) Потому что при эксплуатации выделенный ресурс номерации нарезается на самые различные категории. Есть категории, для того, что бы абон.отдел знал, какие номера можно выдавать на таком то объекте, есть категории номеров, которые выделяются не просто так, а за, различной величины, дополнительные деньги, да и мало ли с какой целью необходимо пометить номера. И бывает, что логически номер должен находится в двух или больше категориях. Так просто удобнее рассматривать множество номеров с разных сторон.
2) Сам выделенный ресурс номерации тоже приходится контролировать. Вот и представьте, что у вас пять выделений ресурса, распределенные по 20 категориям, а вам нужно определить степень использования каждого из выделений. Сейчас, благодаря багу, это было просто - есть пять категорий со всей нумерацией. Есть кнопка "Синхронизировать занятые", которая корректно работала, не смотря на то, что баг. А после устранения бага это будет кошмар - облазить все 20 категорий, выписать из них занятые или свободные по каждому выделению, после чего еще проверить, нет ли номеров, которые в эти 20 категорий не попали, потому что никто не распределяет 5000 номеров по объектам сразу после выделения и никто не гарантирует, что при за три года экплуатации не было ни одной ошибки при внесении номеров в категории.
3) В resource.categories для отлавливания косяков гораздо надежнее указать категории со всей нумерацией, чем объяснять людям, что после создания каждой новой категории надо обязательно не забывать информировать рассчетный отдел, что бы можно было вовремя поправить конфигурацию.
В итоге вы хотите чтобы номер привязывался к первой попавшейся категории ? или к конкретной ? Уникальность номера хотя бы внутр одной категории проверять нужно , или вам вообще это не нужно ?