b) На стадии внедрения системы необходимо сформировать ролевую модель для организации управлением доступа пользователей к компонентам системы. За администраторами Корпоративно-сервисного центра должны быть закреплены функции управления локальными серверами и пользователями.
c) Для обеспечения требований информационной безопасности корпоративного сетевого периметра при построении сегмента пограничных серверов должны использоваться межсетевые экраны и демилитаризованные зоны Заказчика.
d) Для внешнего доступа удалённых и внешних пользователей, а также для организации федеративных отношений с другими организациями, необходимо использовать действующие сертификаты, выпущенный коммерческим центром сертификатов.
4.1.10. Требования по сохранности информации при авариях
a) Должно обеспечиваться сохранение накопленной информации и штатное (нормальное) завершение работы системы при угрозе обесточивания физических серверов АСУ MTO. TMS за 10 минут до полной разрядки батарей ИБП, и их автоматический или ручной запуск после восстановления электропитания.
b) Для обеспечения сохранности информации при авариях в процессе эксплуатации должно применяться регулярное резервное копирование.
c) В службе АСУ MTO. TMS и их подсистемах должны быть предусмотрены меры по защите технических и программных средств от ошибочных действий персонала на основе разделения административных полномочий в соответствии с выполняемыми функциями и должностными обязанностями.
4.1.11. Требования к защите от влияния внешних воздействий
В помещениях с размещёнными серверами системы АСУ MTO. TMS Заказчик обеспечивает климатические условия, определяемые требованиями производителей используемых технических средств. Если условия эксплуатации не оговорены производителем, то должны быть обеспечены условия не хуже чем требуемые СанПиН 2.2.4.548-96.
4.1.12. Требования по стандартизации и унификации
Технические решения должны быть унифицированы, и позволять последовательное подключение к сервису АСУ MTO. TMS новых филиалов и представительств Компании, а также отключение от системы АСУ MTO. TMS (в случае реорганизации или ликвидации).
4.1.13. Дополнительные требования
На протяжении всего проекта Заказчик обеспечивает Исполнителю организационно-административную поддержку в целях исполнения задач проекта согласно требованиям настоящего ТЗ:
a) подготовка и согласование инициирующих документов по проекту;
b) исполнение конкурсных процедур;
c) ведение договоров на разработку системы и актирование работ по проекту;
d) обеспечение коммуникаций со специалистами и менеджерами Заказчика и смежных организаций;
e) предоставление информационных материалов;
f) ведение проектного документооборота и согласование документации в установленные сроки. Набор документов и регламент их ведения должны быть отражены в Уставе проекта;
g) ведение отчетности по проекту;
h) исполнение процедуры закрытия проекта. Процедуры закрытия проекта включают в себя подготовку приказа о вводе в ПЭ, подписание акта ввода в эксплуатацию, выдачу отзыва о работе исполнителя, выпуск пресс-релизов. Перечень документов должен быть отражен в Уставе проекта.
На этапе внедрения системы Заказчик предоставляет Исполнителю доступ к АСУ MTO. TMS для настройки системы.
4.2. Функциональные требования к блоку «Управление закупками».
4.2.1. Ценообразование и начало планирования в системе.
Предполагается следующий алгоритм расчета и хранения цен:
a) Документ «Прайс» (содержит номенклатуру и цену за единицу, имеет срок действия).
b) В случае отсутствия прайса, цена по номенклатуре подбирается из заказа поставщику по данной номенклатуре.
c) В случае отсутствия «Заказа поставщику» - цена должна подбираться из последнего тендера по данной номенклатуре.
d) В случае отсутствия тендера – цена подбирается из ПТУ (цена последнего закупа).
Если данная номенклатура является новой или по ней не проводилось никаких действий, должна быть возможность ввода цены вручную документом «Ввод цен» или при вводе потребности
В системе Расчет цен с использованием алгоритмов расчета на основании цен, предыдущих периодов, зарегистрированных в Системе должен, предполагать использование операций:
· Удалить (обнулить);
· Рассчитать по формуле;
· Рассчитать по ценам контрагентов;
· Округлить;
· Изменить цены на %;
· Цена из «Прайса»;
· Цена из последней поставки.
Операция «Удалить (обнулить)» позволит удалить (обнулить) цены на выбранную номенклатуру.
Операция «Рассчитать по формуле» позволит при указании типа цен, математического действия (плюс или минус) и значения, рассчитать цену, используя формулу.
Операция «Рассчитать по ценам контрагентов» позволит рассчитать цены на основании последних закупочных цен, определенного контрагента.
Операция «Изменить цены на %» позволит цены, имеющиеся в системе, либо произвольно рассчитанные пользователем, на определенный процент.
Операция «Цена из договора» позволит рассчитать последние цены из договоров поставки.
Операция «Цена из последней поставки» позволит рассчитать цены на основании последних поставок.
В Системе настраиваются типы цен номенклатуры предприятия и типы цен номенклатуры контрагентов:
· Плановых цен, используемых для планирования и подстановки в документы;
· Закупочных цен, используемых для анализа последних цен закупки и темпа роста цен;
· Договорных цен, используемых для определения цен поставки;
На основании введенных в Системе типов цен необходимо иметь возможность расчёта других типов цен. Также тип цен должен хранить информацию о валюте цен и методах округления.
Для регистрации в Системе плановых цен, с типом цены соответствующему, типу цены параметров планирования (справочник «Заявочная компания»), необходимо использовать документ «Установка цен номенклатуры».
Регистрации в Системе цен поступления (тип цены «Закупочная»), может осуществляться типовым механизмом. Для этого необходимо в договорах указывать тип цен контрагентов, а на закладке «Условия закупки», документа «Поступление товаров и услуг», включить флаг «Регистрировать цены закупки».
Регистрировать новые цены в Системе необходимо в разрезе филиалов. В работе на любых этапах цены по номенклатуре должны определяться в рамках организации документа.
Системе должна иметь возможность регистрировать цены в валюте отличной от управленческой валюты (управленческая валюта - RUB).
Планируется использовать отдельный тип цен для каждого календарного года. Например: Плановые цены (Новый год). При создании цены могут рассчитываться на основании плановых цен за прошлый год (Например, может быть создан тип цен = "Плановые цены 2016", данный тип цен будет рассчитываться, как (Плановые цены 2015)*K%), где К – коэффициент инфляции, задается пользователем.
4.2.2. Определение параметров планирования потребностей необходимо осуществлять с использованием справочника «Заявочная компания».
В рабочей области «Период заявочной компании», на форме элемента справочника «Заявочные компании», использовать реквизиты «Дата начала» и «Дата окончания», для контроля ввода долгосрочных потребностей в указанный ограниченный период. Данный контроль будет осуществляться на этапе ввода долгосрочных потребностей, посредством обработки «Ввод и согласование потребностей».
Система должна хранить значение действующей заявочной компании в регистре «Настройки организаций МТО». Значения будут храниться с периодом действия, равным периоду планирования заявочной компании и в разрезе организаций. В объекты системы данная заявочная компания должна подставляться по умолчанию в качестве значения реквизита «Заявочная компания». Объекты, в которых требуется автоматически заполнять реквизит «Заявочная компания»:
· Обработка «Ввод и согласование лимитов»;
· Обработка «Ввод лимитов»;
· Документ «Обеспечение ЗК»;
· Документ «Распределение МТР».
4.2.3. Формирование лимитов
Формирование лимитов должно осуществляться на основе разрезов планирования, определенных «Заявочной компанией». Для гибкого планирования системой должно быть предусмотрено два варианта списания лимитов:
· Жесткая связка – ввод и расход лимита по каждому разрезу планирования.
· Иерархическое планирование (мягкая связка). Планирование по разрезам планирования/списание по группе статей планирования. На примере статей затрат (Таблица 1.):
Таблица 1.
Группа статей затрат H | Наименование статей затрат | Лимит | Расход | |
Масла и смазки | 9 000,00 | 9 000,00 | ||
Статья затрат 1 | Масла для ДЭС | 3 000,00 | 8 000,00 | |
Статья затрат 2 | Масла для буровых насосов | 4 000,00 | 1 000,00 | |
Статья затрат 3 | Смазки для механизмов | 2 000,00 |
Из примера видно что лимит по группе статей затрат не превышен.
Настройка способа контроля лимита должна настраиваться в справочнике «Заявочная кампания».
4.2.4. Ввод и согласование потребностей.
При вводе долгосрочных или оперативных потребностей требуется подтягивать цены автоматически по следующему алгоритма описанного в п.1 «Ценообразование».
Если система не найдет цену по заданному алгоритму, инициатору потребности следует обратиться к ответственным сотрудникам, с ролью «Менеджер по управлению закупками», которые зафиксируют цену. Редактирование цен при вводе потребностей не доступно.
В случае нахождения на один период двух цен, Система может позволить опционально для каждой организации отдельно указать какую цену подставить:
· Максимальную;
· Последнюю.
Если цена не определилась, Система не должна позволить отправить на согласование данную потребность с выводом текстового оповещения пользователю. Установка плановой цены по нужной номенклатуре, доступно пользователям с ролью «Менеджер по управлению запасами» или «Организатор планирования.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
