Необходима обработка "Подбор номенклатуры" аналогичная типовой, только проще (только номенклатура и ее остатки). Но необходимо, чтобы остатки в соответствующей колонке обновлялись сразу после подбора какого либо количества в документ. Когда будет открыто несколько подборов, от разных операторов, надо чтобы каждый из них видел остаток товара за минусом уже отобранного в документы у всех операторов. Это нужно для того, чтобы операторы не могли выбрать товар в минус.

У кого какие мысли есть на это счет?

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

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

Доля правды в этом естьЮ но тем не менее. Например в 7 базе у нас так сделано и вполне прилично работает. При подборе отобранный товар собирается в 1 внешний дбф файл и по нему же и происходит проверка. После окончания подбора из этого файла соответствущие позиции удаляются.
В 8 я думал сделать такой механизм через регистр сведений. Насколько будет затормаживаться подбор?

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

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

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

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