Техническое задание москва 2015 содержание введение Функциональные и технические требования (далее фтт) по проекту iid-094 «Интегрированная корпоративная система отчетности (иксо)»

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

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

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

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

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

9. 
   Обеспечение возможности внесения ручных и автоматических корректировок данных, в том числе в трансформированные и консолидированные данные;
   
10. 
    В интерфейсе ручной корректировки должны отражаться не только коды, но и названия аналитики (измерения) (Приложение 3. Особые Требования к функциональности системы, п. 38, 17, 21);
    
11. 
    Поддержка механизма проводок и поддержка двойной записи в рамках процесса подготовки консолидированной отчетности. В случае отсутствия баланса в проводках система должна выдавать ошибку и результат этот ошибки должен отражаться в статусе мероприятия породившего эту ошибку;
    
12. 
    Ограничение набора аналитик их значений в зависимости от выбранного счета при ручных проводках. (Приложение 3. Особые Требования к функциональности системы, п. 20);
    
13. 
    Ведение неограниченного количества версий данных, создание новых версий путем копирования с обеспечением прозрачности данных новой версии;
    
14. 
    Возможность сохранения полной истории формирования и корректировки данных;
    
15. 
    Возможность системным образом устанавливать запрет на изменение данных по определенным комбинациям аналитических признаков (блокировка среза данных по версии, периоду, единице консолидации);
    
16. 
    Для обеспечения прозрачности процесса, необходимо, чтобы пакет консолидации был разбит на отдельные мероприятия, чтобы, в случае сбоя, можно было понять, на каком этапе возник сбой, какие автоматические проводки выполнились, а какие нет (Приложение 3. Особые Требования к функциональности системы, п. 12);
    
17. 
    Все автоматические мероприятия по процессам трансформации, аллокации и консолидации должны быть представлены списком, с привязкой к порядку их выполнения (Приложение 3. Особые Требования к функциональности системы, п. 13);
    
18. 
    Обеспечение обязательного предварительного автоматического удаления предыдущих результатов расчета при повторном запуске автоматических проводок (Приложение 3. Особые Требования к функциональности системы, п. 33);
    
19. 
    Расширение стандартных возможностей по реклассифицирующим и исключающим проводкам: включение в настройку реклассов всех аналитических признаков из модели (Приложение 3. Особые Требования к функциональности системы, п. 36);
    
20. 
    Обеспечение в диспетчере долей владения межстрочной разлиновки или переменной заливки строк двумя цветами (Приложение 3. Особые Требования к функциональности системы, п. 8);
    
21. 
    Настройка монитора консолидации:
    
    • 
      Требуется обеспечить полноценный монитор консолидации с возможностью запуска всех необходимых мероприятий (перенос сальдо, Script logic и т.д.) (Приложение 3. Особые Требования к функциональности системы, п. 6);
      
    • 
      Требуется обеспечить функциональность множественного выбора единиц консолидации при установке рабочего статуса. Пользователь должен иметь возможность выбирать узлы иерархии компаний и (или) отдельные компании (Приложение 3. Особые Требования к функциональности системы, п. 3);
      
    • 
      Требуется наличие монитора/нескольких мониторов мероприятий (загрузка данных, проверка, автоматические и ручные проводки и т.п.) по трансформации, консолидации и аллокации, который/которые бы отражал статусы выполнения мероприятий по каждой единице консолидации или каждой группе компаний (Приложение 3. Особые Требования к функциональности системы, п. 37);
      
    • 
      Требуется в наличие в мониторе трансформации, аллокации и консолидации мероприятий ручной проводки, при вызове которых (в web-интрефейс) для выполняющей этот процесс функции будут переданы данные единицы консолидации / группы компаний, периода, кода проводки, версия отчетности (Приложение 3. Особые Требования к функциональности системы, п. 34);
      
    • 
      Статус выполнения пакетов должен быть привязан к единице консолидации (Приложение 3. Особые Требования к функциональности системы, п. 19);
      
    • 
      Статус выполнения мероприятия в мониторе консолидации (или в BPF) должен автоматически возвращать результат выполнения данного мероприятия (ошибка, предупреждение, успех). Не допускается установка статуса мероприятия пользователем вручную, без связи с фактом выполнения и результатом работы мероприятия (Приложение 3. Особые Требования к функциональности системы, п. 4);
      
    • 
      Необходим функционал (web-интерфейса) для запуска консолидации кнопкой или пунктом меню "консолидировать". Данная функция должна обеспечивать не только запуск консолидации (кнопка «консолидировать»), но и активировать возможность просмотра статусов по всем ЕК и всем пакетам на одном экране (монитор консолидации) (Приложение 3. Особые Требования к функциональности системы, п. 11);
      
    • 
      Блокирование для выбранных (или для всех) компаний монитора консолидации на выполнение в нем действий пользователями;
      
    • 
      Требуется обеспечить возможность сортировки единиц консолидации по номеру (Приложение 3. Особые Требования к функциональности системы, п. 9).
      
22. 
    Журналирование операций:
    
    • 
      Необходим журнал (отчет), в котором пошагово можно проверить расчет суммы автоматической поправки, включая промежуточные итоги расчета для уровней трансформации, аллокации и консолидации данных (Приложение 3. Особые Требования к функциональности системы, п. 18, 35, 2);
      
    • 
      Требуется более детальный аудиторский след выполнения пакетов трансформации и консолидации, частности, требуется выводить информацию: какие конкретно функции (бизнес-правила) отработали в рамках запущенного пакета, какие при этом записи были сгенерированы, какие ошибки возникли (Приложение 3. Особые Требования к функциональности системы, п. 5);
      
    • 
      Требуется обеспечить возможность экспорта журналов ручных проводок в формат MS Excel (Приложение 3. Особые Требования к функциональности системы, п. 7);
      
    • 
      При выведении ошибки при проведении мероприятия должен быть подробный отчет для пользователя в бизнес-терминах, без излишней технической детализации (Приложение 3. Особые Требования к функциональности системы, п. 15);
      
    • 
      Отчет о журнальных проводках должен экспортироваться в MS Excel из web, нужна доработка (аналог "список итоговых позиций", или "список итоговых записей" которые сейчас экспортируются в MS Excel) (Приложение 3. Особые Требования к функциональности системы, п. 16);
      

• 
  Трансформационные проводки (35);
  
• 
  Аллокационные проводки (113);
  
• 
  Консолидационные BS&PL проводки (67);
  
• 
  Консолидационные БДПС проводки (15).