Ребяты помогите! После изменения поставки этим модулем, а он один на сколько я понял делает отпуск материала, поставка не сторнируется! Там появляется в поле LIKP-VLSTK (С) и всё, труба, не сторнировать после измененя эту поставку. Чтото тут с децентрализованым ведением склада связано видимо, но у нас ведение централизованное, что сделать-то чтобы не происходила такая фигня???

BADI LE_SHP_DELIVERY_PROC, метод CHANGE_DELIVERY_HEADER, что-то типа:

Спасибо! Сильно!

Естественно, поставка не удаляется после того, как произошел отпуск материала. Сначала нужно строрнировать отпуск материала (VL09) , а потом уже саму поставку.

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

Вообще-то речь шла об изменении поставки, а не о создании... Я так понимаю, что BAPI_OUTB_DELIVERY_CONFIRM_DEC не создает поставок, а только делает goods issue к ним. И VL09 не удаляет поставки, а cancels goods issue. Удалять поставку потом надо в VL02N.

Кстати, если ведение склада централизованное, то этот BAPI вообще не годится, т.к. там конкретно сказано:



Попробуйте WS_DELIVERY_UPDATE, здесь пример есть:
https://www.sdn.sap.com/irj/sdn/message ... ID=2957819

ну да (ляпнул чушь ), конечно же нужно читать так: "ОМ созданный с помощью BAPI_OUTB_DELIVERY_CONFIRM_DEC не сторнируется с помощью VL09" (если не сделать соответсвующие дополнения, которые я описал выше - и будет работать несмотря на то, что это БАПИ для Decentralized System).
Все-таки появление БАДИ LE_SHP_*, и LE_SHP_DELIVERY_PROC в частности, придало определенную гибкость LE.

p.s.: кстати в БАПИ BAPI_OUTB_DELIVERY_CONFIRM_DEC используется вызов именно WS_DELIVERY_UPDATE. Ну а что использовать - имхо, дело вкуса и желания.

Не совсем так - использование BAPI и ФМ ведет к разным результатам. Только что прогнала два примера с одной поставкой. Для простоты эксперимента создала поставку и ввела pick quantity вручную, чтобы осталось только goods issue (ОМ кажись по-русски) сделать. Пример с BAPI:



Результат: сторнировать goods issue в этом случае действительно невозможно. Причем это нормальное поведение decentralized warehouse, о чем четко и явно указано вот в этом документе на странице 15:


http://help.sap.com/printdocu/core/Prin ... /LEIDW.pdf

Bот этот пример делает goods issue, который потом можно очень даже замечательно сторнировать в VL09 и поставку удалить в VL02N:



Вполне возможно, что есть и более элегантные пути решения, чем этот ФМ, но мой пойнт в том, что автор просто взял не тот BAPI и все проблемы исключительно из-за этого. Можно, конечно, лезть и править статусы, но зачем ломиться в закрытую дверь?

2 Jelena: ну что тут скажешь:
1. Где гарантия, что после наката очередного пака WS_DELIVERY_UPDATE сохранит тот же интерфейс и функциональность? Согласитесь, что использование недокументированного ФМ несет определенный риск, тем более если речь идет о создании материальных и, возможно, бухгалтерских проводок в системе.
2. А если ОМ будет инициироваться IDOC-ом?

так что мой пойнт в том, что могут быть разные решения одной и той же проблемы, и в зависимости от поставленной задачи и условий более приемлемым может оказаться тот или иной вариант.

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

Олег и Елена или кто-то ещё, может, Вы в курсе чем лучше пользоваться.
У меня децентрализованный WMS, я должен создавать RFC входящие и исходящие поставки.
Хочу воспользоваться существующими БАПИ.
Мне нужно ползоваться вот этими, насколько я понимаю.
BAPI_OUTB_DELIVERY_SAVEREPLICA
BAPI_INB_DELIVERY_SAVEREPLICA

Вопрос в том, что там везде надо указывать номер документа поставки. А что делать, если у меня его ещё нету?

Если есть примеры создания, буду ОЧЕНЬ признателен!

ICQ 247-472-278 (последние правда 2 часа что-то он не работает )

Вы уверены? Там номер поставки является возвращаемым параметром...

Там во всех нужных таблицах кроме HEADER_DEADLINES
нужны номер и позиция поставки.
Если я её не заполняю возвращает ошибку 4 из класса VLBAPI
(Ошибка в документе....)
TABLES
HEADER_PARTNER = HEADER_PARTNER
* HEADER_PARTNER_ADDR =
HEADER_DEADLINES = HEADER_DEADLINES
ITEM_DATA = ITEM_DATA
ITEM_ORG = ITEM_ORG

OlegDm, Вы не знаете, что минимально надо заполнить в этой бапи, чтобы создалась Вх.Поставка?
Заранее спасибо!

с этой БАПИшкой я не работал. Может кто рабочий пример выложит, но если этого не произойдет, то для размышлений следующее:
1. В BAPI_INB_DELIVERY_SAVEREPLICA , после расфасовки входящих интерфейсных параметров по внутренним таблицам, сама собственно поставка создаеться с помощью ФМ GN_DELIVERY_CREATE
2. Пример использования (и заполнения соответствующих внутр.таблиц) ФМ GN_DELIVERY_CREATE в случае вход.поставок ты можешь найти в отчете RM06EANL
3. Сопоставив код BAPI_INB_DELIVERY_SAVEREPLICA и RM06EANL думаю можно найти истину

Спасибо, буду разбираться
Кстати обнаружил, что в этой же группе функций есть чудный ФМ
BAPI_IBDLV_CREATE_FROM_OBDLV
Вроде по параметрам то, что надо.
Если разберусь, выложу чем создал

Мы как раз используем только IDoc для ОМ без каких-либо осложнений.