Сбыт (SD)

[NachDenken]

может кто  сталкивался ?
возникает при фоновом выполнении, при прямой отладке все ок.
копаю что вызывается из MCV_STATISTICS_DELIVERY..

[Uukrul]

Нашел две ноты но все на системы до 4.5, обе типа связаны с определением целевой валюты как я понял... у тебя что версия системы до 4.6?

[Dmitriy]

Нашел две ноты но все на системы до 4.5, обе типа связаны с определением целевой валюты как я понял... у тебя что версия системы до 4.6?

Аналогично...
А BAPI вообще с какой версии появились в SAP?

[Dmitriy]

Все, нашел, с 3.1.

[Uukrul]

А BAPI вообще с какой версии появились в SAP?

Ну вроде как в 4.5 предложили идеологию.. но на самом деле все же все равно сводится к вызову ФМ.

[NachDenken]

ситуация усложнилась, оказывается не зависит от фонового или диалогово режима,
эта ошибка возникает при первом вызове бапишки, почему когда дело доходит до MCV_STATISTICS_DELIVERY туда передается структура поставки с заполненным только номером поставки, и все (ни мандант ни пользователь ни сбытовая организация не заполнены) поэтому для пустой сбытовой организации не может найти целевую валюту из (tvko),
но стоит запустить повторный сеанс для поставки, то на вход MCV_STATISTICS_DELIVERY приходит уже заполненная структура...
копаю далее

[Uukrul]

эта ошибка возникает при первом вызове бапишки, почему когда дело доходит до MCV_STATISTICS_DELIVERY туда передается структура

Интересный вариант, а система то хоть какая?

[Uukrul]

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

[NachDenken]

версия 7.0
ну про чтение надо подумать

[Dmitriy]

Если я правильно понимаю суть вопроса, то на вход BAPI_OUTB_DELIVERY_CHANGE вы подаете только параметр DELIVERY (номер), а на входе ФМ CV_STATISTICS_DELIVERY структура likp при первом запуске пустая...

[NachDenken]

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

[Uukrul]

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

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

[NachDenken]

окно, окно
мне наоборот кажется логичным

[Dmitriy]

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

А может быть такое, что при "первом" запуске объект существует лишь виртуально? А после коммита где-то в конце вашей программы поставка появляется в БД и затем уже корректно считывается и доступна для изменения...

[Uukrul]

окно, окно
мне наоборот кажется логичным

Нет, не логично.. окно оно контекст как бы на сервере один... так как это одна и та же регистрация, вот если бы это был второй логин, то тут как бы логично, а так, совсем не логично что в новом окне все уже типа работает, у тебя ж пулы загруженных данных как бы общие и почему оно в соседнем окне работает, а в предыдущем нет?1 Короче где-то что-то таки случилось 

[Dmitriy]

100% что-то случилось!
Если поставка уже существует, то данные должны считываться корректно.

[Uukrul]

Если поставка уже существует, то данные должны считываться корректно.

Ну это надо таки прочитать данные, а потом их обновить...

[Dmitriy]

Ну это надо таки прочитать данные, а потом их обновить...

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

[NachDenken]

коллеги,
поставка к этому времени конечно существует,
читать то оно конечно можно,
только вот почему нормально срабатывает в новом окне, и там также подается только 1 номер поставки на вход, и затем структура нормально заполяется,
 а то, что не срабатывает в контексте первого процесса, то до вызова бапишки там идет вызов еще другой бапи (сторно отпуска материала по поставке) возможно _портится_ среда да так, что стандартная MCV_STATISTICS_DELIVERY лишается на входе структуры.

[Uukrul]

коллеги,
поставка к этому времени конечно существует,
читать то оно конечно можно,
только вот почему нормально срабатывает в новом окне, и там также подается только 1 номер поставки на вход, и затем структура нормально заполяется,
 а то, что не срабатывает в контексте первого процесса, то до вызова бапишки там идет вызов еще другой бапи (сторно отпуска материала по поставке) возможно _портится_ среда да так, что стандартная MCV_STATISTICS_DELIVERY лишается на входе структуры.

После сторно есть COMMIT? Если да, тогда получается что структуры содержат после сторно не правильную информацию. Ну тогда чтение поставки перед изменением должно исправить ситуацию. Если этого не произойдет, значит проблема не в сторно. Если ситуация исправиться, значит таки сторно портит информацию в структурах.

[NachDenken]

ага без политры не разобраться )

[Dmitriy]

ага без политры не разобраться )

Ну почему же? Просто нужно проследить в отладке весь путь после запуска BAPI_OUTB_DELIVERY_CHANGE до вызова MCV_STATISTICS_DELIVERY, как внутри бапишки структура LIKP заполняется? А с поллитрой и разбираться не в чем будет, забил - и все.    

[NachDenken]

да бы поставить точку.
Вообщем, пришлось разделить на 2 отдельных процесса то, что происходит до BAPI_OUTB_DELIVERY_CHANGE,
а само выполнение bapi в отдельный, тогда все заработало.