Доброго всем времени суток!

Возникла такая проблема. Нужно выполнить проверку Shopping Cart. Есть чудесный ФМ BBP_PROCDOC_CHECK. Но дело в том, что я сначала делаю изменения, а потом хочу их проверять. Поэтому ввиду того, что BBP_PD_SC_UPDATE сам вызывает в процессе работы BBP_PROCDOC_CHECK, то решено было использовать только BBP_PD_SC_UPDATE и выводить получаемые назад сообщения.

Суть проблемы. Если один раз сделать изменения, указав несуществующие данные, то ФМ конечно же выдаст ошибку и возможно не изменит данные. Но если после этого я меняю все обратно, то всеравно продолжаю получать те же сообщения об ошибке. Они как бы из буфера на удаляются. Причем если я изменил дату поставки на слишком раннюю и потом вернул на нормальное значение, то больше не получаю сообщения об ошибке. Но если я поставил левый Cost Center в Account Assignment, то потом постоянно получаю сообщения об ошибке, даже если уже все нормально стоит.

Эту проблему решил с помощью вызова ФМ BBP_PDH_MSG_RESET_DBBUFFER перед вызовом апдейта, он как раз и чистит глобальные буфферные таблицы (спасибо дебаггеру). Но при этом появилась другая проблема. Если я одновременно изменяю и дату на неверную, и Cost Center, то потом не получаю сообщения об ошибке после изменения Cost Center на верный (но дата то по прежнему стоит неверная). Пробовал решить проблему вызовом после апдейта ФМ BBP_PROCDOC_CHECK, но в итоге получаю снова весь набор сообщений. После долгого времяпровождения в дебаггере выяснилось, что это ФМ имеет буффер сообщений еще непонятно где и очень запутанным образом их оттуда достает.

Вобщем написал много, если кто сталкивался с таким, буду очень благодарен. Уже третий день над этой проблемой сижу...

Попробуйте BBP_PD_SC_RESET_BUFFER. Потеряете в производительности, но она должна очистить все буферы...

Уже пробовал, не получается. Это ФМ чистит буффер данных, скажем так, а сообщения лежат вроде как в каких-то глобальных внутренних таблицах классов/групп функций. Для одного случая нашел как их почистить, для другого пока нет, там через статические объявления идет, не сталкивался еще с таким, надо разбираться. Набор "META"-функций, в результате сообщения, как откуда пока не ясно...

а почему Вы не используете badi BBP_DOC_CHECK_BADI ?

Тык может вы тогда задачу полностью опишите, а мы уже подумаем, как ее лучше сделать.
Например идея с CHECK_BADI очень неплоха...

Значит для тех, у кого есть возможность это посмотреть в портале.

Действия:

1. Создаем Shopping Cart (подскажите плз русское название, замучался переключать раскладки... потребительская корзина?)

2. Конечно же этот Shopping Cart должен быть без ошибок.

3. Важно только создать и сохранить, не запускать в Approval. Хотя может и не важно, не проверял.

4. Теперь изменяем сохраненный Shopping Cart.

5. На закладке Account Assignment/Kontierung/2й таб слева в поле Business Area/Geschäftsbereich/последнее поле в таблице ставим любое неверное значение (8888, 9999...).

6. После этого жмем на Check/Prüfen и получаем конечно же сообщения, что не канает. При этом значение в этом поле возвращается автоматом на старое.

7. Вроде как все данные теперь снова верные. Жмем Check/Prüfen и получаем снова весь набор сообщений. И так можно жать пока не надоест, ошибки всеравно выдаются.

Многочасовое сидение в дебаггере показало, что эти сообщения во время проверок получают вызовом ФМ BBP_BUFFER, причем пока очень загадочным для меня каким-то универсальным для всех случаев способом. Эти сообщения добавляются к полученным во время проверки, вроде так. Код конечно мне понятен, только вот он не дает возможности найти место, где эти сообщения хранятся.

Вобщем вроде понятно описал. Если нужны уточнения, то запросто.

З.Ы. В данный момент мы это оформляем в сообщение САПу. Если будут результаты, то постараюсь не забыть сообщить.

А насчет BBP_DOC_CHECK_BADI... Так а что мне в нем делать? Опять же BBP_PROCDOC_CHECK вызывать? Так проблема то именно в нем, что он лишние сообщения выдает. И не важно откуда его вызывать... Или поправте если я не прав.

Посмотрел еще раз БАдИ, его реализации вызываются как раз во время работы BBP_PROCDOC_CHECK. Там я могу выполнить дополнительные проверки (в чем я не нуждаюсь) и как раз никак не могу повлиять на те сообщения, которые выводятся после проверки стандартными средствами.

Проверил на SRM 5.0 SP16 - нет такого поведения.
Единственное что насторожило, что ошибка показывалась два раза. Неправильное значение автоматом не менялось, после изменения вручную ошибка исчезла.

Хм, значит это проблема только семерки. У нас 7.01.

Кстати по теме. Насколько мне удалось понять проблему, она именно в ФМ META_ACCSERV_CHECKACCASSIGNMT. Там идет проверка, имеется ли что-либо в буффере, если да, то просто выдается то что в буффере и проверка Account Assignment не запускается. Возможно это и правильно, вот только в этом случае они забыли кое-где поставить очистку буффера.

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

SRM_SERVER 700 0006 SAPKIBKV06
Ошибки нет...

У нас SRM_SERVER 700 0007 SAPKIBKV07. Получается толко в нем проблема...

2Vid
Shopping Cart - корзина покупок по-русски


BADI BBP_DOC_CHECK_BADI была присоветована к этой фразе, она используется для доп. пользовательских проверок.
Не сразу понятно было, что у Вас за проблема.

Если поле business area = русскому полю бизнес-сфера, то в нашей системе (SRM_SERVER 700 0007 SAPKIBKV07 )проблем с очисткой буфера нет . Проверить на англ. не могу, настроек не хватает. Какое-то время назад в других местах (контракт)
было задвоение сообщений, но после очередного обновления проблема пропала.

Хм... Версия системы та же... Неужели это только наша проблема? В любом случае сообщение САПу уже отправили, процесс обработки затрудняется тем, что мы пока не можем открыть свою систему для WTS, а саповцы не могут повторить это у себя. Как только что-то решится, обязательно отпишу. Всем спасибо за информацию!

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

Могу такую идейку подкинуть если еще актуально - когда начинаются какие-то мутки при повторных вызовах стандартных BADI/FM-ов с неочищенными таблицами, буферами и тд тд, можно попробовать следующий универсальный способ: повторные вызовы BADI выполнять в отдельной программе, которую вызывать через

В этом отдельном вызове все буферы, глобальные переменные и тд будут абсолютно чисты и все будет работать как в первый раз