Это всё здорово конечно, но фактически тут идёт речь о полностью отдельном алгоритме ценообразования ("ценозадания" наверное правильнее). Вероятно этот способ можно применить где-то ещё кроме ризо...
Вся беда здесь в том, что для того, чтобы сделать этот "ещё один алгоритм" надо либо дописывать в куче мест костыли (типа if...then...else...) либо делать рефакторинг всего приложения и вводить понятие "ID-механизма ценозадания", выносить всю эту кухню в отдельный модуль, так чтобы калькулятор вообще не знал - как вычисляется цена, просто функция, на вход которой подаются тупо все параметры калькулятора, а эта функция внутри (исходя из заданного для этого принтера и/или материала и/или клиента и/или "и т.д." ID механизма ценозадания уже подгружала этот самый алгоритм (шаги которого должны быть формализованы для того, чтобы его (или его подвид, или полностью новый алгоритм) можно было добавить в систему через дилог, а не путём дописывания кода...
Первый вариант - это будет слишком, там и так (из-за эволюционного развития системы, при котором функционал постоянно расширялся и всё это реализовывалось без рефакторинга и таким образом, чтобы была обратная совместимость с сущецствующими заказами) костылей хватает...
А второй вариант - об этом я уже писал... делать рефакторинг только это части - глупо, а делать полный - нет ни смысла, ни времени, ни желания...
Итого - сорри...
А что касается "окна с фактическим тиражом одного вида", то для этого есть поле "кол-во экземпляров". Это поле актуально, когда модуль расчёта кол-ва листов находится в режиме 2 и 3 -" расчёт кол-ва листов исходя из ручного задания кол-ва изделий на листе" и "расчёт.... исходя из вычисленного кол-ва изделий на листе". Значение в поле "кол-во экземпляров" и определяет тираж одного вида. Единственное что - для сложных и/или двухсторонних цветностей (в которых надо использовать несколько мастеров) нужно помнить, что кол-во видов "больше", больше пропорционально "кол-ву мастеров на цветность"...
В режиме модуля расчёта кол-ва листов, где кол-во листов задаётся явно, специально оставлена возможность произвольно задавать кол-во листов и кол-во мастером. К примеру, может быть заказ, в котором всего 1000 листов, но по факту это 400 одного вида, 500 другого и 100 третьего... В этом (при использовании явного задания) случае можно всё это дело уместить в одном СЗ... В этом месте "тулить" окно с описанием "тираж одного вида" бессмысленно, так это не одно число, а три...
Что касается фактического кол-ва мастеров, единственное более-менее простое и эффективное решение, это добавить (в редакторе цветностей) к понятию цветность свойство "кол-во мастеров" и далее, уже в калькуляторе, умножать кол-во мастеров калькулятора (фактически это фиктивное число во всех случаях кроме 1+0 и 1+1 со своим оборотом... кстати - тоже отдельный случай 
- тут видимо надо делать "1+1 обычный" и "1+1 свой оборот"... и цены задавать отдельно... и идея твоя с коэффициентами тут получает "исключение"...) на значение "кол-во мастеров" из свойства цветности СЗ....
Кароче сложно всё это))))) У нас тут не НИИ с бюджетом от налогоплательщиков... Идей масса по поводу учёта и автоматизации полиграфии, вопрос только в том, что вложенное в их реализацию время и средство должны окупиться...
