Статья указывает эффективный метод создания соединений с SAP BW из приложений Microsoft Office. Хотелось бы добавить несколько неочевидных пунктов:

При создании подключений через SAP Logon Control, важное значение имеет корректность его локальной установки на машине пользователя. При наличии ошибок подключения рекомендуется переустановить или обновить SAP GUI frontend.

При вводе учетной записи пользователя и пароля следует обязательно проверить какая система выбрана в окне авторизации SAP Logon (Кнопка System) в каждом случае.

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

Ну в жизни бывают разные варианты, SM30 может быть закрыта, командочка SE16N, имя таблицы -> &sap_edit, еще большая вероятность что может быть закрыта, так что просто учтены все варианты как можно поменять поле, а то была ситуация когда полномочия были на SA38, а с остальным было плохо, так что пришлось программку приблизительно для этих целей и набросать.

Спасибо за статью.
Интересная статья. Если уж есть такая потребность - видеть ссылку на документ инвентаризации в FI , то можно так решить. Вполне изящно.
Единственное, что напрягает, так это предложение курочить контент стандартных таблиц в дебаге.
## Смену поля можно сделать любым из описанных ниже способов: ##
Тем более крос-клиентный кастомайзинг. Кастомайзинговая вьюха ищется элементарно - для этого не надо ходить на форум, достаточно запустить SM30,
подставить имя таблички и нажать кнопку "Find Maintanance Dialog".
Хочешь посмотрать все вьюхи - SE11 ->Where-Used List, Views.
Уж в крайнем случае можно запустить SE16N, имя таблицы ->  &sap_edit в окно ввода транакции.
Этот способ по крайней мере позволит создать транспорт через Table Entry -> Transport.
А настройку надо будет оттранспортить по ланшафту в обязательном порядке (либо проделовать тоже самое ручками в кажной ситеме выше - тесте и продуктиве).
Предложение писать ABAP для изменения контента поля вообще из разряда моделирования шарообразных
коней в вакууме -  создать свою кастомайзинговую вьюху подобную VWTYGB01в SE11 занимает 5-10 минут, решает проблему с транспортами и не требует знаний ABAP.

К сожалению реалии правил ведения бузгалтерского учета в РФ и РБ таковы, что наиболее применимым методом оценки запасов при заготовке их на стороне является партионный учет с раздельной оценкой партий и ССЦ.
 
Однако западные клиенты могут себе позволить раздельную оценку, например для раздельного учета складских запасов оборудовани в зависимости от их принадлежности к инвестициям, видам запаса и т.д.
Например: новое оборудование, демонтированное оборудование, ремонтный пул и т.д.
 
В целом статья полезная. Спасибо автору

===
Оптимизация данной конструкции должна быть достойна внимания не меньше, чем SELECT SINGLE.
===
Решение об оптимизации должно приниматься на основе измерений, а не использовния каких-либо конструкций в коде.
Для разных БД и версий системы результаты могут быть отличаться.

===
Использование SELECT ...ENDSELECT уже говорит о том, что программа не оптимизирована.
===
А кто вам это сказал, что это значит что она не оптимизирована? Или оптимизация по памяти таковой не считается? Ситуации бывают разные, а поэтому сказать что данная конструкция не должна применяться, очень спорное заявление.
===
 
Безусловно , ситуации бывают разные, иногда бывает дешевле оставить такую конструкцию.
Однако конструкция SELECT ... ENDSELECT при выполнении каких-либо существенных по времени операций в цикле сильно съедает ресурсы БД и подлежит оптимизации в первую очередь. Естественно, на все надо смотреть комплексно, чтобы не влезть в другую крайность.
Оптимизация данной конструкции должна быть достойна внимания не меньше, чем SELECT SINGLE.

Все давно настроил, все работает.
Не получилось разрешить только одну задачу. Если к заводу-поставщику можно создавать два вида документов, например,
"NB - стандартный вид заказа" и какой-нибудь "ZNB - заказ по агентской схеме", где нет необходимости формировать исходящую поставку.
Система запрещает создавать ZNB с "железной" ошибкой: "Для завода-поставщика xxxx и вида докум. ZNB вид поставки не определен.".

Все давно настроил, все работает.
Не получилось разрешить только одну задачу. Если к заводу-поставщику можно создавать два вида документов, например,
"NB - стандартный вид заказа" и какой-нибудь "ZNB - заказ по агентской схеме", где нет необходимости формировать исходящую поставку.
Система запрещает создавать ZNB с "железной" ошибкой: "Для завода-поставщика xxxx и вида докум. ZNB вид поставки не определен.".

Все давно настроил, все работает.
Не получилось разрешить только одну задачу. Если к заводу-поставщику можно создавать два вида документов, например,
"NB - стандартный вид заказа" и какой-нибудь "ZNB - заказ по агентской схеме", где нет необходимости формировать исходящую поставку.
Система запрещает создавать ZNB с "железной" ошибкой: "Для завода-поставщика xxxx и вида докум. ZNB вид поставки не определен.".

===
Использование SELECT ...ENDSELECT уже говорит о том, что программа не оптимизирована.
===
А кто вам это сказал, что это значит что она не оптимизирована? Или оптимизация по памяти таковой не считается? Ситуации бывают разные, а поэтому сказать что данная конструкция не должна применяться, очень спорное заявление.

Использование SELECT ...ENDSELECT уже говорит о том, что программа не оптимизирована.
Вы забыли указать про предпочтительное использование внутренних таблиц для обработки данных, чем
обработку данных через СУБД.
Конструкция SELECT ... ENDSELECT подразумевает обработку данных в цикле, при этом СУБД будет занята на время выполнения всего цикла.
Гораздо предпочтительнее  использовать внутренние таблицы и считывать запрос за один проход
select field1 , field2 into itab
where .... .
а даллее проводить обработку данных в цикле
loop at itab.
endloop.
При таком подходе можно значительно снизить нагрузку на СУБД.

Коллеги, спасибо за комментарии.
 
SELECT SINGLE достоин упоминания вне всякого сомнения. Почему он не указан, я постараюсь объяснить в следующем посту. Но думаю интересней будет о самом операторе.
 
Использование SELECT SINGLE должно давать не менее эффективный результат, с т.ч. производительности, чем приведенная в статье конструкция SELECT ... UP TO 1 ROWS. Теоретически выигрыш при SELECT SINGLE, в сравнение с формой SELECT ... UP TO 1 ROWS, возможен, поскольку эта конструкция более очевидная и, следовательно, потенциально менее зависит от силы оптимизирующих механизмов как на уровне системы SAP, так и на уровне БД. На уровне сервера приложения SAP мы можем получить также потенциально более эффективный код, поскольку не требуется накладных расходов на организацию цикла. Однако, по крупному, в обоих случаях, мы совершенно ясно указываем системе, что нам нужна ровно одна запись. А это значит, что с большой долей вероятности обе конструкции будут давать эквивалентный результат. Важными дополнениями к этим рассуждениям будут несколько моментов:
 
* При указании первичного ключа во фразе WHERE интерфейс БД не будет генерировать специальной конструкции (ROWNUMBER, ROWNUM и пр.) для ограничения числа записей. Результирующий оператор будет короче и, следовательно пусть не намного, но оптимальней.
 
* SELECT ... UP TO 1 ROWS позволяет использовать фразу ORDER BY. Это дает нам, в определенных случаях, наиболее оптимальный способ поиска записи с наименьшим/наибольшим значением поля среди набора записей с одинаковым критерием выборки.
 
* Интерфейс БД SAP НЕ ИСПОЛЬЗУЕТ SINGLE-RECORD буфер при использовании конструкции SELECT ... UP TO 1 ROWS, даже если мы укажем полный первичный ключ во фразе WHERE. Это значит, скорость доступ к буферизируемым таблицам может быть на порядки медленней при использовании конструкции SELECT ... UP TO 1 ROWS.

Олег, добрый день!
В качестве ответа на Ваш комментарий, я разместил еще один пост.
http://www.sapland.ru/blogs/jukov/?post=3076
 
С Уважением,
Константин.

оказалось, что пишут неправду. up to 1 rows работает быстрее. может от базы зависит? но на MSS по любому критерию шустрее.

Статья интересная и полезная.
Минус - как-то четкая картина процесса отправки почты не сложилась, хотя по отдельности все понятно
Плюс - как и в другой статье Михаила - понравился раздел источники информации, со ссылками, очень удобно

а мне казалось, что все-таки разница между ними есть. да и в SLIN вот, что пишут на эту тему:
 
The SELECT SINGLE is designed to allow a most efficient access to exactly one record of a database table. It requires that you specify the entire primary key in the WHERE condition with AND and EQ (or "="). Then an access to the database is possible, which requires only one communication step between application server and database server.
 
If you did not specify the entire primary key, instead of a direct access on the database server, a "normal" SELECT is performed, which is the same as a SELECT ... UP TO 1 ROWS. In this case, a cursor is opened, a record is read, and the cursor is closed. This requires a number of communication steps between application server and database server.
 
The extended program check provides a warning to inform you that with the mentioned SELECT SINGLE not the expected fast direct access can be performed.

Хорошая, понятная и полезная статья!
 
Мы давно используем замещения для нужд ММ, FI и СО.
Кроме того знаю и про доступ к глобальным данным вызывающих программ,
но соединить это воедино, скорее всего, не догадался бы.))
Спасибо за идею!
(видел неоптимальные методы решения этой проблемы путем записи данных в БД (в одном из ранее вызываемых экзитов) и считывания этих данных в нужном месте (другой экзит))
 
Тема раскрыта!

Прошу прощения оценки по 5-бальной системе

1) Олег прав, на уровень БД они буду т интерпретированы одинаково, ибо в SQL основных СУБД нет оператора SELECT SINGLE, убедиться в этом можно выполнив трассировку SQL с помощью транзакции ST05
 
2) однако, меня очень удивляет тот факт, что и автор статьи и даже многие разработчики SAP (это видно по исходным текстам) пренебрегают оператором SELECT SINGLE. (Кстати SAP-овцы даже не трудятся приписывать в таких случаях UP TO 1 ROW ! )
На мой взгляд это неэффективное и непрофессиональное использование столь мощного инструмента как ABAP.
 
3) В статье приводятся слишком уж избитые истины и к тому же очень бегло.
Статья получилась ни о чем.
Считаю, что лучше досконально раскрыть один из аспектов оптимизации, например, JOIN или использование FOR ALL ENTRIES OF.
Ведь ньюансов там очень много.
 
И вообще не понятна целевая аудитория.
Если статья предназначалась начинающим абаперам - оценка "4 с минусом" (для начинающих слишком бегло)
Если - для среднего уровня - оценка "3 с минусом" (все и так понятно)
Если - для высокого уровня - "эээ.... а где, собственно, статья" )))
 
П.С.: нисколько не пытаюсь умалить профессионализм автора, это всего лишь моя оценка данной конкретной статьи

Будет возможность посмотрим. Спасибо за комментарии.