Разработка технологического процесса по организации обработки информации для составления аналитических обзоров бизнес-процессов на базе системы SAP BW

Содержание
Статья I. Введение
Статья II. 1 ОБОСНОВАНИЕ ВЫБОРА ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ
Статья III. 1.1 ERP системы
Статья IV. 1.2 Программный комплекс SAP R/3
Статья V. 1.2.1 Общие сведения
Статья VI. 1.2.2 Архитектура SAP R/3
Статья VII. 1.3 Информационное хранилище данных SAP BW
Статья VIII. 1.4 Предпосылки выбора системы
Статья IX. 1.5 Примеры использования ERP системы SAP BW
Статья X. 2 ТЕХНОЛОГИИ ИСПОЛЬЗУЕМЫЕ ХРАНИЛИЩЕМ ДАННЫХ SAP BW
Статья XI. 2.1 Business Intelligence
Статья XII. 2.2 Моделирование бизнеса
Статья XIII. 2.3 Структура информационного хранилища данных SAP BW
Статья XIV. 2.3.1 Информационная модель SAP BW
Статья XV. 2.3.2 Элементы информационной модели
Статья XVI. 2.4 Экстракция, преобразование, загрузка (ETL)
Статья XVII. 2.4.1 Основные сведения
Статья XVIII. 2.4.2 Экстракция, преобразование и загрузка (ETL) в SAP BW
Статья XIX. 2.5 Хранилище операционных данных (ODS)
Статья XX. 2.6 Многомерные модели и агрегаты
Статья XXI. 2.7 Схема «Звезда»
Статья XXII. 2.8 Общие сведения об аналитической отчетности
Статья XXIII. 2.9 Технология OLAP
Статья XXIV. 2.10 Язык программирования ABAP/4
Статья XXV. 3 РАЗРАБОТКА ТЕХНОЛОГИЧЕСКОГО ПРОЦЕССА ПО ОГАНИЗАЦИИ ОБРАБОТКИ ИНФОРМАЦИИ ДЛЯ СОСТАВЛЕНИЯ АНАЛИТИЧЕСКИХ ОБЗОРОВ БИЗНЕС-ПРОЦЕССОВ
Статья XXVI. 3.1 Постановка задачи
Статья XXVII. 3.1.1 Характеристика предприятия
Статья XXVIII. 3.1.2 Формулировка требований к разрабатываемому процессу
Статья XXIX. 3.2 Активация стандартных инфо-объектов SAP BW
Статья XXX. 3.3 Создание ракурсов исходных баз данных
Статья XXXI. 3.3.1 Ракурс «Мероприятия. Тексты»
Статья XXXII. 3.3.2 Ракурс «Мероприятия. Даты мероприятий»
Статья XXXIII. 3.3.3 Ракурс «Факт исполнения БДДС»
Статья XXXIV. 3.3.4 Ракурс «Затраты на материалы»
Статья XXXV. 3.4 Создание источников данных
Статья XXXVI. 3.5 Работа с данными на стадии загрузки
Статья XXXVII. 3.5.1 Копирование глобальных переменных из SAP R/3 в SAP BW
Статья XXXVIII. 3.5.1 Тиражирование источников данных
Статья XXXIX. 3.6 Создание инфо-источников
Статья XL. 3.6.1 Загрузка данных из PSA
Статья XLI. 3.6.1 Создание инфо-источника «Даты мероприятий»
Статья XLII. 3.6.2 Создание инфо-источника «Индикаторы мероприятий»
Статья XLIII. 3.6.3 Создание инфо-источника «Оценка материалов в мероприятиях»
Статья XLIV. 3.6.4 Создание инфо-источника «БДДС. Платежи. Факт и облиго»
Статья XLV. 3.6.5 Создание инфо-источника «БДР. Факт и облиго»
Статья XLVI. 3.7 Присвоение исходных систем инфо-источникам
Статья XLVII. 3.8 Перенос инфо-источников
Статья XLVIII. 3.8.1 Перенос инфо-источников в ODS-объекты
Статья XLIX. 3.8.2 Настройка правила переноса инфо-источника «Оценка материалов в мероприятиях» (ZMZB_COMPMAT_COST) и источника данных «Затраты на материалы» (ZCOMPMAT_COST)
Статья L. 3.8.3 Настройка правила переноса инфо-источника «Даты мероприятий» (ZMZTARNGM_DATES) и источника данных «Атрибуты мероприятия» (ZMZTARNGM_DATES) 56
Статья LI. 3.8.4 Настройка правила переноса инфо-источника «Индикаторы мероприятий» (ZMZTARNGM_INDIC) и источника данных «Мероприятия. Индикаторы» (ZMZTARNGM_INDIC)
Статья LII. 3.8.5 Настройка правила переноса инфо-источника «БДДС. Платежи. Факт и облиго»(ZMZB007) и источника данных «БДДС. Факт»(Z_FI_FACT)
Статья LIII. 3.9 Настройка правил обновления
Статья LIV. 3.10 Разработка ETL-процесса средствами ABAP
Статья LV. 3.10.1 Предпосылки создания ETL-процесса
Статья LVI. 3.10.2 Работа ETL-процесса
Статья LVII. Заключение
Статья LVIII. Список использованных источников
Статья LIX. Приложение А
Введение
Современным предприятиям приходится обрабатывать высокие объемы данных, причем количество входящих и исходящих данных быстро растет. Источники этих дан­ных нам хорошо знакомы – от систем электронно-кассо­вых терминалов до административных приложений бэк-офиса. Со все увеличивающейся скоростью эти данные поступают из растущего множества приложений электрон­ного бизнеса, которые генерируют и работают с большими объемами данных.
Количество данных, проходящих через подразделения современной компании, растет в геометрической прогрес­сии. Чтобы воспользоваться теми преимуществами, которые дает факт обладания своевременной и полной информаци­ей, предприятия применяют различные методы хранения и управления данными. Подход, предлагаемый компанией SAP для решения указанных задач, позволяет объединять дан­ные из отдельных систем, предоставляя компаниям единый, последовательный ракурс информации о клиентах, опера­циях и других аспектах бизнеса.
SAP Business Information Warehouse (SAP BW) – это компо­нент mySAP Business Intelligence (mySAP BI), который обеспечивает хранение данных в пределах всего предпри­ятия, платформу для бизнес-информации и ряд инструмен­тов преобразования данных. Затраты на приобретение SAP BW благодаря его комплекс­ным возможностям могут быть ниже, чем на приобретение автономных частных технологий. Интегрированный подход сокращает затраты на внедрение и обслуживание. А так как система более простая, то она обеспечивает большую гибкость с течением времени.
Темой данного дипломного проекта является разработка технологического процесса по организации обработки информации для составления аналитических обзоров бизнес-процессов на базе системы SAP BW. Целью проекта является разработка технологического процесса загрузки данных из ERP-системы SAP R/3 в информационное хранилище данных SAP BW для их обработки, структурирования и последующего анализа.
1 ОБОСНОВАНИЕ ВЫБОРА ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ
1.1 ERP системы
Сегодня основным условием стабильного функционирования компании на рынке становится совершенствование процедур организационно-экономического управления. В частности, разработка более эффективных систем управления касается и сферы IT.
Большинство пользователей представляет информационные системы предприятия как некие помещения, до отказа наполненные компьютерами. И хотя ядро информационной инфраструктуры имеет нечто общее с данным предположением, ее «сердцем» является не вычислительная техника, а программное обеспечение. На базе современных компьютерных технологий создано поколение систем управления, именуемое ERP (Enterprise Resource Planning – планирование ресурсов предприятия, то есть системы управления ресурсами). Такие системы предоставляют возможность работать на интегрированном информационном поле множеству удаленных пользователей, что обеспечивает максимальный эффект при управлении крупными производствами и корпорациями. Родоначальником рынка ERP-систем стала немецкая компания SAP AG с продуктом R/3. К числу же наиболее значительных представителей рынка можно отнести фирмы PeopleSoft, Oracle, Baan и J.D. Edwards.
Идея таких систем состоит в том, что элементы ПО, предназначенные для поддержки разных функций предприятия, должны непрерывно взаимодействовать между собой. По сути, ERP-система пытается «воспроизвести» бизнес-процессы в программном обеспечении и сопровождать каждое действие того или иного сотрудника.
Среди отечественных компаний превалируют решения типа «все-в-одном», которые очень часто не оправдывают себя, так как могут работать с очень ограниченным кругом задач. Зачастую в неудачах винят консультантов, предлагающих более сложные и, следовательно, дорогие решения, чем требует предприятие. Однако вина подобных специалистов не столь велика, как кажется – ведь чаще всего представители предприятия сами просят именно ERP-систему, не задумываясь о том, что проще и разумнее воспользоваться другими средствами.
На данном этапе развития сферы бизнеса, понятие «ERP» значительно расширилось. Разумеется, речь не идет о ключевых изменениях, поскольку системы все так же планируют распределение ресурсов, однако этой областью применения не ограничиваются. Например, в одном из словарей приводится следующее определение: «Набор интегрированных приложений, позволяющих создать единую среду для автоматизации планирования, учета, контроля и анализа всех основных бизнес-операций предприятия, финансы, снабжение, сбыт, хранение, техническое обслуживание и т. д.». Собственно, к этому перечню можно добавить реализованные в ряде ERP-систем SSM (поддержку управления сбытом и сервисом), SCM (управление цепочками поставок), PDM (данные о продукции), а иногда и CRM (стратегии отношений с клиентами). Изначально все эти функции не вписывались в концепцию ERP, которые были лишь одним из таких же классов, однако тенденция к многофункциональности информационных систем постепенно набирает обороты. То есть получается, что в отдельных случаях несоответствие объема работы и используемых систем ассоциируется с выражением «что слишком – то не здраво».
ERP-системы позволяют решить следующие задачи:
– организовать эффективное планирование всей финансовой и хозяйственной деятельности;
– повысить доверие инвесторов путем формирования максимальной прозрачности бизнеса;
– снизить риски и увеличить прибыль за счет оперативного принятия решений и их точности, интуитивности системы управления, разграничения доступа к информации в соответствии с должностями сотрудников, и реализации функций ее безопасности;
– сократить количественный аспект потерь рабочего времени за счет исключения дублирования данных разными службами и организации беспрепятственного обмена данными между отделами компании.
Унифицированная природа ERP предоставляет значительные преимущества, включая уменьшение количества ошибок, большую скорость и эффективность доступа к информации. В свою очередь, корректно организованный доступ поможет руководителям быстро ориентироваться в любой ситуации, имеющей место на предприятии, и повысить вероятность принятия правильного решения за счет оперативного информирования о проблеме и ее точного определения.
Изначально ERP создавались для обслуживания информационных потребностей производственных предприятий. Со временем сфера их применения расширилась за счет использования в здравоохранении, финансовых услугах, секторе потребительских товаров и т. д. Более того, если ранее ERP-системы функционировали только на мощных вычислительных центрах класса мейнфреймов, то теперь они успешно функционируют в рамках клиент-серверных систем и включают на порядок больше функций и возможностей.
Стандартный процесс внедрения ERP-системы состоит из следующих этапов:
а) Разработка стратегий автоматизации.
б) Анализ деятельности предприятия.
в) Реорганизация деятельности.
г) Выбор системы.
д) Внедрение системы.
е) Использование (эксплуатация + сопровождение).
Понятие «стратегия автоматизации» состоит из базовых принципов, которые используются при автоматизации предприятия:
– цели (выявление областей деятельности предприятия и последующая их автоматизации);
– способ автоматизации (по отделам, направлениям или комплексная автоматизация);
– долгосрочная IT-политика (внедрения комплекса внутренних стандартов);
– ограничения (финансовые, временные, кадровые и т. д.);
– процедура управления изменениями в планировании.
Анализ деятельности предприятия – довольно общее понятие, а потому в данном случае под ним подразумевается сбор и представление данных о деятельности компании в формализованном виде, пригодном для последующего выбора и дальнейшей разработки проекта внедрения автоматизированной системы.
Технологии сбора и представления информации отличаются в зависимости от выбранной стратегии автоматизации, однако заканчивать анализ предприятия необходимо построением набора моделей, пригодных для внедрения.
Реорганизация деятельности необходима для повышения эффективности функционирования предприятия в целом. Так, существует несколько методик реорганизации.
Методика ISO 9000 является стандартом качества проектирования, разработки, изготовления, гарантийного и постгарантийного обслуживания. Он определяет основной набор мероприятий по контролю за качеством продукции и представляет собой не что иное, как схему функционирования бизнес-процессов компании, призванную обеспечить наивысшее качество работы. В то же время ISO 9000 не является стандартом для производимых товаров или услуг, а лишь очерчивает этапы выпуска продукции – от покупки производственных материалов до обслуживания клиентов.
Такая система имеет два ключевых момента. Во-первых, необходимо четкое документированное наличие соответствующего бизнес-процесса, а во-вторых, должна быть возможность объективной оценки его качества. Поэтому сертификация компании по данному стандарту состоит из трех этапов: оценка применения стандартов на предприятии, проведение сертификации соответствующими органами и проведение два раза в год проверки предприятия на соответствие стандартам ISO 9000.
Хотелось бы добавить, что подобная сертификация – дело добровольное, однако многие зарубежные компании часто требуют подобный сертификат качества от своих поставщиков. Кроме того, без наличия данного стандарта участие предприятия в международных тендерах, государственных заказах, а также получение льготных кредитов или страхования становится достаточно проблематичным или вообще невозможным.
Хаммер и Чампи определяют BPR (Business processes reengineering) как глобальное переосмысление и радикальное изменение планирования бизнес-процессов предприятий для повышения эффективности их деятельности. При этом используются такие положения, как:
– объединение нескольких рабочих процессов в один;
– предоставление исполнителям права принимать решения в рамках своей ответственности;
– естественный порядок проведения этапов процесса;
– реализация нескольких версий процесса;
– выполнение работы в тех областях, где она наиболее целесообразна;
– снижение уровня ресурсов, выделяемых для проверки и контроля;
– уменьшение количества необходимых согласований;
– реализация связи клиента с процессом через ответственного менеджера;
– использование как централизованных, так и децентрализованных операций.
Выбор системы зависит от множества критериев и связан с качеством и полнотой проработки всех предшествующих этапов цепочки. Все объективные соображения, которыми руководствуются при выборе той или иной системы, – ее функциональные возможности, стоимость, затраты на поддержку, технические характеристики и т. д. – выводятся на предыдущих этапах. Также, именно в результате их проведения, решается, будет ли внедрена готовая система или придется создавать программное обеспечение непосредственно под имеющееся предприятие. Некоторые компании могут оценивать, что проще и дешевле: своими силами создать ERP-систему или приобрести ее на стороне. Но одно дело доверить столь ответственное задание специалистам, которые долгие годы занимаются подобными проектами и имеют авторитет на рынке, другое – собрать IT-отдел и заказать написание системы ему. Основные аргументы против такого подхода следующие:
– на написание стандартных промышленных систем, таких как SAP, Oracle Applications, People Soft затрачены огромные силы и ресурсы. Причем это касается не только написания, но и последующей отладки ERP-системы. Так, на разработку последней интернет-ориентированной ERP-системы компания PeopleSoft потратила $500 млн и два года работы 2 тыс. разработчиков;
– промышленные системы опробованы и работают на тысячах предприятий всего мира: например, у того же SAP R/3 более 15 тыс. клиентов;
– как правило, стандартные системы сопровождаются выверенными методологиями внедрения;
– в случае с «самописной» системой человек, ее написавший, может при увольнении забрать все свои наработки, что невозможно при использовании стандартных систем;
– отладка приложений стандартной системы значительно проще и дешевле, нежели созданной своими руками.
Критерии выбора систем индивидуальны для каждого предприятия и зачастую основаны на технологиях, используемых в их рамках. Общие же моменты таковы. Во-первых, ИС управления предприятием должна быть полностью интегрированной и не только обеспечить реализацию бизнес-процедур компании, но и предоставить возможность гибкой настройки бизнес-процессов в системе. Во-вторых, система не должна быть избыточной. В-третьих, она должна быть защищена от несанкционированного проникновения и обеспечивать полную аутентификацию доступа к данным. Кроме того, система должны быть построена на открытых стандартах и включать средства разработки – это поможет настроить ее под нужды отдельного предприятия.
Внедрение системы может проводиться с использованием одной из четырех стратегий:
а) Параллельная стратегия осуществляется путем одновременной работы старой и новой систем с последующим сравнением документации. В случае если продолжительное время их согласование не составляет никаких трудностей, можно полностью переходить на новую систему.
б) Скачкообразная стратегия – самый рискованный вариант. В кратчайшие сроки происходит отказ от старой и внедрение новой системы. При этом отладка оборота происходит, что называется, на ходу.
в) Пробная стратегия реализуется путем применения новой системы к ограниченному числу процессов или небольшому участку деятельности. Эта тактика наиболее надежна, потому что поддерживает максимальную длину отката.
г) Малая стратегия – автоматизация небольшой части производственного процесса. То есть план внедрения осуществляется только для выделенного участка, анализ эффективности также проводится только для него, и т. д.
Почти все вендоры промышленных ERP-систем владеют (или предлагают) быстрой технологией внедрения, рассчитанной на 3-6 месяцев. Этот промежуток реален лишь для небольших предприятий малого и среднего бизнеса, но крупной компании лишь на внедрение в сфере финансов и бухгалтерии потребуется от 9 до 12 месяцев, столько же понадобится отделу логистики, а также для производственной части.
Однако не стоит заранее расстраиваться из-за длительности процесса, поскольку внедрение происходит поэтапно, результаты работы системы будут видны после проведения каждого из них.
Этап эксплуатации, или сопровождения, в рамках динамических условий предприятия является достаточно сложным. Во-первых, из-за физического и морального старения компонентов нужна оперативная модернизация программно-аппаратной части комплекса. Во-вторых, необходимо постоянно следить за изменениями в законодательной базе. Кроме того, система требует отдельной доработки под новые требования пользователей, обеспечения безопасности данных и т. д.
Под экономическими выгодами подразумевается получение реальной экономической отдачи от использования всего пакета приложений и отдельных функциональных блоков системы. К примеру, объем поставок, выполненных в срок, может увеличиться до 80%, точность учета затрат – на 30%, расходы на управленческий аппарат могут уменьшиться на четверть, а транспортные расходы снизиться в полтора раза.
Развертывание и поддержка ERP-системы – сложный и трудоемкий процесс, требующий не только высокой квалификации, но и значительных финансовых вливаний. Причем последние могут быть как очевидными (запланированными), так и совершенно неожиданными. Чтобы избежать лишних издержек, следует заранее учесть скрытые затраты на внедрение ERP-систем, а также те основные проблемы, которыми оно может сопровождаться.
а) Планирование и управление проектом. IT-персоналу необходимо время, чтобы спланировать и оценить область охвата проекта, затраты и графики выполнения плана. Немаловажно убедиться, что за руководство процессом отвечает специалист, хорошо разбирающийся не только в компьютерных технологиях, но и в бизнес-процессах, а также способный видеть проект в целом, а не его составляющие. В противном случае может оказаться, что временные задержки и отсутствие оперативного реагирования на изменения плана приведут к полному краху внедрения.
б) Как уже упоминалось, зачастую компании недооценивают время и средства, необходимые для интеграции программного обеспечения. Важно понимать, что ERP-система должна быть так или иначе связана с первичным программным обеспечением бизнес-процессов, которое занимается предварительной обработкой данных. Иначе перенос информации будет занимать слишком много времени и обладать очень низкой эффективностью.
в) Тестировать систему следует до ее запуска. Лучше всего, если перед внедрением глава проекта некоторое время поработает с демоверсией данного продукта, примененного на узком, не особенно важном участке работы. Свое тестирование должны провести и сотрудники, обслуживающие специфические бизнес-процессы, так как после внедрения системы полностью поменять ее функциональность в любой из специализированных областей будет довольно сложно.
г) Весьма важным аспектом является обучение персонала. Неправильно думать, что кадры необходимо лишь научить пользоваться новой системой. Людей нужно подготовить к изменениям, которые несет глобальное внедрение, мотивировать их отдачу и принять новые формы контроля: ведь сколько бы денег не было вложено в автоматизацию, она не достигнет цели, если будет отторгнута персоналом.
д) Еще одной статьей расходов станет оплата консалтинга. не следует считать, будто справиться со столь объемным массивом работ можно, используя лишь собственные активы, так или иначе, даже самые толковые специалисты могут столкнуться с незнакомыми условиями и вопросами, для решения которых понадобится внешний специалист.
е) Принять меры для предотвращения неудачного внедрения ERP-систем, разумеется, необходимо, однако 100%-й успешности интеграции не может гарантировать никто. Поэтому неудивительно, что не менее актуальной, нежели правильный подход к установке системы, является и ликвидация негативных последствий внедрения.
Так как определение успешности не бывает однозначным, заранее примем за константу, что неудачное внедрение – это сохранение экономической эффективности на начальном уровне или же снижение ее значения относительно начального уровня.
Исправлениями ошибок занимаются некоторые компании-консультанты, но результаты их деятельности напрямую зависят от значимости и запущенности сбойных звеньев системы в целом. Если переустановка одного модуля, например управления ремонтами, достаточно проста, то ликвидация ошибок в ядре требует повторного проведения интеграции с нуля. А потому лучше заранее обезопасить себя от негативных последствий и провести тестирование системы до того, как она окончательно войдет в эксплуатацию[9].
1.2 Программный комплекс SAP R/3
1.2.1 Общие сведения
SAP R/3 является одним из наиболее развитых продуктов категории ERP. Система основана на трехзвенной архитектуре “клиент/сервер”:
– Уровень представления обеспечивает графический пользовательский интерфейс на PC, связанных с серверами приложений через локальную или глобальную сеть.
– На прикладном уровне выполняются предопределенные или определяемые пользователями приложения категорий OLTP или OLAP. Обычно серверы приложений связываются с сервером баз данных через локальную сеть.
– На уровне баз данных функционирует один из коммерческих серверов баз данных (например, Adabas D, IBM UDB, Informix Dynamic Server, Microsoft SQL Server или Oracle8).
Приложения для SAP R/3 пишутся на интерпретируемом языке четвертого поколения ABAP/4 (Advanced Business Application Language). За исключением небольшого ядра, вся система R/3 написана на ABAP/4. Для доступа к базам данных в ABAP/4 поддерживаются два интерфейса: Native SQL и Open SQL. Для управления транзакциями (LUW – Logical Unit of Work – в терминологии SAP) компанией реализован собственный монитор транзакций. Для использования в режиме обработки транзакций R/3 включает возможности настройки компонентов управления памятью и кэширования данных на серверах приложений. Имеются две собственные возможности оптимизации запросов к базам данных (при использовании Open SQL): кэширование курсора и кэширование данных. В R/3 имеются также развитые средства мониторинга и оценки производительности.
Система R/3 состоит из набора прикладных модулей, которые поддерживают различные бизнес-процессы компании и интегрированы между собой в масштабе реального времени.
Рассмотрим наиболее важные модули системы SAP R/3.
Финансы (FI). Модуль предназначен для организации основной бухгалтерской отчетности, отчетности по дебиторам, кредиторам и вспомогательной бухгалтерии. Он включает в себя: Главную книгу, Бухгалтерию дебиторов, Бухгалтерию кредиторов, Финансовое управление, Специальный регистр, Консолидацию и Информационную систему учета и отчетности.
Контроллинг (CO). Модуль обеспечивает учет затрат и прибыли предприятия и включает в себя: Учет затрат по местам их возникновения (центры затрат), Учет затрат по заказам, Учет затрат по проектам, Калькуляцию затрат, Контроль прибыльности (результатов), Контроль мест возникновения прибыли (центров прибыли), Учет выработки, Контроллинг деятельности предприятия.
Управление основными средствами (AM). Модуль предназначен для учета основных средств и управления ими. Ключевые элементы модуля: Техническое управление основными средствами, Техобслуживание и ремонт оборудования, Контроллинг инвестиций и продажа активов, Традиционный бухучет основных средств, Замена основных средств и амортизация, Управление инвестициями.
Управление проектами (PS). Прикладной модуль PS поддерживает планирование, управление и мониторинг долгосрочных проектов с высоким уровнем сложности. Ключевые элементы прикладного модуля PS: Контроль финансовых средств и ресурсов, Контроль качества, Управление временными данными, Информационная система управления проектами, Общие модули.
Производственное планирование (PP). Модуль используется для организации планирования и контроля производственной деятельности предприятия. Ключевые элементы прикладного модуля: Спецификации (BOM), Технологические карты, Рабочие центры (места), Планирование сбыта (SOP), Производственное планирование (MPS), Планирование потребности в материалах (MRP), Управление производством (SFC), Производственные заказы, Калькуляция затрат на изделие, Учет затрат по процессам, Серийное производство, Канбан (Just in time), Планирование непрерывного производства.
Управление материальными потоками (MM). Модуль поддерживает функции снабжения и управления запасами, используемые в различных хозяйственных операциях. Ключевые элементы: Закупка материалов, Управление запасами, Управление складами, Контроль счетов, Оценка запасов материала, Аттестация поставщика, Обработка работ и услуг, Информационная система закупок и информационная система управления запасами.
Сбыт (SD). Модуль решает задачи распределения, продаж, поставок и выставления счетов. Ключевые элементы: Предпродажная поддержка, Обработка запросов, Обработка предложений, Обработка заказов, Обработка поставок, Выставление счетов (фактурирование), Информационная система сбыта.
Управление качеством (QM). Этот модуль включает в себя информационную систему и систему управления качеством. Он обеспечивает поддержку планирования качества, проверку и контроль качества при производстве и закупках. Ключевые элементы: Проверка качества, Планирование качества, Информационная система контроля качества (QMIS).
Техобслуживание и ремонт оборудования (PM). Модуль помогает учитывать затраты и планировать ресурсы на техобслуживание и ремонт. Ключевые элементы: Незапланированный ремонт, Управление сервисом, Планово-профилактический ремонт, Ведение спецификаций, Информационная система техобслуживания и ремонта.
Управление персоналом (HR). Полностью интегрированная система для планирования и управления работой персонала. Ключевые элементы: Администрирование персонала, Расчет зарплаты, Управление временными данными, Расчет командировочных расходов, Льготы, Набор новых сотрудников, Планирование и повышение квалификации персонала, Использование рабочей силы, Управление семинарами, Организационный менеджмент, Информационная система персонала.
Даже самый краткий обзор функций системы R/3 показывает ее способность решать основные задачи, стоящие перед крупными организациями. SAP R/3 – это самая обширная система на сегодняшний день. Не случайно многие лидеры мировой экономики именно ее выбрали в качестве основной корпоративной системы. Тем не менее, статистика показывает, что более трети компаний, покупающих R/3 – это средние фирмы с годовым оборотом менее 200 млн долл. Дело в том, что R/3 – конфигурируемая система, поэтому, купив ее, предприятие будет работать с индивидуальной версией, настроенной именно под его параметры. Показателем технического уровня системы может служить способ ее настройки. Чем шире возможности конфигурирования и настройки системы без необходимости ее переписывания, тем выше технический уровень данной системы. Поэтому параметру R/3 также занимает лидирующее положение в мире.
1.2.2 Архитектура SAP R/3
SAP R/3 представляет собой многослойную систему и состоит из сервера базы данных, сервера приложений и сервера представления информации (рисунок 1).
Указанные компоненты архитектуры предназначены для выполнения следующих функций:
Сервер базы данных. Сервер базы данных используется для хранения всех долговременных данных (persistent data) в системе SAP R/3. Однако, не все данные SAP R/3 могут быть получены посредством SQL, поскольку некоторые из них находятся в специальных форматах: объединенных (pool) и кластерных (cluster) таблицах. Эти таблицы сжимают несколько логических таблиц в одну физическую таблицу. В результате, становится невозможно устанавливать соответствие между логическими таблицами SAP R/3, описанными в словаре данных SAP R/3, и таблицами или аналитическими выборками, хранимыми на сервере базы данных.

Рисунок 1 – Архитектура SAP R/3
Сервер приложений. Сервер приложений связывается с сервером базы данных и исполняет программы (написанные на ABAP), которые реализуют бизнес-модели. В большинстве случаев, к бизнес-логике этих программ можно получить доступ, обратившись к ABAP-функциям. Кроме того, часть информации не хранится в таблицах, а вычисляется с помощью удаленного вызова этих функций (RFC, remote function call) во время исполнения. Сервер приложений – этот как раз то место, где находится SAP BAPI (Business Application Programming Interface, Бизнес-интерфейс прикладного программирования компании SAP).
Сервер представления информации. Сервер представления информации функционирует на рабочем месте каждого пользователя: обрабатывает команды, вводимые с клавиатуры, управляет отображением информации и обеспечивает связь с исполняемыми на сервере приложений программами, реализующими бизнес-модели. При этом, клиентские машины не задействованы в выполнении бизнес-логики.
При создании технологии R/3, предполагалось, что только небольшое количество пользователей будут досконально знать эту систему. Ожидалось, что они будут управлять набором стандартных отчетов и предоставлять информацию всем тем, кому она необходима. Однако, появление Интернета полностью изменило положение вещей: теперь за информацией можно обратиться из любой точки земного шара, в любой момент времени. Мгновенный доступ к информации, без привлечения сотрудников технических отделов – одно из требований, предъявляемых к системам поддержки принятия решений.
Помимо того, со временем стало очевидно, что стандартные отчеты SAP, о которых говорилось выше, больше не могут удовлетворять информационные потребности работников, ответственных за принятие решений. С этой целью, в систему SAP R/3 был встроен свой собственный язык репортинга: язык ABAP (Advanced Business Application Programming, Программирование продвинутых бизнес приложений). Этот язык позволяет создавать отчеты, отвечающие самым разнообразным пожеланиям пользователей.
Тем не менее, все больше и все больше бизнес-пользователей нуждаются в проведении сложного анализа и составлении отчетов. А IT-специалисты уже не могут “обслужить все новых и новых клиентов”. Сами пользователи не могут воспользоваться мощью ABAP, поскольку ABAP – крайне сложный язык, к тому же нетехнический специалист просто не в состоянии освоить запутанную модель данных SAP (которая включает более 10 тысяч таблиц, каждый из которых состоит из сотен столбцов). Поэтому для того, чтобы получить данные SAP, необходимо прибегнуть к средствам репортинга третьих фирм, либо использовать потенциальные возможности технологии SAP R/3.
Ниже изложены три основных подхода, которые можно использовать для получения данных SAP R/3.
1.3 Информационное хранилище данных SAP BW
SAP Business Information Warehouse (SAP BW, хранилище бизнес информации SAP) – это комплект интегрированных компонент, предназначенных для сбора, хранения, анализа и администрирования данных SAP (и других данных). Другими словами, SAP BW – это система, которая опирается на технологию хранилищ данных и позволяет получать доступ к данным, полученным как из систем SAP, так и других корпоративных приложений.
Базовая структура SAP BW является многомерной, то есть извлеченные данные агрегируются в многомерные склады (store) данных – кубы InfoCube, которые затем используются при репортинге и анализе информации. На основании этих концепций SAP BW поставляет информационную модель, которая формирует основу для ответа на все вопросы, которые ставит современный бизнес. Эта способ­ность базируется, в основном, на предоставлении тех дан­ных, которые обладают соответствующей структурой, степенью детализации и своевременны для данного анализа. Вес этих факторов различен в зависимости от ситуаций и пользователей компании.
При этом, компании могут использовать как предопределенные кубы InfoCube, так создавать свои собственные. Для анализа информации, находящейся в кубах InfoCube, и генерации отчетов, можно применять не только средства аналитики от SAP, например SAP Business Explorer Analyzer, но и продукты третьих фирм. Доступ к данным кубов InfoCube осуществляется через стандартный интерфейс OBDO (OLE-DB for OLAP, OLE для баз данных под OLAP). OBDO – это универсальный протокол, который компания SAP встроила в свое SAP BW (рисунок 2).
SAP BW использует кубы InfoCube в качестве своего источника данных. Эти кубы хранятся в базе данных по схеме “звезда”. Для того, чтобы конечный пользователь мог обратиться к кубам InfoCube, администратор Хранилища данных с помощью приложения Business Explorer Analyzer компании SAP готовит эти кубы, разбивая их на кубы Query Cubes. Затем эти кубы активируются, чтобы к ним было можно обратиться через ODBO, то они становятся доступными для программ анализа, предлагаемых третьими фирмами.
Как было указано выше, кроме фирменных средств анализа данных, хранящимся в SAP BW, Хранилище данных позволяет применять сторонние средства. Примером успешного решения можно считать программное обеспечение, предлагаемое компаниями Brio и Cognos. Оба OLAP-клиента этих фирм опираются на технологию ODBO.
Для того, чтобы связать PowerPLay – программный продукт Cognos – с кубами InfoCube, используется специальная утилита, которая создает куб Pointer Cube. Эти кубы содержат информацию, необходимую для установления соединения с данными Хранилища, и сведения о том, какой драйвер SAP следует активировать, чтобы PowerPLay мог обращаться к данным Query Cubes.

Рисунок 2 – Архитектура SAP BW
Подобно решению Cognos, приложение, поставляемое Brio – Brio Intelligence – позволяет проводить OLAP-операций над данными, хранимыми в кубах Query Cubes. К достоинству Brio Intelligence также можно отнести возможность построения SQL-запросов.
Кроме того, продукты обеих компаний могут использоваться для генерации отчетов.
1.4 Предпосылки выбора системы
Компании практически во всех областях бизнеса осознали, что способность заставить данные работать эффективно играет важную роль для достижения успеха. Данные в их действительном смысле – это животворная основа бизнеса, поэтому сбор данных и их понимание являются ключевыми моментами для нескольких фундаментальных областей.
Идентификация проблем и возможностей в постоянно изменяющейся и быстрорастущей бизнес-среде. Для того чтобы быть впереди своих конкурентов, жизненно необ­ходимо обладать способностью четко отслеживать производительность и определять направления и возможности развития бизнеса.
Поддержка стратегических бизнес-инициатив. Приложения и методы ведения бизнеса, такие как управ­ление связями с клиентами, управление логистической цепочкой и сервис для ведущих сотрудников, должны иметь способность к управлению большими объемами данных из разных источников.
Поддержка сотрудничества. Для того чтобы быть конкурентоспособным, Ваше предприятие должно иметь возможность совместно использовать точные данные во всех внутренних функциональных областях бизнеса и за его пределами, чтобы сотрудники и деловые партнеры могли сотрудничать, быстро реагировать на изменения, рационализировать операции и поставлять инновацион­ные продукты.
Чтобы эффективно использовать большие объемы данных, перемещающихся по всей компании, многие предприятия создают специализированные хранилища данных. Эти хранилища спроектированы таким образом, чтобы собирать данные из разных систем и платформ, чтобы у компании была “одна версия правды”, т.е. единый последовательный ракурс информации о клиентах, операциях и других аспек­тах бизнеса. Имея возможность сбора данных и их преобра­зования в информацию через аналитику, компании получа­ют поддержку своих усилий в отношении сохранения кли­ентов, увеличения эффективности, контроля над затратами и увеличения доходов.
Эта концепция достаточно проста, но на практике многим компаниям приходится прикладывать максимальные усилия для достижения позитивных результатов от вложенных затрат по организации хранения данных. Каждая ситуация индивидуальна, но есть три общих фактора, которые влияют на неуспех реализации концепции хранения данных: частные технологии; фрагментарные, противоречивые данные и ограниченное принятие системы конечными пользователями.
Слишком часто компании пытаются построить процесс хра­нения данных и инфраструктуры бизнес-информации при помощи разнородных инструментов и приложений, которые требуют значительной интеграции. Это ведет к более высо­ким затратам на внедрение на начальном этапе и сокраще­нию возможностей по адаптации системы в течение длитель­ного срока по причине сложности различных технологий, интерфейсов и форматов.
1.5 Примеры использования ERP системы SAP BW
Newport News Shipbuilding — это крупнейшее в США частное судостроительное предприятие, работающее по заказам МО США. При внедрении в 1999 г. в компании ERP-системы SAP R/3 была обнаружена необходимость совершенствования технологии генерации и распространения корпоративных отчетов. Фактически нужно было создать корпоративную среду генерации и распространения отчетов. Кроме того, возник еще ряд проблем. Во-первых, некоторая необходимая информация всё еще находилась в унаследованных системах. Сотрудники компании, проработавшие в ней достаточно большой срок, привыкли обращаться к этой информации, однако новые сотрудники предпочитали работать только с системой SAP R/3. Кроме того, было выявлено, что средства генерации отчетов в SAP R/3 не обеспечивали всех потребностей компании.
Именно поэтому в 2002 г. в Newport News Shipbuilding и началось внедрение ПО управления выводом и генерацией отчетов посредством технологии SAP BW, с помощью которой Newport News собиралась исключить ручную печать и распространение отчетов. Если в ноябре 2002 г. с BW работало 2000 сотрудников из разных подразделений компании, то уже к октябрю 2003 г. их число достигло 3700.
Через единый интерфейс сотрудники компании получают доступ ко всем генерируемым корпоративным отчетам, независимо от их источника. В системе автоматически генерируются тысячи отчетов (только по одному разу) и с помощью SAP BW по графику доставляются пользователям. В ходе своей работы SAP BW захватывает поток отчетов, выводимых на печать, и позволяет определять получателя каждого конкретного отчета и метод его доставки пользователю (удаленный принтер или факс, очередь заданий, электронная почта и др.). В результате внедрения SAP BW компания Newport News ежегодно экономит до $500000 (вследствие исключения расходов на печать и распространение отчетов). В настоящее время Newport News Shipbuilding переходит на ОС MS Windows XP и более новую версию SAP BW, модуль доставки Web-документов, обеспечивающий персонализированную страницу портала для пользователей (доступ к ней осуществляется через Web-браузер MS Internet Explorer). Весь проект внедрения предполагалось закончить к июлю 2005г.

2 ТЕХНОЛОГИИ ИСПОЛЬЗУЕМЫЕ ХРАНИЛИЩЕМ ДАННЫХ SAP BW
2.1 Business Intelligence
Термин «Business Intelligence» (далее BI) существует сравнительно давно, хотя у нас он мало употребляется из-за отсутствия адекватного перевода и четкого понимания, что, впрочем, характерно и для запада.
В русском языке слово «интеллект» однозначно понимается, как мыслительная способность человека. На первый взгляд неплохой перевод для термина Business Intelligence предложен как «интеллектуальный анализ данных», но сразу возникает вопрос, а имеется ли «неинтеллектуальный анализ данных».
На неопределенность обсуждаемого термина повлияла многозначность английского слова «Intelligence»:
– способность узнавать и понимать; готовность к пониманию;
– знания, переданные или приобретенные путем обучения, исследования или опыта;
– действие или состояние в процессе познания;
– разведка, разведывательные данные.
Впервые термин BI был введен в обращение аналитиками Gartner в конце 1980-х годов, как «пользователецентри-ческий процесс, который включает доступ и исследование информации, ее анализ, выработку интуиции и понимания, которые ведут к улучшенному и неформальному принятию решений». Позже в 1996 году появилось уточнение — «инструменты для анализа данных, построения отчетов и запросов могут помочь бизнес-пользователям преодолеть море данных для того, чтобы синтезировать из них значимую информацию, — сегодня эти инструменты в совокупности попадают в категорию, называемую бизнес-интеллект BI.
Согласно первоначальным определениям, BI — это процесс анализа информации, выработки интуиции и понимания для улучшенного и неформального принятия решений бизнес-пользователями, а также инструменты для извлечения из данных значимой для бизнеса информации. Надо отметить, что большинство определений трактуют «Iusiness Intelligence» как процесс, технологии, методы и средства извлечения и представления знаний[9].
2.2 Моделирование бизнеса
Как следует из графической интерпретации пирамиды бизнес-информации (рисунок 3) решение для управления бизнес-информацией, поддерживающее способность разрешать все вопросы, связанные с бизнесом, жизненно важно для получения высокой прибыли на вло­женный капитал. Поэтому способность моделиро­вать бизнес-структуру компании детально обычно явля­ется критическим фактором для успеха проекта системы хранения данных.
SAP Business Information Warehouse (SAP BW) – это компо­нент mySAP BI, который включает в себя механизм хранения данных в масштабах предприятия, платформу для бизнес-информации и набор инструментов для работы с бизнес-ин­формацией. Он был спроектирован изначально для предос­тавления самых эффективных инструментов моделирования бизнеса и методологий – и сегодня возможности SAP в этой области признаны лучшими среди подобных решений. Под­ход SAP к моделированию бизнеса основан на нескольких фундаментальных концепциях:
– технология следует за бизнес-структурой, а не наоборот;
– информация должна предоставляться в ракурсе бизнеса;
– модели данных быстро адаптируются к изменениям и при этом необходимость в повторной конфигурации отсутствует.
На основании этих концепций SAP BW поставляет информационную модель, которая формирует основу для ответа на все связанные с бизнесом вопросы.

Рисунок 3 – Пирамида бизнес-информации
Для удовлетворения этих разнообразных потребностей SAP BW поддерживает три концептуальных уровня хранения данных: хранилище операционных данных, хранилище дан­ных и многомерные модели. В следующих разделах рассма­тривается информационная модель, на основании которой строятся эти три слоя[4].
2.3 Структура информационного хранилища данных SAP BW
2.3.1 Информационная модель SAP BW
Информационная модель SAP BW основывается на фунда­ментальном структурном блоке, который называется инфо-объектом. Инфо-объекты содержат данные о клиентах, заказе клиента и т.д. Они также являются носителями мета­данных, которые описывают данные, содержащиеся в инфо-объекте, такие как их происхождение, история и техниче­ские свойства (рисунок 4).
В инфо-объекте есть три класса метаданных:
– технические метаданные описывают технические cвойства, такие как тип данных и длина поля;
– метаданные пользователя несут информацию о полномочиях;
Бизнес-определения особенно важны в информационной модели SAP BW. Они устраняют семантические несоответ­ствия в элементах данных в разных системах и организа­ционных единицах и следят за тем, чтобы данные были непротиворечивыми и достоверными. SAP BW содержит более 5000 шаблонов инфо-объекта, которые включают в себя бизнес-определения. Дополнительную информацию по тому вопросу можно найти в разделе “Управление хра­нилищем данных”.
Метаданные играют фундаментальную роль в преобразова­нии данных в информацию. В этом процессе метаданные предоставляют контекст и понимание того, каким образом соединены разные элементы данных. Для создания полез­ной бизнес-информации к комбинации данных и метадан­ных применяются бизнес-правила. Информационная модель SAP BW предоставляет последовательные и интегрирован­ные метаданные для всех объектов по всему процессу хранения данных[5].

Рисунок 4 – Информационная модель SAP BW
2.3.2 Элементы информационной модели
Инфо-объекты – основополагающие элементы информаци­онной модели SAP BW Инфо-объект может быть легко использован повторно в элементах информационной модели (рисунок 4).
На рисунке 4 показано, что все объекты информацион­ной модели хранят метаданные. Три из четырех элементов в информационной модели также хранят переменные или ос­новные данные: PSA, ODS-объект и инфо-куб.
Основными элементами в информационной модели являются:
Источник данных: данные переносятся в SAP BW в плоской, а не в многомерной структуре данных. Источ­ники данных содержат определения исходных данных.
Persistent Staging Area (PSA): в информационной модели SAP BW данные физически хранятся в PSA-объекте, прозрачной таблице базы данных. PSA – это пер­вичная область хранения данных, где запрошенные дан­ные сохраняются неизмененными из исходной системы в соответствии со структурой, определенной в источни­ке данных.
Инфо-источник: инфо-объекты, которые логически объединены друг с другом с точки зрения бизнеса, груп­пируются в инфо-источники. Инфо-источники (и входя­щие в них инфо-объекты) могут заполняться любыми дан­ными в пределах предприятия или данными из внешних источников. Они могут содержать как переменные, так и как основные данные. Переменные данные генерируются из операций в системе OLTP, например, в системе R/3 они количественные и могут быть гранулярными.
Объект операционного хранения данных (ODS-объект): SAP BW использует технологию ODS-объектов для построения уровня хранилища операционных данных (ODS). ODS-объект содержит консолидированный набор данных из одного или нескольких инфо-источников. В противоположность многомерным моделям данных (инфо-кубы) данные в ODS-объектах хранятся в плоских прозрачных таблицах базы данных. Данные ODS-объекта можно загружать в инфо-кубы или другие ODS-объекты при помощи дельта-обновления. Данные в ODS-объекте можно анализировать при помощи инструмента SAP BW Business Explorer (BEx), набора бизнес-информации в рамках mySAP BI.
Инфо-куб: контейнер, который организует данные на основе многомерной модели в плане бизнес-измерений. Это означает, что пользователи имеют возможность анали­зировать информацию с разных точек зрения, таких как географический регион или вид канала сбыта. SAP BW Business Explorer осуществляет доступ к инфо-кубу с це­лью построения отчетов, a OLAP – для выполнения анали­за.
Возможны и другие комбинации элементов. Например, данные можно загружать непосредственно в инфо-куб, или несколько источников данных могут быть присвоены одному инфо-источнику.
Источник данных присваивается инфо-источнику через правила переноса в SAP BW. Правила переноса отображают поля источника данных в инфо-объектах, которые составля­ют инфо-источник. На этом этапе можно применять обшир­ную библиотеку функций преобразования, представляющих бизнес-логику. Правила обновления SAP BW обрабатывают последующий поток данных из инфо-источников в ODS-объекты и инфо-кубы.
Во многих случаях данные, которые хранятся в PSA (и опи­саны в источнике данных), обладают неполным набором метаданных. Метаданные добавляются во время создания инфо-объектов и объединения инфо-объектов при форми­ровании инфо-источника. Именно во время процесса пере­мещения из источника данных в инфо-источник данные преобразуются в информацию. Информационная модель SAP BW может быть представлена в виде “завода по очистке данных”, на котором данные обогащаются, приобретая больше бизнес-стоимости по мере того, как они поступают в репозитарий.
2.4 Экстракция, преобразование, загрузка (ETL)
2.4.1 Основные сведения
Во многих компаниях данные фрагментарны и разбросаны по десяткам, если не сотням, баз данных и приложений. Сотрудникам, ответственным за принятие решений, необхо­дима точная и полная информация для разработки всесто­ронней информационной картины компании и ответа на основные бизнес-вопросы. Чтобы быть действительно полезными, данные должны быть интегрированы, стандар­тизированы, синхронизированы и агрегированы. Это осуще­ствляется через процесс, известный как экстракция, преоб­разование и загрузка (ETL).
ETL является жизненно важной и, возможно, наиболее про­блематичной частью хранения данных, а значит таковой она является и для всего проекта управления бизнес-информа­цией. Надо определять правильные источники данных, оце­нивать значимость и достоверность этих данных и отслежи­вать потоки данных. Необходимо удостовериться, что про­цесс ETL охватывает и загружает весь диапазон требуемых данных, одновременно избегая перегрузки за счет “лишних” данных. Данные необходимо собрать и очистить, чтобы уда­лить дубликаты и неправильные значения. И их необходимо обогатить (агрегировать), чтобы преобразовать в удобную для практического применения информацию.
Экстракцию данных можно выполнять на двух уровнях: на уровне приложения и на уровне базы данных или файла (“техническом уровне”). На уровне приложения экстракция данных выполняется в виде бизнес-объектов.
Так как он быстрее и проще, то этот метод наиболее предпочтительный, особенно когда в экстракции участвует много приложений и требуется длительный период времени для реализации данной задачи. Например, такой бизнес-объект, как “заказ клиента”, может быть представлен несколькими основными таблицами СУБД. Отношение между таблицами определяет­ся логикой приложения. Экстракция на уровне базы данных или файла означает, что полный набор данных и соответст­вующие метаданные берутся непосредственно их этих раз­ных таблиц, а это трудная задача, занимающая много време­ни и требующая высокой квалификации[7].
Однако есть ситуации, при которых требуется экстракция на уровне базы данных или файла:
– данные хранятся в файлах (плоских файлах);
– данные отправляются через XML;
– данные существуют в базах данных, которые находятся. под прежними или специальными приложениями;
– структуры таблицы прозрачны;
– экстракция на уровне приложения невозможна.
2.4.2 Экстракция, преобразование и загрузка (ETL) в SAP BW
SAP BW предоставляет пользователям широкий набор возможностей ETL, который поддерживает экстракцию данных на уровнях приложения и файла. Он также предла­гает открытые интерфейсы для внешних инструментов ETL, которые обеспечивают дополнительные возможности. Дан­ные могут загружаться практически из любого источника (рисунок 5).
На рисунке 5 данные становятся доступными в SAP BW в соответствии с определениями исходных данных в каждом источнике данных. Фактические данные из разных источни­ков физически хранятся в объекте Persistent Staging Area (PSA), прозрачной таблице базы данных. PSA – это первич­ная область хранения в информационной модели SAP BW, в которой содержаться данные, запрошенные в неизменном виде из исходной системы. PSA создается для каждого источника данных и исходной системы[3].
Данные перемещаются из источника данных в инфо-источник (рисунок 4). В инфо-источнике содержатся данные, которые связаны друг с другом с точки зрения бизнеса.
Когда данные перемещаются из источника данных в инфо-источник, они очищаются и преобразовываются при помо­щи правил переноса. SAP BW предлагает богатую библиоте­ку правил переноса, которые прилагают бизнес-логику к данным через такие действия, как преобразование даты и времени, строковые операции и агрегация. Эти правила можно легко применять при помощи формул, что означает, что необходимость в кодировании отсутствует.
Для поддержки мэппинга (мэппинг – процесс установления взаимно однозначного соответствия между объектами) в SAP BW отдельные поля источника данных присваиваются соответствующим инфо-объектам, которые составляют инфо-источник. Также в процессе мэппинга точно опреде­ляется, какие данные будут переноситься в инфо-источник из источника данных.
В SAP BW данные переносятся в инфо-пакетах. Инфо-пакет определяет, какие данные, содержащиеся в источнике дан­ных, должны запрашиваться из исходной системы. Инфо-пакет может запрашивать как переменные, так и основные данные при помощи точных параметров, например, только контроллинговая единица 0001 за октябрь 2001 года. Это означает, что инфо-пакеты могут описывать целевые поднаборы данных, содержащиеся в источнике данных. С помо­щью инструментальных средств администратора SAP BW можно планировать и отслеживать перенос инфо-пакетов.

Рисунок 5 – Экстракция, преобразование и загрузка (ETL) в SAP BW
2.5 Хранилище операционных данных (ODS)
Хранилище данных (рисунок 6) является относительно статичным. Оно спроектировано для оптимизации запросов на крупные объемы исторических и агрегированных дан­ных, для поддержания в основном стратегического, а не оперативного процесса принятия решений.
Хранилище операционных данных, с другой стороны, спро­ектировано для поддержки большого количества запросов на небольшие объемы данных, которые часто обновляются. Оно хранит подробные данные и поддерживает процесс ежедневного принятия решений на тактическом уровне. Точные определения хранилища операционных данных бы­вают разными, но SAP рассматривает его как информацион­ную среду “почти” реального времени, которая поддер­живает оперативную отчетность, взаимодействуя с сущест­вующими операционными системами, хранилищами данных или аналитическими приложениями.

Рисунок 6 – Хранилище данных SAP BW
Хранилище операционных данных играет важную роль, потому что основные области бизнеса во многом зависят от точных и своевременных данных. Оперативной информа­цией должны регулярно пользоваться поставщики и партне­ры, а прямой доступ к нужным данным играет критическую роль в обслуживании клиентов. Хранилище операционных данных помогает использовать данные предприятия для тактических операций, делает их доступными для основных сотрудников и помогает в привлечении большого количест­ва пользователей в этих областях.
SAP BW предоставляет гибкий доступ к данным в хранилище данных (рисунок 6), хранилище операци­онных данных и многомерных моделях. Данные можно за­гружать из Persistent Staging Area непосредственно в храни­лище операционных данных и хранилище данных. Их также можно загружать непосредственно в многомерные инфо-кубы, если нет необходимости в очистке, преобразовании или консолидации данных, т.е. когда исходная система обеспе­чивает необходимый уровень качества данных.
В SAP BW ODS-объекты и связанные с ними правила обнов­ления, которые обрабатывают поток данных между объек­тами, создают хранилище операционных данных. Хранили­ще операционных данных может состоять из нескольких уровней ODS-объектов, разрешая дальнейшую консолида­цию данных. Например, ODS-объект, который содержит данные об “объеме отгрузки” можно объединить с ODS-объектом, который описывает “входящие заказы” для созда­ния консолидированного объекта “заказов и фактических данных” для продукта. Равно тому, как можно создавать уровни ODS-объектов, можно взвешивать преимущество анализа консолидированных данных относительно расту­щих затрат на хранение, необходимых для создания дополнительных объектов[5].
2.6 Многомерные модели и агрегаты
Многомерные модели предоставляют ракурсы данных, необходимые для выполнения анализа, которые отражают одновременно несколько измерений данных, такие как вре­мя, место и продукт (рисунок 7). При помощи многомерного анализа (OLAP) можно отвечать на такие сложные вопросы бизнеса, как “Какова наша выручка по регионам и офисам в пределах каждого региона, год нарастающим итогом и насколько она отличается от того же периода в прошлом году?” или “Какие продукты в пределах подразделения “А” вместе составляют 80% общей прибыли этого подразделения на основании сбыта и связанных прямых и косвенных затрат за последние три года?” Компонент OLAP SAP BW выполня­ет запросы, которые сформулированы на основании бизнес-требований.
В SAP BW многомерные модели – это инфо-кубы. Инфо-куб содержит два типа данных, которые используются для анализа:
– показатели, такие как выручка, постоянные затраты, объем сбыта или количество сотрудников;
– признаки, такие как продукт, тип клиента, финансовый год, период или регион. Признаки используются для соз­дания групп оценки для анализа;
Основные инфо-объекты, которые составляют инфо-куб, распределяются по категориям относительно этих двух типов данных. То есть данный инфо-объект представляет собой либо показатель, либо признак. Третий тип инфо-объектов – атрибуты – содержит метаданные, описывающие другие инфо-объекты.
Эти два типа несущих данных инфо-объектов объединяются для выполнения анализа многомерных объектов. На приве­денном выше рисунке показатели представлены в выручке для таких продуктов, как стекло и керамика. Признаки (или группы оценки) представлены как регионы (Север, Юг и Восток) и группы клиентов (розничные, оптовые и супер­маркеты). Анализ при помощи этой модели может показать, например, “выручку за керамические изделия, проданные в магазинах в северном регионе”.

Рисунок 7 – Многомерная модель данных
Эти два типа несущих данных инфо-объектов объединяются для выполнения анализа многомерных объектов. На приве­денном выше рисунке показатели представлены в выручке для таких продуктов, как стекло и керамика. Признаки (или группы оценки) представлены как регионы (Север, Юг и Восток) и группы клиентов (розничные, оптовые и супер­маркеты). Анализ при помощи этой модели может показать, например, “выручку за керамические изделия, проданные в магазинах в северном регионе”.
Инфо-куб представлен в СУБД как набор реляционных таблиц, организованных в соответствии со схемой “звезда” – технологией, которая организует данные в соответствии с бизнес-измерениями (рисунок 8). В определении инфо-куба признаки суммируются в таблицы измерений. Схема “звезда” размещает несколько таблиц измерений вокруг цен­тральной таблицы фактов. Таблица фактов хранит показате­ли, в то время как окружающие таблицы измерения хранят признаки, необходимые для оценки и отчета по этим пока­зателям. Таблицы измерения не зависят друг от друга. Таб­лица фактов соединяет таблицы измерений и показатели[11].
2.7 Схема «Звезда»
SAP BW использует расширенную схему “звезда” (рисунок 8), которая строится на основной схеме, сохраняя основные данные об атрибутах, иерархиях и тексте в отдельных таблицах, которые используются разными инфо-кубами. Это сокраща­ет избыточность данных, потому что основные данные сохранятся только один раз, а затем используются разными инфо-кубами. Схема “звезда” также поддерживает подход к моделированию бизнеса mySAP BI двумя способами. Во-первых, можно легко строить иерархии для отражения бизнес-структуры. Во-вторых, изменения в данных обраба­тываются немедленно и последовательно. Еще одним преи­муществом расширенной схемы “звезда” является то, что изменения в инфо-кубе автоматически применяются к соот­ветствующим агрегатам (уплотнениям данных в схеме “звезда”, оптимизированным для быстрого доступа). Также известная как реорганизация данных, эта важная функция постоянно синхронизирует инфо-кубы и агрегаты, несмотря на постоянные изменения в бизнес-процессах.
Как и предварительно рассчитанные варианты данных, агрегаты сокращают время запроса, подготавливая ответы до того, как задаются вопросы. Агрегат хранит краткий вариант набора данных инфо-куба, т.е. он уплотняет исход­ную таблицу фактов инфо-куба. Эта сжатая таблица обеспе­чивает быстрый доступ к данным в инфо-кубе, что повыша­ет производительность запроса. Система поддерживает в агрегатах самую последнюю информацию. Когда изменяет­ся основной инфо-куб, связанный с ним агрегат автоматиче­ски модифицируется, чтобы отразить новые данные. В SAP BW система генерирует предложения для создания опти­мальных агрегатов, и системный администратор может после этого решить, создавать эти агрегаты или нет.
Инфо-кубы, хранящиеся в SAP BW, основаны на реляцион­ном хранении данных и могут использоваться для ROLAP-процессов (данные хранятся в таблицах, сгруппированных по схеме “звезда”). В этом случае для хранения используется Microsoft Analysis Services, и доступ к ним осуществляется процессо­ром OLAP SAP BW.
На выбор между двумя типами агрегатов – MOLAP и ROLAP – оказывают влияние несколько факторов: количество дан­ных в инфо-кубе, уровень детализации данных, спрос на подробный анализ и количество “стандартных” запросов. Всеобщей идеальной архитектуры OLAP, такой, которая предлагала бы наиболее эффективное решение для каж­дой организационной и функциональной потребности, не существует.

Рисунок 8 – Схема «Звезда»
Независимо от типа хранения, агрегаты обеспечивают повы­шение производительности. Благодаря гибкой архитектуре SAP BW можно внедрять модели данных, которые охватыва­ют все аналитические сценарии, независимо от основной базы данных SAP BW[4].
2.8 Общие сведения об аналитической отчетности
Согласно недавно проведенному опросу финансовых директоров, большинство из них (81%) считает, что сегодня наиболее важной задачей является достижение высокой точности прогнозирования доходов и поступлений. Примечательно, что при этом более половины из них (63%) не удовлетворены качеством своих систем бюджетирования и прогнозирования. Чем объясняются подобные пессимистичные настроения работников финансовой сферы? Дело в том, что сегодня финансовые директора оказываются под постоянно растущим “давлением” – новые реалии бизнеса требуют более надежной, значимой и точной финансовой информации:
– технологии Internet создают новые бизнес-модели, для которых необходимы новые финансовые модели;
– изменение бизнес-среды вызвало обострение конкурентной борьбы, когда неоспоримым преимуществом можно считать возможность проведения динамического анализа конкурентной среды;
– последние бухгалтерские скандалы и реакция надзорных органов повысили требования к целостности и точности данных;
При этом, как выяснилось в результате еще одного опроса, две трети “мировых” и 90% “средних” компаний не уверены в точности и надежности своих прогнозов и отчетов. Возникает вопрос: почему? В качестве ответа необходимо рассмотреть два момента:
– несовместимость многочисленных ERP-систем, используемых для сбора данных для бюджетирования, прогнозирования и отчетности, является основной причиной неточности данных;
– электронные таблицы по-прежнему широко используются в финансовых отделах при проведении бюджетирования, прогнозирования и подготовке отчетности.
Все больше и больше исследований свидетельствуют о наличие проблем, связанные с использованием электронных таблиц. Другими словами, электронные системы, вероятно, далеко не самая лучшая система для финансовых отделов. И хотя удовлетворительной альтернативы электронным таблицам пока не создано, изучения опыта применения электронных таблиц в целом не представляет большую практическую ценность для финансовой сферы. Тем не менее, открытым остается вопрос: “Могут ли другие технологии заменить электронные таблицы, используемые в финансовом отделе?”. Ответ на этот вопрос довольно прост: потому что их можно использовать. Несмотря на то, что финансовые специалисты практически не обладают знаниями в области разработки компьютерных программ, программирования или проектирования приложений, они могут разрабатывать сложные модели, которые можно применять для управления финансовой деятельностью. Кроме того, электронные таблицы широко используются в компаниях, а большинство пользователей, работающих с информацией, умеет доступ к электронным таблицам и знает, как ими пользоваться[6].
2.9 Технология OLAP
Термин OLAP (On-Line Analytical Processing), или оперативная аналитическая обработка, был веден в 1993г. Эдгаром Коддом (Edgar Codd), автором реляционной модели. Первоначально OLAP использовался как профессиональный термин, обозначающий принципиальное отличие от OLTP (On-Line Transaction Processing, Оперативная обработка транзакций). Буква T была заменена на A, что подчеркивало аналитические возможности OLAP в отличие от транзакционных характеристик технологии реляционных баз данных. Сегодня термин OLAP используется родовое понятие для различных технологий, включая системы поддержки принятия решений, Business Intelligence и управленческие информационные системы.
Основная функция OLAP – управление измерениями, которые применяются для моделирования основных характеристик бизнеса.
В отличие от традиционных реляционных СУБД, концепция OLAP не так широко известна, хотя загадочный термин “кубы OLAP” слышали, наверное, почти все. Что же такое On-Line Analytical Processing, где он обитает, и с чем его едят, мы и попытаемся разобраться.
OLAP – это не отдельно взятый программный продукт, не язык программирования и даже не конкретная технология. Если постараться охватить OLAP во всех его проявлениях, то это совокупность концепций, принципов и требований, лежащих в основе программных продуктов, облегчающих аналитикам доступ к данным. Несмотря на то, что с таким определением вряд ли кто-нибудь не согласится, сомнительно, чтобы оно хоть на йоту приблизило неспециалистов к пониманию нашего предмета. Поэтому в своем стремлении к познанию OLAP мы пойдем другим путем. Для начала мы выясним, зачем аналитикам надо как-то специально облегчать доступ к данным.
Дело в том, что аналитики – это особые потребители корпоративной информации. Задача аналитика – находить закономерности в больших массивах данных. Поэтому аналитик не будет обращать внимания на отдельно взятый факт, что в четверг четвертого числа контрагенту Чернову была продана партия черных чернил – ему нужна информация о сотнях и тысячах подобных событий. Одиночные факты в базе данных могут заинтересовать, к примеру, бухгалтера или начальника отдела продаж, в компетенции которого находится сделка. Аналитику одной записи мало – ему, к примеру, могут понадобиться все сделки данного филиала или представительства за месяц, год. Заодно аналитик отбрасывает ненужные ему подробности вроде ИНН покупателя, его точного адреса и номера телефона, индекса контракта и тому подобного. В то же время данные, которые требуются аналитику для работы, обязательно содержат числовые значения – это обусловлено самой сущностью его деятельности.
Итак, аналитику нужно много данных, эти данные являются выборочными, а также носят характер “набор атрибутов – число”. Последнее означает, что аналитик работает с таблицами следующего типа (Таблица 1):
Таблица 1 – Данные о товарах
Страна
Товар
Год
Объем продаж
Аргентина
Бытовая электроника
1988
105
Аргентина
Бытовая электроника
1989
117
Аргентина
Бытовая электроника
1990
122
Аргентина
Резиновые изделия
1988
212
Аргентина
Резиновые изделия
1989
217
Бразилия
Бытовая электроника
1990
919
Бразилия
Бытовая электроника
1988
342
Бразилия
Бытовая электроника
1989
337
Бразилия
Резиновые изделия
199
515
Бразилия
Резиновые изделия
1988
542
Бразилия
Резиновые изделия
1989
566
Венесуэлла
Бытовая электроника
1990
94
Венесуэлла
Бытовая электроника
1988
96
Венесуэлла
Бытовая электроника
1989
102
Венесуэлла
Резиновые изделия
1990
153
Венесуэлла
Резиновые изделия
1989
147
Венесуэлла
Резиновые изделия
1990
162

Здесь “Страна”, “Товар”, “Год” являются атрибутами, а “Объем продаж” – тем самым числовым значением. Задачей аналитика, повторимся, является выявление стойких взаимосвязей между атрибутами и числовыми параметрами. Посмотрев на таблицу 1, можно заметить, что ее легко можно перевести в три измерения: по одной из осей отложим страны, по другой – товары, по третьей – годы.
А значениями в этом трехмерном массиве (инфокубе) у нас будут соответствующие объемы продаж (рисунок 10).
Трехмерное представление таблицы. Серым сегментом показано, что для Аргентины в 1988 году данных нет.
Измерения OLAP-кубов состоят из так называемых меток или членов (members). Например, измерение “Страна” состоит из меток “Аргентина”, “Бразилия”, “Венесуэла” и так далее.
Должны быть заполнены далеко не все элементы куба: если нет информации о продажах резиновых изделий в Аргентине в 1988 году, значение в соответствующей ячейке просто не будет определено. Совершенно необязательно также, чтобы приложение OLAP хранило данные непременно в многомерной структуре – главное, чтобы для пользователя эти данные выглядели именно так. Кстати именно специальным способам компактного хранения многомерных данных, “вакуум” (незаполненные элементы) в кубах не приводят к бесполезной трате памяти.

Рисунок 10 – Инфокуб в системе OLAP
Однако куб сам по себе для анализа не пригоден. Если еще можно адекватно представить или изобразить трехмерный куб, то с шести- или девятнадцатимерным дело обстоит значительно хуже. Поэтому перед употреблением из многомерного куба извлекают обычные двумерные таблицы. Эта операция называется “разрезанием” куба. Термин этот, опять же, образный. Аналитик как бы берет и “разрезает” измерения куба по интересующим его меткам. Этим способом аналитик получает двумерный срез куба и с ним работает. Примерно так же лесорубы считают годовые кольца на спиле.
Соответственно, “неразрезанными”, как правило, остаются только два измерения – по числу измерений таблицы. Бывает, “неразрезанным” остается только измерение – если куб содержит несколько видов числовых значений, они могут откладываться по одному из измерений таблицы.
Если еще внимательнее всмотреться в таблицу, которую мы изобразили первой, можно заметить, что находящиеся в ней данные, скорее всего, не являются первичными, а получены в результате суммирования по более мелким элементам. Например, год делится на кварталы, кварталы на месяцы, месяцы на недели, недели на дни. Страна состоит из регионов, а регионы – из населенных пунктов. Наконец в самих городах можно выделить районы и конкретные торговые точки. Товары можно объединять в товарные группы и так далее. В терминах OLAP такие многоуровневые объединения совершенно логично называется иерархиями. Средства OLAP дают возможность в любой момент перейти на нужный уровень иерархии. Причем, как правило, для одних и тех же элементов поддерживается несколько видов иерархий: например день-неделя-месяц или день-декада-квартал. Исходные данные берутся из нижних уровней иерархий, а затем суммируются для получения значений более высоких уровней. Для того чтобы ускорить процесс перехода, просуммированные значения для разных уровней хранятся в кубе. Таким образом, то, что со стороны пользователя выглядит одним кубом, грубо говоря, состоит из множества более примитивных кубов.
Технология многомерных отчетов OLAP предполагает 12 принципов:
– Концептуальное многомерное представление
– Прозрачность
– Доступность
– Постоянная производительность при разработке отчетов
– Клиент-серверная архитектура
– Общая многомерность
– Динамическое управление разреженными матрицами
– Многопользовательская поддержка
– Неограниченные перекрестные операции
– Интуитивная манипуляция данными
– Гибкие возможности получения отчетов
– Неограниченная размерность и число уровней агрегации
Большинство современных разработчиков многомерных OLAP-отчетов придерживаются этих принципов или стараются их придерживаться.
Помимо OLAP употребляются и другие аббревиатуры:
MOLAP – cобственно многомерная (multidimensional) OLAP. В основе продукта лежит нереляционная структура данных, обеспечивающая многомерное хранение, обработку и представление данных. Соответственно и базы данных называют многомерными. Продукты, относящиеся к этому классу, обычно имеют сервер многомерных баз данных. Данные в процессе анализа выбираются исключительно из многомерной структуры. Подобная структура является высокопроизводительной.
ROLAP – реляционная (relational) OLAP. Как и подразумевается названием, многомерная структура в таких инструментах реализуется реляционными таблицами. А данные в процессе анализа, соответственно, выбираются из реляционной базы данных аналитическим инструментом.
HOLAP – гибридная (hybrid) оперативная аналитическая обработка. Инструменты этого класса позволяют сочетать оба подхода – реляционного и многомерного. Доступ может вестись как к данным многомерных баз, так и к данным реляционных.
DOLAP – “настольный” (desktop) OLAP. Речь идет о такой аналитической обработке, где гиперкубы малы, размерность их небольшая, потребности скромны, и для такой аналитической обработки достаточно персональной машины на рабочем столе[4].
2.10 Язык программирования ABAP/4
Название языка ABAP (Advanced Business Application Programming) дословно переводится как «современное программирование бизнес приложений». Язык был создан в 1980, для работы с системой SAP R/2, позднее перешёл в обновленную систему SAP R/3.
Язык реализует работу с внутренними структурами данных, интерфейсом пользователя R/3 транзакции и отчётами, работу с интерфейсами загрузки и выгрузки данных. В настоящее время активно развивается в сторону архитектуры ООП, в частности внутренние компоненты системы – BAPI,BADI. Без среды R/3 не существует (рисунок 11).
В настоящее время является полностью объектно-ориентированным, а также имеет собственный GUI (Graphic User Interface) – графический интерфейс пользователя, интегрированный в среду разработки. Синтаксис языка схож с синтаксисом языка программирования Cobol.

Рисунок 11 – Среда разработки в системе SAP R/3
3 РАЗРАБОТКА ТЕХНОЛОГИЧЕСКОГО ПРОЦЕССА ПО ОГАНИЗАЦИИ ОБРАБОТКИ ИНФОРМАЦИИ ДЛЯ СОСТАВЛЕНИЯ АНАЛИТИЧЕСКИХ ОБЗОРОВ БИЗНЕС-ПРОЦЕССОВ
3.1 Постановка задачи
3.1.1 Характеристика предприятия
1963г. совет Народного Хозяйства БССР выдал задание на проектирование нефтеперерабатывающего завода как одного из объектов Мозырского промышленного узла, а в начале 1966г. Было принято решение о его первоочередном строительстве.
В 1970г. были организованы ведущие отделы, которые возглавили опытные производственники, начато строительство пожарного депо, главной проходной, склада РМЦ базы оборудования. С апреля следующего года, после сдачи в эксплуатацию линии электропередачи и трансформаторной подстанции, строительство МНПЗ развернулось в полную мощь.
30 января 1975г. предприятие выдало первый полесский бензин.
Осенью 1976г. директором завода был назначен В.П.Пушкарев, работавший ранее главным инженером Киришского НПЗ.
Производимые заводом нефтепродукты не раз демонстрировались на выставках достижений народного хозяйства и получали дипломы.
В феврале 1994 года решением исполкома Мозырского городского совета народных депутатов было зарегистрировано «ОАО Мозырский нефтеперерабатывающий завод».
В 1997г. стал годом, в котором проводимая на заводе продукция дала ощутимые результаты. Был получен высокооктановый бензин АИ-95.
За прошедший двадцатипятилетний период последние пять лет были наиболее трудными. Это было время выживания коллектива в жестких экономических условий, время оптимальных решений и путей выхода из тупика. И этот путь был найден.
Полный планов и надежд, вступил в третье тысячелетие сплоченный коллектив «ОАО Мозырский нефтеперерабатывающий завод». Для осуществления планов здесь имеется все необходимое – четкая организация труда, накопленный опыт, желание добиться наилучших результатов.
3.1.2 Формулировка требований к разрабатываемому процессу
Целью данного дипломного проекта является разработка технологического процесса по организации обработки информации для составления аналитических обзоров бизнес-процессов на базе системы SAP BW. Процесс разрабатывался для «ОАО Мозырский нефтеперерабатывающий завод».
Разработка технологического процесса подразумевает разработку специфики переноса данных из ERP-системы SAP R/3 в информационное хранилище данных SAP BW. Подготовка переносимой информации, настройка правил обновления, а также создание инфо-пакетов загрузки осуществляется стандартными средствами SAP. Выборка данных, ее правила и параметры реализованы в посредством ETL-процесса. ETL-процесс, отвечающий за правильность выборки данных, а также достоверность, был разработан при помощи языка программирования на ABAP/4.
Предпосылкой разработки технологического процесса по организации обработки информации для составления аналитических обзоров бизнес-процессов на базе системы SAP BW являлось постоянно растущий объем данных, загружаемых в хранилище данных. Проблемой являлось то, что загружаемые данные очень часто повторялись. В разработанном ETL-процессе существует возможность быстрого вызова уже загруженных ранее данных. Как известно – основной функцией информационного хранилища данных SAP BW является обработка и анализ загруженных данных. Разработанный процесс способствует уменьшению загрузки повторяющихся данных, а следовательно и способствуем увеличению быстродействия всего комплекса в целом.
Отметим основные части технологического процесса по составлению обзоров бизнес-процессов:
– активация стандартных инфо-объектов SAP BW;
– создание источников данных;
– активация источников данных;
– копирование глобальных параметров из SAP R/3 в SAP BW;
– разработка ETL-процесса;
– создание инфо-источников;
– настройка правил переноса;
– настройка правил обновления;
– настройка правил загрузки.
Принимая во внимание то, что количество переносимой между программными комплексами информации может исчисляться сотнями гигабайт следует сделать особый упор на оптимизацию алгоритмов выборки, группировки и переноса данных.
Методы переноса, выборки и группировки анализируемых данных должны строго соответствовать правилам, принятыми разработчиками SAP.
Как было сказано выше, загрузка информации из ERP системы SAP R/3 в хранилище данных SAP BW осуществляется посредством ETL-процессов.
Приложения ETL извлекают информацию из исходной базы данных, преобразуют ее в формат, поддерживаемый базой данных назначения, а затем загружают в нее преобразованную информацию. Для того чтобы инициировать процесс ETL, применяются программы извлечения данных для чтения записей в исходной базе данных и для подготовки информации, хранящейся в этих записях, к процессу преобразования. Чтобы извлечь данные из исходной базы данных, можно выбрать один из трех вариантов – создать собственные программы, обратиться к готовому специализированному инструментарию ETL или использовать сочетание и того и другого.
Процесс организации обработки информации для составления аналитических обзоров бизнес-процессов был разработан на основе третьего способа разработки ELT-процесса. Настройка загрузки осуществлялась посредством стандартных функций хранилища данных SAP BW, а параметры и специфические особенности загрузки осуществлялись посредством программы, написанной на языке ABAP/4.
3.2 Активация стандартных инфо-объектов SAP BW
Некоторые инфо-объекты, необходимые для решения конкретных бизнес задач, заранее разработаны и внесены в систему SAP BW. Для того, что бы ими можно было воспользоваться их необходимо активировать из бизнес-содержимого.
Выполняется транзакция RSA1. В появившемся окне выбирается раздел «Бизнес-содержимое», а далее вносятся необходимые инфо-провайдеры (рисунок 12). Необходимо перенести следующие инфо-провайдеры:
1. Контроллинг (0CO);
2. Финансовая бухгалтерия (0FI);
3. Управление бюджетом (0FIFM).
Также необходимо перенести приложения инфо-источников:
4. Финансы (FI)
5. Контроллинг (CO).

Рисунок 12 – Активация стандартных инфо-объектов SAP BW
При активации стандартных инфо-объектов необходимо выбрать группировку «Поток данных до и после». Это сделано для того, чтобы исключить повторяющиеся данные, а так же свести к минимуму вероятность потери информации (рисунок 12).
3.3 Создание ракурсов исходных баз данных
Ракурсом базы данных является тип и характер ее использования. Любая база данных может иметь несколько ракурсов. Создание ракурса базы данных является одним из этапов загрузки данных в информационное хранилище. Создание ракурсов является очень важным и трудоемким процессом на стадии разработки специфики переноса данных из ERP-системы SAP R/3, так как они являются шаблонами для загружаемых данных.
Создание нового ракурса осуществляется при помощи системы SAP R/3 посредством вызова транзакции SE11 (рисунок 13).

Рисунок 13 – Создание ракурсов ZMZTARNGM_TEXT
Новый ракурс создается путем ввода нового имени в поле «Ракурс» и нажатием кнопки «Создать». Далее указываются необходимые таблицы и условия их соединения. В данном случае был создан ракурс «ZMZTARNGM_TEXT» – ракурс текстов мероприятий.

Рисунок 14 – Изменение настроек ракурса ZMZTARNGM_TEXT
При нажатии кнопки «Изменить» открывается окно настроек созданного ракурса (рисунок 14). В появившемся диалоговом окне слева находится список доступных для соединения таблиц, а справа условия их соединения.
Далее составляется словарь ракурсов. Описываются типы и длина полей, вносятся краткие описания выбранных полей (рисунок 15).

Рисунок 15 – Создание словаря ракурса ZMZTARNGM_TEXT
Следующим этапом разработки технологического процесса является указание условий отбора данных их таблиц (рисунок 16), выбранных при создании ракурса.

Рисунок 16 – Условия отбора данных в ракурсе ZMZTARNGM_TEXT
Следует отметить, что условия, выбранные в данном ракурсе необходимо указать для всех таблиц, поступающих в данный ракурс. Это решает проблему повторяющихся данных.
В ходе разработки проекта было создано 4 основных ракурса.
3.3.1 Ракурс «Мероприятия. Тексты»
Ракурс содержит краткое описание предполагаемого мероприятия. Под мероприятием подразумевается какой-либо проект или задание.
Элементы ракурса:
1. PRPS – Элемент Структурного Плана (основные данные);
2. PROJ – Определение проекта.
Условия соединения:
1. PRPS-MANDT = PROJ-MANDT;
2. PROJ-PSPNR = PRPS-PSPHI.
Поля ракурса:
1. PRPS-MANDT – Мандант;
2. PROJ-PSPID – Определение проекта;
3. PRPS-PSPNR – СПП-элемент;
4. PRPS-POSID – Элемент структурного плана проекта;
5. PRPS-POST1 – Краткое описание (первая строка текста).
Условие выбора:
1. PRPS-STUFE=1.
Данное условие необходимо указать для всех последующих ракурсов, в которых присутствует таблица PRPS. Оно необходимо для того, чтобы ограничить выбираемые данные элемента структурного плана.
3.3.2 Ракурс «Мероприятия. Даты мероприятий»
Ракурс содержит данные о времени проведения и сроках проекта либо задания, номер руководителя проекта, а так же месторасположение.
Элементы ракурса:
1. PRPS – Элемент Структурного Плана (основные данные);
2. PROJ – Определение проекта.
Условия соединения:
3. PRPS-MANDT = PRTE-MANDT;
1. PRPS-MANDT = PROJ-MANDT;
2. PRTE-POSNR = PRPS-PSPNR;
3. PROJ-PSPNR = PRPS-PSPHI.
Поля ракурса:
1. PRPS – Мандант;
2. PROJ – Определение проекта;
3. PRPS – СПП-элемент;
4. PRPS – Элемент структурного плана проекта (СПП-элемент);
5. PRTE – Базисный срок начала СПП-элемента;
6. PRTE – Базисный срок конца СПП-элемента;
7. PRPS – Номер ответственного (руководителя проекта);
8. PRPS – Ответственный (руководитель проекта);
9. PRPS – Номер автора заявки;
10. PRPS – Автор заявки;
11. PRPS – Место возникновения прибыли;
12. PRPS – Запрашивающее МВЗ;
13. PRPS – Ответственное МВЗ;
14. PRPS – Завод;
15. PRPS – Местоположение.
Условие выбора:
16. PRPS MAND = PRTE MANDT;
17. PRPS MANDT = PROJ MANDT;
18. PRPS MANDT = T001 MANDT;
19. PRTE POSNR = PRPS PSPNR;
20. PROJ PSPNR = RPS PSPHI;
21. T001 BUKRS = PRPS PBUKR.
3.3.3 Ракурс «Факт исполнения БДДС»
Ракурс содержит данные о бюджете движения денежных средств на предприятии.
Элементы ракурса:
1. KBLK – Заголовок документа: Ввод документа вручную;
2. KBLP – Позиция документа: Ввод документа вручную.
Условия соединения:
1. KBLK-MANDT = KBLP-MANDT;
2. KBLK-BELNR = KBLP-BELNR.
Поля ракурса:
1. KBLK – Мандант;
2. KBLP – Номер документа для выделения финансовых средств;
3. KBLP – Позиция документа: выделение средств;
4. KBLP – Дата исполнения;
5. KBLP – Дата ввода;
6. KBLP – Индикатор исполнения для позиции документа;
7. KBLP – Плановый срок возникновения затрат;
8. KBLK – Дата документа;
9. KBLK – Дата проводки в документе;
10. KBLK – Контроллинговая единица;
11. KBLP – Финансовая позиция;
12. KBLP – Подразделение финансового менеджмента;
13. KBLK – Единица финансового менеджмента;
14. KBLP – СПП-элемент;
15. KBLP – Общая стоимость в валюте транзакции;
16. KBLP HWGES KBLHWG CURR – Общее значение во внутренней валюте;
17. KBLK WAERS TWAER CUKY – Валюта транзакции;
18. KBLK HWAER HSWAE CUKY – Код внутренней валюты.
3.3.4 Ракурс «Затраты на материалы»
Ракурс «Затраты на материалы» является наиболее значимым. Содержит данные об определении проекта, элементах структурного плана, операциях заказа, резервировании, данные календарного планирования позиций проекта, а также оценке материалов и балансовых единицах.
Элементы ракурса:
1. PROJ – Определение проекта;
2. PRPS – СПП-элемент;
3. AFVC – Операция заказа;
4. RESB – Резервирование/ВторичнПотребн;
5. PRTE – Данные КалендПланирования позиции проекта;
6. MBEW – Оценка материала;
7. T001 – Балансовые единицы.
Условия соединения:
1. PRPS-MANDT = PROJ-MANDT;
2. AFVC-MANDT = PROJ-MANDT;
3. RESB-MANDT = PROJ-MANDT;
4. PRTE-MANDT = PROJ-MANDT;
5. MBEW-MANDT = PROJ-MANDT;
6. T001-MANDT = PROJ-MANDT;
7. PRPS-PSPNR = RESB-PSPEL;
8. PROJ-PSPNR = PRPS-PSPHI;
9. AFVC-AUFPL = RESB-AUFPL;
10. AFVC-APLZL = RESB-APLZL;
11. PRTE-POSNR = RESB-PSPEL;
12. MBEW-MATNR = RESB-MATNR;
13. MBEW-BWKEY = RESB-WERKS;
14. MBEW-BWTAR = RESB-CHARG;
15. T001-BUKRS = AFVC-BUKRS.
Поля ракурса:
1. PRPS – Мандант;
2. PRPS – СПП-элемент;
3. RESB – Номер резервирования/вторичной потребности;
4. RESB – Номер позиции резервирования/вторичной потребности;
5. RESB – Вид записи;
6. PROJ – Определение проекта (внутр.);
7. PROJ – Определение проекта;
8. PRPS – Элемент структурного плана проекта (СПП-элемент);
9. RESB – Номер материала;
10. RESB – Объем потребности;
11. RESB – Базисная единица измерения;
12. AFVC – Запрашивающее МВЗ;
13. AFVC – Вид затрат;
14. PRTE – Базисный срок начала СПП-элемента;
15. PRTE – Базисный срок конца СПП-элемента;
16. PRPS КЕ – СПП-элемент;
17. PRPS – Номер ответственного (руководителя проекта);
18. PRPS – Ответственный (руководитель проекта);
19. MBEW – Стандартная цена;
20. MBEW – Средняя скользящая/периодическая учетная цена;
21. MBEW – Код управления ценой;
22. T001 – Код валюты;
23. PRPS – Индикатор элемента планирования;
24. PRPS – Индикатор: элемент контировки;
25. PRPS – Индикатор: элемент фактурирования.
3.4 Создание источников данных
Для того чтобы поместить информацию из баз данных SAP R/3 в хранилище данных SAP BW необходимо создать родовые источники данных (рисунок 17). При создании нового источника данных указывается его имя, необходимые атрибуты, прикладной компонент, описания, а также ракурсы (шаблоны).

Рисунок 17 – Создание родового источника данных
После создания родового источника данных изменяем основные параметры нажатием кнопки «Изменить». Для источников данных следует указать ракурс, техническое имя которого совпадает с техническим именем создаваемого источника данных (рисунок 18).
Наиболее важным параметром является выбор прикладного компонента – источника данных для SAP BW. В данном случае таковым являются базы данных SAP R/3. Также вносятся краткие описания, а также ракурс для экстракции данных.
При загрузке большого количества данных возникает проблема избытка информации. В данном случае возможно введение ограничения на загружаемые поля посредством стандартных функций и настроек SAP BW (рисунок 19).
При этом отмечаются только те поля, по которым необходимо будет ограничивать загрузку данных. Это является заключительной стадией создания источников данных. Следует отметить, что этап создания источников данных является наиболее важным в проектировании новых хранилищ данных в системе SAP BW.

Рисунок 18 – Изменение параметров источника данных

Рисунок 19 – Выбор ограничений на загрузку данных
Необходимо создать следующие источники данных:
1. «Мероприятия. Тексты» (ZMZTARNGM_TEXT) – тексты;
2. «Мероприятия. Даты мероприятий» (ZMZTARNGM_ATTR) – переменные данные;
3. «Мероприятия. Индикаторы» (ZMZTARNGM_INDIC) – переменные данные;
4. «Факт исполнения БДДС» (Z_FI_FACT) – переменные данные.
Активация источников данных в системе SAP R/3 осуществляется при помощи запуска транзакции RSA5. Далее выбирается требуемый источник данных и нажимается кнопка «Скопировать источник данных». После нажатия кнопки произойдет активация источника данных в системе R/3 (рисунок 20).

Рисунок 20 – Создание источников данных в системе SAP R/3
Необходимо активировать следующие источники данных:
1. 0CMMT_ITEM_TEXT – Финансовая позиция;
2. 0FM_AREA_TEXT – Единица финансового менеджмента;
3. 0BUD_VERSN_TEXT – Версия бюджета;
4. 0MATERIAL_TEXT – Материал;
5. 0COSTELMNT_TEXT – Вид затрат;
6. 0CO_AREA_TEXT – Контроллинговая единица;
7. 0MATL_GROUP_TEXT – Группа материалов;
8. 0FUNDS_CTR_TEXT – Подразделение финансового менеджмента;
9. 0PS_RESPNO_TEXT – Ответственный исполнитель;
10. 0COSTCENTER_TEXT – Место возникновения затрат.
3.5 Работа с данными на стадии загрузки
3.5.1 Копирование глобальных переменных из SAP R/3 в SAP BW
Любой источник данных обладает определенными уникальными параметрами. Важным аспектом при переносе данных из одного хранилища в другое является копирование глобальных параметров. Таковыми могут служить:
– валюта;
– единицы измерения;
– варианты финансового года;
– производственный календарь и д.р.
Копирование глобальных параметров осуществляется посредством запуска транзакции RSA1. Далее осуществляется переход в закладку «Исходные системы». Выбирается исходная система, в данном случае это система R3T01_101 – продуктивная система SAP R/3 (рисунок 21). По нажатию на выбранную систему правой кнопкой мыши на всплывающем окне необходимо выбрать «Скопировать глобальные переменные». В появившемся диалоговом окне следует выбрать копируемые параметры и нажатием клавиши «F8» подтвердить выбор копируемых переменных.

Рисунок 21 – Выбор системы для копирования глобальных переменных
Результатом всех вышеперечисленных операций является подготовка данных для загрузки в PSA. Напомним, что PSA – это пер­вичная область хранения данных SAP BW. Здесь загруженные дан­ные сохраняются неизмененными. В данном случае источником данных является система SAP R/3. Однако источником данных может являться как стороння СУБД, так и плоский файл, либо XML-документ.
3.5.1 Тиражирование источников данных
В связи с риском потери данных в информационное хранилище данных SAP BW в системы SAP R/3 существует возможность тиражирования данных на стадии загрузки.
Для этого необходимо запустить транзакцию RSA1 в системе SAP R/3, затем запустить эту же транзакцию в системе SAP BW. Перейти на закладку «Исходные системы». Нажать правой кнопкой на иконке, обозначающей систему R/3 и выбрать «Тиражировать источники данных» (рисунок 22).

Рисунок 22 – Тиражирование данных в SAP BW
3.6 Создание инфо-источников
3.6.1 Загрузка данных из PSA
После загрузки информации в первичную область PSA, при помощи ETL-процесса, данные поступают в инфо-источники. Инфо-объекты, которые логически объединены друг с другом с точки зрения бизнеса, груп­пируются в инфо-источники. Инфо-источники (и входя­щие в них инфо-объекты) могут заполняться любыми дан­ными в пределах предприятия или данными из внешних источников.
Загрузка данных из PSA в инфо-источники осуществляется посредством прикрепления стандартного компонента ZMZA_PSLOAD (рисунок 23).

Рисунок 23 – Загрузка данных из PSA
В закладке «Инфо-источники» выбираем нужный нам источник, нажимаем правой кнопкой мыши, в всплывающем окне выбираем «Изменить» (рисунок 24).
Диалоговом окне на рисунке 18 возможно изменение свойств выбранного инфо-источника. Основными свойствами являются:
– типы полей;
– длина полей;
– единица измерения;

Рисунок 24 – Настройка инфо-источника
Также возможна замена источника поля. Пользователь может самостоятельно указывать путь к конкретно выбранному полю (путь к источнику данных).
3.6.1 Создание инфо-источника «Даты мероприятий»
Инфо-источник создается в прикладном компоненте «Загрузка данных из PSА» (ZMZA_PSLOAD).
Инфо-источник содержит следующие признаки:
1. ZMZTARNGM – Мероприятие;
2. 0FM_AREA – Единица ФМ;
3. 0BUD_VERSN – Версия бюджета;
4. 0CO_AREA – Контроллинговая единица;
5. ZMZTKFTP – Вид коэффициента;
6. 0CALYEAR – Календарный год;
7. ZMZTSARNG – Срок начала мероприятия;
8. ZMZTEARNG – Срок завершения мероприятия;
9. YMZK_AMNT – Сумма затрат (ввод);
10. ZMZTRSPNS – Ответственный исполнитель.
3.6.2 Создание инфо-источника «Индикаторы мероприятий»
Инфо-источник создается в прикладном компоненте «Загрузка данных из PS» (ZMZA_PSLOAD).
Инфо-источник содержит следующие признаки:
1. ZMZTARNGM – Мероприятие;
2. 0FM_AREA – Единица ФМ;
3. 0BUD_VERSN – Версия бюджета;
4. 0CO_AREA – Контроллинговая единича;
5. ZMZTKFTP – Вид коэффициента;
6. 0CALYEAR – Календарный год;
7. YMZKCRATE – Курс валюты;
8. ZMZTRSPNS – Ответственный исполнитель.
3.6.3 Создание инфо-источника «Оценка материалов в мероприятиях»
Инфо-источник создается в прикладном компоненте «Загрузка данных из PS» (ZMZA_PSLOAD).
Инфо-источник содержит следующие признаки:
1. ZMZTARNGM – Мероприятие;
2. ZMZTGNPLN – Общезаводской план;
3. 0FM_AREA – Единица ФМ;
4. 0BUD_VERSN – Версия бюджета;
5. 0MATERIAL – Материал;
6. 0CO_AREA – Контроллинговая единица;
7. 0MATL_GROUP – Группа материалов;
8. ZMZFUNCT2 – ПФМ;
9. ZMZTKFTP – Вид коэффициента;
10. ZMZTRSPNS – Ответственный исполнитель;
11. ZMZT_RTYP – Тип ресурса;
12. ZMZT_MRKT – Рынок сбыта;
13. ZMZTRESME – Ответственный исполнитель мероприятия;
14. YMZBYRNDS – Сумма затрат в бел. руб.;
15. YMZINBUDG – Участвует в бюджете;
16. YMZKCOTR – Цена;
17. YMZK_AMNT – Сумма затрат (ввод);
18. YMZK_QMT – Треб. кол-во материала.
3.6.4 Создание инфо-источника «БДДС. Платежи. Факт и облиго»
Инфо-источник создается в прикладном компоненте «Загрузка данных из PS» (ZMZA_PSLOAD).
Инфо-источник содержит следующие признаки:
1. 0BUD_VERSN – Версия бюджета;
2. 0FM_AREA – Единица ФМ;
3. ZMZFUNCT2 – ПФМ;
4. 0CMMT_ITEM – ФП;
5. 0CO_AREA – Контроллинговая единица;
6. ZMZTKFTP – Вид коэффициента;
7. 0CALDAY – Календарный день;
8. ZMZSUMSM – Сумма затрат в валюте;
9. YMZKINBYB – Сумма эквивалента без НДС;
3.6.5 Создание инфо-источника «БДР. Факт и облиго»
Инфо-источник создается в прикладном компоненте «Загрузка данных из PS» (ZMZA_PSLOAD).
Инфо-источник должен содержать следующие признаки:
1. 0BUD_VERSN – Версия бюджета;
2. 0FM_AREA – Единица ФМ;
3. ZMZFUNCT2 – ПФМ;
4. 0CMMT_ITEM – ФП;
5. 0CO_AREA – Контроллинговая единица;
6. ZMZTKFTP – Вид коэффициента;
7. 0CALDAY – Календарный день;
8. ZMZSUMSM – Сумма затрат в валюте;
9. YMZKINBYB – Сумма эквивалента без НДС;
3.7 Присвоение исходных систем инфо-источникам
После завершения загрузки данных в инфо-источники им присваиваются исходные системы.
Присваивание исходных систем инфо-источникам осуществляется при помощи вызова транзакции RSA1 путем перехода на закладку «Инфо-источники». Далее выбирается нужный инфо-источник, из контекстного меню пункт меню «Присвоить источник данных». Выбрать систему R/3. Нажать «Сохранить» (рисунок 25).

Рисунок 25 – Присвоение исходных систем инфо-источникам
Присвоение необходимо выполнять с выбором источника данных для следующих инфо-источников (таблица 2).
Таблица 2 – Список присваиваемых атрибутов
Инфо-источник
Исходная системы
Источник данных
1
2
3
ZMZTKFTP Вид коэффициента
Файловая система
–
ZMZTARNGM Мероприятие
Файловая система
R/3
ZMZTARNGM_TEXT Мероприятия. Тексты
ZMZTARNGM_ATTR Мероприятия. Атрибуты
0MATERIAL_TEXT Материал (тексты)
R/3
0MATERIAL_TEXT Тест материала
0MATERIAL_ATTR Материал (атрибуты)
R/3
0MATERIAL_ATTR Материал
0MATL_GROUP_TEXT Группа материалов
R/3
0MATL_GROUP_TEXT Группа материалов
Продолжение таблицы
1
2
3
0FM_AREA Единица ФМ
R/3
0FM_AREA_TEXT Единица финансового менеджмента
0FUNDS_CTR Подразделение ФМ
R/3
0FUNDS_CTR_TEXT Подразделение финансового менеджмента
0CMMT_ITEM Финансовая позиция
R/3
0CMMT_ITEM_TEXT Финансовая позиция
0CMMT_ITEM_FMCI_HIER Финансовая позиция
0CO_AREA Контроллинговая единица
R/3
0CO_AREA_TEXT Контроллинговая единица
0COSTCENTER Место возникновения затрат
R/3
0COSTCENTER_TEXT Место возникновения затрат
0COSTELMNT Вид затрат
R/3
0COSTELMNT_TEXT Вид затрат
0COSTELMNT_0102_HIER Вид затрат
ZMZTGNPLN Общезаводской план
Файловая система

–
0BUD_VERSN Версия бюджета
Файловая система
R/3
0BUD_VERSN_TEXT Версия бюджета
ZMZT_ORG Организационная структура ССО
Файловая система
–
ZMZTORGAN Организация
Файловая система
R/3
0PS_RESPNO_TEXT Номер ответственного (руководителя проекта)
ZMZT_MRKT Рынок сбыта
–
Заносится вручную
ZMZTBU001 Строки БДР
Файловая система
–
ZMZTARNGM_DATES Даты мероприятий
R/3
ZMZTARNGM_DATES Атрибуты мероприятий
ZMZTARNGM_INDIC Индикаторы мероприятий
R/3
ZMZTARNGM_INDIC Мероприятия. Индикаторы
ZMZB_COMPMAT_COST Оценка материалов в мероприятиях
R/3
ZCOMPMAT_COST Затраты на материалы
ZMZB007 БДДС. Платежи. Факт и облиго
R/3
Z_FI_FACT БДДС-факт
Необходимо активировать каждое присвоение источника данных у каждого инфо-объекта.
3.8 Перенос инфо-источников
3.8.1 Перенос инфо-источников в ODS-объекты
ODS является хранилищем оперативных данных. Хранилище операционных данных, спро­ектировано для поддержки большого количества запросов на небольшие объемы данных, которые часто обновляются. Оно хранит подробные данные и поддерживает процесс ежедневного принятия решений на тактическом уровне.
Поступающие в ODS данные анализируются и распределяются между оперативным и статическим хранилищем данных.

Рисунок 26 – Изменение правил переноса инфо-источников
Нередко в систему переносятся лишние данные. Избыточная информация только замедляет работу системы. Зачастую информация требуется не в том виде, в каком она представлена в исходных базах данных. Например, для отчета требуется только конечная сумма по каким-то определенным показателям, а значения самих показателей никогда не бывает востребовано. Так на этом шаге загрузки информации данные группируются по заданным пользователем критериям, также возможно выполнение логических и арифметических операций.
Вся «не качественная» либо сомнительная информация, поступающая в ODS, отфильтровывается и перемещается в отдельную область. Более точная и проверенная информация пересылается в статические хранилища данных (рисунок 6()хранилище данных. татических мация хранится в статических выбираем “буется удаление конкретных анных один раз, а замет делать).
При помощи транзакции RSA1 осуществляем перенос данный из инфо-источников в ODS. Переходим в закладку «Инфо-источники» и выбираем нужный инфо-источник. Нажимаем правой кнопкой мыши и в появившемся диалоговом окне выбираем «Изменить правила переноса» (рисунок 26).
3.8.2 Настройка правила переноса инфо-источника «Оценка материалов в мероприятиях» (ZMZB_COMPMAT_COST) и источника данных «Затраты на материалы» (ZCOMPMAT_COST)
В приведенной ниже таблице 3 указаны правила переноса для инфо-источника «Оценка материалов в мероприятиях».
Таблица 3 – Правила переноса для инфо-источника «Оценка материалов в мероприятиях»
Признак
Значение (константа или поле из структуры переноса)
ZMZTARNGM – Мероприятие
POSID Элемент структурного плана проекта (СПП-элемент)
ZMZTGNPLN – Общезаводской план
#
ZMZFUNCT2 – ПФМ
#
0CMMT_ITEM – Финансовая позиция
#
0FM_AREA – Единица ФМ
MNPZ
0BUD_VERSN – Версия бюджета
0
0CO_AREA – Контроллинговая Единица
MNPZ
0MATERIAL – Материал
MATNR Номер материала
0MATL_GROUP – Группа материалов
#
ZMZTKFTP – Вид коэффициента
1
ZMZTRSPNS – Ответственный исполнитель
VERNR Номер ответственного (руководителя проекта)
ZMZTKFTP2 – Вид коэффициента 2
1
YMZINBUDG – Участвует в бюджете
1,00000
YMZKCOTR – Цена
STPRS Стандартная цена
YMZK_AMNT – Сумма затрат (ввод)
СтандартнЦена * ОбъемПотребн
YMZK_QMT – Треб. кол-во материала
BDMNG Объем потребности
0CALYEAR – Календарный год
2005

3.8.3 Настройка правила переноса инфо-источника «Даты мероприятий» (ZMZTARNGM_DATES) и источника данных «Атрибуты мероприятия» (ZMZTARNGM_DATES)
В приведенной ниже таблице 4 указаны правила переноса для инфо-источника «Даты мероприятий».
Таблица 4 – Правила переноса для инфо-источника «Даты мероприятий»
Признак
Значение (константа или поле из структуры переноса)
ZMZTARNGM – Мероприятие
POSID Элемент структурного плана проекта (СПП-элемент)
0FM_AREA – Единица ФМ
FIKRS Единица финансового менеджмента
0BUD_VERSN – Версия бюджета
0
0CO_AREA – Контроллинговая единица
PKOKR КЕ СПП-элемента
ZMZTKFTP – Вид коэффициента
51
0CALYEAR – Календарный год
2005
ZMZTSARNG – Срок начала мероприятия
PSTRT Базисный срок начала СПП-элемента
ZMZTEARNG – Срок завершения мероприятия
PENDE Базисный срок конца СПП-элемента
YMZK_AMNT – Сумма затрат (ввод)
0,01
ZMZTRSPNS – Ответственный исполнитель
VERNR Номер ответственного (руководителя проекта)
3.8.4 Настройка правила переноса инфо-источника «Индикаторы мероприятий» (ZMZTARNGM_INDIC) и источника данных «Мероприятия. Индикаторы» (ZMZTARNGM_INDIC)
В приведенной ниже таблице 5 указаны правила переноса для инфо-источника «Индикаторы мероприятий».
Таблица 5 – Правила переноса для инфо-источника «Индикаторы мероприятий»
Признак
Значение (константа или поле из структуры переноса)
1
2
ZMZTARNGM – Мероприятие
POSID Элемент структурного плана проекта (СПП-элемент)
0FM_AREA – Единица ФМ
FIKRS Единица финансового менеджмента
0BUD_VERSN – Версия бюджета
#
0CO_AREA – Контроллинговая единица
PKOKR КЕ СПП-элемента

Продолжение таблицы
1
2
ZMZTKFTP – Вид коэффициента
69
0CALYEAR – Календарный год
2005
YMZKCRATE – Курс валюты
1,00000
ZMZTRSPNS – Ответственный исполнитель
VERNR Номер ответственного (руководителя проекта)
3.8.5 Настройка правила переноса инфо-источника «БДДС. Платежи. Факт и облиго» (ZMZB007) и источника данных «БДДС. Факт» (Z_FI_FACT)
В приведенной ниже таблице 6 указаны правила переноса для инфо-источника «БДДС. Платежи. Факт и облиго».
Таблица 6 – Правила переноса для инфо-источника «БДДС. Платежи. Факт и облиго»
Признак
Значение (константа или поле из структуры переноса)
0BU D_VERSN – Версия бюджета
0
0FM_AREA – Единица ФМ
FIKRS Единица финансового менеджмента
ZMZFUNCT2 – ПФМ
FISTL Подразделение финансового менеджмента
0CMMT_ITEM – ФП
FIPOS Финансовая позиция
0CO_AREA – Контроллинговая единица
#
ZMZTKFTP – Вид коэффициента
67
0CALDAY – Календарный день
BUDAT Дата проводки в документе
3.9 Настройка правил обновления
Одной из завершающих стадий загрузки данных в информационное хранилище данных SAP BW из системы SAP R/3 является настройка правил обновления.
Правила обновления настраиваются в транзакции RSA1 на закладке «Инфо-провайдеры». Выбрать в контекстном меню пункт «Создать правила обновления». Далее указываются правила обновления (рисунок 28). После установки всех необходимых параметров: выбор инфо-источника, ODS-объекта, вспомогательного инфо-куба нажатием кнопки «Активировать» сохраняются все сделанные настройки и данные составляются в инфо-куб. Также далее возможна последующая обработка данных инфо-куба посредством OLAP – процессора.
На момент разработки данного технологического процесса система информационного хранилища данных SAP BW находилась на стадии внедрения, поэтому увидеть работу OLAP-процессора в действии не удалось.

Рисунок 28 – Настройка правил обновления
3.10 Разработка ETL-процесса средствами ABAP
3.10.1 Предпосылки создания ETL-процесса
Стандартные возможности систем SAP R/3 и SAP BW очень велики, а набор доступных функций постоянно расширяется. При разработке ETL-процесса программист может пользоваться базовыми средствами SAP. Так, например, возможно выполнение логических и арифметических операций над переносимыми данными. Однако существуют случаи, когда перед программистом ставят задачи, выполнение которых при помощи стандартных функций SAP невозможно.
Была поставлена задача разработать ETL-процесс, при помощи которого пользователь мог бы комфортно работать с данными, загруженными в хранилище данных SAP BW.
Основными требованиями к ETL-процессу были:
– просмотр данных по определенному интервалу времени;
– просмотр по отчетам, либо финансированию;
– выборка по счетам;
– вывод на экран загружаемой информации через ALV-грид (стандартная таблица SAP для вывода информации на экран);
– копирование в текстовый файл;
Также ETL-процесс должен поддерживать работу со сторонними базами данных. А также вести собственную базу данных уже использованных ранее настроек. Это помогает облегчить работу пользователю и сократить загрузку сервера информационного хранилища данных.
3.10.2 Работа ETL-процесса
Как было упомянуто выше, ETL-процесс разрабатывался на языке ABAP/4 в среде разработки SAP R/3. При помощи GUI был разработан пользовательский интерфейс ETL-процесса (рисунок 29).
Рассмотрим принцип работы ETL-процесса.
В виртуальной памяти создается таблица, структура которой полностью соответствует таблице запрашиваемой пользователем.
Производится считывание данных их хранилища данных и помещений их в виртуальную таблицу. При этом пользователь указывает уникальное имя для своего запроса (экстракта). Запрос пользователя выводится на экран, а отображенная таблица сохраняется под указанным пользователем уникальным именем.
Если пользователю вновь потребуется вызов уже вызываемых ранее данных, то он просто вводит имя созданного ранее экстракта и данные в течении небольшого промежутка извлекутся из базы.
mzextrheader-progid = sy-repid.
mzextrheader-strukid = ‘MYTABLEOUT’.
mzextrheader-extrid = pexrt.
mzextrheader-exrttext = extrtext_info.
INSERT INTO zextrheader VALUES mzextrheader.
IF NOT sy-subrc IS INITIAL.
В данном коде поверяется на истину введенное уникальное имя экстракта. При значении параметра sy-subrc = 0 начинает отрабатывать основной код программы.
Листинг ETL-программы приведен в приложении А.
Особенностями разработанного ETL-процесса являются:
а) Загрузка данных по периоду.
Загрузка какой-нибудь конкретной таблицы без указания периода была бы очень долгой и сильно бы загружала сервер базы данных. Так, например, время загрузки базы данных по ТМЦ (товарно-материальные ценности) за весь период ее существования (2-3 года) составило бы 15-20 часов, тогда как зачастую пользователю требуется данные за последний квартал или месяц, загрузка которых составила бы 5-10 минут. Выборка данных по времени значительно разгружает работу центрального процессора, дисковой системы, а также оперативной памяти сервера. Принимая во внимание то, что как SAP R/3, так и SAP BW являются исключительно клиент-серверными системами, то снижение загрузки серверов приведет к значительной разгрузке сетевого трафика.
б) Выборка по НКС (незавершенное капитальное строительство).
Различные строительно-монтажные работы, изыскательские, проектные, различное оборудование
в) Выборка по счетам и источникам финансирования.
Также позволяет значительно уменьшить количество контролируемой информации, а также исключить избыточную информацию.
г) Вариант вывода отчета.
Доступны два варианта вывода отчета – вывод как текстовый файл, либо вывод как ALV-грид. Вывод информации в текстовый файл полезен для дальнейшего использования полученной информации в DOS-приложениях, либо старых СУБД (FoxPro).
Вывод в ALV-грид лучше воспринимается пользователем, поскольку информация выводится в таблицу имеющую вид excel-таблиц.

Рисунок 29 – Интерфейс ETL-процесса, созданного средствами ABAP
Наиболее важной частью работы процесса является часть «Работы с экстрактом». В данном разделе осуществляется выбор метода, по которому будет работать ETL-процесс. Рассмотрим методы работы раздела более подробно:
а) Работа с БД – процесс работает со стандартной SAP R/3 базой данных, путь к которой указывается активации источника данных.
б) Сохранить экстракт – при работе со стандартной базой данных при установке всех параметров загрузки и отработке ETL-процесса возможно сохранение полученных при загрузке данных под уникальным именем с возможностью последующего вызова.
в) Данные из экстракта – как говорилось в пункте б), существует возможность сохранения всех полученных данных после отработки ETL-процесса. Для вызова данных из отработанного ETL-процесса достаточно ввести уникальное имя, под которым он был сохранен. Данная возможность в сотни раз облегчает работу людям, работающими с одними и теми же данными. Зачем переносить одни и те же данные несколько раз в одно и то же месть, ведь можно произвести перенос данных один раз, а затем делать выборку из уже загруженных данных. Такой подход значительно снижает загруженность серверов и уменьшает сетевой трафик.
г) Удалить экстракт – возникают ситуации, когда загруженные в хранилище данные перестают быть актуальными и требуется удаление некоторых ETL-процессов. Для удаления процесса достаточно ввести имя процесса, нажать клавишу «F8» и нажать кнопку подтверждения удаления.
д) Выбор экстракта – осуществляется выбор ETL-процесса для дальнейшей загрузки либо удаления.
Основной целью создания данного приложения было уменьшение загрузки сервера при постоянном обращении к одним и тем же данным.
Стоит отметить, что данная функция была реализована на основе стандартной программы SAP R/3 «ZVEDOPLOBOR», транзакции «ZMT59».
Заключение
В результате проделанной работы был разработан технологический процесса по организации обработки информации для составления аналитических обзоров бизнес-процессов на базе системы SAP BW.
Сущностью технологического процесса по организации обработки информации для составления аналитических обзоров бизнес-процессов на базе системы SAP BW являлась загрузка данных из ERP-системы SAP R/3 в информационное хранилище SAP BW для последующей обработки и анализа.
На момент разработки технологического процесса информационное хранилище данных SAP BW находилось на стадии внедрения. Была проделана колоссальная работа по загрузке данных из ERP-системы SAP R/3.
Основными плюсами являются перенос информации информационное хранилище данных, которое является мощнейшим средством для анализа данных бизнес-процессов, а также разгрузка сервера SAP R/3, на момент внедрения системы не справляющегося с количеством накопившейся информации.
В данный момент разработанный технологический процесс активно используется на предприятии «ОАО Мозырский нефтеперерабатывающий завод». Проект регулярно обновляется и масштабируется, переносится на другие системы. Также стоит отметить заинтересованность других организаций, использующих SAP BW в качестве информационного хранилища данных в разработанном проекте. Были получены заказы на разработку аналогичных технологический процессов загрузки данных из ERP-систем в информационные хранилища данных.
Стоит отметить тот факт, что на момент внедрения системы SAP BW ее мощнейший OLAP-процессор для глубокого и мощного анализа бизнес информации не был готов для эксплуатации. В настоящее время процессор функционирует, составляя по 1000 бизнес отчетов в день. Это дает возможность в кратчайшие сроки получать полную и развернутую картину экономического состояния предприятия. Помогает мгновенно увидеть реальное положение его как на внутреннем, так и на внешних рынках. Способствует предугадыванию дальнейшего поведения конкурентов, а также укреплению свои позиции в бизнесе путем анализа обработанной бизнес информации основных экономических показателей.
Список использованных источников
1. Корнеев В.В., Гареев А.Ф., Васютин С.В., Райх В.В. Базы данных. Интеллектуальная обработка информации. // М.: Нолидж, 2001. – 635 c.
2. Салливан Т. Данных – больше, доступ – лучше // Computerworld Россия, №38/2001.
3. Kimbal R. The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses. John Willey&Sons, 1996. – 248 c.
4. Thomsen E. OLAP Solutions: Building Multidimensional Information Systems. Wiley Computer Publishing, 1997. – 315 c.
5. Спирли Э. Корпоративные хранилища данных. Планирование, разработка, реализация. Том.1: Пер. с англ. // М.: Вильямс, 2001. – 480 c.
6. Архипенков С.Я., Голубев Д.В., Максименко О.Б. Хранилища данных. От концепции до внедрения. Под общ. Ред. С.Я. Архипенкова // М.: ДИАЛОГ-МИФИ, 2002. – 850 c.
7. Дюк В.В., Самойленко А.Н. Datamining: учебный курс. // СПб: Питер, 2001. – 470 c.
8. Когаловский М.Р. Энциклопедия технологий баз данных. // М.: Финансы и статистика, 2002. – 800 с.
9. Liautaud B., Hammond M. e-Business Intelligence: Turning Information into Knoledge into Profit. McGraw-Hill, 2001. – 1210 c.
10. Комафорд К. Корпоративная отчетность: Серверная архитектура для распределенного доступа к информации. // Открытые системы, 1999. – 150 c.
11. Салливан Т. Это надо рисовать: Программное обеспечение анализа данных становится более выразительным. // ComputerWorld Россия, 2000, 42.
12. Тихонов А.Н. Интернет порталы: Содержания и технологии. // М.: Просвещение, 2003. – 720 с.
13. Конноли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.: Пер. с англ. // М.: Издательский дом “Вильямс”, 2000. – 1120 с.
Приложение А
REPORT zmt59 LINE-SIZE 255 LINE-COUNT 82.
INCLUDE zmt59_data.
INCLUDE lz_func_itf01.
SELECT-OPTIONS sodate FOR sy-datum.
PARAMETERS: disp_err TYPE check DEFAULT ‘X’.
PARAMETERS: disp_nbr TYPE check DEFAULT ‘X’.
PARAMETERS: un_plat TYPE check DEFAULT ‘X’.
SELECTION-SCREEN BEGIN OF BLOCK type_report
WITH FRAME TITLE text-010.
PARAMETERS: pr_mat TYPE check DEFAULT ‘X’.
SELECT-OPTIONS so_hkont FOR mybseg-hkont.
SELECT-OPTIONS so_d_pr FOR sy-datum.
PARAMETERS: pr_usl TYPE check DEFAULT ‘X’.
SELECTION-SCREEN END OF BLOCK type_report.
SELECTION-SCREEN BEGIN OF BLOCK type_opl
WITH FRAME TITLE text-015.
PARAMETERS: z001 RADIOBUTTON GROUP op.
PARAMETERS: z002 RADIOBUTTON GROUP op.
SELECTION-SCREEN END OF BLOCK type_opl.
SELECTION-SCREEN BEGIN OF BLOCK type_o
WITH FRAME TITLE text-011.
PARAMETERS: w001 RADIOBUTTON GROUP mp.
PARAMETERS: w002 RADIOBUTTON GROUP mp.
SELECT-OPTIONS hkontnds FOR mybseg-hkont.
SELECTION-SCREEN END OF BLOCK type_o.
SELECTION-SCREEN BEGIN OF BLOCK type_fin
WITH FRAME TITLE text-012.
PARAMETERS: x001 RADIOBUTTON GROUP mw.
PARAMETERS: x002 RADIOBUTTON GROUP mw.
SELECTION-SCREEN END OF BLOCK type_fin.
SELECTION-SCREEN BEGIN OF BLOCK type_print
WITH FRAME TITLE text-014.
PARAMETERS: p001 RADIOBUTTON GROUP pr.
PARAMETERS: p002 RADIOBUTTON GROUP pr.
SELECTION-SCREEN END OF BLOCK type_print.
SELECTION-SCREEN BEGIN OF BLOCK type_choise
WITH FRAME TITLE text-016.
PARAMETERS: c001 RADIOBUTTON GROUP ch.
PARAMETERS: c002 RADIOBUTTON GROUP ch.
PARAMETERS: c003 RADIOBUTTON GROUP ch.
PARAMETERS: c004 RADIOBUTTON GROUP ch.
PARAMETERS: pexrt LIKE zextrheader-extrid.
SELECTION-SCREEN END OF BLOCK type_choise.
PARAMETERS: name_var(12).
AT SELECTION-SCREEN ON VALUE-REQUEST FOR name_var.
PERFORM alv_f4.
AT SELECTION-SCREEN ON VALUE-REQUEST FOR pexrt.
PERFORM help_ext USING ‘ZEXTRHEADER_S’ ‘EXTRID’.
END-OF-SELECTION.
IF c004 = ‘X’. “Удалить экстракт
DELETE FROM zmt59_ext CLIENT SPECIFIED WHERE
mandt = sy-mandt AND extrid = pexrt.
DELETE FROM zextrheader CLIENT SPECIFIED WHERE
mandt = sy-mandt AND extrid = pexrt.
EXIT.
ENDIF.
IF NOT c001 IS INITIAL OR NOT c003 IS INITIAL.
IF w001 = ‘X’.
sy-tvar3 = ‘объекты НКС ‘.
ELSE.
sy-tvar3 = ‘затраты и счета’.
ENDIF.
IF w002 = ‘X’. ” Если разницу на материалы, то услуги игнорируем
CLEAR: pr_usl.
ENDIF.
REFRESH tablends_copy.
* Если материалы не выбраны, то удаляем счет и дату прихода
IF pr_mat = ‘ ‘.
REFRESH: so_hkont,so_d_pr.
CLEAR: so_hkont,so_d_pr.
ENDIF.
* Формируем дату (Range), которая sodate_old-high = sodate-low – 1.
sodate_old-sign = ‘I’.
sodate_old-option = ‘BT’.
APPEND sodate_old.
z_ind_sfk = 0.
** Обрабатываем таблицу ZOST561 , подготовленном Макаревичем
** “Статинфотех” по остаткам материалов
IF pr_mat = ‘X’. “Если по ТМЦ
SELECT * FROM zost561 INTO CORRESPONDING FIELDS OF TABLE ost561.
SORT ost561 BY bwtar lgort.
ENDIF.
ENDIF. “If not c001 is initial or not c003 is initial.
WRITE sodate-low TO sy-tvar1 DD/MM/YYYY.
WRITE sodate-high TO sy-tvar2 DD/MM/YYYY.
IF NOT c001 IS INITIAL OR NOT c003 IS INITIAL.
type_calc = 1.
* Ищем документы, созданные в данном периоде и смотрим, чтобы это был
* документ выравнивания
SELECT * INTO mybkpf FROM bkpf
WHERE bukrs = ‘MNPZ’ AND
bstat IN (‘ ‘,’A’) AND
budat IN sodate.
* Проверка на документ, сторно выравнивания
CLEAR fl_storno_zakr_per.
IF NOT ( mybkpf-stblg IS INITIAL ).
SELECT SINGLE stgrd INTO mystgrd FROM bkpf
WHERE bukrs = mybkpf-bukrs AND
belnr = mybkpf-stblg AND
gjahr = mybkpf-stjah.
IF ( sy-subrc = 0 ) AND
( mystgrd ’01’ ) AND
( NOT ( mystgrd IS INITIAL ) ) .
fl_storno_zakr_per = ‘X’.
ENDIF.
ENDIF.
IF ( mybkpf-stblg IS INITIAL ) OR “Не сторно или
( ( mystgrd ’01’ ) AND
( NOT ( mystgrd IS INITIAL ) ) ) OR “Сторнировано в закрытом
” периоде или
( fl_storno_zakr_per = ‘X’ ).”отмена выравнивания в закрытом периоде
IF fl_storno_zakr_per = ‘X’. “отмена выравнивания в закрытом периоде
mybkpf-belnr = mybkpf-stblg.
mybkpf-gjahr = mybkpf-stjah.
ENDIF.
SELECT SINGLE * INTO mybse_clr FROM bse_clr
WHERE bukrs_clr = mybkpf-bukrs AND
belnr_clr = mybkpf-belnr AND
gjahr_clr = mybkpf-gjahr AND
koart = ‘K’. “Выранивание кредитора
IF sy-subrc = 0. “Кредитор
* Определяем позиции фактуры
SELECT * INTO mybse_clr FROM bse_clr
WHERE bukrs_clr = mybkpf-bukrs AND
belnr_clr = mybkpf-belnr AND
gjahr_clr = mybkpf-gjahr AND
koart = ‘K’.
SELECT SINGLE xnegp INTO tablesfk-xnegp FROM bseg
WHERE bukrs = mybse_clr-bukrs AND
belnr = mybse_clr-belnr AND
gjahr = mybse_clr-gjahr AND
buzei = mybse_clr-buzei.
* Не платеж
IF ( mybse_clr-shkzg = ‘H’ AND tablesfk-xnegp = ‘X’ ) OR
( mybse_clr-shkzg = ‘S’ AND tablesfk-xnegp = ‘ ‘ ).
* if myBSE_CLR-SHKZG = ‘S’ and tableSfk-xnegp = ‘ ‘ .
CONTINUE.
ENDIF.
* Убираем позиции выравнивания
SELECT SINGLE * INTO mybse_clr2 FROM bse_clr
WHERE bukrs_clr = mybse_clr-bukrs AND
belnr_clr = mybse_clr-belnr AND
gjahr_clr = mybse_clr-gjahr AND
koart ‘S’.
IF sy-subrc 0. ” Если не документ выравнивания
* Проверяем на обработку документиа фактуры
READ TABLE tablesfk WITH KEY belnr_sfk = mybse_clr-belnr
gjahr_sfk = mybse_clr-gjahr.
IF sy-subrc 0. “Документ не найден
tablesfk-belnr_sfk = mybse_clr-belnr.
tablesfk-gjahr_sfk = mybse_clr-gjahr.
tablesfk-fl_storno_zakr_per = fl_storno_zakr_per.
CLEAR: tablesfk-anln1,
tablesfk-anln2,
tablesfk-fl_usl_fi,
tablesfk-txz01,
tablesfk-lifnr.
PERFORM ch_storno_mm_fakt USING tablesfk-belnr_sfk
tablesfk-gjahr_sfk
CHANGING ttt.
IF ttt = ‘X’.
CONTINUE.
ENDIF.
IF pr_usl = ‘X’. ” Если по услугам
PERFORM ch_fakt_fi_nks USING mybkpf-bukrs
tablesfk-belnr_sfk
tablesfk-gjahr_sfk
CHANGING tablesfk-anln1
tablesfk-anln2
tablesfk-txz01
tablesfk-fl_usl_fi.
IF tablesfk-fl_usl_fi = ‘X’.
PERFORM ch_klass_os
USING
tablesfk-anln1
tablesfk-anln2
CHANGING
fl_mbp.
IF fl_mbp = ‘X’.
CONTINUE.
ENDIF.
SELECT SINGLE lifnr INTO tablesfk-lifnr FROM bseg
WHERE bukrs = mybse_clr-bukrs AND
belnr = mybse_clr-belnr AND
gjahr = mybse_clr-gjahr AND
buzei = mybse_clr-buzei.
ENDIF.
ENDIF.
SELECT SINGLE tcode waers budat
INTO (mytcode,tablesfk-waers,tablesfk-d_sfk)
FROM bkpf
WHERE bukrs = mybkpf-bukrs AND
belnr = tablesfk-belnr_sfk AND
gjahr = tablesfk-gjahr_sfk.
IF ( mytcode = ‘MIRO’ ) OR
( mytcode = ‘MR01’ ) OR
( tablesfk-fl_usl_fi = ‘X’ ).
IF tablesfk-fl_storno_zakr_per = ‘ ‘.
PERFORM croplfakt TABLES sodate
USING tablesfk-belnr_sfk
tablesfk-gjahr_sfk
mybse_clr-buzei
emptybelnr
emptygjahr.
ELSE.
PERFORM croplfakt TABLES sodate_old
USING tablesfk-belnr_sfk
tablesfk-gjahr_sfk
mybse_clr-buzei
mybkpf-belnr
mybkpf-gjahr.
ENDIF.
IF tablesfk-fl_usl_fi = ‘X’. ” Если фактура FI, то НДС
* Определяем сумму оплаты за исключением НДС и НДС
snds = 0.
CLEAR tablesfk-hkont_nds_clr.
SELECT * INTO mybset FROM bset ” Сумма НДС
WHERE bukrs = mybkpf-bukrs AND
belnr = tablesfk-belnr_sfk AND
gjahr = tablesfk-gjahr_sfk AND
hwste 0.
snds = snds + mybset-hwste.
ENDSELECT.
SELECT SINGLE * INTO mybseg FROM bseg
WHERE bukrs = mybkpf-bukrs AND
belnr = tablesfk-belnr_sfk AND
gjahr = tablesfk-gjahr_sfk AND
koart = ‘K’.
IF sy-subrc = 0. ” Сумма по фактуре
LOOP AT tablesfk WHERE belnr_sfk = mybseg-belnr AND
gjahr_sfk = mybseg-gjahr.
old_tablesfk_dmbtr_clr2 = tablesfk-dmbtr_clr.
IF z001 = ‘X’.
tablesfk-dmbtr_clr = ( ( mybseg-dmbtr – snds ) /
mybseg-dmbtr ) * old_tablesfk_dmbtr_clr2.
ELSE.
CLEAR s777.
* Приводим оплату к валюте фактуры
CALL FUNCTION ‘ZCONV_FOREIGN_TO_FOREIGN_CUR’
EXPORTING
* CLIENT = SY-MANDT
date = tablesfk-d_clr
* TYPE_OF_RATE = ‘M’
from_amount = tablesfk-dmbtr_clr
from_currency = ‘BYB’
to_currency = tablesfk-waers
local_currency = ‘BYB’
* CONVERSION_MODE =
IMPORTING
to_amount = s777
EXCEPTIONS
no_rate_found = 1
overflow = 2
no_factors_found = 3
no_spread_found = 4
derived_2_times = 5
OTHERS = 6
.
IF sy-subrc 0.
WRITE: tablesfk-belnr_sfk, sy-msgv1,sy-msgv2,
sy-msgv3,sy-msgv4.
NEW-LINE.
s777 = 1.
ENDIF.
tablesfk-dmbtr_clr = ( mybseg-dmbtr – snds )
* ( s777 / mybseg-wrbtr ).
ENDIF.
MODIFY tablesfk.
ENDLOOP.
ENDIF.
ENDIF. ” Если фактура FI, то НДС
ENDIF.
ENDIF. “Документ не найден
ENDIF. ” Если не документ выравнивания
ENDSELECT. ” myBSE_CLR
ENDIF.” Кредитор
ENDIF. “Не сторно
ENDSELECT.
* PERFORM DEL_DOUBLE_FAKTURE.
* Удаляем позиции, дата выравнивания котторых не в SO_DATE И НЕ ОТМЕНА
* ВЫРАВНИВАНИЯ
DELETE tablesfk WHERE d_clr PERFORM crdocmat.
IF pr_mat = ‘X’.
old_pr_usl = pr_usl.
pr_usl = ‘ ‘.
* Обрабатываем Все движения с ВД 241, чтобы найти перемещения ТМЦ,
* оплаченных ранее, т.е. которые не обработались сверху
type_calc = 2.
REFRESH: tablesfk,
tableat,
tableebeln,
tablends.
REFRESH: table241,
table241_i.
CLEAR: tablesfk,
tableat,
tableebeln,
tablends.
ost561-fl_obr = ‘ ‘.
MODIFY ost561 TRANSPORTING fl_obr WHERE fl_obr = ‘X’.
IF w001 = ‘X’. “НКС
SELECT * INTO CORRESPONDING FIELDS OF mymseg
FROM mseg AS mseg INNER JOIN mkpf AS mkpf
ON mseg~mblnr = mkpf~mblnr AND
mseg~mjahr = mkpf~mjahr
WHERE mkpf~budat IN sodate AND
( mseg~bwart = ‘241’ OR ” на НКС
mseg~bwart = ‘281’ ). ” на проект
IF mymseg-bwart = ‘281’. ” если СПП
CALL FUNCTION ‘Z_KOL_SPP_NAL’
EXPORTING
p_pspnr = mymseg-ps_psp_pnr
IMPORTING
p_anln1 = mymseg-anln1
p_anln2 = mymseg-anln2
EXCEPTIONS
neopr = 1
nespp = 2
nonks = 3
OTHERS = 4.
IF sy-subrc 0.
CONTINUE.
ENDIF.
ENDIF.
PERFORM ch_klass_os
USING
mymseg-anln1
mymseg-anln2
CHANGING
fl_mbp.
IF fl_mbp = ‘X’. ” МБП
CONTINUE.
ENDIF.
* Проверка на сторно
IF NOT ( mymseg-smbln IS INITIAL ).” Не сторно
CONTINUE.
ENDIF.
SELECT SINGLE * INTO mymseg2 FROM *mseg
WHERE smbln = mymseg-mblnr AND
sjahr = mymseg-mjahr AND
smblp = mymseg-zeile.
IF sy-subrc 0. ” Не сторно документа материала
READ TABLE table241 WITH KEY mblnr = mymseg-mblnr
mjahr = mymseg-mjahr
zeile = mymseg-zeile.
IF sy-subrc 0. ” Не найдено в движениях прошлых лет
PERFORM seek_sf
USING
mymseg.
ENDIF.
ENDIF. ” Не сторно документа материала
ENDSELECT. “Mseg & Mkpf
ELSE. ” На затраты
SELECT * INTO CORRESPONDING FIELDS OF mymseg
FROM mseg AS mseg INNER JOIN mkpf AS mkpf
ON mseg~mblnr = mkpf~mblnr AND
mseg~mjahr = mkpf~mjahr
WHERE mkpf~budat IN sodate AND
mkpf~blart = ‘WA’ AND
mseg~shkzg = ‘H’ AND
( ( mseg~kostl ‘ ‘ OR
mseg~sakto ‘ ‘ ) AND
( mseg~umwrk = ‘ ‘ AND
mseg~ummat = ‘ ‘ )
).
* Проверка на сторно
IF NOT ( mymseg-smbln IS INITIAL ).” Не сторно
* Проверяем
CONTINUE.
ENDIF.
* Убираем кредит МБП (завод 1207) без цены
IF mymseg-werks = ‘1207’.
CONTINUE.
ENDIF.
SELECT SINGLE * INTO mymseg2 FROM *mseg
WHERE smbln = mymseg-mblnr AND
sjahr = mymseg-mjahr AND
smblp = mymseg-zeile.
IF sy-subrc 0. ” Не сторно документа материала
READ TABLE table241_c WITH KEY mblnr = mymseg-mblnr
mjahr = mymseg-mjahr
zeile = mymseg-zeile.
IF sy-subrc 0. ” Не найдено в движениях прошлых лет
PERFORM seek_sf
USING
mymseg.
ENDIF.
ENDIF. ” Не сторно документа материала
ENDSELECT. “Mseg & Mkpf
ENDIF.
* PERFORM DEL_DOUBLE_FAKTURE.
PERFORM crdocmat.
** Обрабатываем Все движения с ВД Z02, чтобы найти перемещения ТМЦ,
** оплаченных ранее, но возвращенных на склад (с минусом)
*refresh tableSfk.
*refresh tableMat.
*refresh tableebeln.
*refresh tableNds.
*type_calc = 3.
*SELECT * INTO CORRESPONDING FIELDS of myMseg
* FROM MSEG AS MSEG INNER JOIN MKPF AS MKPF
* ON MSEG~mblnr = mkpf~mblnr AND
* MSEG~mjahr = mkpf~mjahr
* where mkpf~budat in sodate and
* mseg~BWART = ‘Z02’.
** Проверка на сторно
* if not ( myMseg-smbln is initial ).” Не сторно
* table241-fl_Z02 = ‘X’.
* table241-mblnr = mymseg-mblnr.
* table241-mjahr = mymseg-mjahr.
* table241-zeile = myMseg-zeile.
* table241-fl_561 = ‘ ‘.
* append table241.
* continue.
* endif.
* select single * into myMseg2 from *mseg
* where smbln = myMseg-mblnr and
* sjahr = myMseg-mjahr and
* smblp = myMseg-ZEILE.
* if sy-subrc = 0. ” Cторно документа материала
* table241-fl_Z02 = ‘X’.
* table241-mblnr = mymseg-mblnr.
* table241-mjahr = mymseg-mjahr.
* table241-zeile = myMseg-zeile.
* table241-fl_561 = ‘ ‘.
* append table241.
* continue.
* endif.
** Ищем номер документа материала, которым данный материал попал на НКС
* select * into myMseg2 from mseg
* where matnr = myMseg-matnr and
* charg = myMseg-bwtar and
* bwart = ‘241’.
*
* if not ( myMseg2-smbln is initial ).” Не сторно
* table241-mblnr = mymseg2-mblnr.
* table241-mjahr = mymseg2-mjahr.
* table241-zeile = myMseg2-zeile.
* table241-fl_561 = ‘ ‘.
* append table241.
* continue.
* endif.
* select single * into myMseg3 from *mseg
* where smbln = myMseg2-mblnr and
* sjahr = myMseg2-mjahr and
* smblp = myMseg2-ZEILE.
* if sy-subrc = 0. ” Cторно документа материала
* table241-mblnr = mymseg2-mblnr.
* table241-mjahr = mymseg2-mjahr.
* table241-zeile = myMseg2-zeile.
* table241-fl_561 = ‘ ‘.
* append table241.
* continue.
* else.
*
* PERFORM SEEK_SF
* USING
* myMseg2.
* exit.
* endif.
* endselect.
*
*ENDSELECT. “Mseg & Mkpf
*PERFORM DEL_DOUBLE_FAKTURE.
*
* PERFORM CRDOCMAT.
* Обрабатываем Все движения с ВД 241, чтобы вывести
* все необработанные документы
IF disp_nbr = ‘X’.
WRITE: / ‘Необработанные д-ты с 241 ВД:’.
SELECT * INTO CORRESPONDING FIELDS OF mymseg
FROM mseg AS mseg INNER JOIN mkpf AS mkpf
ON mseg~mblnr = mkpf~mblnr AND
mseg~mjahr = mkpf~mjahr
WHERE mkpf~budat IN sodate AND
mseg~bwart IN (‘241′,’281’).
* mseg~BWART in (‘241’, ‘Z02’).
IF mymseg-bwart = ‘281’. ” если СПП
CALL FUNCTION ‘Z_KOL_SPP_NAL’
EXPORTING
p_pspnr = mymseg-ps_psp_pnr
IMPORTING
p_anln1 = mymseg-anln1
p_anln2 = mymseg-anln2
EXCEPTIONS
neopr = 1
nespp = 2
nonks = 3
OTHERS = 4.
IF sy-subrc 0.
CONTINUE.
ENDIF.
ENDIF.
PERFORM ch_klass_os
USING
mymseg-anln1
mymseg-anln2
CHANGING
fl_mbp.
IF fl_mbp = ‘X’. ” МБП
CONTINUE.
ENDIF.
* Проверка на сторно
SELECT SINGLE * INTO mymseg2 FROM *mseg
WHERE smbln = mymseg-mblnr AND
sjahr = mymseg-mjahr AND
smblp = mymseg-zeile.
IF sy-subrc 0. ” Не сторно документа материала
READ TABLE table241 WITH KEY mblnr = mymseg-mblnr
mjahr = mymseg-mjahr
zeile = mymseg-zeile.
IF ( sy-subrc 0 ). ” Не найдено в обраб-х движениях
SELECT SINGLE * INTO mymkpf FROM mkpf
WHERE mblnr = mymseg-mblnr AND
mjahr = mymseg-mjahr.
WRITE: / ‘241 – ‘, mymkpf-budat DD/MM/YYYY,
mymseg-mblnr,
mymseg-zeile,
mymseg-matnr NO-ZERO,
mymseg-bwtar,
mymseg-menge,
table241-lifnr.
fl_err = ‘241’.
ELSE.
IF table241-fl_561 = ‘X’ . ” Старый приход
WRITE: / ‘561 – ‘, mymkpf-budat DD/MM/YYYY,
mymseg-menge,
table241-lifnr.
fl_err = ‘561’.
out_err_mblnr = mymseg-mblnr.
out_err_mgahr = mymseg-mjahr.
HIDE: out_err_mblnr, out_err_mgahr, fl_err.
ENDIF.
IF table241-fl_z02 = ‘X’ . ” ВД Z02
WRITE: / ‘Z02 – ‘, mymkpf-budat DD/MM/YYYY,
mymseg-mblnr,
mymseg-zeile,
mymseg-matnr NO-ZERO,
mymseg-bwtar,
mymseg-menge,
table241-lifnr.
fl_err = ‘561’.
out_err_mblnr = mymseg-mblnr.
out_err_mgahr = mymseg-mjahr.
HIDE: out_err_mblnr, out_err_mgahr, fl_err.
ENDIF.
ENDIF.
ENDIF. ” Не сторно документа материала
ENDSELECT. “Mseg & Mkpf
ENDIF.” Вывод необработанных документов
pr_usl = old_pr_usl.
ENDIF. “PR_MAT
SORT tableout BY hkont_main mblnr mjahr zeile.
ENDIF. “If not c001 is initial or not c003 is initial.
**——-
DATA: extrtext_info(20),
cnterr(10) TYPE p DECIMALS 0.
CONCATENATE sy-datum ‘ ” ‘ sy-uzeit INTO extrtext_info.
IF c003 = ‘X’ AND NOT pexrt IS INITIAL.
DATA mzextrheader LIKE zextrheader.
mzextrheader-progid = sy-repid.
mzextrheader-strukid = ‘MYTABLEOUT’.
mzextrheader-extrid = pexrt.
mzextrheader-exrttext = extrtext_info.
INSERT INTO zextrheader VALUES mzextrheader.
IF NOT sy-subrc IS INITIAL.
DELETE FROM zextrheader
WHERE progid = mzextrheader-progid
AND strukid = mzextrheader-strukid
AND extrid = mzextrheader-extrid.
IF NOT sy-subrc IS INITIAL.
DELETE FROM zmt59_ext
WHERE progid = mzextrheader-progid
AND strukid = mzextrheader-strukid
AND extrid = mzextrheader-extrid.
ENDIF.
INSERT INTO zextrheader VALUES mzextrheader.
ENDIF.
IF NOT sy-subrc IS INITIAL.
MESSAGE i001(zbasmessage) WITH ‘ОшибкаДобавЭкстр’ pexrt.
ELSE.
* Если запись в ZEXTRHEADER успешна
DATA mzmt59_ext LIKE zmt59_ext.
MOVE-CORRESPONDING mzextrheader TO mzmt59_ext.
LOOP AT tableout.
MOVE-CORRESPONDING tableout TO mzmt59_ext.
UNPACK sy-tabix TO mzmt59_ext-id_line.
INSERT INTO zmt59_ext VALUES mzmt59_ext.
IF NOT sy-subrc IS INITIAL.
ADD 1 TO cnterr.
ENDIF.
ENDLOOP.
IF NOT cnterr IS INITIAL.
MESSAGE i001(zbasmessage) WITH
cnterr ‘Ошибок(и)ДобавПоз’ pexrt.
ENDIF.
ENDIF.
ENDIF.
IF c002 = ‘X’ AND NOT pexrt IS INITIAL.
SELECT * FROM zmt59_ext INTO CORRESPONDING FIELDS OF TABLE tableout
WHERE progid = sy-repid
AND strukid = ‘MYTABLEOUT’
AND extrid = pexrt.
ENDIF.