что такое автоматизированная система ас сбербанк
Информационная безопасность банковских безналичных платежей. Часть 2 — Типовая IT-инфраструктура банка
В первой части нашего исследования мы рассмотрели работу системы банковских безналичных платежей c экономической точки зрения. Теперь настало время посмотреть на внутреннее устройство ИТ-инфраструктуры банка, с помощью которой эти платежи реализуются.
Disclaimer
Статья не содержит конфиденциальной информации. Все использованные материалы публично доступны в Интернете, в том числе на сайте Банка России.
Глава 1. Общее описание ИТ-инфраструктуры
Основные термины
автоматизированная система; AC: Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.
информационная система — совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств;
В рамках данного исследования оба термина будут использоваться как синонимы.
Справедливость подобного подхода можно доказать тем, что в Приказе ФСТЭК России от 11.02.2013 N 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» для защиты информационных систем госрегулятор предписывает руководствоваться ГОСТами по автоматизированным системам.
Помимо информационных систем в IT-инфраструктуре банка можно выделить еще один тип элементов — информационные сервисы, или, как их часто называют, роботы.
Дать определение понятию информационный сервис довольно сложно, поэтому просто перечислим его основные отличия от информационной системы:
Автоматизированная банковская система
Ядром информационной инфраструктуры любого банка является автоматизированная банковская система или сокращенно АБС.
автоматизированная система, реализующая банковский технологический процесс.
Данное определение позволяет подвести под него практически любую IT-систему в банке. В то же время обычные банковские служащие называют АБС ту систему, которая занимается учетом банковских счетов, проводок между ними (движением денежных средств) и остатков. Второе определение не противоречит первому и более четко его детализирует, им и будем пользоваться дальше.
В современных Российских банках наиболее распространенными являются следующие АБС :
Иногда в банках параллельно используют несколько АБС различных производителей. Зачастую это происходит, когда банк пытается перейти с одной АБС на другую, но возможны и менее тривиальные причины.
Прикладные информационные системы
Несмотря на то что АБС автоматизирует довольно большое количество задач, она не покрывает все нужды банка. Есть задачи, которые АБС не делает вообще или делает не так, как хочет того банк. Поэтому к АБС подключаются (интегрируются) другие информационные системы, автоматизирующие отдельные бизнес-процессы. В дальнейшем подобные информационные системы будем называть — прикладными информационными системами.
Примерами прикладных информационных систем могут быть:
Инфраструктурные информационные системы
Помимо АБС и прикладных информационных систем, автоматизирующих основные бизнес-процессы, в банках также присутствует приличное количество вспомогательных инфраструктурных информационных систем. Примерами подобных систем могу быть:
Информационные сервисы
В банках используется гигантское количество различных информационных сервисов, выполняющих простые, рутинные функции, например, загрузка справочников БИК и ФИАС, публикация курсов валют на официальном сайте и т.д.
Клиентские части сторонних информационных систем
Отдельного упоминания стоят клиентские части внешних по отношению к банку информационных систем. В качестве примеров приведу:
Типовые способы интеграции информационных систем
Для интеграции информационных систем обычно применяются следующие механизмы:
Модули интеграции
Под модулем интеграции будем понимать виртуальный элемент IT-инфраструктуры, реализующий интеграцию других элементов IT-инфраструктуры.
Данный элемент мы назвали виртуальным, потому что его функционал может быть реализован, как в виде отдельного специализированного элемента ИТ-инфраструктуры (например, информационного сервиса), так и в виде компонентов интегрируемых информационных систем. Более того, в качестве модуля интеграции может выступать даже человек, «вручную» переносящий информацию между интегрируемыми информационными системами.
Пример ИТ-инфраструктуры банка
На Рис.1 можно увидеть фрагмент типовой информационной инфраструктуры банка, содержащий рассмотренные выше типы элементов.
Глава 2. Инфраструктура безналичных расчетов
Если посмотреть на эту схему (Рис.1) с точки зрения осуществления безналичных расчетов, то можно увидеть, что банк реализует их при помощи:
Для успешного функционирования банк обязан обеспечивать у себя информационную безопасность всех перечисленных способов осуществления платежей. Рассмотреть их в рамках одного, даже крупного исследования весьма проблематично, и поэтому мы сконцентрируемся только на одном наиболее критичном, с точки зрения возможных потерь, направлении — платежном взаимодействии банка с Банком России.
Инфраструктура обеспечения платежного взаимодействия с Банком России
Рис. 2.
IT-инфраструктуру платежного взаимодействия банка с Банком России будем рассматривать на примере исполнения платежа, отправляемого в адрес клиента другого банка.
Как мы помним из первой части, вначале клиент должен передать в банк платежное поручение. Сделать это он может двумя способами:
Если клиент передал платежное поручение на бумажном носителе, то работник банка на его основании делает электронное платежное поручение в АБС. Если распоряжение было подано через ДБО ИКБ, то через модуль интеграции оно попадает в АБС автоматически.
Доказательством того, что именно клиент сделал распоряжение о переводе денежных средств, в первом случае является лично подписанный им бумажный документ, а во втором, электронный документ в ДБО ИКБ, заверенный в соответствии с договором.
Обычно для заверения электронных документов клиентов — юридических лиц в ДБО ИКБ применяют криптографическую электронную подпись, а для документов клиентов — физических лиц коды SMS-подтверждений. С юридической точки зрения для заверения электронных документов в обоих случаях банки обычно применяют правовой режим аналога собственноручной подписи (АСП).
Попав в АБС, платежное поручение в соответствии с внутренними регламентами банка проходит контроль и передается для исполнения в платежную систему Банка России.
Технические средства взаимодействия с платежной системой Банка России
Технические средства (программное обеспечение), используемые для взаимодействия с платежной системой Банка России могут варьироваться в зависимости от территориального учреждения Банка России, обслуживающего корр. счет банка.
Для банков, обслуживаемых в Московском регионе, применяется следующее ПО:
АРМ КБР
АРМ КБР – это ПО, с помощью которого уполномоченные работники банка осуществляют шифрование и электронную подпись исходящих платежных документов, а также расшифровку и проверку электронной подписи платежных документов, поступающих из Банка России. Но, если быть более точным, то АРМ КБР в своей работе оперирует не платежными документами, а электронными сообщениями (ЭС), которые бывают двух типов:
Для того чтобы АРМ КБР мог обработать платеж, он должен быть преобразован в файл, содержащий электронное платежное сообщение формата УФЭБС. За подобное преобразование отвечает модуль интеграции АБС с платежной системой Банка России. С технической точки зрения подобные преобразования довольно просты, поскольку формат УФЭБС основан на XML.
Файлы электронных сообщений покидают модуль интеграции АБС в открытом виде и помещаются в специальную папку файловой системы (обычно это сетевая папка), которая настроена в АРМ КБР для электронных сообщений, имеющих статус «Введенные». На ранее представленной схеме (Рис. 2.) эта папка обозначена как «Папка 1».
Затем в процессе обработки электронные сообщения меняют свои статусы на «Контролируемые», «Отправленные» и т. д., что технически реализуется путем перемещения файла с электронным сообщением в соответствующие папки, которые настроены в АРМ КБР. На схеме (Рис. 2.) эти папки обозначены как «Папка 2».
В определенный момент технологической обработки (установленный внутренними регламентами банка) исходящих электронных сообщений они шифруются и подписываются электронной подписью с помощью СКАД Сигнатура и закрытых криптографических ключей ответственных работников.
СКАД Сигнатура
СКАД Сигнатура, это СКЗИ, разработанное компанией ООО «Валидата» по заказу Банка России и предназначенное для защиты информации в платежной системе Банка России. Данного СКЗИ нет в открытом доступе (кроме документации, размещенной на сайте ЦБ РФ), и оно распространяется Банком России только среди участников его платежной системы. К отличительным особенностям данного СКЗИ можно отнести:
Зашифрованные и подписанные электронные сообщения помещаются в специальную папку, на схеме (Рис. 2.) это «Папка 3». УТА непрерывно мониторит эту папку и, если он видит там новые файлы, передает их в ЦБ РФ одним из следующих способов:
Следует отметить, что все электронные сообщения, с которыми работает УТА, зашифрованы и подписаны электронной подписью.
Получив зашифрованное электронное сообщение, УТА перекладывает его в папку с входящими зашифрованными сообщениями. Уполномоченный работник с помощью своих криптоключей и АРМ КБР проверяет электронную подпись и расшифровывает сообщение.
Далее обработка производится в зависимости от типа электронного сообщения. Если это платежное сообщение, то оно через модуль интеграции передается в АБС, где на его основании формируются бухгалтерские проводки, изменяющие остатки на счетах. Важно отметить, что при взаимодействии АБС (модуля интеграции) и АРМ КБР используются файлы стандартного формата в открытом виде.
В процессе функционирования АРМ КБР ведет журнал своей работы, который может быть реализован в виде текстовых файлов или с помощью БД, работающих под управлением СУБД.
Альтернативные схемы обработки
Мы рассмотрели «классическую» схему работы системы. В реальности существует множество ее разновидностей. Рассмотрим некоторые из них.
Разновидность 1. Разделение контуров отправки и приема сообщений
Реализуется схема с двумя АРМ КБР. Первый работает с участием человека и выполняет только отправку сообщений, второй работает в автоматическом режиме и выполняет только прием сообщений.
Разновидность 2. Полный автомат
АРМ КБР настраивается на работу полностью в автоматическом режиме без участия человека
Разновидность 3. Изолированный АРМ КБР
АРМ КБР функционирует как выделенный компьютер, не подключенный к сети банка. Электронные сообщения передаются на него человеком-оператором с помощью ОМНИ.
Перенос электронной подписи из АРМ КБР в АБС
Банк России планирует перейти на новую технологическую схему обработки платежей, при которой электронные сообщения будут подписываться не в АРМ КБР, как было ранее, а в АБС (точнее в модуле интеграции АБС — АРМ КБР).
Для реализации данного подхода выпущена новая версия АРМ КБР, которая стала называться АРМ КБР-Н (новая). Все основные изменения можно увидеть, если сравнить схемы информационных потоков, проходящих через АРМ КБР старой и новой версии.
Рассмотрим схему информационных потоков в классическом АРМ КБР. Источник схемы – официальная документация на АРМ КБР «АВТОМАТИЗИРОВАННОЕ РАБОЧЕЕ МЕСТО КЛИЕНТА БАНКА РОССИИ. Руководство программиста. ЦБРФ.61209-04 33 01».
Рис. 3.
Примечания.
Рис. 4.
С точки зрения криптографии АРМ КБР-Н отвечает за шифрование / расшифрование электронных сообщений, а также за проверку электронных подписей на них. Формирование электронных подписей перенесено в модуль интеграции АБС.
Логично предположить, что данный модуль также должен будет проверять подписи под сообщениями, полученными из АРМ КБР-Н. С технической точки зрения это не является обязательным, но с точки зрения обеспечения безопасности имеет критическое значение, поскольку обеспечивает целостность сообщений, передаваемых между АБС и АРМ КБР-Н.
Помимо файлового интерфейса взаимодействия между АБС, АРМ КБР-Н и УТА добавлен интерфейс IBM WebSphere MQ, что позволяет строить сервис-ориентированную ИТ-инфраструктуру банка и решить проблему старой схемы с организацией одновременной работы нескольких операторов, ответственных за отправку платежей.
Общие требования к автоматизированной системе «Управление внутрихозяйственной деятельностью Сбербанка России ОАО» на базе решений SAP ERP
Общие требования к автоматизированной системе «Управление внутрихозяйственной деятельностью Сбербанка России ОАО» на базе решений SAP ERP
1. Программа внедрения SAP ERP. 4
2. Цели создания АС «УВХД». 4
3. Функциональные требования к АС «УВХД». 5
ФТ-1. Общие функциональные требования к системе. 5
ФТ-1.1 Требования к функциональным рамкам системы.. 5
ФТ-1.2 Требования к организационным рамкам системы.. 5
ФТ-1.3 Требования к модели бизнес процессов. 5
ФТ-1.4 Требования к интеграции. 5
ФТ-1.5 Требования к транзакционности отражения бизнес операций. 5
ФТ-1.6 Требования к распределенности регистрации бизнес операций. 5
ФТ-1.7 Требования к полноте управленческого учета. 5
ФТ-1.8 Требования к построению отчетов. 6
ФТ-1.9 Требования к нормативно справочной информации. 6
ФТ-2. Управление закупками и запасами. 6
ФТ-2.1 Общие требования к блоку бизнес процессов Управление закупками и запасами 6
ФТ-2.2 Планирование закупок. 7
ФТ-2.3 Управление закупками. 7
ФТ-2.4 Управление запасами. 7
ФТ-2.5 Управление услугами. 7
ФТ-2.6 Ведение справочника ресурсов. 7
ФТ-3. Управление договорами (Расширение Проекта АС «БРиЗ») 8
ФТ-4. Бухгалтерский учет. 8
ФТ-4.1 Общие требования к блоку бизнес процессов Бухгалтерский учет. 8
ФТ-4.2 Система должна обеспечить ведение аналитической главной книги. 9
ФТ-5. Налоговый учет. 9
ФТ-6. Управленческий учет (управление расходами) 9
ФТ-6.1 Учет расходов по МВЗ. 9
ФТ-7. Управление бюджетом (расширение Проекта АС «БРиЗ») 9
ФТ-8. Требования к модулям SAP. 9
Термины и определения
Количественный учет материальных ценностей (МЦ) Банка, в разрезе Материально Ответственных Лиц (МОЛ) и прочей управленческой аналитики, применяемый к МЦ после списания стоимости данного объекта материального учета на расходы
Единица товарно-материального учета
Минимальная единица с точки зрения бухгалтерского учета, идентифицирующая физический объект (материальные ценности) путем перечисления его свойств и характеристик
Внутренний первичный документ управленческого учета, предназначенный для регистрации факта резервирования средств в бюджете, а также регистрации факта оплаты и/или отнесения на расходы зарезервированной суммы
Место возникновения затрат, дополнительная аналитика, используемая для целей управленческого учета в качестве объекта сбора и перераспределения затрат
Нематериальные объекты (работы и услуги, нематериальные активы, неисключительные права), приобретаемые вне Банка и потребляемые его подразделениями в процессе выполнения возложенных на них функций
Условно постоянный (в рамках финансового периода) перечень материальных ценностей(основные средства, инвентарь и принадлежности, материалы, издания, специальная и форменная одежда и т. д.), работ, услуг, нематериальных активов и неисключительных прав, закупаемых Банком для обеспечения хозяйственной деятельности. Уровень детализации справочника ресурсов должен обеспечивать необходимую аналитику для процессов планирования, бюджетирования, бухгалтерского, налогового и управленческого учета. Структура и уровень детализации справочника будут определены на фазе подготовки «Концептуального проекта»
Совокупность хозяйственных операций по приобретению, перемещению, реализации, выбытию по ветхости, выдачи в подразделения материальных ценностей, регистрируемых в системе в разрезе единиц товарно-материального учета в количественном и стоимостном выражении
Учет затрат в разрезе управленческих аналитик для целей внутренней отчетности
2. Программа внедрения SAP ERP
В рамках повышения эффективности управления расходами в Банке реализуется Программа внедрения SAP ERP.
· Повышение эффективности управления расходами по административно-хозяйственной деятельности;
· Повышение прозрачности и качества данных;
· Повышение эффективности бизнес процессов;
· Повышение интегрируемости ИТ-систем.
1.2 Функциональные рамки Программы:
· Планирование и бюджетирование;
· Финансы (бухгалтерский, налоговый и управленческий учет);
· Снабжение и закупки (снабжение, склады, инвентаризация, логистика);
· Управление персоналом (развитие, администрирование, расчет ЗП);
· Аналитика (финансовый анализ, оперативный анализ, анализ персонала);
· Корпоративные сервисы (управление портфелем объектов недвижимости и др.).
1.3 Географические рамки Программы:
· Московский Банк Сбербанка;
· 17 Территориальных Банков.
1.4 Функциональный объем внедряемого решения.
В рамках программы внедрения SAP ERP предлагается реализовать ряд проектов (подробнее см. «Порядок проведения конкурса») по внедрению автоматизированной системы управления внутрихозяйственной деятельностью Сбербанка России базе решений SAP ERP (далее АС «Управление внутрихозяйственной деятельностью», АС «УВХД», Система). Внедрение АС «УВХД» включает автоматизацию следующих функциональных блоков:
· Управление закупками и договорами;
· Бухгалтерский и налоговый учет;
3. Цели создания АС «УВХД»
· Обеспечение единого информационного пространства для сквозных процессов по учету хозяйственных операций (с момента регистрации договора, до момента оплаты обязательств по договору).
· Обеспечение однократного ввода первичных документов с одновременным отражением необходимых данных в оперативном, бухгалтерском и налоговом учете.
· Уменьшение складских запасов за счет получения оперативной и актуальной информации по остаткам на складах.
· Повышение эффективности деятельности Банка в части договорной работы.
· Сокращение времени и трудозатрат на обработку хозяйственных операций путем стандартизации и унификации процессов управления и учета.
· Уменьшение трудоемкости при подготовке бухгалтерской, налоговой, управленческой и статистической отчетности в части ведения хозяйственной деятельности Банка.
· Подготовка данных в части учета хозяйственной деятельности для формирования отчетности по стандартам МСФО.
· Повышение ответственности сотрудников за ведение хозяйственных операций.
4. Функциональные требования к АС «УВХД»
ФТ-1. Общие функциональные требования к системе
ФТ-1.1 Требования к функциональным рамкам системы
В ходе внедрения АС «УВХД» должны быть автоматизированы следующие функциональные блоки:
· Управление закупками и запасами;
· Управление договорами (расширение АС «БРиЗ»);
· Бухгалтерский учет и отчетность;
· Налоговый учет и отчетность;
· Управленческий учет (управление затратами);
· Управление бюджетом (расширение АС «БРиЗ»).
ФТ-1.2 Требования к организационным рамкам системы
ФТ-1.2.1 Система должна обеспечить автоматизацию бизнес процессов всех подразделений Банка, задействованных в его хозяйственной деятельности.
ФТ-1.3 Требования к модели бизнес процессов
ФТ-1.3.1 Создаваемая модель бизнес процессов в Системе должна учитывать возможность тиражирования решения на другие организационные структуры Банка (Территориальные Банки).
ФТ-1.3.2 Создаваемая модель бизнес процессов в Системе должна учитывать возможные варианты развития Системы в будущем ходе реализации Программы внедрения SAP ERP(см. раздел 1 настоящего Приложения).
ФТ-1.4 Требования к интеграции
ФТ-1.4.1 Система должна обеспечивать интеграцию с внешними информационными системами, в случае, если выполнение бизнес процессов, входящих в функциональные рамки Проектов внедрения АС «УВХД», требует передачи/получения данных из других систем как в режиме «онлайн» так и в режиме «оффлайн».
ФТ-1.4.2 Обмен данными с внешними системами должен быть обеспечен с периодичностью, необходимой и достаточной для транзакционного функционирования бизнес процесса.
ФТ-1.5 Требования к транзакционности отражения бизнес операций
ФТ-1.5.1 Система должна обеспечивать регистрацию бизнес операций в режиме реального времени, по факту их свершения.
ФТ-1.5.2 Система должна обеспечить однократную регистрацию хозяйственных операций, без дублирующегося ввода данных и первичных документов, с учетом всей информации, необходимой для бухгалтерского, налогового и управленческого учета.
ФТ-1.6 Требования к распределенности регистрации бизнес операций
ФТ-1.6.1 Система должна обеспечивать регистрацию бизнес операции сотрудником Банка, отвечающим за результат данной операции, в месте ее возникновения.
ФТ-1.7 Требования к полноте управленческого учета
ФТ-1.7.1 Реализация управленческого учета в Системе должна обеспечивать полный набор аналитических признаков, необходимых для анализа управленческой информации и поддержки принятия управленческих решений.
ФТ-1.8 Требования к построению отчетов
ФТ-1.8.1 Система должна позволять строить аналитические отчеты в необходимом числе разрезов по любым признакам и аналитикам, предусмотренным в Системе.
ФТ-1.8.2 Система должна позволять формировать отчеты в соответствии с требованиями, предусмотренными регламентирующими документами Банка.
ФТ-1.8.3 Перечень отчетов, приведенный в данных функциональных требованиях ниже, не является исчерпывающим и будет уточняться на этапе концептуального проектирования.
ФТ-1.9 Требования к нормативно справочной информации
ФТ-1.9.1 Система должна обеспечить единой, полной и актуальной нормативно-справочной информацией все подразделения Банка, задействованные в ведении хозяйственной деятельности.
ФТ-1.9.2 Система должна обеспечивать реализацию двух типов справочников:
· универсальные справочники (обеспечивают работу 2х и более блоков бизнес-процессов);
· уникальные справочники (обеспечивают работу внутри одного блока бизнес-процессов).
ФТ-2. Управление закупками и запасами
Данный блок включает в себя следующие бизнес процессы:
· Управление запасами (материально техническое обеспечение);
· Ведение справочника ресурсов.
ФТ-2.1 Общие требования к блоку бизнес процессов Управление закупками и запасами
ФТ-2.1.1 Система должна быть интегрирована с блоком бизнес процессов по ведению договоров, автоматизированным в рамках АС «БРиЗ» в части регистрации спецификации к договору.
ФТ-2.1.2 Система должна обеспечивать ведение операций по приобретению ресурсов, закупаемых для хозяйственной деятельности Банка и централизованных закупок в адрес Территориальных банков, совершаемых от имени ЦА.
ФТ-2.1.3 В системе должна быть предусмотрена возможность ведения операций по приобретению ресурсов в валюте контракта и условных единицах, с возможностью пересчета в рубли, как в соответствии со справочником курсов валют (неограниченное число курсов), так и по курсам, определенным положениями контракта.
ФТ-2.1.4 Система должна поддерживать операции по безналичному и наличному виду расчетов с контрагентами.
ФТ-2.1.5 Система должны обеспечивать ведение операций по приобретению складируемых, нескладируемых ресурсов и услуг в разрезе имеющихся аналитик.
ФТ-2.1.6 В Системе должен быть предусмотрен механизм хранения отсканированных копий оригиналов документов, связанных с регистрируемыми операциями.
ФТ-2.1.7 Система должна обеспечивать учет связанных услуг, в случае, если стоимость данных услуг увеличивает балансовую стоимость приобретенных ресурсов.
ФТ-2.1.8 В Системе должно быть предусмотрено автоматическое формирование записей в бухгалтерском, налоговом и управленческом регистре в момент регистрации операции.
ФТ-2.1.9 В рамках блока бизнес процессов по управлению закупками и запасами система должна обеспечивать формирование отчетов.
ФТ-2.2 Планирование закупок
ФТ-2.2.1 В ходе реализации Проекта АС «УВХД» процесс бюджетирования закупок должен быть интегрирован с процессами оперативного планирования и исполнения закупок с целью контроля количества закупаемых ресурсов и сбора фактических данных о совершенных закупках (реализовано в АС «БРиЗ»).
ФТ-2.3 Управление закупками
В системе должны быть предусмотрены следующие функции в части управления закупками:
· Регистрация оперативных заявок на потребление ТМЦ, работ и услуг.
· Формирование оперативного плана закупок ТМЦ, работ и услуг.
· Регистрация спецификации на поставку ТМЦ/услуг.
· Контроль осуществления поставок ТМЦ, оказания услуг.
· Регистрация расчетных документов от Поставщика всех видов ресурсов.
ФТ-2.4 Управление запасами
ФТ-2.4.1 Система должна обеспечить ведение оперативного, бухгалтерского и налогового учета в рамках Банка для всех ресурсов в следующих разрезах:
· В системе должна быть предусмотрена возможность резервирования объемов доступного запаса складируемых ресурсов (под конкретную заявку), находящихся в местах хранения, для каждого подразделения получателя.
· Система должна обеспечить возможность ведения внесистемного учета в отношении группы ресурсов «материальные запасы долгосрочного использования».
· Система должна обеспечить возможность ведения оперативного учета в разрезе материально ответственных лиц (МОЛ) по всем видам ресурсов.
· По факту регистрации операции, связанных с движением запасов, в системе должны автоматически формироваться первичные документы с возможностью формирования печатных форм.
ФТ-2.4.2 В системе должна быть предусмотрена возможность интеграции с системой штрихового кодирования для автоматизации операций по учету складируемых ресурсов. При этом системой должна распознаваться информация, поступающая со сканера и(или) ввода штрих-кода вручную для следующих операций.
· Регистрация поступления ТМЦ.
· Регистрация перемещения складируемых ТМЦ.
· Регистрация отпуска ТМЦ со склада.
· Проведение и регистрация результатов инвентаризации.
ФТ-2.5 Управление услугами
ФТ-2.5.1 В системе должна быть реализована возможность регистрации факта оказания работ/услуг без формирования записей в бухгалтерском и управленческом.
ФТ-2.5.2 В момент проверки и регистрации акта выполненных работ/оказанных услуг, система должна обеспечить автоматический контроль на не превышение количества и стоимости по каждой услуге.
ФТ-2.6 Ведение справочника ресурсов
ФТ-2.6.1 Система должна обеспечить ведение и поддержание в актуальном и непротиворечивом состоянии единого справочника закупаемых ресурсов.
ФТ-2.6.2 Уровень детализации справочника ресурсов должен обеспечивать необходимую аналитику для проведения план-факт анализа закупок, запасов на складе, а также формирования первичных документов, порождаемых в процессе хозяйственной деятельности.
ФТ-3. Управление договорами (Расширение АС «БРиЗ»)
В рамках АС «БРиЗ» были автоматизированы следующие бизнес процессы:
· Учет платежей и расходов.
ФТ-3.1.1 В ходе реализации Проекта «УВХД» система должна обеспечить интеграцию бизнес процессов, реализованных в ходе выполнения проекта АС «БРиЗ» с автоматизируемыми бизнес процессами управления закупками и запасами, управлением финансами, бухгалтерским, налоговым и управленческим учетами.
ФТ-3.1.2 Система должна обеспечивать обязательное наличие аналитики договор/дополнительное соглашение (счет, в случае закупки без договора) при регистрации первичных документов в системе.
ФТ-3.1.3 Система должна обеспечивать формирование отчета об исполнении договоров во всех допустимых разрезах.
ФТ-4. Бухгалтерский учет
Данный блок бизнес процессов включает в себя следующие бизнес процессы:
· Ведение аналитической главной книги;
· Учет расчетов с контрагентами;
· Учет материальных запасов (запасы ТМЦ и материалов за исключением ОС и НМА);
· Учет расходов будущих периодов;
· Учет расчетов с территориальными банками;
· Учет затрат (отнесение на затраты стоимости материальных ценностей, услуг и пр. в соответствии с положением 302П).
ФТ-4.1 Общие требования к блоку бизнес процессов Бухгалтерский учет
ФТ-4.1.1 Система должна обеспечивать ведение бухгалтерского учета и документальное оформление бухгалтерских документов в части операций, относимых к хозяйственной деятельности Банка, в соответствии с Положением 302-П ЦБ РФ, указанием Банка России 2161-У, учетной политикой Банка.
ФТ-4.1.2 Система должна обеспечивать ведение журнала регистрации проводок с указанием пользователя, осуществившего ввод проводки, времени и месте ее регистрации.
ФТ-4.1.4 При регистрации проводок, Система должна контролировать корректность и допустимость использования аналитических признаков, обязательных для данного вида проводки.
ФТ-4.1.5 Система должна быть интегрирована с АБС «Гамма» в части передачи данных обо всех проводках и платежных поручениях к оплате и загрузке данных совершенных платежей.
ФТ-4.2 Система должна обеспечить ведение аналитической главной книги.
ФТ-5. Налоговый учет
ФТ-5.1.1 Система должна обеспечивать раздельный учет расходов по признаку «учитываемый / не учитываемый» при расчете налогооблагаемой базы по налогу на прибыль.
ФТ-5.1.2 Система должна обеспечивать формирование регистров налогового учета.
ФТ-6. Управленческий учет (управление расходами)
ФТ-6.1 Учет расходов по МВЗ
ФТ-6.1.1 Система должна обеспечивать ведение справочника мест возникновения затрат (МВЗ), с учетом требований управленческой отчетности (отчет по прибылям и убыткам) к хозяйственным расходам Банка.
ФТ-6.1.2 Система должна обеспечивать возможность отнесения расходов, учитываемые в рамках АС «БРиЗ» (услуги, ТМЦ, ОС, НМА) на места возникновения затрат при регистрации первичного документа, подтверждающего факт хозяйственной деятельности относимой на расходы.
ФТ-6.1.3 Система должна обеспечивать прямой перенос расходов, учитываемых в рамках АС «УВХД» (услуги, ТМЦ, ОС, НМА) с одного МВЗ на другое(ие) МВЗ (конечные потребители), без изменения данных бухгалтерского учета, в целях управленческого учета.
ФТ-6.1.4 Система должна обеспечивать возможность отнесения расходов при выбытии/переоценке ОС/НМА, учитываемые в рамках Проекта №2 на места возникновения затрат.
Реализация управленческого учета платежей и расходов является развитием решения Проекта АС «БРиЗ».
ФТ-7. Управление бюджетом (расширение Проекта АС «БРиЗ»)
ФТ-7.1.1 В рамках Проекта АС «УВХД» Система должна обеспечивать получение Бюджета расходов и затрат на следующий финансовый год из системы планирования Бюджета, созданной в рамках АС «БРиЗ».
ФТ-7.1.2 В рамках Проекта АС «УВХД» Система должна обеспечивать интеграцию процессов по управлению закупками и запасами с созданной моделью ведения и контроля бюджета на Проекте АС «БРиЗ».
ФТ-7.1.3 В системе должна быть предусмотрена возможность проверки бюджета платежей (в момент регистрации графика платежей по договору) и/или бюджета обязательств (в момент регистрации спецификации к договору на закупку).
ФТ-7.1.4 Система должна обеспечивать регистрацию и контроль бюджетных обязательств по договорам, срок действия которых распространяется на будущие отчетные периоды.
ФТ-7.1.5 Система должна обеспечивать проверку, согласование и сохранение информации о заявках на платеж, а также поддерживать интеграцию с процессом учета платежей (бухгалтерский учет).
ФТ-7.1.6 Система должна обеспечивать сбор фактических данных о платежах и расходах, понесенных в отчетном периоде для формирования отчета по план-факт анализу исполнения сметы.
ФТ-8. Требования к модулям SAP
ФТ-8.1.1 Решение должно быть реализовано на базе следующих модулей SAP ERP: FI, CO, MM, RCM, BI-IP; BW.