При прогоне ППМ теряется связь резервирования и заявки.

Входные данные:

Из PS создаются 2 документа резервирования:
резерв. 1212, мат. 11111, кол. 50, дата 01.08.08
резерв. 2121, мат. 11111, кол. 100, дата 01.08.08

после выполнения ППМ и обработки резервирования на выходе из ППМ создается 1 документ -
заявка на закупку мат. 11111, кол. 150, дата 01.08.08.

Задача: как можно отключить объединение одинаковой потребности при прогоне ППМ, т.е.
по примеру описанному выше на выходе должно быть 2 заявки:

заявка на закупку 333, мат. 11111, кол. 50, дата 01.08.08
заявка на закупку 334, мат. 11111, кол. 100, дата 01.08.08

Задача 2:

Как можно добавить во вновь созданную заявку аналитику - номер резервирования, по которому
была создана эта заявка, либо как еще можно установить (не потерять) связь - резервирования
и заявки:

Например: заявка на закупку 333, мат. 11111, кол. 50, дата 01.08.08, резервирование 1212.

Есть предположение, что это возможно реализовать при помощи BADI MD_PURREQ_CHANGE, но

неизвестно, как определить точку внедрения.

Спасибо, с уважением, Виктор.

В ППМ4 мат-ла, для которого нужна отдельная потребность,
1 - Только отдельная потребность (Разузлование спецификации/вторичная потребность) Поставили?

Хотел бы поднять тему.
только есть одно но :
резервирования создаются не из PS, а вручную на заказ ТОРО.

Есть решение проблемы ?

Для ТОРО никак. А зачем?

Зачем. Зачем =)
хочется ППМ-ом рождать заявку равной потребности со своей аналитикой по торовским заказам и т.д.

MD09 не предлагать =)

Почему так безапеляционно ?
Если использовать настройки то не получится. это я знаю.
Вопрос скорее в том есть ли бадишка какая-нибудь позволяющая не объединять потребности. Может кто знает или пользовал ?
Сам пока не смог найти.

Измените партию на точную и будет у вас 1:1 потребность и плановый заказ.

Размер партии EX не делает две заявки под разные потребности попавшие на один день.

А зачем на заявках аналитика по заказам? Закупщик все равно должен купить все. А если все не получается, то ППМ все равно не определит - кому дать, а кому нет:)

не будет если потребность на один и тот же день попадает.


В зависимости от объекта ремонта может выбираться поставщик материалов. Один из тривиальных случаев - география объекта ремонта.
Т.е. закупщику необходима детальная информация о потребности.

Если география разная - то делайте разные заводы или хотя бы разные области ППМ
Про детальную информацию - это тоже не ответ. Зачем она нужна? В разовых случаях - можно псомотреть какие заказы ТОРО генерят потребность. Но систематически закупщик не должен смотреть для кого закупается. Если у вас не так, то вопрос - почему...

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

1) Делай закупку на разные склады и добавь их в разные области ППМ. Тога заявки будут разные.

имеется ввиду склад = заявитель ?

или как-то по другому?

Ну да. Т.е. если есть два разных заказа ТОРО у которых потребность на один день, но на них должн быть две заявки - то на уровне позии компонент указывайте разные склады для потребности.

не хотелось бы так делать. может есть бади который я изначально искал? =)

...уж больно знакомые буквы
А если по делу:+1, к тому же в этом случае, при обработке изменений потребности, поступающих от заказчика, не нужно будет гонять ППМ по заводу и обрабатывать все стопицот позиций, а всего лишь запустить прогон по конкретному складу
А там ещё и с оценённым запасом можно поиграться...