Автор совершенно точно, без лишних слов, описывает различные сценарии применения данного инструмента (Операция дополнительного дебетования) и также раскрывает секреты, как пользоваться данным инструментом.

В статье допущена маленькая неоднозначность, которая может поставить читателя в замешательство. Перед картинкой 3 сказано, что когда вы нажмете клавишу Enter, система обновит текущую стандартную цену в колонке «цена» вместе с информацией о единице цены. В данном предложении указано только про изменение в конкретной ячейке программы, которое служит для информационных целей, а не про реальное изменение стандартной цены. Важно понимать, что при операции дополнительного дебетования стандартная цена не меняется, а вся сумма дополнительного дебетования попадает на счет отклонений и в соответствующие поля в регистре материалов (более подробно см. Табл. 1) .

Хотел бы также дополнить данную тему по поводу дополнительного дебетования/кредитования материалов и пояснить некоторые моменты.

Как уже описал автор, при операции дополнительного дебетования/кредитования стоимости материала, в случае, когда материалы оцениваются по стандартной цене, производится проводка по операциям Д(К) PRD К(Д) UMB. Важно понимать, что именно за счет операции UMB производится переоценка стоимости запасов. Я рекомендую настраивать разные счета для операций UMB и PRD. Иначе потом трудно обнаружить ошибки, которые пользователь в результате своих некорректных действий или некорректных настроек может допустить при операциях переоценки. Иногда в отдельных случаях может потребоваться (например, при закрытии периода распределять накопленные суммы отклонений на материал) производить переоценку с разных счетов, то есть для операции UMB должны быть настроены несколько счетов (так как существует несколько причин изменения стоимости запасов). В этом случае вам необходимо произвести необходимые настройки в транзакции OBYC для операции UMB. Для этого необходимо зайти в настройки правила и добавить столбец «Общая модификация» (Рис. 1).

Рис. 1	Добавление столбца «Общая модификация»

Затем прописать необходимые счета с указанием модификации в этой же транзакции (Рис. 2).

Рис. 2	Настройка счета UMB с использованием общей модификации

Теперь необходимо в ссылочном меню IMG SAP настроить :

Контроллинг -> Контроллинг затрат на продукт -> ФактичКалькуляция/Регистр материалов -> Причины для изменений цен

Добавить причину указанным образом. При этом одна из причин должна быть помечена галочкой в графе «По умолчанию» (Рис.3).

Рис. 3	Настройка причины изменения цены

После добавления аналитики по причинам изменения цены транзакция MR22 будет выглядеть как показано на Рис. 4. Выбор счета производится при помощи выпадающего меню.

Рис. 4	Транзакция MR22 после добавления аналитики по причинам изменения цены

Стандартная и среднескользящая цены в транзакции MR22 и MR21 обрабатываются по-разному. Также имеет значение, активирован ли РМ для завода, на котором производится изменение стоимости оценки или нет. В Табл. 1 попытался прояснить детали использования операций изменения цен:

Табл. 1	Обзор упрощенного подхода к внедрению ChaRM

Операции по дополнительному дебетованию/кредитованию материалов предлагают удобный инструмент для гибкого включения затрат в себестоимость продукции.

В статье рассматривается функциональность комментирования данных и возможность экстракции комментариев из BW Document Repository Manager с целью отображения в пользовательских отчетах для обеспечения аналитикам более простого доступа к ним, чем через стандартную функциональность Business Explorer.

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

Более того, используя данный куб хранения комментариев, мы можем вывести информацию о наличии документов в репозитарии BW на уровень агрегированных данных и компенсировать тем самым потерю данной информации в отчётах, о которой говорится в статье, т.к. значок о наличии комментария, привязанного к комбинации аналитик, появляется только при полной детализации отчёта BEx.

Для этого необходимо выполнить несколько несложных операций:

1. Создать мульти-куб на основе куба данных отображённых на рисунках 1 и 4 статьи, а также куба, содержащего комментарии – рис. 5, 7 и 8.
2. Добавить в мульти-куб признаки для отображения комментариев (рис. 5), признаки для определения данных (рис. 7), необходимые показатели куба данных и показатель ZBDS_RECS куба комментариев.
3. Отчёт, изображённый на рис. 4, построить на данном мульти-кубе.
4. Добавить в него показатель ZBDS_RECS.
5. Настроить для данного показателя подсветку через функциональность Exception в BEx.

В результате данный отчёт примет вид (рис. 10):

Рис. 10	Отчет с пиктограммами документов (вместо Рис.1 статьи)

Т.е. теперь мы видим количество комментариев, созданных аналитиком, для всех комбинаций признаков, просматриваемых в отчёте. Данный показатель можно выводить или прятать в зависимости от целей анализа (рис. 11).

Рис. 11	Вывод отчета при агрегировании по счету (вместо Рис.4 статьи)

С одной стороны, вывод дополнительного столбца перегружает отчёт, когда идёт исключительно анализ данных. С другой стороны, он даёт возможность просматривать данные и видеть наличие комментариев на одном информационном поле, с которого возможен переход в более детальные отчёты с возможностью просмотра документов из репозитария BW, например, через добавление аналитик в отчёт из свободной области при помощи drag&drop или через интерфейс Report-to-Report.

 

Компания SAP всегда сопровождала свои решения подробной методологией внедрения. Основанная на лучших мировых практиках ведения ИТ проектов, методология внедрения AcceleratedSAP содержит подробное описание этапов проекта, шагов и их последовательности. Содержит шаблоны и результаты, которые необходимо получить на том или ином шаге проекта. Использование методологии гарантирует успешное завершение проекта внедрения вовремя и в рамках бюджета.

В статье Катрин Роуз, немалое внимание уделяется фазе перехода к продуктивной эксплуатации. Все действия, выполняемые в этой фазе, очень важны. От их качества зависит успех всей работы проведенной по проектированию, реализации и подготовке решения. Так же в статье приводятся советы, и опыт которые были приобретены на множестве проектов внедрения SAP BWA. Не учитывать эти знания, на наш взгляд, нельзя. Они являются дополнительным инструментарием для снижения рисков при внедрении и своеобразным гарантом завершения проекта в срок и с необходимым качеством. При этом предполагается, что читатель уже обладает фундаментальными знаниями о SAP NetWeaver BW и акселераторе.

Исходя из нашей проектной статистики, многие BI специалисты, как заказчика, так и от системных интеграторов, не сталкивались с таким решением как BWA. Учитывая этот факт, предлагаем вашему вниманию статью, которая даст общее представление о BWA и будет являться введением к статье Катрин Роуз.

Введение в BWA. Преимущества и требования

Немного истории

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

В настоящее время перед руководителями ИТ-отделов стоит задача предоставления бизнес-пользователям самых современных аналитических инструментов. ИТ-отдел по-прежнему несет ответственность за управление аналитикой, доступной с рабочих мест, наполнением системы новыми данными, за управление пользователями и их полномочиями, а также способами формирования запросов.

SAP NetWeaver BW Accelerator

Одними из самых популярных средств аналитики всегда были решения корпорации SAP.

Компании SI BIS и SAPRUN разработали решение на основе SAP NetWeaver BW Accelerator, которое в десятки и сотни раз повышает производительность аналитических приложений, построенных на основе платформы SAP NetWeaver Business Intelligence, бесшовно встраиваясь в ее архитектуру и не требуя значительных затрат на настройку, дополнительные разработки и интеграцию.

Технически SAP NetWeaver BW Accelerator представляет собой модульную блейд-систему c 64-битными процессорами Intel, на которую установлено специальное программное обеспечение SAP. Для начала работы с SAP NetWeaver BW Accelerator его необходимо соединить с существующей системой SAP NetWeaver Business Intelligence и определить те информационные кубы, для которых он будет активен. В настоящее время SAP NetWeaver BW Accelerator функционирует на двух специализированных аппаратных платформах:

• IBM BladeCenter и IBM TotalStorage;
• HP BladeSystem и HP StorageWorks.

Решение позволяет проводить автоматическое конфигурирование, что значительно упрощает расширение системы. Линейная масшабируемость позволяет постепенно расширять систему по мере роста потребностей в обработке данных.

 

Для выбранных информационных кубов SAP NetWeaver BW Accelerator строит индексы, сжимает их и загружает в оперативную память. В SAP NetWeaver BW Accelerator используются высокоэффективные методы агрегации, чтобы обеспечить возможность обработки запросов исключительно в оперативной памяти.

Передовая архитектура решения SAP NetWeaver BW Accelerator позволяет повысить производительность аналитических сервисов и приложений за счет двух факторов:

• устраняется необходимость предварительного агрегирования данных, поскольку агрегирование происходит непосредственно во время выполнения запросов пользователей;
• пользователи получают возможность работы с любыми объемами данных в соответствии с их информационными потребностями и временными ограничениями, при этом значительно уменьшается необходимость в дополнительных оптимизационных настройках, производимых ИТ-отделом.

 

Полевые исследования

Компании SI BIS и Saprun провели установку и конфигурирование SAP NetWeaver BW Accelerator на базе платформы IBM BladeCenter, а затем выполнили ряд тестов, ориентированных на потребности ведущих розничных сетей, телекоммуникационных компаний и банков.

Этапы внедрения решения

• На первом этапе происходит подключение блейд-систем к системе хранения, установка и настройка ОС Linux SUSE Enterprise Server, настройка GPFS на подключенных дисках. Как правило, данный этап занимает около 5 дней.
• Второй этап подразумевает настройку параметров BWA и связи BI - BWA. Этот процесс занимает 1-2 дня.
• На третьем этапе создается модель данных, происходит загрузка данных в BI, индексация куба в BWA, и в результате строится необходимая отчетность. Финальный этап занимает 3,5-4 дня.

Преимущества использования NetWeaver BW Accelerator на базе платформы IBM

Установка и конфигурация SAP NetWeaver BW Accelerator на базе платформы IBM BladeCenter и IBM TotalStorage позволяет получить ряд важных преимуществ.

SAP NetWeaver BW Accelerator дает возможность развивать аналитическую систему, пользоваться новыми функциональными возможностями, что, в свою очередь, способствует более быстрому переходу к сервисно-ориентированной архитектуре

Все эти возможности обеспечиваются за счет снижения ограничений на объемы одновременно обрабатываемых данных и сокращения времени отклика системы.

Неплохая статья, вспомнилось практически по теме, хотя и не большое отступление зато из жизни.
----
На одном водочном заводике в Украине, внедряли систему управления складами, она же WMS по нашему. Ну и в качестве автоматизации решили использовать радиометки, оно же RFID по ихнему и обнаружился интересный эффект, вся эта система глючила при считывании данных меток при проходе ворот. После поисков обнаружилось, что стекло и водка в этом стекле, являются природным искажателем радиочастот, как раз в том диапазоне, в котором работают радио-метки. В общем вот такая она водка загадочная... что даже нормальный учет и то наладить трудно... хотя опять же с другой стороны, а может это кому-то очень было нужно  чтобы оно искажалось...

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

Сложно сказать интересная статья или нет, автор почему-то больше зациклился на загрузке остатков по системе управления складом, а про загрузку остатков собственно в ММ, как-то пробежался, мимоходом и как правильно заметили несколько раз упомянул про сверку стоимости с количеством, но никак не описал а как же осуществляется такая сверка или какие есть подводные камни... Так же не по понятно причем там упоминаемые заказы на закупку, если автор загружает остатки через 561 вид движения запаса, в котором нет ссылок на заказы ММ. Так же не ясно почему автор предлагает создавать записи материалов в ручном режиме? Нет если у него материалов 10-100 штук то не вопрос а если несколько десятков тысяч? Кажется правильнее было бы указать что предварительным этапом загрузки данных по запасам, должен быть шаг загрузки данных ОЗМ (а это своя, не менее сложная задача), после которой загрузка запаса уже как мне кажется будет мелочью :-)
 
Кстати, я не понял почему автор делает такую большую проблему сверки количества и стоимости, т.е. в чем проблема? Если система с одной валютой без параллельной оценки запасов, то для вида движения 561 открывается поле внешняя сумма движения после чего указывается количество и общая стоимость движения запаса т.е. например пишем приход 3 штуки, стоимость запаса 2 копейки а уже система сама поймет когда ей копейку при движении списывать и какая будет цена за единицу, но при этом никакого расхождения не будет, потому что мы задаем, стоимость запаса, а не цену за единицу... Для параллельного учета задача конечно сложнее,но и она решаема.
 
В общем как по мне, то есть такая формулировка в интернете, для статей, не полностью осветивших вопрос, звучит она так: "тема сисек не раскрыта полностью". Так таки не раскрыта полностью...

Нормально написано, но как по мне, то вся суть статьи заключается в одном абзатце, а именно:
----
Документы WMS (транспортные заказы) созданные с ссылочным видом движения 999 не обрабатываются интерфейсом создания IDoc, ну и далее картинка где показывается присвоение вида движения ММ, ссылочному виду движения WMS.
Все!
----
А вот это вот в самом начале про присвоение номера склада WMS скалду ММ, это вообще тут по большому для объема, так как иначе если уже писать полностью про то как правильно определить номер склада и т.д.

К сожалению или к счастью пользователям практически никогда не выдают полномочий на транзакции SE*, поэтому для конечного пользователя статья вряд ли актуальна, а для консультанта работающего в области логистики, это узнается на первых шагах работы с ОЗМ и автоматической настройки выбора счета при движении материала.
 
Мое мнение для конечного пользователя более интересно было бы задав материал, класс оценки материала или группу материалов, получить информацию какие счета и для каких операций будут использоваться,а это стандартными средствами сделать нельзя, поэтому в свое время для конечных пользователей и различных проверяющих/аудиторов был написан небольшой отчет, который по группам/классам оценки и т.д. позволял получить информацию по присвоенным счетам в понятном разрезе.

Решение описанное в статье не учитывает такую вещь как несколько инстанций (серверов приложений) при подключении к серверу базы данных, что в принципе возможно и бывает (при использовании SolMan возможно реже), а при такой ситуации данный метода может давать не верные результаты, так как для нумерации скорее всего включена буферизация (без нее возможны проблемы производительности и конфликты при доступах к таблице интервалов). При включенной буферизации каждая инстанция берет по диапазону номеров в момент старта в локальный буфер и выделяет номера по требованию подключенных клиентов. Обычно буферизация настраивается на 10 номеров, следовательно имеем картину:
1 инстанция получит номера: 0001 - 0010
2 инстанция получит номера: 0011 - 0020
При запросе номера, по первой инстанции будет сгенерирована заявка с номером 1, а при запросе номера по второй инстанции будет получен номер 11. При этом если пользователи первой инстанции более активные, то их диапазон исчерпается раньше и они получат новый в интервале с 0021 - 0030, так что уже имеем погрешность в среднем на величину размера локального буфера номеров для инстанции. Далее при перезагрузке системы не использованные номера не возвращаются, т.е. система зафиксирует последний используемый номер, пусть это будет 0030 из первой инстанции, а во второй пусть были выбраны только 5 номеров с 0011 - 0015, так вот при загрузке инстанции получат номер с 0031 - 0040 и с 0041 - 0050, т..е. каждая получит по следующему десятку номеров.
 
В общем виде, я бы считал номера заявок используя SELECT COUNT(*) FROM <таблица> WHERE <Условия> в с каком-нибудь отчете. Все остальные способы исходя из реализации работы с диапазонами номеров в SAP, будут давать погрешности в оценке количества документов/записей.

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

Статья неплохая, но читается сложно.
Так же, было бы целесообразно, указать, какие из описываемых методов есть в ECC (как было замечено в комментарии ранее).
 
Как ни странно, в ECC возможно практически все, что описано выше используя стандартную функциональности или минимальные доработки.
 
1) Фиксированное количество страхового запаса так же поддерживается в ECC. Для этого необходимо просто указать поле Страховой запас (MARC-EISBE).
 
2) Обеспеченность запасами поддерживается в ECC. Для использования необходимо указать в поле "Страховое время/ФактОборЗап"(MARC-SHZET) в рабочих днях. Так же необходимо используя индикатор Страховое время(MARC-SHFLG) указать, какая потребность будет "отодвигаться" - первичная или все. Кстати, данная возможность не описана. Не думаю, что это нельзя реализовать в APO.
Альтернативно, можно использовать профиль страхового времни (MARC-SHPRO), который можно использовать для того, чтобы задавать страховое время с привязкой к жестким периодам по датам.
 
3) Максимальное количество из фиксированного количества и обеспеченности запасами. Данного метода в ECC нет.
 
4) Страховой запас, как прогноз/потребность. Данный способ можно так же аналогично реализовать в MRP. Например, используя ведение дополнительных первичных потребностей по данному материалу в отдельной версии. Это вообще универсальный способ сделать практически любую модель, т.к. всегда можно написать АВАР программу по формированию данной потребности по любому алгоритму, и просто запускать ее перед кажжым запуском ППМ.
 
5) Статистический метод. В ЕСС можно так же использовать уровень сервисного обслуживания (указывается в ОЗМ поле MARC-MARC-LGRAD - уровень обеспеченности поставками) используя который на основании исторически-прогнозных данных может рассчитываться страховой запас.
 
6) Гибкое, экономически выгодное поддержание запаса. Очень похожая функциональность есть в ЕСС - в ОЗМ можно указать профиль динамической обеспеченности (MARC-RWPRO), который так же определяет методы расчета средней дневной потребности и уровни поддержания запаса в днях. Чего нет в стандарте - это учета количество дней распределения страхового запаса. Но мне кажется, что похожего результата можно добиться "играясь" имеющимися настройками.

Никогда бы не стал искать решение в пользовательских параметрах. Для этой цели (только в контроллинге) как то делали вариант транзакции, в спецрегистрах писали query, а для пользователей попроще писали инструкцию по обраoению с динамическими условиями выбора.
Жаль, что описан только вариант с платежами. Поиск по пользовательским параметрам в SU3 с выборкой по запросу *date* выдал 76 вариантов, надо копать, наверняка найдется что-то подходящее

Не знаю ни одного внедрения (по крайней мере в России), где бы функциональность IM вошла стандартном. Планирование без разбивки на кварталы-месяцы общая беда всего модуля IM, а уж заявок и подавно. Сложно докопаться до формул расчета эффективности, изменить стандартом тоже нельзя (бесспорно, это неверно с точки зрения методологии, но хотя бы расширение на этот счет не помешало бы).
Не зря данный функционал считается динозавром и вместо него предполагается исопльзование cProjects,cFolders, XRPM.

Интересно, хотя с российской спецификой это вряд ли пригодится.

Полезно было просмотреть. Аналогичное есть в MM (по материалам тр. MM17) и PS (тр.CNMASS).

Достаточно полезная информация, особенно для консультанта поддержки.