да вопрос то не в том чем пользоваться для решения задачи (хотя и не так страшна рекурсия как звучит )

а в том что для практических целей данная постановка (набрать чего-то на опр. сумму) задачи "не взлетает"

вот я предположим согласен с тем что в ~80% "кодить" в общепринятом смысле прогеру 1С и нет необходимости (сделать выборку потом перебором порассовывать куда-то чего-то и вкинуть результаты в хранилища или просто вывести в грид - не высокоаналитическая задача) зато есть необходимость включать моск для отрисовки там самой идеи (бизнес процесса и т.д. как пожелаете)

посему включая моск получаем следующую картину (опять же в подавляющем большинстве случаев)

1. есть отдел занимающийся комплектацией поставок на филиалы (торг. точки, удалённые склады напрямую клиенту и т.д.)
2. есть сформированные потребности точек т.н. "заказы/дефектура/потребность" (там уже или вручную или по мин. остаткам или по планам и т.д.)
3. есть политики резервирования в заказах (категоризация топы бренды и т.д. см. мой первый пост в этой теме)
4. есть политики ограничения заказов (в т.ч. и одна из них которая оглашена в задаче т.е. бюджет - лимит суммы выделяемый на закупки и заказы за опр. период)
5. логистика (сюда вообще пока не заходим) 6. 7. .... энное условия формирования "корзинки" :)


и уж поверьте после применения всего этого комплекса места для (забивки "от фонаря") останется оооочень мало и ломать копья насчет того чем пользоваться при наборе остатка просто не имеет смысла т.к. в любом случае это уже несущественно из-за малых объёмов и некритичности как по временным затратам на выполнение процедур так и для самого бизнеса


вот собственно пару процентов верхнего слоя темы а вы с пузырьков начали

просто не вижу смысла в подтверждении принципа 80/20 когда 80% времени реализации задачи уйдёт на наименее весомую преследуемую цель