Приветствую, коллеги.

Тема материалов неоднократно поднималась на данном форуме, но вопросы, однако, остались... Так, например вопрос с объединением/разделением потребности (OPUV, галка "ГрупповаяЗаявка").

Входные следующие: Структура подразумевает ведение операций закупки и компонентов материалов к ним, причем компоненты группируются по одной дате потребности внутри одной операции.

1) Автоматом создавать резервирование + заявка к СПП из PS.
В случае с разделением потребности, имеем отношение: 1 заявка на 1 компонент материала. Внутри каждой заявки есть возможность прописать операцию и СПП. Т.е. получаем аналитику потребности в разрезе операций и контролируем исполнение.
Проблема в обработке большого количества заявок (увеличение объёма работы снабженцев и усложнение процесса сгласования через обратную связь в Workflow...).
В случае с объединением потребности имеем отношение: 1 заявка на все компоненты материала внутри сетевого графика.
Проблема в том, что даже в деблокированные заявки (в индикаторе деблокирования стоит галка "фиксация для ППМ") система позволяет вносить новые позиции игнорируя разработку запрета внесения изменений после деблокирования (отрабатывает только на существующие компоненты материалов). Есть ли возможность создавать новую заявку на новые компоненты если старая заявка уже деблокирована? Может как-нибудь докрутить всё тот же индикатор деблокирования?... Т.к. очень хочется иметь потребность с разделением по операциям, а не на весь сетевой график сразу.

2) Автоматом создавать только резервирование к СПП и далее через прогон ППМ создавать заявки (без объединения потребности в OPUV).
В этом случае получаем искомое разбиение по операциям для удобства контроля сроков поставок, здесь ППМ очень помогает.
Проблема в том, что ППМ схлопывает потребность внутри одной заявки (по дате потребности, материалу и СПП) и нет возможности сохранить ряд аналитик в пользовательских полях и кое-какие проблемы в части ведения ТОРО (на одну дату по одному материалу на один СПП может быть несколько позиций). От этого варианта отказались, т.к. хочется сохранить целостность схемы ведения потребностей как для PS так и для PM

Кто как решал эту задачу?