В алгоритме такое учитывать нельзя! Такие вопросы, если они установлены нормативно, нужно решать в комплексе:
1. Нужно отказываться от определения не по породам, а ярусу в неспелых. Поскольку смысл микроуточнений по породе при определении высоты яруса не по ней, а в среднем по ярусу делает его бессмысленным. Ловить 5%, а потом крякать все на +- 10-15% не логично.
2. Нужно ставить номер таблицы запаса не в НСИ (там можно оставить по умолчанию), а в карточке таксации (или заносить их туда автоматом по логическому справочнику). Иначе при появлении новых алогизмов или в других регионах, где это не применимо придется делать свои "версии программы".
Задача потребует переработки систем ввода, контроля и расчетных показателей.
3. Альтернативой для Вас может быть пока:
- либо учет нюансов таксатором с расширением условий контроля по породам;
- либо расширение списка пород до К2-5 (расшиф. Кедр), К6-7 (расшиф. Кедр), К8-10 (расшиф. Кедр) и соответствующие классификационные коды, подобранные с учетом логики классификатора. То если, коды ввода и классификационные разные, а расшифровка одна.

Как и с любыми другими расчетными полями. Нам нужно будет добавлять в структуру БД новое поле, учитывать его в системе обновления БД, делать логический справочник его заполнения. Затем переделывать систему расчета производных показателей.

Я не думаю, что этот алгоритм можно переделать одними SQL запросами. Это как минимум нужно снять программиста с текущих задач, дать ему время вспомнить и поднять алгоритм всей цепочки (а она не ограничивается только тем, что Вы перечислили), а потом вместо того, чтобы реализовать - объяснить Вам как это сделать самому, да еще без вмешательства в исходные коды программы.
А потом еще поддерживать несколько вариантов реализации. Нет, Александр, это не правильный путь. Работоспособные программы получаются решением частных случаев через общие. Если есть в одном месте нюанс, который нужно учесть,то он должен наследником общего алгоритма, а не наоборот.