8.х Доработанная обработка "Подбор номенклатуры"

IMHO Вы получите кучу тормозов и проблем без сколь нибудь полезной отдачи. Зачем вам это? С контролем остатков на складах прекрасно справляется механизм проведения документов. А дрыгать базу по сто раз в минуту из за того, что кто-то где-то подбирает документ на мой взгляд бессмысленная растрата ресурсов сервера и локальной сети.

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

Хм, о таком методе я не подумал. Вполне возможно, что и взлетит. Достаточно будет двух измерений и одного ресурса в регистре без подчинения регистратору. Интереснее всего в данном вопросе - будут ли возникать записи-призраки, когда подбор уже выполнен, а записи из-за тех или иных причин остались...

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

Если обновлять только после подбора - то вполне возможна ситуация, что остаток уже не соответствует действительному. У меня такая ситуация возникала при 5+ операторов. (Клиенты тарились большими партиями и могли выбрать весь остаток в 1000 штук, например)
Поскольку никто не оплачивал решение такой проблемы - не занимался её практическим решением.
Но хотел попробовать реализовать вариант оповещения каждого подключения об изменении статуса остатков (в виде передачи структуры, что и где поменялось - для анализа: а нужно ли обновлять данные)

По идеи - должно было взлететь без тормозов.