Так в первоначальной постановке такого же не было

Каюсь - не было. Просто для меня это очевидно было, поэтому упустила.

Продумайте/пропишите два варианта:
1. Поштучное ведение, как написала ichy, с возможность интерфейсного перемещения диапазонами.
2. Ведение как диапазонов так и поштучно, примерно так, как писал я.

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

З.Ы. Надеюсь, что Заказчик не читает данную ветку )

Продумайте/пропишите два варианта:
1. Поштучное ведение, как написала ichy, с возможность интерфейсного перемещения диапазонами.
2. Ведение как диапазонов так и поштучно, примерно так, как писал я.

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

В принципе так и делаю:)
1. поштучный учет уже прописала
2. диапазонами оч туманно получилось
Разработчики отвергают поштучный учет, а диапазонами - хотят, но грят недостаточно информации, чтоб реализовать.
Заказчикам пока ничего не говорила во избежание международного конфликта

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

P.S. кстати, на эту тему есть смешной анекдот..

Но разных типов бланков много, в каждом типе по, например, 999999 штук бланков, операций тоже очень много, одних только приемов-передач в филиально-агентской сети можете себе представить сколько.

Тогда тем более поштучный учет, потому что если вы ко всем этим типам и количеству операций добавите еще какую-то сложную логику работы со множествами, вы там все совсем закопаетесь...

И потом, на сколько я понимаю, операции для любого типа бланков будут приблизительно одинаковые - значит выписываем возможные операции с бланками и добавляем бланку дополнительный атрибут "тип". Если некоторые операции зависят от типа, прописываем и это, и живем себе счастливо ))

P.S. кстати, на эту тему есть смешной анекдот..

И какой?

пока читайте написанное и играйте в карты...

Тогда тем более поштучный учет, потому что если вы ко всем этим типам и количеству операций добавите еще какую-то сложную логику работы со множествами, вы там все совсем закопаетесь...

И потом, на сколько я понимаю, операции для любого типа бланков будут приблизительно одинаковые - значит выписываем возможные операции с бланками и добавляем бланку дополнительный атрибут "тип". Если некоторые операции зависят от типа, прописываем и это, и живем себе счастливо ))

Но разработчики утверждают, что при таком количестве бланков и операций с ними, журнал операций разрастется непомерно, что не есть хорошо

пока читайте написанное и играйте в карты...

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

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

Разработчики отвергают поштучный учет, а диапазонами - хотят, но грят недостаточно информации, чтоб реализовать.

Это в них просто азарт сложного задания говорит ))

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

Хм..звучит так будто заткнуться должна я на этом форуме.
Журнал операций - это неотъемлемая часть учета бланков.
А разработчиков я конечно могу попросить заткнуться, но только смысл в этом?

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

Абсолютно согласна! ))

В вашем случае, если я все правильно понимаю, журнал операций может быть просто отчетной формой, которая, по идее, не должна очень беспокоить разработчиков и размер которой будет проблемой только Заказчика, который хочет видеть этот журнал именно в таком виде