Если есть возможность, поясните пожалуйста, что такео Авизо об отправке (это входящая поставка?), Зависимые резервирования (это резервирования созданные из заказов РР и РМ ??), Потребности отзыва.
 
Хотелось бы так же чтобы вы рассмотрели взаимодействие связанных потребностей. Например Сбытового заказа и Исходящей поставке. Заказа на поставку и входящей поставки.

В этои посте к сожалению, много опечаток и ошибок :(
 
По поводу объема проверки хотел уточнить. Раньше вы писали что для сбытовых заказов и исходящих поставок жестко устанавливаются правила проверки (А и В соответственно). Значит ли это, что в таких документах объем проверки зависит только от материала (группы проверки) и нет возможности настроить разную логику проверки для разных видов заказов?

Начнем читать с анонса :)

Очень хорошая статья. Все подробно расписано, а самое главное, у меня сейчас как раз стоит похожая задача.

Во всей русскоязычной документации давно принято Universe BusinessObjects именовать Юниверс, и не универс.

Статья полезная.
 
В части заказов на поставку зачастую контроль документов отделом закупки или логистики оставляет желать лучшего. Поэтому в процессе работы появляется масса заказов без индикатора "КонечнаяПоставка":
- заказанное количество поставлено не полностью, однако последующие поставки не ожидаются. Индикатор мало кто контролирует;
- иногда создаются дубли заказов "по недосмотру";
- используются заказы на перемещение внутри компании. Организовать контроль из закрытия намного сложнее.
 
Если не организован процесс регулярного контроля открытых заказов, то можно попытаться разработать программу по автоматической установке индикатора "КонечнаяПоставка" в заказе по сроку давности. Таким образом, максимально увеличить объем архивируемых заказов на поставку.

Адиль, можно попросить Вас обновить скриншоты?

Да уж, было дело, вот например есть индусцы, которые предлагают услуги по тестирования, само собой за деньги, само собой все равно на выходе будет фигня, зато денег стоит не мало (от 100 000 не нашими деньгами), а руководство верит, что качество будет супер. Я даже было как-то подумал, что если бы эти деньги дали непосредственно ключевым пользователям, которые должны по логике проводить эти тесты, то стресса и "ломания" в большинстве случае можно было бы избежать, потому что люди знали бы за что собственно они так напрягаются.

Хорошая статья. Рассмотрены сценарии разной степени сложности.
Функция номера детали производителя полезна и удобна не только для учета; при внедрении планирования потребности в материалах удобно когда для запаса с одинаковыми свойствами используется один инвентаризационный номер.

Существует интересный вариант классификации производств по ассортименту готовой продукции, которая изготавливается в одной технологической цепочке, т.н. VAT-классификация. Это не аббревиатура, а схематическое обозначение разузлования в технологическом цикле. Так например, примером T-производства является металлургия, V - переработка нефти, А - сборка автомобиля.

Классификация типов производства в статье не позволяет разделять различные производства.
К примеру, по данной классифкации металлургическое производство можно отнести как к дискретному, так и к серийному, так и к позаказному типу производства:
-есть передельный учет
-есть позаказное планирование производства
-выполнение больших заказов обладает всеми характеристиками серийного производства (о чем в принципе и сказано в п.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 вид поставки не определен.".