Функциональные и технические. требования (стр. 5 )

Состав справочников может быть уточнен в ходе проекта. Окончательные требования по составу справочников содержатся в утвержденной Модели данных ИКСО.

Формирование структуры и содержания справочников осуществляет Заказчик.

Общие справочники ИР ИКСО и КИС SAP РН

ИР ИКСО предусматривает синхронизацию по следующим корпоративным справочникам с КИС SAP РН:

Деловые партнеры - Аналитика 96: Контрагенты; Материалы, Класс материалов - Аналитика для ИКСО в Классе материалов - Аналитика 24: Группы продуктов, услуг (в зависимости от Вида класса материала устанавливается аналитика ИКСО для КСМ); ЕУП - Аналитика 95: Единый унифицированный периметр; Страны - Аналитика 41: Направления реализации; Единицы измерения - Аналитика T01: Единица измерения; Валюты - Аналитика 4: Виды валют.

Предварительно, до начала работ по синхронизации, будет получено согласие владельцев указанных справочников на их использование в ИР ИКСО.

Для поддержания целостности справочников и классификаторов, имеющихся в ИР ИКСО и используемых в КИС SAP РН, необходимо поддержать процесс гармонизации состава и содержимого справочников.

Перечень корпоративных объектов НСИ приведен в приложении (ПРИЛОЖЕНИЕ 6. Перечень корпоративных объектов НСИ).

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

Перечень некорпоративных справочников НСИ приведен в приложении (ПРИЛОЖЕНИЕ 7. Перечень некорпоративных объектов НСИ).

Средства хранения данных

Хранилище данных должно быть построено на основе модели данных ИКСО и обеспечивать сопоставимость  и отсутствие избыточности данных.

В хранилище выделена подистема сбора, обработки, архивации и хранения данных представляющую собой реализацию детального уровня модели ИКСО.

Данная подсистема имеет дополнительную функциональность по обеспечению пересчетов неконсолидированных и неагрегированных данных и их обогащения (включая деривацию) необходимыми аналитиками. Часть существующих (в реализации ИР ИКСО) процедур по обогащению и деривации необходимо мигрировать с уровня агрегации в эту подиситему.

Требования в части хранения данных

ИР ИКСО должен обеспечить выполнение следующих требований в части хранения данных:

Возможность хранения в одном хранилище данных факта, плана и ожидаемого итога; Поддержка произвольного числа нескольких версий для хранимых данных; Обеспечение единства структурирования (показатели, аналитические разрезы и т. п.) между данными планирования, прогнозирования и фактическими данными; Поддержка хранения различных типов данных:

одномерные – измерения и их атрибуты, например, атрибуты валют, балансовых счетов или филиалов; реляционные – например, данные об остатках и оборотах, хранимые в соответствии с принятой ER-моделью, описывающей соответствующую предметную область; многомерные – например, данные об остатках и оборотах, разложенные по нескольким измерениям (или аналитическим срезам, например, балансовым счетам, валюте и времени);

Возможность сегментирования хранения данных по видам бизнеса (видам деятельности), по функциональным областям (процессам и функциям), т. е. возможность хранения данных принадлежащих разным «видам бизнеса» или разным «функциональным областям» в физически различных объектах хранилища данных; Поддержка необходимого количества измерений для хранимых данных; Обеспечение поддержки единиц измерений как для финансовых данных, так и для нефинансовых данных (например, объемы, численность); Поддержка необходимой иерархии значений измерений для хранимых данных (например, период: год – квартал – месяц); Возможность хранения данных с незаполненными/частично заполненными измерениями; Возможность хранения рассчитанных значений (как по модели, так и по иерархии); Возможность внесения изменений в справочники непосредственно в хранилище данных в соответствии с существующим в Компании регламентом; Возможность обновления справочников через импорт файлов в формате CSV; Возможность экспорта справочников в формате CSV; Поддержка времязависимых иерархий справочников, версионности, времязависимых текстовых описаний  основных данных; Возможность загрузки и хранения данных в разных  моделях данных ИКСО (оперативная,  перспективная); Поддержка произвольного количества иерархических представления значений справочников; Управление метаданными объектов ИР ИКСО и хранение этой информации в разделах базы данных ИР; Хранение данных по курсам ряда иностранных валют (доллары США, Евро) к Российскому рублю, установленных Банком России на каждый день и средние курсы за месяц, квартал, год; Поддержка многовалютности при формировании отчетности. В системе должна быть обеспечена  возможность перевода показателей из базовой в любую валюту на уровне отчетов (курсы пересчета). А также для иностранных компаний, входящих в периметр консолидации, должен осуществляться пересчет из валюты компании в функциональную валюту – рубль РФ; Поддержка возможности ведения данных в валюте транзакции исходных документов с возможностью пересчета в функциональную валюту. Ориентировочное количество показателей в модели данных - около 4000; Количество аналитических признаков в модели данных ИКСО представлены в таблицах ниже.

Таблица 4. Аналитики модели ИКСО

	Текущее Количество	Возможное изменение (+/-)	Итого
1	2	3	4
Количество аналитик модели данных	51	+3/-1	54/53
из них атрибуты к аналитикам	15	+1/-0	16/15
Количество основных аналитик	36	+2/-1	38/37
в т. ч. на детальном уровне	36	+2/-1	38/37
в т. ч. на уровне консолидации	12	0	12/12

Таблица 5. Основные аналитики консолидации

№	Наименование	комментарий
1	2	3
Аналитика 1: Вид движения
Аналитика 4: Виды валют
Аналитика 24: Группы продуктов, услуг	наборы Х1, Х3
Аналитика 41: Направления реализации
Аналитика 46: Канал сбыта	набор Х1
Аналитика 72: Схемы замещения
Аналитика 95: Единый унифицированный периметр
Аналитика 96: Контрагенты

Таблица 6. Вспомогательные аналитики консолидации

№	Наименование	комментарий
1	2	3
Аналитика T01: Единица измерения
Аналитика T02: Типы бизнес-единиц	атрибут аналитики 97
Аналитика T08: Принадлежность компании	атрибут аналитик 95, 96
Аналитика T14_1: Признаки к значениям аналитик - методы консолидации.	атрибут аналитики 95,96
Аналитика T14_2: Признаки к значениям аналитик - тип актива.	атрибут аналитики 97
Аналитика T14_3: Признаки к значениям аналитик - территориальная принадлежность.	атрибут аналитики 97
Аналитика T14_4: Признаки к значениям аналитик – Классификация ОГ по видам деятельности	атрибут аналитики 97
Аналитика T14_5: Признаки к значениям аналитик - виды перевалки.	атрибут аналитики 52
Аналитика T14_6: Признаки к значениям аналитик – ОГ с параллельным учетом	атрибут аналитики 97
Аналитика T14_8: Признаки к значениям аналитик - ОГ добыча/разведка на суше или шельфе	атрибут аналитики 95
Аналитика T14_9: Признаки к значениям аналитик - Группа ТНК	атрибут аналитики 95
Аналитика T20: Регион	атрибут аналитик 95, 96
Аналитика T21: Период
Аналитика T22: Версия данных
Аналитика T94: Сегмент и направление деятельности, производственный блок	атрибут значений 95, 96
Аналитика 200: Перечень поправок по процессам

Требования к аналитическим приложениям

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

Требования к приложениям по работе с данными:

Проведение логических проверок данных согласно предопределенным правилам; Обеспечение возможности присваивать метод логической проверки в зависимости от единицы консолидации (Приложение 3. Особые Требования к функциональности системы, п.26); Обеспечение универсального механизма перехода из операндов логической проверки к детализации данных, которые образуют соответствующую сумму. Для выполнения данного требования не допускается создавать индивидуальные отчеты под каждый шаг логической проверки (Приложение 3. Особые Требования к функциональности системы, п. 27); Обеспечение проверки данных, привязанной, например,  к рабочим статусам (для SAP BPC), для обеспечения зависимости выбора дальнейших шагов от результата проверки, на всех уровнях процесса консолидации на уровнях исходных данных, трансформированных данных, аллокированных данных, консолидированных данных. Не допускается замена системных проверок проверочными отчетами (Приложение 3. Особые Требования к функциональности системы, п.28); Обеспечение выполнения операций консолидации, в частности:

исключение внутригрупповой задолженности и внутригрупповых оборотов с учетом различных аналитических признаков (в частности признаки ТМЦ, ОС-НКС, различные виды услуг); расчет внутригрупповой маржи на каждом уровне (консолидация полная, консолидация отдельных ОГ и т. д.) с учетом различных аналитических признаков (в частности признаки ТМЦ, ОС, НКС, различные виды услуг); консолидация капитала в частности расчет неконтролирующей доли, гудвилл, исключение в инвестициях и капитале, пропорциональная консолидация, метод долевого участия (на всех уровнях, при полной консолидации и консолидации отдельных ОГ); консолидация натуральных показателей (в частности тонны, м3); поддержка проверок внутригрупповых оборотов (финансовых и натуральных показателей); консолидируется указанный в организационном объеме периметр ОГ (до 1000 ОГ); консолидация на уровне субхолдинга;

Обеспечение встроенных бизнес-правил консолидации, исключения внутригрупповых оборотов, пересчета валют, проверки корректности комбинаций ввода, переноса сальдо, формирование наборов бизнес-правил консолидации (добавления/ исключения бизнес-правил для отдельной консолидации – версии консолидации) и т. д.; Возможность ведения нескольких Периметров консолидации одновременно; Автоматизация следующих операций с капиталом:

начальная консолидация, постепенное приобретение, повторная консолидация, частичное выбытие, перенос долей участия, полное выбытие, увеличение капитала, уменьшение капитала;

Обеспечение возможности внесения ручных и автоматических корректировок данных, в том числе в трансформированные и консолидированные данные; В интерфейсе ручной корректировки должны отражаться не только коды, но и названия аналитики (измерения) (Приложение 3. Особые Требования к функциональности системы, п. 38, 17,  21); Поддержка механизма проводок и поддержка двойной записи в рамках процесса подготовки консолидированной отчетности. В случае отсутствия баланса в проводках система должна выдавать ошибку и результат этот ошибки должен отражаться в статусе мероприятия породившего эту ошибку; Ограничение набора аналитик их значений в зависимости от выбранного счета при ручных проводках.  (Приложение 3. Особые Требования к функциональности системы, п. 20); Ведение неограниченного количества версий данных, создание новых версий путем копирования с обеспечением прозрачности данных новой версии; Возможность сохранения полной истории формирования и корректировки данных; Возможность системным образом устанавливать запрет на изменение данных по определенным комбинациям аналитических признаков (блокировка среза данных по версии, периоду, единице консолидации); Для обеспечения  прозрачности процесса, необходимо, чтобы пакет консолидации был разбит на отдельные мероприятия, чтобы, в случае сбоя,  можно было понять, на каком этапе возник сбой, какие автоматические проводки выполнились, а какие нет (Приложение 3. Особые Требования к функциональности системы, п. 12); Все автоматические мероприятия по процессам трансформации, аллокации и консолидации должны быть представлены списком, с привязкой к порядку их выполнения (Приложение 3. Особые Требования к функциональности системы, п. 13); Обеспечение обязательного предварительного автоматического удаления предыдущих результатов расчета при повторном запуске автоматических проводок (Приложение 3. Особые Требования к функциональности системы, п. 33); Расширение стандартных возможностей по реклассифицирующим и исключающим проводкам: включение в настройку реклассов всех аналитических признаков из модели (Приложение 3. Особые Требования к функциональности системы, п. 36); Обеспечение в диспетчере долей владения межстрочной разлиновки или переменной заливки строк двумя цветами (Приложение 3. Особые Требования к функциональности системы, п. 8); Настройка монитора консолидации:

Требуется обеспечить полноценный монитор консолидации с возможностью запуска всех необходимых мероприятий (перенос сальдо, Script logic и т. д.) (Приложение 3. Особые Требования к функциональности системы, п. 6); Требуется обеспечить функциональность множественного выбора единиц консолидации при установке рабочего статуса. Пользователь должен иметь возможность выбирать узлы иерархии компаний и (или) отдельные компании (Приложение 3. Особые Требования к функциональности системы, п. 3); Требуется наличие монитора/нескольких мониторов мероприятий (загрузка данных, проверка, автоматические и ручные проводки и т. п.) по трансформации, консолидации и аллокации, который/которые бы отражал статусы выполнения мероприятий по каждой единице консолидации или каждой группе компаний (Приложение 3. Особые Требования к функциональности системы, п. 37); Требуется в наличие в мониторе трансформации, аллокации и консолидации мероприятий ручной проводки, при вызове которых (в web-интрефейс) для выполняющей этот процесс функции будут переданы данные единицы консолидации / группы компаний, периода, кода проводки, версия отчетности (Приложение 3. Особые Требования к функциональности системы, п. 34); Статус выполнения пакетов должен быть привязан к единице консолидации (Приложение 3. Особые Требования к функциональности системы, п. 19); Статус выполнения мероприятия в мониторе консолидации (или в BPF) должен автоматически возвращать результат выполнения данного мероприятия  (ошибка, предупреждение, успех). Не допускается установка статуса мероприятия пользователем вручную, без связи с фактом выполнения и результатом работы мероприятия (Приложение 3. Особые Требования к функциональности системы, п. 4); Необходим функционал (web-интерфейса) для запуска консолидации кнопкой или пунктом меню "консолидировать". Данная функция должна обеспечивать не только запуск консолидации (кнопка «консолидировать»), но и активировать возможность просмотра статусов по всем ЕК и всем пакетам на одном экране (монитор консолидации) (Приложение 3. Особые Требования к функциональности системы, п. 11); Блокирование для выбранных (или для всех) компаний монитора консолидации на выполнение в нем действий пользователями; Требуется обеспечить возможность сортировки единиц консолидации по номеру (Приложение 3. Особые Требования к функциональности системы, п. 9).

Журналирование операций:

Необходим журнал (отчет), в котором пошагово можно проверить расчет суммы автоматической поправки, включая промежуточные итоги расчета для уровней трансформации, аллокации и консолидации данных (Приложение 3. Особые Требования к функциональности системы, п. 18,  35, 2); Требуется более детальный аудиторский след выполнения пакетов трансформации и консолидации,  частности, требуется выводить информацию: какие конкретно функции (бизнес-правила) отработали в рамках запущенного пакета, какие при этом записи были сгенерированы, какие ошибки возникли (Приложение 3. Особые Требования к функциональности системы, п. 5); Требуется обеспечить возможность экспорта журналов ручных проводок в формат MS Excel (Приложение 3. Особые Требования к функциональности системы, п. 7); При выведении ошибки  при проведении мероприятия должен быть подробный отчет для пользователя в бизнес-терминах, без излишней технической детализации (Приложение 3. Особые Требования к функциональности системы, п. 15); Отчет о журнальных проводках должен экспортироваться в MS Excel из web, нужна доработка  (аналог "список итоговых позиций", или "список итоговых записей" которые сейчас экспортируются в MS Excel) (Приложение 3. Особые Требования к функциональности системы, п. 16);

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

Общее количество автоматических  корректировочных проводок в модели данных ИКСО 230. Из них по видам деление следующее: