Все давно настроил, все работает.
Не получилось разрешить только одну задачу. Если к заводу-поставщику можно создавать два вида документов, например,
"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 с минусом" (все и так понятно)
Если - для высокого уровня - "эээ.... а где, собственно, статья" )))
 
П.С.: нисколько не пытаюсь умалить профессионализм автора, это всего лишь моя оценка данной конкретной статьи

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

Я не спорю по поводу возможности ведения раздельной оценки с/без регистра материалов.
Вариант расчета фактической калькуляции для материала с управлением ценой S c "тройкой" без раздельной оценки тоже работает отлично...
а вот для материала от второго передела и выше с раздельной оценкой многоуровневые отклонения распределяются не совсем корректно, на что было получено подтверждение от SAP support.
А насчет "не верю" - то вы все можете протестировать сами ;)

==
а разве select single не эффективнее select ... up to 1 rows ... endselect?
==
Вообще-то на уровень базы данных, эти запросы будут интерпретированы одинаковой командой, поэтому они не могут быть быстрее или медленнее, они на абапе будут написаны по разному, а вот выполняться будут одинаково.

Александр, позвольте с вами не согласиться. еще раз, во-первых, настройка раздельной оценки никак не зависит от типа управления ценой, для регистра материала тип управления ценой важен, но для раздельной оценки нет, вы можете использовать раздельную оценку с регистром материала или нет без нее. Во-вторых, позволю тоже не согласиться: "нормально не работает, т.е. отклонения при расчете фактической калькуляции не совсем корректно дооценяют запасы и потребление", так как при производстве тип управления ценой S, это стандартно рекомендуемый тип и что этот вариант работает не правильно?! Т.е. кроме вас этого никто другой из клиентов и собственно сам SAP, не знает? Скорее всего ваш реализованный метод дооценки отличается от стандартно предлагаемых системой и по выходу, вы имеете так называемую не корректную дооценку... других вариантов я не вижу.
 
PS: Я не специалист по контроллингу затрат на продукт, поэтому дальше мне будет сложно поддерживать дискуссию по поводу методов расчета дооценки... единственное что как говорил Станиславский: "Не верю!", что оно работает не правильно...

Согласен с обоими Александрами, но истины ради нужно еще упомянуть необходимость добавления в проект этапа бизнес-инжениринга на ранней стадии (имхо, лучше за счет отдельной компании интегратора). Например эту функцию прекрасно могли бы на себя взять бизнес-консультанты из BIG4 (которые все равно, как правило привлекаются на серьезные проекты, но только в качестве аудиторов и слишком поздно, что толку кулаками махать, когда концепт подписан? :) ).

блестящая статья-инструкция. много раз обращался к ней на различных проектах.

а разве select single не эффективнее select ... up to 1 rows ... endselect? одно обращение к базе вместо двух должно быть быстрее.

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

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