WS_DELIVERY_UPDATE зачищает даты при изменении нескольких поставок в цикле

[Fotina]

Загружается файл, на основе данных из файла формируется заказ, по которому автоматически создается поставка.
Затем транзакция SNPM ( это такая беда, реализация учета по серийным номерам) обрабатывает эти поставки и формирует по ним отпуск. Проблема в том, что эта SNPM-транзакиця изменяет даты в поставке, чего делать нельзя. Эксперименты и наблюдения показали, что если поставку сначала изменить (в принципе, чтобы было заполнено дата изменения), а потом уже обрабатывать SNPM-транзакцией, то даты не изменяются. Причем этот эффект не зависит, запускается SNPM-транзакция вручную или в программе как ФМ.
Поэтому решили перед SNPM-транзакцией обрабатывать поставки ФМ WS_DELIVERY_UPDATE, устанавливая дату фактического отпуска материала.
И все бы хорошо, когда поставка одна обрабатывается этой ФМ. Но когда в цикле - во всех обработанных поставках, кроме последней, почти все даты, кроме даты фактического отпуска материала, пустые! Проверяла в дебаггере - создается поставка нормально, все даты есть.
В структуре, которая передается в WS_DELIVERY_UPDATE, задала явно все даты и установила признаки соответствующие - никакого эффекта.

CLEAR: lw_vbkok, lc_vbupd_err.
lw_vbkok-vbeln_vl = <lw_sertxt>-vbeln_vl.
lw_vbkok-vbtyp_vl = 'J'.
lw_vbkok-borgr_kzwad = 'X'.
lw_vbkok-wadat_ist = <lw_billing>-date.
lw_vbkok-wadat = <lw_billing>-date.
lw_vbkok-kzwad = 'X'. "Confirm planned goods issue date
lw_vbkok-lddat = <lw_billing>-date.
lw_vbkok-KZLDDAT = 'X'. " Change Loading Date

CALL FUNCTION 'WS_DELIVERY_UPDATE'
EXPORTING
VBKOK_WA = lw_vbkok
SYNCHRON = 'X'
COMMIT = 'X'
IMPORTING
EF_ERROR_ANY_0 = lc_vbupd_err

Порылась в интернетах - тоже нигде не нашла, чтобы кто-то сталкивался с такой проблемой.
ЧТО я не так делаю??? :?

Единственное, что нашла - в примерах нескольких не передают COMMIT = 'X', а используют после вызова, если нет ошибок
COMMIT WORK AND WAIT.
но мне это не помогло...

[Fotina]

В процессе разбирательств выяснилось, что поставка портится не при редактировании новой поставки. А при создании нового заказа.
Заказы создаются через BAPI_SALESORDER_CREATEFROMDAT2
По заказу автоматически создается поставка. И когда выполянется BAPI_TRANSACTION_COMMIT, то изменяется поставка, созданная  ранее.  :o

[Uukrul]

По заказу автоматически создается поставка. И когда выполянется BAPI_TRANSACTION_COMMIT, то изменяется поставка, созданная  ранее.  :o

Ну смотрите данный модуль WS_DELIVERY_UPDATE отмечен как вызываемый дистанционно, Может при вызове передать типа так: CALL FUNCTION 'WS_DELIVERY_UPDATE' DESTINATION 'NONE' ну и дальше ваши параметры. Как бы если вы вызвали уже коммит для предыдущей поставки, новый заказ с новой поставкой никак не связан с предыдущей, то такого быть не должно если честно.

[Fotina]

Да однозначно такого быть не должно.

В общем, в мое случае все решилось до безобразия просто. Ну если не считать 2 недели, потраченные на поиски.

Я собрала номера поставок и даты к ним в таблицу. ФМ  WS_DELIVERY_UPDATE_2 вынесла в процедуру (это я раньше сделала, просто оставила так). После того, как создала все заказы, прошлась по этой таблице и изменила даты в поставках. И все хорошо.

"Это САП, детка!" ....  (дальше нецензурно)

[Fotina]

Ну смотрите данный модуль WS_DELIVERY_UPDATE отмечен как вызываемый дистанционно, Может при вызове передать типа так: CALL FUNCTION 'WS_DELIVERY_UPDATE' DESTINATION 'NONE' ну и дальше ваши параметры. Как бы если вы вызвали уже коммит для предыдущей поставки, новый заказ с новой поставкой никак не связан с предыдущей, то такого быть не должно если честно.

Uukrul получается, что портит данные не вызов в явном виде WS_DELIVERY_UPDATE' , а последующий вызов какого-то стандартного ФМ, который создает новую поставку. Что интересно, из всех данных "портятся" только даты. Такой вот интересный глюк...

[Uukrul]

какого-то стандартного ФМ, который создает новую поставку. Что интересно, из всех данных "портятся" только даты. Такой

Да скорее всего какая-то внутренняя таблица не чиститься, было как-то дело одно, там оставалась одна табличка после вызова бапишки не обнуленная ну и соответственно при следующем вызове, проводилось немного не то, что надо, т.е. данные предыдущего документа попадали в новый. Но в SAP имело смысл писать только найдя 100% что это проблема кода.

[Fotina]

Ну смотрите данный модуль WS_DELIVERY_UPDATE отмечен как вызываемый дистанционно, Может при вызове передать типа так: CALL FUNCTION 'WS_DELIVERY_UPDATE' DESTINATION 'NONE' ну и дальше ваши параметры. Как бы если вы вызвали уже коммит для предыдущей поставки, новый заказ с новой поставкой никак не связан с предыдущей, то такого быть не должно если честно.

Кстати, попробовала. добавила в вызов DESTINATION 'NONE' как в бапишку, создающую заказ, так и в WS_DELIVERY_UPDATE.  Никакого эффекта.
Собственно, это и не удивляет. Даты зачищаются именно в момент автоматического создания поставки по новому заказу. А к этому у меня никакого доступа нет. Разве что только если через user-exit'ы поставки и т.п.