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

Проблема недостаточного использования серверных мощностей была в первую очередь связана с тем, что производители серверов не могли гарантировать на формальном и практическом уровне независимость работы приложений друг от друга. С появлением внутренних разделов вроде бы появился выход, но ситуация еще более осложнилась. Производители пошли по принципиально разным путям создания разделов – так называемые «логические» и «аппаратные». Аппаратные разделы «уменьшали» проблему, по сути создавая внутри серверов «жесткие» мини-сервера, которые действительно не позволяли приложениям, работающим в разных разделах влиять друг на друга. Но проблема в принципе осталась, потому что внутри каждого «жесткого» раздела опять-таки возникали те же неиспользованные ресурсы. Логические разделы позволяли гибко «сдвигать» ресурсы и разделять их, но не могли гарантировать (в том числе формально, по сертификатам и документам) независимость работы разделов. Мы здесь рассматриваем проблему с точки зрения технической документации и практики, а не с точки зрения маркетинговых заявлений.

Выход был найден за счет очень оригинального (хотя и невероятно «древнего») решения, которое в процессорах Power применила компания IBM. Это создание специального механизма, который осуществляет разделение ресурсов не пространственно, а во времени. Попросту говоря, каждая задача выполняется в течение ряда процессорных тактов, и при этом другие приложения НЕ выполняются. Как в старые времена при работе на больших ЕС ЭВМ или мейнфреймах, люди клали перфокарты, и каждая колода перфокарт обрабатывалась отдельно. Одна задача не влияла на другие. Сейчас этот механизм на новом уровне технологий внедрен в процессора Power и уже несколько лет активно используется на практике. Это позволило процессорам Power получить сертификат, подтверждающий независимость работы приложений в разделах, а сами разделы трактовать как аппаратные (!), хотя «жесткого» разделения ресурсов в них нет. Это принципиально важный момент, который позволил совмещать работу различных приложений в одном сервере и существенно экономить ресурсы.

При этом необходимо отметить, что IBM и SAP вели многолетнюю совместную работу по совместимости механизмов виртуализации, и технологии SAP Adaptive Computing могут прекрасно дополнять возможности процессоров Power. Оба механизма дают нужную гибкость системе. При этом мы абсолютно согласны с автором: сотрудничество и получение полной и подробной информации при выборе типа виртуализации и понимание ее возможностей являются крайне необходимыми при построении оптимального SAP-ландшафта.

А под словами о необходимости серьезного подхода и обучения команды у самого заказчика я бы просто подписался. Здесь как нельзя более подходит прямолинейное и грубоватое, но точное определение преподавателя нашей военной кафедры (МВТУ, 1980-е): «Техника в руках дикаря – кусок железа». Какими бы причинами не был вызван отказ от вдумчивого подхода к проекту и обучению своих специалистов, на бизнесе это скажется крайне негативно.

Статья указывает эффективный метод создания соединений с 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-бальной системе