Текущее время: Чт, мар 28 2024, 13:04

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 5 ] 
Автор Сообщение
 Заголовок сообщения: Оптимизация переноса документов в FI-SL
СообщениеДобавлено: Чт, сен 06 2012, 13:28 
Начинающий
Начинающий

Зарегистрирован:
Пн, фев 07 2011, 10:00
Сообщения: 23
Коллеги, вопрос по переносу документов из других модулей (в частности FI) в FI-SL. В ТПР для переноса используется ФМ J_3RF_TAX_SELECT_OBJ_FI. Так вот там есть цикл как я понимаю по проверке дополнительных условий в критериях выбора:
Code:
LOOP AT lt_addfields.
...
ENDLOOP.


И я так понимаю, что форма CHECK_SO в этом цикле как раз и проверяет выполняется условие или нет и возвращает информацию об этом в B_OK.
Так вот, если B_OK = ' ', то почему бы сразу не выйти из этого цикла? Зачем цикл идет дальше, ведь если x_add_ok очистили, то оно так и будет пустым и нет смысла проверять другие условия в этом правиле выбора. На мой взгляд надо сразу писать так:
Code:
      IF B_OK = ' '.
        CLEAR x_add_ok.
        EXIT.
      ENDIF.


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


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Оптимизация переноса документов в FI-SL
СообщениеДобавлено: Чт, сен 13 2012, 09:35 
Начинающий
Начинающий

Зарегистрирован:
Пн, фев 07 2011, 10:00
Сообщения: 23
Ну что коллеги, так никто и не выскажется по этому поводу?
Господа SL-щики со знанием абап - посмотрите пожалуйста ФМ о котором я писал.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Оптимизация переноса документов в FI-SL
СообщениеДобавлено: Пт, май 10 2013, 16:54 
Специалист
Специалист

Зарегистрирован:
Ср, июн 09 2010, 14:26
Сообщения: 153
И таких мест в коде САП немало. Удивляться нечему.
Однако, как правило основная причина тормозов при переносе полей - пользовательские экзиты, читающие таблицы MSEG, BSEG, VBAK и так далее.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Оптимизация переноса документов в FI-SL
СообщениеДобавлено: Пт, июл 05 2013, 09:01 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Вс, окт 17 2004, 11:34
Сообщения: 1551
Пол: Мужской
SB написал(а):
И таких мест в коде САП немало. Удивляться нечему.
Однако, как правило основная причина тормозов при переносе полей - пользовательские экзиты, читающие таблицы MSEG, BSEG, VBAK и так далее.

Именно. Причем без использования возможностей формирования полного ключа или использования вторичных таблиц типа BSID/BSAD. Хотя возможность формирования полного ключа или обращения к вторичным ключам обычно есть.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Оптимизация переноса документов в FI-SL
СообщениеДобавлено: Ср, сен 11 2013, 13:21 
Директор
Директор
Аватара пользователя

Зарегистрирован:
Пт, июл 21 2006, 15:56
Сообщения: 1138
Откуда: Москва
Пол: Мужской
cfgthq написал(а):
Коллеги, вопрос по переносу документов из других модулей (в частности FI) в FI-SL. В ТПР для переноса используется ФМ J_3RF_TAX_SELECT_OBJ_FI. Так вот там есть цикл как я понимаю по проверке дополнительных условий в критериях выбора:
Code:
LOOP AT lt_addfields.
...
ENDLOOP.


И я так понимаю, что форма CHECK_SO в этом цикле как раз и проверяет выполняется условие или нет и возвращает информацию об этом в B_OK.
Так вот, если B_OK = ' ', то почему бы сразу не выйти из этого цикла? Зачем цикл идет дальше, ведь если x_add_ok очистили, то оно так и будет пустым и нет смысла проверять другие условия в этом правиле выбора. На мой взгляд надо сразу писать так:
Code:
      IF B_OK = ' '.
        CLEAR x_add_ok.
        EXIT.
      ENDIF.


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

А если не выполняется сразу второе? :) Тогда что?
Вы тут рассуждаете с позиции, когда у вас в селекционном критерии один признак, тогда да, все это пианино с лупом по всей таблице lt_addfields не нужно, а если их несколько в рамках одного RTAXOBJ, и расхождение возникает далее, чем на первом признаке в списке?!

_________________
Гюгюльме аля улю


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 5 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: -TT-


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB